Activity LED is always on

[Pedro-vk]

Hi, I bought the enviro 1 year ago and I had to stop using it because I had a lot of issues. Right now I tried again and installed the last main version.

I'm using the battery and the activity LED is always on. I think that it is not normal.

Here are the logs:

2024-01-24 19:40:04 [info     / 121kB] > performing startup
2024-01-24 19:40:04 [debug    / 119kB]   - running Enviro 0.0.10, MicroPython 9dfabcd-dirty on 2022-08-10
2024-01-24 19:40:04 [info     / 113kB]   - wake reason: rtc_alarm
2024-01-24 19:40:04 [debug    / 112kB]   - turn on activity led
2024-01-24 19:40:04 [debug    / 107kB] > 98 blocks free out of 212
2024-01-24 19:40:04 [debug    / 105kB] > taking new reading
2024-01-24 19:40:05 [info     / 100kB]   - seconds since last reading: 1200
2024-01-24 19:40:05 [debug    /  95kB] > caching reading for upload
2024-01-24 19:40:05 [info     /  90kB] > 2 cache file(s) not being uploaded. Waiting until there are 10 file(s)
2024-01-24 19:40:05 [info     /  88kB] > going to sleep
2024-01-24 19:40:05 [debug    / 121kB]   - clearing and disabling previous alarm
2024-01-24 19:40:05 [info     / 119kB]   - setting alarm to wake at 20:00pm
2024-01-24 19:40:05 [info     / 117kB]   - shutting down
2024-01-24 22:57:32 [info     / 121kB] > performing startup
2024-01-24 22:57:32 [debug    / 119kB]   - running Enviro 0.0.10, MicroPython 9dfabcd-dirty on 2022-08-10

So it seems that got stuck at 19:40 or 20:00 and it never ran again until I disconnected and connected to the USB port.

Thanks for your help :)

[Pedro-vk]

I bought it 1 year ago and I had to stop trying to use it because I was wasting my time with something that just didn't work. After a year, I have the same problem using the last updates. It gets hanged after some hours... So my specific board is useless :(

[sjefferson99]

@Pedro-vk Many of the issues I had with the board crashing inexplicably and similar to your issue above were due to some issues in the wireless code. These were fixed in #199 which if you scroll to the bottom of the comments, now has a link to the zip file of the code or uf2 to copy over to make it easy to try that ahead of it hopefully going into main release.

Give that code a try and see if it makes things more stable for you.

[Pedro-vk]

Thank you! :) I'll check it during this week

[Pedro-vk]

I used the code of this branch for a week and I have the same issues... Sometimes the LED is always on, sometimes the red warning without a log... And it drained the batteries in just 1 week :(

[sjefferson99]

So are you saying that sometimes it crashes with the white LED on solid and sometimes it crashes with the red LED on solid? And in either case there is no useful log output? Could you post the logs you have and what state you found the board in when that log file was written just to be 100% clear?

All my issues that were similar were cleared up by the wifi improvements, but you could also try the code in PR #144 as this was developed to try and handle crashes. I don't think it did much for my specific issues, but it's worth a try.

[LMieldazis]

I have observed a similar behavior to what Pedro described, though let me add some more details:

My Indoor arrived on April 25th. I flashed it with v0.2.0 immediately and integrated with the rest of my setup to consume its data (HASS, Grafana, etc). The device would freeze seemingly randomly, with the white LED left on at full brightness and no new attempts to read or upload anything. It would stay that way until I manually intervened. This would happen repetitively between a few hours and a couple of days after the last reboot. This happened both with an MQTT broker as well as InfluxDB. The 2x AmazonBasics AAA batteries that came with it died exactly 7 days later, on May 2nd. I confirmed that I was running v0.2.0, by checking the code as well as the MicroPython version. During that first week I tried re-flashing it by using the "flash_nuke.u2f" provided but the issue persisted.

Right after the batteries died, I switched to a generic USB charger plugged right on the wall. No other changes to firmware or to the upload target. It never froze again. I have increased the frequency of the readings from 15min to 10min, which in theory should increase the likelihood of triggering that behavior. But nope, still running now 10 days later.

I no longer have the logs of those freezings, though I remember them being unspecific. Something about going to sleep and subsequent logs having an incorrect date (1900), most likely created during the new boot. I can put it back on batteries and provide the logs here if that helps.