Showing posts with label software. Show all posts
Showing posts with label software. Show all posts

Tuesday, August 25, 2020

DFU - Device Firmware Upgrade

Gateways 2.s have now a new user convenient way of upgrading firmware without any external programmer. As STM32F4xx devices include built in USB DfuSe bootloader, I was wanting to implement such functionality into OHS as well. Since software version 1.2 there is an option in shell interface to boot the device to dfu mode., and then upgrade the firmware directly via USB cable.

DFU tools:

dfu-util  is a simple multi-platform command line tool that can upload binary data directly to flash.

List DFU ready devices via: dfu-util -l

Example output of gateway 2.x, most important is the 'alt=0, name="@Internal Flash  ' descriptor that we gonna use:

Found DFU: [0483:df11] ver=2200, devnum=12, cfg=1, intf=0, path="3-6", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="336A34763437"
Found DFU: [0483:df11] ver=2200, devnum=12, cfg=1, intf=0, path="3-6", alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e", serial="336A34763437"
Found DFU: [0483:df11] ver=2200, devnum=12, cfg=1, intf=0, path="3-6", alt=1, name="@Option Bytes  /0x1FFFC000/01*016 e/0x1FFEC000/01*016 e", serial="336A34763437"
Found DFU: [0483:df11] ver=2200, devnum=12, cfg=1, intf=0, path="3-6", alt=0, name="@Internal Flash  /0x08000000/04*016Kg,01*064Kg,07*128Kg", serial="336A34763437"

Flash the firmware via: dfu-util -a 0 --dfuse-address 0x08000000 -D ch.bin

STM32CubeProgrammer is also multi-platform tool but with graphical user interface. One downside is that you need older Java version installed to run it, but once you have it it will work nicely.

DFU howto:

  1. Connect your laptop/PC via USB cable to gateway. Status LED on gateway should change to short rapid flashes.
  2. Open any terminal emulation program like Putty and open serial connection to new enumerated USB device. On Linux it will be ACM0.
  3. In the terminal issue command 'boot dfu'.
  4. The gateway should close the USB connection, terminal will exit, or close, and the status LED will stop blinking.
  5. New USB device should be enumerated as 'STMicroelectronics STM Device in DFU Mode'
  6. Use any of DFU tool to list, connect and to download(in terms of to download a file to a DfuSe device) firmware into gateway.
  7. Reset the gateway via onboard reset button.

 

Saturday, August 22, 2020

Skeches for nodes compatible with OHS 2.x gateway

Recently I have pushed to GitHub new example sketches for the Arduino like remote nodes. These include software modifications, that are needed for the changes made in gateway 2.x software. Hardware part of nodes is still the same for both wired(RS485) and radio(RFM69) nodes.

Changes include:

  • Periodical ping to gateway. OHS 2.x gateway require a ping command from every registered node at lest one in an hour, or it is removed from node list.
  • Arm home. This new functionality is added to authentication mechanism on node, precisely to iButton routine. It works as usual for arm away, that is a quick touch of iButton arms away or disarms the group. When arm home state is required, user needs hold the iButton in probe for more then 1 second. Disarm is same as for arm away, a quick touch only is enough.
  • Authentication key is sent to gateway, and OK / Not OK sound is result of gateway accepting the packet with key. This does not mean that the key is valid and accepted, only that the gateway has received the key. On old node software, the OK / Not OK sound was result of iButton probe reading the iButton correctly or not.
  • New method for CRC signature for RS485 packets.

Repositories with software for nodes compatible with OHS 2.x gateway has name starting with: OHS_2-node

I will add new node examples as I build them.

Sunday, May 26, 2019

Remote uplodad and debug

Maybe you have similar setup at home as me. That is you have your OHS gateway close in some storage room along with your home server. I have it, my network panel, my small backup/sharing server (running excellent Open Media Vault), and my OHS gateway sit close to each other. And my desk computer is down one floor. It is rather inconvenient to push upgrades to gateway, one would have to put the code into laptop, go upstairs, take a chair and plug the FTDI programmer in. Each time you make some changes in code. So I have searched and found rather nice solution to this.

I use remote serial over TCP network. My server runs basically a Debian fork and after small search and couple of tries I found a program called socat. Socat can take physical /dev/tty* device and stream it over TCP. My example:

socat tcp-l:1234,reuseaddr,fork file:/dev/ttyUSB0,nonblock,raw,echo=0,waitlock=/var/run/tty,b115200

This above creates a stream of /dev/ttyUSB0 to TCP port 1234.


On the other side there is not much to install or setup, just use avrdude command line. Only thing you need to do in Arduino IDE is to select Sketch->Export compiled binary, this will place two hex files in you sketch folder. Then using avrdude command push the hex to created network serial port like this:

