I haven’t set up Alexa support myself. (but plan to). Maybe an ignore tag would be in order.
As an aside, there’s been some discussion and some work about the future of configuring Openhab2 Homekit items is through item metadata.
Yes an ignore tag would be nice.
I also saw that maybe the Alexa skill will also change the way of how the items are recognized.
Is there a discussion about the item metadata tagging?
Andy Lintner had started some work on it, too: https://github.com/beowulfe/openhab2/commit/8ede0bcf1a405b8a41b42f60a2da9de7939c7a57
Hi Tim,
integration of ContactSensors works now.
My item: Contact Sensor_Fenster "Bad Fenster" <window> (OG_Bad) [ "ContactSensor" ] {channel='innogysmarthome:WDS:...........:contact'}
Smoke Sensor is also shown in HomeKit, but without the battery Level. Here my Group:
roup Flur_Melder "Flur Rauchmelder" (OG_Flur) ["SmokeSensor"]
Contact Rauch "Flur Rauchmelder" <smoke> (Flur_Melder) ["SmokeSensor"] {channel='innogysmarthome:WSD:................:smoke'}
Switch Flur_Batterie "Flur Rauchmelder Batterie" <battery> (Flur_Melder) ["homekit:BatteryLowStatus"] {channel='innogysmarthome:WSD:..........:battery_low'}
Any Idea?
It’s only going to report when your battery is less than 10%. If you want to test it out, maybe you can Find someway to manually set the battery level (find it to a site map?). You will need to close the Home app, and reopen it, for it to clear the battery status.
Has there been any work on alarms? Ie the ability to set a device as armed/disarmed etc and expose it to homekit?
@psyciknz: no, not yet, but I’ll probably pick that up soon. I first want to get some metadata stuff working so that I can define the proper number of steps for fan speeds, and for allowing you to limit the thermostat range per-thermostat (I have multiple thermostats in my home of different brands, so they have different ranges).
Not to my knowledge
Maybe this does not belong here, but I received no response elsewhere: Can I change the Homekit:HeatingCoolingMode from a voice control like Alexa or Google Home? What would be the (preferably German) command?
@psyciknz: ask and ye shall receive: https://github.com/ccutrer/openhab2-addons/releases/tag/2.5.0-cody2
sorry no support for changing config to specify different enum values for your security system state. use rules if what you have doesn’t match (mine doesn’t, but I had to use rules to do lots of transformations, not just mismatched strings).
Awesome. That was the main reason I pushed most of my homekit items to home assistant.
Thankfully the thing that posts the value from my paradox I wrote so I can set the value to whatever I want.
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.