#4 is the method that worked for me. What version of OpenHab are you running? I compiled the jar for 3 and 4, but it’s untested on 3. Im running 4.
Maybe that’s it… Sorry, I am still on OH3. 3.4.1 I think. I should have let you know that!
I haven’t been doing a lot of reading on the forums lately. Is 4.0 ready and stable? And, I’m hoping it’s a little easier than the switch from OH2 to OH3!
But, in the meantime, I’d be glad to try out your 3.0 jar.
The 2023-05-12 jar was compiled for OH3 and OH4. I went ahead and recompiled it…
I’m running 4.0.0.M2 and it is stable. If you are using ECMA scripts, you will need to update them from Nashorn v5.1 to Graal ECMA 2021 v11.
Sorry about the continual delays in testing these out… I hope you had a nice memorial day weekend. I’m still unable to get the new .jar to work. This is the error I get when trying install it from karaf console:
openhab> bundle:install file://home/user1/haywardomnilogic_400.jar
Bundle IDs:
Error executing command: Error installing bundles:
Unable to install bundle file://home/user1/haywardomnilogic_400.jar: org.osgi.framework.BundleException: Error reading bundle content.
One question, I’m renaming the file ‘haywardomnilogic_400.jar’, is that a problem? Does it for some reason need to stay the same name that you sent? If so, do you know how to make a file name with a space in it work in karaf?
Phil,
Please upgrade the release binding with the jar file. This is what worked for me.
- Do bundle:upgrade ### from home folder, with release binding installed = Binding does not show up on ‘add thing’ page, looks good on the bundle:list
This morning I tested the jar from 5/26/23 (from google drive) and it upgraded fine on my OH4.0.0.M2. I did rename the file to eliminate the spaces without any issues. I went ahead and recompiled it again (for both OH3 and OH4).
If this doesn’t work, I suggest you upgrade to OH4.
Success! I haven’t been home to change my operational OpenHAB server to 4.0.0 yet, but I’ve upgraded my test setup on my laptop (Win) to 4.0.0-Snapshot, dropped the latest .jar into the addons folder, and it worked with no problems. I deleted and rescanned for the Light thing and the new Brightness (0-4) and Speed (0-8) channels were there, and they are updating fine. I haven’t actually sent commands yet, I am going to make rules so that there are proxy dimmer items to use for each.
Thank you! I’ll let you know how the commands are received once I get a chance to do that.
Glad to hear that. Once you confirm the commands are functional I’ll update the released version. Please also check to make sure the appropriate light shows/colors are showing up. Thanks.
Will do! Thanks again.
Phil,
Did you have a chance to confirm the commands are functional and the correct light shows/colors are showing up?
Thanks
I actually just loaded 4.0.0-M3 on my home system, and will be copying the jar over tonight and testing the commands. I will let you know ASAP!
Ok, here’s what I’ve found. Most of it functions as it should, as far as I can tell. These are the issues:
- Pool Lights Show naming is slightly inconsistent: Some of the names have underscores for spaces, others don’t (not a big deal, but I like it with spaces instead of underscores, if I have to choose)
- The “Afternoon_Skies” name is actually “Afternoon Sky” on the Hayward App
- When using sitemap generated Selector for the Brightness Item, it appears to properly enumerate the selections and send the commands, as does sending 0-4 (for 20-100%) to that string item. And, the lights properly change. The only strange behavior is that when I select a colorlight show (multi-color) rather than one of the solid colors, the brightness value that returns in the getTelemetryData response is ‘7’, which there is no label for, so when looking at a sitemap generated Selector switch for the brightness item, one of the selections is ‘7’. I don’t know what ‘7’ represents… not sure if you do based on Hayward documentation, etc.
That’s all I’ve found so far, but it was a pretty quick test, I’ll continue to test it. Thank you!!
Thanks Phil.
- Underscores were previously removed.
- No problem.
- None of the documentation mentions a valid description/value for a brightness of 7. I pulled a fresh ApiDef from my controller and it matches the one you sent back on 3/28/23. You could try to pull a fresh apiDef to see if something changed on your end. What was the brightness value on the solid color before switching to a show and the brightness changing to 7? Maybe you can correlate the old and new values. You can also try creating a number item and entering 5-? to see what happens. Maybe they are using 5-9 for the shows rather than 0-4?
<Key name="0">CL_20_PERCENT</Key>
<Key name="1">CL_40_PERCENT</Key>
<Key name="2">CL_60_PERCENT</Key>
<Key name="3">CL_80_PERCENT</Key>
<Key name="4">CL_100_PERCENT</Key>
</Brightness
Here is the updated jar. Let me know if everything is corrected (my lights don’t support brightness). It looks like the 7 was sent to the server, which will set it to a 4, but return a 7 in the getTelemetry. I added a limit to the outgoing command with a max of 4.
So, for some reason changing the Pool Lights Speed, on a Colorlogic Show, changes the Brigtness as well once the getTelemetry is returned…
But, I can’t figure out what the pattern is. It’s all over the place. If I select 1/16th speed using the binding, sometimes the brightness changes to a 7 (out of limits), sometimes to a 4. Changing Speed to 8x usually sets the brightness to 8 (out of limits). Speed 2x sets brightness to 6, Speed 1x sets brightness to 5. Then selecting a different show changes everything, I tried setting “Gemstone” and the Brightness comes up as 6, and the speed comes up as 8x.
For some reason, in the binding, changing the Brightness, Show, or Speed changes some or all of the other values. I’ve verified that this isn’t the case in the Hayward App or via the controller. In fact, when the incorrect messages get sent from OpenHAB, it puts the app display into an out of range condition. I’ll attach two pics in my next post, one of the app normal, and one of the app when it has received the out of range data.
Let me know what else I can send! Thanks!
Here is the out of limit display, you can see the brightness % is off the charts and overlaps the speed. Clearly the app doesn’t know how to handle these values, so I don’t think they’re supposed to be sent.
I found the bug. Hopefully this does the trick. This is untested…
Fixed a couple typos in the Pump thing…
Great! Loading it up now. I’m going to remove and reload both pump things just in case that’s necessary. I would be interested to know the details of what you found, if you have time to explain. I’ll let you know how it goes.