Openhab-addons: [homekit] Lightning Dimmer sends 2 commands
Hello,
i check the headlines for the "homekit" issues, but nothing matches my problem.
"Wrong behaviuor" homekit Dimmer with iOS 11 iPhone 7 and knx
ITEM Config: Dimmer Weiss "Weiss Dimmer [%s]" (Lights) [ "Lighting" ] { knx="1/4/1, 1/4/2, 1/4/3+<1/4/4" }
In Homekit the icon has 2 functions:
- tap (ON or OFF)
- long tap for slider (Percent)
first tap: ON
Openhab2 log
2017-10-14 03:45:21.227 [ItemCommandEvent ] - Item 'Weiss' received command ON
2017-10-14 03:45:21.242 [ItemCommandEvent ] - Item 'Weiss' received command 100
2017-10-14 03:45:21.454 [ItemStateChangedEvent ] - Weiss changed from 0 to 50
KNX Groupmonitor
Zeit Dienst Flags Prio Quell-Adresse Quell-Name Ziel-Adresse Ziel-Name Rout Typ DPT Info
46 14.10.2017聽03:44:56,022 vom Bus Niedrig 0.0.4 - 1/4/1 Gruppe1 weiss an 5 GroupValueWrite 1.001 Schalten $01 | Ein
47 14.10.2017聽03:44:56,049 vom Bus Niedrig 0.0.4 - 1/4/3 Gruppe1 weiss wert 5 GroupValueWrite 5.001 Prozent (0..100%) $FF | 100 %
48 14.10.2017聽03:44:56,229 vom Bus Niedrig 1.1.1 KNX DALI-Gateway REG-K/1/16(64)/64 1/4/4 Gruppe1 weiss status 5 GroupValueWrite 5.001 Prozent (0..100%) $80 | 50 %
Result
Lights on with 50% (Config in KNX Dali modul for GA 1/4/1 ON)
homekit icon change to ON (white, bulb yellow), the percent display short 100%, next millisecond 50%
==> homekit sends wrong command 100%
second tap: OFF
Openhab2 log
2017-10-14 03:51:24.423 [ItemCommandEvent ] - Item 'Weiss' received command OFF
2017-10-14 03:51:24.681 [ItemStateChangedEvent ] - Weiss changed from 50 to 0
KNX Groupmonitor
Zeit Dienst Flags Prio Quell-Adresse Quell-Name Ziel-Adresse Ziel-Name Rout Typ DPT Info
1 14.10.2017聽03:50:59,216 vom Bus Niedrig 0.0.4 - 1/4/1 Gruppe1 weiss an 5 GroupValueWrite 1.001 Schalten $00 | Aus
2 14.10.2017聽03:50:59,451 vom Bus Niedrig 1.1.1 KNX DALI-Gateway REG-K/1/16(64)/64 1/4/4 Gruppe1 weiss status 5 GroupValueWrite 5.001 Prozent (0..100%) $00 | 0 %
Result
Lights off
homekit icon change to Off (grey)
==> Okay
long tap: slider (from OFF to 15%)
Openhab2 log
2017-10-14 03:53:59.102 [ItemCommandEvent ] - Item 'Weiss' received command ON
2017-10-14 03:53:59.109 [ItemCommandEvent ] - Item 'Weiss' received command 13
2017-10-14 03:53:59.231 [ItemStateChangedEvent ] - Weiss changed from 0 to 50
2017-10-14 03:53:59.360 [ItemCommandEvent ] - Item 'Weiss' received command ON
2017-10-14 03:53:59.370 [ItemCommandEvent ] - Item 'Weiss' received command 14
2017-10-14 03:53:59.717 [ItemCommandEvent ] - Item 'Weiss' received command ON
2017-10-14 03:53:59.724 [ItemCommandEvent ] - Item 'Weiss' received command 15
KNX Groupmonitor
Zeit Dienst Flags Prio Quell-Adresse Quell-Name Ziel-Adresse Ziel-Name Rout Typ DPT Info
3 14.10.2017聽03:53:33,891 vom Bus Niedrig 0.0.4 - 1/4/1 Gruppe1 weiss an 5 GroupValueWrite 1.001 Schalten $01 | Ein
4 14.10.2017聽03:53:33,918 vom Bus Niedrig 0.0.4 - 1/4/3 Gruppe1 weiss wert 5 GroupValueWrite 5.001 Prozent (0..100%) $21 | 13 %
5 14.10.2017聽03:53:34,004 vom Bus Niedrig 1.1.1 KNX DALI-Gateway REG-K/1/16(64)/64 1/4/4 Gruppe1 weiss status 5 GroupValueWrite 5.001 Prozent (0..100%) $80 | 50 %
6 14.10.2017聽03:53:34,144 vom Bus Niedrig 0.0.4 - 1/4/1 Gruppe1 weiss an 5 GroupValueWrite 1.001 Schalten $01 | Ein
7 14.10.2017聽03:53:34,172 vom Bus Niedrig 0.0.4 - 1/4/3 Gruppe1 weiss wert 5 GroupValueWrite 5.001 Prozent (0..100%) $24 | 14 %
8 14.10.2017聽03:53:34,506 vom Bus Niedrig 0.0.4 - 1/4/1 Gruppe1 weiss an 5 GroupValueWrite 1.001 Schalten $01 | Ein
9 14.10.2017聽03:53:34,534 vom Bus Niedrig 0.0.4 - 1/4/3 Gruppe1 weiss wert 5 GroupValueWrite 5.001 Prozent (0..100%) $26 | 15 %
Result
Lights on with 50% (Config in KNX Dali modul for GA 1/4/1 ON)
homekit slider shows 15% (wrong value)
BasicUI shows 50% (right value)
==> homekit sends the wrong command ON
long tap: slider (from 15% to 72%)
Openhab2 log
2017-10-14 03:58:10.020 [ItemCommandEvent ] - Item 'Weiss' received command ON
2017-10-14 03:58:10.029 [ItemCommandEvent ] - Item 'Weiss' received command 58
2017-10-14 03:58:10.273 [ItemCommandEvent ] - Item 'Weiss' received command ON
2017-10-14 03:58:10.280 [ItemCommandEvent ] - Item 'Weiss' received command 72
KNX Groupmonitor
Zeit Dienst Flags Prio Quell-Adresse Quell-Name Ziel-Adresse Ziel-Name Rout Typ DPT Info
10 14.10.2017聽03:57:44,805 vom Bus Niedrig 0.0.4 - 1/4/1 Gruppe1 weiss an 5 GroupValueWrite 1.001 Schalten $01 | Ein
11 14.10.2017聽03:57:44,832 vom Bus Niedrig 0.0.4 - 1/4/3 Gruppe1 weiss wert 5 GroupValueWrite 5.001 Prozent (0..100%) $94 | 58 %
12 14.10.2017聽03:57:45,055 vom Bus Niedrig 0.0.4 - 1/4/1 Gruppe1 weiss an 5 GroupValueWrite 1.001 Schalten $01 | Ein
13 14.10.2017聽03:57:45,082 vom Bus Niedrig 0.0.4 - 1/4/3 Gruppe1 weiss wert 5 GroupValueWrite 5.001 Prozent (0..100%) $B8 | 72 %
Result
Lights on with 50% (Config in KNX Dali modul for GA 1/4/1 ON)
homekit slider shows 15% (wrong value)
BasicUI shows 50% (right value / no change, because no ItemStateChangedEvent was send)
==> homekit sends the wrong command ON## long tap: slider (from 72% to OFF)
Openhab2 log
2017-10-14 04:02:26.882 [ItemCommandEvent ] - Item 'Weiss' received command OFF
2017-10-14 04:02:26.891 [ItemCommandEvent ] - Item 'Weiss' received command 0
2017-10-14 04:02:27.034 [ItemStateChangedEvent ] - Weiss changed from 50 to 0
KNX Groupmonitor
Zeit Dienst Flags Prio Quell-Adresse Quell-Name Ziel-Adresse Ziel-Name Rout Typ DPT Info
14 14.10.2017聽04:02:01,658 vom Bus Niedrig 0.0.4 - 1/4/1 Gruppe1 weiss an 5 GroupValueWrite 1.001 Schalten $00 | Aus
15 14.10.2017聽04:02:01,685 vom Bus Niedrig 0.0.4 - 1/4/3 Gruppe1 weiss wert 5 GroupValueWrite 5.001 Prozent (0..100%) $00 | 0 %
16 14.10.2017聽04:02:01,788 vom Bus Niedrig 1.1.1 KNX DALI-Gateway REG-K/1/16(64)/64 1/4/4 Gruppe1 weiss status 5 GroupValueWrite 5.001 Prozent (0..100%) $00 | 0 %
Result
Lights off
homekit slider shows OFF
==> homekit sends the wrong command OFF
Feature Request
Send only one command for a Lighting / Dimmer item:
on short tap: ON or OFF
long tap (slider): Percent
System
Openhabian 2.1.0 / KNX1 Binding 1.1.0 / Homekit MISC 2.1.0 (2 entrys, because feature.xml contains 2 entrys)
feature:list
openhab-binding-knx1 | 1.10.0 | Started | addons-2.1.0 | KNX Binding
openhab-misc-homekit | 2.1.0 | x | Started | addons-2.1.0 | HomeKit Integration
openhab-misc-homekit | 2.1.0 | x | Started | addons-2.1.0 | HomeKit Integration
I hope, my explanation is okay.
Please tell me, if this is the wrong place for this request.
THX
Florian
floriandd2ba
All 26 comments
Excellent description of the problem. I experience the same problem with my openHAB connected Z-wave dimmer when i control it via HomeKit from an iOS 11 device.
Turning the dimmer ON using the ON/OFF toggle in HomeKit sends the "ON" command _and_ a "100" command. In my case that results in a 100% brightness level regardless of the dimmer state when turned off. This is not ideal.
Changing the dimmer brightness with the slider sends multiple commands, but always in pairs of "ON" _and_ a percentage level. This seems unnecessary, but in my case doesn't pose a problem.
I second Florians request that a simple toggle ON/OFF should send a single command, either "ON" or "OFF". A slider change should send a single percentage command.
/ Mattias
mattiasmalm
on 14 Nov 2017
Exact the same problem I have! I use the dimmer object to control the volume of my Sonos and it's very annoying, because the volume will raise up to 100% if i use the slider!
dkuschmierz
on 18 Nov 2017
I experienced the same issue. To be a bit more precise, I see this only with increasing commands, whereas decreasing is working fine, i.e. from 0% to 50%, a second command might bring the light to 100%. Coming from 100% to 50%, this is not happening.
Some of my dimmer send an "on" and afterwards the dimmer value - others do it the other way around (first dimmer value then "on").
While I use homekit only for sending voice commands, my workaround is to setup two items to control one dimmer:
Dimmer
Switch
instead of one item like
Dimmer
2/0/0 -> on/off (1 bit)
2/0/1 -> dimmer command (4 bit)
2/0/2 -> set value (8 bit)
2/0/5 -> return value for on/off (1 bit)
2/0/6 -> return value for dimming lights (8 bit)
Maybe, you have better ideas for this.
Martin
dfrg2010
on 16 Feb 2018
This is a known problem of KNX1 binding. We all hope soon to use the new KNX2 binding:
https://github.com/openhab/openhab2-addons/pull/2323#pullrequestreview-97178285
lewie
on 17 Feb 2018
This problem is not only with KNX Binding, same happens with Simatic S7 bindings.
grzegorz914
on 17 Feb 2018
This seems to happen with my Z-Wave Dimmers:
02:56:09.420 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'MasterBedroomLight_Dimmer' received command ON
02:56:09.434 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'MasterBedroomLight_Dimmer' received command 39
02:56:09.491 [INFO ] [smarthome.event.ItemStateChangedEvent] - MasterBedroomLight_Dimmer changed from 38 to 100
02:56:09.500 [INFO ] [smarthome.event.ItemStateChangedEvent] - MasterBedroomLight_Dimmer changed from 100 to 39
It seems openhab always sends a 100% and ON command?
spacesuitdiver
on 20 Mar 2018
Any developments on this? Same happening for me with the WiFiLed Binding, colors and brightness are all over the place when sent from the Home app.
Dobbler
on 10 Apr 2018
FWIW, you can work around the level issue with a dummy item for HomeKit and some rules.
At least the level doesn't jump around like crazy while being adjusted through HomeKit...
your.items example:
Dimmer KitchenCeilingLight "Deckenlampe" <light> (gKitchen, gLights) { channel="zigbee:device:XYZ_1_switch_level" }
Dimmer KitchenCeilingLightHomeKit "Deckenlampe" <light> (gKitchen) [ "Lighting" ]
your.rules example:
// Kitchen Ceiling Light
rule "KitchenCeilingLightHomeKit"
when
Item KitchenCeilingLightHomeKit received command
then
if (receivedCommand != ON && receivedCommand != OFF) {
KitchenCeilingLight.sendCommand(receivedCommand)
} else if (receivedCommand == OFF) {
KitchenCeilingLight.sendCommand(0)
}
end
rule "KitchenCeilingLight"
when
Item KitchenCeilingLight received update
then
val level = KitchenCeilingLight.state as Number
KitchenCeilingLightHomeKit.postUpdate(level)
end
weakfl
on 10 Apr 2018
I don't think this is technically an issue with the HomeKit binding, but is more of a difference in how On/Off state vs brightness levels are handled in HomeKit vs OpenHAB.
The HomeKit spec requires that accessories that provide the Lightbulb service have an On characteristic, with additional optional characteristics of Brightness, Hue, etc. The On characteristic is always binary, as you would expect, and is independent of the Brightness characteristic.
The key difference that I see is that bindings (Insteon in my case, KNX in others, etc) - or maybe this is in OpenHAB core, I admittedly haven't looked too deeply yet - treat ON/OFF on Dimmers as the two ends of the brightness scale, and not as an independent attribute that can be controlled separately.
Whatever the root cause, I too came up with a workaround as I was also having this same problem with dimmers being sent both the ON and the numerical value resulting in some erratic behaviour. I ended up solving it in a slightly more complicated way, as shown below, because there are in fact cases where HomeKit will send only the ON command to a dimmable light...
One of these cases is when using Siri to turn on lights that are on a dimmer. When this happens, HomeKit simply sends a single ON command and completely omits sending the brightness 100. This results in a bit of an awkward conversation when using a basic proxy to catch and completely ignore the ON command:
Me: "Hey Siri, turn on the kitchen lights"
...
[INFO][smarthome.event.ItemCommandEvent] Item 'HK_KitchenPotLights' received command ON
[INFO][arthome.model.script.hk_kitchen_proxy] Ignoring ON command so brightness takes priority...
Siri: "Ok, the lights are on."
...
The lights are most definitely not on
In order to handle this use case, I beefed up my proxy rules and extracted all the logic out into a function to make setting up multiple lights easier. I assume something similar can be done for the hue/saturation of coloured lights, but I don't have any in my house to play with.
Here is my current implementation, which has been solid so far:
First we need some Items (eg lighting.items):
/**
* Items to hold some global state
*/
Group HK_Dimmers
Number HK_DimmerProxySleepDelay
Switch HK_DimmerProxyReady
/**
* Pairs of dimmers - one with the actual binding config, the other as a proxy for HomeKit
*/
Dimmer KitchenPotLights "Kitchen Island Pot Lights" { **BINDING CONFIG** }
Dimmer HK_KitchenPotLights "Kitchen Island Pot Lights" (HK_Dimmers) [ "Lighting" ]
And then the Rules (eg lighting.rules):
import org.eclipse.xtext.xbase.lib.Functions
import java.util.concurrent.locks.ReentrantLock
import java.util.List
import java.util.ArrayList
import java.util.Collections
import java.util.Map
import java.util.HashMap
/**
* Collections for managing shared state for each dimmer
*/
var Map<String, ReentrantLock> hkDimmerLocks = new HashMap<String, ReentrantLock>()
var Map<String, List<Integer>> hkDimmerCommandQueues = new HashMap<String, List<Integer>>()
/**
* sleepDelay: Time (in ms) to wait before determining what to send to the actual dimmer.
*/
val sleepDelay = 200
/**
* homekitDimmerCommandHandler: Function to manage incoming HomeKit commands to dimmers
*
* Removes flapping caused by HomeKit sending both an ON command and a Number brightness level at the same time
* when triggered from within the Home app
*/
val Functions$Function5 <DimmerItem, DimmerItem, Command, Map<String, ReentrantLock>, Map<String, List<Integer>>, Boolean>
homekitDimmerCommandHandler = [ homekitDimmerProxy, realDimmer, receivedCommand, locks, commandQueues |
if (HK_DimmerProxyReady.state != ON) {
logDebug('homekitDimmerCommandHandler', "HomeKit proxies not ready yet, aborting.")
return false
}
val groupName = HK_Dimmers.getName()
if (!homekitDimmerProxy.getGroupNames.contains(groupName)) {
logError('homekitDimmerCommandHandler', "Dimmer {} not a member of {}", homekitDimmerProxy, groupName)
return false
}
val hkItemName = homekitDimmerProxy.getName()
var hkLock = locks.get(hkItemName)
var hkCommandQueue = commandQueues.get(hkItemName)
var Number level = 0
if (receivedCommand instanceof OnOffType) {
if (receivedCommand == ON) level = 100
} else {
level = (receivedCommand as Number)
}
logDebug(hkItemName, "Got command: {}, using level: {}", receivedCommand , level)
hkCommandQueue.add(level.intValue())
logDebug(hkItemName, "Attempting to acquire lock")
val isLocked = hkLock.tryLock();
if(isLocked) {
logDebug(hkItemName, "Lock acquired")
try {
val sleepDelay = HK_DimmerProxySleepDelay.state as Number
logDebug(hkItemName, "Sleeping for {} ms to allow other commands to queue up", sleepDelay)
Thread.sleep(sleepDelay.intValue())
logDebug(hkItemName, "Getting minimum of received commands: {}", hkCommandQueue)
val setLevel = Collections.min(hkCommandQueue)
logDebug(hkItemName, "Setting lights to: {}", setLevel)
realDimmer.sendCommand(setLevel)
logDebug(hkItemName, "Clearing queue")
hkCommandQueue.clear()
} finally {
logDebug(hkItemName, "Releasing lock")
hkLock.unlock()
}
} else {
logDebug(hkItemName, "Failed to acquire lock")
}
true
]
/*
* Initialize all the global state that is required to manage the dimmers
*/
rule "Prime locks, command queues, and constants"
when
System started
then
HK_DimmerProxyReady.postUpdate(OFF)
HK_DimmerProxySleepDelay.postUpdate(sleepDelay)
HK_Dimmers.members.forEach[ GenericItem dimmer |
if (dimmer instanceof DimmerItem) {
val key = dimmer.getName()
logDebug("HK_LightingRulesInit", "Setting up lock and command queue for {}", key)
hkDimmerLocks.putIfAbsent(key, new ReentrantLock())
hkDimmerCommandQueues.putIfAbsent(key, new ArrayList<Integer>())
} else {
logError("HK_LightingRulesInit", "Got unexpected item: {}", dimmer)
}
]
HK_DimmerProxyReady.postUpdate(ON)
logInfo("HK_LightingRulesInit", "HomeKit Proxy locks and command queues primed. {} dimmers ready.", HK_Dimmers.members.size())
end
/*
* Dimmer configs
*/
rule "Update KitchenPotlights from HomeKit"
when
Item HK_KitchenPotLights received command
then
homekitDimmerCommandHandler.apply(HK_KitchenPotLights, KitchenPotLights, receivedCommand, hkDimmerLocks, hkDimmerCommandQueues)
end
rule "Sync KitchenPotlights to HomeKit"
when
Item KitchenPotLights received update
then
val level = KitchenPotLights.state as Number
HK_KitchenPotLights.postUpdate(level)
end
// Repeat previous two rules for all dimmers...
Hopefully this helps someone :)
j-mutter
on 17 Apr 2018
@j-mutter - this script (drop "on" command) seems like a great solution to this issue. I'm very new to openHAB (just started today), could you point me in the right direction so I can add this to my system? I currently have 4 dimmers (insteon PLM) and homekit setup in my openHAB.
What's the easiest way to add this code so my homekit dimmers will work better?
crxporter
on 17 May 2018
@j-mutter Alright I'm a few days into openhab now and getting more comfortable with it. I've implemented this rule but I'm getting an error when the .rules file is loaded:
2018-05-22 16:36:08.644 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'light.rules', using it anyway:
The field Tmp_lightRules.homekitDimmerCommandHandler refers to the missing type Object
Any ideas how to fix that one? This setup does work very well - much better than the default homekit "flashing dimmers" situation.
Thanks!
crxporter
on 22 May 2018
Odd... Object is the base class in the entire Java hierarchy, so I have no idea how that could be missing.
But no, I have no idea as to what could cause this. It's also an INFO log, not a WARN or ERROR, and if the script is working, then I wouldn't be too worried about it... It is strange though.
j-mutter
on 24 May 2018
Thanks for the response. I鈥檝e been doing some more digging and have seen your OpenHAB fork with the updated HomeKit add on - does that fix this issue system wide without the rule and double set of dimmers?
If so, any chance you have a minute to explain how to get that version installed on a pi 3?
crxporter
on 25 May 2018
No it doesn't - I've just added support for my alarm and garage door opener, but those, along with the lights, still rely on some rules to glue them together.
j-mutter
on 30 May 2018
I also have this anoying problem. When i tell siri to switch the light on to 5% ist first switches on to 100% and when i say the same comand a second time (when the light is on) it switches to 5% like it should before. Would like to have a solution without a big rule :)
Julian0o
on 15 Oct 2018
I have this issue too. HomeKit + Insteon + Dimming = _disco dance party_. It's the only thing keeping OpenHAB from being perfect for me.
dfraser
on 15 Oct 2018
I鈥檝e kept all of my Insteon (along with mqtt and some other things) in openhab but moved all of my homekit connections to node red.
It鈥檚 fantastic. No more double commands. HomeKit has been working great for months.
Send me some messages if you鈥檇 like examples.
crxporter
on 15 Oct 2018
In anticipation of someone asking how I've fixed this (and since I had some free time) - here is an example of an openhab dimmer (chandelier) and how I'm linking it to HomeKit in Node Red:
Here we have the OpenHAB item Chandelier on the far left going to dimmer in function, then HomeKit, then dimmer out function, finally back to Chandelier in OpenHAB. The OpenHAB and HomeKit items are pretty much "standard" - just choose the right item in the node settings. On the right I'm using "send command" for going back to OpenHAB.
The important part is in the functions and making sure you always send number commands (not "on/off") to your items in OpenHAB. I'm using this with insteon and so long as my rules are written to send updates/commands then everything works great (including polling).
My dimmer in function:
var input = msg.payload;
if (input < 101){
if (input < 1) {
msg.payload = {
"On": false
}
}
else {
msg.payload = {
"Brightness": input,
"On": true
}
}
return msg;
}
Dimmer out function:
var b = context.get('b')||0;
if(msg.payload.Brightness){
b = msg.payload.Brightness;
context.set('b',b);
msg.payload=b
}
if (msg.hap.context !== undefined) {
if(msg.payload.Brightness === 0){
msg.payload = 0
}
if(msg.payload.On === false){
msg.payload = 0
}
if(msg.payload.On === true){
msg.payload = b
}
return msg
}
I tried for hours to "break" this (have openhab or homekit show wrong values) but everything kept working. After reboot the homekit system will show everything "off" until polling happens to all of the insteon updates to change from "NULL" to current value.
I've gone on to set up all of my switches, smoke detectors, curtain, and sprinklers with similar functions. OpenHAB with HomeKit set up like this is just great. Everything running on a Pi 3B+ and stable for weeks/months at a time between restarts (power outages or new features added).
crxporter
on 15 Oct 2018
I have same problem with the IHC Binding :
21:30:41.059 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'IHCELKOController_StueAlrumOverSpisebordLampeudtagDimmerLysNiveau' received command 80
21:30:41.084 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'IHCELKOController_StueAlrumOverSpisebordLampeudtagDimmerLysNiveau' received command ON
21:30:41.096 [INFO ] [arthome.event.ItemStatePredictedEvent] - IHCELKOController_StueAlrumOverSpisebordLampeudtagDimmerLysNiveau predicted to become 80
21:30:41.115 [INFO ] [smarthome.event.ItemStateChangedEvent] - IHCELKOController_StueAlrumOverSpisebordLampeudtagDimmerLysNiveau changed from 1 to 80
21:30:41.121 [INFO ] [arthome.event.ItemStatePredictedEvent] - IHCELKOController_StueAlrumOverSpisebordLampeudtagDimmerLysNiveau predicted to become ON
21:30:41.141 [INFO ] [smarthome.event.ItemStateChangedEvent] - IHCELKOController_StueAlrumOverSpisebordLampeudtagDimmerLysNiveau changed from 80 to 100
21:30:41.372 [INFO ] [smarthome.event.ItemStateChangedEvent] - IHCELKOController_StueAlrumOverSpisebordLampeudtagDimmerLysNiveau changed from 100 to 80
21:30:41.596 [INFO ] [smarthome.event.ItemStateChangedEvent] - IHCELKOController_StueAlrumOverSpisebordLampeudtagDimmerLysNiveau changed from 80 to 1
Have anyone found a fix other then the node red one?
gfk76
on 17 Jan 2019
Please check if this is still a problem with the latest code (2.5 Snapshot >1602)
J-N-K
on 7 Jun 2019
Hi! This is still an issue with the latest MILESTONE build
bbsan2k
on 29 Sep 2019
Would a custom Profile be a solution for this issue? It seems possible to cancel sending ON, if current state is on. Or just ignore sending ON/OFF entirely.
2xPower
on 13 May 2020
(for KNX binding only)
To answer my own question: yes.
I added a custom profile for color and dimmer items that use a knx dimmer channel to the KNX binding. This custom profile will cancel some commands:
1. ON command to the item if the item is already ON.
This prevents the KNX binding to send an ON command if the Item is supposed to be ON. In other words, the dimmer will not jump to 100% because of slider manipulation in the Home app.
2. 100% command, within 200 milliseconds of the last issued ON command.
When turning a dimmable lightbulb to ON in the Home app, a 100% command is always issued to the Item (by the Home app), right after the ON command.
To allow the dimmer to restore a previous value the 100% command is cancelled, if it is issued to the Item within 200 milliseconds of an ON command.
In other words, if the lighting was at 43% the before it was turned off, the light will be turned on to 43%.
If there is any interest in this solution i would be happy to create a pull request so my code can be added to the distrubution.
2xPower
on 13 May 2020
I have this issue too. HomeKit + Insteon + Dimming = _disco dance party_. It's the only thing keeping OpenHAB from being perfect for me.
I have a problem with color items, but otherwise I would fully agree. Can someone finally fix this? I think many are waiting for this to finally be possible. I could get rid of some bridges if the dimmers and color items would work.
FabianZellmer
on 27 May 2020
@FabianZellmer @2xPower
please test once this PR https://github.com/openhab/openhab-addons/pull/7825 get merged.
current logic:
- ON and Brightness commands within 50ms - only ON is sent
yfre
on 1 Jun 2020
@yfre - looks like a clean solution. Looking forward to test - will report back.
Thank you!
2xPower
on 1 Jun 2020
Related issues
mjcumming
路
5Comments
UrsusS
路
5Comments
LukasA83
路
5Comments
doandzhi
路
6Comments
tobiwan88
路
4Comments
Most helpful comment
FWIW, you can work around the level issue with a dummy item for HomeKit and some rules.
At least the level doesn't jump around like crazy while being adjusted through HomeKit...
your.items example:
your.rules example: