Updated to gateway 2.2 and DHT end node 2.1 - no connection

[lewishollow]

I just set up the combination RFM/Ethernet gateway using Gateway 2.2, and it's reporting that it's connecting to the MQTT server, which is great!

The node is reporting no connection, however. I'm using the DHT end node 2.1 version (I didn't see a 2.2 version), and when I run it on my sensor node, it's just reporting No connection...

As far as I could tell, there was nothing to change other than the radio frequency in my end node code, and the only change in the wiring of my temperature sensor was to move the data pin to D4.

Any tips for debugging? I'm still sorting through the code, but if you guys know of any gotchas here, I would appreciate it.

Note that I'm using the Buono boards and not the Pro minis in the new schematics. I'm not sure if that matters.

Thanks!

[papa]

You have the latest Gateway & end node versions.  I also use Buono Uno Arduino compatibles & they work fine.  In my Success... post 9/22/2015 4:44pm is a Gateway schematic adapted to use Buonos.  The 9/22/2015 7:51 pm post has an End Node schematic with a Buono (though it uses a solid state relay instead of an LED.)

Success with a MQTT connection means the Gateway is connected with your home network & with the MQTT service where you installed it in your network. 

When you write "The node is reporting no connection," I assume you mean the End Node is in debugging mode, connected to the computer's usb & you see a "no connection' message via the Arduino IDE serial monitor.  Right?

"No connection" means the RFM69 transceivers on Gateway & End Node are not connecting for some reason.

   Did you make the needed changes in the w5100.h library file?  If not, in my Success... post, at the middle of the Oct. 7, 2015 10:15am post, see how to do that.

   I suggest you carefully recheck how you connected the RFM69 transceivers to the Arduino connections to match the Gateway & End node schematics.  Are they in the right socket & are they securely in that socket.  Be especially careful that for the Gateway, NSS is connected to D8 & the End Node's NSS connects to D10.

  You might also review my Success... post Oct. 8, 3:18pm about troubleshooting using hardware clues.

Sometimes, something as simple as restarting the Gateway (press the reset button) & restarting the End node can help them begin communicating.

I hope this helps.  If not, say more about what you've tried & what results you are seeing & not seeing.  Those clues might help with diagnosing.

[kmac]

I ran into this problem with my setup. Turned out the packets were being received fine by the gateway, the Ack sent by the gateway to acknowledge reception wasn't reaching the node in time. To see if this is your problem, try this.
Look for the following line in the RFM_DHT_node_21 sketch:

#define ACK_TIME 50 // max # of ms to wait for an ack

Change the 50 to 100
Then look for a line like this:

if (radio.sendWithRetry(GATEWAYID, (const void*)(&mes), sizeof(mes)))

Change it to look like this:
if (radio.sendWithRetry(GATEWAYID, (const void*)(&mes), sizeof(mes)), 3, ACK_TIME)

The two optional parameters at the end tell it to re-try sending 3 times, and wait ACK_TIME for the Ack response.
If you don't add these parameters then the defaults are used, whick is 2 retries and 40ms wait time.

[lewishollow]

Thanks for the help, papa and kmac! This is such a helpful and supportive forum! Changing the ACK_TIME and adding those optional parameters seemed to be the part that made the difference!

The node now says it's sending temp and humidity data, but I'm not seeing any debug output on the gateway about  the received packet. It's just sitting at "got connection with MQTT server". I have DEBUG defined, so it looks like it's supposed to print out a block of data when it receives a message. At this point, it seems every link in the chain should be satisfied. Any thoughts?

[kmac]

When you compile/upload the gateway sketch with debug enabled do you get a warning at the bottom about low memory?

[papa]

To help me respond better to your situation, please say more detail about what you report in the second paragraph of your last post. WHERE do you see the node is sending temp/humidity data...? When it's in debug mode, connected to the Arduino IDE computer via USB & serial monitor is open? Where & how do you see the Gateway is sitting at MQTT server connection? In both cases, are both Gateway & Node powered at same time?

