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.



  • @user2684

    Where my weather station is on-line now I resumed work on this project.

    Is it possible that processing a rule is delayed/influenced by a lot of sensor activity of the weather station?



  • @user2684

    Every now and than there is no result at all of the rule

    alarm_rule.jpg

    No suppression set



  • @eporocrail said in My burglary alarm system:

    Is it possible that processing a rule is delayed/influenced by a lot of sensor activity of the weather station?

    Should not be the case. Every eGeoffrey component runs in parallel, even different processes, this was one of the main themes during the initial development.
    Try enabling debug in controller/alerter to see if the rule evaluation is not even starting or just not triggering



  • @user2684

    I am working on scheduling the arming of the system.
    When creating the constant "is_null" in your heater howto the right field is left empty if I understand correctly.

    isnull.jpg

    In my case eGeoffrey does not allow the right field to be left empty.

    Your advice please.



  • @user2684

    I tried to set a period of 15 minutes during every day.
    It was not saved.

    Log message:
    Schedule.jpg



  • I noticed that when an alert message is sent by the radar sensor module the alert arrives in eGeoffrey but the rule to process this alert is not always leading to the alarm becoming red. I have the suspicion this has something to do with eGeoffrey being busy processing other incoming messages.

    The following approach was taken to solve this issue:
    When the radar sensor is triggered, the output goes high. After 2 seconds (±) the output is going low.
    The module sends an alert message to eGeoffrey during the time the output is high. The value is alternating 5 times per second "0" and "1".

    This results in a series of ON/OFF alerts is entering eGeoffrey when the radar sensor is triggered. During testing after a trigger a rapid change of colour of the alert was visible. It turned out that the alert was converted in an alarm not always on the first alert. But because of a series of alerts coming in I did not see that an alert was missed.

    I am now at the stage that the sensor module is as dumb as possible. Next to a heartbeat message every 20 secs it sends a series of alternating messages when the sensor is triggered during ± 2 seconds. The data processing is done completely by eGeoffrey.

    The last steps will be to have the arming done based on the schedule. Next to that I aim to have the Shelly button1 to arm and disarm the system and silence the siren. When that works the system is ready as far as software and eGeoffrey are concerned.



  • @eporocrail said in My burglary alarm system:

    When creating the constant "is_null" in your heater howto the right field is left empty if I understand correctly.

    Nice finding, fixed now in v1.3-11

    I tried to set a period of 15 minutes during every day.

    The error message tells me you are trying to store the content of a calendar sensor in a sensor with a wrong format. Can you please share the entire rule or what is causing that error?

    When the radar sensor is triggered, the output goes high. After 2 seconds (±) the output is going low.

    I wonder if this has something to with a controller/hub configuration called "duplicates_tolerance" which prevents to save a new value if it is the same of the latest and is coming in before "duplicates_tolerance" seconds (this to prevent remote radio devices which usually transmit the same measure multiple times to trigger rules multiple times). New values are what realtime rules relies on. I'd recommend to cross check with the logs: controller/hub tells you something is received and saved, controller/alerter when a rule triggers (and if debug is enabled when runs but not triggers).
    The system busy in processing incoming messages still does not sound to me a probable scenario.



  • @user2684

    What I describe of the radar sensor is the physical sensor in my surveillance module. It is not the eGeoffrey sensor.

    What I am trying to solve here is the fact that I observed that when an alert arrives not always the alarm is set by the rule. Mostly it is. But the system needs to be reliable and is not allowed to miss any alert.

    I am using the fact that the radar sensor goes high on activation, stays high for ± 2 seconds and than goes low again. During this high period I have the module sent alternating "0" and "1" messages. I have set the rate such that eGeoffrey does handle the incoming alerts. Mostly on the first incoming "1" the rule sets the alarm. But every now and than it needs more incoming "1" messages to have the rule set the alarm. (the alarm is a sensor triggered by the rule. I have to reset it manually. I did this to have always visible which alert triggered it's related alarm).



  • @user2684
    As far as the schedule is concerned, the problem is solved. I had not selected "calendar" as format for the sensor.

    Thanks for the tip.



  • @user2684

    I set the duplicate tolerance from 3 to 2. This seems to give a better response. Rule sets alarm at first incoming sensor message as far as I can see now.


Log in to reply