|
Post by zanyhunter on Apr 16, 2018 3:32:45 GMT
As of a few hours ago, after months of off-and-on troubleshooting, I finally got a successful and stable connection between a bare-bones end node and the gateway. I am now able to read the RSSI and Voltage values from within OpenHAB2. I was so excited! However, using the My.items provided by Mr. Papa, I tried actuating the ACTOR switch (D9) on the node using OpenHAB. I see the gateway's serial output display "MQTT-Topic: home/rfm_gw/sb/node02/dev16", however the node never sets the output to high and always returns the MQTT message "home/rfm_gw/nb/node02/dev16: OFF". I already uncommented "#define ACTOR" and even tried some of the other relay ports (dev 17-20), however their states never change no matter how I manipulate the Items config. My current Switch code is: Switch Act_Node02 { mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:default::]", mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:*:default]" }
Is there something I'm missing? I feel like I'm so close! Thanks in advance!
|
|
|
Post by zanyhunter on Apr 16, 2018 3:48:11 GMT
I just noticed something really strange. If I look at the serial monitor of the gateway, all is happy. Receiving voltage, RSSI, and current switch states. But, if I look at the serial monitor on the end node, it continuously says "no connection". Does that mean that it is only sending data, but not receiving it?
|
|
|
Post by greginkansas on Apr 16, 2018 21:36:06 GMT
I have this on my two way items.
Switch window_switch_01 "window Switch " (LEDStatus) { mqtt="<[mosquitto:home/rfm_gw/nb/node04/dev16:state:default::]", mqtt=">[mosquitto:home/rfm_gw/sb/node04/dev16:command:ON:ON],>[mosquitto:home/rfm_gw/sb/node04/dev16:command:OFF:OFF]" }
|
|
|
Post by papa on Apr 18, 2018 0:19:57 GMT
zanyhunter, welcome, sorry you having trouble with DIY Home Automation via RFM6 radios. Most of us do at the beginning.
I am traveling at the moment & will have some set up time when I arrive, but I'm taking some of my end of day time to give you some response.zanyhunter: "My current Switch code is: Switch Act_Node02 { mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:default::]", mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:*:default]" }" I rechecked my code. You are using the same mqtt binding code as I use for several nodes & they work just fine. I believe I learned doing this item with a double binding (the first checks the device's status & the second passes any commands to change status) from greginkansas. I also believe that the version greg gave you is a longer version of doing the 2 mqtt bindings I provided.zanyhunter: "I finally got a successful and stable connection between a bare-bones end node and the gateway. I am now able to read the RSSI and Voltage values from within OpenHAB2." papa: That does sound promising.zanyhunter: "I just noticed something really strange. If I look at the serial monitor of the gateway, all is happy. Receiving voltage, RSSI, and current switch states. But, if I look at the serial monitor on the end node, it continuously says "no connection". Does that mean that it is only sending data, but not receiving it?" papa: That is strange. Without knowing more, I can only guess what would cause that & ask questions that may seem to have obvious answers ... When you get the strange results are BOTH the Gateway & the Node powered (via computer USB or wall adapter) AT THE SAME TIME?
zanyhunter: "I tried actuating the ACTOR switch (D9) on the node using OpenHAB. I see the gateway's serial output display "MQTT-Topic: home/rfm_gw/sb/node02/dev16", however the node never sets the output to high and always returns the MQTT message "home/rfm_gw/nb/node02/dev16: OFF". I already uncommented "#define ACTOR" papa: You said you got a working bare bones node (which is not yet wired for the Actuator used by the ACTOR code). From the later schematic in this post, did you add the wiring for D9: D9 to 100-220ohm resistor to long LED pin & short LED pin to ground?zanyhunter: "tried some of the other relay ports (dev 17-20)" papa: use dev 16. Without other changes in the sketch, dev 17-20 would not work.
BTW what is the full name of the Gateway sketch you are using & the full name of the node sketch you are using.
Did you follow the instructions in this post about code libraries, especially this link to make two key edits in code libraries.
Let me know your answers to the above & maybe we can rule out some things while I consider the above & your next responses. About 23 hours from now, when we've stopped for the night, I'll look for your responses & we'll go from there.
|
|
|
Post by zanyhunter on Apr 19, 2018 3:43:23 GMT
Thank you greginkansas for your code. I tried that before, based on other examples, but unfortunately came to the same result.
Mr. papa, I'm powering the gateway via PC and end node via a 5v wall adapter. They are both powered on and have been reset simultaneously multiple times.
I flipped the radios around and now I'm getting the LED (which I did connect with a 220 ohm resistor to D9 and ground on the end node) to light up. Every once and a while, I will get random splurts of data from the end node on the gateway's serial output, like voltage or status of the ACTOR, but never all of it at the same time. I noticed it would give random data like that whenever I moved the wires around... I wonder if that's the problem. I'll be soldering the RFM69 module to my proto shield to iron out any possibilities tomorrow.
End node sketch name: computourist_node_v2.2MhC_choices_pub Gateway sketch name: RFM_MQTT_GW_25.1_pub1
I already edited w5100.h and ethernet.h according to your instructions.
Anyway, I ordered 2 more RFM69 radios yesterday and I already have a spare BUONO UNO, so if all else fails I can start from scratch. After experimenting, though, I feel like I'm so close already.
Thanks for devoting your time and energy to this community!
|
|
|
Post by papa on Apr 19, 2018 9:55:40 GMT
zanyhunter: "I noticed it would give random data like that whenever I moved the wires around... I wonder if that's the problem"
papa:could be you have a short or loose connection somewhere. RFM69 radios are a bit power hungry & could act up if not getting steady power. Often some little thing is the final problem to solve. I also believe you are close.
Thanks for the updates on your construction & programming & library edits. Those should be right.
You are welcome. I'll let you know if I think of other things to check.
|
|
|
Post by zanyhunter on Apr 19, 2018 23:22:37 GMT
I tried resoldering every wire in that radio and soldering them to my UNO, but I still had the same results. For the time being I am going to declare that radio dead. I stumbled across a spare radio while looking through spare parts, so I soldered wires to it, inserted it into my UNO, and BAM! Solid connection both ways. Works without a hitch! I modified the multi-choice end node sketch and now I am operating two garage doors from it.
Thanks a lot for your help!
|
|
|
Post by papa on Apr 21, 2018 13:47:08 GMT
Excellent, zanyhunter. You're welcome. I'm glad you got things working. That's a powerful feeling, isn't it. AND often things go better after getting the first RFM69 gateway & node to communicate with each other. I wish you well in adding other nodes.
By the way, as you did, having spare parts & substituting them one at a time is a good troubleshooting technique.
I'll mark this thread as "Solved"
|
|
|
Post by zanyhunter on Apr 24, 2018 23:57:43 GMT
Thanks! I finally found the problem with the original radio. Weird stuff was happening with it. I could move it around, vibrate it, or anything and it wouldn't connect. It was only when I brought my finger CLOSE or TOUCHED the top of antenna where it immediately responded. Turns out that the antenna length was barely a few millimeters too short to achieve a full quarter wave, and therefore couldn't transmit a signal! Lengthened the antenna and now I have a third node that works flawlessly.
|
|
|
Post by papa on Apr 25, 2018 12:11:48 GMT
good troubleshooting, zanyhunter. Your discovery about antenna length adds another thing for users to check when gateway/node communication is not reliable.
|
|