[DaveC]

FWIW…
Predictability and reliability of watering are my highest priorities. MUCH higher than the convenience of automatic adjustment or simpler schedule creation. Based on what I *think* know about OS scheduling, I build programs where every zone starts at a specific time, the run time specified is the max that they can run, and nothing runs in parallel (though I wish I could explicitly control this when I know that some zones can run in parallel with other zones). I make manual adjustments when I want to. A simplistic example is: spring 50%, summer 100%, fall 50%.

I do not have to worry about teh impact of potential day overruns or pushing one programs zone schedule into the next. When watering is adjusted down it leaves time gaps between when one zone stops and the next begins, but it always does what I expect/programmed.

Perhaps as I gain more experience with OS scheduling I’ll try some other techniques.

[DaveC]

Thanks for the src pointer. I’ll try to spend more time looking at your code for reference. I’ve focused all my spare time on getting my app fully functional.

Initially, I interpreted the API document as you say; no need to specify a value. However, I’m *fairly* sure that when I tried a /co command with the ‘need to preserve’ options in the form o2, o3, etc. (i.e. wtihout any values), it behaved the same as not specifying the option. I’d have to go and try it again to be sure. In wiresharking what the Web GUI does, I decided that I should specify a value, even though the value is ignored. That is working fine.

If you want me to test the ‘no option value specified’ case to insure the doc is correct I will. It’s relatively easy to do.

[DaveC]

OK, o36 is the logging state option. It needs to be added to the doc and shaded.

In working with the /co command, I noticed a couple of minor behaviors that I didn’t expect.
I incorrectly tried to use &wl to specify the water level (rather than &o23). The response to the command was success. As expected the water level was not set, but I would have expected an error return.
I also incorrectly specified a parameter without a value (e.g. &o2 rather than &o2=1). The response was success. I would have expected an error. Since it was successful, what did OS do? Did it treat it as if the option wasn’t specified, setting the the option to 0, or do nothing with that option?

[DaveC]

I wiresharked a /co command and it appears that the Logging State is o36. Please confirm.
I’m curious about the tnn parameters that are not in the API and appear to specify the date/time in addition to ttt. Care to share or this a code exercise? 🙂

[DaveC]

What option index for /co corresponds to the ‘lg’ state in /jo? The logging state needs to be preserved when sending a /co command but it’s not in the options table. o40 perhaps?

Thanks

[DaveC]

Let me know if I can help with anything. Hopefully other user’s of the API will chime in with their views so you get an idea of the impact to them and their preferences.

Thanks

[DaveC]

To set the rain delay the command is /cv with a parameter of &rd=n, where n is the number of hours.
When looking at the status of the rain delay the command is /jc. rd will be 1 if the delay is in effect and rdst will be the time when the rain delay will end (in epoch time format).

[DaveC]

The OS API documentation is in the support section of opensprinkler.com

[DaveC]

Re: managing OS IP address
With DHCP on you can either take what your router gives you or have your router always provide the same address (via DHCP reservation in the router). If you want to give OS a static address, turn off DHCP (in options / advanced). You will then have the ability to add the IP and gateway address.

[DaveC]

There are no unsolicited event notifications, yet. I’d like to see them and have asked. In some other posts Samer has indicated they are considering them, if not already working them. I don’t have any info on what the mechanism would look like. I would think that the supplied apps would benefit from such a mechanism, too.

Until then I’m trying to balance overhead vs currency of display. I poll for general info every 15s (settable) and trigger additional requests whenever there is an action coming from my app so that displays updates quickly. Polling for specific info occurs more or less frequently depending on the type of info and the state of the controller.

[DaveC]

I connected my wife’s identical (HW-wise) notebook to the OS and it connected OK (CH340 driver). The only USB usage difference that I know of between her system and mine is that I use a Keyspan USB to Serial adapter to connect to other devices. I then loaded the Win XP driver (listed as CH341) on my system and that worked. (When it configures it says its a CH340 driver). The rest of the FW update was simple.

