Home Assistant MQTT Alarm Control Panel Integration

Home Assistant is becoming increasingly popular in DIY home automation projects. To help you integrate OHS groups as alarm control panels, I've put together a small guide. The steps are straightforward:

First, you need to access the main configuration file, located at /homeassistant/configuration.yaml. The easiest way to do this is by using the File editor add-on. Go to Settings, then Add-ons, and click on the ADD-ON STORE button at the bottom right. Type "File" in the search bar, and the first add-on to appear should be the File editor. Install it, start it, and set it to start on boot.

Once the File editor is installed, you can access the configuration file at /homeassistant/configuration.yaml. All local files are conveniently accessible from the Folder icon located at the top left. Edit the file and add the following section at the bottom, making sure to maintain proper YAML indentation:

# OHS Alarm
mqtt:
  - alarm_control_panel:
    name: "Alarm Group House"
    supported_features:
      - arm_home
      - arm_away
    payload_arm_away: "arm_away"
    payload_arm_home: "arm_home"
    payload_disarm: "disarm"
    code_arm_required: false
    state_topic: "OHS/group/1/state"
    command_topic: "OHS/set/group/1/state"

This section can be repeated for each group number you have defined in OHS. Simply change the group number in both the state and command topics to match the actual number in OHS, and adjust the alarm panel name as needed.

After editing, save the configuration and then restart Home Assistant. The restart option is conveniently accessible from the editor menu at the top right under the settings icon.

After restarting, the following panel will be added to the main overview. Here, you can directly arm or disarm the OHS group and see its current state.

 

Note: Each time you edit or remove the MQTT configuration, you need to restart Home Assistant and also log off and log on again to clear the web cache.

Alarm State Machine / Group Zones Example

Just to update of gateway configuration page,  I've created a state machine diagram showing arm/disarm cycle.Also here is an example of my own groups (Garage, House) and zones (PIR, reed) setting for ground floor. You can see here how authentication unit is attached to particular zone. Only these zone is then set up with authentication delay. That is, when someone trips these zones there is time allowed for the person to authenticate. All other zones in house group trigger the alarm state immediately. You can read more about it in zone's setting.

 

Updated Radio NodeMini with STM32

Here comes the updated version of Radio Node Mini on STM32f103. There are only a few visual changes, like places for the required pull-up resistors for the I2C bus. I add them automatically when someone orders the optional HTU21D temperature/humidity sensor. Other than that, only silkscreen labels are enhanced. But the most important fact is the change of way I make those boards. 

The chip crisis is fading out and with it all the components are getting cheaper. This brought me to an idea to use fabrication services. And since I'm getting busier and I value my free time even more, I tried to compromise and I let the new nodes be assembled and soldered at the PCB shop. I invested the effort into making a small panel of the boards and created BOM and CPL files for the machine assembly. 

Make it short, the service is great. Actually it allows me to lower the price of the Mini Nodes, simply because it takes me much less time. And not only by saving my labor time, but also the components are priced similarly, or sometimes even cheaper, to my preferred shop TME. There are only a few cosmetic problems with the micro USB ports, or the micro buttons which are not always aligned, but the boards are nicely soldered and even cleaned of the residue flux.

To celebrate this accomplishment, I made a new graphical pin-out diagram for the STM32 Radio Nodes Mini. Take a look:

STM32 Radio Nodes Mini

STM32 Radio Nodes Mini are here and available for sale in my shop and on Tindie.com

I created this board to use it as base for various battery powered sensors I use at, and around my house. It is evolution of my Radio Mini Node based on ATmega328P, but instead of ATmega, it's using STM32F103 (basically well known BluePill). It suited for RFM69HCW(CW) or various LoRa RFM9X(RFM95/96) modules. It can have an u.UL connector for pigtail, or it has a solder pin for simple wire antenna. It comes with micro USB charging for 3.7V Li-ion cells with capacity ranging from 500mAh to 2000mAh. Quite good are 102050 (1000mAh) or 102550 (1500mAh) with JST-PH2.0 connector, that are almost matching the size of this board. It also includes battery voltage measurement connected to MCU analog pin. USB port can be used for programming, or as serial port. It has also standard ST-LINK SWD port. There are RESET and BOOT0 push buttons for convenience. Then there is also external RTC quartz crystal which allows indefinite sleeps instead of ATmegas maximum 8 seconds. It has LED on PC13. Also on top, there's a place to mount various temperature/humidity sensors like HTU21D. PCB comes with mounting holes to fit in various places.

Specification is as follows, it's STM32Duino BluePill compatible board with STM32F103C8:

