There seems to be frequent off-by-1 errors in setting the dimmer value in Trädfri dimmers and Trädfri light remotes. I can confirm it in the Event log, as the values are often off by 1. This also results in the chosen switch value not being highlighted as it doesn’t match the value selected (e.g. click “1”, get “2”).
The Event log (/var/log/openhab2/events.log) reports the following state changes:
2019-02-12 21:11:48.196 [ome.event.ItemCommandEvent] - Item 'GF_Kitchen_Light_Dimmer' received command 1
2019-02-12 21:11:48.203 [nt.ItemStatePredictedEvent] - GF_Kitchen_Light_Dimmer predicted to become 1
2019-02-12 21:11:48.208 [vent.ItemStateChangedEvent] - GF_Kitchen_Light_Dimmer changed from 0 to 1
2019-02-12 21:11:48.209 [vent.ItemStateChangedEvent] - GF_Kitchen_Light_Dimmer changed from 1 to 0
2019-02-12 21:11:48.223 [vent.ItemStateChangedEvent] - GF_Kitchen_Light_Toggle changed from OFF to ON
2019-02-12 21:11:48.224 [vent.ItemStateChangedEvent] - tradfri_0100_GATEWAY_ID_65560_brightness changed from 0 to 2
2019-02-12 21:11:48.225 [vent.ItemStateChangedEvent] - GF_Kitchen_Light_Dimmer changed from 0 to 2
2019-02-12 21:11:48.271 [vent.ItemStateChangedEvent] - GF_Kitchen_Light_Toggle changed from ON to OFF
2019-02-12 21:11:48.272 [vent.ItemStateChangedEvent] - tradfri_0100_GATEWAY_ID_65560_brightness changed from 2 to 0
2019-02-12 21:11:48.274 [vent.ItemStateChangedEvent] - GF_Kitchen_Light_Dimmer changed from 2 to 0
2019-02-12 21:11:48.321 [vent.ItemStateChangedEvent] - GF_Kitchen_Light_Toggle changed from OFF to ON
2019-02-12 21:11:48.322 [vent.ItemStateChangedEvent] - tradfri_0100_GATEWAY_ID_65560_brightness changed from 0 to 1
2019-02-12 21:11:48.323 [vent.ItemStateChangedEvent] - GF_Kitchen_Light_Dimmer changed from 0 to 1
2019-02-12 21:11:50.139 [vent.ItemStateChangedEvent] - tradfri_0100_GATEWAY_ID_65560_brightness changed from 1 to 2
2019-02-12 21:11:50.140 [vent.ItemStateChangedEvent] - GF_Kitchen_Light_Dimmer changed from 1 to 2
2019-02-12 21:11:54.475 [ome.event.ItemCommandEvent] - Item 'GF_Kitchen_Light_Dimmer' received command 90
2019-02-12 21:11:54.480 [nt.ItemStatePredictedEvent] - GF_Kitchen_Light_Dimmer predicted to become 90
2019-02-12 21:11:54.482 [vent.ItemStateChangedEvent] - GF_Kitchen_Light_Dimmer changed from 2 to 90
2019-02-12 21:11:54.484 [vent.ItemStateChangedEvent] - tradfri_0100_GATEWAY_ID_65560_brightness changed from 2 to 91
2019-02-12 21:11:54.484 [vent.ItemStateChangedEvent] - GF_Kitchen_Light_Dimmer changed from 90 to 91
2019-02-12 21:11:56.985 [ome.event.ItemCommandEvent] - Item 'GF_Kitchen_Light_Dimmer' received command 100
2019-02-12 21:11:56.990 [nt.ItemStatePredictedEvent] - GF_Kitchen_Light_Dimmer predicted to become 100
2019-02-12 21:11:56.991 [vent.ItemStateChangedEvent] - GF_Kitchen_Light_Dimmer changed from 91 to 100
I’m running OpenHAB 2.4.0:
openhab> feature:list|grep -i tradfri
esh-binding-tradfri │ 0.10.0.oh240 │ │ Started │ openhab-addons-2.4.0 │
openhab-binding-tradfri │ 2.4.0 │ x │ Started │ openhab-addons-2.4.0 │ TRÅDFRI Binding
I’m not excluding this, but other apps I frequently use don’t display this behaviour (e.g., Home app on iOS, Eve app).
Here’s the OpenHAB2 event log when using the Home app on an iPhone to set the dimmer value to 1:
2019-02-12 21:43:49.210 [vent.ItemStateChangedEvent] - tradfri_0100_GATEWAY_ID_65553_brightness changed from 1 to 0
2019-02-12 21:43:49.212 [vent.ItemStateChangedEvent] - AT_GuestRoom_Light_Toggle changed from ON to OFF
2019-02-12 21:43:49.212 [vent.ItemStateChangedEvent] - AT_GuestRoom_Light_Dimmer changed from 1 to 0
2019-02-12 21:43:50.858 [vent.ItemStateChangedEvent] - tradfri_0100_GATEWAY_ID_65553_brightness changed from 0 to 1
2019-02-12 21:43:50.859 [vent.ItemStateChangedEvent] - AT_GuestRoom_Light_Toggle changed from OFF to ON
2019-02-12 21:43:50.860 [vent.ItemStateChangedEvent] - AT_GuestRoom_Light_Dimmer changed from 0 to 1
2019-02-12 21:43:52.217 [vent.ItemStateChangedEvent] - tradfri_0100_GATEWAY_ID_65553_brightness changed from 1 to 0
2019-02-12 21:43:52.219 [vent.ItemStateChangedEvent] - AT_GuestRoom_Light_Toggle changed from ON to OFF
2019-02-12 21:43:52.221 [vent.ItemStateChangedEvent] - AT_GuestRoom_Light_Dimmer changed from 1 to 0
It’s another light that’s being manipulated here, but you see that the state neatly toggles between 0 and 1 (1%), as opposed to the almost always off-by-1 state updates in OpenHAB.
I think both of you are right. The TRÅDFRI API expects a value from 0 to 254. We have to map it to a range from 0 to 100. Therefore rounding is used. But similar to this Hue binding issue, the binding uses rounding inconsistently. Meaning it uses Math.round() for outgoing values (from OH2 towards TRÅDFRI) and Math.ceil() for incoming values. Changing the outgoing calculation to Math.floor() will solve this issue. I will prepare a fix for it.
They don’t as ‘1’ cannot be set, apparently due to a rounding error. But if I set a value in OpenHAB then other apps will pick up the changes. At least that’s the case for the Trädfri binding.
No, that will not work smoothly. The problem is the edge case when we receive a 1 for the brightness from TRADFRI. That will result in 0 (Math.round(1 / 2.54) = 0) after rounding and will show the bulb as OFF.
I see. So it’s either (a) making use of a lookup table or (b) use a combination of Math.floor() for outbound and Math.ceil() for inbound levels.
Likewise I suppose the Trädfri remote / dimmer battery levels are also quantised and may have a similar issue:
2019-02-13 18:25:52.427 [vent.ItemStateChangedEvent] - TradfriDimmer1BatteryLevel changed from 74 to 60
2019-02-13 18:25:52.429 [vent.ItemStateChangedEvent] - tradfri_0820_GATEWAY_ID_65559_battery_level changed from 74 to 60
2019-02-13 18:26:06.000 [vent.ItemStateChangedEvent] - TradfriDimmer1BatteryLevel changed from 60 to 74
2019-02-13 18:26:06.001 [vent.ItemStateChangedEvent] - tradfri_0820_GATEWAY_ID_65559_battery_level changed from 60 to 74
From the reported battery levels, it seems to me that there are 7 or probably 8 discreet battery levels reported by OpenHAB. Right now I have seen: (NULL), 34%, 47%, 60%, 74%, 87% and 100%.
And sometimes battery levels seem to jump between 2 states:
2019-02-13 13:48:55.097 [vent.ItemStateChangedEvent] - tradfri_0820_GATEWAY_ID_65559_battery_level changed from 60 to 74
2019-02-13 14:06:48.512 [vent.ItemStateChangedEvent] - tradfri_0820_GATEWAY_ID_65559_battery_level changed from 74 to 60
2019-02-13 16:51:12.174 [vent.ItemStateChangedEvent] - tradfri_0820_GATEWAY_ID_65559_battery_level changed from 60 to 74
2019-02-13 16:51:33.067 [vent.ItemStateChangedEvent] - tradfri_0820_GATEWAY_ID_65559_battery_level changed from 74 to 60
2019-02-13 17:47:06.238 [vent.ItemStateChangedEvent] - tradfri_0820_GATEWAY_ID_65559_battery_level changed from 60 to 74
2019-02-13 18:25:52.429 [vent.ItemStateChangedEvent] - tradfri_0820_GATEWAY_ID_65559_battery_level changed from 74 to 60
2019-02-13 18:26:06.001 [vent.ItemStateChangedEvent] - tradfri_0820_GATEWAY_ID_65559_battery_level changed from 60 to 74
2019-02-13 18:49:26.270 [vent.ItemStateChangedEvent] - tradfri_0820_GATEWAY_ID_65559_battery_level changed from 74 to 60
UPDATE - from all data I collected so far, I can conclude the following:
There seems to be only a few battery level steps: 100%, 87%, 74%, 60%, 47%, 34% I can relate; likewise I’m expecting to see 20% and 7% (to be confirmed).
The “low battery” channel appears to be ON when the battery level drops below 50% (actually, 47% due to the discrete battery level steps)
Sometimes the battery level transitions between 2 discrete levels (see the line for Dimmer 1 in green)
Here’s the Influx data rendered in Grafana spanning 9 days and covering 5 Trädfri remotes and one dimmer:
@shutterfreak Thanks for the update. Indeed some nice information. I never persisted my battery levels, thus a deeper analysis was not possible.
Are you talking about the OH2 “low battery” channel? I guess not because this only will be ON if the battery level drops below 10% (see TradfriWirelessDeviceData.java).