Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Further rain issues (now in 0.0.8) #70

Closed
MrDrem opened this issue Sep 5, 2022 · 36 comments
Closed

Further rain issues (now in 0.0.8) #70

MrDrem opened this issue Sep 5, 2022 · 36 comments
Labels
bug Something isn't working fixed in patch Issues that may now be fixed in the patch branch

Comments

@MrDrem
Copy link

MrDrem commented Sep 5, 2022 •
edited
Loading

I've been playing with the rain detection, with "manually" generated rainfall, and have identified another issue with the code as it stands.

When the system is put into sleep having woken from a rain event, no wake timer is set (I suspect), and so the board doesn't start logging again for normal logging afterwards. If the 'Poke' button is pressed, this does restart logging. I think that this can be seen in 2022-09-05b log.txt.

The initial wake also recorded the 3 quick tips, but the later 2 only recorded a single tip each, despite there being more than one (this may be due to how close together the tips were though). This can be seen in 2022-09-05 rain.txt.

Hope this makes sense!
@MrDrem
Copy link
Author

MrDrem commented Sep 5, 2022 •
edited
Loading

I had also initially added the below, but have pulled it, as I think that I am not understanding what is happening correctly I am adding it here for transparency:

  1. The rain persists between uploads, I want the rain that has fallen within each logging period to be recorded, and then cleared at the end of the logging period, not kept over between logging periods.

    E.G. if I am logging every 5 minutes & uploading every 15, I want the following to happen:
    0 minutes - initial log
    2 minutes - rain tip 1
    4 minutes - rain tip 2
    5 minutes - log 2 - records 2 tip events and clears rain log
    6 minutes - rain tip 3
    8 minutes - rain tip 4
    10 minutes - log 3 - records 2 tip events and clears rain log
    15 minutes - log 4 - records 0 tip events, clears rain log (if needed) and uploads prior logs.

    Looking at my current io.adafruit.com logs, I can see that the rain uploads are cumulative, and not attached to log events correctly.
    rain
    (I'm currently logging & uploading every 5 minutes)

If I'm trying to calculate hourly/daily rainfall, I want to do it from the data records, not have the data uploaded in that form, as it prevents me from doing later calculations without lot of effort.

The issues above may be because they are a 'poke' log, rather than a timed one? If so, I would expect 'poke' logs to clear the rainfall count too.

@MrDrem MrDrem mentioned this issue Sep 6, 2022
Open
@lowfatcode
Copy link
Member

The rainfall reading is returned in millimetres per hour - therefore it has to use the previous hours worth of data to determine that value - I think that for most users this is the most convenient way for it to work since they can simply log that data to a graph or dashboard.

You could quite easily customise the firmware to return readings in the format you prefer though. Count the number of lines in rain.txt to get the event count and then delete the file - add that event count to your readings and report that. Does that make sense?

@MrDrem
Copy link
Author

MrDrem commented Sep 6, 2022

I've dug through the code around the second again, and yes, I can see what's happening now.

None of the other readings are cumulative, and the Met Office requests that they are per reading, I don't want to create a more permanent fork until the code is a bit more stable than currently, so I'll work on how to do it later.

That the rainfall stops the device from waking at the expected time is more of an issue :)

@lowfatcode
Copy link
Member

Can you link to the Met Office documentation for that please? We'll take a look.

What do you mean by it "stops waking the device at the expected time"?

@MrDrem
Copy link
Author

MrDrem commented Sep 6, 2022 •
edited
Loading

Met Office WOW data page - https://wow.metoffice.gov.uk/support/dataformats under the "Weather Data:" heading

From my log file:

18:00 all good wake expected at 18:05
18:01 rain detected
18:05 no wake.
18:16 I manually poked it and it started again

