OpenSprinkler Forums OpenSprinkler Unified Firmware Trouble with Zimmerman Method

Tagged: 

Viewing 25 posts - 76 through 100 (of 104 total)
  • Author
    Posts
  • #42769

    kabbak
    Participant

    Hi,
    Please see comments below.

    On 6/1/16 4:30 PM, OpenSprinkler wrote:
    > Peter wrote:
    >
    > @kabbak, my Zimmerman method is working on 2.1.6. Would you be willing to post your zimmerman option settings and the Weather Underground station’s pws ? Happy to check to see if I get the same results.

    > A couple of quick questions:
    > 1) Can you tell us the exact version number of the firmware i.e. 2.1.6 (1) or 2.1.6 (2).

    2.1.6 (1).

    > 2) When you say “the adjustment method options don’t seem to accept my changes” do you mean one of the following: 1) you change the options, press submit and then restart OpenSprinkler but the changes have not been remembered, 2) that changing the settings is remembered but seems to have no impact on the watering % or
    > 3) there are options in the UI that you cant edit e.g. baseline temp/rain/humidity.Also true for me.

    I can’t edit the baseline values . They’re greyed out and at: 70, 0, 30%.

    My experience is that the “adjustment method options” (AMO) panel’s submit button gives no feedback that pressing it has done anything. Reentering that panel WITHOUT clicking submit at top right of screen doesn’t show any change in values I changed in the panel. However, IF I click submit in panel AND top right, the values change and DO affect watering percentage. Reentering the AMO panel now shows my changes.
    AMO options of 30,100,35 only get me to around 77% watering.
    So, IMHO, the AMO panel needs to allow me to change the baseline (grayed out) values, show all value changes when AMO panel submit button is clicked and the confusion with “submit” in top right corner addressed somehow. Maybe changed to “Save changes”

    I’m trying to adjust the baseline behavior (OFFSET) so I get about 100% watering for my typical situation and then tune the options (GAIN) to adjust the sensitivity to weather changes.

    Also FWIW, I find the two menu icons confusing. Three bars at top left and box of 9 dots at bottom right. How about just one with submenus or two at top left, or more descriptive icons or ….

    I hope this helps.
    Thanks for your help!
    Keith

    FYI, I’m using firefox 46.
    Thanks!
    Keith

    #42771

    Peter
    Participant

    Keith,

    OK. so the new version of the App exposes the new Zimmerman baseline feature hence you can see the fields for baseline temp/rain/humidity. However, to make use of this feature you also need the latest version of firmware 2.1.6 (2). Since you have firmware 2.1.6 (1), the App has “grey’ed out” the fields as your firmware version does not support the new feature parameters.

    So if you want to make use of the zimmerman baseline – this is essential for me as I’m in a very high humidity location – then you will need to update the firmware using the instructions on the support page (Update Guide)

    If I were coding this feature again, I might have kept the fields hidden until both the new App and the new Firmware were both running rather than “teasing” a new feature that causes some end-user confusion. Sorry about that and I’ll take the knowledge on-board for next time.

    Pete

    #42825

    chickenmad
    Participant

    #Ray

    Did a fresh install using your OSPi image. Left it on Wheezy. Manually entered the config entries instead of import. Weather diagnostics has a nice fresh couple of dates in it after configuring it to use my location, WUNDERGROUND key and turning on Zimmerman method BUT by manually calculating the Zimmerman method it is significantly below 100% but still the watering percentage remains at 100%.

    Next up – spanning the port and providing you a wireshark capture showing the server request and response.

    Not sure what else I need to do to reinforce that this isnt user error.

    Also – the guide uses an off the shelf WPA_Supplicant advice but that doesnt make the WIFI aggressive reconnect. WICD-CURSES (lazy hate nano’ing/vi all over the place) might be the best package to include in your image since its menuing will hit the middle of your audience.

    *****update – turned off Zimmerman – set to rain delay – turned back on Zimmerman and now calculating as Zimmerman predicts. Will let this bake for awhile BUT gonna have to assume that from the initial image I setup whenever the Unified firmware came out to now that an artifact caused this issue and the new image does not carry that forward.

    #42884

    chickenmad
    Participant

    Second day with successful Zimmerman watering. Reimage the SD Card and manual data entry did the trick.


    @Ray
    any reason your OSPi image doesnt turn on the BCM2708 watchdog by default? Since this system fits the bill for an embedded system seems like a no brainer.

    #42932

    Ray
    Keymaster

    We found a bug in the weather script a couple days ago that may be related:
    https://github.com/OpenSprinkler/OpenSprinkler-Weather/commit/bf538ab0854a85ce6461772be1ef4e1d5a16f0bf
    Specifically, I noticed that the ‘precipitation_today’ data returned from WUnderground tends to be empty (instead of 0). That was causing the script to throw a NaN (not a number) value, and later causing the calculated watering percentage to fall back to 100% due to not a number issue. This probably explained why there were lots of ‘stuck at 100%’ problems. I wish they put a filler 0 as opposed to returning an empty string. But the bug has now been fixed and deployed.

    #42942

    William
    Participant

    Will there be a version 2.17 with this change available shortly? Due to laziness, I would prefer to load it with the more or less automatic update program on my laptop.

    #42944

    Ray
    Keymaster

    This is a weather script change and it does not require firmware change. The weather script is independent of the firmware.

    #42960

    William
    Participant

    Interesting. So how does the script change flow down to the end user? Will the change be later implemented in the iPhone, android and web apps or does something else happen?

    #42961

    Samer
    Keymaster

    The weather service is something we provide via Amazon Elastic Beanstalk and allows the OpenSprinkler device to query it for weather information as well as other things like daylight saving information, etc. The controller automatically attempts to contact the server for information daily and that is when this change will be noticed (since the cloud service was updated right after the fix was posted).

    Hope this makes sense.

    #42977

    William
    Participant

    That makes good sense. Thank you. This IOT stuff it more complicated than I thought.
    Bill

    #43037

    Tryptophane
    Participant

    Wondering if the issue of an unchanging “Current % Watering” value has been solved? Mine has been stuck at 30% for weeks. I’m using a static IP, and the gateway/router address is correct. When I click “Verify” for my Wunderground key it verifies quickly and is green. I can connect to my OpenSprinkler from outside of my network – which also tells me that communications seem to be working as they should. Could it be a DNS issue?

    Thanks!

    #43038

    Tryptophane
    Participant

    Re: OpenGarage – having recently lost a good friend to carbon monoxide poisoning while working in his garage, it strikes me that being able to tie automatic opening of the garage door to a CO sensor would have likely saved my friend’s life. It would be a great feature if it’s do-able. (I understand the legal ramifications may prevent it though.)

    #43078

    Ray
    Keymaster

    @Tryptophane: the first thing to check is ‘Last Successful Weather Call’ time stamp. You can find it via ‘Weather Diagnostics’, or on the controller’s LCD screen directly by pressing B2+B3 (the same way as how you press Ctrl+A). If the Last Successful Weather Call time stamp is synchronized with the Last Weather call time stamp (i.e. within a minute from the call), that means the controller is receiving data from the weather server correctly. If not, it could be a DNS issue as you asked.

    Particularly, if you use static IP, the firmware currently assumes the DNS server is the same as the router / gateway. This can sometimes cause issues. I recommend you to turn it back to DHCP, and use the router’s DHCP reservation feature to achieve static IP instead.

    #43088

    William
    Participant

    Is there a way to tell what IP address Open Sprinkler is using? After reading the post above I checked my last successful weather call and found it blank ‘–‘. I rebooted and got synched times and dates at the time of the reboot. I know from problems with LibreElec that my Time Warner modem does not supply DNS from the gateway address. Is there a way to give Open Sprinkler an external address such as google’s open DNS 8.8.8.8 if it is trying to use the gateway?

    #43101

    Tryptophane
    Participant

    Thanks for the reply Ray. I’d prefer to keep my static IP as it lets me access my OpenSprinkler controller from anywhere – which I do frequently. My gateway is a Juniper firewall – which is doing proxy DNS – yet I don’t have any successful weather calls. Is it possible to SSH into the controller? If so, can name resolution be altered then? It’d be nice to be able to run TCPDUMP from the controller – just so I can see what’s going on. I suppose I can do that from the firewall though…

    #43149

    Ray
    Keymaster

    The Ethernet library that OpenSprinkler uses does allow defining custom DNS when using static IP. Unfortunately this is currently not exposed in the firmware / UI. When using static IP, it assumes the router is the DNS server, which is not an ideal solution in some cases.

    That’s why we recommend keeping OpenSprinkler in DHCP mode (so that the router will automatically populate the correct DNS IP to the device). You can still achieve static IP by using your router’s DHCP reservation / IP reservation feature. This way, every time OpenSprinkler restarts and requests DHCP, the router will always assign the same IP to it. Unless if the router doesn’t support DHCP reservation, there is really no need to set OpenSprinkler in static IP mode.

    #43179

    William
    Participant

    Ray,

    I use duckdns to access opensprinkler remotely. If DHCP assigns a new address then I have to change my port forwarding to make it match. A static IP would be better. Also based on my experiences with LibreElec my Time Warner furnished modem does not provide DNS at the gateway address (at least not reliably). At a minimum, it would be helpful to see what address opensprinkler is attempting to use for DNS. The ability to set a static IP, Gateway and DNS would be really helpful. Remoting in with SSH to do it would be fine.

    Bill

    #43222

    Ray
    Keymaster

    Hi Bill,

    As I said, most routers these days support DHCP reservation — you can bind a specific IP address to the MAC address of OpenSprinkler. This way, you can keep OpenSprinkler in DHCP mode and the router will always assign the same IP address to it.

    #43237

    William
    Participant

    Ray,

    Yes, that would work. My ubee modem did not call it DHCP reservation, the term I am familiar with. I missed it in my menu look-thru.

    #43238

    ShawnHarte
    Participant

    William can you post the name of the option you found on your modem, it may be helpful to others with similar problems.

    #43244

    William
    Participant

    Sure, on the ubee modem DHCP reservation is found as follows:

    Login as admin:
    Basic >> DHCP -> (bottom of the screen) DHCP Clients

    The ubee modem has considerable trouble with the NEST thermostat. When the NEST is busy, it puts the network connection in standby. Apparently there an established protocol for this function. When the NEST sends the RESUME command the ubee modem ignores it and the connection is lost. I ended up plugging my power hungry LINKSYS router into the ubee modem to provide connectivity to the NEST. So far this problem had not affected the Arduino version of opensprinkler. I am mentioning it because it could conceivably affect the other hardware versions.

    Bill

    #43363

    imissnixon2
    Participant

    I’m having issues with this too. Just stopped working after working fine forever.

    App version 1.4.10
    Firmware 2.1.6 (2)
    Hardware version 2.2 – AC

    I tried reformatting the SD card, and obviously all the updates. I have not tried rebuilding as I have a 24 zone system and it wasn’t worth it.
    I have no problems with accurate weather appearing on the zone page, I just get no updates to the watering %. Weather key is valid, and I can successfully get a response from http://weather.opensprinkler.com/weather1.py?loc=pws:knccary68&key=XXXXXXX using my key. In fact, as a workaround, I have written a script that runs in Homeseer that periodically accesses that address, extracts the % value, and then uses the Homeseer Open Sprinkler plug-in to update the value.

    #43405

    chickenmad
    Participant

    No trouble to report since your script update and the reimage from scratch.

    Thanks.

    Also as an FWIW :opensprinkler with a 12v battery and electric matches makes an awesome fireworks controller…..not that anyone would ever do that

    #43449

    devanl
    Participant

    Hello,

    I am also having problems with my Zimmerman method. The weather statistics appear to be either wrong of blank.

    If I run the weather script I get:
    http://weather.opensprinkler.com/weather1.py?loc=41.97218,-71.40619&key=xxxx
    &scale=100&rd=-1&tz=32&sunrise=323&sunset=1219&eip=1655692958

    My config:

    {"settings":{"devt":1468574122,"nbrd":1,"en":1,"rd":0,"rs":0,"rdst":0,"loc":"41.97218,-71.40619",
    "wtkey":xxx,"sunrise":323,"sunset":1219,"eip":1627197609,"lwc":1468572425,
    "lswc":1468572425,"lrun":[4,1,300,1468565221],"curr":0,"sbits":[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]],"wto":{"h":80,"t":80,"r":100}},
    
    "options":{"fwv":216,"tz":32,"ntp":1,"dhcp":1,"ip1":192,"ip2":168,"ip3":1,"ip4":11,
    "gw1":192,"gw2":168,"gw3":1,"gw4":1,"hp0":80,"hp1":0,"hwv":23,"ext":0,"sdt":0,"mas":0,
    "mton":0,"mtof":0,"urs":1,"rso":0,"wl":100,"den":1,"ipas":0,"con":150,"lit":100,
    "dim":15,"bst":320,"uwt":1,"ntp1":50,"ntp2":97,"ntp3":210,"ntp4":169,"lg":1,"mas2":0,
    "mton2":0,"mtof2":0,"fwm":1,"fpr0":100,"fpr1":0,"re":0,"reset":0,"dexp":0,"mexp":6,"hwt":220},}

    It looks like communication is good, the data just isn’t populating?
    Also, it doesn’t look like this is tied to the data populating but I’m thinking I’m getting caught here?
    https://github.com/OpenSprinkler/OpenSprinkler-Weather/blob/master/routes/weather.js#L311

    Attachments:
    #43499

    Ray
    Keymaster

    I am trying to import your configurations and reproduce the issue, but your configurations seems to be missing some data in the end. Specifically, it’s ending with:
    “hwt”:220},}
    which is not entirely correct. If you don’t want to post this publicly on the forum, you can export your configurations as a file and submit a support ticket attaching the file.

Viewing 25 posts - 76 through 100 (of 104 total)
  • You must be logged in to reply to this topic.

OpenSprinkler Forums OpenSprinkler Unified Firmware Trouble with Zimmerman Method