In addition, what did you try of my suggestions, like restarting (a few times) Gateway & end node (press each's reset button)? When you try those, what are the results. What else have you tried with what results?

More details can help us know what you've tried & not & may offer clues to what's working & not .

[lewishollow]

As I was going back over all of the steps to be able to answer all of these questions in detail, it started working! I'm not sure what I did differently. Maybe it was just the additional reboots of the devices...

For the record - I am looking at the serial monitor of the output with DEBUG defined in the code. Both devices are connected via USB (to different machines), powered on simultaneously.

Thanks for the help, guys!

[papa]

Sounds similar to my experience. Restarts do seem to help sometimes.

You're welcome.  Pass the help along to someone else if you are able.

Enjoy.

[lewishollow]

I absolutely will help others where possible!

One last question - are there docs to help setup of openhab? The openhab config files I was using for the old setup from the instructables tutorial obviously isn't working anymore, and I'm looking for info on getting openhab listening to mqtt again.

I think the critical bit is in items where I subscribe to the event. It sounds like, for a temp sensor on node 2, the subscribe string should be -
{mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev48:state:default]"}

Is that correct?

Thanks!

[papa]

In my following answer, keep in mind that I'm using OpenHAB 1.7.0 on a Windows 7 laptop. I don't know yet if it makes a difference using the latest OpenHAB or Linux (like Raspberry Pi).

Yes, the syntax may have changed a bit from the Uber Home Automation Instructables to the CompuTourist derived approach that's often followed in this forum. There's some OpenHAB documentation within RFM_MQTT_gateway_description_V21.pdf in ComputTourist's Gateway 2.1 folder of this zip file.

One can glean some helpful information from the OpenHAB wikis, like for the MQTT Binding.

          The comparable line in my Items config file reads:
Number Temperature_Node02 "Temperature_Node02 [%.1f °F]" <temperature> {mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev48:state:default]"}
                                 so it looks like your mqtt subscription matches mine (which works for that part).

          Also the following affects the node sending data via the Gateway to OpenHAB:

                       About line 85 in my DHT End Node sketch, is this:

// STARTUP DEFAULTS
//
long TXinterval = 20; // periodic transmission interval in seconds
            Starting about line 208 in my DHT End Node sketch,  is this section:

// PERIODIC TRANSMISSION
//
if (TXinterval > 0)  
{
int currPeriod = millis()/(TXinterval*1000);
if (currPeriod != lastPeriod) { // interval elapsed ?
lastPeriod = currPeriod;

// list of sensordata to be sent periodically..
// remove comment to include parameter in transmission

// send1 = true; // send transmission interval
send2 = true; // signal strength
send4 = true; // voltage level [battery]
send16 = true; // actuator state
send48 = true; // send temperature
send49 = true; // send humidity
}
}
       The above means that every 20 seconds (TXinterval), the DHT end node sends data for devices 2, 4, 16, 48, & 49, but does NOT send device 1 because "//" at the start of the line makes the line a "comment" not working code.  So in the above list, make sure send48 = true & is not commented out.  Of course, OpenHAB config must subscribe to receive that sent data, which is what you're seeking to do with the device 48 subscription in your Items file.

       To see the Node02 temperature data updated within the User Interface on your browser, you'll need a line (in OpenHAB's sitemap config file) like:

                             Text item=Temperature_Node02

[lewishollow]

Once again - thank you! I think the problem in the end was that I was trying to reuse the old openhab config files with just enough modifications to where it seemed like it should have been working. I basically had to just create new config files with only the parts I wanted. I'm just editing in a text editor and not in eclipse, so it's possible I had a typo that I was missing.

[papa]

You're welcome. I had the same trouble trying to use the demo config files & like for you, it worked better to mostly start over. In the official OpenHAB forum others said how confusing to just start with the demo config & asked for a basic config set to build on.

[lewishollow]