2022-09-05 18:00:02 [debug    / 115kB] > performing startup
2022-09-05 18:00:02 [info     / 123kB]   - wake reason: unknown
2022-09-05 18:00:02 [debug    / 121kB]   - turn on activity led
2022-09-05 18:00:03 [info     / 112kB] > 1 cache files need uploading
2022-09-05 18:00:03 [info     / 110kB] > connecting to wifi network 'Celestia'
2022-09-05 18:00:05 [debug    / 104kB]   - connecting
2022-09-05 18:00:08 [debug    /  90kB]   - connecting
2022-09-05 18:00:11 [info     / 118kB]   - ip address:  192.168.1.208
2022-09-05 18:00:11 [info     / 100kB]   - uploaded 2022-09-05T18:00:03Z.json to adafruit_io
2022-09-05 18:00:11 [info     /  98kB] > going to sleep
2022-09-05 18:00:12 [debug    /  95kB]   - clearing and disabling timer and alarm
2022-09-05 18:00:12 [info     /  93kB]   - setting alarm to wake at 18:05pm
2022-09-05 18:00:12 [info     /  91kB]   - shutting down
2022-09-05 18:01:23 [debug    / 115kB] > performing startup
2022-09-05 18:01:23 [info     / 123kB] > add new rain trigger at {helpers.datetime_string()}
2022-09-05 18:01:26 [debug    / 115kB] > performing startup
2022-09-05 18:01:26 [info     / 121kB] > add new rain trigger at {helpers.datetime_string()}
2022-09-05 18:01:31 [debug    / 115kB] > performing startup
2022-09-05 18:01:31 [info     / 121kB] > add new rain trigger at {helpers.datetime_string()}
2022-09-05 18:16:37 [debug    / 115kB] > performing startup
2022-09-05 18:16:37 [info     / 123kB]   - wake reason: unknown
2022-09-05 18:16:37 [debug    / 121kB]   - turn on activity led
2022-09-05 18:16:38 [info     / 109kB] > 1 cache files need uploading
2022-09-05 18:16:38 [info     / 106kB] > connecting to wifi network 'Celestia'
2022-09-05 18:16:40 [debug    / 100kB]   - connecting
2022-09-05 18:16:43 [debug    / 124kB]   - connecting
2022-09-05 18:16:45 [info     / 115kB]   - ip address:  192.168.1.208
2022-09-05 18:16:46 [info     / 116kB]   - uploaded 2022-09-05T18:16:38Z.json to adafruit_io
2022-09-05 18:16:47 [info     / 114kB] > going to sleep
2022-09-05 18:16:47 [debug    / 112kB]   - clearing and disabling timer and alarm
2022-09-05 18:16:47 [info     / 109kB]   - setting alarm to wake at 18:20pm
2022-09-05 18:16:47 [info     / 107kB]   - shutting down

@MrDrem
Copy link
Author

MrDrem commented Sep 7, 2022

So, I've just had a period of "organic" rainfall, and once again, as soon as rain was detected, the wake sequence failed, and so uploads stopped.

The below logs show
09:55:02 - Standard wake from sleep & logging
09:55:15 - Sleep set with alarm to wake at 10:00am
09:59:37 - Wake with rainfall
[10:00:00 - No wake]
10:02:47 - Wake with rainfall
[10:05:00 - No wake]
10:07:33 - Wake due to me poking the 'poke' button manually.

I'm running on my fork with more verbose logging (see #68) at the moment, hence the extra log lines.

