It’s late and I feel like I’m beating my head against a brick wall, but since updating the OpenHAB host system to the latest Mac OS, the OpenSprinkler binding appears to be dropping offline repeatedly. The line in the log is:
02:11:51.131 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'opensprinkler:http:192_168_11_97' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Could not refresh current state from the OpenSprinkler.
If I go into PaperUI and disable then re-enable the Thing, it goes back online… then drops offline again less than a minute later. When it is online, it works perfectly - I can send commands to the system and it responds - but openHAB itself seems determined to take the Thing offline. This is a brand new problem, and although the host OS has been updated, that doesn’t seem to make sense that it would break something at that fine a level while everything else in openHAB appears not to have missed a beat. Is there something quirky or out-of-date about the OpenSprinkler binding that could be causing the problem? I’ve updated the OpenSprinkler to the latest firmware, but that hasn’t helped at all. Accessing the OpenSprinkler directly through its web interface works perfectly.
Further to this, it sort of works through the openHAB interface, even when it’s complaining about being offline. The interface doesn’t track the state perfectly, but I can toggle stations on and off. So communications between the openHAB host and the opensprinkler seem to be running, even though PaperUI and the openHAB log both confidently tell me that the opensprinkler is offline.
Ahah! We have a culprit! Although I’m not sure that leads immediately to a solution, but at least we’re on the trail of it now.
03:21:22.698 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'opensprinkler:http:192_168_11_97' changed from UNINITIALIZED (DISABLED) to INITIALIZING
03:21:22.698 [DEBUG] [rnal.handler.OpenSprinklerHTTPHandler] - Initializing OpenSprinkler with config (Hostname: 192.168.11.97, Port: 80, Password: ******, Refresh: 60).
03:21:22.940 [DEBUG] [rnal.handler.OpenSprinklerHTTPHandler] - Successfully created API connection to the OpenSprinkler device.
03:21:22.987 [DEBUG] [rnal.handler.OpenSprinklerHTTPHandler] - OpenSprinkler connected.
03:21:22.987 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'opensprinkler:http:192_168_11_97' changed from INITIALIZING to ONLINE
03:21:52.992 [DEBUG] [rnal.handler.OpenSprinklerHTTPHandler] - Refreshing state with the OpenSprinkler device.
03:21:53.053 [DEBUG] [rnal.handler.OpenSprinklerHTTPHandler] - Could not refresh current state of the OpenSprinkler device. Exception received: org.openhab.binding.opensprinkler.internal.api.exception.GeneralApiException: Could not get the current state of the rain sensor.
03:21:53.053 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'opensprinkler:http:192_168_11_97' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Could not refresh current state from the OpenSprinkler.
I’ve removed things that didn’t have anything to do with the opensprinkler system. However, it seems the problem is that it can’t get a valid answer about the state of the opensprinkler’s rain sensor, so it throws up its hands and says it doesn’t have a valid connection to the opensprinkler, even though it (otherwise) does. The opensprinkler doesn’t have a rain sensor connected, so I don’t care if it can read its state or not, and I certainly don’t need it pretending it can’t talk to the sprinkler controller just because it can’t get a valid response out of the rain sensor channel. So, can I tell it just to forget about the rain sensor response (or lack thereof)?
Hmm, that looks strange, the binding, as of the current master branch, does not emit such a log message. Can you please give us the info what openHAB version you’re using? Could you update the binding (maybe including your openHAB as well) to the latest snapshot and see if the error still persists? The binding was undergoing a massive rewrite so you may need to change some configuration, though Maybe you can setup a test system with docker and your opensprinkler?
I’m using the current release of openHAB, so that’s… 2.4.0? And the version of the opensprinkler binding that came with it. OK - I’ve just found the “bundle:list” command - 2.4.0 for both openHAB core and the opensprinkler binding.
How would I tell it to update the binding to the latest snapshot? That’s not something I’ve played around with - I’m more at the level of “advanced user” than “amateur developer”, although I’m happy to try things as long as I know the right things to do.
I’ve only got two things linked to the opensprinkler at the moment (stations 1 and 2 - that’s all I need), so even just creating a brand new configuration for the opensprinkler binding won’t be a hassle, as long as it can either be done through PaperUI, or there are up-to-date docs that match the snapshot. Given that there’s a fair bit else running on the openHAB system itself, I’d prefer to keep that running stable release versions than latest snapshots if possible. I suppose we might be coming close to a release cycle for openHAB core anyway.
I’m using the current release of openHAB, so that’s… 2.4.0? And the version of the opensprinkler binding that came with it. OK - I’ve just found the “bundle:list” command - 2.4.0 for both openHAB core and the opensprinkler binding.
Ok, that’s an older version of the binding, which does not include the rewrite of the binding, that’s why I can’t find the corresponding code path for the log message anymore
I’ve only got two things linked to the opensprinkler at the moment (stations 1 and 2 - that’s all I need), so even just creating a brand new configuration for the opensprinkler binding won’t be a hassle, as long as it can either be done through PaperUI, or there are up-to-date docs that match the snapshot. Given that there’s a fair bit else running on the openHAB system itself, I’d prefer to keep that running stable release versions than latest snapshots if possible. I suppose we might be coming close to a release cycle for openHAB core anyway.
I completely understand that you want to keep your running system stable, that’s totally fine. So, my idea would now be, if that is ok for you as well, that we go forward with setting up a local test system (openHAB wise) on your local computer and work with that to see if the error is fixed in the latest snapshot version. If that is ok for you, I would kindly ask you, if you can provide the operating system you’re using? Do you already have some knowledge with docker?
This would be the steps I kindly ask you to do:
Install docker (Get Docker | Docker Docs) on your computer, you can find instructions for different operating systems on the left side in the navigation tree
Start up a local openHAB instance, see the docs for that Docker | openHAB (use snapshot as a version tag)
After that you should be able to open http://localhost:8080 in your browser and it should open the openHAB page you’re already familiar with
Now finish the initial setup, go to bindings and install the opensprinkler binding
Setup at least one thing in your openHAB and see if it is going offline as well
This may be a lot of work for you depending on how familiar you’re already with the stuff involved, so I would like to thank you already for taking the time to help us here finding the underlying problem, no matter if you decide to go this way with docker or not
OK - that’s a fair chunk of unfamiliar territory. I’ve never used docker, and I’ll need to devote some time to that - probably won’t have the chance for several days at least.
However, I’ve also just discovered that despite openhab’s binding saying it’s offline, the commands to run the stations are sort-of working. By “sort of”, I mean that it ran one station for 18 hours today, and would probably have run the other for 24 hours if I hadn’t noticed the sound of water running and turned it off after only an hour. This is because the rules that set the timer to turn the stations off again are bypassed by the binding reporting that the station is offline (even though it isn’t): the station state within openhab immediately becomes OFF after being commanded ON, thus not having the chance to trigger the rule to set the off-timer.
So it’s not just benignly wrong, it’s malignantly wrong.
I dunno. Maybe I should just update the whole thing to the latest snapshot? But are openHAB planning a release some time soon? It seems bad for the current release to be so far out of date that we’re essentially in “unsupported” territory for the bindings.
Anyway, it’s frustrating. I’ve turned off the opensprinkler altogether for now so I won’t discover any more days like today. I suppose it probably makes more sense to delete the binding from openhab and set up the opensprinkler to run based on its own schedule, but it’s not nearly as smart as the logic I’ve got programmed in openhab.
There are Milestone releases once a month (usually). Honestly, a Milestone release has about as much testing prior to release as the so called stable releases. Essentially, either means that there are no known bugs that break things, or if there are such bugs the fix for them are unknown. Release versions of OH get a slightly longer period of burn in but do not think there is anything magic about the stable releases. They are stable because they go six months (usually) without updates, not because they are better.
OH 2.5 M4 was just released a few days ago. The official OH 2.5 is expected by the end of the year.
SUCCESS! Updating the system to 2.5.0.M4 and setting up the new binding, has worked perfectly. It’s now responding correctly, shows no sign of spontaneously dropping offline… and I’ve also added a backup water-off timer that doesn’t depend on a successful return from the water-on command, so that next time this happens I won’t waste over 6000 litres of water discovering it.
Awesome that it does work now, really sad about the last thing, the water loss Hope that this is now fixed. Can you elaborate a little bit what the problem was? Maybe this can be fixed in the binding itself?
The water loss was associated with the way the 2.4.0 binding responded to flagging the device as offline. I have a pair of rules set up along these lines:
Rule 1, triggered by time (offsets from sunrise/sunset) - according to certain logic, commands one or another station item to ON (using stationItem.sendCommand(ON)).
Rule 2, triggered by a station item changing state to ON, sets a timer to turn all stations off an appropriate number of minutes later.
The problem arose when the binding was reporting the thing as offline: when rule 1 fired, it sent the command to turn the station on, but instantly openHAB’s internal feedback was “station x predicted to become OFF”. The ON command was passed through to the opensprinkler unit, but according to openHAB itself the station never changed state to ON, so there was no trigger to cause rule 2 to fire. openHAB thought the station had remained off because the binding said the opensprinkler thing was offline (therefore couldn’t receive commands), but it had been successful in passing the ON command through to the opensprinkler, so the station stayed on forever.
I’m not sure if the new architecture could even do that, now that it has two logical layers between the opensprinkler unit and any associated openHAB items. If the bridge indicated that the opensprinkler was offline, would the station things be prevented from sending any command to the bridge? Or is it still possible that an ON command could be sent all the way through, with openHAB believing that the station thing had remained in the OFF state?
In either case, I have now added a backup timer to rule 1, which should always set a timer to command all stations off after twice the normal time, even if rule 2 is never triggered.
Given that OpenSprinkler is open source, maybe a fail safe could be added to the device itself similar to your timer. Set a max time that the sprinkler is allowed to run. If it doesn’t receive an off command in that time, the device turns off the valve on it’s own. Then no matter what, as long as the device has power, if everything else fails (OH, networking, etc) the sprinkler will not run forever.
@FlorianSW
Hi Florain
First thank you for your work.
Could you help me with dissabling rich INFO messages in Karaf system?
Currently we have winter and I switched off OpenSprinkler device…
In log files I can see large info messages like:
Could not create API connection to the OpenSprinkler device. Error received: org.openhab.binding.opensprinkler.internal.api.exception.CommunicationApiException: There was a problem in the HTTP communication with the OpenSprinkler API: There was a problem in the HTTP communication with the OpenSprinkler API: Request to OpenSprinkler device failed: java.net.NoRouteToHostException: No route to host
QUESTION: it is possible to run commands like - this example is NOT working
log:set WARN org.openhab.binding.opensprinkler
BTW (other question):remainingWaterTime and nextDuration -schould work with existing OpenSprinkler programs or with manually triggred jobs only?
To the problem: I can not help you turn off the log messages, tbh, would need to read into the docs myself. However, if you turn off the device a binding is communicating with, maybe “just” disable the associated things as well? That should not only turn off the log messages, but also makes the system not do pointless http calls?
To the last point: They work with manually triggered jobs only, iirc, but I’m not that sure, tbh. Maybe try it out?
I would love to be able to do that - unfortunately, I’m having great difficulty building the OpenSprinkler firmware from source (and there doesn’t seem to be any point modifying the source code if I can’t get it to build).
Just today, with no errors at all in my log, I discovered that a false “off” signal had come from… absolutely no idea where… shortly after the sprinkler turned on, and it was running all day before I noticed. I think you’re right that I need to find a way to get the safety limit into the OpenSprinkler firmware, but apart from submitting a feature request and waiting for the folks who run the project to incorporate it, I don’t know how to make it happen.
Maybe you can setup a test system with docker and your opensprinkler?
