[DaveC]

Hi Raphael,
In bit fields, the Least Significant Bit (bit 0) is the right most bit. In your example: where the program is enabled and all other bits are zero, the field will look like: 00000001.
Dave

[DaveC]

FWIW – I use the 2-controller solution. I replaced an older Hunter controller with OS. The company that I use to do the blowout and maintenance has a Hunter remote module that they connect to my Hunter controller when they do work. Ray gave me the same info/warning about using 2 controllers. I decided to take one additional isolation step. I build a ‘switch’ using Phoenix connectors that allow me to manually switch which controller is connected to the zones. Since I only need to switch controllers once or twice a year, the manual switch works well.

[DaveC]

Hi Ray,
Independent of the reason for the unsuccessful server calls (Bad Data OR No Response), the data pattern I was seeing does not align with the error only being in the server. I collected data over ~2 months. Each time I rebooted my OS, the server calls were always 100% successful for a few days and then started failing at a high rate.
Re: rebooting the weather server
I’m not currently collecting granular data, but I keep track of the last successful call. Looking at it right now (Aug 18, 2023 7:12AM), I see:
Last Server Call: Fri, Aug 18, 2023 3:09:57AM
Last Successful Call: Mon, Aug 14, 2023 9:07:00
Rebooting the server did not seem to effect whatever problem I’m seeing.

Let me know if there is anything I can try to collect data. If you change the FW to address the possible error return issue and want me to test it, I will.

Dave

[DaveC]

Follow-up to the last exchange with Ray on June 11th:

I had already rebooted OS. Location was still my home location. I continued this run.
24 consecutive successful calls
After the first failure, there was only 1 successful call out of 21 calls (95% failure rate)

I then changed to a location 1 town away. I hope that this is what was meant by “slightly”.
I did NOT reboot OS. Changing the location caused OS to start a new weather call sequence.
There was no continuous successful call sequence at the start.
The failure rate was 92% (25 calls, 2 Successful)

I then rebooted OS and changed to a location 2 towns away.
23 consecutive successful calls
After the first failure, the failure rate was 90% (31 calls, 3 Successes)

I have no more testing/data collection planned, but I will do some if there is another suggestion to try.

[DaveC]

Thanks for info about how the weather calls work, Ray. I find it interesting that calls are successful for about the first 10 calls after a reboot and they then fail at a fairly consistent rate (85%). I’m going to continue the run I’m on to see if I get similar behavior to the last 2. After that I will change my location and see how that affects the weather call responses.

[DaveC]

I rebooted OS and gathered statistics for another 10 days. After the reboot, weather calls were successful 100% of the time for 2 and a half days (10 calls). After the first call failure, the failure rate was 86%. The longest continuous string of failures was 12.
The return code on the call failures is always BadWeatherData. My limited understanding of this is that the call to the weather server was successful in that the server responded and provided information, but OS could not calculate a weather scale from the data. Either the server is not providing good data or OS is not dealing with the data correctly, but it is not an issue with connectivity to the server.

[DaveC]

Since I only typically need to switch the controllers a couple of times per year, startup and blowout, I used a very simple, manual mechanism that isolates the controllers.
Each controller is in its own enclosure with wire bundles that come over to the separate ‘switch’ enclosure and are terminated on phoenix plug blocks (e.g. 1792388).
The valve wire bundles come into the ‘switch’ enclosure and are terminated on phoenix receptacle blocks (e.g. 178867) screwed to the internal plate.
https://www.phoenixcontact.com/en-pc/products/printed-circuit-board-connector-mvstbu-25-16-gb-508-1788677

[DaveC]

I asked about this kind of operation a while back. Ray’s response may address your question.
https://opensprinkler.com/forums/topic/coexistence-of-an-os-with-a-hunter-pro-c/

I implemented the 2-controller solution, but it requires manual intervention to switch from one controller to the other. I used phoenix connectors to create an easy way to switch from one controller to the other.

[DaveC]

Update
I gathered weather call statistics for the last 10 days. The call failure rate is 85%. The failure cause is always “BadWeatherData”
The description of this code is: /** The watering scale could not be calculated due to a problem with the weather information. */
It appears that weather calls are made every 6 hours. The longest continuous string of failures is 12.
Ray, I assume this behavior is not what you would expect. I’m not asking you to do anything. I’m just providing my observations in case it is useful to you. Let me know if there is other info you would like to see.
I’m located in southeast NH, USA. The OS is connected to my network via Ethernet. My app polls the device every minute or so with no connection issues. I have a reliable connection to my ISP.
I will update again after I reboot the OS and gather more stats.
Dave

[DaveC]