2022-09-07 09:55:02 [debug    / 114kB] > performing startup
2022-09-07 09:55:02 [info     / 123kB]   - wake reason: unknown
2022-09-07 09:55:02 [debug    / 121kB]   - turn on activity led
2022-09-07 09:55:02 [info     / 120kB]   - config loaded
2022-09-07 09:55:02 [info     / 117kB]   - clock already set
2022-09-07 09:55:02 [info     / 101kB]   - disk space OK
2022-09-07 09:55:03 [info     /  98kB]   - wind speed started
2022-09-07 09:55:03 [info     /  96kB]   - wind sensor state got
2022-09-07 09:55:03 [info     /  94kB]   - wind sensor tick
2022-09-07 09:55:03 [info     /  91kB]   - wind sensor tick
2022-09-07 09:55:03 [info     / 122kB]   - wind sensor tick
2022-09-07 09:55:03 [info     / 119kB]   - wind sensor tick
2022-09-07 09:55:04 [info     / 117kB]   - wind speed captured
2022-09-07 09:55:04 [info     / 110kB]   - wind direction captured
2022-09-07 09:55:04 [info     / 108kB]   - sensor readings OK
2022-09-07 09:55:04 [info     / 104kB]   - cached OK
2022-09-07 09:55:04 [info     / 101kB] > 1 cache files need uploading
2022-09-07 09:55:04 [info     /  99kB] > connecting to wifi network 'Celestia'
2022-09-07 09:55:06 [debug    /  93kB]   - connecting
2022-09-07 09:55:09 [debug    / 124kB]   - connecting
2022-09-07 09:55:11 [info     / 115kB]   - ip address:  192.168.1.208
2022-09-07 09:55:15 [info     /  86kB]   - uploaded 2022-09-07T09:55:04Z.json to adafruit_io
2022-09-07 09:55:15 [info     /  84kB] > going to sleep
2022-09-07 09:55:15 [debug    / 121kB]   - clearing and disabling timer and alarm
2022-09-07 09:55:15 [info     / 119kB]   - setting alarm to wake at 10:00am
2022-09-07 09:55:15 [info     / 117kB]   - shutting down
2022-09-07 09:59:37 [debug    / 114kB] > performing startup
2022-09-07 09:59:37 [info     / 121kB] > add new rain trigger at {helpers.datetime_string()}
2022-09-07 10:02:47 [debug    / 114kB] > performing startup
2022-09-07 10:02:47 [info     / 121kB] > add new rain trigger at {helpers.datetime_string()}
2022-09-07 10:07:33 [debug    / 114kB] > performing startup
2022-09-07 10:07:33 [info     / 123kB]   - wake reason: unknown
2022-09-07 10:07:33 [debug    / 121kB]   - turn on activity led
2022-09-07 10:07:33 [info     / 120kB]   - config loaded
2022-09-07 10:07:33 [info     / 118kB]   - clock already set
2022-09-07 10:07:33 [info     / 115kB]   - disk space OK
2022-09-07 10:07:33 [info     / 112kB]   - wind speed started
2022-09-07 10:07:33 [info     / 110kB]   - wind sensor state got
2022-09-07 10:07:34 [info     / 108kB]   - wind sensor tick
2022-09-07 10:07:34 [info     / 105kB]   - wind sensor tick
2022-09-07 10:07:34 [info     / 102kB]   - wind sensor tick
2022-09-07 10:07:34 [info     /  99kB]   - wind speed captured
2022-09-07 10:07:35 [info     /  92kB]   - wind direction captured
2022-09-07 10:07:35 [info     / 125kB]   - sensor readings OK
2022-09-07 10:07:35 [info     / 121kB]   - cached OK
2022-09-07 10:07:35 [info     / 118kB] > 1 cache files need uploading
2022-09-07 10:07:35 [info     / 116kB] > connecting to wifi network 'Celestia'
2022-09-07 10:07:37 [debug    / 110kB]   - connecting
2022-09-07 10:07:40 [debug    /  96kB]   - connecting
2022-09-07 10:07:42 [info     /  87kB]   - ip address:  192.168.1.208
2022-09-07 10:07:43 [info     / 108kB]   - uploaded 2022-09-07T10:07:35Z.json to adafruit_io
2022-09-07 10:07:43 [info     / 106kB] > going to sleep
2022-09-07 10:07:43 [debug    / 104kB]   - clearing and disabling timer and alarm
2022-09-07 10:07:43 [info     / 102kB]   - setting alarm to wake at 10:10am
2022-09-07 10:07:43 [info     / 100kB]   - shutting down

