|
Post by papa on Jun 21, 2016 18:51:33 GMT
?? How to Use More Than One RFM69 Network ??
When I tested a Gateway 2.4 with a Gateway 2.4 compatible DHT End Node, I did not want to suspend or interfere with my Gateway 2.2 Network. So I tried creating a second RFM69 network of the new 2.4 Gateway & one DHT End Node (including push button, LED/Relay, & DHT11 sensor) using the Gateway 2.4 option. In the Gateway 2.4 Sketch, I gave it a different MAC & address & default IP address than the first gateway. In the Gateway 2.4 Sketch & OpenHAB items, I changed the start of the MQTT topics from home/rfm_gw to hom2/rfm_gt. When I shut down the first, existing gateway & thus its network, things worked well in the Gateway 2.4 network: I can toggle the LED with the node button or OpenHAB’s UI (& it updates properly on the UI); also temp, humidity, RSSI, & voltage all report fine on the UI. However, when both gateways are powered, switch related topics do not work so reliably. Pushing the DHT End Node's button does work to toggle the LED. Looks like temp, humidity, RSSI, & voltage may update on the UI. However, pushing the node button does not necessarily update the UI switch status AND clicking the UI virtual switch does not necessarily toggle the node LED. I also notice that the second Gateway’s (2.4) MQTT LED turns off sometime, suggesting the Gateway is losing its connection. In another context, some of us discussed spreading network loads by using more than one network. So who can help me properly set up a second RFM69 network?
|
|
|
Post by greginkansas on Jun 22, 2016 0:37:16 GMT
This seems like the first place to start -
I also notice that the second Gateway’s (2.4) MQTT LED turns off sometime, suggesting the Gateway is losing its connection.
Swap gateway's and see if it changes
|
|
|
Post by computourist on Jun 22, 2016 6:02:09 GMT
Have you changed your network-id and encryption key on the second network ?
|
|
|
Post by papa on Jun 23, 2016 1:07:51 GMT
Computourist, I changed the network id #, but NOT the encryption key. I will try the latter.
Greg, I may try building a gateway with a different Arduino & a different w5100 Ethernet shield.
|
|
|
Post by papa on Jun 23, 2016 3:19:37 GMT
Computourist, I tried also changing the encryption key used by the added gateway & the node that relates to it. So far I've changed the Network ID, the MAC address, the encryption key & the mqtt topic for the new gateway-node.
Greg, I tried building a gateway with a different Arduino & a different Ethernet shield.
Neither seem to make any difference. So far using one network is much more reliable.
As before, having the added gateway connected to USB, I can see (on the Serial Monitor) that the gateway & node are communicating. The node's Temp, Humidity, voltage, & RSSI seem to reach the OpenHAB UI, but push button action does not always reach the UI switch & likewise clicking the UI switch does not always reach the node LED.
Again it seems gateway & node are communicating but data is not getting reliably between OPENHAB (UI or logging) & the gateway-node network.
The added gateway is near my mqtt computer & I can see the mqtt LED going off (connection lost) sometimes briefly. It also seems that the data flow in logging slows down when the added gateway is connected in addition to the first gateway. So I wonder if the gateways are taking turns disconnecting each other from mqtt.
Do I need to have two brokers defined in openhab.cfg? If so, how do I do that?
|
|
|
Post by computourist on Jun 23, 2016 5:47:25 GMT
Hi papa , Only one broker is needed. The whole idea is that Mosquitto is a broker for a multitude of clients. I use Mosquitto for an RFM_gateway and ESP nodes: no problem. The connection to the broker should not go down. If it does, you could have a network problem. Do you see a reconnection message on the serial monitor ? Try to figure out where the bottleneck is: - Radiolink: use the serial port to see messages being handled. (seems OK according to your post) - IP-link: the link to the MQTT broker should not go down. Check the Serial Monitor for problems. - Mosquitto: connect with an external client (f.e. MQTTlens) to see if all messages are handled correctly by the broker. Make sure the max number of clients is not a problem (set in /etc/mosquitto/mosquitto.conf) - Openhab: what type of host machine are you using? A Raspi might get slow if load increases. The logging rate slowing down might indicate a capacity problem on the host. Try the "top" command to see CPU load and memory usage. Success..
|
|
|
Post by papa on Jun 23, 2016 18:17:23 GMT
computourist, thanks, for more suggestions. I will interleave my responses with your questions / suggestions:
Only one broker is needed. The whole idea is that Mosquitto is a broker for a multitude of clients. I use Mosquitto for an RFM_gateway and ESP nodes: no problem. Good to know. In fact before you answered this, when I tried adding a broker, I did see broker disconnections in the logging.
Have you tried more than one gateway, with what results?
The connection to the broker should not go down. If it does, you could have a network problem. Do you see a reconnection message on the serial monitor ? Yes, broker disconnects are obviously not good. Watching both the original gateway & the added gateway, I see their mqtt LEDs go off some times.
I just re-activated MQTT debugging on the added gateway: Now the problem is worse. When the added gateway is connected to USB: SM shows MQTT connects & no disconnects, but mqtt LED blips VERY briefly. SM shows some MQTT msg, incl device 09: 6 [message failed] Sometimes node push button toggle gets through & often not. Logging data pretty much halts when both gateways are connected. Resumes when added gateway is disconnected. added 6/24/2016: When both gateways are running, both their mqtt LEDS blip rapidly & logging messages bog down.
Try to figure out where the bottleneck is: - Radiolink: use the serial port to see messages being handled. (seems OK according to your post) This was good before, but not so good since the problem got worse. - IP-link: the link to the MQTT broker should not go down. Check the Serial Monitor for problems. Again, no disconnect messages show on SM. - Mosquitto: connect with an external client (f.e. MQTTlens) to see if all messages are handled correctly by the broker. Not done yet. Make sure the max number of clients is not a problem (set in /etc/mosquitto/mosquitto.conf) Is this what you mean? C:\Program Files (x86)\mosquitto\mosquitto.conf: # The maximum number of client connections to allow. This is # a per listener setting. # Default is -1, which means unlimited connections. # Note that other process limits mean that unlimited connections # are not really possible. Typically the default maximum number of # connections possible is around 1024. #max_connections -1 - Openhab: what type of host machine are you using? A Raspi might get slow if load increases. The logging rate slowing down might indicate a capacity problem on the host. I'm running OpenHAB on a Windows 7 laptop.
Try the "top" command to see CPU load and memory usage. Say more. I'm not sure what you mean.
I've now changed the Arduino, the Ethernet Shield & the radio for this gateway. So far having 2 gateways has been less reliable, not more.
I just disconnected the original gateway & now the added gateway connects to mqtt & stays connected. MQTT messages show just fine on the Serial Monitor. Node's push button toggles LED & UI switch just fine. Clicking the node's UI switch toggles the node's LED just fine.
So bottom line, both gateways & the node or nodes in their network work fine when only one gateway is running, but there's problems when both are running & connected to Ethernet network.
|
|
|
Post by greginkansas on Jun 24, 2016 1:21:02 GMT
One thing is the Mosquitto server on wireless?
|
|
|
Post by papa on Jun 24, 2016 17:40:10 GMT
No, Greg, the Mosquitto Server is not on a wireless machine. It's on a Windows 7 laptop & is connected to my house network via an ethernet cable.
I avoid a wireless host for Mosquitto because early on that did not work well for me.
|
|
|
Post by greginkansas on Jun 25, 2016 0:08:17 GMT
WELL, keep looking I do have a WEEWX "weather server" sending msgs to my Mosquitto Server and the gateway works fine.
|
|
|
Post by papa on Jun 25, 2016 1:44:24 GMT
I am still looking, Greg.
Anyone out there, Who has more than one Gateway AND where & how did you vary settings between the two gateways?
Did that work or do the two gateways take turns connecting & disconnecting from MQTT?
PS my two gateways (& their networks) have different gateway id, different network id, different encryption key, & different mqtt topic.
|
|
|
Post by computourist on Jun 25, 2016 12:04:49 GMT
This looks like a network problem. Do both gateways have different MAC-adresses and IP adresses ?
I have a 2.4 gateway running and several ESP8266-based nodes reporting to Mosquitto without problems.
BTW: "top" is a linux command to show CPU utilization.
|
|
|
Post by papa on Jun 25, 2016 12:41:12 GMT
Thanks for more suggestions, computourist. In response:This looks like a network problem. Do both gateways have different MAC-adresses and IP adresses ? Yes, as shown in the following pic, each gateway has a different MAC & IP. I have a 2.4 gateway running and several ESP8266-based nodes reporting to Mosquitto without problems. I surmise that shows that shows Mosquitto can have more than one connection. However, does that necessarily show that two gateways can run at the same time.
I'd like to hear if someone has successfully connected two gateways to MQTT & how they did it.BTW: "top" is a linux command to show CPU utilization. Oh, I'm not so conversant with Linux as Windows (where I'm running OpenHAB/MQTT. Using Windows task manager, I looked at top CPU utilization & saw nothing that grabbed CPU at high rate.
|
|
|
Post by papa on Jun 26, 2016 2:02:55 GMT
My original RFM69 runs as Gateway 2.2 compatible. The newest gateway & its one node did run at Gateway 2.4 compatible. Mostly to cross off trying it, I changed the second network to Gateway 2.2 compatible. As I expected, same problems continue, no improvement.
To my query at LowPowerLab forum, TomWS, Global Moderator, Hero Member replied: "ISTM that the problem is on the LAN/MQTT side of the gateways. I've had three gateways with different network IDs, same encryption, same frequency, running for a couple of years at my site. Collisions on the RFM69 side occur but don't show up in the recvd data and seem to iron themselves out with no more than 3 tries."
From what I've seen, I also wonder if something is still needed for both gateways to stay reliably connected to MQTT at the same time.
Computourist or anyone, have you had two gateways connected to MQTT at the same time, with what results? What settings did you use?
Computourist, could you look at the Gateway's MQTT code to see if you can see what might cause my problems?
|
|
|
Post by computourist on Jun 26, 2016 19:58:07 GMT
Hi papa , I do not have multiple gateways running. In the end, the gateway is just an MQTT-client, and I have several MQTT clients connected to my broker: the RFM gateway, several ESP-nodes and of course Openhab. The RSP nodes run simular code as the RFM gateway. The idea for a broker is to be the middleman between multiple clients, so this is how it is designed to work. The fact that your gateways are not working simultaneously points at some interference, either on network or on MQTT layer. Try to diagnose and pinpoint the root cause: - are both gateways using different topics, both to send (northbound) and subscribe (southbound) ? - do you see interruptions on the network layer ? Try pinging the gateways and look for lost packets. - do your problems always occur, even if there is no MQTT taffic (no active nodes), that would point to the network. - install an MQTT client to inspect MQTT traffic. MQTT.FX has possibilities to monitor and log the broker. Without such a client it is impossible to see whether Mosquitto is behaving as it should. You should really try to narrow down the possible cause of your problem.
|
|
|
Post by papa on Jun 26, 2016 22:56:41 GMT
OK, I solved it. It should be pretty simple to solve if one knows what they are doing about MQTT, which I don't know much. I just knew some things connect, then some thing subscribes & some things publish to the subscribers. I'm getting to know the node code possibilities much more, but I have not done much with gateway code because to this point (after a few settings covered), it has worked. Remember I said, "I'm definitely not God," even in this niche of electronics where I've posted a bunch. However turn g-o-d around to d o g & I am dogged about analyzing, asking help, & trying things until I often find a solution or a dead end. As a result, I now I know a little more about MQTT. There were clues embedded in the communication on this forum & a couple others: I kept saying it seemed like a problem mainly with MQTT with the two gateways fighting each other & knocking each other off. In a general sense, some of you would talk about MQTT clients. So the solution came down to the one necessary MQTT thing that I did not have different on the two gateways. In the Gateway sketch, in the line: char *clientName = "RFM_gateway"; // MQTT system name of gateway
the second gateway needs ... a different clientName, like "RFM_gatew y2. The gateways were fighting because they kept trying to connect with the same clientName. Now I have a version 2.2 Gateway plus its several nodes AND a version 2.4 Gateway plus its one node both connected to the same MQTT server & the same openHAB UI & its all working together just fine. Now I see that one can spread the load of node communication & expand the network capability by using more than one gateway, more than one MQTT client.
|
|
|
Post by greginkansas on Jun 27, 2016 1:27:56 GMT
Nice glad you found it.
|
|
|
Post by computourist on Jun 27, 2016 6:00:30 GMT
Good you solved this one. Just out of curiousity: do you have both gateways on the radio network defined as node 1 ? This should be no problem when using different network ID's. If not, could you please try this, just to make sure.
Thnx..
|
|
|
Post by papa on Jun 27, 2016 16:16:53 GMT
Computourist, even when I had both gateways on dif network IDs, did not seem to work to make both gateways into node 1 so I made # 2 gateway into node 250. That works well.
|
|
|
Post by papa on Dec 27, 2016 20:05:15 GMT
Adding More RFM69 Gateways & Networks Updated Dec. 16, 2018
As a trial, I built a third gateway & set up a third RFM69 Network connected to my MQTT broker. My other two gateways/networks handled their radio traffic fine. I was building & testing this network to move to another address. Making the third network unique, I could run it alongside the others without conflicts. In case others need or want it, I’ll outline here what works for more than one gateway & network. For each network, build one gateway & at least one node. To do this, see this thread. If using a Buono Uno to build a gateway, be sure to disable the VCC pin in the ICSP cluster. Otherwise the Buono supplies too much voltage for your RFM69 radio. Customizing the sketch for each gateway (RFM_MQTT_GW_xxx.ino):
For the first gateway/network, your main customizing is choosing the frequency of your RFM69 radio, defining whether your RFM69 radio is “high power” (“h” in the radio’s part ID), & defining your 16 character ENCRYPTKEY. In the computourist original, the gateway’s NODEID is 1 & the NETWORKID is 100. Likewise for this gateway, the MQTT topic starts with /home/rfm_gw/ & *clientName = "RFM_gateway" To connect to this gateway & its network, an end node (via its sketch) must define GATEWAYID as 1, NETWORKID as 100, & the same ENCRYPTKEY as the gateway.
For the second, etc. gateway/network, customize (as usual & as necessary): RFM69 frequency & “high power” or not. Beyond this, the sketch of each additional gateway needs a NODEID, NETWORKID, & ENCRYPTKEY unique & different from the other gateways. In the gateway sketch, change the clientName (for example, from RFM_gateway to RFM_gatewy2). To connect to each gateway & its network, an end node (via its sketch) must define GATEWAYID, NETWORKID, ENCRYPTKEY, & clientName the same as its intended gateway.
In the OpenHAB config files, each gateway & working items for nodes in a gateway's network use the SAME subTopic. For the first gateway/network this is /home/rfm_gw/ To add a second network ...
In several gateway sketch locations, also change the start of the MQTT topic to make it unique. Search for /home/rfm_gw/ & replace it (for example, with /hom2/rfm_gw/). In OpenHAB config files, items for these nodes need to start with how the MQTT topic starts in the gateway sketch ( /hom2/rfm_gw/ if following the second gateway example above).
|
|
brump
Junior Member
Posts: 81
|
Post by brump on Dec 28, 2016 8:24:03 GMT
Papa, Good progress.
I have one problem with my system. I formatted my notebook and my gateway not connecting with MQTT Broker. I'm suspecting that the backup installation I used for windows 10 is corrupted.
|
|
|
Post by papa on Dec 6, 2018 17:11:07 GMT
Sketches to Use More Than One RFM69 Gateway Updated Dec. 16, 2018An RFM69 gateway handles incoming data & outgoing commands for all RFM69 nodes in its network. The gateway handles communication between the nodes & Mosquitto/OpenHAB. On one gateway, without noticeable problems, I've had up to 12 nodes which transmit data at least every 45-60 seconds. Some also transmit immediately after a status change. Depending on the number of nodes & the resulting amount & frequency of communication, a gateway will eventually reach saturation & possible dropped communication. A couple years ago, as described above, I worked through being able to have more than one RFM69 Gateway & Network. Many users should be fine with one gateway, especially beginners with a few nodes. They can just use their current ENCRYPTKEY for GatewayOne.
For those who may develop multiple nodes & experience congested communication, I have updated the Gateway & Node Choices sketches so one can choose to have up to three gateways/networks.
This post will have the latest choose_nodes sketch which includes options for using a second or third gateway.
|
|