enviro
enviro copied to clipboard
pimoroni
enviro grow hangs 0.0.9
enviro grow with v 0.0.9 runs for a while then hangs. I turned off uploading to Adafruit which seemed to make it last longer between hangs but it still just stops. soft reboot and sometimes a poke brings it back. extract from log:-
2023-01-02 16:57:02 [debug / 103kB] - clearing and disabling previous alarm 2023-01-02 16:57:02 [info / 111kB] - setting alarm to wake at 16:58pm 2023-01-02 16:57:02 [info / 108kB] - shutting down 2023-01-02 16:57:02 [debug / 106kB] - on usb power (so can't shutdown). Halt and wait for alarm or user reset instead 2023-01-02 16:59:07 [info / 124kB] > performing startup 2023-01-02 16:59:07 [debug / 122kB] - running Enviro 0.0.9, MicroPython 9dfabcd-dirty on 2022-11-18 2023-01-02 16:59:07 [info / 115kB] - wake reason: rtc_alarm 2023-01-02 16:59:07 [debug / 113kB] - turn on activity led 2023-01-02 16:59:07 [debug / 109kB] > 99 blocks free out of 212 2023-01-02 16:59:07 [debug / 106kB] > taking new reading 2023-01-02 16:59:07 [info / 101kB] - seconds since last reading: 382022 2023-01-02 16:59:08 [info / 96kB] > sensor A below moisture target 50 (currently at 0). 2023-01-02 16:59:08 [info / 94kB] - running pump A for 2.0 second(s) 2023-01-02 16:59:10 [info / 115kB] > sensor B below moisture target 50 (currently at 0). 2023-01-02 16:59:11 [info / 113kB] - running pump B for 2.0 second(s) 2023-01-02 16:59:13 [info / 103kB] > sensor C below moisture target 50 (currently at 0). 2023-01-02 16:59:13 [info / 101kB] - running pump C for 2.0 second(s) 2023-01-02 16:59:15 [debug / 91kB] > saving reading locally 2023-01-02 16:59:15 [info / 86kB] > going to sleep 2023-01-02 16:59:15 [debug / 84kB] - clearing and disabling previous alarm 2023-01-02 16:59:15 [info / 82kB] - setting alarm to wake at 17:00pm 2023-01-02 16:59:15 [info / 80kB] - shutting down 2023-01-02 16:59:15 [debug / 77kB] - on usb power (so can't shutdown). Halt and wait for alarm or user reset instead 2023-01-02 17:02:51 [info / 115kB] > performing startup 2023-01-02 17:02:51 [debug / 113kB] - running Enviro 0.0.9, MicroPython 9dfabcd-dirty on 2022-11-18 2023-01-02 17:02:51 [info / 122kB] - wake reason: rtc_alarm 2023-01-02 17:02:51 [debug / 120kB] - turn on activity led 2023-01-02 17:02:51 [debug / 115kB] > 98 blocks free out of 212 2023-01-02 17:02:51 [debug / 113kB] > taking new reading 2023-01-02 17:02:51 [info / 108kB] - seconds since last reading: 224 2023-01-02 17:02:52 [info / 103kB] > sensor A below moisture target 50 (currently at 0). 2023-01-02 17:02:52 [info / 101kB] - running pump A for 2.0 second(s) 2023-01-02 17:02:54 [info / 92kB] > sensor B below moisture target 50 (currently at 0). 2023-01-02 17:02:54 [info / 89kB] - running pump B for 2.0 second(s) 2023-01-02 17:02:56 [info / 119kB] > sensor C below moisture target 50 (currently at 0). 2023-01-02 17:02:56 [info / 117kB] - running pump C for 2.0 second(s) 2023-01-02 17:02:59 [debug / 106kB] > saving reading locally 2023-01-02 17:02:59 [info / 102kB] > going to sleep 2023-01-02 17:02:59 [debug / 99kB] - clearing and disabling previous alarm 2023-01-02 17:02:59 [info / 97kB] - setting alarm to wake at 17:04pm 2023-01-02 17:02:59 [info / 95kB] - shutting down 2023-01-02 17:02:59 [debug / 92kB] - on usb power (so can't shutdown). Halt and wait for alarm or user reset instead 2023-01-02 17:04:00 [debug / 91kB] - reset 2023-01-02 17:04:03 [info / 114kB] > performing startup 2023-01-02 17:04:03 [debug / 112kB] - running Enviro 0.0.9, MicroPython 9dfabcd-dirty on 2022-11-18 2023-01-02 17:04:03 [info / 121kB] - wake reason: rtc_alarm 2023-01-02 17:04:03 [debug / 119kB] - turn on activity led 2023-01-02 17:04:03 [debug / 114kB] > 98 blocks free out of 212 2023-01-02 17:04:03 [debug / 112kB] > taking new reading 2023-01-02 17:04:03 [info / 107kB] - seconds since last reading: 72 2023-01-02 17:04:04 [info / 102kB] > sensor A below moisture target 50 (currently at 0). 2023-01-02 17:04:04 [info / 99kB] - running pump A for 2.0 second(s) 2023-01-02 17:04:06 [info / 90kB] > sensor B below moisture target 50 (currently at 0). 2023-01-02 17:04:06 [info / 119kB] - running pump B for 2.0 second(s) 2023-01-02 17:04:09 [info / 110kB] > sensor C below moisture target 50 (currently at 0). 2023-01-02 17:04:09 [info / 93kB] - running pump C for 2.0 second(s) 2023-01-02 17:04:11 [debug / 83kB] > saving reading locally 2023-01-02 17:04:11 [info / 78kB] > going to sleep 2023-01-02 17:04:11 [debug / 123kB] - clearing and disabling previous alarm 2023-01-02 17:04:11 [info / 120kB] - setting alarm to wake at 17:06pm 2023-01-02 17:04:11 [info / 118kB] - shutting down 2023-01-02 17:04:11 [debug / 116kB] - on usb power (so can't shutdown). Halt and wait for alarm or user reset instead
Hi @pontolimbique. Thanks for raising this. From that log, I can see that there are points where it isn't saying - reset where it should be, but because of how close together all those log times are, it's hard to tell an exact problem case for me to begin to diagnose.
I do acknowledge though that Enviro Grow seems to have issues. I set up all four boards over the holiday break, and only the Indoor and Weather ran fine, despite it supposedly being the same code.
Hi there, I had also setup an Indoor and a Grow around Christmas, only the indoor still sends data to Adafruit.io The grow seems to have stopped working after a few days (at least for the data upload). Unfortunately I won't have access to the grow for a while in order to check its log, since it's in a remote location. Luckily I am just using the grow for soil moisture monitoring and not for supplying water yet (done in a different way). Due to a plant monitoring cam at that location I can at least see that the red LED of the grow is flashing. Is there a simple and reliable way to program e.g. a reset once a day as soon as I have access to it? Just in case... ;)
Hello there, I would like to confirm that I too suffer from the pimoroni-grow hanging. I am using the last released software version and it is random. I end up having a steady white light and cannot at this point access the board (I assume it just never gets woken up?)
I am happy to do some troubleshooting if you guide me guys :) Furthermore I also noticed a higher temerature when running on USB power and jittery temperature as in other threads.
Pontolimbique can you tell me how you managed to get soil and pumps just to work I can only get the temperature sensor to work with adafruit it took a whole day I have the enviro grow I'm a newbie. Adafruit only has bme temperature sensor dash, no pump dash the soil sensor dash doest work nor the buzzer or light sensor and the wifi cuts off,on intermittently nightmare I was hoping to set something up in my greenhouse this year but it could end up in a drawer for a year or 2
wllms630 - I couldn't get it work properly, got a replacement as the first board started getting very hot but had no luck with the second one either. I've given up, I think there are serious hardware issues. I sent it back eventually for a refund.
Hi @wllms630 could you elaborate on the issues with the soil sensors and pumps? This is the first time I have heard of them, so perhaps it is just a configuration issue?
Do you know what version of the Enviro firmware you are using? I.e. is it what came on the board, or have you updated it since?
@pontolimbique Sorry to hear that, but glad our support team were able to refund you. I really wish the boards were more stable, but it seems these hanging issues are happening at a lower level than the Enviro firmware, likely on the Pico W itself, and my attempts to diagnose or mitigate them have been fruitless so far.
Hi @ZodiusInfuser , I am sorry to hear it is happening somewhere lower. I have the grow board and it just keeps on hanging withing a few hours. Usually after some 4 hours, if i upload every 5 minutes to influxb. I tried to apply the PIO watchdog, however I am a bit lost how that should work. How does the Hold_vsys_en pin work? is it providing energy for the enviro board? Why should changing it to an input pin put the board to sleep?
I am asking cos given my frequent hangs (which happen faster when the wifi signal is low, ie from balcony) so if u have any tips what voltages to measure at what pins, do not hesitate to let me know. How would the PIO watchdog reboot the chip? cos the init.py file only this block seems to be doing theh sleeping
hold_vsys_en_pin.init(Pin.IN)
apparently cutting off the power supply, but how is that? Could you maybe elaborate a bit how the sleeping this way works please? :) thanks a lot, Petr
Sure. The Pico W is not particularly energy efficient for a WiFi device, so our Enviro boards include circuitry that let the Pico W physically turn off its own power.
I'm not sure how adept you are with reading schematics, but the summary is, for the Pico W to get power it needs VSYS_EN to be high (e.g. 3.3V). This can happen from the three sources you see, the Poke switch on the front of the board, the RTC alarm, and the HOLD_VSYS_EN you have spotted in the code already. USB power also wakes up the board, but that circuitry is internal to the Pico W so not shown above.
When the board wakes up, the firmware immediately HOLD_VSYS_EN to high to keep the board awake. When the board wants to go to sleep, that pin can either be set to low or to an input. In both cases, that R2 resistor makes VSYS_EN turn off. I believe there may be some minor benefit to setting HOLD_VSYS_EN to an input over setting it to low, but don't quote me on that.
The idea with the PIO watchdog is that if the board hangs at some point late on in the code (seemingly because of WiFi communication issues) then the PIO continues in the background and turns off HOLD_VSYS_EN at the specified time.
Unfortunately, these kinds of hangs are just some of the type I have observed. Others occur whilst the board is booting, before Micropython has started. In this case the PIO watchdog will not offer any benefit. It could be possible to inject the PIO watchdog during bootup, but that depends on where in the boot process those hangs occur. I need to dig out some time to explore this idea.
@ZodiusInfuser Thanks for such a prompt reply, especially on a Sunday evening :) I am not an expert in reading electrical diagrams, but I can sometimes roughly get an idea, however your explanation made it clearer. Following your reply I did a few tests. One of them was to measure the voltage on GPIO2 (hold_vsys_pin) even though I disabled the part of the init.py bringing it up as soon as possible (Pin(2, Pin.OUT, value= True). The Pin is high even without explicitly calling it. I checked that forcing the pin to go to zero it will turn the pico off as described.
I noticed that when turning on the battery pack, the activity LED ligthens up briefly and then turns off until it starts pulsating (activity_led function).
I decided to start the PIO watch as early as possible in the main.py, actually it is the first part of the main.py file. I tested it quite rigorously and it worked as expected, until I put the Pico on the position with bad wifi reception where it would hang again after an hour or so. And then again. The white LED is steady, so I measured the voltage across various pins and it was only the LED pin that had voltage (pin 9, gpio6). All other pins are zero (pins 40, 39, 38, 37..., pin 4 = gpio2).
Would you know how the LED gets voltage? BUt I can definitely observe that weak WIFI signal somehow causes these freezes. and that writing the PIO watchdog even as the first thing during boot doesn't help (how does the LED even gets started first). I checked the watchdog by purposefully hanging the processor using some while True: continue endless loop and it works. SO the hang must be happening before micropython starts...
I have a suggestion, would it be possible to talk to the RTC directly just from micropython using i2c? If so, I could just write a loop for standard micropython build and let it use this watchdog and post to influxdb some dumb data as a hearbeet signal and see, whether the hangs might originate from your custom upython builld. Thanks a lot for reading through this, greetings from Prague, Petr
The Pin is high even without explicitly calling it. I checked that forcing the pin to go to zero it will turn the pico off as described.
I noticed that when turning on the battery pack, the activity LED ligthens up briefly and then turns off until it starts pulsating (activity_led function).
So about that, we found that the time it takes Micropython to boot and get to the enable hold_vsys_pin code line was too long for quick taps of the Poke button, meaning the board would appear to never wake up. To get around this, we build a custom version of our Pirate brand Micropython that includes early enabling of hold_vsys_en and the activity LED. Technically that means that early code line is redundant, but it is left in as it lets people use the Non-Enviro specific version of our Micropython and still get the same functionality (though with the need to hold Poke for a few seconds).
I decided to start the PIO watch as early as possible in the main.py, actually it is the first part of the main.py file. I tested it quite rigorously and it worked as expected, until I put the Pico on the position with bad wifi reception where it would hang again after an hour or so. And then again. The white LED is steady, so I measured the voltage across various pins and it was only the LED pin that had voltage (pin 9, gpio6). All other pins are zero (pins 40, 39, 38, 37..., pin 4 = gpio2).
Thanks for testing this! So with what I said above, that means the board has hung somewhere between the early boot (where we turn on hold_vsys_en and the activity LED), and Micropython starting. Odd that you say that only the LED pin as voltage, as literally both that and hold are set with a single write command.
I have had these lockups before too, and attempted to diagnose them by setting pin states at various points during the booting process and reading the voltages as you have, but I could not pinpoint a single place within code where this occurred. It was certainly well before the WiFi was even touched though. Perhaps a flash read error, as I did have one case where the board would 100% lock up with the white light, and it did not recover when pressing reset.
I checked the watchdog by purposefully hanging the processor using some while True: continue endless loop and it works. SO the hang must be happening before micropython starts...
That's useful confirmation, thanks!
I have a suggestion, would it be possible to talk to the RTC directly just from micropython using i2c?
Yes, the RTC is just an I2C device that we have conveniently wrapped up. The part is the PCF85063A, and it's on address 0x51. You can see the underlying C++ code we use to talk to it here: https://github.com/pimoroni/pimoroni-pico/blob/main/drivers/pcf85063a/pcf85063a.cpp
If so, I could just write a loop for standard micropython build and let it use this watchdog and post to influxdb some dumb data as a hearbeet signal and see, whether the hangs might originate from your custom upython builld.
That sounds like a great test to do! I know our Micropython build is close to the edge of free memory, so it could well be that the things we introduce to make it a nice experience for users of our products, could be interacting with the WiFi in weird ways. There's three micropython builds you could try:
- The latest official release for Pico W
- Our general micropython release for Pico W
- The specific Enviro micropython release (i.e. one that turns the hold and activity LED on)
I would be very interested to hear your findings! For enviro there's not all that much that requires our custom Micropython that could not be written in pure Python. For Enviro Grow, the RTC, the light sensor (LTR559) and the temp/pressure/humidity sensor (BME280) are the only I2C devices that would need new drivers writing/importing.
@ZodiusInfuser Thank you for the comments, I came home and found the Grow hung after a very promising day :D I had it close to a very powerful wifi source so it definitelly lasted much longer than when the wifi reception is weak. I took my multimeter and here are teh findings: I will be using teh pin denotation, not the gpio number: on the right hand side, pins 21-40 all are 0 (even run pin 30), except, pins 24,25,26,27 having 3.3, 2.6, 2.6 and 2.6 V respecitvely. On the left side pins from 1 to 10 were zero expet either pin 9 or 10 (3.3 V) after which it was rebooted. So maybe the LED pin I was mentioning before was actually the switch-status pin 10. The further ones I could not measure as the reboot was done and hung suspended.
I will try and study how to do the I2C communication. I will study the communication and see if I can implement it somehow myself. The reason I got the Pico grow was because I wanted to build something like a weather station and getting the pico W alone without sensors would be fruitless unless u connect some sensors. And then I found the enviro grow and now I am troubleshooting. One learns so much when fixing issues, so I see it as a learning curve :) Fingers crossed
So I will report on the Pins 9 or 10 again, to confirm which one is stuck.
@ZodiusInfuser Errata to my previous comment: the pin 9 (LED pin) is 0 during a hang, but the pin 10 (GP7) is 3V but as soon as I touch it with the volt meter, it reboots.