I'm going to try and look at the alarm setting code, and seem if it can be added to the rainfall sleep.

@helgibbons
Copy link
Contributor

helgibbons commented Sep 7, 2022 •
edited
Loading

I think I'm seeing shenanigans with rain also - our weather station (running v0.0.8) has stopped reporting in overnight rain, just after a couple of add new rain trigger at {helpers.datetime_string()}s, as above.

@helgibbons
Copy link
Contributor

Just went out to check on our non-responsive Weather (I really need a testing setup that's not at the top of a tall pole!) and like @MrDrem 's, the board hadn't crashed, it was just asleep and was revived with a press of the poke button. So I agree that it looks like the wake up timer is not being set correctly after a rain trigger event?

This was referenced Sep 9, 2022
Open
Closed
Closed
@MrDrem MrDrem mentioned this issue Sep 28, 2022
Closed
@dave-ct dave-ct mentioned this issue Oct 31, 2022
Closed
@dave-ct
Copy link
Contributor

dave-ct commented Oct 31, 2022

New to this but if in sleep() I set a global variables for hour and minute of the alarm that is calculated last before it goes ot sleep like this:

global last_hour
global last_minute
last_hour = hour
last_minute = minute

Then in weather.py add this to the end of the startup() if statement where it goes back ot sleep

  rtc.set_alarm(0, last_minute, last_hour)
  rtc.enable_alarm_interrupt(True)

just before
hold_vsys_en_pin.init(Pin.IN)

Just wanted your thoughts before I go up my pole to test it?

@dave-ct
Copy link
Contributor

dave-ct commented Nov 3, 2022

@MrDrem @lowfatcode @helgibbons - Has anyone managed to get this to work understand what execatly needs to be done. I am happy to try it out but tried the above and did not work.

@ZodiusInfuser
Copy link
Member

@dave-ct I have looked into this and can reproduce the error. The past discussion is correct that the rain detection code path does not set the RTC alarm again, however it never unsets the RTC alarm either, so the previously set alarm should still be active in between multiple rain detections. Clearly that is not happening and I would like to understand why first before doing what you propose.

Also, I think the code path can be neatened up so that if that avenue is needed, the code can call the regular sleep() which would set the RTC with a newly calculated time.

@ZodiusInfuser ZodiusInfuser added the bug Something isn't working label Nov 4, 2022
@dave-ct
Copy link
Contributor

dave-ct commented Nov 7, 2022

@ZodiusInfuser thanks for the update, see you are doing some changes in the patch branch, let me know if you would like any help testing any of the changes you make.

@ZodiusInfuser
Copy link
Member

@dave-ct if you could test the patch branch that would be great! There's still much I need to do, but I would be curious if any of my changes so far help resolve some of people's issues. No rush though, as I've got plenty to be getting on with still.

Currently I'm trying to improve the execution order of the code so that rain detection happens quicker, as at the moment it will under report with heavy rainfall, at least in my simulated tests of filling the bucket to the top (equates to 2 ticks per second). I have no idea if that is representative of real rainfall though, so perhaps this isn't worth my time to fix?

@dave-ct
Copy link
Contributor

dave-ct commented Nov 7, 2022

2 ticks per second is pretty unrealistic as that would be about 0.6mm per second (0.2794 mm per tick) with the size of the one in the kit, if someone uses a smaller bucket on their sensor say an accuracy of 0.1mm per Tik that , for violent rain would be about 50mm per hour so 500 ticks per hour or 1 Tik roughly every 10 seconds. I think if you can get a Tik every 10 seconds recorded it should be fine.

@ZodiusInfuser
Copy link
Member

Currently it takes about 3-4 seconds for the board to wake up, process a rain event and go back to sleep. That seems awfully long to me, but is well within the 10 seconds you say so not important to address now. I'll raise this as a new issue to revisit at some point in the future.

@ZodiusInfuser
Copy link
Member

I have pushed some changes to the patch branch that should fix most of the rainfall bugs that were reported here. If any of you could retest and let me know which are still outstanding that would be great!

@ZodiusInfuser ZodiusInfuser added the fixed in patch Issues that may now be fixed in the patch branch label Nov 11, 2022
@dave-ct
Copy link
Contributor

dave-ct commented Nov 13, 2022

Been offline, will test it out tomorrow

@MrDrem
Copy link
Author

MrDrem commented Nov 13, 2022 •
edited
Loading

@ZodiusInfuser I've just tried loading the patch branch, and there are now issues around uploads.

MicroPython 9dfabcd-dirty on 2022-08-10; Raspberry Pi Pico W with RP2040

Type "help()" for more information.
%Run -c $EDITOR_CONTENT
       ___            ___            ___          ___          ___            ___       
      /  /\          /__/\          /__/\        /  /\        /  /\          /  /\      
     /  /:/_         \  \:\         \  \:\      /  /:/       /  /::\        /  /::\     
    /  /:/ /\         \  \:\         \  \:\    /  /:/       /  /:/\:\      /  /:/\:\    
   /  /:/ /:/_    _____\__\:\    ___  \  \:\  /__/::\      /  /:/~/:/     /  /:/  \:\   
  /__/:/ /:/ /\  /__/::::::::\  /___\  \__\:\ \__\/\:\__  /__/:/ /:/___  /__/:/ \__\:\  
  \  \:\/:/ /:/  \  \:\~~~__\/  \  \:\ |  |:|    \  \:\/\ \  \:\/:::::/  \  \:\ /  /:/  
   \  \::/ /:/    \  \:\         \  \:\|  |:|     \__\::/  \  \::/~~~`    \  \:\  /:/   
    \  \:\/:/      \  \:\         \  \:\__|:|     /  /:/    \  \:\         \  \:\/:/    
     \  \::/        \  \:\         \  \::::/     /__/:/      \  \:\         \  \::/     
      \__\/          \__\/          `~~~~~`      \__\/        \__\/          \__\/      

    -  --  ---- -----=--==--===  hey enviro, let's go!  ===--==--=----- ----  --  -     

2022-11-13 21:42:39 [debug    / 118kB] > performing startup
2022-11-13 21:42:39 [info     / 121kB]   - wake reason: usb_powered
2022-11-13 21:42:39 [debug    / 119kB]   - turn on activity led
2022-11-13 21:42:39 [debug    / 117kB] > 96 blocks free out of 212
2022-11-13 21:42:39 [debug    / 115kB] > taking new reading
2022-11-13 21:42:39 [info     / 110kB]   - seconds since last reading: 48
2022-11-13 21:42:42 [debug    /  98kB] > caching reading for upload
2022-11-13 21:42:42 [info     / 119kB] > 27 cache file(s) need uploading
2022-11-13 21:42:42 [info     / 117kB] > connecting to wifi network '$NAME'
2022-11-13 21:42:42 [info     / 113kB]   - ip address:  $IPADDRESS
Traceback (most recent call last):
  File "<stdin>", line 67, in <module>
  File "enviro/__init__.py", line 370, in upload_readings
AttributeError: 'module' object has no attribute 'upload_readings'

Looking around row 370, it's:

destination_module.upload_readings()

There's a load of code commented out before it, but not replaced, so I think it may be in this, as I've poked around the influxdb.py file (which is what I'm using) and I can't see what the issue is there, and it's not been touched for 2 months. Any ideas?

@ZodiusInfuser
Copy link
Member

@MrDrem That's my bad. I haven't looked at the influxdb destination file yet and it seems that have upload_reading() rather than upload_readings() as its function name. Also I suspect there's some more fundamental differences. I'll look at getting it sorted today.

Btw. Going forward I think it would be useful to have comments about the patch testing go on the draft pull request #113

@ZodiusInfuser
Copy link
Member

@MrDrem Have a go with the enviro patch now. I brought forward the upload code from v0.0.8 and improved various things (including more logging)

@MrDrem
Copy link
Author

MrDrem commented Nov 14, 2022

Now we get:

%Run -c $EDITOR_CONTENT
       ___            ___            ___          ___          ___            ___       
      /  /\          /__/\          /__/\        /  /\        /  /\          /  /\      
     /  /:/_         \  \:\         \  \:\      /  /:/       /  /::\        /  /::\     
    /  /:/ /\         \  \:\         \  \:\    /  /:/       /  /:/\:\      /  /:/\:\    
   /  /:/ /:/_    _____\__\:\    ___  \  \:\  /__/::\      /  /:/~/:/     /  /:/  \:\   
  /__/:/ /:/ /\  /__/::::::::\  /___\  \__\:\ \__\/\:\__  /__/:/ /:/___  /__/:/ \__\:\  
  \  \:\/:/ /:/  \  \:\~~~__\/  \  \:\ |  |:|    \  \:\/\ \  \:\/:::::/  \  \:\ /  /:/  
   \  \::/ /:/    \  \:\         \  \:\|  |:|     \__\::/  \  \::/~~~`    \  \:\  /:/   
    \  \:\/:/      \  \:\         \  \:\__|:|     /  /:/    \  \:\         \  \:\/:/    
     \  \::/        \  \:\         \  \::::/     /__/:/      \  \:\         \  \::/     
      \__\/          \__\/          `~~~~~`      \__\/        \__\/          \__\/      

    -  --  ---- -----=--==--===  hey enviro, let's go!  ===--==--=----- ----  --  -     

2022-11-14 17:33:21 [debug    / 120kB] > performing startup
2022-11-14 17:33:21 [info     / 111kB]   - wake reason: usb_powered
2022-11-14 17:33:21 [debug    / 123kB]   - turn on activity led
2022-11-14 17:33:21 [debug    / 121kB] > 93 blocks free out of 212
2022-11-14 17:33:21 [debug    / 119kB] > taking new reading
2022-11-14 17:33:21 [info     / 114kB]   - seconds since last reading: 931
2022-11-14 17:33:23 [debug    / 105kB] > caching reading for upload
2022-11-14 17:33:23 [info     /  94kB] > 32 cache file(s) need uploading
2022-11-14 17:33:23 [info     /  92kB] > connecting to wifi network 'Celestia'
2022-11-14 17:33:30 [info     / 112kB]   - ip address:  192.168.1.208
2022-11-14 17:33:30 [info     / 105kB] > uploading cached readings to Influxdb bucket: home
Traceback (most recent call last):
  File "<stdin>", line 67, in <module>
  File "enviro/__init__.py", line 361, in upload_readings
  File "enviro/destinations/influxdb.py", line 25, in upload_reading
KeyError: readings

Which is at least a new error :)

