[spanno]

Hi ray,

Thanks for the new firmware, it offers a lot of useful functionalities, I suspect a lot of work went into it!

Just one thing that doesn’t seem to work for me: OTC through Android App.

I am on an internet connection in a remote area. My network provider uses different layers of NAT (Network Address Translation). In the past I have never gotten any Dynamic DNS services or port forwarding working (for Opensprinkler or any other service within my network).

I was hoping OTC for Opensprinkler would work, and it does, BUT ONLY when I access my Opensprinkler remotely through the webinterface on https://ui.opensprinkler.com/

When I try to connect remotely (mobile 4G) through the Android App (2.3.0, firmware 2.2.0(1) HW version 3.2DC) I get an “unable to connect” message.
When I connect remotely through my home Wifi network (using the token). the App does connect to my Opensprinkler flawlessly.

it is not a very big deal for me, although it would be nice to be able to access Opensprinkler out in the field, without having to walk back to my WIFI network;)

*edit: well, actually I can access through the webinterface, so I don’t have to walk back;)*

any suggestions you might have on resolving this are very welcome!

thanks for all the good work!

[spanno]

OK, I applied the work around. I can confirm that:
1) after re-engaging ET the water level percentage was updated
2) wto entry has been abbreviated to: wto: {baseETo: 0.16, elevation: 246, d: 24}

So now it seems to work just fine.

If i run into any hangups with ET not phoning home (yep, had that one coming;), I will post a reply here. If no news, good news!

And a lot less work then redefining everything. Thanks a lot Ray!

[spanno]

@Ray

OK, here is as much info as I can provide:

settings file:

{“settings”:{“devt”:1566850792,”nbrd”:2,”en”:1,”rd”:0,”rs”:0,”rdst”:0,”loc”:”40.81050,0.45852″,”wtkey”:””,”sunrise”:437,”sunset”:1247,”eip”:1602354689,”lwc”:1566848605,”lswc”:0,”lupt”:1566646945,”lrun”:[2,2,3300,1566712501],”curr”:0,”sbits”:[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]],”wto”:{“baseETo”:0.16,”elevation”:246,”h”:100,”t”:100,”r”:100,”bh”:40,”bt”:69.98,”br”:0},”ifkey”:””,”RSSI”:-65},”programs”:{“nprogs”:2,”nboards”:2,”mnp”:35,”mnst”:4,”pnsize”:16,”pd”:[[113,1,2,[297,-1,-1,-1],[0,0,0,0,0,0,0,0,240,0,0,0,0,0,0,0],”pump start progr”],[115,1,2,[300,-1,-1,-1],[0,0,3000,0,0,0,0,0,0,0,0,0,0,0,0,0],”irri moestuin”]]},”options”:{“fwv”:218,”tz”:56,”ntp”:1,”dhcp”:1,”ip1″:192,”ip2″:168,”ip3″:0,”ip4″:111,”gw1″:192,”gw2″:168,”gw3″:0,”gw4″:1,”hp0″:80,”hp1″:0,”hwv”:30,”ext”:1,”sdt”:0,”mas”:1,”mton”:0,”mtof”:0,”urs”:0,”rso”:0,”wl”:110,”den”:1,”ipas”:0,”bst”:320,”uwt”:3,”ntp1″:50,”ntp2″:97,”ntp3″:210,”ntp4″:169,”lg”:1,”mas2″:2,”mton2″:0,”mtof2″:-20,”fwm”:4,”fpr0″:100,”fpr1″:0,”re”:0,”dns1″:8,”dns2″:8,”dns3″:8,”dns4″:8,”sar”:0,”ife”:0,”sn2t”:0,”sn2o”:0,”reset”:0,”dexp”:0,”mexp”:8,”hwt”:220},”status”:{“sn”:[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”nstations”:16},”stations”:{“masop”:[253,123],”ignore_rain”:[0,0],”masop2″:[4,128],”stn_dis”:[0,0],”stn_seq”:[252,56],”stn_spe”:[4,195],”snames”:[“master 1 pomp”,”master 2 ball valves”,”virtual moestuin”,”S04″,”S05″,”S06″,”S07″,”S08″,”pump start advance”,”pump stop delay”,”S11″,”S12″,”S13″,”S14″,”run pump only”,”Open ball valves only”],”maxlen”:24}}

Firmware 2.1.8 (4)
Hardware version : 3.0 DC

Anything else that might help?

Thanks for your time and attention, so far!!

[spanno]

@Ray,

OK, here is the output from /ja/settings/loc:

loc: “40.81050,0.45852”

doesnt seem to be a pws location name, I am sorry…

settings: {devt: 1566850462, nbrd: 2, en: 1, rd: 0, rs: 0, rdst: 0, loc: “40.81050,0.45852”, wtkey: “”,…}
RSSI: -65
curr: 0
devt: 1566850462
eip: 1602354689
en: 1
ifkey: “”
loc: “40.81050,0.45852”
lrun: [2, 2, 3300, 1566712501]
lswc: 0
lupt: 1566646945
lwc: 1566848605
nbrd: 2
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],…]
rd: 0
rdst: 0
rs: 0
sbits: [0, 0, 0]
sunrise: 437
sunset: 1247
wtkey: “”