avrdude -p m1284p -c arduino -P net:10.10.10.127:1234 -Uflash:w:main_board.ino.with_bootloader.standard.hex 
  
Where net:10.10.10.127:1234 is target machine virtual network serial port, and other parameters represents Atmega1284p configuration with Arduino bootloader. Only one warning is issued by avrdue:

ioctl("TIOCMGET"): Inappropriate ioctl for device 


But it can be safely ignored. And this is it. Happy programming!

Friday, May 3, 2019

Updates in 1.7.6.4

This update is rather small and concentrates only on users having problems with false alarm of AC disruption on PSC-35A switching power supply.


If your PSC-35A or PSC-60A is repeatedly reporting AC On and Off alarms in OHS Log, then you should definitely go for the update. It adds kind of oversampling of AC_OFF pin, and also introduces 60 seconds delay when On/Off alert is issued.

As it is only minor version update configuration of you GW will remain as is.

Purpose of it, is to overcome the short, but frequent pulses of logical 1 to AC_OFF signal even when it supposed to be 0. This is caused by some logic inside the PSU.

If you still experience any issues with this PSU, let me know, best to use forum.

Firmware is pre-compiled in firmware section. 

Monday, December 31, 2018

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. 

Saturday, December 8, 2018

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.



Monday, April 23, 2018

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.

Tuesday, February 20, 2018

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.

Tuesday, January 16, 2018

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 :).

Saturday, October 21, 2017

New major version 1.7.6.0

Since summer time I was adding some features to gateway that led into new major version 1.7.6.0. Changes include:
  • Remote zones added.
  • Added group arm and disarm chain. That is when arming/disarming group by key, Gateway is able to automatically arm/disarm another group or groups.
  • Added group state MQTT publish. Gateway now, if enabled, will publish state of group via MQTT. Such information can captured by Home Assistant or other automation program.
  • MQTT sensor publish structure modified, added group name to path.
  • Updated MQTT library and MQTT protocol to 3.1.1.
  • Added new sensor type "Battery", to easily identify battery powered nodes voltage. 
  • Added new sensor type "Gas", to easily identify any air quality environmental sensor.
  • Added SMS command gateway. Authorized numbers from contact list are able to get Group state or set it On, Off, Arm and Disarm by sending SMS in predefine format to gateway GSM number. This functionality need some testing.
  • Updated NilRTOS to latest version available. In future port is needed to ChNil, which is newer replacement of NilRTOS, but unfortunately not one to one compatible with NilRTOS.
  • Various small enhancements in code and web interface.
New version is now at GItHub.

Monday, September 18, 2017

Remote zones

Recently I have started to play with feature that was on my list for long time. That is remote zone. To introduce it a little, on beginning I had in mind 2 general types of zones. Local zones are directly connected to gateway hardware. These can be build in 8 analog plus 4 digital zones, or zones connected by I2C expansion connector. Then remote zones connected either by RS485(wire) or wireless zones. Connection type does not matter to gateway, but such zones can be divided to two groups by reporting state. One group would report fully its state, that is it will report every change of state out of OK, PIR or Tamper. The other, battery powered remote zones, will only report alarm states such as PIR or Tamper. Gateway will then automatically change the zone state to OK if there is no event received for 2 seconds.

Remote zones brings new possibilities, you can build yourself a wireless PIR and add it to your gateway. Or you can build remote expander, either wired or wireless that will extend you zone count. Imagine you have barn near by, and you have only 4 wires connected to barn, that is only enough wires for authentication node. Now you decide you need two analog plus one digital zones there. Simply enough you connect such zones, with some little protection circuity, directly to authentication node. Add code to authentication node to include zone registration plus zone state handling, and you have 3 new zones connected.

I have here on my desk for test a battery powered remote zone, as shown on
picture. It is running for some days, and seems to do its job properly. I use Chinese all-in-one PIR sensor AS312 attached to PIR shell by hot glue. For this purpose I have modified standard battery node code and added zone state handling, based on interrupt signal coming form PIR sensor. The node does also temperature and humidity monitoring out of external SHT11. Battery life seems to be reasonable, with some modification it could last few months with 700mAh Li-Po. This is tempting, it would be nice to create rechargeable wireless PIR sensor that could be placed into standard commercial PIR shell :). I will publish the code to GitHub as example code.

Registering is same as for sensors. As soon as the node is powered up it will send registration packet and gateway will add a zone in zone tab. Then you can set attributes as for any other zone. Zone setting are sent back to nodes as master copy, and on next power cycle the zone is registered with newly stored  attributes. There are enforced rules for remote zones during registration, such as analog digital flag on bit 15 and it is based on registration  type ('A' or 'D'). Or remote zone flag on bit 12 is set On, and present bit flag on bit 14 is set On. Zone number cannot override any local zone, that is it cannot be lower then 13, or cannot override existing I2C zone. Zone last OK and PIR timestamps are set to registration time. Sleeping battery powered remote zones share the same message queue as sensors, that is gateway keeps registration packet for at least one hour to not loose such packets during node sleep.