I might try to look at it to work it out later.

@ZodiusInfuser
Copy link
Member

Ah, that error. That's because the file format the patch branch previously used was that of v0.0.2, but as of today now matches what v0.0.8 uses. I can add a nice error for this issue, and skip over such files. Until I do unfortunately you'll either need to delete those files and start logging fresh, or open the very last file and copy the structure changes.

@MrDrem
Copy link
Author

MrDrem commented Nov 14, 2022

That's grand, and seems to be back uploading. I'll get it back outside and see how it goes,

@ZodiusInfuser
Copy link
Member

Cool. I've added a check for that error now, so it shouldn't catch others out in future.

@MrDrem
Copy link
Author

MrDrem commented Nov 15, 2022

so, it's currently raining here, and I can see that I am getting recordings back

image

I'm slightly suspicious of only ever getting on rain tick per 5 minutes though, but I've not currently got another way of measuring to check.

@ZodiusInfuser
Copy link
Member

Hmm, well that's progress at least. I'm not sure how much liquid the rain tipper can actually store. The fact there's 10 minute periods without a reading suggests its not heavy rain though.

@daved38
Copy link

daved38 commented Nov 15, 2022

updated all the files yesterday, been running ok overnight indoors with no sensors. just taking weather station out side and connected sensors. its raining now.