Thanks

[DaveC]

Thanks Ray!

[DaveC]

Samer and Ray,

Thanks for the detailed info cloud functions. It’s very helpful to know what your development philosophy is for OS. It’s also nice that it aligns with what I’m looking for.

It is a non-goal of mine to create custom OS FW. I have no desire to create a special version that I somehow have to keep in sync with the main code as it evolves and addresses bugs. OS is going to become my irrigation controller and its job will be to reliability water my landscaping. If I found it necessary to go my own way, I’d probably start looking for different device. I’m a fan of the open source approach. I’ll contribute testing and make suggestions and, if get familiar enough with the main code, maybe even propose code changes for bugs or enhancements that you can use, modify or discard.

Thanks for responding to my questions as I go through the discovery and testing stage.

[DaveC]

Hi Samer,

Thanks for info on what OS depends on from the cloud. Why do I care so much?

#1: I want a reliable irrigation system that will run correctly regardless of the state of my local network and connectivity to the internet. No matter what else happens, except a loss of power, the controller will execute its program just like a traditional controller will. All the ease of use features and scheduling optimizations are great but it should be my choice to use features that carry additional risk. My system does not need to be dependent on them to water the landscape. Users should know what those dependencies are and what risk they take in using them. A simple and relatively insignificant example: If one uses sunrise to start a program, but the internet is down and has been down for a day or more, will the controller use a default value or the last value it had for sunrise? Is assume so. A few days difference in that time doesn’t matter but failing to execute because it couldn’t get a value would be bad.

I want any device that I put on my local network to behave reasonably well because bad behavior can affect other devices and capabilities that I depend on. I want to know what the devices in my network do and what if any security or privacy issues exist as a result so that I can take appropriate action. A simple example: I do not open ports up for external access. I use a vpn. Bit of a PIA, but worth it from my perspective. In any case, I get to make the choice about what capability I take advance of and what risk I’m willing to take.

I think that using the cloud for some capabilities is fine as long people who want to know what is done externally have the info and that it does not compromise #1. I can easily see that it’s easier, safer and in some case only possible to provide some features in the cloud vs having to do regular FW updates to deliver them and keep them up to date.

[DaveC]

I have multiple programs that run one after another during the time period. So the ping behavior saw is expected.
Thanks.

[DaveC]

Hi Ray,

Thanks for providing more info detailed about how OS works. I’ll spend more time getting familiar with the code to help my understanding. That will just take some time 🙂

Re: connected to the router
When network connectivity is lost, it might be useful to log that condition. It might make noticing and correcting network issues a little easier as some might require user action. Having the OS’s view is may be helpful. Just a suggestion.

Re: The controller won’t ping or do time sync’ing when a program is running.
The key here is thinking about program objects. While the irrigation schedule from my (user) perspective was busy from midnight to 10:30AM yesterday, there are multiple programs that make up that time period. I’ll guess that the ping activity was occurring between when one program ended and the next one started even though that is a very short period of time. So, the ping behavior I saw is expected.

Re: DHCP behavior
Yes, I understand that kind of issue. Thanks for the more detailed info. If I experience a connection issue when statically connected it is not likely to be this problem.

[DaveC]

Just to be clear, I’m not suggesting that the ping info I’m seeing is wrong. I’m just trying to understand what the expected network behavior is so i can tell when I see something that is wrong and to help validate any changes that are made. I have experienced loss of local network connectivity to the OS when using a reserved DHCP address and a static address.In each case it took somewhere from 1 to 4 days to get into that state.

The DHCP behavior while triggered by some issue also showed that the OS could be a poorly behaving DHCP client. This seems like a concern because it could potently be triggered by something different than whatever was addressed in 2.1.4(new). I have also had the OS fail to respond locally when set with a static IP so I’m watching things as I learn the OS network behavior to see if I can help identify what caused that.

