programs aren't triggering

[tomnykds]

With a new RPi 2+, fresh OS install, new OSPi, with App version 1.8.1, firmware 2.1.8 (1), the programs I set up either with or without starting at sunrise with Zimmerman algorithm, aren’t triggering. System Diagnostics show that the Last Weather Call is in the last few minutes and it was successful. The time and TZ are correct on the RPi. I’ve tried several variations of program setup, and a few ran automatically once, but that’s about it. I’ve seen mentioned weather status icons on the main page, but I don’t have that on the web view. There’s almost no logging about what’s going on. How do i proceed with debugging the issue? I’m a linux veteran, and prefer xterm type solutions, but certainly open to what’s useful to give helpful feedback.

I’ll leave comments on Log view to later, but on that front, it would be really nice to have an automatic view of the last two days, that ha consistent scale. Having to update the date range is less than optimal, and the scale on the timeline seems to be all over the map. Table is better to me.

Thx, Chris

[tomnykds]

So, I figured out how to dump the state of the system with >>> contents = urllib2.urlopen(“http://192.168.0.69:8080/ja?pw=xxxx”).read(),
and I still can’t figure out why the programs (#5 specifically) isn’t triggering. I’d like to see logs of how the scheduler is deciding
to start or not start a station. I’ve found plenty of DEBUG_PRINT statements in the code, but don’t know how to enable them. This
is what’s in the logs. Can’t make sense of what it means, though.
pi@pi2b:~/OpenSprinklerGen2 $ cat logs/17747.txt
[0,”wl”,0,1533343998]
[0,”wl”,0,1533351200]
[0,”wl”,0,1533358402]
[0,”wl”,1,1533365604]
[0,”wl”,57,1533372806]
[0,”wl”,77,1533380008]
[0,”wl”,91,1533387210]
[0,”wl”,114,1533394412]
[0,”wl”,118,1533401614]

>>> print json.dumps(parsed, indent=4, sort_keys=True)
{
“options”: {
“con”: 150,
“den”: 1,
“devid”: 0,
“dexp”: -1,
“dim”: 50,
“dns1”: 8, “dns2”: 8, “dns3”: 8, “dns4”: 8, “ext”: 0,
“fpr0”: 100,
“fpr1”: 0,
“fwm”: 1,
“fwv”: 218,
“hwv”: 64,
“hp0”: 144, “hp1”: 31, “hwt”: 255,
“ife”: 0, “ipas”: 0,
“lg”: 1,
“lit”: 100,
“mas”: 0, “mas2”: 0,
“mexp”: 8, “mtof”: 0, “mtof2”: 0, “mton”: 0, “mton2”: 0,
“ntp1”: 50, “ntp2”: 97, “ntp3” : 210, “ntp4”: 169, “re” : 0,
“reset”: 0, “rso”: 0, “sar” : 0, “sdt”: 0, “sn2o” : 0, “sn2t”: 0,
“tz”: 20,
“urs”: 0,
“uwt”: 1,
“wl”: 0
},
“programs”: {
“pnsize” : 20
“mnp” : 34,
“mnst” : 4,
“nboards” : 1,
“nprogs” : 3,
“pd”: [ [ 3, 127, 0, [ 360, 0, 0, 0 ], [ 480, 480, 480, 480, 480, 480, 480, 0 ], “Program 5” ],
[ 3, 127, 0, [ 480, 0, 0, 0 ], [ 60, 60, 60, 60, 0, 0, 0, 0 ], “Program 4” ],
[ 0, 127, 0, [ 16384, 0, 0, 0 ], [ 60, 60, 60, 60, 60, 60, 60, 0 ], “Program 36” ],
],
“settings”: {
“devt” : 1533279729,
“lswc” : 1533279180,
“lwc” : 1533279180,
“sunrise” : 359,
“sunset” : 1238,
“eip” : 842338188,
“en” : 1,
“ifkey” : “”,
“loc” : “45.45015,-122.88491”,
“lupt” : 0,
“nbrd” : 1,
“rd” : 0,
“rdst” : 0,
“rs” : 0,
“sbits” : [ 0, 0 ],
“wtkey” : “”,
“wto”: { “bh” : 30, “br” : 0, “bt” : 69.98, “h” : 100, “r” : 100, “t” : 100 }
“lrun” : [ 3, 3, 21, 1532937685 ],
“ps” : [ [ 0, 0, 0 ],
[ 0, 0, 0 ],
[ 0, 0, 0 ],
[ 0, 0, 0 ],
[ 0, 0, 0 ],
[ 0, 0, 0 ],
[ 0, 0, 0 ],
[ 0, 0, 0 ] ],
},
“stations”: {
“ignore_rain” : [ 0 ],
“masop” : [ 255 ],
“masop2” : [ 0 ],
“maxlen” : 24,
“snames” : [ “S01”, “S02”, “S03”, “S04”, “S05”, “S06”, “S07”, “S08” ],
“stn_dis” : [ 128 ],
“stn_seq” : [ 255 ],
“stn_spe” : [ 0 ]
},
“status”: {
“nstations”: 8,
“sn”: [ 0, 0, 0, 0, 0, 0, 0, 0 ]
}
}

[tomnykds]

I have more details… Looking at the log, I see that the percentage offset based on the Zimmerman method returns, to me, unexpected values, depending on the time of day it checks. I’d expect that the percentage offset would be the same all day based on yesterday’s weather and today’s forecast. It appears that the calculation is done based on the current temp, not the forecast high for the day, which would explain why programs set to run early would end up with no watering time after the offset, and programs that run later have >100%. Where can I get more info on how this Zimmerman method calculates the offsets? The code isn’t part of OpenSprinkler.

3rd value is % offset of run-time for the valves
pi@pi2b:~/OpenSprinklerGen2 $ grep wl logs/17749.txt
[0,”wl”,1,1533519861]
[0,”wl”,0,1533527063]
[0,”wl”,18,1533534265]
[0,”wl”,30,1533538615]
[0,”wl”,30,1533539666]
[0,”wl”,100,1533546868]
[0,”wl”,150,1533554070]
[0,”wl”,138,1533561272]
[0,”wl”,152,1533568474]

Thx, Chris

[Samer]

This is a known issue with the OpenWeather Maps implementation of the Zimmerman method. That API charges a ridiculous amount for historical data and it was wired up to use current weather forecast. We are working to improve this but currently this is not ready yet.

The source for the weather adjustments is available here: https://github.com/OpenSprinkler/OpenSprinkler-Weather

We welcome any pull requests you may have and also allow you to run the service yourself and point OpenSprinkler to it by using http://OSIP/su.

[tomnykds]

Thanks. I’ve pulled the repo and can more-or-less read the code.
What’s the state of finding an improved solution? I’m happy (and motivated)
to help, but don’t want to duplicate already done work.

Is there a quick start on how to host this locally on my own? I’ve got a linux box
with a running httpd and the like. Is it just a matter of a web page with
the .js plugged into it?

Thx, Chris

[tomnykds]

Samer, not sure the status of your changes to fix this, but I managed to get the weather server running locally and still using OWM data found a way to get the high/low temps and low humidity for the next day or so. If you want to see the changes, I can email offline.
Chris

[Author]

Posts