Beginner was stuck, now making progress.

[papa]

agecrabahaykubo: "Then I made some changes to the code/sketch and they started to talk."

Excellent! Looks like you successfully completed "Step B) Add a DHT Humidity & Temperature Sensor to the End Node" in the Building... thread.  I'm glad your got them to work using 3.3 volts for your RFM69 radios' sake.

In my experience it seems like we fiddle & fiddle with hardware & code & then at some point, Gateway & end node start to communicate. I wonder if they finally connect after a number of times rebooting Gateway & end node (similar to rebooting router & gateway to get DHCP / MQTT connection.

Now that Gateway & end node are communicating, you can move on further. FULL DHT End Node?? Other possibilities in the Multi-choice End Node Sketch with schematics documentation for them in other threads?? ?? Your experience so far should enhance your possibilities of success & decrease frustations.

I'll compare your code changes with the originals & see what that might mean. Thanks for reporting your results & stay in touch.

[agecrabahaykubo]

Thank you papa! I'm going to make the full DHT node next still haven't receive the SSR yet.

One question though, should this be node02 not node01??

[papa]

You're right.  It should be Node02, not Node01.  Here's what I think happened. ...

        I looked at your code changes & see that ...
you changed radio.initialize(FREQUENCY,NODEID,NETWORKID); // initialise radio
   to radio.initialize(FREQUENCY,GATEWAYID,NETWORKID); // initialise radio

I don't believe you changed anything in the following quote. (The original already said ...(GATEWAYID...)

    here's the other line
void txRadio() // Transmits the 'mes'-struct to the gateway
{
...
if (radio.sendWithRetry(GATEWAYID, (const void*)(&mes), sizeof(mes),5)) {

This "success" is very curious. I'm not as clear about coding for the RFM69's as I'd like to be.  However, l I believe your results come from this: Your first indicated change from NODEID to GATEWAY initialized the RFM69 radio as being Node 1 (from the GATEWAYID of 1). The second area where you thought you made a change (but did not) sends a msg to GATEWAYID (namely Node 1). From what I understand, the way you code the sketch causes it to identify itself as Node 1 to be sent to Node 1 (Gateway).

In spite of the above, your last pic above indicates the Gateway successfully received what the End Node sent. MQTT messages reported by the Gateway indicate the sending node is 1, NOT 2 as you saw. I'm surprised that it did not cause a conflict because the Gateway is in effect Node 1 also. If you left the code the same to program MORE end nodes, I believe you would get conflicts because no node should share the same ID as another especially with the Gateway (Node 1).

I wonder if your "success" happened from something else ... maybe the RFM69 radios got connected right & were able to send / receive & your code change squeaked by because only two "nodes" had the same ID.  Maybe there is good news in this. (End node RFM69 & Gateway RFM69s can work, but maybe have some connections that get loose)

What to try now??  I suggest ... Handle the end node carefully so connections will not change. Where you reported the first change from NODEID to GATEWAYID, change it back to NODEID. Reprogram the end node & see if it & gateway connect.

[agecrabahaykubo]

papa, I change the variable code back to NODEID but I got the "No connection" result again. I wonder where I messed up. Anyways I'm going to look at the code and see what I can find.

Here's the node 2 serial monitor result.

[papa]

agecrabahaykubo, you said, "I change the variable code back to NODEID but I got the "No connection" result again."

        Then you showed a pic of node 2 serial monitor result which looks good. ??

    Do you mean that you get results like that pic THEN you get "no connection" ??   Please confirm on that.
Because if that's what you mean, that means Gateway & end node ARE communicating for a while & then the communication stops for some reason.

        Again please confirm before I go further.



Caution:  Only change a little (hardware or software) at a time, keep track of what you change, & then test.

Don't change much at a time or one can get lost.

[agecrabahaykubo]

Do you mean that you get results like that pic THEN you get "no connection" ?? Please confirm on that.

I did not post the image of serial monitor result of Node 2 "No connection" because I posted it before in my previous frustration post. This was after I change the code back to NODEID that was the result


This one is from the variable code change GATEWAYID, Node 2 (earlier post) showing correct node id.


This is from RFM gateway (DEBUGRADIO) latest result, showing incorrect node id??



Thanks

[papa]

    OK, I figured out the difference in NODE designations in the last two pics (in your post just above).
In the last pic of GATEWAY serial monitor results, each line starts with "1" because your code change has the End Node radio say its from Node 1 (Gateway ID)

In the next to last pic above (end node serial monitor result), it says Node: 2 because in the end node sketch you left NODEID as 2 & lines 552-554 still DISPLAYS NODEID on the serial monitor.

Even though both Gateway & end node had NODEID of 1, there was only one subscriber (listener), the gateway, & only one publisher (sender), the end node.  So that's probably how the gateway & end node communicated.  However, confusion & conflict could soon occur if the gateway sent commands or other end nodes were added.
    ===============================

As I've said, it looks like with your code change, Gateway & End Node communicate, but that code change cannot be sustained for multiple end nodes.

Maybe you're right to wonder about some code problem (from me or you) in Gateway &/or End Node sketches that you're using.

How about this? Save your current sketch versions (in case you need to return to them), but try later versions of both sketches (below). You should know now which lines to customize.

    RFM_MQTT_GW_24_pub4.ino (15.75 KB)   << Here's a fresh Gateway sketch version whose output will look a little different than your last pic above. (I'm currently using it successfully myself)
            Customize it to your situation
Try DEBUG mode first with only the gateway & then with programmed & running end node.  Then try DEBUGRADIO

   computourist_node_v2.2Mg4_choices_pub.ino (62.9 KB)   << Here's a later Multi-choice sketch version which I'm using currently (though for another type of node).
                Customize it to your situation, (but please don't change NODEID to GATEWAY ID in that one line):   HT, CELS, Encryptkey, frequency, DEBUG, H

Let me know what results you get.  We'll beat this yet.

[agecrabahaykubo]

Mar 15, 2017 2:28:59 GMT papa said:

    OK, I figured out the difference in NODE designations in the last two pics (in your post just above).
In the last pic of GATEWAY serial monitor results, each line starts with "1" because your code change has the End Node radio say its from Node 1 (Gateway ID)

In the next to last pic above (end node serial monitor result), it says Node: 2 because in the end node sketch you left NODEID as 2 & lines 552-554 still DISPLAYS NODEID on the serial monitor.

Even though both Gateway & end node had NODEID of 1, there was only one subscriber (listener), the gateway, & only one publisher (sender), the end node.  So that's probably how the gateway & end node communicated.  However, confusion & conflict could soon occur if the gateway sent commands or other end nodes were added.
    ===============================

As I've said, it looks like with your code change, Gateway & End Node communicate, but that code change cannot be sustained for multiple end nodes.

Maybe you're right to wonder about some code problem (from me or you) in Gateway &/or End Node sketches that you're using.

How about this? Save your current sketch versions (in case you need to return to them), but try later versions of both sketches (below). You should know now which lines to customize.

       << Here's a fresh Gateway sketch version whose output will look a little different than your last pic above. (I'm currently using it successfully myself)
            Customize it to your situation
Try DEBUG mode first with only the gateway & then with programmed & running end node.  Then try DEBUGRADIO

      << Here's a later Multi-choice sketch version which I'm using currently (though for another type of node).
                Customize it to your situation, (but please don't change NODEID to GATEWAY ID in that one line):   HT, CELS, Encryptkey, frequency, DEBUG, H

Let me know what results you get.  We'll beat this yet.

Ok. Will try this and let you know the results. Thanks.

[agecrabahaykubo]

papa - A good result from your new code. Maybe I got lost where I made the changes. I was just trying to figure out and making them connect to each other (RFM radio). Anyways, thanks again for your help and time to answer my questions.

Here's the result of RFM Gateway.



I got the SSR yesterday and made it. I still have the ethernet shield box so I recycled it.



Moving on to making Full DHT node. YES!

[papa]

YES, YES, YES. A BIG, BIG HOORAY. You're welcome.  I'm so thrilled for both of us that it worked. I suspect your editing the ethernet.h & w5100.h files were a key part of success. You may want to back up those edited files somewhere outside the Arduino IDE folders. When you install a later version of the Arduino IDE, you likely lose the edited files.

Yes, one can get lost in the code. Good to learn by experimenting, but important to make small changes at a time & mark where we made the changes & then test. I recommend always saving a copy of a sketch version that's worked so far & use a slightly different sketch name for experiments.

Good adaptation on an "insulator" box for the SSR. Though for safety's sake, you & I both need to remember that our insulation is NOT waterproof. I've considered painting my cardboard with a sealant. Instead I do not use the SSR around water.

I look forward to hearing your progress with the FULL DHT End Node. One of its challenges is where to get or mount the push button. As you may have seen, I used the spare push button of an Arduino shield.

[papa]

    A warning about building the SSR version of the Full DHT End Node: The Building... thread I wrote documents the LED version of the DHT node.

When I removed the LED & resistor & instead connected to the SSR's DC input, that was maybe enough to light the SSR's LED, but did not necessarily cause the relay to switch on the AC.
        I suspected the SSR was not getting enough current from the 3.3 volt pin.
It's worked fine since I use the Arduino 3.3 volt output & a transistor to send 5 volts to the SSR which is able to switch on the AC.

    ^^ I documented this in the Success... thread where you probably saw my crude, but pretty effective cardboard SSR insulator.

[agecrabahaykubo]

papa said:

YES, YES, YES. A BIG, BIG HOORAY. You're welcome. I'm so thrilled for both of us that it worked. I suspect your editing the ethernet.h & w5100.h files were a key part of success. You may want to back up those edited files somewhere outside the Arduino IDE folders. When you install a later version of the Arduino IDE, you likely lose the edited files.

Yes, one can get lost in the code. Good to learn by experimenting, but important to make small changes at a time & mark where we made the changes & then test. I recommend always saving a copy of a sketch version that's worked so far & use a slightly different sketch name for experiments.

Good adaptation on an "insulator" box for the SSR. Though for safety's sake, you & I both need to remember that our insulation is NOT waterproof. I've considered painting my cardboard with a sealant. Instead I do not use the SSR around water.

I look forward to hearing your progress with the FULL DHT End Node. One of its challenges is where to get or mount the push button. As you may have seen, I used the spare push button of an Arduino shield.

Backing up the files now, for Pete's sake. Wait, what... later version of Arduino IDE?

I used to copy the line where I made the changes and paste it in the next line and put "//" to comment the original.

Yes I agree cardboard box isn't a good insulation for SSR, we'll need to find a plastic box in the dollar store maybe, we need some for the arduino's as well.

I almost gave up on this project and lost a lot of sleep just making the nodes to communicate, kudos to you papa for all your hardwork in documentation and helping us beginners.

I'll keep in touch for sure.

[papa]

" what... later version of Arduino IDE?" papa: any Arduino IDE version later than your current one.

Thanks for the kudos. Your success & some thanks are nice returns for volunteers like me.

One more thing I would appreciate down the line: Please contribute to the forum. If you see some other beginner struggling on this forum & you think you might notice something that could help, please contribute (even a "hang in there, I struggled, too."). If you find a way (your own or someone else's) to advance this project (even in a small part), please contribute.

Other perspectives besides mine would add to this forum.

[agecrabahaykubo]

Mar 15, 2017 15:05:00 GMT papa said:

" what... later version of Arduino IDE?" papa: any Arduino IDE version later than your current one.

Thanks for the kudos. Your success & some thanks are nice returns for volunteers like me.

One more thing I would appreciate down the line: Please contribute to the forum. If you see some other beginner struggling on this forum & you think you might notice something that could help, please contribute (even a "hang in there, I struggled, too."). If you find a way (your own or someone else's) to advance this project (even in a small part), please contribute.

Other perspectives besides mine would add to this forum.

Certainly papa, I will be more than glad to contribute here and to someone that needs help with this project.

[papa]

        Copying stuff discussed in private message in case others might benefit from the discussion:

agecrabahaykubo:  papa, I have been searching high and low where to find openhab.cfg in my raspberry pi 3, honestly I can't find it! All I can see are the folders (item, persistence, sitemaps etc.)

Is there really an openhab.cfg in the new openhab 2.0?     Thanks.

[papa]

agecrabahaykubo: ... Is there really an openhab.cfg in the new openhab 2.0?

Disclosure: I had OH 2 working on a Linux laptop, but then the laptop's hard drive started acting up. I backed up my files, but now I'm back to OH 1.x on a Pi for a while. My experience with OH 2 is migrating from 1.x to OH 2 & then back again. So the OH 1 & 2 boundaries are sometimes a little blurred for me.

That said, I remember & also looking at the OH 2 config files I backed up, openhab.cfg contents are broken into smaller files that end with .cfg. You'll find those in a /services folder. In the /services folder runtime.cfg & addons.cfg are higher level .cfg files. Then there are individual .cfg files for bindings (like mqtt.cfg), peristence (like mapdb.cfg).

If you're configuring OpenHAB 2 without migrating from OH 1.x, I recommend you try the official OH2 Beginner Tutorial. (The migration tutorial was pretty good. I've not looked much at the beginner tutorial.)

I believe the beginner approach leans to using a PaperUI interface more than editing .cfg text files like we've done for OH 1.x

If you're looking to use (in OH 2) some OH config entries that might be from OH 1, look at this piece of official docs on migrating from 1 to 2 which handles the (few?) differences between the 2 versions.

Maybe the above will get you started.

I'd like to hear how helpful you find the OH 2 Beginner Tutorial

[agecrabahaykubo]

papa - I see now the .cfg files that are broken to smaller files and no openhab.cfg. I edited a few configs like the weather and mail, the others I am still finding my way.

BTW, something weird is happening with the DHT node results, the signals are intermittent. I haven't done anything just shutdown/power them down last night.

Here's the screenshot of Node2 SM.

I temporarily remove the my.rules in the config(rules folder) and the serial monitor results are back to normal. I guess it is about the timing of sending the data to openhab?

Thanks.

[papa]

Yes, agecrabahaykubo, it is weird what we see in your SM output. All the selected Node 2 devices should report in a group: 2, 4, 9, 48, 49.

Also we should not be seeing "Node: 1" Looks like that is often interrupting the flow of Node: 2 device messages.

I just saw your addition about My.rules. (Good thing to check.)  So apparently a rule was trying to communicate with Node 2 via the gateway (Node 1).

Still I don't believe a rule should cause that kind of interruption in the message output.
     May not have been written correctly.

Maybe your rule tried to access a device not yet installed on Node 2 (push button?? or ACTOR that trips LED or relay ??)

In your My.items & My.rules & My.sitemap files you might for the time being disable entries that relate to devices that are not 2, 4, 9, 48, or 49).  That is, put // at the start of the entry line.

[agecrabahaykubo]

Here's the completed RFM Gateway and Full DHT Node.




Full DHT Serial MOnitor result



Openhab configuration next. :

[papa]

Congrats, agecrabahaykubo. Looks like you used the shield I recommended & maybe the shield's spare push button. Right?

I cannot tell from the pic ... how are you triggering the relay? With transistor & 5 volts or with 3.3 volts from Arduino D9?

I see the relay's LED is lit so it was triggered? Did the relay also trigger an AC device?

[agecrabahaykubo]

Mar 16, 2017 19:18:57 GMT papa said:

Congrats, agecrabahaykubo. Looks like you used the shield I recommended & maybe the shield's spare push button. Right?

I cannot tell from the pic ... how are you triggering the relay? With transistor & 5 volts or with 3.3 volts from Arduino D9?

I see the relay's LED is lit so it was triggered? Did the relay also trigger an AC device?

Yes, I got the shield you recommended. It took 2-3 weeks before it arrive. Yes the shield's spare button is working as well.

I connected the relay +/- to resistor(female header) & 5v. I guess the LED was lit when I manually triggered the button, not so sure if it trigger the gateway which was connected to the power outlet.

[papa]

agecrabahaykubo: "I connected the relay +/- to resistor(female header) & 5v."

If you connected relay + to 5V & relay - to GND that would trigger the relay by itself.

In order for OpenHAB / Arduino to trigger the relay via the push button or a virtual switch on a browser interface (as you want) ...

    1) relay + (with NO resistor) must be connected to D9 OR
    2) Or use D9 & 5v & a transistor as shown here especially in the schematic.

        ^^ With option 1) D9's 3.3 volts might be able to trigger the relay's LED AND the AC device
                    But if it does NOT trigger the AC device you need to do option 2)

PS In the Building... for Beginners thread, I added some notes about OpenHAB installation that distinguishes between what applies to OpenHAB 1.x & what applies to OpenHAB 2. These notes may not be complete, but I hope they will give some hints to help along with the OH2 official documentation.

[agecrabahaykubo]

Update: Been playing/learning lately about Openhab, I also added a motion sensor + extra breadboard for wiring to the DHT node.

Here's a screenshot from OH2 app.



Sometimes there is no data coming from weather bindin like today, just not consistent. Not complaining though still learning.

[papa]

Coming along there, young Jedi, congrats. Good to hear your current experiences.

"Not complaining though still learning." That's the way to move forward.

"no data coming from weather bindin like today, just not consistent"

When we make changes to .items files & re-save them, our items may revert to unitialized (& show up as "-")

Some things take longer than others to refresh uninitialized items.
In services/weather.cfg, take a look at the updateInterval setting [in minutes]

You can change updateInterval to be more often. However, be careful ... because frequent taps on a Wunderground service can put us beyond our daily limit for the no pay level.