I am not sure what version of the binding I had. It was one you previously had me load by dropping into addons. it was 3.2.0.X, but not sure exactly. So I installed the new one by dropping it into the addons folder. Once I looked back at my Things page, I noted that the Water and FlowSensor Things for both bodies of water were “Uninitialized” (I deleted them and attempted a re-scan), previously these were their own “things” with separate channels, but it now looks like they are grouped under Pool and Spa BOW, but they both seem fine and linked to the original items.
The re-scan found the two heater things (system ID 5 and 13), so that’s good. But the newest problem since I updated the binding is that the binding does not seem to be calling for the getTelemetery data call every 12 sec as I have it set. It does call for the getAlarmList every 60 sec though. So currently I’m not getting any new data from the system. Any ideas?
@matchews… More data: I am able to get it to do one getTelemetery call by pausing and then un-pausing the OmniLogix connection thing. Then it throws this error one time and doesn’t seem to do another getTelemetery:
12:24:16.519 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) ~[?:?]
at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) ~[?:?]
at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248) ~[?:?]
at java.util.Objects.checkIndex(Objects.java:372) ~[?:?]
at java.util.ArrayList.get(ArrayList.java:459) ~[?:?]
at org.openhab.binding.haywardomnilogic.internal.handler.HaywardPumpHandler.getTelemetry(HaywardPumpHandler.java:156) ~[?:?]
at org.openhab.binding.haywardomnilogic.internal.handler.HaywardBridgeHandler.getTelemetryData(HaywardBridgeHandler.java:348) ~[?:?]
at org.openhab.binding.haywardomnilogic.internal.handler.HaywardBridgeHandler.lambda$1(HaywardBridgeHandler.java:381) ~[?:?]
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:829) [?:?]
@matchews, I installed it in my test system (I’m on the road, sorry about the delay) and it did fix most of the issue. As far as I can tell all of my things are working, or at least receiving data. I haven’t tried sending commands with the latest build yet since I’m not actually at the house. Need to let the wife know before I start turning pumps on/off!
There is one error that I get after every telemetry call:
15:04:48.925 [DEBUG] [internal.handler.HaywardBridgeHandler] - Hayward getTelemetry XML File Open: IO Exception: C:\Users\Controls\Desktop\Hayward User Data<my username> getTelemetry2.txt
(Sorry I can’t figure out how to do code fences on my phone)
This isn’t a folder on my system, so I’m guessing it must be some kind of remnant from where you may have had a temporary text file for testing?
First, let me say, thank you for being patient with me! I’ve updated the binding and here are the latest issues:
If I set a pump to 50% with the native Omni app, I see it go from 0% to 50% on pumpSpeed getTelemetery response, and the lastPumpSpeed changes to 50% if it wasn’t already. If I turn it off and then back on with the switch on the app it goes back to 50%. If I turn it off and then back on using OpenHAB and the pumpEnable channel, it will go to some other setting. Some pumps go to 75% and some go to 100% (so it seems that they go to their max speed). Shouldn’t they go to the lastPumpSpeed value (which in this case would have been 50%)? Is this possible somehow?
BTW, I’ve noticed that there are lots of new channels and that some old channel names have changed. I have updated all of my pump items and that answered a few questions. I will probably delete and recreate all of the things just to be sure I’m not missing anything.
Here are the startup Errors I’m still seeing…
During startup I’m seeing this warning a few times:
14:51:49.315 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler HaywardBridgeHandler tried updating the thing status although the handler was already disposed.
It looks like during startup the whole binding tries to initialize twice… there are probably 1000 lines of trace and debug log output, but scrolling through it I can see where it gets the MSP config twice and it gets the whole API download twice, it seems like it’s successful on the second try or at least I don’t see this error anymore after that.
Then I noticed I’m seeing this during startup:
14:51:48.196 [DEBUG] [internal.handler.HaywardBridgeHandler] - Hayward getMSPConfig XML File Open: IO Exception: C:\Users\Controls\Desktop\Hayward User Data\<username> getMSP.txt
And I’m seeing this at the end of the startup:
14:52:00.595 [DEBUG] [internal.handler.HaywardBridgeHandler] - Hayward getTelemetry XML File Open: IO Exception: C:\Users\Controls\Desktop\Hayward User Data\<username> getTelemetry2.txt
14:52:00.595 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NoClassDefFoundError: org/openhab/binding/haywardomnilogic/internal/HaywardThingHandler
at org.openhab.binding.haywardomnilogic.internal.handler.HaywardBridgeHandler.getTelemetryData(HaywardBridgeHandler.java:348) ~[?:?]
at org.openhab.binding.haywardomnilogic.internal.handler.HaywardBridgeHandler.lambda$1(HaywardBridgeHandler.java:384) ~[?:?]
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:829) [?:?]
Caused by: java.lang.ClassNotFoundException: org.openhab.binding.haywardomnilogic.internal.HaywardThingHandler cannot be found by org.openhab.binding.haywardomnilogic_3.2.0.202112140037
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:519) ~[org.eclipse.osgi-3.16.300.jar:?]
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:170) ~[org.eclipse.osgi-3.16.300.jar:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:522) ~[?:?]
... 8 more
So it still looks there may still be some debug code, or something in there because for both the initial getMSPconfig and the initial getTelemetery calls it’s referring to a path that doesn’t exist on my machine.
After startup the normal getAlarmList and getTelemetery seem to happen without errors.
If this is normal behavior I’ll stop worrying about it!
I did reconfigure some of the channels based on new intel I’ve learned about the API. The reverse engineering of the API is a work in progress as I don’t have every device (i.e. pump) that Hayward offers. The best way to handle this is to delete all of the things and the bridge, then re-create the bridge using the old UI, then add the things. The channels that didn’t change will reconnect with your existing items. I added logic to set the speed of the pump and filter to the last speed. The high, med, low states do have default values, but those are overwritten with the actual high, med, low speeds from the OmniLogic. I fixed what I could, but this isn’t 100% tested as I don’t have a pump…
All the work you’re doing on this is fantastic! Thank you. However, I was not able to download the latest .jar from the google drive, almost like it isn’t there or something, it’s giving me a “The page isn’t redirecting properly” error. I tried my phone, iPad and PC. I’m in Germany now so shouldn’t be any internet issues, everything else seems to work.
Excellent! I got it going, I was able to get it from my iPad to my PC. Looking good. The pump and filter enable channels now do go to the “lastSpeed” when they are turned on, which is awesome! (Same action the native app uses) The pumpSpeedSelect and filterSpeedSelect items all exhibit weird behavior. They do now seem to pull the pumps specific speeds (Low, Med, High) from each pump, but they don’t always use the correct “Label” for that speed.
Example: If I select “LOW” in the dropdown menu on the sitemap for the filterSpeedSelect, it commands the pump to 48 (this particular pump has a Low, Med, High of 48, 50, 75), which is correct, but then it displays “CUSTOM” as the SpeedSelect string. On another pump it has similar behavior when I select “HIGH”, this pump has a Low, Med, High of 50, 75, 100 and when I select HIGH it displays “CUSTOM”.
I am wondering if CUSTOM value should be removed. Is there any way the dropdown can just have “OFF, LOW, MED, HIGH”, and then if another value is set for the speed via the pumpSpeedPercent channel, or via the Hayward system itself, then the SpeedSelect string could just say “72” (the string representation of that actual percentage, that doesn’t correlate to OFF, LOW, MED, HIGH. With CUSTOM in the dropdown, I don’t know what I would use it for anyways.
The custom value also comes from the OmniLogic as a 4th preset speed. If the actual speed is something other than Low, Medium, High or Custom, it will display the numeric value. The issue you are seeing is caused by your custom speeds matching with another preset. Change those custom speeds in your OmniLogic and the problem should resolve. See the snippets below from your getMsp. Is everything else working OK?
Ok, wow! I will fix those on the Hayward side then. Thank you. It looks as if everything else is working great, but I won’t be able to fully put it’s through its paces until I’m back at home. Have a great weekend.
@matchews in the last three or four weeks (estimated) I’ve been having lots of connection issues where the Binding goes offline, and the Hayward OmniLogix Connection thing specifically says:
OFFLINE (COMMUNICATION_ERROR): Connection Timeout. Check Hayward hostname and your internet connection. java.util.concurrent.TimeoutException: Total timeout 10000 ms elapsed
I have my Telemetry poll delay set to 12 seconds, and my alarm polling set to 60 sec, FYI.
Once I realize that ‘most’ of the binding is unresponsive, if I go into the OpenHAB settings, things and then Pause and Restart the Hayward OmniLogix Connection thing, it all comes back to life. I have other notifications in my OpenHAB that alert me if my internet goes down, and the internet is solid, also, I have the Pool controller connected via Ethernet Cable, not Wifi, so I know that’s not the issue either. I think something’s changed with either the Hayward API or the way the server handles requests and it’s kicking the bridge offline.
Also, the reason I said ‘most’ above it because sometimes when it’s in this state I can control a few things, like the pool jets, or the lights, for instance, but everything else is unresponsive. Also, there are now situations where I will command the pool jets or lights to turn off, and they will, but the status never makes it back to OpenHAB.
I’m wondering if maybe you’ve made updates to the binding and I need to load a more recent version. I have the most up to date milestone upgrade of openHAB.
@stagf15
I have also observed this anomaly approximately 3 times over the last 1.5 months. Restarting the OmniLogix connection brought it back online for me as well. I also noticed that I had one device that did not go offline (Relay - Deck Jets), but I didn’t attempt to send a command to it or any other devices while the bridge was offline. I set my logger to trace mode and also have it setup to log to and independent file. If you can do the same and send me any pertinent log entries, that will help identify the issue. I would also like to confirm that the only device that did not go offline for you when the bridge went offline were of the type “Relay”. That sounds like a bug in the Relay handler. As for the commands not making it to the OmniLogix, I haven’t noticed this on my end. If you can send me a log of the outgoing command, the associated command response and 2-3 subsequent getTelemetry calls, that would be helpful.
Hello. Matt Myers.
I am looking for information about how to integrate our equipment with Hyward.
Currently main question is getting information about pump state and control a pump.
You wrote openhab binding for Hyward. As I see it’s using their web API.
Would you share their API details or provide information how to get it?
I found the issue. The server is sending back an empty xml response and there is one place in the code I’m not handling it. Once I get my IDE back online, I’ll push a fix.
I increased the HTTP response timeout, and added a few retries before taking the Thing offline. I still see an occasional empty XML file coming back from Hayward, but the communications are much more stable.
I finally got the .jar uploaded and it’s been running for more than a day, which is a step in the right direction. I will let you know if I have any disconnection issues. I am very sorry I wasn’t able to help with any of the troubleshooting and logging… we’ve basically had the busiest and most chaotic summer I can remember and I haven’t yet been able to come up for air! Thank you for all your work on this binding!