Since I don’t know what the controller uses the pings for, I don’t know what it means to the controller when they stop or change frequency. They should not be needed for regular operation and the lack of or changing frequency does not seem to impact my irrigation schedule. I’ve latched on to them because they may be an indicator of when something is going wrong that leads to the loss of or spotty local network access. I’m surprised that the OS pings so frequently if its just checking to see if it has a connection to something.

The ping pattern does not directly correlate to station run times. I can provide the run log if that’s useful.

Once I lean more about the controller behavior with a static address, I’ll update my FW to see if the issues I’ve seen are addressed by it.

Thanks

[DaveC]

Update: The following is the previous post ping time log continued up though 10:32AM MT. The pattern continues AND then returns to 54s pings.
An interesting correlation is that today’s irrigation schedule runs from midnight to 10:29.
Is this what you would expect to occur?

Jun 2 23:56:04 Rotary kernel: [LAN_Local-30-A]IN=eth1 OUT= MAC=dc:9f:db:28:40:fc:00:1e:c0:d7:2b:bd:08:00 SRC=192.168.1.80 DST=192.168.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=1360 SEQ=1
Jun 2 23:56:58 (+54s)
Jun 2 23:57:52 (+54s)
Jun 2 23:58:46 (+54s)
Jun 2 23:59:40 (+54s)
Jun 3 00:29:01 (+1761s)
Jun 3 00:29:55 (+54s)
Jun 3 00:59:01 (+1746s = 30m – 54s)
Jun 3 00:59:55 (+54s)
Jun 3 01:59:01 (+3546s = 60m – 54s)
Jun 3 01:59:55 (+54s)
Jun 3 02:59:00 (+3546s = 60m – 54s)
Jun 3 02:59:54 (+54s)
Jun 3 03:29:01 (+1747s = 30m – 53s)
Jun 3 03:29:55 (+54s)
Jun 3 03:59:01 (+1746s = 30m – 54s)
Jun 3 03:59:55 (+54s)
Jun 3 04:59:01 (+3546s = 60m – 54s)
Jun 3 04:59:55 (+54s)
Jun 3 05:59:01 (+3546s = 60m – 54s)
Jun 3 05:59:55 (+54s)
Jun 3 07:29:00 (+5345s = 90m – 55s)
Jun 3 07:29:54 (+54s)
Jun 3 08:59:01 (+5347s = 90m – 53s)
Jun 3 08:59:55 (+54s)
Jun 3 10:29:01 (+5346s = 90m – 54s)
Jun 3 10:29:55 (+54s)
Jun 3 10:30:49 (+54s)
Jun 3 10:31:43 (+54s)
Jun 3 10:32:37 (+54s)

[DaveC]

Hi Ray,
I’m still running the original 2.1.4 FW.
I have been running with a static IP since 6/2 1PM MT. From that time until midnight the OS sent an ICMP message to the router every 54 seconds. Based on your explanation this is the expected behavior. At midnight the behavior changed. From midnight to now the ICMP messages came at the following times. I’ve edited the log to show the time of the message and the delta from the previous message. With the exception of the delta at the midnight crossover, a pattern is emerging. Is it what you would expect with 2.1.4 (minus the 2.1.4’ change)?

Jun 2 23:56:04 Rotary kernel: [LAN_Local-30-A]IN=eth1 OUT= MAC=dc:9f:db:28:40:fc:00:1e:c0:d7:2b:bd:08:00 SRC=192.168.1.80 DST=192.168.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=1360 SEQ=1
Jun 2 23:56:58 (+54s)
Jun 2 23:57:52 (+54s)
Jun 2 23:58:46 (+54s)
Jun 2 23:59:40 (+54s)
Jun 3 00:29:01 (+1761s)
Jun 3 00:29:55 (+54s)
Jun 3 00:59:01 (+1746s = 30m – 54s)
Jun 3 00:59:55 (+54s)
Jun 3 01:59:01 (+3546s = 60m – 54s)
Jun 3 01:59:55 (+54s)
Jun 3 02:59:00 (+3546s = 60m – 54s)
Jun 3 02:59:54 (+54s)
Jun 3 03:29:01 (+1747s = 30m – 53s)
Jun 3 03:29:55 (+54s)
Jun 3 03:59:01 (+1746s = 30m – 54s)
Jun 3 03:59:55 (+54s)
Jun 3 04:59:01 (+3546s = 60m – 54s)
Jun 3 04:59:55 (+54s)
Jun 3 05:59:01 (+3546s = 60m – 54s)
Jun 3 05:59:55 (+54s)

