I have made some big changes to the OpenSprinkler binding and need some users willing to help test it out and look for bugs. Since I don’t have the PI version it would be great to hear from someone with one of those. There should be no breaking changes with the old functionality, only new features and fixes have been added. Due to new channels getting added it is probably necessary to delete and re-add the things.
I installed the test binding and it seems to work well. Thank you for adding the resetStations channel. I have already made use of it. For interest, I am using the OpenSprinkler HW version 3.1 (the DC model) with firmware 2.1.9 (2). After the update I confirmed that everything worked as it did before I added the new binding.
I was able to test the following new channels:
They are working completely fine. With the new “stations” channel, I initially I forgot that the valves/stations are numbered starting from 0, so when I tried to trigger my 6th valve (station 5) I incorrectly sent the command to activate station 6. This meant that a non-existent 7th valve was put into a queued state. Luckily I was confirming things through the OS web portal so I was able to switch it off.
As all my scheduling is done through OH I didn’t look at the channels which trigger the programs coded in the opensprinkler device.
Happy to answer any questions or test a specific feature you might be worried about, but from my point of view there’s no reason to stop using this new version. Thank you for the time you have spent on it.
You can give the stations a name in the web portal of OS and after doing that change the poll/refresh time of the binding to trigger a restart. Doing this will populate the stations with friendly names so you can’t get mixed up.
Thanks for the feedback, nothing needs to be tested in particular just if you notice something please don’t hesitate to post so it can get fixed before it gets merged.
Today I upgraded from OH 3.1M2 to 3.1M5 and am now getting the following error:
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.opensprinkler 
Unresolved requirement: Import-Package: javax.measure; version="[1.0.0,2.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:440) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.8]
I still had the addon jar from January (been working beautifully since then), so I removed it and tried with the 3.1M5 version, and while it works without any error, it seems your changes may not have been merged yet. I then downloaded a new copy from the link in your original post but it results in the same error.
I’m hopeful that this is something that can be easily fixed
EDIT: This was posted shortly after I posted this:
EDIT 2: After reading that post a few times I am suspecting (in my very untrained way) a dependency issue for bindings which aren’t part of the official distribution…?
I don’t know the exact reasons for it, but I suspect it happened due to dependancies located on the server that got shut down and hence the need for a new core to be created for openhab 3.0.2.
Good news is I already fixed it a few weeks back and its been running fine on my system here, but did not upload it as the newer build may have issues on older cores. Download the newer build which I just uploaded. If you have the merged copy installed, you need to uninstall it for the external jar to be used.
New build opensprinkler-20210703.zip uploaded for openHAB 3.1 Milestone 5 and newer which has a new feature. Now when you move a control, 3 seconds later the rest of the controls will be updated instead of you having to wait until the next poll time. Handy as you see the current draw jump to confirm the solenoids have worked. A 3 second delay is necessary due to how AD convertors work as they have to charge a cap and this takes time to get a stable reading.
It is merged and built into the latest openHAB Milestones and will also be in 3.2 Stable which is days away from a release. To see the new channels, you need to delete and re-add the things if you were using the older version of the binding when the things were created. Items do not need to be deleted, so keep the UID the same.