About the time you pushed the new firmware, I started noticing problems. The device to go to sleep and no longer wakeup without having to have the card ejected and reinserted. I replaced multiple systems (irrigation and lighting) with the imp, and now both systems are no longer working. Is there any effort at finding a fix.
The only symptom is that the device just goes offline after working for awhile…
Monday, January 07, 2013 14:20:18: temp=58.91 hum=74.8843 rssi=-75
Monday, January 07, 2013 14:20:47: Power state: online=>offline
and I can’t get it to “awaken” from the web browser.
Had this issue few times this year but don’t really knew if it’s the result of my power supply testing (battery backup functionality) or it’s the new firmware …
For what it is worth, I have had this throughout all the different versions. It would be random (work for days, then go offline and never come back). Don’t really want to have an imp that is in charge of rebooting my other imp:-)
I had that for older versions only when I had a lot of string stuff (format("%d",x) for example) in functions which were called many times - my guess was the memory ended because string manipulation. But this time I had it in IMP where does not have string stuff or other things involving many local variables … But as I said I am still not sure if it’s not causes by switching the powerpath’s behind … For memory issues now we have the availablememory functionality which worth logging time to time so we can track back memory eating from now on …
I suspect what you’re seeing is a NAT timeout, which is causing the connection to the imp to be closed by the router, so the imp doesn’t see the server-initiated ping and hence gets marked offline.
Is your imp regularly sending data to the server? Until the server starts asking the clients to do client pings (in release-14 just not enabled by the server) you can definitely improve connectivity by regularly doing a server.log or similar. We have devices that have been up weeks without issues. They should stay up “forever”, but as we update firmware regularly, that causes a reboot…
It’s still broken. Lasts a few hours after a eject-and-insert reset – Any chance to revert the firmware so I can get my lights and irrigation system operational again?
We’re looking into it now; the code around there has changed due to the (partial) addition of the wifi-less mode and it looks like something bad has crept in. We’ll have a fix shortly and push it out - apologies.
Let me know when it’s ready as I’ll have to power cycle my device so it goes back online. I understand how these things can happen, but I hope put in place a more robust QA system, or require the individual to manually upgrade the firmware. If you expect your product to be deployed in a multitude of consumer devices, a problem like this can ruin the reputation of your company.
If it was me, I would have the planner have the option to upgrade & downgrade firmware, as well as have the option for auto-upgrade. Once a system works, there is no benefit (from the consumers perspective) to upgrade anything, less it break.
By the way, I have seen mention of your new sockless module in the docs, but no further details or photos. Where can i get more information. And any chance you guys might make a version of the firmware to made the hardware a dumb wifi/serial (or wifi/spi) bridge? You can expand your market share by doing that; just look at all the competitors in that space. And you can gain a foothold via a little firmware.
We did do QA on this build with multiple devices, but it appears that the issues only occur with some routers - not the ones we were testing with, as our always-on devices have been connected since the upgrade without issue. We’ll improve this process in the future. We do multiple router join/authentication testing automatically, but not connection maintenance, which requires a different setup where we can provoke the routers individually.
…and yes, upgrades will become something you can delay. Right now, we push upgrades because they contain critical fixes for issues, but the frequency will reduce and vendors have the option to delay updates until they’ve run QA with their firmware.
More info on the module will come. If you’re interested, email manufacturer@ and we can send a preliminary datasheet.
We have had wifi-serial API calls on the wishlist for a long time. It would be something configured in squirrel though (which would then pass through the service as normal, it’s just that squirrel wouldn’t need to be involved in the data handling which would improve throughput). Not interested in making dumb local bridges though, sorry.