Mainly driven by the bluetooth binding I migrated my environment to OH 3 M2 these days. Most of the things are up and runnung smoothly.
As the rework of http1 binding seems to be not finished I’ve tried opensprinkler binding to connect to my device once more. But the binding tells me that it is not able to access it.
COMMUNICATION_ERROR
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: Error sending HTTP GET request to http://X.X.X.X:80/sn0. Got response code: 404
while the address and the port is accessable in the browser and also using telnet to check the local network route.
/sn0 does not seem exist at least not in my OpenSprinkler setup but I don’t find where I could change this.
I checked it with the lates oh3 build and it works immediately after entering the right things. I changed the opensprinkler passwort from opendorr to something else and the port ist not 80 it is 8080 on my system. After these changes the binding goes online immediately.
No , I still play around from time to time. But there is no way to get the connection up.
No mather if i try to discover, add it manually or configure it with things file.
OpenSprinkler is a good product with a fair price for home irrigation control. Beside the fact that it could be used for much larger areas than mine (50 sqm)
I had a quick look into the code base of the binding and I think it fails somewhere in the identification of OS version (OpenSprinklerApiFactory).
I would not make a statement about the binding itself as I up to now never used it and currently even cannot use it.
No I didn’t and I think will not focus on that.
As I wrote earlier in V2 I was using HTTP binding to get what I need and most probably I will do the same approach in V3 but I didn’t decide yet. I also spent some time with MQTT in OH2 but never came to a point where I was really happy with it.
And as I don’t have any other devices that would enforce me to use MQTT I don’t see a reason to try it yet.
So I will simply see what’s changing till OH3 becomes its first final release. I hope that the opensprinkler binding will get some better handling in the meantime.
I had entered the hostname/address for my binding with a leading “http://” which should be okay. Ran into the same issue as you with GET “/sn0”. Removing the leading “http://” appears to have solved the issue.
Fixed the on and offline detection which meant doing huge amounts of code shuffling so this needs some testing to find any bugs.
Made the current sensor show up again in V3.
Cached the replies as the binding was making the same request 4 times for each station you had setup, so now it only fetches the state once per poll. This was insane as it was fetching the same thing 8*4 = 32 times for a single 8 station unit if my understanding was correct.
Discovery is now done differently to remove apache commons library and they now list the IP they were found at.
I think I have sorted the main bits of the code so I can finally look at adding some new features to this binding.
What do others think about the binding and what should change?
Firstly thank you for taking the interest in this binding and for addressing the issue with the currentDraw channel.
I deleted the version of the binding that ships with OH3 and dropped your jar in the addons. I had to restart OH3 but it was detected after that. I did notice that all the stations came online first and it took maybe a minute or so for the HTTP Interface to change from initializing to online. (I think it was the HTTP interface but it might have been the device Thing). After that I confirmed that the stations all work correctly and the currentDraw channel is now visible and provides the correct information.
Overall the binding has been pretty good to me. I haven’t had any problems with the online/offline detection, or if I did, I didn’t notice it. Maybe once or twice I had to power cycle the device to get it to get picked up by the binding, but nothing that worried me enough to investigate. When the binding switched to using the HTTP Interface model it was originally slow to update, but I changed the refresh to 5 seconds and it’s been pretty good.
Although the OpenSprinkler device, web interface and API have a lot of features, I use the binding simply to switch the valves on and off, with all my scheduling is done through OH rules, so the binding with its current feature set has been completely fine for me. Having had said that you suggested the possibility of future enhancements so I came up with the following two ideas, which I will preface as being very specific to my use case, may not be interesting for others and are probably “good to haves” rather than “must haves”:
include support for the rsn parameter. This parameter resets all the stations. I use the cascading timers DP to cycle through the stations I wish to trigger, switching them on and off in turn. Sometimes, usually after I have been fiddling with the code, I have inadvertently double triggered a particular station, which causes it to be “queued” in the device. This has resulted in subsequent stations not being opened, but rather added to the end of this queue (at least this is my interpretation). It would be helpful, but not critical, to be able to reset all the stations when the irrigation cycle is cancelled, and avoid having queued stations blocking subsequent runs.
include support for flow meters. Due to some annoying “sticky” valves, I had the ambition of eventually getting a flow meter, mostly to double check that stations have actually been switched off, so adding support for the flow meters could be something to consider, however I don’t even have a flow meter yet and am only mentioning this as you asked for ideas.
Hope some of this is helpful and thanks again for fixing the currentDraw channel…
This has happened here a few times to me and I suspect it is the hardware firmware and not connecting to the wifi, as when that happens I can not reach the webpage of the hardware until I power cycle the device. The moment it is power cycled it shows up on network again and everything works for hours. The merged binding would still show as online when that happened and only went offline for a split second.
@smhaller
I have not seen the binding send this yet, what causes this to get sent? How to reproduce?
EDIT:
try sending this and reporting back what it shows. This is used to work out the firmware version and I suspect yours is trying to use V1 firmware/api which does send sn0 which is not used in newer firmwares.
This is what I thought as well based on having a look into the code lines. But I don’t / didn’t get why the binding was not able to find / identify the correct version…
It would also be a good idea to try using the linux wget command to fetch this to ensure there is not a firewall issue stopping the request from reaching the binding. Its possible for another device to sucessfully work but a firewall rule to block the same call from the openhab machine.
EDIT: @smhaller what happens if you give the wrong password that is not hashed? Try this…
/jo?pw=wrong
It should still give you the same output and it wont give you the full data set unless the password is in the hash format.
If you enable TRACE logging on the binding do you get any clues? note the md5hash does not offer your password any protection so dont post any output after ?pw= in the URL’s that are logged. The latest version I uploaded has the logging removed so if you have the first version I uploaded it had a lot more log output in it.
