PURPOSES OF PROJET:
SOFTWARE COMPONENTS USED:
PHYSICAL DEVICES USED:
PROJET MOST INDICATED FOR:
Notes and disclaimer
|revision projet: 1.0|
Before we start, some important clarification.
To manage to to domotize a plant traditional security, burglar-proof, alarm or what you want to call (maybe already present in the environment and not equipped with any computer interface) rappperhaps resists the Holy Grail of personal home automation. We need to agree also on the definition: what does it mean domotizzarlo? Obtain the home automation control of the single elements that compose it (sensors, control units, sirens, logic)? Being able to arm him and disarm him? Do you know the instant status, the anomalies? To be notified in case of intrusion or other states?
A single answer simply does not exist. The theme of alarm systems - beyond home automation - is so vast and nuanced to deserve dozens of pages dedicated to it; this projet inDomus prosets a reading key among the many possible, suggests solutions to achieve the maximum with minimum effort, both technical and economic. It does not claim to be THE solution: it offers hints, triggers thought, leads - hopefully - to the averagenamecompared to how to solve, at home profirst, the question.
Another necessary clarification: in principle some concepts expressed in this procastings are to be considered, for the average user, quite complex. Before addressing it, therefore, the user is sure to master concepts such as theMQTT, clean contact in home automation, the functionnamein principle of Node-RED.
The purpose of the present projet is therefore to make it possible rigging, disarmament and priming of a traditional alarm system means personal home automation. As we will see, we will use different techniques previously illustrated to assemble a single one profunctional casting.
|Nb This procast articulates in two parts: the first one (this one), dedicated to the steps in common regardless ofHUB implemented for the proman personal home automation; the second (published later) illustrates how to configure the proprio personale HUB to check what was done in the first part (an article for each HUB).|
- Identify the contacts to act on
- Select and certify the actuators on the contacts
- Configure inching
- Assemble a wall box
- Define with Node-RED a virtual MQTT device
- Integrate the virtual device into home automation
- Home Assistant
The thing that makes it difficult to describe a projet of this type is in promerges differences that exist among the various alarm systems in the world.
Despite these great differences, there are certainly common minimum denominators, such as:
- they serve to identify a break-in;
- they can be armed / unarmed;
- trigger a siren when they go into alarm.
What prowe will put in this projet is to use the native control elements of the burglar alarm to succeed, through other elements (of the actuators), a make it home automation, in the sense of being able to at least control its rigging, disarmament and priming. Compared to the state, we will do a reasonnamein its own right.
The first thing to do is to observe the profirst alarm system - possibly manual to the hand - and then ask: "how to arm / disarm? '
The answers are usually:
- means RFID tag;
- via numeric keypad;
- by coded remote control.
While in the first two cases the question becomes more complicated, the presence of a coded remote control - perhaps with more buttons (one by function) - opens to easy domotization (below we will see why). Some market solutions are "modular" (see for example solutions Diagral, to quote a random brand), therefore even not having a remote control it is sometimes possible to consider purchasing one ad hoc for the purpose of domotizing the system. Everything depends on the brand and the type of anti-theft system available.
Some alarms - usually the most advanced - have "complex" control units which they have at prointernal of one or more terminal blocks on which the various alarm components (sensors, sirens, etc.) are connected. Some contacts, sometimes, rappresentano "clean contacts”Useful maybe probeforearmo / disarm / alarm triggering - which, like the presence of a remote control, opens up for easy domotization.
The idea of this projet, therefore, is to use of the home automation actuators with clean contact (a few tens of euros) attesting to them profirst of all on those electronic contacts offered by the alarm system itself (on the remote control or on the control unit).
To summarize, these home automation actuators allow to open / close the contacts on which they are attested; if this is done on the two contacts relative to the button of a remote control, this action "simulates" the pressure of the human finger on the remote control button. Similarly, by attesting a home automation actuator on the contacts of a control unit that allows this type of control, the result will be that of controlling the function foreseen by the control unit via home automation.
We will therefore face the only example of the remote control as perfectly loanable, with the same concepts, to a possible control unit equipped with clean contacts dedicated to arming / disarming and / or priming of the system.
|Nb It is vital to understand how the present projet leave to the alarm system the burden of management, complete, of the mechanisms, the logics and the detection systems. Basically the alarm will continue to do the profirst job: what we will do will be to equip ourselves with the possibility of arming it, disarming it and triggering it from our personal domotics (which opens up a whole series of automation scenarios not just - which will motivate, as we will see, the company).|
The steps we are going to take will be the following:
- identify contacts on which to act;
- choose and certify the actuators on the contacts;
- assemble a wall box;
- configuration the inching;
- define, through Node-RED, an virtual MQTT device that rappthe alarm system controlled by the actuators is present.
Identify the contacts
So let's assume we have it available a control remote control alarm with at least two basic buttons (functions), ie armo and disarmament and, possibly, a third (key panic, which if triggered triggers the alarm).
We will therefore assume that:
- 1 button: rig
- 2 button: disarm
- 3 button: panic mode (forced alarm trigger).
What we will have to do will be certify three clean contact actuators on the same number of buttons. By doing this the act of activating an actuator would cause the closure of the contacts of the relative button on which it has been certified, Thus "simulating" pressing the button on the remote control and then commanding the relative function.
Similarly, what we describe would also work with actuators certified on the contact pairs on the terminal block of one any control unit dedicated to checking the above features. Obviously the documentation of the alarm system will be of great help in this.
Select and certify the actuators on the contacts
This is the crucial phase - and perhaps the most complicated one - which plans to attest the outputs of several clean contact actuators on contacts you want to check, in this case those of the buttons of a remote control or on the terminal board of the control unit.
Yup, but which actuators should we use?
The requirement for the "type" actuator to be attested on a contact to be checked is the following:
- it must be a home automation actuator that provides MQTT support;
- must be provided with clean contact.
To give examples, they are valid:
- ITEAD Sonoff Basic (that was it modified with clean contact): simple actuator, single channel;
- ITEAD Sonoff dual (that was it modified with clean contact): dual channel actuator;
- ITEAD Sonoff 4Ch PRO: four-channel actuator natively equipped with four clean contact channels.
Nb Whatever the choice, all three are intended riprogrammed with firmware Tasmota (or analogues - to ensure they are equipped with proMQTT tocollo. Who an ap is availableproelucidation). No one forbids using Sonoff Basic and / or Sonoff Dual: but we recommend using the Sonoff 4Ch PRO for the simple fact that it is equipped with a factory of four clean-contact channels and therefore does not need hardware modifications to operate in this mode.
For this procast we will choose to use a Sonoff 4Ch Pro:
As explained in the abstract, this projet is, de facto, the whole di più procastings and techniques: this is why at this point in the projet we will make a detour to the prodomotization jet of a remote control via clean contact, ie the following link:
|Nb Tale deviation It is not of interest to anyone wishing to control the clean contacts on the terminal board of a control unit, but a reading is still recommended, given that conceptually it is the same logic of functionnamento.|
In order for everything to work properly it is necessary to configure the inching - or the effect "button". Actuators (or single channels of a multichannel), in fact, when activated prothey close the contact clean and ... leave it that way: closed.
A button on a remote control instead works differently: press it (closes) for about a tenth of a second to send the radio command and then release it (open).
In order for an actuator with firmware to be activated Tasmota close the contact to reopen it immediately afterwards, you must use the PULSETIME command. This command allows you to configure the actuator proin this mode.
How to configure this command is explained in detail in this guide dedicated.
Well: we have pronoted the actuators (or the individual channels of a multi-channel actuator such as the Sonoff 4Ch PRO, or the Dual) on the various buttons to be controlled and we have configured the inching. At this point, by activating the various actuator channels (or the various actuators) the remote control will react as if it were materially pressed by a human being, in fact domotizzando the functions of armo, disarmament and triggering of the traditional alarm.
At this point the advice is of close everything in a wall box, hide it somewhere appropriate of the house and, fundamentally, forget about the "physical" aspect of this projet. All you need to do is replace the batteries with the remote control from time to time.
At this point we will have on our network Wi-Fi private three MQTT topics to whom to send an ignition payload, which will correspond to the simulated "pressure" of a key on the remote control, and therefore to the execution of the function connected to it.
Let's assume that i the coupled function / command are the following:
|Function||MQTT command (hypothetical for Sonoff 4Ch PRO)|
|ARMO (1 Button)||cmnd /Sonoff/ POWER1 ON|
|DISARM (2 Button)||cmnd /Sonoff/ POWER2 ON|
|PANIC TRIM (3 Button)||cmnd /Sonoff/ POWER3 ON|
Notice how, given that we are assuming the use of a Sonoff 4Ch PRO with firmware Tasmota, the name of the actuator wired in the MQTT topic is always the same ("Sonoff"): To change is the topic suffix"POWER“, Which is numbered according to the actuator channel.
In case we had used three Sonoff Basic, proprobably a scenario would have arisen as follows:
|Function||MQTT command (hypothetical for Sonoff Basic x3)|
|ARMO (1 Button)||cmnd /Sonoff1 / POWER ON|
|DISARM (2 Button)||cmnd /Sonoff2 / POWER ON|
|PANIC TRIM (3 Button)||cmnd /Sonoff3 / POWER ON|
The name of the actuator would change ("SonoffX"), While the channel (single) would not have been indicated as a suffix to the command"POWER"
That said, in both cases the prothe problem is always the same: instead of having a single command topic useful, based on its payload, to arm, disarm and / or trigger the alarm, we have it three different with payload always the same ("ON"). This it is not positive, as i personal HUBthis logic is not designed to understand it: to drive an MQTT element they need MQTT topic unique.
To solve it comes to help Node-RED.
Let us assume that we aspire to have a single MQTT command topic so defined:
|Armo||cmnd / Alarm||armed_away|
This means we could send an armo command "cmnd / armed_away alarm"One of disarmament"cmnd / alarm disarmed"And one of trigger (panic)"cmnd / Alarm triggered"
The entity "Alarm"We can create it virtualizing everything through flows to and from Node-RED which "convert" the individual commands to and from the various actuators into a single "virtual" MQTT topic ("cmnd / Alarm“).
Also the telemetry (MQTT topic containing an operational status sent cyclically) are no exception. It will indeed be necessary to create, starting from telemetry naturally received by the various actuators (or from the multi-channel), a single "virtual" telemetric topic useful forpersonale HUB that we use to understand the operating status (return from a command) of the system.
|MQTT telemetry (hypothetical for Sonoff Basic x3)||Corresponding virtual telemetry|
|stat /Sonoff1 / POWER ON||stat / alarm armed_away|
|stat /Sonoff2 / POWER ON||stat / alarm disarmed|
|stat /Sonoff3 / POWER ON||stat / Alarm triggered|
|Nb Obviously this solution does not provideHUB the actual status of armo / disarm / alarm triggering, but only the MQTT response of the actuator that has supposedly (therefore in optimistic mode) proknown to engage the function. To obtain the actual status it is necessary to strive even more - but here we enter a bush given by the very nature of the alarm - which varies from solution to solution. Who of us has written this procast, for example, deduces the state of armo / disarmament of prosystem by means of a relay connected natively to the control unit by the alarm which closes i profirst contacts when the plant is armed. This closure of the contacts is read by a home automation sensor which returns this state to home automation based on Home Assistant through a flow Node-RED as explained above.|
Any traditional alarm makes history to itself: let's say that for these types of systems, being able to obtain rigging, disarmament and triggering via home automation is in itself an excellent result.
To achieve these two "virtual" topics we deviate from projet to land on another, who explains exactly what is the logic of how much appena described and how to implement it with Node-RED.
In conclusion of this first part, we were able to:
- appof actuators to contacts in order to to domotize the functionnamealarm alarm;
- define a virtual MQTT entity.
At this point we are proto integrate this "virtual MQTT alarm" on our HUB personnel. Since i HUB treat these objects in different ways, we decided to write different guides for each of them.
As we also explained on the "Overview: alarm systems, home automation and Home Assistant", Home Assistant it's a personale HUB that allows you to manage the main functions of an alarm system that can be integrated into it.
Among the various possibilities for the integration of an alarm system, the present projet channels to the adoption of the "MQTT Alarm Control Panel" component, which allows appto the integration of a controllable alarm system via protocollo MQTT - that is one like the one that, virtualizing it, we realized in this first part of projet.
The second part, that appdedicated to integration at Home Assistant, is available here.
Also Homebridge, as Home Assistant, is a good candidate for the integration of an MQTT alarm system, which enables the control and management of the alarm system via Appthe HomeKits.
The guide to this personale HUB is available here.