Re-imagined RFM node code - All-in-one, low power, OO design

[lewishollow]

Code updated.  Change notes - 

Changed low power design to use a combo of periodic wake up (sleepMultiplier * 8 = seconds the node will sleep before waking up to send a message) and pin-based interrupt. Tested functional with a reedswitch



Brought back the ACTUATOR device - I had replaced it with ACT1 and ACT2, but that caused confusion.



Fixed a bug in the RealInputData class that tried to use a define to which it did not actually have access.
--------------------------------------------------------

Example openhab files were requested.  I'm posting my sitemap, items and rules files.  I did not add comments or clean up commented code, but you should be able to walk through and see what I've done.  Also, they are not going to necessarily work for everyone - my gas and flame thresholds are calibrated for the rooms they're in, and my alarm notification basically sends an email for every time it detects a sensor above a threshold.  This is something I use for troubleshooting and calibrating the sensors, but if you set it up to point at your email address and your sensors aren't completely calibrated, you will most likely get a flood of emails.  Consider yourself warned. 

See attached files.

I'm working on a separate post about my solar powered sensor now!

Attachments:

examples.zip (4.71 KB)

[ragoth]

Your Example files are great help for us to learn and implement the extensive options of openHAB. Now I got one year homework to do.
Yes, exploring all the options in your sitemaps, items, rules etc., may take an year for me to become familiar. Already I learned one year subject in one month by going through your Re-imagined RFM node code.

Thank you so much for your wonderful contribution. 

[lewishollow]

Hello ragoth - I'm so glad you find the code and openhab config files helpful! If you have any questions about the openhab config files, please let me know. I could even try to comment my openhab files to make them more understandable, though I don't know if it would totally clarify everything for you.

PS - solar powered node instructions posted -
homeautomation.proboards.com/thread/108/solar-powered-outdoor-node-instructions

[ragoth]

Dear Mr.lewishollow, Thank you for the latest release. Your earlier release of RfmNode used compile fine, but the latest release of RfmNode gives the following error message and stops compiling. Please advice.

C:\DOCUME~1\SAIRAA~1\LOCALS~1\Temp\build1812997315619463284.tmp\RfmAioNode\AnalogSensorData.cpp.o: In function `AnalogSensorDataClass::getValueToSend()':
C:\Documents and Settings\ragoth\My Documents\Arduino\libraries\RfmAioNode/AnalogSensorData.cpp:56: undefined reference to `currentTime'
C:\Documents and Settings\ragoth\My Documents\Arduino\libraries\RfmAioNode/AnalogSensorData.cpp:56: undefined reference to `currentTime'
C:\Documents and Settings\ragoth\My Documents\Arduino\libraries\RfmAioNode/AnalogSensorData.cpp:56: undefined reference to `currentTime'
C:\Documents and Settings\ragoth\My Documents\Arduino\libraries\RfmAioNode/AnalogSensorData.cpp:56: undefined reference to `currentTime'
C:\DOCUME~1\SAIRAA~1\LOCALS~1\Temp\build1812997315619463284.tmp\RfmAioNode\ComponentData.cpp.o: In function `ComponentDataClass::getShouldSend()':
C:\Documents and Settings\ragoth\My Documents\Arduino\libraries\RfmAioNode/ComponentData.cpp:36: undefined reference to `currentTime'
C:\DOCUME~1\SAIRAA~1\LOCALS~1\Temp\build1812997315619463284.tmp\RfmAioNode\ComponentData.cpp.o:C:\Documents and Settings\ragoth\My Documents\Arduino\libraries\RfmAioNode/ComponentData.cpp:36: more undefined references to `currentTime' follow
collect2.exe: error: ld returned 1 exit status
Error compiling.

[lewishollow]

Hi ragoth -

I got rid of the "currentTime" variable in the latest version of my code. Please make sure to update RfmNode as well as all of the library files and not just the RfmNode itself.

[ragoth]

Dear lewishollow, Thanks for your immediate advice. Now I am using all New libraries, but still getting this error while compiling. Excuse me for disturbing you again. Please advice where I am going wrong.

