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…