Dont think bucket stores the rain. its tip and release. heavy rain might make it rattle lol

Some minor observations: Running on LiPo but voltage is reading as Zero. I use Adafruit-io can see youve created a new rainfeed i.e weather-stat-1-rain-per-second.

Waiting on first rain report

@ZodiusInfuser
Copy link
Member

ZodiusInfuser commented Nov 15, 2022 •
edited
Loading

Thanks for testing. Battery voltage measuring is currently disabled as the way that was done previously caused issues with the WiFi and boards locking up.

Yes, there's rain which is the amount of rain that fell since the last reading, and rain-per-second which uses the time between the new reading and the last reading to work out an average. If you're measuring consistently at 5 minutes for example, then that value should equal rain / 5 * 60. If you're not, if say you're pressing the Poke button to take readings, then that average may be more consistent than the rain reading.

@daved38
Copy link

daved38 commented Nov 15, 2022

we have rain....

image

@daved38
Copy link

daved38 commented Nov 15, 2022

All good for about 2 hours then no further reporting. Went out to recover weather station when rainstopped!

Have added log_usb file when connecected via USB. Shows halt at 12:19 and USB restart at 16:23
log_usb.txt

Attempted restart then "add new rain trigger" looped. see shell.log
shell.txt

Further restart failed, so removed rain.txt
Futher attempt looped again with rain.txt being recreated!
Futher attempt after removing rain.txt and last_time.txt same result.

