[raaahbin]

The reboot is set up as a watering program.

Go to the Opensprinkler web interface or app, Edit Programs, create a program named “:>reboot”, and schedule it to run whenever you want the OpenSprinkler to reboot itself. I have mine scheduled at 1:01 every morning.

[raaahbin]

Yes – I noticed that tick() was called inside maintain()… but the difference is that maintain() is a public function (as opposed to tick() which is private in the stock version of UIPEthernet), so I figured I can put it in that place in OpenSprinkler.cpp without causing a fatal error during build. Of course, if the customised version of the library makes tick() public, that would fix the error too.

And it still doesn’t appear to matter, since I’m pretty sure delay_nicely is not called at all in the current version of OpenSprinkler.cpp

[raaahbin]

Thanks for that. On going through the code, I’ve discovered that (I think) the function in which the Ethernet.tick() function is attempted to be called is not, itself, ever called… so I’m pretty sure it can be safely either commented out (which would break things if I’m wrong), or replaced with Ethernet.maintain() (which should be safer if I’m wrong).

[raaahbin]

Further to the above, I’ve found that commenting out the one line in OpenSprinkler.cpp where Ethernet.tick() is called, seems to allow it all to build without errors… but I feel like that’s not a good way to do things, if tick() is supposed to do something important in the yield_nicely function.

[raaahbin]

I have also tried Stefan’s firmware. Unfortunately, it doesn’t seem to resolve the problem I’m having. I’ve now got a mesh system (before I had a single access point), and I think it’s a new variant of the problem (the unit drops off and back on randomly rather than just off and staying off like it did before) but it can’t complain about the strength of the signal now. Every other device in the house is rock-solid on the wifi, so it’s just an opensprinkler problem AFAICT. I still have a couple of things to try, but I’m not optimistic that this can ever be as reliable as something like this needs to be.

[raaahbin]

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.

[raaahbin]

I think your case may have been a slightly different issue (or at least different to some of these cases, including mine – there could be multiple problems in this thread). In my case, the display on the OpenSprinkler indicates that it is trying to reconnect (as opposed to indicating that it’s connected and has an IP address), but it never successfully reconnects. So the OpenSprinkler unit is picking up that it has lost the connection… but the only way to do anything about it is to reboot the OpenSprinkler unit.

I have already set a fixed IP address for OS on the router, so that has not been a solution for the problem I’m encountering.

[raaahbin]

That seems like a really good idea, actually – it doesn’t depend on being able to trace why it is currently failing to connect (which sounds, from Ray’s post, like it could otherwise be a roadblock if they can’t reproduce it). I don’t think there’s any need for the time tolerance to be particularly short. For example, it could be a logic like this:

IF no functioning network connection (unable to sync NTP?) for at least 6 hours
AND currently configured for WiFi connection
AND unit uptime > 24 hours

THEN reboot system

That will mean it only tries the reboot as a last resort – not because the router it is connected to is disconnected from the internet for a while – and even then it would only reboot itself once every 24 hours.

[raaahbin]

Mine is an Asus RT-AC88U.

I know it’s splitting hairs, but I don’t think it’s a disconnection issue: I believe it is a *reconnection* issue. That is, connection interruptions can happen for all sorts of reasons – for example, I’ve rebooted my router three times in the past week for other reasons – and in each case the OpenSprinkler has re-established the connection just fine as soon as the router comes back up. However, when the failure arises, the display on the OpenSprinkler shows that it is reconnecting, but it fails to do so until I intervene, no matter how long it is left to attempt reconnection. When the failure occurs, the issue is resolved immediately – and 100% reliably – by rebooting the OpenSprinkler unit. That appears to be the only way to resolve the issue. It would be good if detailed diagnostic logs were kept on the OpenSprinkler itself so that we can see what is going wrong in the OS’s system when it fails, but I am not aware of any logs except those associated with the timing of watering.

[raaahbin]

I’ve also been having this problem occasionally (maybe days or weeks apart?) where I discover the controller has dropped off the wifi network. I use OpenHab to drive the watering program, so it’s a big problem if it drops offline when I’m not around to reconnect it for more than a day or two. The display on the unit says it is reconnecting, but it does not do so until I reboot the unit (either by power cycling or holding the B2 button), at which point it reconnects immediately.

The get info page says “Firmware: 2.1.8(1), Hardware version: 3.0 – DC”

For now, I’ve set OpenHab up to warn me more actively if it drops the connection, but there’s something clearly not working in the firmware when it attempts to reconnect to wifi (its attempts – if indeed it is really attempting to reconnect – universally fail, whereas following a reboot it reconnects immediately… this leads me to believe it will not be solved by replacing the hardware).

Is there any way to access the unit at a lower level than the web gui and download a system log?

[Author]

Posts