Rick, quick clarification, this situation applies where any mesh node (not the gateway?) uses Particle.publish which uses UDP and not TCP and will timeout. This does not apply to Mesh.publish() nor would it apply to a Xenon in an ethernet featherwing acting as gateway or to any other mesh in the same mesh network using Particle.publish?
As I understood the OP and how it makes sense to me is that it’s not about device initiated communication but when the cloud tries to reach the device.
The device always knows how to contact the cloud, but due to the lack of a persistent back-channel from the cloud to the device the route just breaks without the device keeping the cloud regularly informed where and how to find it.
2 Likes
Correct. If you have a mesh devices connected via a gateway that requires a short keep-alive (typically Boron with a 3rd-party SIM) this could be an issue.
Correct. Presumably if you require a short keep-alive (think Boron with 3rd-party SIM) the gateway already needs a short keep-alive. However, it's likely true that the Xenon nodes will need one as well.
This does not apply to Mesh.publish()
Correct. It only affects the UDP back-channel that gets data from the cloud to the mesh device. So mesh publish and subscribe are not affected.
nor would it apply to a Xenon in an ethernet featherwing acting as gateway
Using the Ethernet FeatherWing you typically won't need a short keep-alive so it's not generally an issue.
2 Likes
I don't understand what you mean by that. Can you clarify how to change the Xenon to do that?
If you don’t want to have all your nodes regularly punching data out to the cloud just to keep the back path open, you can direct your requests to the gateway which then dispatches them via Mesh.publish() where the respective node can pick the events meant for it and do its job or answer to the request by actively sending out a Particle.publish()
An alternative might be to introduce some means to “nudge” the device(s) - on demand - from the gateway (again via a Mesh.publish()) to which the respective devices respond by Particle.publish()ing a “I’mHere” event which in turn opens a window for subsequent requests.
This may need restructuring your communication scheme, but when data consumption is a concern concessions may have to be made (for the time being).
But depending on your actual needs there may be better strategies based on the principles outlined above.
1 Like
OK, I understand what you mean about distributing the requests. Yes, it sounds like that would be a workaround for getting command requests down to the device. It would still not be possible to ping the device, but I guess you would just have to live with that.
When you take my second suggestion, you can "ping" the device after you alerted it that something will be coming its way and it should open the window to receive the ping.
1 Like
Just for the record, my Xenon has been running without problems for almost 24 hours with Particle.keepAlive(). Without that change it would not last more than a couple of minutes! Thanks for all the help!
7 Likes
I have a Boron using Particle’s SIM and Xenon network both running 1.2.0-beta.1. The Boron’s vitals indicate only 2 disconnects in nearly a week of continuous operation. The Xenon however shows many disconnects and from the diagnostic results and the uptime I have calculated the disconnects happening precisely every 23 minutes. I am using a standard Boron with the Particle SIM (not a third party SIM) and my understanding is that there should not be a need for a Particle.keepalive for the Xenon’s. Is that correct? After nearly 4 and half days the Xenon went offline for 6 hours, i.e. did not show as an active device in the console list. It then came back online for a period of time and was pingable i.e. could get variables etc. Now it shows “active” in the console list yet can not be pinged or accessed for the past 12 hours. Any thoughts on how to address or work around this? I have 11 more Xenons that will be going online in the next few days. I would really like to get a handle on this issue before the client starts asking questions I can’t answer. Saw similar behavior when I had a dozen Xenons and the Boron on my bench. Initially all would show online and be pingable. Then they would indicate as unreachable. Power cycling was the only thing that brought them back. I may have to put in a power supply reboot relay at the Boron which has access to the Xenons DC power supply. I would like a better solution than a periodic power cold boot.
Not an answer but the particle sims use a 23 minute keep alive by default. Your 23 minute disconnects on the Xenon could coincide with the Boron’s keep alive.
The offline indicators are a known issue that is being worked on. The issue there is the inherent connectionless nature of UDP communication. The console has no knowledge that the Xenon goes offline. One pig the workarounds is to add a function that can be called to return data… so if you can call the function, the device is online.