Updates in 1.7.6.3

New minor release is ready with following changes:

• Full support for remote radio Authentication node including rather big change in RFM69 thread.
• Update of WebUI, added JavaScript to Trigger menu to better show meaning of Pass option.
• Update of WebUI, on Triggers and Timers overview. Many of the columns that are blocked via option, that is, they are now shown as blank instead of default for clarity.
• Updated DigitalIO library most recent one and relevant OHS code.
• Updated Ethernet library to most recent version (Now even newer Ethernet library available, need to do it again). 
• Updated GSM library, there are some enhancements in parser.
• Fixes in counting radio packets and other counters (++i vs. i++).
• Few minor bugs fixed in WebUI. 

Authentication unit over radio

Recently new user of OHS gateway has explored a slightly new way how use authentication units. That is normally until now, the authentication units are desired to be online when main unit is online. This was easily achieved when they were wired nodes with RS485 wired connection. The power and data were going to node over 4 wires, like in any industrial RS485 application. Same 4, or more, wires are usually installed in your house for old authentication units. And it is easy to use them switching old unit to new one.

But what to do in case you have no wires in walls and you want try it without too much construction work. Well, then use the radio as for sensors, right!.

For this reason there is new code example on GitHub. The code is build on RFM69 example, but adds parts of wired node where iButton, LEDs and speaker is used to complete a basic authentication node. I have tested it and it woks quite well without any issue. There were some changes needed in the gateway code, and I will soon post them to GitHub as version 1.7.6.3, along with other tweaks.

Of course there are some drawback over wired connection. It is recommended to have some battery backup for the node as well. That is use the USB node with charging and place a decent 1000mAh, or better bigger, battery. Still it can happen that the gateway is powered from it main 12V supply, and the authentication node battery is depleted and dies. In this case, when you arrive at home at this exact moment, you will not be able to disarm standard way, and you will face system alarm. It is probably not a security concern, but you'll annoy your neighbors a bit until you run to your gateway and turn it off. Thankfully there are two possible solutions. There is possibility to disarm over web interface, but unless you have battery backuped home network, you probably will not be able to do so. But, you can always disarm group over SMS command, this should work as GSM module is in the gateway.

Second problem can be radio connection. As for any sensor, the radio authentication can be out of reach of the gateway. While it is unlikely in normal house, you have to think about having at least RSSI of -75, so you are guaranteed to have room to some unexpected radio noise. It can be easily checked in web interface debug tab, incoming RSSI is reported on any received node packet.

Also, one have to keep the unit powered all the time from at least 500mA USB charger, some older cellular charger perhaps. As the node is not entering any sleep state, nor suspending the radio module, and consuming 20-40mA of power. It cannot be asleep, as it needs listen to receive all radio updates. Rest of power to 500mA is to charge the battery after power failure.

Still I think these small disadvantages can be accepted as trade off for fast deployment.

Radio node mini

There is now new basic sketch on GitHub that can be used as basis for integration of mini node to OHS. It registers 3 sensors, that is: battery voltage, TX power level and charging state. Sketch can be uploaded using Arduino IDE and selecting Arduino Pro Mini board, be careful to select proper crystal speed(16 or 8MHz) when uploading the sketch. Voltage selection in menu of Arduino IDE can be ignored as board works always with 3V3.

Just now I realized the board size is pretty close to standard SD card.

Also I will be mostly using simple wire antenna with this small boards. Here are length of wire that can be soldered directly to RFM69 pad:

433 1/4 wave = 164.7mm
433 1/2 wave = 329.4mm
433 full wave = 692.7mm

868 1/4 wave = 82.2mm
868 1/2 wave = 164.3mm
868 full wave = 345.5mm

915 1/4 wave = 77.9mm
915 1/2 wave = 155.9mm
915 full wave = 327.8mm

I personally use 868 modules and 1/4 wave length antennas.

Updates in 1.7.6.2

Here is list of updates in current release:

• Fixed bug of log queue being full, when alert queue become full. When alert queue is filled with slow alerts, it issues a log entry. But the log processing did not free log queue if there was alert requested for queue overflow. Now gateway ignore alerts about alert queue full, and log queue correctly free its FIFO.
• Added disarm button to group tab. This has various purposes, especially for groups that are taking care about smoke and flood detectors. 
• Changed main_board.cpp into main_board.ino to better suite the Arduino IDE.
• Moved and compiled from Arduino 1.6.9 to latest 1.8.5.

Arduino IDE upgrade

I have just updated instruction in Compiling section on right. This include complete setup of latest Arduino IDE and its environment to compile your own version of gateway firmware.

The move from 1.6.9 to 1.8.5 resulted to around 3KB smaller flash size, but on the other hand increased around 100B in RAM size. RAM size increase might be just result of different calculation of unused stack above NilRTOS environment.

New wireless mini node

Lately I have stared to play even more with various remote sensors wirelessly
connected to OHS gateway. I have used my standard radio nodes, but its versatility is somehow to much for small wireless node. To save space and gain easier access to pins of MCU I have designed new node called Radio Node Mini. It resembles Arduino Pro Mini with ATmega328P, but it has place to mount RFM69 board on it. It also has micro USB connector for charging designed for 3.7 Li-Po or Li-On battery.

