[DaveC]

nate:
The last server call (lwc) is the time that the call is made by OS. However, if lswc = 0 then it didn’t get through. So your statement: “My last weather call seems to updated as it should and the data it returns is accurate every time I check.” is not really what is happening. The call is being made but it is unsuccessful and therefore doesn’t return anything. Also, the server calls should be successful regardless of the water algorithm settings. I run my OS with the manual weather setting and no auto rain delay and my server calls are successful every hour, except when there is a program running. In that case the call is not made.

It is possible that the problem is not with OS itself but with your network/firewall. It would be worth checking to see if that call is getting out and returning successfully. Wireshark is a useful tool for these checks. You could also try making the server access from a PC on your network to see what happens.

[DaveC]

Re: Wokkeltje
I haven’t tried it but you might be able to create a ‘short-cut-like’ browser reference with the Manual run command you want an start your lights. Starting that browser instance would emit the command that you want. There are also ‘http requester’ mobile apps that might do this in a cleaner way.

[DaveC]

Re: georgetarmitage
I’ve never used WUHU but in a very quick look I see that it has the ability to create web pages. I wonder if you can use this capability to emit a run-once program command with all the zones that you want for 1 minute each and repeat this action in WUHU until the temp is OK.

While it doesn’t help you now I think your usage need provides a good feature suggestion that would useful in other cases.
Suggestion to Ray: Provide the ability to create a program with type ‘Manual’. That type of program allows setting zone run times and additional start times (both fixed and repeating). It has all the attributes to describe what to do when triggered manually. It could be triggered from the API via Run-Once Program by supplying the PID or the Program Name. It could be triggered by the existing UIs in a similar way to Quick Programs.

This capability would be generally useful early or late in the watering season where you could manually kickoff a program when you need it.

[DaveC]

Very cool. And not more than I wanted hear. I like seeing how people solve problems using control and automation technologies There’s sooooo many different kinds of solutions possible.

Re: main page of the webgui
I think its difficult to design a single UI to cover such a broad range of users, from an expert user managing 40+ controllers to a single non-technical resi user. Your control app allows you to custom design a UI and the underlying functions to fit your needs. The web and mobile apps can still be used when appropriate. You can focus your app on the things that make managing a big installation easy for you and modify it over time as you refine what’s needed.

Providing a status-at glance dashboard and diagnostic functions seem like items that would be useful to you but difficult/time consuming with the supplied UIs.

Thanks for sharing
Dave

[DaveC]

Hi Ed,

Seems like a nice application for OS. I’d be interested to know what you see as the key features from a central control/monitoring perspective and if you find ways to know when something is wrong, without visual inspection.

The model I have for integration with automation systems (in this case Crestron) is to provide simple controls (enable/disable, manual run, etc.), quick visual monitoring (zone/program activity), and notifications, particularly when something is wrong. I let OS and the supplied Web UI and Mobile App do what they do best: configure, program, schedule. Of course, you can still use the supplied tools for any purpose.

Determining when something is wrong is the most difficult. Having to regularly monitor the OS log or noticing that plants are drying out are not the best ways find to find out. People want automatic weather based adjustment and everything to just work as they expect, but in the case of some failure they want to be notified of a problem before they incur landscaping damage and cost.

Personally I don’t use the auto adjustments because I don’t think they reliable enough yet (not just with OS) and I don’t have good enough ways to spot problems ahead of time. Knowing that server calls are not working is a simple check but knowing over time if the weather based adjustments are correct and if they are what you need across your various irrigation zones is a bit harder.

Dave

[DaveC]

It sounds like you’ve tried the basic case where your OS is set to (“loc”:”yourcity,Arizona”) and the timezone is correct (“tz”:20) BUT the server (weather) calls are still not successful (“lswc”:0). The server call is to an OS cloud server. The following thread contains some info about the server call and what it is used for.
https://opensprinkler.com/forums/topic/os-regular-connection-to-the-cloud/
I think it would good to find out what is going on with the server calls. Are they getting out? Is there a failure of some kind? I think you can do it with Wireshark, looking for traffic from your OS IP to your gateway. I’ve done it via the logging capability of my router. In either case, the calls should be easy to spot as they occur once an hour.

[DaveC]

The API provides a way to run a program but not a pre-defined named program. See Section 16. Start Run-Once Program of the API manual. Essentially Run-Once Program allows you to specify a list of zones to run with their duration.

What I’ve done (and I think the UI and App do something similar for ‘Quick’ programs) is to maintain a list of all the programs and the zone defs for them. When a user wants to manually run the program called ‘Front Lawn Zones’, I take the program definition and turn it into the format required by the Run-Once Program command. In my home use I define a set of manual run programs for this purpose as they are often somewhat different from the programs I’ve defined for scheduled runs.

