Check accompanying documents especially for the components marked with an asterisk '*'.
Security: Due to its technical implementation, it is much more difficult to restore the previous logical state of the appliance, than to allow one of thousands of different states. Almost any attempt of manipulation in favour of an attacker who wants to leave no traces of his unauthorized intrusion, would likely leave other striking marks. Covert mission: failed!
In contrast to an ordinary alarm system, the Mesusa can be active all of the time, yet we do not have to take a notice of it. For example, in times of several people going in and out of your appartment and you would unconditionally trust them, you may simply ignore the information that the Mesusa offers. No one shall trade freedom for security!
Timeouts: All interactions are limited to about 1 minute of duration. This is to prevent batteries from being exhausted in case of a defective door switch or improperly closed door. Closing of door will always forward to the next operational state (i.e. armed/disarmed)!
Security considerations: In the alarm-functionality, we must somehow identify as 'authorized'. Our ticket is the four-digits code number that's been agreed on before leaving the hut. It is of course valid for only one operational cycle.
Chance that an attacker can guess the right access code and enter this code correctly, is about 1 to 9999. Brute-forcing numerous codes is therefore totally unrealistic option, given the fact that every failed attempt will result in 1-minute of acoustic alarm plus further delays. This is why four digits seem more than sufficient for this application.
If an attacker somehow spied on our valid code, he may indeed disarm the Mesusa instead of ours and continue his insiduous activities unchallenged. But now this ticket is no longer valid. When we return and enter this code to disarm the system, it won't work. Also any attempts from an attacker to perform a controller reset or power interruption will result in a invalid code from our perspective. That is to say: We will be informed about any door event or attempts to sabotage the Mesusa by a third-party.
Input method of the code number: Assuming the door has just been opened. In order to disarm the device, one must identify as the legitimate user. Mesusa prompts to enter the right code number with a blinkin "CodE" symbol. But how? Actually this is a very simple and easy protocol:
One may have to get used to this method at the first time, but then it is probably the simplemost method that goes with a minimum of switchplay. In practice it works pretty well! (We can, alternatively, keep the door switch open and use a pushbutton parallel to the current loop for faster / more responsive code entry.).
- First close that door again and by this start code entry. The display initially shows up "0000".
- The 1st digit is blinkin and being count-up slowly from 0 to 9. (don't panic, it's several cycles!)
- To confirm that 1st digit, we simply must re-open the door at the right moment.
- The 2nd digit is blinkin now and being also count-up from 0 to 9.
- To confirm the 2nd digit, we close the door at the right moment.
- 3rd digit ... open the door.
- 4th digit ... close the door.
- After the last digit has been entere this way, the whole code number will be counter checked. If the code was right, the whole display is gonna blink happily for some seconds, then display the number of possibly failed attempts ("ALxx"). If the code was not right, the acoustic alarm will be engaged...
Timeout before Leaving: If we simply wait more than 1 minute after a newly generated code has been displayed, the Mesusa will simply discard this code and stay 'disarmed'. With the next door opening, Mesusa would again be in the Leaving mode and not require authentification. This feature has proven very helpful in conjunction with receiving a visitor or postman at the door.
Timeout after Return: If no code number has been entered, or the entered number was wrong, the audible alarm will be triggered and after that, Mesusa will enter sleep mode. Minimum duration of such alarm is about 1 minute. There is no realistic way for an intruder to bypass the acoustic alarm and its registration. There is also no way to conceal failed attempts of code entry; when we enter our correct code later on, we will also be informed if and how many alarm events have occurred in the meantime. Door closing or timeout does not change alarm status!
|
|
| Circuit schematics on 'Mesusa door control and alarm device': Check accompanying documents especially for the components marked with an asterisk '*'. |
| MESUSA-Setup |
Jumper 1 |
Jumper 2 |
| Function 1 Door control, Normal |
closed |
closed |
| Function 1 Door control, Energy saving |
open |
closed |
| Function 2 Alarm, Normal |
closed |
open |
| Function 2 Alarm, Energy saving |
open |
open |
 |
 |
Battery life expectations: The very first prototype of the mesusa has run more than half a year with a small CR2032 lithium cell (BIOS battery from an old mainboard!). The rough calculations down below assume, that Mesusa is being activated in doorkeeper mode (F-1) with display lighting about 6 minutes per day. This would equal at least 3 door events (going out + coming back) with timeout being stressed each single event. Power consumption will then appear as such:
Case I: 3 x Alkaline AAA (Micro)
Nominal voltage: 4,5 V
Nominal capacity: 1200 mAh (roughly estimated)
Current (measured) with display on: 15 mA
Duty cycle per day: 6 min = 6/60 h = 0,1 h
Current consumption per day: 0,1 h * 15 mA = 1,5 mAh
Quiescent current: 4,5 V / 470.000 Ohm = 0,010 mA
Quiescent current per day: 0,010 mA * 24 h = 0,24 mAh
Total current per day: 1,5 mAh + 0,24 mAh = 1,74 mAh
Expected battery life: 1200 mAh / 1,74 mAh = 690 days = 1,9 yrs
Nearly 2 years of battery life with normal configuration, even 4 to 5 years should be feasible with energy saving option.
Case II: 1 x Lithium-Mangane button cell 20 mm x 3.2 mm (CR2032)
Nominal voltage: 3 V
Nominal capacity: 200 mAh
Current (measured) with display on: 8 mA
Duty cycle per day: 6 min = 6/60 h = 0,1 h
Current consumption per day: 0,1 h * 8 mA = 0,80 mAh
Quiescent current: 3,0 V / 470.000 Ohm = 0,0063 mA
Quiescent current per day: 0,0063 mA * 24 h = 0,15 mAh
Total current per day: 0,80 mAh + 0,15 mAh = 0,95 mAh
Expected battery life: 200 mAh / 0,95 mAh = 210 days = 0,6 yrs (half a year)
Well, with energy saving activated, even the button-cell option will presumably last one year or longer.
| |
|
 |
Once again, it all began on a plugboard (using big display from the project LED-Uhrenwecker.) |
 |
Test circuit on 'breadboard' (component side) |
 |
Test circuit on breadboard; in my workflow, these manually routed wires are direct template for layout artwork. |
 |
First PCB, preliminary layout (with modifications) solder side |
 |
First PCB, component side |
 |
Improvised DIL-10-sockets for the LED displays |
 |
One of the first PCB's built into some plastic case, reed-and-magnet- configuration. |
 |
Plastic prototype mounted to an appartment door (half open, code lights up) |