Well as luck would have it, our prototype product was recently demo’d at a large tradeshow where a serious flaw was found.
My client has an existing, non-IoT, product that is a real-time control system with button and LCD UI.
We are currently engineering the “premium” next version of that product with the substantial upgrade feature being IoT. The new product is built on the P1 platform.
When the product was at the tradeshow and for the first time away from a development workstation, it began suffering pretty bad issues where it basically became unresponsive.
Some research on the forums and testing to confirm, shows that I am having the well-known issues with the P1 being basically dead when trying to reconnect to the Cloud. I replicated this quite simply by turning of the WiFi router it was connected to and the button interface went from super responsive to basically not working.
So I’ve seen on the forums and on the issues tracker on GitHub plenty of people discussing workarounds and some ideas on how to get acceptable functionality in this situation. Most of the suggestions aren’t going to be usable by us for 2 reasons:
- The device is going to be installed outside, so poor signal strength is not only possible but will be probable; and
- Most of the suggestions discuss ways to recover when things have been in this locked state for a period of time, but as a real-time control system where the user is expecting to push a button and have something work immediately, that “period of time” is unacceptable.
So the only idea that seems to look promising to me was floated in this thread, and it was to extract basically all of my control system functionality into a completely separate thread and leave all Particle networking/cloud functionality behind in its own thread.
My concerns with that are that:
- I’m already running SYSTEM_THREAD(ENABLED) (albeit there are some Publish calls in my application thread as it stands right now) and my system is still pretty much dead; and
- I saw a comment on GitHub made by @ScruffR that indicated that when Particle.connect is running other threads will have their performance severely affected; and
- I saw a comment (that I can’t locate right now) that seemed to imply that “millis” time keeping might be affected during this blocking behaviour.
So, with all this on-board, does anyone have any comments or advice before I try this?
I have to say that based on what I’ve presented above that I’m not hopeful that it would work anyhow, and I’m wondering if I need to go to my client and tell them we may need to abandon Particle as a platform before they start placing orders for thousands of P1s.
Thanks if you’ve read this far. I hope you have some words of wisdom.