If you prefer the entire output attached to a support ticket, let me know, and also, what is the best way to grab the entire /ja output? (for now I’m using google Chrome, as suggested.

hope this helps!

[spanno]

Yep, does contain data (shown below) and ja? seems to run about every 2-3 seconds

wto: {baseETo: 0.16, elevation: 246, h: 100, t: 100, r: 100, bh: 40, bt: 69.98, br: 0}
baseETo: 0.16
bh: 40
br: 0
bt: 69.98
elevation: 246
h: 100
r: 100
t: 100

One remark: These data shown here are in inches/feet, However, I use the metric option in /Options/System

[spanno]

I have the same problem, stuck at a steady 110%, even after a full day of rain.
Switching between Zimmermnan and ET back and forth forces a manual update of ET, but no automatic, daily update.
I can confirm that weather script is set to point to weather.opensprinkler.com.

When I have time, I will go the factory reset route, or is there any indication this issue might be solved through a software update?

(the question being: are all users affected, or only the ones with a funky setup (mine being pretty straightforward, un-funky), and what would be the common denominator for the affected systems? – but perhaps that is too much hassle to figure out, and heck, what is more fun than reprogramming your sprinkler setup? ;))

[spanno]

Hi Samer,

Without understanding the (technical) reasons why it is not possible to store zone ordering mapping in the controller itself, it would not be my personal preference to pursue the proposed path of storing such critical information in the cloud. I suspect that without a functioning internet connection the mapping could not be retrieved at the time of irrigation, messing up important dependencies that could even result in damaging a well pump in my case. Very undesirable situation.

My observation: zone reordering/mapping seems to be an advanced feature that may not be relevant to the majority of users. Though nice to have, from a developer viewpoint it does not seem to be need to have and should therefor only be implemented if reasonably easy to realize.

Perhaps something to keep in the back of the head for when a complete re-write of controller software is necessary (at some point in the -distant- future?) and implementation becomes feasible with storage in the device itself

[spanno]

oh! and as an afterthought: user definable dummy zones might also be a solution – allow users to define one or more dummy/virtual zones and assign them a zone number either smaller than 1 (starting with 0 and then -1, -2 etc) or larger than 72 to place them at beginning or end of a program ( or even a decimal to place between real zones? i.e. dummy zone 2.5 to run between real zones 2 and 3).

Might be useful to research the user base for advanced and delayed master start/stop and zone re-ordering. Any way to figure out how many users on a well pump for instance? Because if only a handful of users would benefit too advanced a solution would only needlessly complicate UI for most (regular) users.

[spanno]

@Ray: Thanks for the explanation. I agree that zone re-ordering is preferable over re-mapping. I had not considered the complexities of 72 zones reordering. I was just imagining a way to change the order by drag and drop or repeatedly pushing an up- or down button in each zone-bar.

One way to simplify might be to change the program interface from a full list of all available zones to an ‘add zone to program’ option where you start with an empty program and add zones as you need them en then place them in de desired order.

And by the way. I was confused about the GPIO option in the advanced tab. I now realize it is only applicable in/on OSPI and the GPIO does NOT refer to the physical zone connectors on Open Sprinkler. My mistake.

Anyway, (FYI) I came to a work around using two programs and two dummy zones (nr 9 and 10). Zone 9 results in an advanced master start and zone 10 in delayed master stop.
Program one contains only zone 9 (activating Master 1 – the well pump via relay)
Program two starts 2 minutes after program one (activating master 1 again and also master 2 -the two NO/NC valves redirecting flow from the cistern to the irrigation system)

Program one runs for 3 minutes so there is an overlap of one minute in activating master 1 – because I noticed that the well pump relay will shut down momentarily when the programs are sequential- causing a power interruption to the pump for about one second (not desirable for a pump)

Program two will end with dummy zone 10 allowing for the irrigation solenoids to close under pressure and advanced shut down for master 2 to redirect flow from the irrigation system to the open cistern to avoid irrigation water entering the well as water flows back once the pump stops under pressure of about 200 feet of water column.

The advantage of this solution is twofold:
1) does not cost a physical zone (like zone nr 3 acting as a dummy when only one program is used)
2) still allows for automatic changes to the duration of program 2 (the irrigation program) because of weather forecasts or sensor input

Disadvantage is:
1) start times of the two programs must be coordinated and in tune with each other. So a change in start time for one program must be manually matched with a change of the other program’s start time. This becomes more of a challenge in more elaborate and complicated programming schemes

It is a workaround that takes a little thinking through and requires some user-alertness. Would improve a lot with zone re-ordering, making that a nice-to-have feature, not a need-to-have.

Thanks for elaborate reply, I hope my work-around may benefit other OS users or challenge someone to come up with (even;) better approaches. and btw: I am available for betatesting or brainstorming about zone re-ordering anytime.

[spanno]

*bump*

the ability to re-order stations/zones in a program would be a very much appreciated feature!!

[spanno]

(sorry if posting duplicate, am struggling with forum software:()

Hi Ray,

I too, am thinking of a solution for advanced master start (if that’s what you’d call it). And yes, I think the solution with a dummy zone is effective. However, It does come at the cost of a physical station. (whereas the delay at the end of a program can be assigned to an non existing station, for example #9).

I was wondering if it would be possible in a future firmware release to either:

1) change the order of (sequential) stations in a program? (for example place station 10 before station 3, when 1 and 2 are master stations)
2) add manual override mapping of stations (so default software station 3 maps to hardware station 3 on the GPIO, but with advanced setting, user can map software station 3 to hardware station 10 on GPIO – or any other if desirable)

As far as I can see any of these solutions would allow for (one or two) master station(s) to start before irrigation stations are opened, without the cost of one/any (hardware) station.

What are your thoughts? would this work, and also be workable/programmable?

My situation is that I need one master station to start the pump at a depth of about 200 feet, and after about two minutes (when water starts flowing) second master station to close one NO ball valve and simultaneously open a second NC valve diverting water flow from the cistern to the irrigation manifold. And only then open solenoid irrigation valves.

Hope I made some sense. These things are harder to explain then to think up;)

[Author]

Posts