A lot of good stuff here - and interesting to see how the issue shows itself with different hardware.
For this problem I would recommend a fix such that the ON true/false would be used like “when ON changes from true to false” or “when ON changes from false to true”
This is the other issue - homekit keeps it’s own persistence data and always remembers the last dimmer value.
I moved on from OpenHAB’s native homekit setup a while ago. It’s great to see progress - but for my case running homekit in node red lets me write javascript functions to fix everything mentioned above.
My last issue to fix is that occasionally a 0% dimmer level is remembered by homekit as the last value - which means “hey siri turn on the light” sets it to ON=true , brightness=0. I think I know what’s causing it but I haven’t fixed it yet. It’s such a rare occurrence and like everyone else I have more important things on my to-do list.
I don’t think this is true. I’ve never seen HomeKit remember the last value for brightness. If I turn a light on in the Home App by tapping the item, HomeKit sends ON and 100%. If I turn a light on with Siri by saying “turn on ”, I only get the ON command (at which point my switches return to their prior state, but not because HomeKit knew to do so). Here’s the exact request I just received doing so:
PUT /characteristics HTTP/1.1
Host: openHAB._hap._tcp.local
Content-Length: 60
Content-Type: application/hap+json
{"characteristics":[{"aid":954550827,"iid":9,"value":true}]}
Which version of iOS did you last confirm via logs that you’re getting a brightness + power characteristic, initiated by Siri, where brightness was the last remembered value?
Persistence may not have been the right word. It doesn’t SEND the last value when you turn it on but it definitely remembers the value.
Take a dimmer item in the home app and go through the following steps:
1-turn it on
2-drag the dimmer to 25%
3-go to the “room” or “favorites” screen
4-tap the item (turns off)
5-tap the item (turns back on - to 25%)
HomeKit remembers. I know the 25% message isn’t sent at this point, but homekit remembers the last level of the dimmer when it comes back on.
Please note I am using a system with HAP-NodeJS homekit integration, not native openhab/homekit. It’s possible but I think unlikely that openhab is different.
I dunno how that’s working for you. When I get to step 5, my dimmer turns on to 100%. And logging clearly indicates that HomeKit sent both ON and brightness: 100%. Maybe something about the layout of the characteristics?
I’m not a programmer- more a power-user who likes to read documentation and test all of the features… I could send you a link to the github for hap-nodejs but I bet you can find it if you want to check out how they do it.
I really submit, again, that this is a binding issue. The binding should know whether or not the device in question allows out-of-order brightness and on/off state settings, and it is up to the binding to deal with it. For example, if it’s not supported, and the device-in-question is off, but the brightness is set, then the binding should cache the dimmer level and wait for an on/off event.
It is not Homekit’s job to do this, or to know limitations of various devices. Such limitations are not universal. For example, with TP-Link dimmers it is possible to send brightness and on/off out-of-order.
Piling in workarounds in the OpenHab Homekit addon to overcome faulty bindings is not the best way forward.
when you are running OH2.4 the bundle version in bundle:list will be the same version.
Make sure you have:
removed homekit via paper-UI
copied the v2.4.0-homekit-6 jar-file to the addons folder
If you haven’t removed homekit from paper-UI, you will get a message in your openhab.log file during startup : org.osgi.framework.BundleException: A bundle is already installed with the name “org.openhab.io.homekit” and version "2.4.0"
I have now tried to insert empty batteries and I get the battery message displayed. So it works. But… after the next start of the app the battery message is gone again. Can you still change that?
about the fact that respective openhab bindings should deal with this.