OH3 opensprinkler binding

As a request with Json Translation using http Binding works to get the station Status Back, i would assume the same does for the opensprinkler Binding.
But tested it and receive status 200 and the same result back.

With the modified binding i don’t have the Error anymore. It it Just stays at initializing

See my question in my last post about the wrong password, my theory is the PI version must do something different to the esp8266 version and this is my best guess that it does not reply with the firmware if the password is wrong.

/jo
/jo?pw=wrong

They both give the firmware version on the esp8266 version of the hardware.

I also uploaded a newer version last night which will do a TRACE level log output of what the binding is reporting the firmware to be. If you can confirm there is still an issue with this build I can try installing the OS onto a uSD card and booting up a PI without the shield attached to do some testing.

DONE, feature added but until you setup the sensor the channel is not shown.
I also added RSSI for wifi signal strength.

Latest JAR here.
https://openhab.jfrog.io/artifactory/libs-pullrequest-local/org/openhab/addons/bundles/org.openhab.binding.opensprinkler/3.1.0-SNAPSHOT/org.openhab.binding.opensprinkler-3.1.0-SNAPSHOT.jar

I’ll look at this and a list of programs to run from a selection list. Still learning how it all works.

Hi Matt

Sorry I must have missed the hint regarding the password as I was on mobile phone.

I re-ran this again and /jo is giving the same as /jo?pw=wrong
while /jo?pw=HASHED.PW is giving back a much larger output.

Will test connection with latest snapshot too :slight_smile:

following is what I receive with TRACE on

2021-01-23 22:24:00.508 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'opensprinkler:http:993189ee5c': null
java.lang.NullPointerException: null
	at org.openhab.binding.opensprinkler.internal.util.Parse.jsonInt(Parse.java:42) ~[?:?]
	at org.openhab.binding.opensprinkler.internal.api.OpenSprinklerHttpApiV100.getNumberOfStations(OpenSprinklerHttpApiV100.java:211) ~[?:?]
	at org.openhab.binding.opensprinkler.internal.api.OpenSprinklerHttpApiV210.enterManualMode(OpenSprinklerHttpApiV210.java:135) ~[?:?]
	at org.openhab.binding.opensprinkler.internal.handler.OpenSprinklerHttpBridgeHandler.initialize(OpenSprinklerHttpBridgeHandler.java:68) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
	at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:834) [?:?]

OK that error is very helpful.

Can you supply me with the output of
/js?pw=HASHED.PW

The code is looking for nstations in particular and it usually will have a value of 8 if you only have 1 openSprinkler device. It should look like this…

{"sn":[0,0,0,0,0,0,0,0],"nstations":8}

yes this is also the result I receive.

@smhaller
can you test this newer build? You should delete and re-add the bridge and device things as the code and the channels they contain has changed greatly, stations are still the same so no need to delete them. If you use the same UID when you re-add these things everything should link back up.

The entire code that was causing that error you reported has fully been re-written.

http://www.pcmus.com/openhab/opensprinkler/

Hi Matt

Now I see the following:

2021-01-26 08:08:56.747 [DEBUG] [ndler.OpenSprinklerHttpBridgeHandler] - Initializing OpenSprinkler with config (Hostname: 192.168.223.121, Port: 80, Refresh: 60).
2021-01-26 08:08:56.827 [DEBUG] [internal.api.OpenSprinklerApiFactory] - Firmware was reported as 219
2021-01-26 08:09:18.905 [DEBUG] [ndler.OpenSprinklerHttpBridgeHandler] - Initializing OpenSprinkler with config (Hostname: 192.168.223.121, Port: 80, Refresh: 60).
2021-01-26 08:09:19.042 [DEBUG] [internal.api.OpenSprinklerApiFactory] - Firmware was reported as 219
2021-01-26 08:10:13.228 [DEBUG] [ndler.OpenSprinklerHttpBridgeHandler] - Initializing OpenSprinkler with config (Hostname: 192.168.223.121, Port: 80, Refresh: 60).
2021-01-26 08:10:13.315 [DEBUG] [internal.api.OpenSprinklerApiFactory] - Firmware was reported as 219

Firmware is reported correctly but unauthorized access and binding goes offline.

java.lang.IllegalArgumentException: Malformed escape pair at index 39: http://192.168.223.121:80/jo?pw=**removed**
	at java.net.URI.create(URI.java:883) ~[?:?]
	at org.eclipse.jetty.client.HttpClient.newRequest(HttpClient.java:442) ~[?:?]
	at org.openhab.binding.opensprinkler.internal.api.OpenSprinklerHttpApiV100$HttpRequestSender.sendHttpGet(OpenSprinklerHttpApiV100.java:400) ~[?:?]
	at org.openhab.binding.opensprinkler.internal.api.OpenSprinklerHttpApiV100.getOptions(OpenSprinklerHttpApiV100.java:313) ~[?:?]
	at org.openhab.binding.opensprinkler.internal.api.OpenSprinklerHttpApiV100.getFirmwareVersion(OpenSprinklerHttpApiV100.java:246) ~[?:?]
	at org.openhab.binding.opensprinkler.internal.api.OpenSprinklerApiFactory.getHttpApi(OpenSprinklerApiFactory.java:64) ~[?:?]
	at org.openhab.binding.opensprinkler.internal.handler.OpenSprinklerHttpBridgeHandler.setupAPI(OpenSprinklerHttpBridgeHandler.java:98) ~[?:?]
	at org.openhab.binding.opensprinkler.internal.handler.OpenSprinklerHttpBridgeHandler.refreshStations(OpenSprinklerHttpBridgeHandler.java:89) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: java.net.URISyntaxException: Malformed escape pair at index 39: http://192.168.223.121:80/jo?pw=**removed**
	at java.net.URI$Parser.fail(URI.java:2913) ~[?:?]
	at java.net.URI$Parser.scanEscape(URI.java:3041) ~[?:?]
	at java.net.URI$Parser.scan(URI.java:3064) ~[?:?]
	at java.net.URI$Parser.checkChars(URI.java:3082) ~[?:?]
	at java.net.URI$Parser.parseHierarchical(URI.java:3172) ~[?:?]
	at java.net.URI$Parser.parse(URI.java:3114) ~[?:?]
	at java.net.URI.<init>(URI.java:600) ~[?:?]
	at java.net.URI.create(URI.java:881) ~[?:?]
	... 13 more

The above error was caused when I adjusted the password in the code window. I saw that the Special Char that I use in the password was replaced with a Bracket. I changed this to the one which is correct.

What if for testing reasons you change the password to opendoor? It is possible the binding does not handle some characters correctly. On reading your reply again, does that mean the password was wrong in the code tab? If so this may be a bug in the mainUI if the password is not what you enter in.
If you can confirm it works with the default password, I can try and reproduce it here with characters that may cause issues.

I am using daily
Snapshots so my setup is different to yours.

I’ve just retried it, but I am not able to re-produce it, so I suspect I pressed the wrong character myself :slight_smile:

Anyway the error regarding malformed escape character persists. Whenever I change it to the correct password that contains a special char !!!

I will now change the password on opensprinkler itself so that it does not contain special charachters anymore and run another test.

Edit:
Seems to look better. The bridge comes online now.

I tested for this and could not reproduce it in the latest snapshot build so my guess is that it WAS and is now a fixed bug in the core. If I understood you correctly that the wrong password was showing in the code tab after entering it into the things tab, that can not have been a binding bug.
Glad its now sorted.