I’m wondering if I have a hardware (BME280) fault on the EnviroGrow PicoW Aboard recently delivered. Initially setup indoors without making any changes to the supplied software, with readings taken every 15 minutes. Every fourth temperature reading (ie once per hour) is approximately 2 degrees higher than all the others. The humidity values (which will be calculated based on the temperature) are correspondingly lower (by about 6%) at the same timepoints. The moisture readings are stable. The Light values do have some spikes, but don’t seem to have any pattern, so may be OK.
Otherwise: The temperature readings are persistently several degrees too high - may just be that calibration is needed. There are some spikes in Lux to about 42,000 which I think is incorrect as the other values look reasonable at 0 to 4000.
Temperature values from overnight where they should be stable:
2354: 27.07 HIGH
0009: 25.01
0024: 24.99
0039: 24.97
0054: 27.07 HIGH
0109: 24.98
0124: 24.99
0039: 24.91
0054: 26.9 HIGH
Are these the times when Enviro is connecting to the wireless by any chance - we’ve noticed the board gets a degree or two warmer when the wireless is fired up. I’m using Grafana for my graphs which lets you apply a moving average to your graphs to smooth out the readings - don’t think you can do that in Adafruit.io though!
It could be, I will check later.
But if that’s the case you should fix it in the software - ie take all the readings per schedule, and only after they have been taken, bootup the Wifi. That should be easy!
Looks like you’re reading / posting data quite often there which why your board might be getting warmer!
The one I’ve got hooked up to Adafruit.IO is reading every half hour and posting every few readings which makes for a smoother graph - my spikes are from when we had the aircon on!:
It’s reading every 15 min, which is the default!
I’m in Glasgow and it really isn’t hot! It’s 18C outside and maybe 21 inside. That’s why I also said some calibration seems needed.
“Other side of the board” is VERY close indeed.
Try reducing the frequency of WiFi updates (from every 4th reading to every 10th, or similar) and you’ll see the spike frequency decrease
I think that there’s a link, and I’m sure reducing the number of uploads would show a change however I can’t see it being from heating up the board.
It’s not like it’s a heating element!
With the board only on long enough to take the readings and the push them online I can’t see it heating the board up by the 2°C we’re seeing.
Just some quick maths, if the WiFi was heating the air around the board (as that’s much easier than the denser PCB), you’d need 2.4kJ of energy, or 0.627watt hours to heat the 10cm³ around the board.
The datasheet shows the WiFi module consumes at most 320mA.
If we assumed the board was on for a full minute with WiFi going, and we convert watt hours to a single minute the WiFi would need to be consuming 40w!
This would need 12Amps from the battery, this I’m fairly sure AA can’t provide.
As the board is only on for a few seconds, not a full minute this would be worse.
It’s more likely that there’s a power supply or timing issue.
It’s possible that the WiFi module is spiking the power and dropping the voltage as the sensor is taking a reading.
This is not a complaint per say, just an observation. One drawback to having your sensor mounted on the main board is heat transfer when something is working hard.
I’ve run into heat transfer issues several times. It’s even more of an issue if its a Pi versus a Pico.
I soldered a BME280 to my Tufty, even left a little gab between the boards. Temperature read high due to heat transfer from the main board. Likely the display driver chip.
Second time around I used the Qwicc connector and a cable. Breakout mounted away from the Tufty. Temps read accurate now.
What might work, if possible, is don’t take any readings while the WIFI is doing its thing?
Someone on Twitter commented that they saw temperature spikes when posting data into a free adafruit.io account - turns out they were exceeding the data limits for a free account, causing adafruit.io to reject the request (and presumably, for the Enviro to keep repeatedly trying to send it, causing the wifi module to get warm).
If you run main.py from Thonny whilst the Enviro is plugged into a computer it should be possible to see if it’s trying to make repeated requests?
I’m not seeing any suspiciously timed temperature spikes - but I do have a paid account which has higher rate limits! Data from Pirate Towers is here if anyone’s interested :)
I’m not sure what the data limit for free accounts is, but it’s not that low.
I’m seeing no data limit problem with 10 sensors reporting every 3 minutes at IO - Feed: Cortmalaw Outdoor Ammonia (adafruit.com)
(That’s a Pimoroni Enviroplus on a Pi Zero W, with added Geiger counter).
Now this is odd. Despite what I wrote above, running main.py through Thonny does give rate errors (see below). Also, on adafruit.io, there is a warning: “THROTTLE WARNING: 7 actions requested, 6 remaining”
Thonny is showing:
2022-08-16 09:28:43 [debug / 106608] > performing startup
2022-08-16 09:28:43 [debug / 104912] - hold vsys_en high
2022-08-16 09:28:43 [info / 103136] - wake reason: unknown
2022-08-16 09:28:43 [debug / 101408] - turn on activity led
2022-08-16 09:28:44 [debug / 96960] > 76 blocks free out of 212
2022-08-16 09:28:46 [info / 118448] > 6 cache files need uploading
2022-08-16 09:28:46 [info / 103376] > connecting to wifi network ‘TribergL’
2022-08-16 09:28:51 [info / 124592] - ip address: 192.168.1.86
2022-08-16 09:28:52 [info / 100992] - uploaded 2022-08-16 08:46:05.json
2022-08-16 09:28:54 [info / 111408] - uploaded 2022-08-16 09:01:05.json
2022-08-16 09:28:55 [info / 97152] - uploaded 2022-08-16 09:16:05.json
2022-08-16 09:28:56 [info / 82896] - uploaded 2022-08-16 09:16:23.json
2022-08-16 09:28:56 [info / 114752] - rate limited, cooling off for thirty seconds
2022-08-16 09:29:27 [error / 98080] ! failed to upload ‘2022-08-16 09:17:03.json’ (429 b’Too Many Requests’) 2022-08-16 09:17:03.json
2022-08-16 09:29:28 [info / 83424] - rate limited, cooling off for thirty seconds
2022-08-16 09:29:58 [error / 114384] ! failed to upload ‘2022-08-16 09:28:46.json’ (429 b’Too Many Requests’) 2022-08-16 09:28:46.json
2022-08-16 09:29:59 [info / 112448] > going to sleep
2022-08-16 09:29:59 [debug / 110576] - clearing rtc alarm flags
2022-08-16 09:29:59 [info / 108368] - setting timer to wake in 15 minutes
2022-08-16 09:29:59 [info / 106416] - shutting down
2022-08-16 09:29:59 [debug / 104416] - on usb power (so can’t shutdown) halt and reset instead
Checking, the limit for free accounts is 30 data points per minute. EnviroGrow sends 7 data points per measurement (moisture 1, 2, 3, temp, press, hum and lux), so it should stand FOUR sets at a time, but no more. I’ll try that. Also, adafruit_io.py only waits for 30 seconds if there is overload - I’ll chnage it to wait 60 seconds to ensure it’s a ‘new minute’
Yeah, that 429 error is the one - let us know how it goes! Looks like the 30 second time.sleep lives in enviro/destinations/adafruit_io.py if you want to try changing it (though it’s probably better to avoid triggering it if you can - the Pico staying awake unnecessarily for a minute at a time won’t be great for avoiding temperature spikes or conserving battery power).
I’m getting that ‘throttle warning’ message on the website when something posts in a load of readings at once too - I think that just means the data is in a queue at the Adafruit.io end and waiting to be processed. As far as I can tell, it doesn’t seem to cause any problems for the Enviro and nothing seems to be getting lost.
Jealous of your Geiger counter sensor :) Do you see much variation?
Yes changing to 60 seconds worked (see below), though I agree better to avoid triggering the problem by restricting to maximum “upload_frequency = 4”, which is 28 data points.
PS: running main.py through Thonny doesn’t work properly, as it does not sleep when attached to USB power. 5 minutes after the ‘halt and reset’, the board does a ‘HARD RESET’ which loses the connection to Thonny.
RE: Geiger counter. I installed it as there were rumours that ‘workings’ at a nearby waste site were disturbing nuclear waste. I got unbelievably large daytime readings at first - turned out to be because the Geiger tube is light sensitive (some are, some aren’t, at random!), not matching their working hours. It’s now mounted in a dark bird box, but you can still see rises paralleling the Lux readings. I don’t see anything to make me glow in the dark (yet).
This issue with temperature spikes has disappeared after I updated the board firmware (the suggested solution for a different issue [crash during log file truncating]).
See my recent plots at IO - Soil Moisture (adafruit.com)