[DaveC]

As noted above I am now running with a static IP. I have see the ‘Connecting…’ problem when running static in the past (farther back in this thread). I’m logging the OS to router traffic continuously now. I would not expect to see any DHCP requests when it fails while running static, but it will be interesting to see if there is any other unexpected messages. I’m expecting the regular pings to stop as they did in the previous test case.

I will update my FW.

[DaveC]

I’ve had my OS for about 3 weeks. It came with 2.1.4 FW (All my version and environment info is near the start of this thread). Is there a way for me to tell if my FW is the newest, before I attempt my first FW update, and potentially screw i9t up?

I noticed the ‘Connecting…’ behavior with a few days when I was testing the device before replacing my current controller. I’ve put off that change over until this issue gets sorted out. I’ve been gathering data on it, but didn’t see the DHCP behavior until yesterday when I started logging what the OS was sending to the router.

A bug in timeout is one thing, but sending 4-6 DHCP requests per second for hours suggests a another issue.

Thanks

[DaveC]

I’ve restarted the OS with a static IP. I now see the OS pinging the router every 54s.
When I was logging traffic before, there were 0 pings, just DHCP request bursts.

Jun 2 13:35:04 Rotary kernel: [LAN_Local-30-A]IN=eth1 OUT= MAC=dc:9f:db:28:40:fc:00:1e:c0:d7:2b:bd:08:00 SRC=192.168.1.80 DST=192.168.1.1 LEN=84 TOS=0x00
PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=1360 SEQ=1
Jun 2 13:35:58 Rotary kernel: [LAN_Local-30-A]IN=eth1 OUT= MAC=dc:9f:db:28:40:fc:00:1e:c0:d7:2b:bd:08:00 SRC=192.168.1.80 DST=192.168.1.1 LEN=84 TOS=0x00
PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=1360 SEQ=1
Jun 2 13:36:52 Rotary kernel: [LAN_Local-30-A]IN=eth1 OUT= MAC=dc:9f:db:28:40:fc:00:1e:c0:d7:2b:bd:08:00 SRC=192.168.1.80 DST=192.168.1.1 LEN=84 TOS=0x00
PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=1360 SEQ=1
Jun 2 13:37:46 Rotary kernel: [LAN_Local-30-A]IN=eth1 OUT= MAC=dc:9f:db:28:40:fc:00:1e:c0:d7:2b:bd:08:00 SRC=192.168.1.80 DST=192.168.1.1 LEN=84 TOS=0x00
PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=1360 SEQ=1
Jun 2 13:38:40 Rotary kernel: [LAN_Local-30-A]IN=eth1 OUT= MAC=dc:9f:db:28:40:fc:00:1e:c0:d7:2b:bd:08:00 SRC=192.168.1.80 DST=192.168.1.1 LEN=84 TOS=0x00
PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=1360 SEQ=1

[DaveC]

OK, I lied, another update:

At 10:29, 1.5 hrs after the last burst, the DHCP requests started again only this time they did NOT stop in 1 minute. I stopped logging at 11:27 because the rate can be as high a 6 requests per second.

If I don’t hear any back in ~30 mins, I’m going to restart the controller with a static IP address and watch its behavior.

[DaveC]

And one more update for the morning:
Another burst from 8:59 until 9:00. It appears to do this at 1.5 hour intervals for 1 minute until something else occurs and then the it goes on for a much longer time (yesterday afternoon and evening info).

let me know if there is something else you want me to look at.

[DaveC]

Update: From 7:29 AM until 7:30 AM there was another DHCP burst.

[Author]

Posts