Remote unit demo

I have shot a short video that show how the authentication works on the remote unit. As you can see there is red and green LED in the probe that helps to show current state, and piezo that is mounted inside. Slow green flashes without sound means that group/zone is disarmed. After touching the probe with a valid iButton, the group is being set to arm state with the configurable delay, as shown red flashes with sound. When the delay passes it switches to arm state, slow red flashes without sound. Then tripping a zone, here opening front door, shows another state awaiting authorization. The delay of wait state is configurable in 3 to 0 times of authentication delay time, which is configurable in seconds as well. Every such wait state is represented by faster LED flashes and also faster sound.

As you can see in the video I have the unit mounted next to switches, directly in the wall. I found it very fast and easy to arm/disarm the group. My 5 year old daughter still finds it funny after 3 months of use and she ask for my keys to do it.

GSM and uptime

Just today, I have accidentally discovered that the GSM service provider had
some problems with his network. Luckily the thread that check GSM status handled the network failure just well, and recovered from it without issues.

I have the system up and running for 96 days with all threads working. I
must say the NilRTOS is really robust.I'm planning some software updates, but I have to create remote ISP first.


Also recently I have got W5500 chip and Wiz550IO and I'm very tempted to create a new mainboard together with SIM900. This would be all included alarm board that can simply replace old alarms and offer many features with open firmware and hardware.

Web interface - home

Here on the right side is the home page of my security screen. There is not to much to set in terms of system functionality. There is system time, which is NTP synchronized on startup or whenever you hit the "Get NTP time" button (Connection to Internet is needed :). There are also information about the last system start up time and calculated uptime. Then information about power supply and battery state. Another section is about radio and GSM module statuses. Rather self-explaining I guess.

More important are the last three buttons. Starting from "Reset to default" that will wipe all configuration that is kept in the system RAM and replace it with "factory default". You would do it only in case you really want to start from beginning. The "factory default" must be confirmed by pressing any "Save all" button, so the changes are just loaded into RAM but not stored into EEPROM. You can go and take the last stored configuration in EEPROM by "Load last" button. "Load last" can also be used when you change temporarily any configuration in RAM for test cases. Just remember that in case of power loss the system stores current configuration form RAM to EEPROM just before the main backup battery is depleted.

Test run - stability

I've been a little busy at work and with family recently. This led into an unintended testing period of the software and hardware. I'm happy to say that the system is working now for 25 day without any problems. Groups, zones, sensors are doing what they should. The communication with wired and wireless modules is working. GSM modem is sending SMS, LAN is responding and sending data through MQTT. All is just working. Big success for me!

This brings me to an idea, does anyone want to have PCB for this project? Let me know, I have some spare ones, and will send them to you for 6-8 EUR (10$), depending on your location.

Web interface - log

One of the important pages provided by the embedded web server is a log. It translates various system messages to meaningful text(at least for me :). The table is showing 20 entries at once and you can list through them by buttons << and >>. Button "now" will take you to the most recent message. As you can see on the left, there is numeric id of the message, time stamp, the message text and status of the SMS function. Above the table is a button to clear all the log table, but it takes a while.

Physically the log is located in 512kb I2C controlled EEPROM, and the logging mechanism using 16 bytes for every event. This makes together maximum number of 4096 log messages stored. Any call to log message  function pushes the message to FIFO along with actual time stamp. Then there is a logger thread that takes care about the EEPROM circular buffer, and also about the SMS. Every message can be send as SMS to appropriate group of people.

The message itself looks like this:

150218104158;SCW

As you can deduce the "15 02 18" is date, "10 41 45" is time, next is the status of SMS function:

• "." requested, failed
• "," not requested, failed
• ";" not requested, acknowledged
• "|" not connected
• ":" sent

And last 3 characters is the message itself, well not actually, but it is its acronym or code. SCW is "System configuration saved, by pressing button on web interface". All these are decoded by web server and SMS function. You can look for more in code.

Logger thread also pushes all messages into following MQTT topics:

OHS/Log 150218104158;SCW

I'm planning to create on/off button for MQTT push.

Web interface - sensors

Sensor configuration page has a lot similar with authentication units. Sensor can be connected by wire(RS485) or wireless(RFM12B). It is shown in the address field. "W" stands for wired and "R" for Radio. Units in range 1-14 are wired and 17-143 are connected wireless. Currently the firmware recognize following types:

• Temperature
• Humidity
• Pressure

