Thanks, I’ll test it. Is it possible to integrate the battery parameters into the thermostats? That would be very helpful. At the moment I solve this via an extra item with a switch. The integration via the group of thermostats would be more elegant.
Unfortunately, we’re confined to what combinations of characteristics Homekit supports with accessories, and battery-status isn’t one of them. I think you’ll have to continue you with your workaround.
I’ve been going off of this JavaScript HAP-NodeJS file as documentation for supported characteristics and accessories; have a look: https://github.com/KhaosT/HAP-NodeJS/blob/master/lib/gen/HomeKitTypes.js#L3443
hi Tim,
great work - I’ve been using the improvement for a few weeks - runs stable !
Do you consider including “LockMechanism” ?
Thanks Tim for the great improvement. With the 6th release everything works smooth. No delay anymore. Just one small thing i have noticed during testing. If my lights have a dimmer the order of sending command for different light are not equal. This results that the dimmer value does not work.
E.g.:
In my kitchen: (Not working, because dimmer sent before ON value)
1.) Dimmer value is sent
2.) On state is sent
In Bath: (Working)
1.) On state is sent
2.) Dimmer value is sent
May it be possible to also fix that also?
Edit: I just found an issue on Github which also describes this behavior. In my mind it would be enough not to send ON command again if the light is already on.
Do you think it is the fault of the binding or HomeKit?
Well, i’m no expert. But maybe it just Opebhab interpreting things different than the homekit protocol but then there might be something like adapter pattern to get both speaking the same language.
If found another source about this issue.
I’ve spent a good amount of time researching this issue. Here are my comments and observations that might be helpful.
I point the blame at how the homekit protocol works.
My first example is from my first time noticing this issue. I had Insteon dimmers with the official Insteon<->homekit hub. This is from back when Insteon sold and marketed as being “homekit compatible” and was actually listed on apple.com as a homekit partner. These days are over.
Anyway - this official hub had the same issue where if I had a light that was on then slid the dimmer the light would flash to 100% - then drop to the new dimmer level. Often it would get stuck at 100%. If I used siri (set light to 75%) that worked every time.
Fast forward to openhab when I first started, I noticed the same problem. My first solution (which worked great!) was to use rules and proxy items (linked above). This seemed very clunky to me and caused me to have double the number of items for my dimmers.
Next solution was to switch over to node-red for my homekit setup. This has really worked well. I have been able to program my javascript functions around the seemingly odd behavior of the homekit protocol. The other bonus of this is I can actually see each and every command coming from homekit into my workflow.
As I have stated above and in other threads, homekit deals with on/off as a message that says “ON=true” or “ON=false” - in doing this it remembers the previous brightness level of each dimmer so that if you have it at 10%, tell siri to turn it off, then tell siri to turn it back on - it assumes you’re coming back on at 10%. What happens in the message sending then is the previous 10% command is not re-sent. The only command will be ON=false to turn off then ON=true to turn it back on - assuming the lamp remembers it’s previous level just as well.
Oh did I mention the ON sometimes comes first and the brightness sometimes comes first?
The solution some people have used is to just ignore the ON messages and use the dimmer % messages. This won’t work in the cases where homekit only sends on. Well what about if we ignore the ON messages? Turns out the dimmer % message is also not always sent.
Extra messages can be sent into homekit anytime - but there needs to be something in the program to remember the previous brightness value of the dimmer for the case that homekit just says “ON=true”.
The fact that this all happens on every platform points to it being a confusing part of the homekit protocol rather than an issue with openhab. The writers of the openhab plugin just have not added in a way to handle it.
For even more fun, I believe this is the case with HSV colored bulbs as well. The ON message may or may not be accompanied by an HSV message.
This would make sense - from an openhab standpoint you could probably ignore the ON command unless it has changed. Might be an over simplification but I think it’s a start.
Good news for you: I’m running into this issue. Not exactly how you are, but enough that I’m going to fix it for me, and it should address it for you.
The tl;dr: is that HomeKit views the world as if the dimmer level is independent from if the light is on. Which in some ways is nice. All of my physical (wave) switches remember their last level themselves, and when you turn them on locally will return to that last level. I wish that I was able to “preset” that level without the light’s actually coming on (i.e. after midnight, lights will come on to 20% brightness when activated, rather than the 100% that they were last used at earlier this evening). In HomeKit’s paradigm, this could actually work. But the flip side is any device that can’t remember its prior level must interpret an “on” command as “go to 100%”. This is how OpenHAB is designed - it doesn’t rely on persistence, so it allows DimmerItems to receive ON or a specific percentage, and just passes that on to the binding (or if there is no binding, i.e. a proxy item, interprets it as setting it to 100%). This actually works great for my switches - I can send them ON from OpenHAB, and in the log I’ll see “received command ON; predicted to become ON; changed to 100; changed to 27”. I.e. it forwarded the ON message as-is, then checked the state of the switch and said “hey, it actually went to 27%! woohoo!” (the “changed to 100” never actually happened. That was just the OpenHAB assuming an ON will set it to 100% and updating the internal state of the item before the binding could update the state to match reality). Unfortunately, this totally conflicts with HomeKit’s view. HomeKit thinks I need to turn the switch ON and to a specific percent. For most of my switches, this isn’t a problem - when they receive an ON and they’re already ON, they just ignore it. Then they receive the specific % to go to, and start dimming in that direction. No strobing.
It sounds like your switches interpret an ON as “go to 100%”, so when sliding the dimmer around in HomeKit, they strobe switching between 100% and the actual target very quickly. Normally I’d say “well, get smarter switches that can remember their state.” That’s probably not practical. Next I would say "well, OpenHAB supports persistence, it’d be awesome if there was an option to interpret “ON” as “return to last state” automatically, within the framework. That would get your switches to behave like mine.
BUT… even if OpenHAB core were to do that, that would still leave a problem that annoys me: when the switch is off, and I turn it on in HomeKit, it always goes to 100% (ON and 100% are both sent). No way to solve that except for within the HomeKit add-on itself. So… while I’m solving that, I’ll solve your problem for you generically too, because they’re the same fundamentally. My intention is that if in a single request, an ON and a percent target are received, check the current state of the item. If it’s OFF, drop the percent target, and only pass through the ON command – allowing my switches to do their thing and return to their prior state. If it’s already ON (anything non-zero), drop the ON, and only pass through the percent – allowing your switches to not strobe (and actually improving the amount of traffic on my zwave network, because the superfluous message will now be dropped in OpenHAB, instead of by my end device).
I can’t promise when I’ll have this done, but hopefully within the next week or two. I actually have a proxy item controlling a non-zwave device experiencing some amount of strobing like you have, so I want it for that scenario too (funny story, the item is actually a zwave item, but it’s not directly connected to a load; instead it just uses rules to pass on whatever HomeKit or physical acting on the switch does to another service that actually controls the load). I just have lots of items on my openhab todo list (and real life todo list!), that I may have to do first.
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?
1 Like
Very interesting!
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.
1 Like
No plans right now, but you’re welcome to open a PR for it: https://github.com/hap-java/openhab2-addons/tree/homekit/addons/io/org.openhab.io.homekit
Specifically, see my comment 
about the fact that respective openhab bindings should deal with this.
do I have to remove the current-installed version of the Homekit plugin for using the v2.4.0.homekit6?
or can it updated inplace?
You’ll need to remove it, first