C:\Users\j\AppData\Local\Temp\build6928438326521129905.tmp\RfmAioNode\RealInputData.cpp.o: In function `RealInputDataClass::getValueToSend()':
C:\Users\j\Documents\Arduino\libraries\RfmAioNode/RealInputData.cpp:44: undefined reference to `thisCycleActualMillis'
C:\Users\j\Documents\Arduino\libraries\RfmAioNode/RealInputData.cpp:44: undefined reference to `thisCycleActualMillis'
collect2.exe: error: ld returned 1 exit status
Error compiling.

[lewishollow]

Hello ragoth -
Don't worry about disturbing me. I'm happy to help. Also, you pointed out what is indeed an error. I was working on a low power node when I updated the code, and I forgot to test it without being in low power, which was a silly oversight. Thank you, and I apologize for the inconvenience.

Just grab the latest RfmNode.ino and you should be good.

[ragoth]

Dear lewishollow, Thanks for correcting this error and it happens to everyone.
Once again I appreciate your radical approach, to take this DIY openHAB to the next level.

[Ryan]

Hi lewishollow,
Could you suggest me the code to display your rain sensor reading in the LCD node.

[sefi]

Hi lewishollow ,

After reading your ino file for the RfmNode.ino, am I correct in assuming:
1. It is capable of controlling multiple sensors, assuming they are wired properly to the correct pins, using a Proto Shield for Arduino and that their corresponding *ENABLED flag is defined?
i.e., PIR Sensor to pin 8, LIGHT to pin A0, and ACTUATOR to pin 9, for a module that knows to report if the light is on in an empty room and turn the lights off on command

2. Connecting the sensors wires to the UNO are as described in the original post for the Uber Sensor: www.instructables.com/id/Uber-Home-Automation-w-Arduino-Pi/?ALLSTEPS ( in terms of wiring to GRND, V, resistors, capacitors etc - obviously, the pin should be as 1. above).

3. Connecting the RFM69 wires to the UNO node/gateway are as described in the original post (see screenshot)


I am referring to sensor wiring and RFM69 wiring like these ( again, only GRND, V, resistors etc. the pins are as they are annotated in the code):




Also, am I correct in assuming the wiring for the RFMGateway - I should stack the Ethernet Shield on the Uno and wire the RFM69 like above?



Thanks!
Sefi

[sefi]

Oh, Now I see that computourist is using Arduino Pro Mini with Voltage regulator. I think using the Uno will be easier for me (the 5v <-> 3.3V version)
So, I guess I should follow this schematic, just drop the regulator




I'm sorry to ask such questions, but I am so new to this wiring, I just wanna make sure I'm on the right track.

[papa]

sefi, you ask " am I correct in assuming the wiring for the RFMGateway - I should stack the Ethernet Shield on the Uno and wire the RFM69 like above?"
    Yes, stack Ethernet Shield on the Uno compatible switched to 3.3 volts

        Wire the RFM69 ONLY SIMILARLY to the "above." On an end node, NSS connects to Arduino pin D10.  BUT, on the Gateway, NSS connects to Arduino pin D8 (because the Ethernet Shield needs D10).

      << Here's a schematic I adapted from computourist's for the Gateway built with a 3.3 volt Buono Uno. It's worked well for me.
    =====================================================================
Yes, sefi, for the DHT End Node, basically you drop the regulator & make connections on a 3.3v Uno (like a Buono Uno) that are similar to the connections on the Pro-Mini.

       << Here's a schematic I adapted from computourist's for DHT End Node built on a Buono. It's worked well for me.

                ^^ Click on the schematic for a larger view.

                                My Success... thread gives some instructions for building the Gateway & End Nodes.

[sefi]

Perfect!!!

Thanks a lot papa !

However, I don't get is why do we need the LEDs on the Gateway and the LEDs and switch on the Node...

Also - I can't find a 4.7K Ohm resistor like in your schematic - only 470 Ohm and 470K Ohm...

[computourist]

Hi sefi,

You'll find some better schematics at:

github.com/computourist/RFM69-MQTT-client/blob/master/Gateway_2.4/MQTT-GTW.png

and

github.com/computourist/RFM69-MQTT-client/blob/master/DIG%20end%20node/DIG-node.png

[lewishollow]

Feb 11, 2016 5:57:59 GMT Ryan said:

Hi lewishollow,
Could you suggest me the code to display your rain sensor reading in the LCD node.

It's actually in the latest version of RfmNode.ino. 

Make sure this is in your list of enabled devices -
#define RAINSENSORENABLED



Find this code block -
#ifdef RAINSENSORENABLED

#define RAINPIN A0

#define RAINSENSORDEVICEID 67

AnalogSensorDataClass *rainSensorData;

#endif //RAINSENSORENABLED


Just make sure that RAINPIN is set to an analog pin you have free.

In setup(), make sure this exists -
#ifdef RAINSENSORENABLED

int rainSenorThreshold = 20;

rainSensorData = new AnalogSensorDataClass(2 * ONESECOND, rainSenorThreshold, RAINPIN, RAINSENSORDEVICEID);

#endif //RAINSENSORENABLED


and that's it! All of this code exists in the latest RfmNode.ino.  Let me know if you need more help!

[lewishollow]

Feb 11, 2016 12:33:35 GMT sefi said:

Hi lewishollow ,

After reading your ino file for the RfmNode.ino, am I correct in assuming:
1. It is capable of controlling multiple sensors, assuming they are wired properly to the correct pins, using a Proto Shield for Arduino and that their corresponding *ENABLED flag is defined?
i.e., PIR Sensor to pin 8, LIGHT to pin A0, and ACTUATOR to pin 9, for a module that knows to report if the light is on in an empty room and turn the lights off on command

Computourist and papa ably addressed your wiring questions, so I'll just respond to your first question on the software.

You are correct in your assumptions.  The goal of my code was to make it so that it could support multiple sensors, and so that one code base could support all nodes by changing only the node ID and which sensors were defined as enabled.  I have a single node running a dht, a flame sensor, a gas sensor, a PIR sensor, a photoresistor and 2 LEDs.

Based on what you posted, it looks like you are doing the right thing for what you want.  

[Ryan]

Hi lewishollow,
Thank you and I am very sorry, I did not put my question right. Already your rain sensor works fine, but I need to display that content on the LCD Display node.
so please advice, what are the lines to be added in my Sitemap, Items and Rules files etc.,so that the LCD Node displays the Rain level on LCD.

[ragoth]

Dear lewishollow, I added a Switch function in the Front Yard Item and in Rules file as follows. It works, but very slow compared with your all other functions. Your original functions responds very fast but not mine.
//Item File:
//node03
Switch itm_node3_sw1_mqtt "Front Gate Light" (frontYard, frontYardGate) {mqtt=">[mosquitto:home/rfm_gw/sb/node03/dev17:command:ON:ON],>[mosquitto:home/rfm_gw/sb/node03/dev17:command:OFF:OFF]"}

//Rule File:
rule "Front Gate Light"
when
Item Node03_Output changed
then
if(Node03_Output.state==ON) {
postUpdate(Act_Node03, ON) }
if(Node03_Output.state==OFF) {
postUpdate(Act_Node03, OFF) }
end

Please correct me or suggest me the right way of doing it.
Thanks and Best Regards.

[lewishollow]

Feb 13, 2016 11:24:15 GMT Ryan said:

Hi lewishollow,
Thank you and I am very sorry, I did not put my question right. Already your rain sensor works fine, but I need to display that content on the LCD Display node.
so please advice, what are the lines to be added in my Sitemap, Items and Rules files etc.,so that the LCD Node displays the Rain level on LCD.

Hi Ryan -

I haven't actually added an LCD device into my projects.  However, for the openhab side, I posted my openhab files for others to review and use.  In it, the rain sensor analog reading is converted into one of four states - No rain, light rain, heavy rain, flood, and displayed in openhab.  All you would need to do is, in the rule that posts the data to the openhab UI, you would instead send a command to your LCD node to display the state.  I believe computourist has LCD example code.  I'll order an LCD module so that I can implement this into my libs as well.

I hope that helps!

[lewishollow]

Feb 13, 2016 13:06:54 GMT ragoth said:

Dear lewishollow, I added a Switch function in the Front Yard Item and in Rules file as follows. It works, but very slow compared with your all other functions. Your original functions responds very fast but not mine.
//Item File:
//node03
Switch itm_node3_sw1_mqtt "Front Gate Light" (frontYard, frontYardGate) {mqtt=">[mosquitto:home/rfm_gw/sb/node03/dev17:command:ON:ON],>[mosquitto:home/rfm_gw/sb/node03/dev17:command:OFF:OFF]"}

//Rule File:
rule "Front Gate Light"
when
Item Node03_Output changed
then
if(Node03_Output.state==ON) {
postUpdate(Act_Node03, ON) }
if(Node03_Output.state==OFF) {
postUpdate(Act_Node03, OFF) }
end

Please correct me or suggest me the right way of doing it.
Thanks and Best Regards.

How slow is slow?  A couple of seconds?

I'm going to assume this node is not running with low power since you're sending a southbound message, which isn't supported when low power is defined.

Also, it looks like you are not checking the state of itm_node3_sw1_mqtt directly.  Instead, you're checking Node03_Output.  Can you post the code that gets the mqtt data and stores it in Node03_Output?

[ragoth]

Thank you lewishollow, I am not using Low power mode and this is the code used and it takes 1 to 7 seconds as the delay is not uniform. Some times instant and some times 7 seconds or so. What I planed is a simple Switch to control a Relay(D7) to open the Front Yard Door (Node 03). it works but with a irregular delay. Best Regards.

//SiteMap:
Frame {
Switch item=Act_Node02 label="Node02_Output"
}


//Item:
Switch Act_Node02 {mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:ON:ON],>[mosquitto:home/rfm_gw/sb/node02/dev16:command:OFF:OFF]"}


//Rule:
rule "Match UI & Act_Node02"
when
Item Node02_Output changed
then
if(Node02_Output.state==ON) {
postUpdate(Act_Node02, ON) }
if(Node02_Output.state==OFF) {
postUpdate(Act_Node02, OFF) }
end

[Ryan]

Hi lewishollow, Thanks for your suggestion. As you said I referred the computourist example and it works fine now. Thanks again.

[papa]

    ragoth, it looks like you used some code I provided perhaps in the OpenHAB config samples, openhab-papa.zip.

I'm not sure it is the best code, but the only one I could work out (back when I was learning OH) without throwing errors & greater delays.

      It actually depends on two items, the one you listed
Switch Act_Node02 {mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:ON:ON],>[mosquitto:home/rfm_gw/sb/node02/dev16:command:OFF:OFF]"}
      & another
Switch Node02_Output { mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:default]" }

           I worked it out to address the following issue: Using only the first item above ...
if one clicks the node's virtual switch on the browser user interface (UI), the switch toggles (quickly) an ON or OFF state & a LED or relay on the node also toggles.
         HOWEVER, IF ON THE NODE ITSELF, someone uses a switch, the UI switch never changes to show the true state of the node.

Notice that both items use device 16 on the node. The first one toggles device 16 & the other READS the device 16 state.

The rule uses the second item's READ to postUpdate the first item's state AND thus the appearance of the UI switch.
       That's why the rule is called "Match UI & Act_Node02"

It works, but as you notice with a bit of delay, maybe because (necessarily) more is involved or maybe because I unnecessarily complicated things.
     When using rules in other situations (especially including postUpdate), such approaches seems to take longer to show effect.

     Maybe we can find a better, more responsive way to address the issue above.
When I tried to use only the first item, it showed instantiation errors & caused even more delay.

One more thing that I am not yet sure about or sure whether it affects the delay we see with this approach:
    I've seen some indication that at least with Linux/Raspberry Pi, it may matter how one names rules.

At least on Windows a rule name like "Match UI & Act_Node02" seems to work or at least did work.

On Linux, OH may ignore such a name & may require no quotes & no spaces, like Match_UI_&_Act_Node02

[chrisinkc]

I am stuck and I don't know what to do. I pretty much followed lewishollow's code in this thread to a T, but it does not appear to be updating the openhab web interface completely. For example, the "Node2 last response" is still showing empty even though the node has been up and running for 12 hours.

I have only set up 1 node and it has photo, gas, flame, temp and humidity sensors.  Attached is a view of the debug on my Pi.  Any help would be greatly appreciated.

[papa]

Your debug output shows that OpenHAB / MQTT is receiving data from Node2, but for some reason that is not showing on your web browser user interface.

To help us locate the possible cause, please give more information. That is, list all your items, rules, & sitemap entries that relate to Node2.

[chrisinkc]

Attached are my sitemap, rules, and items example.sitemap (1.26 KB)example.rules (12.46 KB)example.items (11.87 KB)

[lewishollow]

chrisinkc 

So a couple of things -

Note that the way I implemented the last response time mechanic was a bit janky. It checks for an update to the temperature reading and posts that time. This could be any device you want - the rssi value is another good one to use. The limitation, however, is that if the value doesn't change from one reading to the next, openhab does not read that as an update, which means the last response value will not update.

Also - I would not recommend using my example files wholesale and trying to modify them. I would pull out the chunks you want to use into new files and build up from there. The reason for that is that code that rules that look for data from nodes that don't exist aren't guaranteed to be no-op. For instance - the rule that runs when the gate status updates - if the node that processes the LED command isn't there, I've seen that hang processing of further rules. It seems like a bug in openHAB, but I'm not totally sure. Basically - you are introducing many other unknown variables by using my entire set of config files if you aren't actually matching my sensor network's functionality.

[chrisinkc]

Lewishollow, I will do what you suggest and see if that helps.

[chrisinkc]

Looks like that was in deed the issue! All good now! Thanks for your help.

[lewishollow]

Feb 14, 2016 12:43:41 GMT ragoth said:

Thank you lewishollow, I am not using Low power mode and this is the code used and it takes 1 to 7 seconds as the delay is not uniform. Some times instant and some times 7 seconds or so. What I planed is a simple Switch to control a Relay(D7) to open the Front Yard Door (Node 03). it works but with a irregular delay. Best Regards.

//SiteMap:
Frame {
Switch item=Act_Node02 label="Node02_Output"
}


//Item:
Switch Act_Node02 {mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:ON:ON],>[mosquitto:home/rfm_gw/sb/node02/dev16:command:OFF:OFF]"}


//Rule:
rule "Match UI & Act_Node02"
when
Item Node02_Output changed
then
if(Node02_Output.state==ON) {
postUpdate(Act_Node02, ON) }
if(Node02_Output.state==OFF) {
postUpdate(Act_Node02, OFF) }
end

Sorry about the delay, Ragoth.  Let me post the relevant bits from my code that do what I think you're trying to do.

In my case, it's a reed switch on one note which, when opened, turns on a red LED and turns off the green one on another node, and when closed, lights up the green and turns off the red.

// in my items file this is where the gate node sends its status.
Contact itm_node3_gate_mqtt "Front Gate Status [%s]" (frontYard, frontYardGate) {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev42:state:CLOSED:ON],<[mosquitto:home/rfm_gw/nb/node03/dev42:state:OPEN:OFF]"}

// when that item is updated, the following rule runs.  Note that I'm using the mqtt value directly, and not storing it in another variable.
rule "Living Room set LED from Front Gate"
when
    Item itm_node3_gate_mqtt received update or System started
then
    if (itm_node3_gate_mqtt.state == CLOSED)
    {
        sendCommand(setNode6GreenLed, "ON")
        sendCommand(setNode6RedLed, "OFF")
    }
    else
    {
        sendCommand(setNode6RedLed, "ON")
        sendCommand(setNode6GreenLed, "OFF")
    }
end

Those two commands look like -

String setNode6GreenLed "Set Node 6 Green LED" {mqtt=">[mosquitto:home/rfm_gw/sb/node06/dev17:command:*:default]"}
String setNode6RedLed "Set Node 6 Red LED" {mqtt=">[mosquitto:home/rfm_gw/sb/node06/dev16:command:*:default]"}

And that's it.  I'm not sure if this helps, since you already have my openhab files, but if you more closely emulate my setup, you might have better luck with responsiveness.  For example, since ON = ON, you can probably just use command:*:default.