Saturday, July 22, 2017

Node code for PCB 1.4.

I have just created new repositories for nodes version 1.4. Although you can, similarly as I did, covert the code from version 1.3. But all new changes will be as always targeted to the latest version.

https://github.com/vysocan/remote_1_4_Key_Temp.git

https://github.com/vysocan/remote_1_4_RFM69.git

There are some changes mostly needed for new hardware features present, like charging indicator and other small corrections.

Tuesday, June 27, 2017

Auto arm moved from zone to group

After improving auto arm, I have realized that auto arm flag should be moved into group instead of zone. That is, it make no sense to have just one zone flagged as auto arm in a group. The algorithm then would not work, if user will not flag all zones in auto arm group, it will not consider all zones.  And most probably gateway will auto arm group that still has some movement detected. To prevent this possible human error, I have moved the auto arm flag to Group setting.

Changes are pushed into GitHub.

The use of auto arm feature can be greatly extended. For example, it can be easily used to lock an electromagnetic locks when authentication node will receive arm packet. As easy as wiring a pair of cable to node, but of course you have to have the electromagnetic locks installed first :).

Tuesday, December 27, 2016

Page alert

Another option named page alert is now functional in firmware 1.7.5. What it does, it takes telephone number and ring it for 15 seconds, then hangs up. It is efficient way to inform you about urgent alerts along with SMS, or as separate alert. But it is meant only for high importance alerts, since it needs to wait for GSM modem to dial, ring and hang up. It is processed at last in alerting thread, but stop processing of alerts for long time, especially when there are more then one telephone number to page/call.

Friday, December 16, 2016

Gateway setup

Just created new section on right called How to start and Gateway setup describing what hardware you would need to get started with OHS. And later first configuration of gateway.

Sunday, December 11, 2016

Email alerting

Some time ago email alerting was added, along to SMS, to send email to predefined contacts. I have been thinking what would be easy to achieve it for me, but also for other users. And although I have small server running at home, I have opted for service available for free online. I have found nice service offered by smtp2go.com, they have free plan service for 1,000 emails per month or 25 emails maximum per hour. That would be sufficient for any even heavy usage for a single gateway. Service is available on port 2525 and they ask for user credential encoded by base64. Simple enough to add into existing alerting thread. Just fill email user and email password in Global section and choose which type of alert is to be send via email. No fancy text is sent through email, just subject with same info as for SMS, and it is send to all recipient that match as single email. It works fast enough and seems efficient for alerts that have less importance.

Friday, December 2, 2016

Timers

Timers are new feature present on gateway firmware 1.7.4. As name suggest it allows you to manage remote nodes relays or any outputs by time schedule.

I was inspired to add timers to GW by repetitive resets of my stand alone digital timer outlet bought in hobby supermarket. This nice looking power outlet with relay and display is able to create 8 different schedules based on time and day of week. But sadly it randomly reset it self every 1~2 months, and leaves me to re-program it by its little buttons. After year or so I toss it away, and soldered another wireless node with relay output and started to add the scheduler to GW. 

There are 10 separate timers present in firmware, or more if you recompile it. The overview is present in following table:
As always all setting of timers is available over the GW web interface. Timers are divided to two different kinds. One called Period and other Calendar. The main difference between them is how they handle days of week. Calendar based timer can run only once a day at any given start time you provide. And you can select what day of week it will run. Period timer will run repetitively at every period time starting at given start time. Period time can range from 1-255 seconds, minutes, hours or days. Both of types of timers have in common run time setting which specify the time between On and Off signal to remote node. It again ranges from 1-255 seconds, minutes, hours or days.

All setting for timers are shown on right screen shot. Every timer can be identified by name, and can be turned On or Off at any time. There must be taken some caution when turning Off timer that is triggered, it would disable the Off signal sent to remote node and it will be left On. Then there is the mentioned Period and Calendar switch, and later on seven switches for every day of Calendar timer. These day switches have no functionality for Period timers. Start time on the other hand has meaning for both, Calendar timer will trigger exactly on this given time at any selected day. And Period timer uses the Start time as offset of its first calculated period interval. Period time and Period interval together make the desired scheduled start for Period based timer. And Run time and Run interval make the desired scheduled end for both types of timers. To address selection lets you assign any node in your wired or wireless network that is capable of input function. Then Constant On and Off are the values that are sent to such node at start and stop time.

