My burglary alarm system



  • Nowadays even cheap radar sensors are available. Several different versions you can buy for some dollars each. Some guy already compared those things. His result was that as far as detection performance is concerned one can take the cheapest available. And that one you can have for around ONE dollar!

    The aim of this project is to evaluate if such a cheap sensor can be used in a "real environment".

    I put together some thoughts about the the scope and use of the alarm system and module.

    The system should be as simple as possible. It uses radar sensor modules only. For control, data-processing, alerting and presentation eGeoffrey is used.

    Arming and dis-arming is done via:

    • push-button on the module

    • smartphone

    • time schedule

    When armed a LED blinks on the module.

    Power-supply via battery. Continuously loading via USB-adapter. No UPS facility.

    The power-level is reported. Alarm-level is adjustable.

    Heartbeat signal.

    Besides blinking an LED an accessory can be switched. Option to be selected via eGeoffrey.



  • I started working on the software and I looked in the eGeoffrey howto for an alarm system. Based on that I added some more detail to the description of my system.

    Requirements

    System on and off via switch action on small control box.
    System on and off via eGeoffrey.

    Alarm module is turned on with power supply switch.
    When power on, radar sensor is on.

    Scheduled activation:

    • when activation is done via button before time activation the button activation activates system.

    • when de-activation is done via button before time de-activation the button de-activation de-activates the system.

    Data communication

    Each module sends heartbeat.
    Status change of switch on control box is sent.
    Status change radar sensor of alarm module is sent.

    No data communication from eGeoffrey to modules.

    Data presentation

    When a radar message is received:

    • the status "1" stays visible after the module sends status "0". Reset is done via manual action on eGeoffrey.

    • the status "1" evokes an eGeoffrey alert. Email notification is sent 3 times.

    Option:
    Siren and flash light are switched on by eGeoffrey alert.



  • @user2684
    I have my sensor module operational.

    I am trying to activate the system in eGeoffrey following your HowTo.

    Observations:

    Alarm system

    Widget not editable.
    After setting Widget configuration → Control → Widget type to "2" and "save" the widget is larger.
    After that going to "Edit page" the widget can not be edited. The three selections for editing, the moving and deleting do NOT work anymore. The ON/OFF status can be changed.

    Colour switch of alarm signal.
    I would like to be able to switch the colour of the widget attached to the radar sensor. It should be green when NO alert is there and RED if the alert is evoked.

    I tried to use the "value" widget and change colour with "Widget configuration → Value → Value in green if between this range: 0 and Value in red if between this range: 1.
    This does not work.

    The next option would be to use the "Status" widget.
    The colour is changing. Now it is Red for the "0" value and Green for the "1". For an alarm signal it would be more natural to have the Green colour when there is no alarm and Red when there is.

    I would suggest one of three possibilities:
    have the value widget react not only on a range but also on a discrete value
    make it possible for the user to switch the colours of the status widget.
    introduce a new "alert widget" which is green and switches to red when the sensor is activated.(a "1" is received)

    Elapsed from a different sensor not working.

    "If you want instead to show the elapsed since the last time the device has reported a status change, set the sensor identifier in "Elapsed from a different sensor". Based on the example above it will be door_first_floor. In this way you can control if the sensor is armed or not and last time it triggered (e.g. set a new value)."

    Widget Configuration → Control → Associated sensor: onshuis/woonkamer/radar_armed.
    Widget Configuration → Control → Elapsed from a different sensor: onshuis/woonkamer/radar.

    Advanced editor - onshuis/woonkamer/radar:

    retain: single_value
    description: radar woonkamer
    service:
    configuration:
    topic: /mesh-out/+/onshuis/woonkamer/radar
    mode: push
    name: mqtt
    format: int

    Advanced editor - onshuis/woonkamer/radar_armed:

    retain: single_value
    description: radar woonkamer armed
    format: int
    After activation of the sensor the elapsed time in the _armed widget is not updated.

    Rule is not working.
    The macro is not working as expected.
    Instead of the very broad "top-down" approach I made the rule for the one sensor I have.
    I managed to get the rule working, but like we had once before, the rule could not be edited anymore. Deleted via "advanced manager" and created a new one.

    Besides that a remark to make for the user the logic more clear.

    " Step 4: create an alarm status
    We need a way to set the alarm on/off globally. To to this, create yet another sensor called e.g. alarm_status "

    In my perception a "status" is a state after an action has been performed.
    IMHO in this case the term "control" would be more clear. I created an extra sensor called "systemcontrol".

    This way we create the following situation:
    We have a "system" with "sensors". To have eGeoffrey send an alarm message the "system"should be "on", the sensor should be "armed" and the sensor should be "on".

    Trigger:
    onshuis/woonkamer/radar

    Constants:
    status_on = 1

    Variables:
    system_on = systemcontrol
    sensor_armed = onshuis/woonkamer/radar_armed
    sensor = onshuis/woonkamer/radar

    Conditions:
    system_on == status_on
    sensor_armed == status_on
    sensor == status_on

    When the "system" widget and the "sensor armed" widget are switched on and the sensor is activated eGeoffrey generates an alarm.

    When one of both widgets is switched OFF, no alarm pops-up.

    When the user has reached this point, it should be easy to adapt the rule to be used in a Macro.

    This two step approach is for me easier to understand when I am trying to find out how it works and to debug the rule.



  • After setting Widget configuration → Control → Widget type to "2" and "save" the widget is larger.

    Correct.

    After that going to "Edit page" the widget can not be edited. The three selections for editing, the moving and deleting do NOT work anymore. The ON/OFF status can be changed.

    For widget type 2 there is a bit of overlapping between the main icon and the three buttons resulting in difficulties to trigger the action. Try moving the mouse on top of the edit button, the icon of the mouse should change shape and then the button should be accessible back again.
    I'm tracking it with https://github.com/egeoffrey/egeoffrey-gui/issues/59 but resolution would be very challenging. As far as you can get those buttons to work, I'll keep it as low priority.

    I tried to use the "value" widget and change colour with "Widget configuration → Value → Value in green if between this range: 0 and Value in red if between this range: 1.

    This has to be a range so try "0-0" and "1-1"

    I would suggest one of three possibilities:

    Let me know about the range which would be my #1 option. Alternative would be to allow customizing the colors of the status widget (https://github.com/egeoffrey/egeoffrey-gui/issues/60)

    After activation of the sensor the elapsed time in the _armed widget is not updated.

    The elapsed from another sensor is something related to the specific widget so you will not see it in the sensor's configuration but in the widget's one. Have a look there. Of course to see something the sensor you are pointing to has to have at least a value set.

    I managed to get the rule working, but like we had once before, the rule could not be edited anymore. Deleted via "advanced manager" and created a new one.

    What is the rule_id of the rule you cannot edit? Wonder if the name has some special character or anything else.

    In my perception a "status" is a state after an action has been performed.
    IMHO in this case the term "control" would be more clear. I created an extra sensor called "systemcontrol".

    You're correct. Sounds way better. And generally speaking the two phases approach is more clear than mine, thanks for the recommendation!

    As for the rule not working, what's the issue specifically? Thanks



  • @user2684 said in My burglary alarm system:

    Let me know about the range which would be my #1 option. Alternative would be to allow customizing the colors of the status widget

    No colour other than the default. No green and no red.

    The elapsed from another sensor is something related to the specific widget so you will not see it in the sensor's configuration but in the widget's one. Have a look there. Of course to see something the sensor you are pointing to has to have at least a value set.

    I did the settings in the widget. It is pointing to the radar sensor. Radar sensor is operational and changing state.
    No sensible elapsed data in widget.



  • @user2684

    I managed to have the system activated by means of the hardware switch on the control box OR by the software system switch. The exact rule I have to think about.

    The next step is to schedule the period the system is active.
    As far as I see it now is that the calendar should facilitate this.

    Some questions do arise:

    How do I grab the trigger caused by the calendar?
    Is it possible to have more triggers next to each other to trigger separate events?

    The aim is:

    The default activation is done by the time schedule.
    Remotely the system can be activated or de-activated by the software system switch in eGeoffrey. The calendar is overruled.

    When I am going to bed early I can activate the system with the button on the control box. The schedule has than no effect on the activation.
    Standard the system is switched off by the calendar.
    When I rise early I de-activate the system with the button on the control box.
    The calendar is then overruled.



  • I did the settings in the widget. It is pointing to the radar sensor. Radar sensor is operational and changing state.
    No sensible elapsed data in widget.

    Oh you're right, widget type 2 has no room for the timestamp, switch to default type if you don't mind.

    How do I grab the trigger caused by the calendar?

    Here's an example on how I used the calendar: https://forum.egeoffrey.com/topic/27/control-your-heater-with-egeoffrey. Bottomline, you create a sensor with format "calendar" which is displayed in a "calendar" widget. Then in the rule you get the value in a variable by using "SCHEDULE <calendar_sensor_id>". This value will be empty if there is nothing scheduled at the current time or the value you set (in the widget you can also set a default value). Based on this your rule can trigger or not. I usually have the rule running every 1 minute or 5 minutes so to be sure to react timely.



  • Today the revised PCB for the alarm system arrived.
    One print will suffice for three functions:

    • with the radar sensor mounted it can detect persons

    • with a switch connected it can control the alarm system

    • with "sound and light" attached to one of the modules one can scare away a possible burglar.

    One single software package with as less intelligence as possible is installed on each module.

    eGeoffrey takes care of the rest



  • @eporocrail I find really interesting how people face the same use case in completely different ways if I look at your approach and my approach for the same. This IHMO gives some value to eGeoffrey philosophy since doesn't oblige you to to things in a specific way but gives you the pieces you can combine in the way you like.
    /end of advertisement 😛



  • @user2684

    I expanded the documentation a little. I aim for simplicity as far as possible:

    Module control

    One software package

    Sensor always active, interrupt driven.
    Switch interrupt driven.
    Switched port activated by MQTT message from eGeoffrey.

    Ad sensor sub-PCB for sensor activity.
    Ad switch for switch control of system activation.
    Ad accessories to module for external alert.

    Sensor and switch do not require system configuration. They are interrupt driven.

    External accessories do not require system configuration because they are activated via MQTT by eGeoffrey. To address an individual module the ID of that module is required. This ID is part of the topic for activating that module.

    The option will be implemented.


Log in to reply