Opensprinkler Keeps changing to wrong date in firmware 2.1.5

[John]

I upgraded the firmware to 2.1.5 yesterday and now my opensprinkler can not keep the right date. At the moment it is saying it is Thursday 3 Aug 2017 when it is Tue 12 Jan 2016.

Even when I set the correct date, at some point the system changes to this future date.

If I set NTP Sync, the system will sync and display the right date, but when I check back later it has jumped forward to Aug 2017 again. If I disable NTP Sync and manually set the right date it works at first. But again, when I check back later it has jumped forward to Aug 2017.

I have my Time zone set to GMT +10 and my location set. Although it doesn’t seem to recognise that it is currently DST so the time is one hour slow. Other than that, the time is ok.

[Daniel]

It seems that you have found the way to travel to the future ! 😉

[John]

Today the date on the system is showing as Fri 4 Aug 2017 ?

[DaveC]

Hi John,
Getting some info from your system might be helpful in trying to get a handle on where things are going wrong.
How long does it take before the date changes? An hour, a day?
Here’s a suggestion for gathering data:
Export your config and save the data (in OS’s current incorrect date state).
Set the time (with NTP off).
Export the config data and save the “working” state.
Start regularly issuing the following “jc” request from a browser once an hour or so (this may a bit inconvenient so whatever you can do will help). Record the data that comes back. The idea here is try to see the before and after info data and approximately when does it occur relative other activities.
Once you see date change and have a “jc” response after it changes, export the config again.

Share all the data here and maybe it’ll provide a clue.
Ray may have other ideas of suggestions.

“jc” command:
http://[your OS’s IP]/jc?/pw=[MD5 hash of your OS password]
Here’s an example:
http://192.168.1.80/jc?/pw=944c6d5d72868e442a3dda88297ac500
It should return something like:
{“devt”:1451485502,”nbrd”:3,”en”:1,”rd”:0,”rs”:0,”rdst”:0,”loc”:”Ault, Colorado”,”wtkey”:””,”sunrise”:443,”sunset”:1001,”eip”:**********,”lwc”:1451483951,”lswc”:1451483951,”lrun”:[8,6,1540,1451467541],”sbits”:[0,0,0,0],”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],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0]],”wto”:{}}

[John]

When I just had a closer look it appears to set the incorrect date as in under 2 minutes from when it is set correctly.