• Size 24 x 49 mm (0.95 x 1.92 in)
• STM32F103C8 - FLASH 64KB, SRAM 20KB, Max. 72MHz @ 3V3.
• 8MHz main crystal, RTC 32.678kHz crystal.
• USB charging designed for 3.7 Li-Ion battery (500 - 2000mAh). Great thermal dissipation.
• Included, but not soldered, JST PH2.0 battery connector.
• Charging state (Hi-Z) available on pin PA8 via NO(Normally Open) PCB jumper.
• Voltage measurement on PB1 pin via 2:1 voltage divider, consuming 2,1uA @ 4.2V.
• LED on PC13, with NC(Normally Closed) PCB jumper.
• ST-LINK SWD 4-pin connector (3V3, SWDIO, SWCLK, GND).
• RESET and BOOT 0 push buttons. BOOT 1 (PB2) pulled-up by 100k resistor.
• SPI1 routed to RFM69/RFM9X modules. PA4(CS), PA5(SCK), PA6(MISO), PA7(MOSI)
• NO PCB jumper for Radio Reset routed to PB11.
• NC PCB jumper for Radio Interrupt(DIO0) routed to PA3
• PCB footprint for HTU2XD, SHT2X, SI70XX humidity/temperature sensor routed to I2C.
• Optional HTU21D humidity and temperature sensor.
• RFM69HCW 868Mhz as soldered on option.
• Optional u.FL antenna connector.
• Optional high quality 20cm u.FL to SMA pigtail.
• Optional rubber SMA 868/915MHz antenna.

The consumption of the board alone is around 60uA while MCU is in deep sleep, when clocked at default 72MHz. With soldered on RFM69HCW radio module and temperature/humidity HTU21D, the consumption raises to around 120uA while sleeping. This is about the same as a normal Li-Ion 1500mAh self-discharge current. It is enough to keep the node sending packet every 10 minutes for many months with a 1000mAh battery.

New Radio Mini Node

There was a little happening on development side of OHS lately. The gateway line 2.0.x
works very stable. No issues found in software or hardware. Arduino based nodes are also reliable. Basically it works as intended, "install and forget". 

But the word is changing and so are the evolution of chips. ATmegas, and also other components are becoming hard to get, and the prices of ATmega tripled. While using STM32 Cortex M4 chips for gateway, I realised they are great replacements, allowing us to do stuff not imaginable on AVR. For example STM32duino, I've been watching the progress of it for long time, and also, I have some blue/black pills on hand. So I decided to give them a try also on OHS environment. I've created a STM32 Radio Node Mini, which render is shown on picture. 

It is 50*24mm board with STM32F103C6T6 Cortex M3 running up to 72MHz with 64KB of flash and 20KB SRAM. Basically well known bluepill. It's meant to be used as radio node, so on back there is place to mount RFM69 or LoRa RFM95/96 module. It has a u.UL connector or place for wire antenna. Board has also 3.7V Li-ion battery charger, and battery measurement resistor divider connected to MCU ADC pin. It is programmable directly via USB port, or it has SWD. There is also RTC quartz crystal which allows indefinite sleeps instead of ATmegas maximum 8 seconds. It has LED on PC13, and also on top a place to mount various temperature/humidity sensors like HTU21D. PCB comes with mounting holes to fit in various places.

Currently I'm having those fabricated, and as soon as I have some of them tested and I'm ready with proper software, I will report more.

Gateway 2.0.4 pinout

Just short update, using nice tool called pinion with few hiccups,  I've created quite nice diagram for pin-out of OHS gateway 2.0.4.

https://vysocan.github.io/OHS_20x.html

It offers nice visuals with highlighting of pins and grouping by type. It has to be hosted out of blogger, as blogger does not allow embedding your own CSS, JS and pages easily.

Authentication added.

New firmware version 1.3.9 has been just released. It includes few minor improvements, and as main new feature an authentication, that was added to web interface.  How it works is pictured on right side. Every new client connection is asked for user and password that must match with internal values. Default user is: admin, and default password is: pass. Both then can be changed in Settings.

At first I was thinking to use obsolete HTTP basic authentication, to make it simple. But it is very obsolete, and also not supported by vanilla HTTPD from lwip contrib package. I was thinking how to add an authentication for a longer time. There are several methods to be used. First would be creating a single page application with authentication message encrypted in URL as parameters. Witch would require a bigger re-work on the HTML page generation. Now HTTPD has several pages, on which user can set tens of options for each section on a page. Quite a difficult task.  Second, to use a cookie to store some secret after user authenticate successfully on browser side, and request the browser to send this secret with each request. But lwip's HTTPD does not support cookies. 

Well I deiced for second option. I created a simple patch to HTTPD  to handle cookie generation and reception. First is done as part of dynamic header option for pages that are not statically liked, that is not generated via makefsdata program. Then, I added an additional callback, that is preceding request for every fs_open (file system open function). This allows an application to verify received cookie and then, if needed, rewrite the page( or file) requested to something else, for example login page.

I think it is nice and neat addition to lwip's HTTPD, so I will try to push it upstream, hoping it will get accepted.

New pre-compiled version is as always available GitHub, together with all sources. Enjoy!

P.S. Finally this is new version for my "production" home gateway. Resetting it after 163 days. Quite satisfied 💪