It is possible to have 2 valves open at the same time, but I think what you are trying to do could be done using the Master Station capability.
I don’t use a master in my operation so it would be good for someone to validate the following:
If you designate Zone 10 (Expander Zone 3) as a Master Station with the Master On Adjustment of -5 (open Master 5 seconds before the zones that use it)
AND specify that Zones 0-9 should Use Master, I think you will get the behavior you are looking for.
When your program runs, the Master will open 5 seconds before the first zone runs. Since the zones all run sequentially the Master will stay open until the last zone finishes. It will then close. You could use the Master Off Adjustment to have it close 5s after the last zone completes if appropriate.

[DaveC]

http://raysfiles.com/os_compiled_firmware/v3.x/experimental/
http://raysfiles.com/os_compiled_firmware/v2.3/experimental/

[DaveC]

Updated my OS 3.2 – DC to FW version 2.2.0(1) today from 2.1.9(11). It is winter here so there is no critical operation issue. I am starting the process of updating my app to the new API and testing in prep for spring.
The process to update FW and get back to my original config did not do as expected. Here’s the detail:
The FW update worked as expected. I then followed the instructions for a new install: connected to the OS in AP mode via a PC, pointed the browser to 192.168.4.1, selected the SSID and provided the appropriate WIFI password. The status on the LCD said connecting… but it didn’t complete or reboot. I normally run with an Ethernet adapter so I reconnected the adapter and rebooted the OS. I then pointed the browser at the normal OS IP and connected. Success. I then tried to import the config which failed with: ‘Unable to import configuration.’

Everything else seems OK. I could change the password. Run System Diagnostics with expected output. Ran a JSON command that worked in 2.1.9. It worked as expected with new 2.2.0 output.

Did I do something wrong? Does the new FW have trouble with some parts of an old configuration file?

Thanks, Dave

[DaveC]

Hi,
I have 2 maps of my irrigation. One is a general zone overview that was done by taking a top view of the house from the original architect drawings (pdf), marking the heads and connecting all that are on the same zone with a colored marker. I then scanned that so I have it in electronic form.
The other is for cases where I needed to have a more detailed view of the piping, main feeds, and valve box locations. I used the drawing capability of PowerPoint: lines, boxes, notations, etc. I’m very familiar with drawing in this tool so it was an easy choice for me. If you are familiar with a drawing tool that provides these kinds of basic objects, that might be a good place to start.

[DaveC]

It’s been a while since I’ve looked at the details of the program I wrote so my recollection of how I did things may be a little off.
The 2 commands you note are functionally different.

12. Manual Station Run (previously manual override) [Keyword /cm]
Turns a single specified station On or Off. Based on your description of what you want to do, I would use this command.

18. Start Run-Once Program [Keyword /cr]
Will execute the program described in the list. If the program described only lists the time for a single station, it will run that single station. In that regard it is functionally similar in result to 12, but you have build a list of zones. I don’t think about it as a way to turn zones off. I’ve not tried it, but I would have thought that it would simply queue zones to run and NOT impact anything that was currently running.
I use 18 when I want to run a set of zones that are not part of an already defined program. E.g. I want to run zones 3, 4, 9 and 10 for 30 minutes because it’s been exceptionally warm and dry and I want to water the 4 sunniest zones. This would be similar to executing 12 4 times, once for each zone.

[DaveC]

I use DHCP reservations in my router to get IP addresses for most devices on my network.
Dave

[DaveC]

Thanks for the update Ray.
Does the program triggered reboot have a unique reboot cause code?
There are 2 codes, 4 & 5, that both say ‘API Triggered Reboot’. I don’t know why there are 2 for the same cause, but it would good if the program reboot cause could be uniquely identified. Perhaps one of these codes could be for the API Triggered Reboot and the other for the Program Triggered Reboot.

Dave

[DaveC]

I don’t use weather services so I have no need for weather calls, unless there is info from the call that is used for something else. Since calls cost you, perhaps you could give users like me a way to turn them off or if weather services aren’t being used turn off or slow down the calls automatically.

[DaveC]

I’ve installed the new Ethernet Module, run for about 24 hours and tested some of the conditions that showed issues. I have NOT seen any issues. No Network Error messages or the corrupted JSON responses. Bad Ethernet Module, case closed. Thanks Ray for suggesting this as the problem and sending the module.
Dave

[DaveC]

I ran OS wireless for 2 days. I did NOT see the JSON data corruption during that time. I just switched OS back to run wired and immediately saw the problem on the web app display and doing a JA command. Attached is the web app zone display.

Dave

Attachments:

1. 

   Web-App-Zone-Display.jpg
   

[DaveC]

This is the missing post from April 5.

A key symptom of the issue is when the web app or the phone app displays ‘Network Error’ in the bottom bar and the bar background becomes red. Does anyone know what conditions in the apps result in this error display?