This is the export from the correct date:
{"programs":{"nprogs":3,"nboards":1,"mnp":14,"mnst":4,"pnsize":12,"pd":[[1,127,0,[480,1,480,0],[0,420,0,0,0,0,0,0],"PlanterBoxes"],[51,1,2,[1800,1,480,0],[0,420,0,1800,0,0,0,0],"RockGarden"],[51,0,2,[1740,0,0,0],[0,0,1800,0,0,0,0,0],"FruitTrees"]]},"stations":{"masop":[222],"ignore_rain":[0],"masop2":[0],"stn_dis":[0],"rfstn":[0],"stn_seq":[254],"snames":["Master","Planter Boxes","Fruit Trees","Rock Gardens","Rear Spare01","Rear Spare 02","S07","S08"],"maxlen":16},"options":{"fwv":215,"tz":92,"ntp":0,"dhcp":1,"ip1":192,"ip2":168,"ip3":1,"ip4":100,"gw1":192,"gw2":168,"gw3":1,"gw4":254,"hp0":88,"hp1":0,"hwv":21,"ext":0,"sdt":0,"mas":1,"mton":0,"mtof":0,"urs":0,"rso":1,"wl":100,"den":1,"ipas":0,"devid":0,"con":110,"lit":100,"dim":15,"uwt":1,"ntp1":54,"ntp2":252,"ntp3":129,"ntp4":186,"lg":1,"mas2":0,"mton2":0,"mtof2":0,"fwm":2,"reset":0,"dexp":0,"mexp":5,"hwt":172},"status":[0,0,0,0,0,0,0,0],"settings":{"devt":1452783597,"nbrd":1,"en":1,"rd":0,"rs":0,"rdst":0,"loc":"-35.28200,149.12868","wtkey":"xxxxxxxxxxxx","sunrise":360,"sunset":1080,"eip":0,"lwc":1501945023,"lswc":0,"lrun":[0,0,0,0],"sbits":[0,0],"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]]}}

This is the export from the incorrect date:
{"programs":{"nprogs":3,"nboards":1,"mnp":14,"mnst":4,"pnsize":12,"pd":[[1,127,0,[480,1,480,0],[0,420,0,0,0,0,0,0],"PlanterBoxes"],[51,0,2,[1800,1,480,0],[0,420,0,1800,0,0,0,0],"RockGarden"],[51,1,2,[1740,0,0,0],[0,0,1800,0,0,0,0,0],"FruitTrees"]]},"stations":{"masop":[222],"ignore_rain":[0],"masop2":[0],"stn_dis":[0],"rfstn":[0],"stn_seq":[254],"snames":["Master","Planter Boxes","Fruit Trees","Rock Gardens","Rear Spare01","Rear Spare 02","S07","S08"],"maxlen":16},"options":{"fwv":215,"tz":92,"ntp":0,"dhcp":1,"ip1":192,"ip2":168,"ip3":1,"ip4":100,"gw1":192,"gw2":168,"gw3":1,"gw4":254,"hp0":88,"hp1":0,"hwv":21,"ext":0,"sdt":0,"mas":1,"mton":0,"mtof":0,"urs":0,"rso":1,"wl":100,"den":1,"ipas":0,"devid":0,"con":110,"lit":100,"dim":15,"uwt":1,"ntp1":54,"ntp2":252,"ntp3":129,"ntp4":186,"lg":1,"mas2":0,"mton2":0,"mtof2":0,"fwm":2,"reset":0,"dexp":0,"mexp":5,"hwt":172},"status":[0,0,0,0,0,0,0,0],"settings":{"devt":1501945305,"nbrd":1,"en":1,"rd":0,"rs":0,"rdst":0,"loc":"-35.28200,149.12868","wtkey":"xxxxxxxxxxx","sunrise":360,"sunset":1080,"eip":0,"lwc":1501945023,"lswc":0,"lrun":[0,0,0,0],"sbits":[0,0],"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]]}}

This is the jc response when the date is correct
{“devt”:1452783631,”nbrd”:1,”en”:1,”rd”:0,”rs”:0,”rdst”:0,”loc”:”-35.28200,149.12868″,”wtkey”:”xxxxxxxxxxx”,”sunrise”:360,”sunset”:1080,”eip”:0,”lwc”:1501945023,”lswc”:0,”lrun”:[0,0,0,0],”sbits”:[0,0],”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]]}

This is the result JC response after the date changes to the future
{“devt”:1501945283,”nbrd”:1,”en”:1,”rd”:0,”rs”:0,”rdst”:0,”loc”:”-35.28200,149.12868″,”wtkey”:”xxxxxxxxxx”,”sunrise”:360,”sunset”:1080,”eip”:0,”lwc”:1501945023,”lswc”:0,”lrun”:[0,0,0,0],”sbits”:[0,0],”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]]}

[DaveC]

I don’t know why your time gets reset to the future yet, though I’ve been rummaging around in the code to see if I can find some correlation with the data coming from your system.

