search

pimoroni / enviro

MIT License
101 stars 79 forks source link

Open to support for running continuously? #196

Open loriendraeger opened 10 months ago

loriendraeger commented 10 months ago

I have an enviro urban and I'm looking to use it to continuously collect data instead of on a schedule, since I can keep it plugged in to USB power. I did some quick hacking of the firmware you have and can make that work, and I'm wondering if you would be open to a few PRs to support that. There are a couple other things I think I would need to improve along the way, too.

Once those are done, I was thinking about adding a config to enable a continuous mode where the board would loop over taking readings and uploading. Probably hidden from the provisioning UI to start (so config file only).

Anyway, I'm hoping this can be the start of a conversation. I don't want to promise I can definitely get all of this done either, but please let me know if you have any thoughts. Thanks!

sjefferson99 commented 10 months ago

@loriendraeger Just some thoughts as another keen consumer of the Pico Enviro project:

I also intend on running the board continuously, potentially much faster polling, but we shall see. You can see my comment on #173 which also houses a key change to the wifi code from the issue author. I have created a branch to ease adopting it, but may upgrade it to a PR crediting them as it seems to fix a key issue for a number of people crashing boards from previous issues and my own experience.

It would be good to consider this code change in your loop, as it's such a key fix and some change to the wifi behaviour is likely for a loop as per your point 2 above.

For temperature offsets I installed an offboard BME688 I had spare to try and compare offset and board heating etc, but got more inaccurate results from that than the offset BM280 on board comparing to other local weather stations. So I think some accurate local thermometer comparison and research on BME sensor calibration in general applied globally would be a good move, it's just tricky to test with only one of the boards available. I will let you know if I make any progress here in the near future. In the interim, having a simple board specific offset is a good start as it is clearly needed at a minimum.

ikonia commented 5 months ago

did a PR get raised for this ? I run my devices continuously and the wifi stability stopping/starting is not great rather than continuous connection after initial setup

sjefferson99 commented 5 months ago

@ikonia I did make a PR for the wifi improvements and I strongly recommend incorporating it into your board as it fixed a lot of issues for me running continuously for months now. That is PR #199

I did some work on the running continuously aspect with a focus on enhanced polling for wind gusts using the second core to achieve 0.25 second polls and averaging. This is almost complete, but there is a bug that occasionally generates incorrect gust values by a factor of 10 (more details in issue #115). You can see this development on my own fork at: https://github.com/sjefferson99/enviro/tree/gust_wind_multicore_polling

While developing this it become very apparent that I was moving away from the original design intent of this project which has always been low power, infrequent polling remote monitoring and upload. So far, the development on that branch is a side by side module that essentially replaces chunks of the enviro code if enabled in config. But future development will see me forking entirely and refactoring the code using the enviro code as inspiration and maybe borrowing specific functions, especially hardware interfaces and calculations.

This is due to the complete change in design approach for having a continuously running board and for now I will be merging these changes into my branch sj-develop-multicore (https://github.com/sjefferson99/enviro/tree/sj-develop-multicore) which takes enviro main as a base, then applies all my PRs for feature improvements and then will have the multicore branch pulled in and from there likely not pull in upstream changes. It will likely become a whole new repo if I pursue it further.

Part of that design is the network still shutting down and reconnecting where as a continuous board it should stay on and check it's maintained, but the new PR for wifi stability means this is not as much of an issue as it sounds for now.

I've not committed to this project for a little while as I have been working on another similar one, which is also giving me potentially useful insights into async code, but I will circle back to this soonish.

ikonia commented 5 months ago

this is great work (just reading the changes for the wifi) this looks like it's been open a while, how has this not been merged or rejected for release ?