I have made small demo video of four Period timers set with Period time to 2, 4, 8 and 16 seconds and Run time set to 1, 2, 4 and 8 seconds. As you see it on LEDs, they create a nice binary counter :). Just to say, the code of below wireless node is only capable to listen to commands from GW, and turn the attached relays On or Off based on received value. So no need to reprogram it in case of changes.


Tuesday, November 8, 2016

Triggers

After some playing with gateway functions and Home Automation Systems, I have realized that I often need to pass some data from one sensor to another. Either periodically every time there is new value or just when there is a condition met. These conditions are mostly rather simple, like voltage on battery powered node is reaching low level, or turn on light then there is a person in front of PIR alarm sensor. Having a gateway, I can collect the data. Pass it through Ethernet to MQTT, then to some automation server like NodeRed, process the state and send the result all the way back to another remote sensor or relay. I thought this can be a bit overkill and always require a running computer or at least a Raspberry Pi, so the triggers were born.

Triggers is new option in firmware 1.7.3, it offers as the name suggest, triggering events on sensors or zones. The overview is shown on following picture:



There can be up to 10 triggers created, or more if you set it in code, that can do various task or react on zone state or sensor value.

The setting of each trigger is shown on right. You can assign name up to 15 characters for each trigger and turn it On or Off. Important is the source address, that is the sensor or zone number, that triggers the subsequent action. Symbol is condition describing when the trigger should happen. Put it simple, it is "if ... then" in code. There can be "=","!","<",">","A", that is equal, not equal, less then, more then or always. Value is a float number that the condition is compared to, except for symbol always that is processed anyway. Then there is logging flag, it means the trigger event is passed to logger, which can then send SMS or email, based on logger setting. Pass flag will indicate that when the event is triggered, gateway will pass the value to To address sensor. Pass once flag is preventing subsequent sending of value for same trigger, and it is reset when condition is negative. Pass Off will send first message to recipient after the condition is negative. Pass value or constant switch is deciding if a source address value is passed to destination address or the constant present in Constant On and Constant Off.

With above you can dynamically assign many events that can help you improve your home automation directly in friendly web interface. On first example picture above, there are 2 triggers created. First to send SMS or email when battery is reaching low level on my meteo station. And second will turn on light whenever there is PIR sensor triggered on zone called stairs. Simple as that, and it just works!

You can create many other scenarios for triggers, such as simply passing data from one sensor to another. I have in mind passing external temperature and humidity to internal temperature and humidity sensor that turns On/Off fan in bathroom. This way you can compare the two values and make better decision.






Friday, September 30, 2016

Software upgrades

With new version of hardware in fabrication, I have turned back to software side of gateway. I have made significant improvements in zone thread and also improved the alarm event thread (AET). It stays, that it can handle 3 simultaneous alarm events at once. That is the software is able to wait for authentication when you enter one zone, while setting alarm for any other two, or any combination.  Additional  AET can be added, but 3 should be enough for any normal household or property. Overflowing event will not be lost, but logged, and if reoccurring it will trigger AET again. In real scenario your inner house zones will have authentication time set to 0 seconds, and they will be properly handled by AET in no-time. Only time the AET will overflow is when your local SWAT team enter your house by every window at once. Still it will set alarm On and notify you and you neighbours :).

I have reworked time keeping mechanism. Mainly inspired by simple idea that the NilRTOS, that is used for gateway, can trigger thread periodically at any given millisecond interval. I have tossed away routine, that was asking RTC chip connected by TWI/I2S every time software was needing exact time. And instead created a new timer thread with 1 second wakeup interval. There the thread increase internal second counter, keeping the time available to other threads. Also there is 2 byte counter that will sync with RTC chip when it overflow, that is every 2^16 seconds, at least once a day. It nicely give back some processing power to all threads as TWI/I2S transfers are only 400kbs.

With all that I was able to get back to original idea of having not only a security system, but also a sensor gateway. All started with unifying authentication nodes and sensors. Now they are put together simply as nodes in web interface, and they can also have name assigned along with address and local number. This further improves registration and handling of sensors. I added new feature, or better new type of node. An input node that represents a remote relay, switch or any other output resource that can be addressed by float point value. It works astonishingly well and it does not matter if the node sits on wired or wireless network.

Another news are new feature sets called triggers and timers. As name imply it will do just that :), but I will leave it for new blog post. I think it is worth it.

Also PCB's are fabricated and waiting for shippment.

Monday, December 28, 2015

Remote node code

Just created new GitHub repositories for remote node code and put links to them on the page here on blog.

In the code there is visible declaration of sensors and authentication units, and their way of registration to gateway. In the iButton node, there is also sound and led code that is based on tone library and performs feedback to user. Wired nodes use my own RS485 library, otherwise standard Arduino libraries are used.