Suggestion to Ray: Allow a PID or a Program Name to be given to the run-once program command (in the API) as another way to specify a program to run. OS already has the info, why make the programmer make the translation. It would also be nice if Manual was a ‘Type’ of a program to distinguish it from Interval or Weekly when that is its sole purpose. More obvious from a User’s perspective. And one more thing, while I’m on a role, if you decide to allow run-once manual to accept a PID, then that PID show up as the active program, not 254.

HTH
Dave

[DaveC]

I don’t live in CA but I’ve been following this thread. I’ve integrated OS into an automation app so I’m interested in the reliability of the device and getting info that helps users know when something is not working as expected. I don’t have a solution but here’s some info on how to get current rain delay info (and a suggestion for Ray).

Relative to seeing rain delay events, I assume you know that you can see historical ‘Rain Delay End Events’ in the log file which show what the duration was. I know this works for manually created rain delays. I would think it would be true for auto set delays too but have not tested. Have you’ve seen some expected auto rain delay events in the log file? For troubleshooting problems like this it would be good of the log file contained an event for when the delay started and what the duration will be (Suggestion).

Current rain delay info is available from the API. You can issue API commands from a web browser. The command would look like:
http://192.168.1.80/jc?/pw=%5Bwhatever your MD5 hashed pwd is], replacing 192.168.1.80 with you OS’s IP address
The response will contain info that tells you if rain delay is in effect and when it will end (described in the API doc).

An example…
Command:
http://192.168.1.80/jc?/pw=944c6d5d72868e442a3dda88297ac500
Response:
{“devt”:1450337786,”nbrd”:3,”en”:1,”rd”:1,”rs”:0,”rdst”:1450380976,”loc”:”Ault, Colorado”,”wtkey”:””,”sunrise”:438,”sunset”:994,”eip”:1089139017,”lwc”:1450335543,”lswc”:1450335543,”lrun”:[9,7,376,1450337777],”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”:{}}

For Rain Delay;
“rd”:1 means rain delay in effect (0 would be no rain delay)
Rdst”: 1450380976 is the stop time. It’s in epoch format. There are converters in excel or you can subtract the value in “devt” from it. The result will be the number of seconds left in the current delay (devt = the current time).

HTH,
Dave

[DaveC]

If by “run 2 valves at the same time”, you mean run 2 stations/zones at the same time, then yes, you can. The stations that you want to run in parallel must have the sequential attribute set to off. You do not need a separate program, but you may have other considerations when you create programs that have a mix of sequential and non-sequential stations in order to get the overall behavior that you want.

[DaveC]

OK. I understand the legacy rational, but it does make it more complicated for the programmer. A simple station attribute change becomes a ‘group of 8’ station update (even the use of the term ‘board index’ has a legacy definition since expansion boards have 16 stations on them). OK, I’ll stop whining…

In the ‘cs’ definition the ‘?’ is used in 2 ways: It is the station index when use with ‘s’ and it is the board index when used with ‘m’ and ‘n’, both of which are stated explicitly and the examples show them, For ‘i’, ‘d’ and ‘q’, ‘?’ is not defined explicitly nor are there examples for them. I can see what you intended now, but since these are all per-station attributes, it seemed like ‘m’ and ‘n’ were the exceptions because the use of ‘?’ was explicitly defined for them.

My suggestion for the API doc: For ‘i’, ‘d’, and ‘q’, state explicitly that ‘?’ is the board index in the same why that it is done for ‘m’ and ‘n’ OR at the start of the Parameter section state that ‘?’ is the board index except when used with ‘s’. Also, there should be a note to remind the programmer that when changing a station attribute, other than its name, you have to preserve the state of the other stations on that board index.

Thanks

[DaveC]

I wiresharked the web app to see what it does when zone 1 is disabled and then enabled. The results were a bit surprising:
GET /cs?pw=*****&s0=FrontLawn+Left+1&q0=255&q1=255&q2=255&i0=255&i1=255&i2=255&d0=1&d1=0&d2=0
GET /cs?pw=*****&s0=FrontLawn+Left+1&q0=255&q1=255&q2=255&i0=255&i1=255&i2=255&d0=0&d1=0&d2=0

It appears that the ‘d’ parameter is a binary parameter (on or off). Great. But…
Why are all the other parameters included, why that collection of parameters and zones and why are ‘q’ and ‘i’ treated differently than ‘d’? Specifically:
Zone 1 name (unchanged)
Zones 1 – 3 Ignore Rain parameter (unchanged) AND each zone specified as a bit field (255). It appears that to change the Ignore Rain (or Sequential) parameter for say Zone 1, one would specify it as &i=254. Yes? Why not binary?
Zones 1 – 3 Sequential parameter (unchanged) AND each zone specified as a bit field (255)
Zones 2 and 3 Enable parameter (unchanged)