It is breadboard friendly and measures only 24.4 x 32.8mm (0.96 x 1.29 in). All available pins are taken out to board sides and marked as on Arduino board. It is 3V3 board and it is available with 16Mhz or 8Mhz quartz oscillator. As it is made to work with Li-Po or Li-On battery it features battery voltage measurement on A6 via 2:1 voltage divider, and also ability to detect charging state connected to pin D8. Pin D2 is not taken out as it will be used as interrupt pin for RFM69. It has also possibility to assign pin D4 as reset for the RFM69 via solder jumper labeled RR. Board is programmable via FTDI programmer. Note, that it is not able to take power from micro USB without battery, the charger is providing only minimal current to the board when it does not detect the battery. However FTDI programmer can be used also as power source while developing.

Board has excellent standby battery consumption within few uA when MCU and radio is asleep. It will last for months to year(s) depending on battery size and sleep conditions. Board is able to handle 500-2000mA battery. I especially like those flat 700-800mAh small quadrocopter batteries found on eBay. they are cheap, has similar size as the board, and have also protection circuit built in. Only drawback is that they have usually 100-150mAh less capacity then advertised.

Boards are also now available in my store for 7EUR fully assembled. As option you can choose radio module, pigtail and antenna.

Updates in 1.7.6.1

Here is list of updates in current release:

• Added authentication (iButton key) handling into radio thread. That is, now both wired and wireless nodes are able to send arm/disarm keys to gateway. Keep in mind, that battery powered node is not a good option as authentication will not wait for you to recharge node battery :)
• Removed Ethernet driver restart when MQTT server is not reachable, now only MQTT part is restarted. Will see how it goes in long time, if web interface will recover after network failure/power off.
• Web interface for GSM modem is changed and simplified. Now there is also GSM model info included.
• Startup sequence for GSM is prolonged and changed to comply with SIM800C start-up times.
• SMS handling is changed to accommodate both SIM800 and SIM900.
• Logger and alert thread is verified, and includes some slight changes. Email alert is moved as last, and needs to further work.
• SMS command gateway bug fixed, it should correctly handle incoming SMS messages.
• Updated Ethernet library to latest release.
• Added special global trigger for all Battery type nodes. It is activated when voltages is bellow 3.6V and deactivated when above 4.16V. Alert handling setting is common with other triggers. That is, it follows your setting on global tab.
• JavaScript was added in web interface of timers. Calendar and Period switch toggles On and Off part of controls that are meaningless.
• Template function was added to all HTML input elements, reducing the code size ~ 1.5kB. But was taken by new code again :)

Gateway source and libraries are pushed to GitHub.

Wireless node configuration.

Wireless nodes are part of OHS ecosystem. They serve as source of data from sensors, and as receivers for inputs. Inputs represents relays or other devices waiting for incoming commands. If you want to connect wireless node to gateway you need to set it up first. Start with download of example sketch from GitHub. Here is code for hardware version 1.4 https://github.com/vysocan/remote_1_4_RFM69. If you have on hand version with on-board temperature sensor and USB charging circuit then you can use the code almost without change. Basically you need to modify just the setting for radio module. Here is the part for radio

// Radio
#define NODEID      14
#define NETWORKID   100
#define GATEWAYID   1
#define FREQUENCY   RF69_868MHZ //Match this with the version of your gateway 
#define KEY         "ABCDABCDABCDABCD" //has to be same 16 characters/bytes on all nodes, not more not less!
#define ENABLE_ATC  //comment out this line to disable AUTO TRANSMISSION CONTROL
#define ATC_RSSI -75 

From this you need to only change following:

NODEID      2     // is number from 2 .. 250, do not number the nodes with same NODEID!
FREQUENCY   RF69_868MHZ // depends on your country, leave it as is or put RF69_915MHZ
KEY         "ABCDABCDABCDABCD" // needs to match the KEY of gateway.
ENABLE_ATC        // leave as is for battery powered nodes
ATC_RSSI -75      // threshold for AUTO TRANSMISSION CONTROL, you can safely leave as it is.

To start with minimal changes only, change just NODEID to be unique and KEY to match the one from gateway.

Wireless nodes are programmable, as gateway, with 3V3 FTDI 6pin USB to Serial programmer. They can be also powered from the programmer, that means you do not need a battery or charger plugged in while experimenting. To upload your sketch into board you have choose the right board target:
Select Tools > Board menu > Arduino Pro or Pro Mini, then choose Tools > Processors > ATmega328P (5V / 16Mhz)

All nodes run on 3V3 but on 16Mhz, as there is no such option choose  always (5V / 16Mhz), it will not do any harm. But FTDI programmer should be always set to 3V3 or the radio module will be damaged!

If all is set, you should see four new sensors in Node tab of gateway web interface. Wireless node then report temperature, battery voltage if battery is connected, charging status and own radio power level. Power level is useful to see how good the signal is when Auto Transmission Control is enabled, lower is better.