I do know that the regular server connections (aka weather calls) are failing. I suspect this may related to the problem I’ve seen (described in https://opensprinkler.com/forums/topic/issues-with-weather-data/ ) where server calls fail when the “loc” is in the lat,long format.

I think the reason that your offset from GMT is an hour off is a consequence to the server call failure. I’m pretty sure that the DST adjustment comes as feedback from the server call.

Some things to try:
From a browser issue the following and see what responses you get
http://weather.opensprinkler.com/weather0.py?loc=-35.28200,149.12868
http://weather.opensprinkler.com/weather0.py?loc=Canberra,%20Australia

Edit your exported config that has the correct time (the one with “devt”:1452783597):
Change the value in “lwc” from 1501945023 to something less than the current time. 1452783631 should be OK because it’s one of the current times that got yesterday.
Change the string in “loc” from ”-35.28200,149.12868″ to “Canberra,%20Australia”.

Import that config and restart the controller.
Perform the same experiment that you did before.

[John]

http://weather.opensprinkler.com/weather0.py?loc=-35.28200,149.12868

Returns:
Error: No weather data found.

http://weather.opensprinkler.com/weather0.py?loc=Canberra,%20Australia
Returns:
&scale=-1&rd=-1&tz=92&sunrise=364&sunset=1222&eip=2092151838

I edited the config file and rebooted the OpenSprinkler unfortunately the problem persists

Config file with correct date:
{"programs":{"nprogs":3,"nboards":1,"mnp":14,"mnst":4,"pnsize":12,"pd":[[51,1,2,[1800,1,480,0],[0,420,0,1800,0,0,0,0],"RockGarden"],[51,1,2,[1800,1,480,0],[0,420,0,1800,0,0,0,0],"RockGarden"],[51,0,2,[1740,0,0,0],[0,0,1800,0,0,0,0,0],"FruitTrees"]]},"stations":{"masop":[222],"ignore_rain":[0],"masop2":[0],"stn_dis":[0],"rfstn":[0],"stn_seq":[254],"snames":["Master","Planter Boxes","Fruit Trees","Rock Gardens","Rear Spare01","Rear Spare 02","S07","S08"],"maxlen":16},"options":{"fwv":215,"tz":92,"ntp":1,"dhcp":1,"ip1":192,"ip2":168,"ip3":1,"ip4":100,"gw1":192,"gw2":168,"gw3":1,"gw4":254,"hp0":88,"hp1":0,"hwv":21,"ext":0,"sdt":0,"mas":1,"mton":0,"mtof":0,"urs":0,"rso":1,"wl":100,"den":1,"ipas":0,"devid":0,"con":110,"lit":100,"dim":15,"uwt":1,"ntp1":54,"ntp2":252,"ntp3":129,"ntp4":186,"lg":1,"mas2":0,"mton2":0,"mtof2":0,"fwm":2,"reset":0,"dexp":0,"mexp":5,"hwt":172},"status":[0,0,0,0,0,0,0,0],"settings":{"devt":1452884409,"nbrd":1,"en":1,"rd":0,"rs":0,"rdst":0,"loc":"Canberra, Australia","wtkey":"xxxxxxxxx","sunrise":360,"sunset":1080,"eip":0,"lwc":1452884367,"lswc":0,"lrun":[0,0,0,0],"sbits":[0,0],"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]]}}

JC Response with correct date:
{"devt":1452884454,"nbrd":1,"en":1,"rd":0,"rs":0,"rdst":0,"loc":"Canberra, Australia","wtkey":"xxxxxxxxxx","sunrise":360,"sunset":1080,"eip":0,"lwc":1452884422,"lswc":0,"lrun":[0,0,0,0],"sbits":[0,0],"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]]}

Config file after the date jumps to the future:
{"programs":{"nprogs":4,"nboards":1,"mnp":14,"mnst":4,"pnsize":12,"pd":[[51,0,2,[1800,1,480,0],[0,420,0,1800,0,0,0,0],"RockGarden"],[51,0,2,[1800,1,480,0],[0,420,0,1800,0,0,0,0],"RockGarden"],[51,1,2,[1740,0,0,0],[0,0,1800,0,0,0,0,0],"FruitTrees"],[51,0,2,[1740,0,0,0],[0,0,1800,0,0,0,0,0],"FruitTrees"]]},"stations":{"masop":[222],"ignore_rain":[0],"masop2":[0],"stn_dis":[0],"rfstn":[0],"stn_seq":[254],"snames":["Master","Planter Boxes","Fruit Trees","Rock Gardens","Rear Spare01","Rear Spare 02","S07","S08"],"maxlen":16},"options":{"fwv":215,"tz":92,"ntp":0,"dhcp":1,"ip1":192,"ip2":168,"ip3":1,"ip4":100,"gw1":192,"gw2":168,"gw3":1,"gw4":254,"hp0":88,"hp1":0,"hwv":21,"ext":0,"sdt":0,"mas":1,"mton":0,"mtof":0,"urs":0,"rso":1,"wl":100,"den":1,"ipas":0,"devid":0,"con":110,"lit":100,"dim":15,"uwt":1,"ntp1":54,"ntp2":252,"ntp3":129,"ntp4":186,"lg":1,"mas2":0,"mton2":0,"mtof2":0,"fwm":2,"reset":0,"dexp":0,"mexp":5,"hwt":172},"status":[0,0,0,0,0,0,0,0],"settings":{"devt":1502046157,"nbrd":1,"en":1,"rd":0,"rs":0,"rdst":0,"loc":"Canberra, Australia","wtkey":"xxxxxxx","sunrise":360,"sunset":1080,"eip":0,"lwc":1502046085,"lswc":0,"lrun":[0,0,0,0],"sbits":[0,0],"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]]}}

and JC Response:
{"devt":1502046153,"nbrd":1,"en":1,"rd":0,"rs":0,"rdst":0,"loc":"Canberra, Australia","wtkey":"xxxxxxxx","sunrise":360,"sunset":1080,"eip":0,"lwc":1502046085,"lswc":0,"lrun":[0,0,0,0],"sbits":[0,0],"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]]}

[DaveC]

Some interesting observations, at least from my perspective:
Early today I tried some more server call tests from my loc. The first few with lat,long failed, but then they started working and have not failed since. The unreliability of these calls is a problem. They are referred to as weather calls, but they are needed to adj for dst, sunrise/sunset, etc. Even a system that does not use weather adjustments can be impacted by these failures. E.g. The values for sunrise and sunset in you system are the default (“sunrise”:360,”sunset”:1080) while the values I get for your location are (“sunrise”:365,”sunset”:1221). If you were doing anything based on sunrise/sunset it would be incorrect (your time problem aside). Also, if the system is not adj for dst, scheduling could be an hour off.
Ray, given the importance of this regular server call, it seems like lswc should always be visible in the UI, not just when there is a weather key. Also something should be put in the log when OS reboots because there hasn’t been a successful server call for 24hrs. This failure is too silent.

I set my OS to your location (lat,long) to see if I could reproduce the issue. So far, no. My server calls, with your location, are working. The time zone info is right: “tz”:92 translates to gmt+11, which means gmt+10 + DST. Please verify that I’m looking at this correctly. Also the local time on my OS matches what the world time map shows for your area.

The time offset (in secs) from correct time to bad is relatively consistent for the 2 data points you shared: 49161652 and 49161676. There going to be some variation just based on how much time elapses when you take the samples, but these 2 numbers differ by only 24s. I wonder if Ray finds this particular number interesting.

Your server call experiment showed that the use of “loc”:City, Country worked. Yet when set that way in the config, the server calls still failed (It has always worked for me). The server request that I used is not exactly what OS emits. Based on the code, your config server call might be more like:
http://weather.opensprinkler.com/weather0.py?loc=-35.28200,149.12868&key=%5Byour-key-here%5D&fmv=215
or
http://weather.opensprinkler.com/weather0.py?loc=Canberra,Australia&key=%5Byour-key-here%5D&fmv=215
I’ve tried these and they work. You may want to give them a try, too.

A suggestion: I saw nothing in the 2.1.6 FW rel notes that relates to the problem you are seeing, but it might be helpful if you could update to this FW. One of the inputs to the server call is the FW version number so there is likely some difference in the handling on the server end between the 2 versions. If there is a bug in the FW would be good to know if its in the current FW and debug it there.

[John]

Yep, you have the time zone for my location right: “tz”:92 translates to gmt+11, which means gmt+10 + DST

When I tried these two (I inserted my wunderground API key)
http://weather.opensprinkler.com/weather0.py?loc=-35.28200,149.12868&key=%5Byour-key-here%5D&fmv=215
or
http://weather.opensprinkler.com/weather0.py?loc=Canberra,Australia&key=%5Byour-key-here%5D&fmv=215

I get this for both
Error: No weather data found.

Then I removed the [] on each end of my key (I wasn’t sure if they were supposed to be there) and both work correctly:
&scale=-1&rd=-1&tz=92&sunrise=364&sunset=1220&eip=2092151838

An interesting point is that I have not been able to see any data in my logs. When I try to view the logs I just get a message : “Error retrieving log data. Please refresh to try again. I assumed that it was because the year keeps jumping ahead, but perhaps it is something else.

I am unable to upgrade past 2.1.5 at this stage as I don’t have the equipment to go to 2.1.6

I am bit surprised that I can manually set the date/time or set it via NPT Sync, only to have both overridden by a comms failure on the weather call.

[DaveC]

I doubt that the server call failure is the direct cause of the time change, but it was a failure to look into to see if it led anywhere interesting and its failure that others see. In the case of your time jump, it seems more likely that the problem lies somewhere with the low level time keeping code, below the routine now(). Another interesting factoid is that the RTC update interval is 60 secs which is similar to the amount of time it takes to jump after its been set.

The symptoms with NTP and manual set are consistent. The system is to the current time when the NTP sync or manual set happens and then jumps ahead within a minute or 2. Out of curiosity, with NTP off, once the time jumps to the future (i.e. jumps ahead by ~49161652s) does the time then stay relative to this jump or does it jump again at some point?

At this point I think Ray needs to weigh in.

[DaveC]

And Ray, just to follow up on the server call issue from this thread.Server updates from OS just stopped working again. Loc is in lat,long format. Its missed 2 and there are no programs running. From a browser, the city,state form is working but the lat,long form is failing again (failed early today, then worked, now failing).

[Ray]

Guys, I don’t think this has anything to do with the time zone or weather script: the time shift is way too large and the only thing I can think of is perhaps the RTC or RTC crystal has a hardware problem. @John, could you submit a support ticket? We can arrange to get your controller shipped back to us and will check if there is any hardware issue.

[John]

Just an update to this. Ray advised that Firmware 2.1.5 had a minor update to account for a small number of 2.1 units that had a different real-time clock chip. So I reflashed my unit and it has fixed the date problem. Happy Days.

[Ray]

@John: thanks for posting the update. Indeed it has come to my attention that the firmware had a bug that affected a small number of OpenSprinkler 2.1 units that use MCP7940 real-time clock (RTC) whereas the majority of OpenSprinkler units use DS1307 RTC.

This was first discovered by a user who reported the fix in blog comments:
http://rayshobby.net/modified-arduino-ds1307rtc-library-that-also-works-for-mcp7940n/#comment-128196

[Author]

Posts