I released a new firmware for the 10 devices that are part of my Product. However, today I noticed that even though I can tell by looking at their output data they do (and looking at their log, they do show as updating) they keep remaining tagged with the wrong Firmware in the cloud for a very long time.
As a result, overnight the devices kept requesting a firmware update. I do not believe they actually downloaded it every single time as (A) they already had that firmware (B) the data usage suggests they haven’t downloaded anything, but instead of sleeping for 6 hour periods, they were in a loop of resetting themselves every time, some taking more than 18 hours before finally receiving the correct firmware tag in the Cloud.
in fact, I can tell now that some devices show up with the correct firmware in the Cloud, they simply stopped connecting at all anymore after the 6-hour periods…
Anyone having experiences with this issue? Why does it take so long for my devices to be tagged with the correct firmware?
EDIT: Just decided to release a new firmware, with no changes to it other than the Product Version. It’s very premature to say but it seems the two devices that did download it don’t have the issue anymore.
Thanks. So far no issues anymore it seems, devices are downloading the new firmware one by one.
The onlly thing I can think of is that at some point I had one device with firmware version A (although I didnt upload that to the Product). Then I created a new firmware and also named it version A, and I did upload that one. Then I tried updating all devices to version A.
Not sure if that played any role but maybe it helps. Perhaps that the cloud software got confused as to which was the correct firmware to provide to devices and so it went rogue and kept telling them continuously to update?
Firmware 0.6.2. All devices run fine, except once I put them in containers with metal lids. Looking at the data I could tell it was mainly two devices that always had issues, so I checked it out and found they’re completely surrounded by metal (although to be fair, these containers often have crevices and holes in them so they do still connect about 50-60% of the time).
Anyway, I started measuring how long it takes on average for devices to connect. When the devices in metal containers connect, they would usually do so no slower than devices at my desk (which has great reception). I’m a bit puzzled by that; I thought they needed a much longer time to connect and that this would result in possibly exceeding the time limit I set on the connection.
Instead, it seems they usually connect fine but occasionally just can’t establish any connection at all. This also explains why increasing the time limit for 1 minute to 2-3 minutes didn’t yield any improvement.
I decided not to go for them anymore, and go with Ultrasonic sensors instead. Although their data output was great, I couldn’t find any material would protect it well enough against grime and oil (e.g. finger-touches) while also allowing the signal to travel through.
With some of my ultrasonic sensors i can expose them to a lot of contamination and they will still work fine
Not sure why the two devices were connecting poorly; I investigated and they were on metal containers but with the lid open…still, I assume the metal has been negatively effecting the antenna signal quite a bit.
So as a test, I drilled a hole and wired the antenna through the container, so now it sits on the outside. It still has the outer wall of the container close to it (a 1-2’’ gap) but other than that it should largely sit in plain sight, which I hope means it’s gonna connect much more reliably.
So far all it seems fine - it made all the connections it should so far.
To be fair, even devices under a plastic lid still miss connections at times (though far less, at maybe 5-10%). So it seems you don’t even need a full-metal enclosure to block the signal; any metal around it may be sufficient to interfere with the signal
Perhaps kinda obvious, but still good to have tested it. Metal waste containers definitely aren’t suitable if you want a sensor that connects very reliably.
I would expect missed publishes if your connection times are short before going to sleep because sometimes it just takes longer to connect to the cellular network.
What is the RSSI now on the cans that you put the antenna on the outside?
It doesn’t seem to be too related to the connection time from what I can tell - if it can connect it does so pretty quick, if it can’t connect, even letting it sit for a long time doesn’t help.
The RSSI still shows values around 1-3; it doesn’t seem to have changed at all from before.
Probably just the fact that the antenna is outside of the metal enclosure. Firmware changes don’t really seem to effect it much really; I can let it connect for 5 minutes and it still fails at times.
All of them have issues correct, but I think even the ones on containers that aren’t all-metal, still receive sufficient interference from the metal around them to negatively affect the signal. So the antenna located on the outside of the metal container rather than the inside, is best I believe.
Things are pretty stable now indeed, I still need to test the ultrasonic sensor a lot more due to lack of materials, but I will get around to that soon. Equipment purchases are funded partially by an university and company.
When containers are picked up, how full they are, location and possibly temperature detection (the accelerometer actually comes with a Temperature reading; although inaccurate it could be used to check if there’s a possibly fire). In the future I also want to add a camera to this, and perhaps some kind of smart-lock system for users to open the container with
After some more time has elapsed, I discovered a pretty significant issue; I’ve used Thingspeak for quite some time, and started using Ubidots very recently. I notice data entries in Ubidots that do not appear in Thingspeak. I know for a fact the entries in Ubidots must be correct as they occur at the exact time interval that I would expect them to, which means that the webhook from Particle to Thingspeak isn’t reliable? I haven’t cleared my Thingspeak data in quite some time, and I’m not exceeding any data-limits as I’m only sending data every half an hour or so max. So far I can only spot 2 data-entries that are missing from Thingspeak, but it would hint at some important issue.
Regardless, in addition to this I also notice that even devices at my desk sometimes still miss a connection. I live in a highly urbanized area and the signal here is excellent, so I’m quite puzzled by this. I wish the issue with putting a device into sleep after running Particle.connect would be fixed, as I think it would solve a lot of issues.
Yea, sometimes the Particle Publishes don’t work due to backend issues but they always get fixed quickly. I would say their uptime is 99%, at least it feels that way with using the Particle Publish to push data to Losant.
Losant has a feature that will alert you if your device has not checked in past a certain time frame if that’s something you’re interested in.
I used Ubidots before finding Losant and I pushed data to Ubidots using their MQTT integration that bypassed the Particle Publish method and still I would see the Electron stop sending data to Ubidots even though the Electron looked like it was waking up and sending data normally. I chalked it up a cellular network problem, the only way to get the Electron working again was to pull the battery and then plug it back in. That was last year but it happened numerous times over time.
Ubidots does have a Particle Webhook integration now I see.
With Losant you could at least get notified if it does not receive data past a preset timeframe so you would know something needs fixed or not.
Either way you go your going to end up with missed data unless you subscribe to your published event and resend that data again if you do not receive a response to your published event, but that would require more on time than your wanting for your application.