If you want to add new hardware to any node you need to create a default configuration for it in software. Assume that you want to add another temperature sensor to above mentioned four. First locate and change the total number of elements on this node, highlighted as bold:

// Configuration struct
struct config_t {
  uint16_t version;
  char     reg[REG_LEN * 5]; // Number of elements on this node
} conf; 

Then locate function setDefault(), you can see it is starting with following:

conf.version = VERSION;   // Change VERSION to force EEPROM load

conf.reg[0]  = 'S';       // Sensor
conf.reg[1]  = 'T';       // Temperature
conf.reg[2]  = 0;         // Local address
conf.reg[3]  = B00000000; // Default setting
conf.reg[4]  = B00011110; // Default setting, group=16, disabled
for (uint8_t ii=0; ii < 17; ii++){ conf.reg[5+ii] = 0;}

conf.version is place holder for node EEPROM setting and is to be left as is. But conf.reg[0..20] is place for default element configuration. Every element size is 21 bytes and their meaning is as follows:

• 0  means the major element type. First letter of Sensor, Input, Key or Zone.
• 1 is minor type of element. First letter of iButton, Temperature, Humidity, Pressure, Voltage, Battery, Digital, Analog, Float, TX_Power or Gas. If others are needed they should be added to GW software, or they will be reported as Unknown.
• 2 Is local address in range from 0..255. In case you need to have more then one device of same type.
• 3..4 are default configuration place holder, it is always as is. In real it holds various status flags of current element, but it is configured through web interface of gateway after it connects.
• 5..20 are storing element name. Here set to null, as real name is received from web interface of gateway.

To go back to adding a new element you need to add bellow 21 bytes to the end of  setDefault() function and increase the number in [] accordingly:

conf.reg[84] = 'S';       // Sensor
conf.reg[85] = 'T';       // Temperature
conf.reg[86] = 1;         // Local address
conf.reg[87] = B00000000; // Default setting
conf.reg[88] = B00011110; // Default setting, group=16, disabled
for (uint8_t ii=0; ii < 17; ii++){ conf.reg[89+ii] = 0;}

Notice the local address is increased by one. Last thing after adding new element is to force the node to reset its EEPROM configuration and load the data from setDefault(). This is done by increasing the VERSION in top of sketch:

#define VERSION     140 // <- increase by 1

If you upload above changes to node gateway should recognize the new sensor and you will see it in Nodes tab. You can then configure it as any other element. Gateway will send the configuration back node and it will store it in its own EEPROM. This configuration persist even if you power off the node.

Next thing would be to actually add the code to handle your new sensor data. I skip the part of how you get the temperature value, as it will depend on which temperature sensor you are actually using. And I go directly to sending. Gateway receives various packets, but similar to registration structure mentioned above, sensor data need to follow data structure:

• 0 identifies type of payload. First letter of  Sensor, Input or Zone.
• 1 is minor type of element as defined in setDefault() function.
• 2 Is local address as defined in setDefault() function.
• 3..6 are the actual data.

For example following code:

// Temperature 
u.fval = (((float)analogRead(A6) * 0.003223)-0.5)*100; 
msg[0] = 'S'; // Sensor
msg[1] = 'T'; // Temperature
msg[2] = 0;   // local address
msg[3] = u.b[0]; msg[4] = u.b[1]; msg[5] = u.b[2]; msg[6] = u.b[3];

// Send to GW 
radio.sendWithRetry(GATEWAYID, msg, 7); 

It will read the analog value from A6 pin, then do some necessary calculation depending on this exact temperature sensor, and store it in special float variable u.fval. All data for sensors and inputs are type float, that is they are 4 bytes long. First part of msg[0..2] create the header describing the source of data and msg[3..6] reads the data converted from float u.fval to 4x u.b[0..3] byte values. Calling radio.sendWithRetry then sends the data stored in msg array to gateway. Length of data is set to 7 as it contains bytes stored in array msg[0..6].
In one packet you can send more then one payload of same major type, here as 'S' in msg[0]. As shown here:

// Temperature 
u.fval = (((float)analogRead(A6) * 0.003223)-0.5)*100; 
msg[0] = 'S'; // Sensor
msg[1] = 'T'; // Temperature
msg[2] = 0;   // local address
msg[3] = u.b[0]; msg[4] = u.b[1]; msg[5] = u.b[2]; msg[6] = u.b[3];
// BATT Voltage 
u.fval = 0.0064453125 * (float)analogRead(A7); // Voltage divider 2:1
msg[7] = 'V'; // Voltage
msg[8] = 0;   // local address
msg[9] = u.b[0]; msg[10] = u.b[1]; msg[11] = u.b[2]; msg[12] = u.b[3];

// Send to GW 
radio.sendWithRetry(GATEWAYID, msg, 13); 

All that is needed, is to prepare the data in msg buffer and increase the length of message. Radio message length cannot exceed 62 bytes, or the actual size of bytes allocated in sketch for array msg[].

And that should be all :).