The type and address is coded in the registration message in the sensor firmware. Other values can be configured and are stored in unit in chip EEPROM. As you can see above you can turn the sensor On or Off. Also you can allow the sensor value to be propagated to MQTT. The default path is "OHS/Group_name/Sensor/Sensor_Type/Sensor_local_address". Example looks like this:

OHS/Zahrada/Sensor/Temperature/0  23.00
OHS/Zahrada/Sensor/Humidity/0  53.00
OHS/Zahrada/Sensor/Temperature/1  24.04
OHS/Zahrada/Sensor/Pressure/0 998.38
OHS/Dilna/Sensor/Temperature/0   9.48
OHS/Domek/Sensor/Temperature/0  13.02
OHS/Garaz/Sensor/Temperature/0  12.06

Last setting is the group name the sensor belongs to.

Sensors are dynamically added when they first join the network. The Sensor type can be chosen to any possible, as long as its value can be stored i a float variable. Main unit does not care about the sensors at all, it doesn't do any computation with it values, and also it does not verify the content. Main purpose is to act as a gateway for MQTT to NodeRed or similar tool. Only value that indicate the health of the sensor is time-stamp called last OK, that indicates delivery time of last message from sensor.

Sensors are defined in the code by following struct:

  uint8_t address;
  char    type;
  uint8_t number;
//          |- MQTT publish
//          ||- Free    
//          |||- Free
//          |||||||- Group number
//          |||||||- 0 .. 15
//          |||||||- 
//          |||||||- 
//          ||||||||-  Enabled   
//          00000000
  uint8_t setting;
  float   value;
  systime_t last_OK = 0;

In the future, the parameters for sensors, and also for authentication units, will extend as they will be battery monitored. I would like main board to take care of the sensors battery life in form of some flag and also sms.

RS485 protocol

Last post reminded me to write about library I have created for the wired network. It is called simply LibRS485, or NilRS485 adopted to work in NilRTOS. The library defines packet protocols on RS485 drivers. I use ST3485EB a 3.3 V powered, 15 kV ESD protected and up to 12 Mbps RS-485 half duplex transceiver. Inexpensive SO8 chip that has all that is needed already inside. As it is half duplex we need one extra pin to tell the transceiver if we are receiving or transmitting. The transmission itself require one twisted pair of wire and is able to push the data to distances over 1km with reasonable speed. The nice thing about RS485 it uses a differential balanced line and resists electromagnetic interference from motors and other equipment, more can be found on wiki.

LibRS485 uses a 9bit protocol and Multi-processor Communication mode defined in ATmega. This allows the MCU to do other thing without looking on communication unless there is a address frame. Basically i work like this:

1. All nodes are in Multi-processor Communication mode (MPCM)
2. One of the node sends an address frame, and all receive and read this frame.
3. All nodes reads the address frame and determine if it has been selected. If so, it clears the MPCM, otherwise it waits for the next address frame and
   keeps the MPCM setting.
4. The addressed node will receive all data frames until a new address frame is received.
5. The other nodes which still have the MPCM bit set, will ignore the data frames.
6. When the last data frame is received by the addressed node, the addressed MCU sets the MPCM and waits for a new address frame. The process then
   repeats from 2.

Library also defines a packet structure like this:

 -------------~~~~~~~~~~~~~~~~~~~~~~
 - A - P - X -  D0 - D63 ~ S0 ~ S1 ~
 -------------~~~~~~~~~~~~~~~~~~~~~~
  
  - Required fields
  ~ Data and signature fields
  A Address - 4 bits form and 4 bits to address.
    0  is master, but not really as any node can drive communication
    15 is broadcast to all
    14 addresses left for other devices
  
  P Packet definition - 2 bits type and 6 bits length.
    Flag bit configuration:
    FLAG_ACK 3
    FLAG_NAK 2
    FLAG_CMD 1
    FLAG_DTA 0
     
    Types: CMD - Command - user defined general commands value 0 - 63
           DTA - Data - user data length D0 - D63 and CRC S0, S1
           ACK, NAK - flags for data, using signature of data packet
           
  X XOR of A and P, for basic transfer safety.
  
  D0 - D63 user data.     
                       
  S0 ~ S0  CRC for user data or signature for ACK, NAK.   

So basically there are two types of packets. Command packet that has only 3 bytes (APX) and deliver a command(number 0-63) to node(s). It is used for example to issue a call for registration. Or data packet  that has 6-69 bytes (APX D0~D63 S0S1). This deliver any data to node(s). The nodes are addressed by its address 0-14, which select any individual node. Or address 15 that is broadcast to all nodes.