I’m continuing to gather data about the corrupted JSON message data.
When I saw the ‘Network Error’ in the web app I stopped my app from polling so that the web app was the only client talking to OS. I then issued a JA request from a browser (firefox) and got back data that had unprintable data overwriting 16 characters in the response. I’ve attached 2 files to display what I saw in the full response (ja.json.45.txt) and a screen shot (ja.json.45.JPG) using a HEX editor to view the area with the bad data. The highlighted character is the character just before the 16 bytes of bad data The bad data starts at 84Ah (2122d)
I then issued each of the separate requests (JC, JO, JN, JS, JP) and they all came back correctly. I then issued JA again and it came back with the same bad data. FWIW, the responses to each of the separate requests are shorter than the position in the JA response where the bad data begins.

I could not clear the ‘Network Error’ in the web app. I tried logging out of the web app, exiting the browser and logging back in. It came up with the ‘Network Error’. I tried using 2 different browsers. After the third browser attempt, OS became unresponsive. It would not respond to pings. After a few minutes it started responding to pings but I could not log in with the web app.

I then issued JA and all the individual requests. Most of the responses had bad data in them. Interestingly it occurred at the same position in the JSON message. The JA response had 2 instances of the bad data. Here’s a summary of the character positions that the 16 bytes of bad data starts in:
JA: 24Ah (586d), C4Ah (3146d)
JC: 24Ah (586d)
JN: 24Ah (586d)
JP: 24Ah (586d)
JO: No bad data. The length of this response is 234h (564d), which is less than the position of the bad data 24Ah (586d)
These files are available if desired.

OS stays in this state. I can ping it. I can turn my app back on. It polls and gets responses with corrupt data. I can’t log into OS with the web app.
The various Jx requests issued via a browser return the bad responses noted in the previous paragraph.

I was able to reboot OS using B2. After reboot all the response data was correct.

Dave

Attachments:

1. 

   ja.json_.45.jpg
   

1. ja.json_.45.txt

[DaveC]

In the previous post the file name ja.json.txt was changed to js.json-2.txt

I posted a note the was between my April 1 post and Ray’s April 6 response that has never appeared. It also had an attached file named js.json.txt which might account for the file name in this post change. I have no idea what happened to it.

At this level it shows 6 replies, but at the next higher level it shows 7. One got swallowed up.

[DaveC]

I updated to 2.1.9(7)

After doing the update, I reconnected my Ethernet module and rebooted OS.
I then went to the web app to see if I needed to import my config.
The zone name display was corrupt.
See attached file Web App.JPG
I then did a JA request. The corruption is particularly interesting because it spans fields causing 2 zone names to appear to be one with non-printing characters.
See attached ja.json.txt.
I have include a view of the he bad data in a HEX editor. Starting address of bad data is C4Ah
See attached ja.json.JPG
Finally I did a JN request, since its response is much shorter. I shows the zone data correctly.
See attached jn.json.txt.

Attachments:

1. 

   Web-App.jpg
   

2. 

   ja-json.jpg
   

1. ja.json_-2.txt
2. jn.json_.txt

[DaveC]

The corruption is transitory and only in the response messages. I think the corruption is just a symptom or byproduct of the issue I’m concerned about, that OS has a problem dealing with 2 clients talking to it at the same time.

The 16 byte overwrite is in the JSON response from OS but the underlying data in OS must still be correct because the responses will eventually return to being correct, even if OS has to be rebooted because of the hang.

I’ve been able to create the same ‘Network Error’ message in the apps and OS lockup using only the phone app and the web app. As with the previous lockup, OS had to be power cycled to bring it back.

Using the phone and web apps at the same time is just a way to reproduce the problem. I understand that would not be typical use, but I do need one of them to be able to run while my monitoring app runs.

The 16 byte overwrite is not limited to a specific field, like a program name. It occurs in each response message starting at character position 363 which means it will hit a variety of fields, including keywords. I thought that the overwrite being in the same place and the nature of the data pattern might help in understanding the underlying issue.

Dave

[DaveC]

In addition to using separate power supplies for each controller, I can insure that only one controller is powered at a time.
To implement the parallel wiring, I will make a zone connection strip, separate from each controller and then connect the zones from each controller to the strip. This will make it easier to disconnect either controller if needed.
The irrigation company is going to be happy 🙂
Thanks, Ray.
Dave

[DaveC]

@Water_my_lawn
I don’t know what the capture environment was but it doesn’t seem like you are looking at the network from the OS perspective, I.e. everything that …20 is receiving. Correct me if I got this wrong.

Like you, I see the last successful exchange and the next one doesn’t get off the ground, i.e. OS doesn’t respond to the connect request. That doesn’t provide much info about what’s going on with OS. If you suspect that the OS hang is due to something on the network that OS is choking on, you would need to see everything OS sees and then correlate suspect activities to a time window where the OS stops responding.

Do you have a managed switch that can mirror ports? If so, you could mirror the port that OS is on to a port that a PC running Wireshark can look at.

[Author]

Posts