Another question if you don't mind. I got the temperature sensor all set up, which is awesome, but now I'm trying to reincorporate the other sensors, like the light sensor, gas sensor, flame sensor, etc. I don't see any sketches that include those anywhere. I'm a capable programmer, so I'm happy to sort through it myself, but I figured there was a possibility that node sketches with more sensors were available elsewhere, so I figured I would ask before going down that rabbit hole. I took a quick stab last night before bed and had the light sensor sending its status on every loop iteration, which is clearly not desired. I'm sure I'll find the bug quickly, but like I said, if there is existing code somewhere, that's always a plus.

Thanks!

[papa]

I don't believe other sensors are addressed in this proboards forum, but they were in the original Uber Home Automation Instructable where you might some helpful code to adapt into the nodes described in this forum.

     Yes, the node sketches tend to send the sensor data at the end of every Transmission Txinterval.  You might code the light sensor device to only send when the data changes out of a certain range.

Keep us posted on your results.  It will be interesting to see if added sensors run into current limitations or if any affect interrupts & interfere with the RFM69 transmissions.

[computourist]

The node sketch has two models for data aquisition:

- push model, where data is pushed at a regular interval (that is what you are using now)
- pull model, where openhab requests the data by sending a "READ" command to the node/device

The first model is used when you want to track data continuously (typically temperature or humidity)
The second model is used whenever you want to check a value as a result of an event generated by Openhab (do I turn on the heating when the window is open ?)

An example of the pull model is somewhere on this forum, where the RSSI value is requested based on a timer (Cron)

EDIT:

Found the example, it is the LCD thread. 
In the openhab example you can see a CRON rule that refreshes RSSI value every minute.

[lewishollow]

I will indeed. I figured out my polling frequency problem, but the messages did seem to be interfering with each other possibly. I'll spend some time with it over the weekend and report back.

[lewishollow]

Oct 15, 2015 6:24:04 GMT computourist said:

The node sketch has two models for data aquisition:

- push model, where data is pushed at a regular interval (that is what you are using now)
- pull model, where openhab requests the data by sending a "READ" comamnd to teh node/device

The first model is used when you want to track data continuously (typically temperature or humidity)
The second model is used whenever you want to check a value as a result of an event generated by Openhab (do I turn on the heating when the window is open ?)

An example of the pull model is somewhere on this forum, where the RSSI value is requested based on a timer (Cron)

That's great info. Thanks!

[papa]

Yes, thanks, CompuTourist, for documenting the data acquisition. Personally, I choose what kinds of data I want to be updated frequently & uncomment sending only those device in the DHT End Node sketch list that starts around line 219. For me, it does not matter how frequently nodes send data as long as it does not bog down the network (which my network of a dozen devices did not do). Granted you'll see a lot of data on the serial monitor in debugging mode & in the OpenHAB cmd console, but not in the OpenHAB user interface shown in your browser.

As CompuTourist says, in OpenHAB rules config file (coordinated with things in the items config file), one can schedule a time frequency for data to be pulled less frequently than the node sketch push frequency. If you schedule that way, comment out sending the corresponding device in the list around line 219.

[lewishollow]

Sorry about the long delay. Work and other commitments make it so that the time I have to devote to these projects comes in fits and starts.

So I was able to set up a node using all of the components from the original instructables tutorial for the so-called uber node - DHT22, photoresistor, MQ2 sensor and flame sensor.

However, I basically rewrote the node code entirely. I grouped the various types of sensors into classes and moved them out into libraries so that the main node code could stay nice and clean. Adding sensors is now as easy as declaring the instance of a given sensor globally, and then instantiating them with the appropriate args for the contructor in the setup function. For special handling, you can also write short functions to get the values you want to return and pass them as callbacks. I'm still testing all of the various device types (I'm finding and fixing small bugs in my library code), but overall it's SO much easier to read and maintain.

If you guys are interested in seeing it, let me know.

[papa]

Sure, document what you've done. The more documentation, the merrier.

If you can document a so called Uber node working reliably, that might be a first here.

You might compare what you're doing with what CompuTourist has provided at github.com/computourist/RFM69-MQTT-client/archive/master.zip

Also compare what you've done with a library & classes in this folder from that zip file:

RFM69-MQTT-client-master\Relay end node

[camblonie]

Sounds good to me.