Forum Replies Created
-
AuthorPosts
-
August 16, 2020 at 9:24 am in reply to: After Power Fail OS booted to Wireless with Ethenet connected #67920
DaveCParticipantRay, Thanks for the detailed info about how OS deals with the 2 network ports. Looking at my router’s boot log, the boot from the power fail, where the WAN had to come up too, took longer than 60s. I’ll switch to static addressing for now. I’m not concerned about managing a static address for OS. That said, I really like the network management niceties that come from using DHCP reservations and I may look at a local workaround:
My OS connects to an automation system which will let me know if the network connection to OS is down. Now that I understand how OS deals with the 2 network ports, I could add the ability for the automation system to understand that behavior. E.g. If the Ethernet address fails after some time period, try the wireless address. If successful, reboot OS to try to get back to the wired port (without looping, of course).
Thanks again,
DaveJuly 19, 2020 at 12:48 pm in reply to: Controller lockups / crashes with wired Ethernet module #67415
DaveCParticipantI have a managed switch that has the capability (port mirroring) described by @Water_my_lawn. I recently used this capability to find a problem where a device (not OS) would drop off the network occasionally.
I mirrored the port with the ‘bad’ device to another port. I plugged a PC into the mirror port and ran WireShark. As expected the mirrored port receives more than just packets with the device IP as the destination, most significantly broadcast packets and lots of them. After some experimentation I made a capture filter to remove most of the broadcast packet noise that was not likely to be creating the problem. In my case, the problem was caused by SNMP discovery broadcast packets that the ‘bad’ device did not handle correctly.
So, I think this method could be a good way to characterize the traffic on the OS port. E.g. Is the issue caused by a packet volume or a specific type of packet or something else?My $.02
Dave
DaveCParticipantI use a VPN for remote access. There is no direct relationship between the VPN and OpenSprinkler. Once connected via the VPN my Android phone can access my home network as if it was local. Step-wise, I start the VPN client on my phone and then run the OpenSprinker phone app. In general the difficult part is setting up the VPN. You need a VPN server on your home router, assuming it provides a VPN capability, (or on a device on the network that you can connect to) and a compatible client on the device that you want to access from.
DaveCParticipantYes, I’ll share it. Contact me directly at h2oskr2001(at)yahoo(dot)com
DaveCParticipantJames,
My Crestron module has been running for the entire season (using 2.1.6 FW). I have not yet looked at the 2.1.7 FW to see if it requires any changes to the module or if there are some capabilities that I want to add.
My request for event notification was to make it more efficient. Polling works OK but, unlike the mobile app or the Web GUI, the Crestron system runs 24/7. Getting some event notifications would significantly cut down on the polling activity in the Crestron system and the response to some state changes would be more timely.
DaveCParticipantThis is something I requested a while back. It would make integrating with at least some automation systems, Crestron in my case, more efficient. You say it would be easy to implement in the firmware. I might want to take a crack at it over the winter. Do you have any prototype code or design notes or anything I could use to start investigating it?
DaveCParticipantWhat happens if you click ‘Show Disabled’ at the bottom of the right side menu?
DaveCParticipantCheck ‘Edit Options’ -> ‘Station Handling’ What does it say under Number of Stations on the left?
If it says 8, then select the number of stations you want to use in the pull down on the right. To use all stations, base and expansion, select 24. Stations can also be individually enabled/disabled by clicking the gear on any station. There are a variety of settings in this box.
DaveCParticipantOver the past year, I’ve tried to participate a few times in this forum to find issues that users have described. In almost all cases the developer has ignored or shutdown that activity. (I realize that it could be just me and that I’m not really being helpful.) In any case, I gave up for a while, but I got sucked back in to this thread because I thought Dominic’s post (May 12, 2016 at 2:35 pm) was off the mark. There might be an issue that would useful to try to address and it wasn’t because the device was under-powered. It might not be a defect in OS, and my data suggests that OS performs quite well in some network environments, but the issue manifests itself in OS behavior. Putting myself in the developer’s shoes (a completely unfair thing for me to do), I would want to address anything that helped to make the embedded network stack more tolerant. I might even want to use it on another project like a thermostat or a garage door opener
Ray’s last post helped me understand why my attempts to participate in the forum have been ineffectual. And Dominic’s last post was a reasonable summary. The developer appears to view this as a hobbyist’s platform. It’s not a product in the normal sense. Both the HW and SW are Open Source. If YOU want to make a product based on it, have at it. OK, I get it now.
I have an OS that works fine in my environment and I’ve successfully integrated it into my home automation environment. I have no need to find a different solution right now, but it was good to be reminded of the environment that I’ve chosen to use and that I should plan for the future.
When Google cut off Rvolv, I thought, this could happen with OS. What happens when Ray moves on and shuts off the cloud connection. The server connection (aka the weather call) is not just for weather info, its integral to the system and is needed to get time zone and DST info. OS will still run, but no weather adjustments, no twice a year DST adjustments, and my OS will silently reboot once day. I understand now that I must either find a new product for the future or modify the Open Source code to free me from this dependency and create an environment that I can depend on. I can do that because its, well, Open Source and because I’m a software developer. But I really don’t want to, I just wanted to help make the better,
Ray’s note also reminded me not to waste my time trying to contribute to solutions. I either have a solution and can provide it or I don’t. The developer isn’t interested in collaboration. Bummer.
DaveCParticipantI’ve run 2 hours pinging every 30s mins, then 1.5hrs pinging every 15 secs, and my app polling 17 message every 5mins throughout. No failures and no missed messages. In addition to this, Kevin says that he had problems trying to connect and that it what led him to monitoring.
I think we can make the assumption that OS’s regular network task processing is unlikely to be the direct cause of the outages. I’m back to an hypothesis that some kind of network message/packet is the stimulus for OS to go busy. Since I never see this behavior, sniffing network activity on my network isn’t going to be of much help. Seems like we might be looking for some kind of broadcast or multi-cast message not specifically for OS but that it tries to process.
PTRG seems to have some form of packet sniffing. Domotz does not appear to have any. Perhaps PTRG might provide a clue of what was going on in the network when OS first stops responding.
It might also be useful to know the period of outages. How often they occur and what their duration is. Kevin, the data you provided above is a small window of this. It might be helpful to see it over a couple of days. Does Domotz have the option of providing a log in text form, like a .csv, that would be easy to digest?
DaveCParticipantMy interest here is to help see if there is an OS issue that is causing the apparent longer duration outages.
I don’t ping the device but I am sending messages to it 24×7 at a rate of about 1 every 30s. Since I don’t see these extended outages, only occasional missed messages, it seems unlikely that the outages are the result of OS being busy doing its normal tasks. It seems more likely that the OS network stack is becoming ’busy’ due to not handling some combination of events correctly.
We know that 2 people who are using tools that ‘ping’ the OS at some rate see similar symptoms. It’s seems useful to understand what these tools are doing more detail.
A quick look at the Domotz FAQ:
Q: What is the difference between a missed Heartbeat and a device being Down?
A: The way the monitoring of devices work is that we send six (6) pings every 30 seconds to each device on the network. If one or more of those pings are returned, then we count this as a Heartbeat. A device can “miss” three Heartbeats without being marked as Down. If a device doesn’t return any of the pings within a two (2) minute period, then the device is marked as Down. If the device starts to respond to pings again, it gets a new Heartbeat and is marked as Up again.Putting aside the question of why you’d want to send 6 pings every 30 seconds to every device in a home network, this info provides some view into what Domotz is doing. A quick look at PRTG didn’t yield as much insight.
The common symptom seems to be that sending regular pings to OS causes it to stop responding to pings for a variable period of time. I’ve started an experiment where I’m sending regular pings to my OS (1 every 30s). The ‘ping’ tool logs the success and failure of each ping. My automation app is also running with its statistics. If there are ping failures, it will be interesting to see 1) Do I also see extended outages 2) Does my app show missed messages that correspond with the ping failures.
If I don’t see any issues after a few hours, I’ll increase the ping rate.
Keep you posted.
DaveCParticipantMy OS doesn’t show these outages, just the occasional expected message failures described in a previous post. Maybe it’s useful to look at things that are different in either the OS setup or what might going on in the network that the OS may be reacting to. Here’s some info about my setup:
OS config: Static address, default http port, ntp sync, manual weather adj.
Its connected via wire to a switch along with about 12 other devices. AP (phones, tablets, notebooks), automation controllers, NAS, A/V devices, printer, PC.
It’s a single sub-net with mixture of static, DHCP and DHCP reserved addresses. External access is via VPN (no port forwarding).I don’t explicitly ping the OS. Communication with OS is periodic polling via the API as described previously.
In the past I’ve monitored the OS’s hourly server calls. Very infrequent failures.I tried sending some regular pings to the OS to see if caused any message failures. I didn’t do this for very long though long enough for it to overlap with my normal polling cycle. Nothing.
I’m willing to experiment some though I don’t have any suggestions as to what network packets the OS might have an allergic reaction to.
Ray, got any ideas?
DaveCParticipantA different perspective, FWIW.
I’m using the Arduino OS with 24 zones. I run an automation app that talks to the OS 24/7. It polls OS at the rate of 17 messages every 5 minutes. Since I’m still tinkering with capability I keep stats on the message activity. Looking at total messages sent and # of messages that failed to get a response in the most recent uptime period:
Up 8.5days. 41616 poll messages sent. 26 message failures.During this period of time I also used the phone app and the browser GUI to make programming changes so there was even more message traffic at times.
Yup, I think the OS makes server calls more frequently than needed (once an hour)
Yup, I wish that OS had an async notification method to let me know when to request updates. This would cut down drastically on polling.However, the message failure rate is still very low and hasn’t caused any issues in sprinkler operation or my ability to monitor and control the device.
DaveCParticipantI see a similar issue. My app automatically updated early this morning and it will not connect. The message I get is “Unable to connect to [Site Name]”.
January 15, 2016 at 7:57 pm in reply to: Opensprinkler Keeps changing to wrong date in firmware 2.1.5 #41311
DaveCParticipantAnd 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).
January 15, 2016 at 7:25 pm in reply to: Opensprinkler Keeps changing to wrong date in firmware 2.1.5 #41310
DaveCParticipantI 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.
January 15, 2016 at 3:58 pm in reply to: Opensprinkler Keeps changing to wrong date in firmware 2.1.5 #41308
DaveCParticipantSome 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.
January 14, 2016 at 8:13 pm in reply to: Opensprinkler Keeps changing to wrong date in firmware 2.1.5 #41305
DaveCParticipantI 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,%20AustraliaEdit 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.January 13, 2016 at 11:51 am in reply to: Opensprinkler Keeps changing to wrong date in firmware 2.1.5 #41292
DaveCParticipantHi 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”:{}}
DaveCParticipantBased on the failures I reported last week using my config and loc…
I changed the location in my OS using the Web GUI map. Loc changed from “Ault, Colorado” to “40.57517,-104.83635”
Since doing that the last 2 server calls by OS have failed.I manually issued 3 server requests with these results:
http://weather.opensprinkler.com/weather0.py?loc=Ault%20Colorado
&scale=-1&rd=-1&tz=20&sunrise=443&sunset=1012&eip=*********http://weather.opensprinkler.com/weather0.py?loc=80610
&scale=-1&rd=-1&tz=20&sunrise=443&sunset=1012&eip=*********http://weather.opensprinkler.com/weather0.py?loc=40.57517,-104.83635
Error: No weather data found.I think there is an issue on the server end when Lat,Long is sent as the loc.
The Lat,Long I used is what the Web GUI produced. I may also be possible that it is delivering Lat,Long in a format that the server does not like.Dave
DaveCParticipantThese were program run times. I checked my programs and the ‘Weather Adjustment’ flag was off. I probably set it this a while back with the incorrect assumption that ‘Weather Adjustment’ was related to automatic weather adjustment. I’ve set up another test for tomorrow, but I expect that this will take care of it. Thanks!
DaveCParticipantI don’t understand the relationship between the ‘weather’/server call and the updating of temp/humidity etc., but temp and humidity are not part the data returned from this call. Interestingly, location is a parameter in the call. This provides a linkage, at least in my experiment, between changing the location and server call failures.
Re: I noticed my eip is always set to 0, could this be a problem?
No, I think it is a consequence of the server call failure. The eip is not needed to make the call, rather it is one of the items returned.Looking at the code, the ‘weather’/server call returns: sunrise, sunset, external ip, water %, time zone, rain delay. Of these only eip has no other data source. I.e. all the others will have values if the call fails. Additionally the lswc is always filled in at the end of the code that processes the return. Since lwsc and eip are both 0 in your data, I would conclude that the server call has not been successful since the last time the system booted.
I’m getting more familiar with this code, so maybe I’ll piece together a working server call soon.
DaveCParticipantFeedback on the 2.1.6 API
As someone trying to provide SW that can be used by others to integrate OpenSprinkler with Crestron automation systems, the API document is not complete enough to provide all the info needed to code to. The API itself also has some shortcomings that make using it in this kind of environment a bit difficult.
Here’s my accumulated feedback on the 2.1.6 API, both the document and the API itself with suggestions.
Section 1 – Introduction
“You can find online MD5 hash tools to convert plain text password to MD5.”
It should also be noted that some of these tools produce MD5 hashes with uppercase hex digits, but OpenSprinkler requires that they be lower case.
PIDs are used inconsistently across the API. In some cases, like Section 2 and Section 17, PIDs start with 1, i.e. PID = 1 refers to the first program. In other sections, such as Section 13, PIDs start with 0, i.e. PID = 0 refers to the first program. I think I understand why this occurs, but it is important to be clear about it in the doc. It should be noted in this section to warn people to watch for the different usage.Section 2 – Get Controller Variables
rdst:
Typo (no -> not)
rdst: Rain delay stop time (0: rain delay no in effect;…
rdst: Rain delay stop time (0: rain delay not in effect;…loc:
It appears that this variable can have different returns depending on how location is setup. E.g.
“loc”:”City, State”
“loc”:”40.57537,-104.83635″
“loc”:”pws: KMANANTU15)”
Is a zip code a valid return? The example in Section 5 shows setting location by zip code.
The document should describe the different forms of returns that may need to be parsed. Are there any others?
Useful to note both here and in Section 5 that loc is read as a controller variable but set as an option.ps:
“pid is the program index (0 means non)”. What is “(0 means non)” trying to say? E.g. That this station is not part of any program? OR that the station running was not run as part of a program? OR ?
This is a case where the special use of PID = 0 should be clearly described.sbits:
If this is the same data as /js sn: but formatted differently, it would be helpful to say that in both sections. If it is not, then the sections should describe in what situations they can be different.lrun:
Since this is the first reference to “station index”, it would be helpful to state that stations start from 0, as is done in later references.curr:
flwrt:
flcrt:
In addition to describing what they are it would be useful to provide any other info that might be needed when using them. E.g. the range of values in the return and how to map flow clicks to a rate (e.g. it’s flow sensor specific). Updating the /jc example (as mentioned below) would probably cover most of this.wto:
Describe the return so that the contents can be parsed and used. It is partly described in Section 5, but it appears that the return here is not exactly the same as the string used to set it (in Section 5).
My system, which does not use weather options, returns: “wto”:{} So, it can be null.
I’ve seen an example in the forum that looks like: wto”:{“h”:90,”t”:90,”r”:90}
The doc should say that it can be null or that it contains {…} and what the values mean. Since the doc refers to “weights”, I assume that “t”:90 does not mean 90 degrees.
It is useful to note that it is read here but set by Change Options.Example Return: It is out of date. It would be useful to give a 2.1.6 example including the use of the new variables. The examples in some other sections could also benefit from updates.
Section 3 – Change Controller Variables
rsn:
“Binary Value” (0 or 1) would imply a that a 1 causes a reset, but sending any value, either a 0 or a 1, causes the reset. Is this what you intended? The doc should state the behavior.rbt:
Is the behavior in rsn also true for rbt?rd:
What is the maximum number of hours that can be set? The User Manual does not address this either. It appears to be quite large. While it’s unlikely that someone will want to set it to an extremely large value, it would be good to know the range and perhaps to limit it to prevent unintended issues. I assume you would get {“result”:17} “Out of range” if you set it larger than whatever the maximum is. As a quick experiment I set it to 4000 days (96000 hours) in the GUI and it set the rain the delay to Apr, 2019.re:
Is this a binary value where 1 = use as remote extension and 0 = remote extension mode off?
As is the case with some items where the get and change are handled in different major sections, this one is set via Change Controller Variables but read via Get Options. It would be useful to highlight this asymmetry where it occurs, perhaps even in Section 1 so people are prepared for it,Section 4 – Get Options
den:
I think this is the same as ‘/jc en’. If so it would be good to say that in both sections. In cases where the same data is set or returned by different API calls (sometimes in a different format), it helps to note that they are the same.uwt:
“Water restriction information for California is encoded in the last bit.” I think a bit more information would be useful on this. What is the encoding? Does it mean that setting high order bit enables CA water restrictions? Is it only valid when the adjustment method is other than manual i.e. 129 (0x81)? What happens if the value is set to 128 (0x80)?hwt:
I understand the 0x terminology but it would be more straight forward in the doc to state what the actual return values are. E.g. 0xAC = AC power type returns “hwt”:172. Yes, 0xAC = 172 decimal, but since the return is in decimal why not make it simple?Section 5 – Change Options
loc:
“Location string (url encoded).” What are the valid ways that a location can be set? This is a similar question to the question in Section 2. E.g. Zip Code? ‘City, State’? ‘lat,long’?
Useful to note that it is set here, but returned in Get Controller Variables.wto:
Typo: (in -> is) “Weather options which in a JSON…” -> “Weather options which is a JSON…”
It is not clear from the description how to specify this parameter. More info is needed and an example.o36:
036 is missing. It is the option to set the state of logging and it is one of the ‘special’ binary options. It should be added to the options list with shading as it may need to be included in the command to maintain the state of logging.Are there any others that are missing? o40 is a gap (as is o36). Does the o40 gap represent another missing item? Is it a new shaded item?
Examples:
The examples should be updated to be clear about the effect of including/omitting the shaded options.
Using the first example item: ‘http://os-ip/co?pw=xxx&loc=95050’
In addition to changing the location, this command will turn off ntp, dhcp, use of the rain sensor, and logging,; set the rain sensor type to normally closed; and enforce using a password.I understand that this special case of preserving options is the result of how the interface developed over time and it preserves compatibility, BUT it is also a source of bugs for an app developer. If you are not going to change the API then more attention to the info in the doc is needed. Note: Because o36 is missing I had to discover why logging kept being turned off when I changed options. I provided this feedback back when the 2.1.5 doc was released and it was ack’d. However, the 2.1.6 doc still has the error.
Section 6 – Set Password
The current password, supplied in the command, must be MD5 hashed, but the new password is in clear text. It would be useful to state this explicitly to avoid any confusion with the info in Section 1.Section 11 – Manual Station Run
It should be noted here that all manual station runs will show up as PID 99 in the ‘ps’ field of Get Controller Variables.Section 16 – Start Run-Once Program
It should be noted here that all run once programs will show up as PID 254 in the ‘ps’ field of Get Controller Variables.
As suggested in another forum thread, it would be useful to allow a PID to be specified as a run-once program parameter. This would allow bringing some other program attributes with it, e.g. repeat data.Section 17 – Get Log Data
It should be noted that hist = 0 delivers the log data for the current day. Hist = 1 delivers the day before and the current day, etc.
As the examples show, when the PID = 0, the next field is not the SID but the event code. This should be noted in the description. This is another case where PID = 0 has a special meaning.
The ‘Return Value:’ description does not seem to be correct with the addition of the 2 new event types. The events, fl and wl, likely do not provide a duration and an end time in their arrays. What do the return arrays for these look like?
Suggestion:
[Re]start/[re]boot events should show up in the log along with their cause, when it is known. Part of the value of the log is to know when something unexpected or wrong has occurred. Restarts are significant events. E.g. If a program is running and there is a power fail / restore, the remaining part of the program that was running will not run and potentially some future programs will not run. Looking at the log you would only see that something you expected to run did not. If the restart event was there you would have an idea why.
Power fail/restores are not the only thing that can cause a reboot. A reboot can be requested through the API. In this case you know what caused it. It is also done internally by the FW if there are no successful server (aka weather) call in 24 hours or if the network checks fail 6 times. Again you know what the cause is. These types of reboots should be in the log along with a code to indicate the cause. I understand that the FW generated reboots try not to interfere with running programs, but it is not clear if an API requested reboot does.
There are probably 2 that you can’t distinguish from one another: A crash/restart and a power fail/restart, but crashes are hopefully infrequent.
Here is an example of an event you could add to the log: rbt. The log entry array might look like: [0, “rbt”, restart code, 0] where restart codes are: 1 – Unknown (most likely powerfail), 2 – API initiated, 3 – Server call failed, 4 – Network issue, etc.Section 20 – Get all
The description ‘This command returns the combined result of /jc, /jo, /jn, /js, /jp in one command.’ That implies that it looks like what you would see if you concatenated the returns from the 5 requests. However, that is not the case. It actually appears to be exactly what you get when you export the config file. I.e. the 5 returns are concatenated and then wrapped in {settings: …. } The description should be more accurate.One more suggestion: Having some form of unsolicited notification of change would make the dealing with this device more efficient. This would particularly helpful when associated with data that does not change frequently such as Zone data or Program data. The Web GUI and Mobile App typically do not run all the time, so polling for everything may be an acceptable trade-off. When integrated into a larger automation system, regular polling for Zone and Program data adds overhead. my solution has been to have settable and different polling intervals for for different kinds of data, but this creates larger windows where data can be stale.
DaveCParticipantI tried an experiment on my system. My “loc” is in the form “City, State” (See previous post). I set my the location from the Web UI using the map. It showed City,State in the box, but it changed “loc” in my config from “City, State” to “lat, long”. After that change server calls failed (about 8 hours worth of them). I just restored my config to the original and server calls are now successful again.
Ray, what does the server call request look like? Knowing this would be an aid in debugging the problem.
DaveCParticipantNo, you aren’t doing anything wrong. This particular case is difficult to see in wireshark unless you have a way to see the OS server call on the system that is running wireshark. That requires a way to mirror the request to the PC. Sorry for making this sound easier that it really is.
The server call is not specifically a wunderground call. It is a call to an OS cloud server. You can see the call in the OpenSprinkler code:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/weather.cpp
The host name is weather.opensprinkler.com. If you do a lookup on this host it returns the following IP addresses:
52.10.151.144 and 54.148.153.152. I just checked to see what my OS used on its server call and it was the 52… address. I use my router’s filtering and logging capability to see what OS is doing externally, but I can’t see the actual GET request that it emits this way.The return from the server call contains both weather info (scale and rd), if enabled, and non-weather info (sunrise/set, external IP, …). It occurs every hour but will not be made if:
the network check has failed OR a program is currently running OR the controller is in remote extension modeI appears from the code (Ray can confirm) that the value of lwc is the time that the next weather call is scheduled but it is not an indicator that the call was actually made. The only indicator that the call was made is if it is successful (lswc = epoch time). You can’t tell if it was made and failed.
I would think that you could make the same server call from a browser if you knew what the request looked like. The code for it is the module referenced above. My C++ is not good enough to piece a request together from the code accurately enough to make one that works. This is what I was suggesting wireshark for, but…
perhaps Ray would provide an example request that you could use to test the server call.Just curious, did you try a simple config that did not use any weather info (key, pws, etc) and where you set your location to yourcity, Arizona (not lat, long) such that the /jc API call returns “loc”:”yourcity, Arizona. This is how my config is set up. Here’s an example of my /jc call (with my eip removed).
http://192.168.1.80/jc?/pw=944c6d5d72868e442a3dda88297ac500
{“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”:{}}I’m looking to see if there is some setting combination that causes the server call to fail.
Dave
-
AuthorPosts