looks like might have to flash the Enviro-Weather!!

@ZodiusInfuser
Copy link
Member

Sorry about this! It looks like there's three separate issues going on here, though it's not obvious at first glance why. I'll investigate when I'm next working.

@MrDrem
Copy link
Author

MrDrem commented Nov 17, 2022

image

So yes, multiple rain triggers in the same 5 minutes are working too! (4 tips in one 5 minute period at one point!)

I think that @daved38 may be using an MQTT based upload method (adafruit.io?) which may be causing the halts. Switching to a local InfluxDB instance solved this for me (not suggesting everyone should do this, just that I don't think their issues are related to the rain code).

@daved38
Copy link

daved38 commented Nov 18, 2022 via email

@dave-ct dave-ct mentioned this issue Nov 18, 2022
Closed
@dave-ct
Copy link
Contributor

dave-ct commented Nov 18, 2022 •
edited
Loading

I have been testing this evening on the latest patch branch. @daved38 I just copied my config file (did not want to reprovison) and then deleted everything on the PICO, flashed with the latest pimoroni picoW firmware (not enviro one), synced enviro repo with GitHub Desktop and switched to patch branch then just copied over (using Thonny) the synced enviro and phew folder plus the main.py file. Finally added my config file back.

So far all good for rain readings running outside on battery, just tipped a little water in two ticks each time which gets recorded correctly. This is using mqtt for the destination but to a local mqtt broker I have setup. Will monitor over the next few days to see if any other issues pop up.

2B0101BA-68BE-495A-B9D1-4534B4316EFC

@ZodiusInfuser
Copy link
Member

@daved38 I have just pushed a fix to the patch branch for the spamming of add new rain trigger that you saw. From my testing it seems this was caused when on USB and the rain bucket doesn't fully tip, causing the trigger to remain active. I have now added code that requires the trigger to go low again before it will accept a new high reading.

@ZodiusInfuser
Copy link
Member

There is a new release that may fix this issue: https://github.com/pimoroni/enviro/releases/tag/v0.0.9
I'll therefore close this but please re-open it or raise a new issue if you update and experience the problem again. Thanks

This was referenced Aug 29, 2023
Open
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working fixed in patch Issues that may now be fixed in the patch branch
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@lowfatcode @MrDrem @ZodiusInfuser @dave-ct @helgibbons @daved38