That should go when you save it (also the āClick to setā)
I think also that after the initial save at the bottom when 1st assigning the driver, you need to click the upper āsaveā button as Iāve noticed that the lowes āsaveā doesnāt always save the settings.
Basically the Time entry doesn't work right using Firefox on my Mac.
And the error was eliminated... however, maybe you can detect null (empty fields) and use a default?
I've been using "Elvis'" a lot for this:
offset = offset ?: 0
where 0 is the default for that. It doesn't fix the error of not entering a value, if just makes the error easier for someone to read.
Installed easily and the settings, save for "Day Cutoff", were very intuitive. I like the idea of everything being in a driver - works especially well for me since my system is still on ST so I can simply use Other Hub to send the switch to ST.
Thanks for all your hard work and ingenuity. I'll send any idea your way.
I do need to understand how the "days" work. I run mine at 4:00am. Is Today's Rain what is forecast or just what has actually fallen from midnight to 4am? Similarly, at 4am, is yesterday the 24 hours period that ended at the just-passed midnight?
I'm wondering if I'm better off throwing the switch at 11:59pm, thereby collecting the daily data at the end of the day, but then delaying action on the switch until 4am. This presupposes that total rainfall for the day is provided by WU and can be reported at 11:59pm.
Youāre welcome!
It was/is an interesting exercise
ok... it seems to me that WU uses midnight to start a new day
So, if you start the switch at 4am then todayās data would only be from midnight to 4 am
Yesterday would be the period upto midnight.
My intended use is to use the switch to remind me to water (if not enough) via āmp3 event playerā at around 6pm so for me, most of the day is gone. I think it would work for me āas isā.
However; I think your idea of switching at 11:59 pm would probably work better for you.
Iāll have to think about this for a while and see if I can come up with something that fits both scenarios.
In the meantime, if I get time tomorrow, Iāll look at adding day restrictions.
I have created a new 'Check Criteria Time' setting.
For your use case... If you set this to 23:59 but still leave the time to turn on as 4am then it will do the following:
Check go/nogo at 23:59 and retain the data
Using the previously stored data (go/nogo) it will trigger the switch 'on' if criterias matched.
At least that's the theory
I've also added a new temporary button.. "Calculate Now" which is just for testing
I'll remove it when we are done testing
Thanks, Andy. You're really going above and beyond! I'm away for a few days doi won't be able to try it until Tue, but it looks like you've hit all the hit buttons. Even thought I'm not home, some torrential downpours are on the way, so I'll be able to evaluate the rainfall, past and present.
@CAL.hub
Iām having real problems getting the driver to restrict action to certain days.
I have tried loads of different ways to code it but it seems a driver is not the place for those restrictions.
However; I too only really want it to work on certain days.
So it looks like a little helper app to enforce the restrictions.
Still looking at options but Iām not sure what Iāll come up with
I think if I write an app then it might be useful to apply restrictions to other things that donāt have them.
In most of my apps I usually restrict the following optional things
Presence
Time
Days
Mode
Obviously we would just be able to apply day restrictions
I just returned and updated the driver to 1.1.0. Testing underway.
I ran into a problem testing the prior version - user error. We had two days of significant rain Saturday & Sunday, but your driver didn't record any. Pretty sure the problem is the station; for some reason, my zip code mapped to a PWS nearby that didn't report precipitation. Fortunately, your driver reports the StationID, so I could deduce the problem and change it to an NWS airport station.
Regarding day restrictions.... I'm not sure they're necessary. In my use-case, I have to have some other app already to actually program the irrigation zone timers. For now, that's a webCoRE piston.
I may use a Rule Machine condition in the future. Either way, it's not a problem to put the day restrictions there.
I did some cleanup of the code (lots of stuff was commented out during testing etc)
I have removed the 'autopoll' switch and put 'Manual Poling Only' as an option in the drop-down for polling interval.
There was an error in the calculation which meant that day 4 was added twice instead of day4 and day5
Also a slight re-order of settings to try and make it look better on both desktop & mobile devices.
Ok.
To be honest, this is now working great for me and is exactly what I wanted out of this.
Hopefully it fulfills your needs too
In which case I'll change the thread title to reflect the status
(Unless it doesn't work when you test! )
The design is spot-on for what I need and, AFAIK, it's working just right. The only caveat is that I don't have any rain (maybe in a couple of days) so I can't say the whole end-to-end solution, which includes user error, actually works. But, I've upgraded to 1.2 and ready for some precip.
Surprisingly.. we have not had any rain in my part of the UK for a week!
So (although I've faked it a few times by 'watering' the weather station) I've not done a real world test yet.
I believe rain is coming (according to the driver) so we will see in a few days.
I will also need to spend some time thinking about my threshold.
@CAL.hub
I'm going crazy with this thing.. should be simple.
One thing to note..
After changing the driver you need to click the bottom save button
then you MUST click the top save button to update everything (including the version number)
Unfortunately I don't have time to look at this right now as I'm packing for another week, working away.
Leaving in an hour
I'll have a look as soon as I'm back