HomeKit Integration additional ON/OFF command

[insidecircuits]

I have been using this binding successfully for the past year also in combination with Amazon Echo and Alexa skill.
I am using these to control Sonoff devices with custom Tasmota firmware, all is good for basic switches but I ran into some problems with dimmers.

At the begining I saw some errors coming to the dimmer items that were associated with this binding and later I found out by troubleshooting that the HomeKit binding sends additional ON command to the dimmer apart from percentage number.

So for example when I set the level of the dimmer to 40% it will send ON then 40. This messes up things because openhab interprets ON as 100%, sets the device to 100% and back to 40. How can I manage this?
Ideally it would be if I could disable this first ON command coming to the item in the first place.

[luckymallari (Lucky)]

This is a good candidate for a proxy item.

Design Pattern: Proxy Item

Please see Design Pattern: What is a Design Pattern and How Do I Use Them for information on what a DP is and how to use them. Problem Statement Often one faces one or more of the following situations: the need to perform additional logic before sending a command to a device the need to send a command to multiple devices based on a single event the need to do something different based on the state of one or more other Items the channel to update the state of an Item and the channel to send c…

[crxporter (Garrett Porter)]

This is a known problem with how homekit works compared to how the openhab plugin is programmed. Your idea of disabling the on and only sending level doesn’t actually work because sometimes homekit ONLY sends “on”. It’s quite frustrating to deal with actually. The proxy items shown below do work - but involve 50 or 100 ms timers to “catch” the double commands. My solution with node red is to save the previously used level in case homekit only sends “on”

There is another recent thread from yesterday I think about a new homebridge-openhab that could also address this but I’m not sure that developer has gotten that far yet. Search the forum for “homekit holy grail” and it will come up.

Most recent discussion here:

Announcing some improvements to the Homekit plugin for openHAB 2

The whole reason why this happens is Apple’s approach to Accessory, where a Lightbulb accessory needs to have an ‘On’ Characteristic and optional a ‘Brightness’, ‘Hue’ and ‘Saturation’ characteristic, depending if the lightbulb also allows dimming and/or colors. When turning the light to a specific percentage value or even HSB color value, every characteristic is fired. First the ‘On’ characteristic changes to true, then the ‘Brightness’ characteristic changes to your specified value and so on. …

Also here for a possible solution with proxy items, works pretty well - about 3/4 of the way down:
https://github.com/openhab/openhab2-addons/issues/2782

Also here for how I’ve solved it in my house by using nodered instead of the built in homekit:

My node-red + HomeKit + OpenHAB setup

I know others have connected their devices and everyone has their own twist on how to do this. My preferred method is to use function nodes wherever possible. This keeps things from getting too messy with all of the switch and change nodes that come up in similar setups. It came up today when I started showing @rkrisi how to use MQTT+Node-Red to send command line codes to other computers. So here goes. A couple of prerequisites: -Install node-red (obviously) -Add the flow “node-red-contrib-h…

[steilerDev (Frank Steiler)]

Yes, this is a behavior that is in accordance with the HomeKit Accessory Protocol (my description was linked above by @crxporter). The post @crxporter is referring to is this one.

Being the dev of the Homebridge plugin I can confirm, that I fixed this issue very early on (not having a proxy item for every light in my home was one of the main reasons I developed this plugin). I am currently using a 250ms delay, however this surely can be reduced a bit, just didn’t came around yet to test the minimum value required.

Either implement a proxy item and stick to your current setup or give my implementation a spin (additionally the dev of the official openHAB HomeKit plugin is currently working on the plugin, therefore it might be possible that he is also implementing some fix for this behavior).