|
Post by sam4205 on Feb 25, 2016 17:32:01 GMT
Hi Guys!
I have been a passive reader of this forum for last couple of months and have learned a lot here, thanks to all.
Special thanks to Computourist and Papa for their massive support and willingness to share with the group and newbies like me.
I have build the gateway and a node with relay for switching lights in my home. Here is the setup
Gateway - UNO/Ethernet shield with RFM69HW with logic converter and tweaks to handle the interrupt modification. Using the Gateway 2.3 version Node - Pro mini with RFM69HW, using the DIG version, with 4 channel Relay module
I am getting "No connection" messages frequently on my node and also the "Connection lost node #" from the gateway.
While troubleshooting, I have noticed the following- - When the Openhab sends multiple messages(quick sequence), the connection is lost. For example, we have a rule in Computourist base code, to read Temp and Uptime every minute. So when the node is processing this, either the first or the second message shows No connection message - When I toggle two buttons on my openhab(I have 4 buttons) in immediate sequence, then the node shows no connection message and also the gateway shows connection lost message
I noticed that in txRadio() function, there is a loop to try for 6 times and also the sendWithRetry has 5 RetryWaitTime, and with delay of 500. - I have modified the loop to have 4 times and also reduced the delay to 100. - This has helped a bit and reduced the connection lost messages, but still there are couple of messages popping up.
My plan is to build out multiple nodes in my house so I am trying to make a node version that is very stable without connection lost.
Could someone please help me on how to resolve this issue. Much appreciated!
Sam
|
|
|
Post by papa on Feb 25, 2016 18:18:16 GMT
You're welcome, Sam. Glad you've jumped in to active building & participation. Nice summary of what you've tried & the results. That's a good start on helping forum participants to help you. Based on what you included & not, I ask for more information to further the cause: Looks like you are using OpenHAB rules to PULL data (like temp & uptime) from the nodes. What node id (a number) did you assign to the DIG node? What temp sensor are you using on the DIG node & how did you wire it? What else is wired to the node besides RFM69 & DIG? LED? Push button? DHT or other temp sensor? I assume you have OpenHAB items that subscribe to that data, right? Please list sample items that subscribe to temp & uptime. Are you seeing data show up on the OpenHAB User Interface? I don't use DIG or Pro Minis. Having enough power on Arduino compatible devices can be a concern. For this reason, I've had to pare some things off my 3.3 volt Buono Uno nodes & supposedly they output more power than pro Minis. Trying to power the RFM69 radio, LED, push button, a temp sensor, & triggering a DIG might cause current issues that break connection. Perhaps powering the logic converters might contribute to this. Multiple button pushes might aggravate that. Are you using RFM_DIG_node_22.ino, namely the 2.2 version intended for Gateway 2.3? If you have a temp sensor installed, I recommend you try removing it & see what happens. Next if node has an LED, try removing it & see what happens.I don't need to use logic converters so can say little about them. Be sure you have wired them correctly. Looks like this discussion could be helpful. When we hear from you about the above, I may have some other possible areas to explore.
|
|
|
Post by greginkansas on Feb 26, 2016 0:16:04 GMT
While troubleshooting, I have noticed the following- - When the Openhab sends multiple messages(quick sequence), the connection is lost. For example, we have a rule in Computourist base code, to read Temp and Uptime every minute. So when the node is processing this, either the first or the second message shows No connection message I have seen this also. I do not send messages to close together you do not know what the gateway is doing, might be receiving. After putting a gap in sends I'm getting good sends. I noticed that in txRadio() function, there is a loop to try for 6 times and also the sendWithRetry has 5 RetryWaitTime, and with delay of 500. - I have modified the loop to have 4 times and also reduced the delay to 100. - This has helped a bit and reduced the connection lost messages, but still there are couple of messages popping up. I did the reverse more Ack time and sendWithRetry, RetryWaitTime to give more time to get msg out. Ack time helped the most I think.
|
|
|
Post by papa on Feb 26, 2016 0:49:58 GMT
Sam, tagging on to greginkansas about not sending messages too close together: Of course, you need OpenHAB to subscribe to messages to receive the data. I would avoid PULLING the data with a rule. Instead I would tell the node to send data every so often (this is set by TXinterval at line 88 of the DIG sketch). To send data from the devices: Around line 220, uncommented lines saying send[device] = true. For example,
send 0 = true // uptime send48 = true // temp However, for the DIG node I would avoid using send48.
I've had TXintervals of 20 or 30 seconds for several nodes & had no problems.
|
|
|
Post by sam4205 on Feb 26, 2016 3:04:34 GMT
Thank you papa and gregikansas, appreciate your quick and valuable help. papa, I have added my comments prefixed with "--" You're welcome, Sam. Glad you've jumped in to active building & participation. Nice summary of what you've tried & the results. That's a good start on helping forum participants to help you. Based on what you included & not, I ask for more information to further the cause: Looks like you are using OpenHAB rules to PULL data (like temp & uptime) from the nodes. What node id (a number) did you assign to the DIG node? -- Node ID is 8. I also had 7 in earlier version. What temp sensor are you using on the DIG node & how did you wire it? --I am using the Temp Sensor embedded to the RFM69. I don't need an accurate temp and didn't want to add another component. What else is wired to the node besides RFM69 & DIG? LED? Push button? DHT or other temp sensor? -- Push buttons. I assume you have OpenHAB items that subscribe to that data, right? Please list sample items that subscribe to temp & uptime. -- Yes, those items are subscribed to the data Number TEMP2 "Temperature [%.1f °C]" {mqtt="<[mosquitto:home/rfm_gw/nb/node08/dev48:state:default]"} Number UPTIME2 "UPTIME [%d min]" {mqtt="<[mosquitto:home/rfm_gw/nb/node08/dev00:state:default]"} String getRSSI2 "get RSSI" {mqtt=">[mosquitto:home/rfm_gw/sb/node08/dev02:command:*:default]"} String getUPTIME2 "get UPTIME" {mqtt=">[mosquitto:home/rfm_gw/sb/node08/dev00:command:*:default]"} Are you seeing data show up on the OpenHAB User Interface? -- Yes I see the data in OpenHAB. Little strange thing happening here- - It seems the gatewat and openhab receives the response and I can see that in mosquitto_sub. But the node log shows "no connection". I don't know if gateway should send an acknowledge of the response received and for some reason thats not happening, causing the node to error no connection. But I also saw that "mes.cmd" is set to 0 and the its commented that 0 means no action needed from Gateway. If this is the reason, then no connection error should happen everytime and not intermittent. I suspect timing of ack might be playing here. I don't use DIG or Pro Minis. Having enough power on Arduino compatible devices can be a concern. For this reason, I've had to pare some things off my 3.3 volt Buono Uno nodes & supposedly they output more power than pro Minis. Trying to power the RFM69 radio, LED, push button, a temp sensor, & triggering a DIG might cause current issues that break connection. Perhaps powering the logic converters might contribute to this. Multiple button pushes might aggravate that. -- Power is not the issue, as I am powering with 12v 2amp power supply with regulators to output 3.3v to the minis and 5v to the relay on the node, and another 12v 2amp to the gateway with Uno and LLC with RFM, with regulators to output 3.3v. Are you using RFM_DIG_node_22.ino, namely the 2.2 version intended for Gateway 2.3? -- That's correct. If you have a temp sensor installed, I recommend you try removing it & see what happens. Next if node has an LED, try removing it & see what happens.
-- Yes, tried removing the LEDs and relay, and same results, intermittent no connection errors on node and connection lost to node on gateway. I don't need to use logic converters so can say little about them. Be sure you have wired them correctly. Looks like this discussion could be helpful. When we hear from you about the above, I may have some other possible areas to explore. I agree with Greg, perhaps I should try that. Papa, like your idea to push the info than to pull from the gateway. However, two use cases would still have issue even after those changes- - When I quickly toggle two buttons on openhab and on the second message it will error out. Looks like processing of messages are taking longer time, and therefore, it can't handle the immediate message after the first one - When the node is pushing the info to the gateway, and at the same time, I toggle the button on openhab, the message from gateway is somewhere stuck and errors out. I am planning to have this rolled out in my new home, so I will have around 30 nodes and therefore looking for a stable communication to avoid breakdown. Appreciate all your help and support.
|
|
|
Post by computourist on Feb 26, 2016 8:55:21 GMT
Hi sam4205 , I think your problem has to do with expectations. This system was designed for very simple end nodes and very limited data traffic. If you keep adding inputs and situations where multiple events happen, these problems will occur. The radio link is simplex (either send or receive, not both at the same time) and low bandwidth, the arduino processing power and memory are limited, and the software is set up in a simple serial flow. As you might have noticed I built in several blocking routines to prevent overflowing the radio link. This is exactly what you are doing. You are trying to send data when the RFM69 is receiving and vice versa. The data does not get received and acknowledged by the end node, so the gateway concludes the radio link is down. There are currently no countermeasures in the software to prevent this from happening. It is no rocket science, so you can't fly rockets with it ... There are several approaches to your problem: - rebuild the software. It would need to include interrupting (to catch all events), store and forward (to retain messages for later processing) and message sequencing (to keep track of which messages have been sent already). This is a major effort and I doubt if it will fit in the Arduino. - use an extra Arduino to prepare your input data. An extra Arduino could handle external events and measurements and encode them in simple messages that are sent to the gateway. In this way the node arduino does not need to keep track of external events and can handle the radio link. The number of messages can be decreased by coding multiple inputs into a single message. - use extra hardware to increase reliability. A simple example: currently software debouncing is used for the switch. This loops the processor and is fine with a single switch, certainly NOT with 4 switches. A simple d-latch could handle and store your switch settings, so the node can read and transmit values at its own pace. So there are several ways to go. Maybe other forum members have other ideas and/or are willing to work on this.. Some general remarks: - as papa said, it is better to have the node generate messages iso send READ requests from Openhab, that can occur randomly. In this way the node is in control and all processes are executed at the node's pace. - if you must read values from openhab, always write your rules so requests are spread in time. Always use crontab rules for fixed timing intervals - limit the amount of things you want to do with a single node. Consider using multiple nodes. Cost is not that high and reliability would increase.
|
|
|
Post by greginkansas on Feb 26, 2016 11:32:18 GMT
This caught my eye- - if you must read values from openhab, always write your rules so requests are spread in time. Always use crontab rules for fixed timing intervals I do this for most things, from the mouth of the master computourist a small send queue in 2.5 would be nice, for those of us pushing the limits Thanks
|
|
|
Post by computourist on Feb 26, 2016 12:59:37 GMT
2.5 ?
|
|
|
Post by papa on Feb 26, 2016 20:19:29 GMT
Yes, again I found it worked more reliably to have the end nodes send data than to have OpenHAB rules request it. However, if I used cron rules, I aimed to request only one or two things at a time from a node.
|
|
|
Post by sam4205 on Feb 27, 2016 8:21:47 GMT
Thanks Computourist, appreciate your inputs. I agree with you about the expectations from this simple design and other ideas to build out a complex design. I am a software person so don't have lot of hardware knowledge I really like the idea to let the node do most of the stuff and push the info instead of pull by gateway, as suggested by papa, greg and yourself. I have tried those tweaks and while troubleshooting, I found some basic issue in my setup related to long time needed for communications. One of the post, I stumbled across, was on the LowPowerLabs forum, where Felix mentioned that typically messages should take less than 100 ms to communicate with reasonable strength (~-70db or more). In my setup, I have push switches on the node that could be toggled either by push or via openhab. Leaving two toggles out of picture, and while trying just one switch at a time, I see issue in my design. Ack times is very variable and has wide ranges. I have attached the screen shot with MQTT log and message time from Serial. - After wakeup, the nodes sends 0, 2, 17,18,19,20 and 48 status to gateway - First line in the serial shows Dev19 took only 137 ms (highlighted in red) - Dev20 took 941 ms- Dev48 took 288 ms- After few seconds, I toggled the Dev17 on openhab and it was immediately received by the node(my led on node changes immediately) and then it took 5636 ms to send the ACK back to the gateway, with 4 retries. Between that 5636ms, the gateway reported connection lost to node. - After few seconds, I toggled Dev18 on opehab and it was also immediately received by the node and my led toggled immediately. But ACK back to the gateway took 328 ms with 1 retry. - The RF strength of -46db seems to be a strong strength, but still its taking longer time to send back the ACK. I don't know if the issue is at the Node or at the Gateway. I have seen messages being sent in less than 100 ms, but only sometimes. Node and Gateway are just 20 ft away. Again, thanks for all your inputs and ideas to solve this.
|
|
|
Post by papa on Feb 27, 2016 14:25:34 GMT
Sam, maybe my expectations are lower, but if I'm getting node data in OpenHAB (even with serial monitor reporting some "no connections"), I'm generally satisfied. If a node does not respond to the push of a real or virtual switch, I do it again. It seems like nodes not getting nudged for a while needed a wake up. It does concern me more to see response times near one second & more than 5 seconds. You might explore something further from your earlier post: I had asked, "What temp sensor are you using on the DIG node & how did you wire it?" You answered "--I am using the Temp Sensor embedded to the RFM69. I don't need an accurate temp and didn't want to add another component." I have not tried that approach. Seems an interesting way to maybe avoid power concerns & yet get temperature. However, could it be that using that is sometimes causing communication hiccups? You might try disabling that & see if communications improve. I've had a dozen nodes working at a time, with little problems that concern me & do hope to add more eventually. It will be interesting to see what happens as you try to have 30 nodes. In another thread, computourist raised the possibility of multiple gateways. We may need to try such options beyond a certain number nodes & functions running on those nodes.
|
|
|
Post by papa on Feb 27, 2016 15:49:55 GMT
One more troubleshooting possibility for you. Did you see the need to make a couple small changes in the library file, w5100.h? Doing that can help prevent communication problems.
Apparently RFM69s are sensitive to how interrupts are handled.
As I mentioned in my just above post, I would still try disabling "using the Temp Sensor embedded to the RFM69"
|
|
|
Post by sam4205 on Feb 27, 2016 19:15:58 GMT
Papa, Yes, I have already made those changes in the w5100.h in the else section.
Regarding disabling the temp sensor on RFM69, I don't think there is an option on the RFM to disable it. the delay happens in all messages and not only on the temp device messages.
Its good to know that you have a dozen of nodes and its working great on your end. I wish I could make to 2nd node and expand further. In fact I also built another node and noticed the similar delay like the previous node.
This leads me to think that, the gateway might have an issue. Would UNO with Logic converter play a role here to delay the ACK messages?
Any other ideas to troubleshoot this?
Sam
|
|
|
Post by papa on Feb 27, 2016 21:43:54 GMT
Regarding the RFM69 temp sensor, I just meant disabling OpenHAB or a sketch checking it, not disabling it on the RFM69 Speaking of logic converters did you learn anything from that discussion on this forum that I noted? I've seen mixed reports about the logic converters. Again, I do not use them, rather Buono Unos switched to 3.3 volts. Some people who've used this forum have had defective w5100 Ethernet Shields.
|
|
|
Post by computourist on Feb 28, 2016 14:28:55 GMT
Hi sam4205, You seem to have some trouble when 'stress-testing' the gateway & endnode. Your findings are consistent with the way things are designed/set up. Main requirement when starting this project was simplicity and duplex communication. It was designed as a data gathering / control network with limited real-time performance. When measuring temperature one or 2 seconds don't count... The design is based on: - Software (both gateway and end node) is designed around a simple loop. - Interrupts are blocked in the gateway in order to share the SPI bus between 2 users: RFM69 and ethernet. - Interrupts are not used to flag external events; the normal program flow is not interrupted. This means that this design is prone to 'collisions' and will only function if: - Events do not occur at the same time or in very short timing intervals. - The amount of end nodes and messages that share a radio link (network ID) is limited - Data transfer allows for delays, so retransmission is a viable option to increase reliability. The 'loop' design is a simple setup and easy to understand/adapt; it means all processes take place one after the other. This also means that when the gateway is talking to Mosquitto, it cannot receive or send data over the radio link and vice versa. It also means that if an end-node is debouncing a switch or writing to an LCD it cannot send/receive data. Not using interrupts in such a setup means you are bound to loose some data on the radio link. A retransmission scheme is used to deal with this. Since the gateway-radio can be offline for quite some time (when handling/decoding MQTT messages FE) it seemed wise to choose a rather long retransmission interval (.5 Seconds) that would lead to rather long response times in case of data collision. But I prefer a long delay over loosing data ;-) In the end it all comes down to a tradeoff between: - Simplicity of program setup - Number of nodes/messages that need to be served - Response time required. Of course things could be improved a lot by choosing an interrupt driven , store/forward, message stack based design. You state you are a software person, so you might be able to improve ... Given the current design you could try the following: - Decrease the transmission retry interval. It is set at an arbitrary value of 0.5 seconds, and I have not experimented with that. - Block radio retransmission by setting the number of reTx to 1. Error handling would need to be done in Openhab, but your response times will definitely improve. - Examine the load on your MQTT broker. If MQTT response time is bad, your radio response times will suffer. - Examine the software on your node. Keep the event-handling part as short as possible. If needed, offload event handling to external hardware or an extra Arduino. Some remarks on your post are inline below: Thanks Computourist, appreciate your inputs. I agree with you about the expectations from this simple design and other ideas to build out a complex design. I am a software person so don't have lot of hardware knowledge I really like the idea to let the node do most of the stuff and push the info instead of pull by gateway, as suggested by papa, greg and yourself. I have tried those tweaks and while troubleshooting, I found some basic issue in my setup related to long time needed for communications. One of the post, I stumbled across, was on the LowPowerLabs forum, where Felix mentioned that typically messages should take less than 100 ms to communicate with reasonable strength (~-70db or more). --> I agree, but the response time in this system is also dependent on performance of MQTT/Openhab: how soon is the gateway available again after handling MQTT messages. Many forum members run Mosquitto & Openhab on a Raspberri Pi with limited performance. Handling MQTT by the Pi is a factor to consider. In my setup, I have push switches on the node that could be toggled either by push or via openhab. Leaving two toggles out of picture, and while trying just one switch at a time, I see issue in my design. Ack times is very variable and has wide ranges. --> as explained above. Also: debouncing pushbuttons in software is NOT good for your performance...I have attached the screen shot with MQTT log and message time from Serial. - After wakeup, the nodes sends 0, 2, 17,18,19,20 and 48 status to gateway - First line in the serial shows Dev19 took only 137 ms (highlighted in red) - Dev20 took 941 ms- Dev48 took 288 ms- After few seconds, I toggled the Dev17 on openhab and it was immediately received by the node(my led on node changes immediately) and then it took 5636 ms to send the ACK back to the gateway, with 4 retries. Between that 5636ms, the gateway reported connection lost to node. - After few seconds, I toggled Dev18 on opehab and it was also immediately received by the node and my led toggled immediately. But ACK back to the gateway took 328 ms with 1 retry. - The RF strength of -46db seems to be a strong strength, but still its taking longer time to send back the ACK. --> As explained above: your signal strength is NOT the limiting factor, handling concurrent events is. The "connection lost" report is an immediate result of the gateway being busy with other things than radio reception.I don't know if the issue is at the Node or at the Gateway. I have seen messages being sent in less than 100 ms, but only sometimes. Node and Gateway are just 20 ft away. --> Again: signal strength is not the issue...
Again, thanks for all your inputs and ideas to solve this.
|
|
|
Post by greginkansas on Feb 28, 2016 15:56:13 GMT
Computourist thank you very much for your code and help. Everyone, nothing wrong with having two gateways if radio traffic is not what you want. Now about 2.5 Greg
|
|
|
Post by papa on Feb 28, 2016 15:58:12 GMT
Thanks, computourist, for the DIY Home Automation overview with respect to Sam's situation. You confirm & inform my sense that one needs to steward the demand on the system. Keeping in mind how many nodes are connected & how many functions on each. Choosing what's most important to know & accomplish. After prioritizing those, spreading the remaining demand on the system: Using rules to pull data only when absolutely necessary (& then not too many at any one time), but more often letting nodes push data. Using an overall node TXinterval (time between data sends) that is adequate & perhaps using a more immediate data send for one function. Not running or reporting too many functions at a node, unless those run infrequently. Accepting some transmission losses as long as OpenHAB stays relatively up to date.
computourist, you said "The 'loop' design is a simple setup and easy to understand/adapt." For someone like me that started with a little experience building & programming Arduino circuits, it was certainly not easy (getting parts & building nodes from a schematic, interlinking OpenHAB-MQTT-Sketch software, troubleshooting), but was doable with some digging. A more complex approach could be daunting for those who want to get their feet wet in DIY Home Automation.
Question, computourist: Could more than one gateway stretch the system's capability? How much? I suppose that would depend on the processing power of the computer hosting MQTT, right? A system built around a Pi would reach its limits sooner than a regular Linux or Windows computer? In which case, it should not be too hard or expensive to move a Pi-centered system to an older computer with Linux installed.
This discussion might be a good thread topic: DIY Home Automation, Capabilities & Limits. Contributors could each list how many Gateways & nodes they have, TXintervals, functions on each node, etc. Where did we seem to bump against limits & how did we adjust?
greginkansas, do you have more than one gateway? How many nodes do you have on each?
|
|
|
Post by greginkansas on Feb 28, 2016 16:17:44 GMT
I'm at 8 nodes sending once a minute and just got 2 more with half having to send BTN or PIR. I think that might be about it for 95% real time performance. The PI2 has Openhab, Mosquitto, squeezebox server and the Echo bridge server and runs 2-15% load so its good for another gateway. I think the load on the gateway is the limit. Greg
|
|
|
Post by papa on Feb 28, 2016 18:00:06 GMT
|
|
|
Post by computourist on Feb 28, 2016 18:45:11 GMT
To answer a few questions from previous posts: @ papa : using more than one gateway certainly stretches the systems capabilities because it lowers the probability of a collision occurring. You could even have one gateway for low reliability (continuous temperature updates, state monitoring) and another for high reliability (only a few buttons that get operated maybe once an hour). In this way you could maybe miss or have a delay on a temperature message, but it gets updated once every few minutes anyhow. At the same time the probability of two pushbuttons being operated simultaneously in the other network is almost zero. Having multiple gateways does not influence load on the MQTT broker: it has to serve an equal amount of messages, regardless whether they originate from one, two, or more gateways. I started out running Mosquitto and Openhab on a Pi and found it somewhat sluggish. I switched to a Cubietruck for my home server and am satisfied with its performance (wifi access point, webserver, mosquitto, openhab, squeezebox, Cups print server, Samba file server). @ greginkansas : about 2.5: In my opinion the capabilities of the 2.x setup are more or less reached. A new system would mean a major upgrade (3.0?) to include the techniques I described in earlier posts. This is a major undertaking for which I presently lack the time. On the other hand: my current system is meeting my needs perfectly... @ sam4205 : I understand you have a need for multiple pushbuttons on a single node. Maybe I can find the time to try some latches to improve the design..
|
|
|
Post by papa on Feb 28, 2016 18:54:29 GMT
Thanks, computourist, for your responses. I'll quote from them in the new thread about capabilities
|
|
|
Post by greginkansas on Feb 28, 2016 20:10:47 GMT
To answer a few questions from previous posts: @ papa : using more than one gateway certainly stretches the systems capabilities because it lowers the probability of a collision occurring. You could even have one gateway for low reliability (continuous temperature updates, state monitoring) and another for high reliability (only a few buttons that get operated maybe once an hour). In this way you could maybe miss or have a delay on a temperature message, but it gets updated once every few minutes anyhow. At the same time the probability of two pushbuttons being operated simultaneously in the other network is almost zero. This is what I would do when-if I need to. I started out running Mosquitto and Openhab on a Pi and found it somewhat sluggish. I switched to a Cubietruck for my home server and am satisfied with its performance (wifi access point, webserver, mosquitto, openhab, squeezebox, Cups print server, Samba file server). Was this a PI1 or PI2 ? I use a PI2 with a SSD seems like a low load and fast with openhab. @ greginkansas : about 2.5: In my opinion the capabilities of the 2.x setup are more or less reached. A new system would mean a major upgrade (3.0?) to include the techniques I described in earlier posts. This is a major undertaking for which I presently lack the time. On the other hand: my current system is meeting my needs perfectly... I agree 2.X is rock solid and is doing fine for me also. Thanks again
|
|
|
Post by computourist on Feb 28, 2016 21:02:19 GMT
It was the first Pi...
|
|
|
Post by sam4205 on Feb 29, 2016 10:08:02 GMT
Thanks Computourist and papa for your valuable inputs and thoughts.
I like the idea of having multiple gateway to handle based on priorities. In my situation, I am planning to have less of sensors and more of switches to control the lights (I was thinking of 30 nodes with average 3 or 4 switches per node, so ~100 switches in total)
As you mentioned, this might cross the limit of Pi2 that I have with Openhab and MQTT setup currently. Thanks for sharing details on Cubietruck. Perhaps I need to get one of those.
But its also good to know that papa and greg, you both seem to have around 10-12 nodes.
Papa, in your other posting, you mentioned you have around 5 nodes with pushbuttons with SSR and corresponding items on openhab. How is the performance of those pushbuttons event communication between the node and gateway? Do you see a variety of time between the ACK? What are is the average time of communications?
Learning from Computourist's thoughts, I suspect the problem is my MQTT/Openhab/rPi setup- - I had build version 1 of my node (hand wired) with 4 buttons and 4 channel Relay module along with version 1 of my rPi2 setup. - I had tested this version for 2 weeks and it worked great. I did see connection drops/delay but that was not as bad as it is now.My toggles on openhab was quickly executed at the node and it was switching the lights properly. Yes I did see delay but those were occurring in once in 10 or 15 toggles . Therefore I was very positive this prototype could be expanded further into larger setup. - Now in my version 2 of the node, where I fabricated the PCB with all components as it will be behind the wall panel. While building this, my rPI2 stopped working due to bad SD card and unfortunately, I didn't have a backup of the SD card. So I rebuild the rPI. I did have issue in setting up the openhab but got it working somehow. My gateway is the same which I had in version 1
Given that I am currently testing just with one node, I should get a real-time performance from the rPI.
Perhaps, I will try to re-build the rPI and see if that helps.
Papa, I did look at the posting of Gateway with level convertor, and agree this might also cause the drops I was seeing in my version 1. I am thinking, I should maybe have two Unos like what Eric Tsai did, to keep RFM processess separate from MQTT processes. Would love any thoughts on this.
Appreciate all the feedback. This is fun stuff. Hopefully I can resolve the issues and expand further with more capabilities like looping, queuing etc.
|
|
|
Post by greginkansas on Feb 29, 2016 12:37:06 GMT
As you mentioned, this might cross the limit of Pi2 that I have with Openhab and MQTT setup currently. Thanks for sharing details on Cubietruck. Perhaps I need to get one of those. @ see he had a PI1 PI2 to is a big leap, I also use a SSD 16GIG + case 25$ But its also good to know that papa and greg, you both seem to have around 10-12 nodes. Papa, in your other posting, you mentioned you have around 5 nodes with pushbuttons with SSR and corresponding items on openhab. How is the performance of those pushbuttons event communication between the node and gateway? Do you see a variety of time between the ACK? What are is the average time of communications? Given that I am currently testing just with one node, I should get a real-time performance from the rPI. @ I do with 8 Perhaps, I will try to re-build the rPI and see if that helps. Papa, I did look at the posting of Gateway with level convertor, and agree this might also cause the drops I was seeing in my version 1. I am thinking, I should maybe have two Unos like what Eric Tsai did, to keep RFM processess separate from MQTT processes. Would love any thoughts on this. @ take a look at www.anarduino.com/miniwireless/ this is what I am using for all new nodes
|
|
|
Post by sam4205 on Feb 29, 2016 15:04:08 GMT
Thanks Greg, when you get a moment, please share how long the messages are taking. Computouring and Papa, this link on openhab forum, might be of interest to you and other members who want to push the performance to next level. rPI PerformanceIts really good to see complex setup successfully running on rPI with openhab - some have 180 items with complex rules, some having 40 nodes etc.
|
|
|
Post by papa on Feb 29, 2016 16:02:38 GMT
Sam, I'm using the convention of interleaving my responses below, starting with -- & text in different color. Thanks Computourist and papa for your valuable inputs and thoughts. -- You're welcomeI like the idea of having multiple gateway to handle based on priorities. In my situation, I am planning to have less of sensors and more of switches to control the lights (I was thinking of 30 nodes with average 3 or 4 switches per node, so ~100 switches in total) -- It'll be great if you can get a long ways on your plan (with help probably). It'll either stretch the capabilities of our approach or show limits to live with or move on from.As you mentioned, this might cross the limit of Pi2 that I have with Openhab and MQTT setup currently. Thanks for sharing details on Cubietruck. Perhaps I need to get one of those. - - I only know what computourist says about Cubietruck. If my Raspberry Pi 2 seems to get overwhelmed, I'll likely use OpenHAB/MQTT on my older laptop with Linux. But its also good to know that papa and greg, you both seem to have around 10-12 nodes. -- I have had up to 11 end nodes on one gateway, currently less as you've probably seen in my new DIY Home Automation, Capabilities & Limits thread.Papa, in your other posting, you mentioned you have around 5 nodes with pushbuttons with SSR and corresponding items on openhab. How is the performance of those pushbuttons event communication between the node and gateway? Do you see a variety of time between the ACK? What are is the average time of communications? -- So far I have only ONE push button or other "switch" on each node. I have not tracked ACK. Mostly when I click the physical push button or the virtual switch on the User Interface, the relay or LED response seems immediate. Occasionally, it seems that the node needed to wake up from a first click & then responded immediately from the second. I use postUpdate to keep the virtual switch appearance in sync with any change the physical push button makes in the Relay or LED state. This postUpdate is delayed up to as long as the sketch's TXinterval (time between data sends). So far things work quite adequately for me, but starting in a couple months, I hope to add more nodes & see what happens.Learning from Computourist's thoughts, I suspect the problem is my MQTT/Openhab/rPi setup- - I had build version 1 of my node (hand wired) with 4 buttons and 4 channel Relay module along with version 1 of my rPi2 setup. - I had tested this version for 2 weeks and it worked great. I did see connection drops/delay but that was not as bad as it is now.My toggles on openhab was quickly executed at the node and it was switching the lights properly. Yes I did see delay but those were occurring in once in 10 or 15 toggles . Therefore I was very positive this prototype could be expanded further into larger setup. - Now in my version 2 of the node, where I fabricated the PCB with all components as it will be behind the wall panel. While building this, my rPI2 stopped working due to bad SD card and unfortunately, I didn't have a backup of the SD card. So I rebuild the rPI. I did have issue in setting up the openhab but got it working somehow. My gateway is the same which I had in version 1 Given that I am currently testing just with one node, I should get a real-time performance from the rPI. Perhaps, I will try to re-build the rPI and see if that helps. Papa, I did look at the posting of Gateway with level convertor, and agree this might also cause the drops I was seeing in my version 1. I am thinking, I should maybe have two Unos like what Eric Tsai did, to keep RFM processess separate from MQTT processes. Would love any thoughts on this. --I'm not sure about the two part Gateway. Some of the code from that original Uber instructable did not seem completely reliable (even with others' follow up efforts). But if you try that, let this forum know if it helps or not.
Appreciate all the feedback. This is fun stuff. Hopefully I can resolve the issues and expand further with more capabilities like looping, queuing etc. -- Yes, definitely fun & satisfying when things work & having others to team with us, but it's sometimes frustrating until one overcomes glitches.
Sam: Computourist and Papa, this link on openhab forum, might be of interest to you and other members who want to push the performance to next level. rPI Performance Its really good to see complex setup successfully running on rPI with openhab - some have 180 items with complex rules, some having 40 nodes etc.
--Thanks for the reminder of that thread, Sam. I had forgotten about it. Another reminder that there is useful info in other threads that are not necessarily on this forum.
-- Sam, see my post below where I ask questions about what you are trying that may help some of us to help you more.
|
|
|
Post by papa on Feb 29, 2016 18:47:09 GMT
Sam: Papa, I did look at the posting of Gateway with level convertor, and agree this might also cause the drops I was seeing in my version 1. I am thinking, I should maybe have two Unos like what Eric Tsai did, to keep RFM processess separate from MQTT processes. Would love any thoughts on this. greginkansas: @ take a look at www.anarduino.com/miniwireless/ this is what I am using for all new nodes --Papa: Greg, I am looking at the anarduino miniwireless at least for future light switch nodes, but I probably won't be able to get to this for a couple months. Have you used the miniwireless to trigger a relay? If so, which relay & could you directly connect the arduino digital pin to the relay's DC input or did you need to use a transistor to help?
|
|
|
Post by papa on Feb 29, 2016 19:00:07 GMT
Sam, some questions about what you're trying to do that might help someone on the forum better help you:
Please say & show more about the device you are adapting. computourist says he designed it around "a single remote controllable digital output (relay) and a button which toggles the output. He posted pictures at this thread on 10/31/2015. You're using devices with 4 push buttons, right? How many outlets? Could you post a picture?I took a closer look at the DIG End Node 2.2 sketch vs DHT End Node 2.2 sketch. It's pretty much as computourist described, "This node is basically the DTH-node with unnecessary code removed." As indicated in the DIG sketch, code for the DHT11 temp / humidity sensor is removed. However, there are some other differences in variables that control the delays to smooth things out ( line numbers): DHT 2.2 sketch: HOLDOFF 2000 [2 secs] DIG 2.2 sketch, line 83: HOLDOFF 1000 [1 sec] Once the sketch detects a button push, it ignores further responses for this long. Helps with debouncing the button & I believe helps prevent overloading messages on the system [Necessarily] adds some delay to button response, esp multiple pushes. DHT 2.2 sketch: TXinterval = 60 seconds DIG 2.2 sketch, line 88: TXinterval = 120 seconds [2 minutes] DHT 2.1 sketch; TXinterval = 20 seconds How long the node waits between data sends via the Gateway. Again I believe this is meant to prevent overloading messages on the system TXinterval adds a built in delay to every data send, but should also help prevent miscommunications The DIG 2.2 sketch, lines 80-81 set ACT1 // Actuator pin (LED or relay) to D9 & set BTN // Button pin to D8 [to read use of the push button]. Sketch was written for ONE button & ONE output. More questions: How did you wire ALL your buttons & outputs? Including did you use a 10 kilo ohm resistor along with each button to give its digital pin a stable HIGH state until the button is pushed? How did you add to / adapt the sketch code to use ALL buttons & outputs?If I may ask, why do you want/need four button & four outputs at each location? How many do you presently see needing? How many are perhaps being put in a new home installation for future capabilities without having to redo things?
|
|
|
Post by greginkansas on Mar 1, 2016 0:38:50 GMT
papa do you know about this- pinMode(buttonbackdoor, INPUT_PULLUP);
sam4205 Learning from Computourist's thoughts, I suspect the problem is my MQTT/Openhab/rPi setup-
He was using a PI1 we are using the PI2 way faster.
|
|