I did all of this with FW 2.1.5

[DaveC]

Thanks for posting the 2.1.6 API and User Manual.

As far as I can tell my feedback on the 2.1.5 API doc is still valid for 2.1.6.
https://opensprinkler.com/forums/topic/api-document-feedback/
I’ll provide any additional feedback when I complete updating my app for 2.1.6

[DaveC]

No worries about the time. Thanks!

[DaveC]

Hi,

Do you have a target time for when you will update the API document? While I understand many of the change that were made, I roll my app based on the doc. It’s also an opportunity for you to get feedback on the doc. If you have a draft in progress and want feedback on it before you publish it, I’m happy to do that.

[DaveC]

Hi. I’m not a ‘watch’ user, but here’s my $.02. I provide this capability in my automation app. At my home I only use the manual capability but I think it’s useful to provide both and allow people a ‘manual override’.

[DaveC]

I would think so. I’m not Python knowledgeable but maybe Pat will comment on what it would take to use his script to the Synology environment.

[DaveC]

In the API the Get Program Data request returns the max size of a program name. In 2.1.5, it is 12 characters. As pointed out above, you could potentially change the field size in the FW but you might have to make other modifications for such a change to work all the way out to the browser and mobile apps.

[DaveC]

The current API provides a way to query the OS to get info. At this time, there needs to be another system involved that does the query and turns that info into whatever kind of unsolicited notification is desired. Given the current size of OS, I’ll guess that providing a general mechanism locally in the OS is unlikely but maybe they have plans to provide this capability via their cloud.

[DaveC]

I don’t know if this is impacting what you are displaying, but FWIW….

With Use Rain Sensor off, if the Rain Sensor Type is set to 1, normally open (the opposite of the default), The API will report Rain Sensor State on. I reported this a few months back running 2.1.4.

[DaveC]

Is the ‘weather call’ referred to here a call to the OS cloud server?

Re: external IP
I’ve wonder this for a while, so since you mentioned it…
Why does the controller store the external IP of the network in which the OS resides? What does it use it for?
Also, I saw a post that suggested that since OS knew the external IP address, it should write it out to a cloud service as a workaround for people who want to access their OS externally but don’t have either a static IP or a router that can’t do DynDNS updates. If you decide to do that, PLEASE make it a configurable option.

Thanks for the info

[DaveC]

Re: Weather call
I don’t use the weather service. Is the reboot done regardless? If so… Even after the current issue with the weather call is addressed I think it would be better to not make a weather call if the service is not used.

Re: lrun valid check
Thanks. It would be good to add that info to the API doc.

[DaveC]

Its a bug…
When processing ‘jc sbits’ an extra 0 is sent out after the last station status group.
In server.cpp

// print sbits
for(bid=0;bid<os.nboards;bid++)
bfill.emit_p(PSTR(“$D,”), os.station_bits[bid]);
bfill.emit_p(PSTR(“0],\”ps\”:[“));

should be something like:
// print sbits
for(bid=0;bid<os.nboards;bid++) {
bfill.emit_p(PSTR(“$D”), os.station_bits[bid]);
if(bid!=os.nboards-1) bfill.emit_p(PSTR(“,”));
}
bfill.emit_p(PSTR(“],\”ps\”:[“));

This is similar to the way it is handled with ‘js sn’:

for (sid=0;sid<os.nstations;sid++) {
bfill.emit_p(PSTR(“$D”), (os.station_bits[(sid>>3)]>>(sid&0x07))&1);
if(sid!=os.nstations-1) bfill.emit_p(PSTR(“,”));
}
bfill.emit_p(PSTR(“],\”nstations\”:$D}”), os.nstations);

[DaveC]

Trying to answer my own question:
The data is not exactly the same. The number of stations returned is different.
I have 24 zones.
‘/jn sn’ returns 24 zones worth of data (zone 11 active as expected)
“sn”:[0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0]
‘/jc sbits’ returns 32 zones worth of data (zone 11 active as expected)
“sbits”:[0,4,0,0]
Why? Is it a bug?

OK, so I can figure out how many zones I really have and ignore any extra zones that ‘sbits’ returns to work around this.
When I get more time, I’ll try hunting the OS code to see if I can find out why.

[DaveC]

…but is the data returned by ‘sbits’ exactly the same as the data returned by ‘sn’ except that ‘sbits’ is packed 8 stations to a byte? My interpretation of the doc is that they are but I was looking to validate that. Having 2 fields encoded differently in 2 different messages makes me think there is something different about them, unless ‘sbits’ was added cut down on the number of message polls one would have to do. If they are the same it would be good if the doc said so.

[DaveC]

The format of the log record is described in the API document, section 16. The first number is the program index, the second number is the station index.

[Author]

Posts