- This topic has 67 replies, 27 voices, and was last updated 1 year, 5 months ago by
.
-
Posts
-
I think I have the same issue (I created a new thread then found this one). Sprinkler falls off the network and does not reconnect. I don’t know if it says ‘reconnecting’, next time I will check. The time I did check I was able to see the IP address on the Sprinkler. Where do you see it say reconnecting?
To fix the issue, I don’t reboot the Sprinkler, I disable the re-enable the WIFI on my router (I don’t reboot the router, just turn of the WIFI then back on). It then reliably reconnects .
App: 1.8.2, Firmware: 2.1.8(2), Hardware version: 3.0 DC
I have a second router I will try soon.
i have a windows 10 computer on wifi and it has a problem getting back a network connection after the dhcp lease has expired… this started about about 6-9 months ago. i’m on a r8000 router running as access point and clearOS as my firewall/router. for some reason i think this is something netgear changed in their firmware… are u guys with problems on netgear hardware???
Asus router here. And in almost every case that sounds genuinely identical to mine (there have been a few others in the thread that sound different – the ones which have the IP address displayed, rather than the “reconnecting” message), it seems we have set it up with fixed IP addresses on the router. The consistent behaviour seems to be that only rebooting the OpenSprinkler unit – not anything else – will resolve the problem in these cases.
It does seem that there are other potential problems with wifi connections to the OpenSprinkler – some of which appear to have been resolved by setting a fixed IP address on the router – but the one a number of us are facing with the unit being stuck on “reconnecting” until rebooted, is a distinct one, and does not appear resolved by the suggestions that have appeared here so far.
On the bright side, my unit seems to have been up for a couple of weeks without the problem occurring… but that’s also the trouble with intermittent faults.
I am using TP-Link newtork hardware. My router sets an IP for my unit with mac address.
Yes, I may have spoken to soon. Fixing an IP address resolved my connection issue for a few days, now the router looses connection to the OS every couple of days. Rebooting the router or WIFI made no difference, can only reboot the OS to regain connection. As suggested previously by others it would be good if the OS rebooted when signal lost, or alternatively a fix for those of us that are having problems, to have the option in the main system menu to reset the OS on a particular schedule (eg 24, 48, 72 hrs etc) and at a chosen time (say 2am when my system is idle). This should go a long way to working around the connection issue.
Thoughts?Hi,
Has there been any progress on this issue recently? Since upgrading to 2.1.8 I’ve been having these drop-outs too. I’m on 2.1.8(2) OSPi with a static IP set up on my TP Link AC1900 router. When my OS drops out the programs stop running too (I’d hoped that it would just continue irrigating in isolation, but my plants started dying). I have it linked to my Home Assistant but it is just reading information over the API, but I’ve set up an alert to tell me it if drops off the internet (nmap can no longer detect the static IP).
Interestingly, usually it drops off and does not reconnect. Today it did eventually reconnect after a few hours, but I could only access it via my browser (the app still couldn’t find it), although the router claimed that it is a connected device. After another few hours the app managed to connect too. Maybe this app thing is a red herring, but the dropping off the network is real, and really frustrating when my garden dies as a result. Can’t OSPi continue operating without the network connection, whilst it tries to reconnect?
Cheers,
Matthew@mattat01: you are talking about OSPi, which is different from what other users are talking about (OS 3.0). For OSPi, the issue is not related to our hardware, it would be your RPi, or in case you use a WiFi dongle, the issue with the WiFi dongle. Only OS 3.0 has built-in WiFi.
Ok, thanks. I’ll look into that, it is just that I never noticed it dropping out before I upgraded to 2.1.8. Still, you may be right so I’ll look into the hardware connection.
Thanks,
MatthewMy opensprinkler also disconnects and fails to reconnect. It only occurred when connecting to a wifi extender (NETGEAR WiFi Range Extender AC750). When I reconfigured the opensprinkler to connect to my main wifi, I haven’t had a problem. Worth noting that my main wifi is actually a weaker signal to the shed, but open sprinkler seems to be more stable with it.
This just happened again to me. Usually stable OS will disconnect from WIFI and stop doing everything! Including watering my lawn! I have to go under the house and do a power cycle to get it to connect again. This has to be fixed or I will ask for a refund on my OS unit as it is useless as it does not do what it says it will do.
Running hardware 3, 2.17 firmware with a TP-Link WAP.I am seeing this issue now too – was working fine for a year or so. Didn´t change the setup. I am on a Vodaphone EasyBox 804 and opensprinkler 3.0 DC with Firmware 2.1.8 (1)
I opened a ticket on github… hopefully someone is picking this up
GITHUBSame issue here on FW2.1.8, HW 3.0 – sporadic reconnect failure each couple of days.
Connected to AVM Fritz!Box 7590 via FRITZ!Repeater 1750E.
DHCP enabled (Although Router configured to always assign same address)Tried FW upgrade to 2.1.8(4) today, after reading this thread I will also try static address setting.
Last resort would be daily powercycle via manual timer on wall outlet, which I want to avoid, because it would need to withstand the current draw of my pump and switches.I have an OpenSprinkler DC 3.0, Firmware 2.1.8 in an AVM Fritz!Box 3590 Mesh configuration running. The OpenSprinkler is installed in the Garage and most of the time connected to the WiFI AP FRITZ!Powerline 1240E installed nearby. It is running for months now without any issues. Please be aware that older Fritz!Repeater, like the FRITZ!WLAN Repeater 300 may be part of your problem.
These “repeaters” and “range extenders” are very often real truble causers.
Avoid using them.
If you have to, don’t mix manufacturer brands. Also don’t mix new and old WiFi devices (like using an older wifi router and a newer repeater or viceversa) as they may implement standards differently, causing malfunctions.
If there’s no other way to avoid this, use different SSIDs for the main and for the “repeated” signal, so that clients like OS don’t get confused.
But better, try using quality AccessPoints, like Ubiquiti UniFi.
I have the same issue here, even updated to the latest firmware available. I have an OS 3.0 (I think) but it has a clear case, powered by an AC/DC adapter.
If I look at the logs on my WR33 meraki access point, when the unit isn’t responding, I can see “invalid credentials” for that wireless client.
I do not have this issue on my opengarage unit (mentioning because the setup screens for wifi are identical)
Perhaps it’s attempting to use a bad auth method during a key rotation or something? Not sure how to dig into the system logs to find a corresponding entry.
By the latest firmware, did you mean 2.1.9 minor revision (3)? Just making sure you have the latest.
Yes, Firmware 2.1.9 (3)
I had some time to try to dig into this a bit tonight. I was unable to get into the system again, so power cycled it to get it on the wifi again.
I logged into the web interface and immediately noticed that the time was wrong again. I double checked that it was set to use my router (pfSense) for NTP which it was, so disabled, ntp, set the time, re-enabled NTP and submitted changes.
In searching around on the forums it seems like weather underground went away, so I decided to check that I’m getting weather service information. I also came across a post saying that ETo is the way to go now for calculating water when precipitation happens so I enabled that.
I left the unit logged into the web page for a few hours and came back to my system. I expected it to not respond, but it was still alive, but the time on the opensprinkler said it was 8am even though it was only just after midnight (Toronto time zone). I verified the time zone is set to -4 as it should be, just like on pfsense etc. I checked the NTP server on my firewall,using a test tool to make sure it’s responding and quickly realized that the NTP KoD option was rate limiting NTP requests, so I figured maybe there is some type of issue there and disabled it. In the meantime I set the NTP IP to 0.0.0.0 because I found another post saying that using this setting would force the system to use a default NTP pool, the clock sync’d as soon as I hit save, so I’ve switched it back now to use my firewall just to see if the time gets out of sync again, and if it does I’ll try going back to 0.0.0.0 to see if that helps. I’m thinking this has something to do with time sync only because every time it seems to be disconnected from the network, the time on the display is incorrect, and when it’s rebooted it is still wrong even though it appears to do an NTP sync at boot.
If after reboot the time is still wrong, then it indicates a problem with NTP sync. In firmware 2.1.9(3) I made a change to NTP in that if the NTP IP is 0.0.0.0 (which is now the factory default value) it uses pool.ntp.org as NTP server, otherwise it uses whatever you specified as NTP server. But I think this shouldn’t matter with OS 3.0 because OS 3.0 already uses pool.ntp.org as default server; the change primarily affects OS 2.3, because its default NTP server previously seems to have stopped working reliably.
It’s definitely not an NTP issue now, device had perfect time even though it dropped off the network last night.
I have found out that on this AP, if I keep the web UI open on my pc to the device, it’ll happily stay on the wifi for hours without an issue. But if I close the browser and check in on the IP/app an hour or so later, the device isn’t on the network (it shows the IP/port on the screen still though if I press B1).
It looks like Opengarage uses the same platform as it’s base, is this true? I can’t figure out why my OG has been rock solid (farther away from the AP), but OS drops. Maybe because of it’s constant communication with blynk?
It appears the OS device just doesn’t like the MR33 access point. I connected the OS to my phone in hotspotAP mode and the connection was live for 3+ hours even after I had no browser tab open. I connected it back up to this Cisco AP and in less than 5 minutes after being rebooted it dropped the wifi association. Going to switch off of this Meraki AP and see how things go.
I can’t think of any reason why OS and OG would behave differently — they use the same chip (ESP8266) and at the moment the firmwares for both use the same ESP core version. I don’t think it has anything to do with Blynk either — that’s just a optional feature for OG — Blynk is not turned on by default, and the built-in web interface is always available, just like in OS. It’s certainly true that OS firmware is much bigger and more complicated than OG firmware. But I can hardly imagine why it would make a different in terms of staying connected to the same router.
I made a typo above and can’t edit my post, I have a Meraki MR33 that the device doesn’t work with, not a “wr33”.
As far as OG/Blynk, since the OS device would stay on the wifi as long as I kept the web page on my PC open (and it seemed to actively communicate with the device), I just thought maybe if it was actively talking to blynk servers every second or two, maybe that was keeping it alive.. I do remember having some similar issues getting the device set up the first time when I didn’t enter the blynk token to start, the second time I set it up and used the token right off the hop it seemed fine.
I ripped the MR33 out and put my ASUS OnHub back in and the connection has been rock solid now. Meraki support was unable to figure out any settings that would have caused any compatibility issues. The only thing I didn’t try on the Meraki was relaxing the WPA2-AES, or changing the SSID/key but things are working great now.
Not sure if this is a known issue or not, but when I would start the system and press/hold B1 after the logo showed to invoke a factory reset, the system would reboot and get stuck on a screen that says “Hold B3 to save” I tried holding it up to 30 seconds and nothing happens. It requires a power cycle to leave and get the OS device to boot up properly.
Hey here is Stefan from OpenSprinkler Germany.
Some of my customers also have the problem that after some time OpenSprinkler cannot reconnect.
However, instead of trying to reconnect again and again, I take a different approach. If no WiFi connection is established after 120s, WiFi is deactivated for 5min, 10min, 20min and finally 40min, in between connection attempts with 120s connection time.The firmware is based on the very latest git master version of today. So I am looking for some testers for the firmware.
The firmware is here:
http://opensprinklershop.de/wp-content/uploads/2020/08/OS2196_wifi_sleepmode.binPlease post test results here in this thread
@ Stefan, have you had any results from this approach? if i load this firmware, can i got back to original if needed?
my 2.1.9(3) HV 3.2-AC looses connectivity to the browser/internet once a week (max twice), but connects again straight away if i power off and on again.
the “about page” shows fair/good signal strength, and when it’s connected the unit work flawlessly, just annoying that it wont stay connected.have been thinking of ways to use a unused station, relays/timers and program a time to cut the power and reboot automatically, somehow….
- You must be logged in to reply to this topic.