Generic Dimmer Item does not increase / decrease state value when receiving INCREASE / DECREASE commands but sets 0 or 100 to state when receiving ON OFF commands even with autoupdate forced to true

remisharrock · January 19, 2025, 11:13pm

Openhab 4.3.2
To reproduce:
1/ create a Dimmer Item “dimmer1”
2/ create a layout with 2 Label Cards, first with:
- Action: Send command
- Time Action : dimmer1
- Action Command : INCREASE
second with DECREASE instead
3/ In run mode, when you click the labels the Item receives the command, in the log we have:
Item 'dimmer1' received command INCREASE
or
Item 'dimmer1' received command DECREASE

but the state value of the Dimmer does not change .

Do the same but this time with ON OFF commands : the state value changes to 0 or 100 correctly.

Any clue what’s happening ?

Little video to show the problem (only with INCREASE DECREASE commands):

AndrewFG · January 19, 2025, 11:29pm

If the Dimmer Item is linked to a Thing Channel, then try creating a Rollershutter Item and linking it to the same Channel.

remisharrock · January 19, 2025, 11:38pm

It’s a pure item, not linked to anything:

I made that for pedagogical purposes and to proove that the Dimmer is (in my view) buggy and has a wrong behavior (receiving an INCREASE command shoud INCREASE the value/ INCREMENT the value with the default “step” - I guess +1)

No Things are involved in that test.

Because no Things are involved, it’s impossible for me to link a Rollershutter item and a Dimmer item with a Channel, because there is no Thing involved here, maybe that’s the problem ?

Also : why when I send the ON OFF commands it indeed changes the state to 0 or 100 but when I send INCREASE DECREASE commands it dos not change the state ?

rlkoshak · January 20, 2025, 12:44am

I’d assume you have autoupdate enabled on this Item. Autoupdate is what is interpreting the commands and predicting the new state of the Item based on that command, When an Item is linked to a Channel, I believe the binding is able to tell autoupdate what to do.

Lacking any binding involvement, autoupdate just has to apply some standard and static behaviors. ON == 100 and OFF== 0 are one such behavior.

Autoupdate should process INCREASE/DECREASE commands too. If it’s not (you’ll see autoupdate predictions in events.log) then an issue should be filed for that.

If you’ve disabled autoupdate, sending a command to an Item will never change its state. Only state updates change the state of an Item. That’s the purpose of autoupdate.

Are you actually verifying the state of the Item? Because if you have autoupdate turned off and send commands to the Item through the UI, the UI and the Item become out of sync. The UI is expecting the Item to become something in response to the command (e.g. turned ON or OFF) and it shows the UI element accordingly. However, because the Item never updates the UI element will remain out of sync until the UI is refreshed or the Item receives another update.

remisharrock · January 20, 2025, 12:54am

with autoupdate=true : ON and OFF are changing the state but INCREASE DECREASE are NOT changing the state !

01:51:23.915 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command ON
01:51:23.915 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'dimmer1' changed from 0 to 100
01:51:25.500 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command OFF
01:51:25.501 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'dimmer1' changed from 100 to 0
01:51:27.063 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command INCREASE
01:51:27.471 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command INCREASE
01:51:27.850 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command INCREASE
01:51:28.631 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command DECREASE
01:51:28.890 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command DECREASE
01:51:29.165 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command DECREASE

with autoupdate=false: ON OFF INCREASE DECREASE are not changing the state

01:52:57.824 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command ON
01:52:58.894 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command OFF
01:52:59.983 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command INCREASE
01:53:00.249 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command INCREASE
01:53:00.387 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command INCREASE
01:53:01.169 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command DECREASE
01:53:01.300 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command DECREASE
01:53:01.465 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command DECREASE

Lolodomo · January 20, 2025, 8:33am

Strange, maybe something missing in the autoupdate feature.

remisharrock · January 20, 2025, 12:58pm

When I turn the TRACE log level

log:set TRACE org.openhab.core.thing

(which has the AutoUpdateManager class with multiple TRACE logs)

with metadata autoupdate=true

I get this:

INCREASE and DECREASE commands do not trace anything
ON and OFF commands are tracing things

13:55:15.053 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command INCREASE
13:55:21.823 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command DECREASE
13:55:28.380 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command ON
13:55:28.380 [TRACE] [core.thing.internal.AutoUpdateManager] - Auto update strategy REQUIRED overriden by item metadata to REQUIRED
13:55:28.380 [TRACE] [core.thing.internal.AutoUpdateManager] - Automatically updating item 'dimmer1' because no channel is linked
13:55:28.381 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'dimmer1' changed from 0 to 100
13:55:31.746 [TRACE] [core.thing.internal.AutoUpdateManager] - Auto update strategy REQUIRED overriden by item metadata to REQUIRED
13:55:31.746 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'dimmer1' received command OFF
13:55:31.746 [TRACE] [core.thing.internal.AutoUpdateManager] - Automatically updating item 'dimmer1' because no channel is linked
13:55:31.747 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'dimmer1' changed from 100 to 0

remisharrock · January 20, 2025, 1:36pm

digging a little bit more here is the difference between the ON command and the INCREASE command with TRACE enabled :

ON command :


14:13:48.481 [TRACE] [.internal.events.ThreadedEventHandler] - inspect event: org.osgi.service.event.Event [topic=openhab] {topic=openhab/items/dimmer1/command, type=ItemCommandEvent, payload={"type":"OnOff","value":"ON"}, timestamp=1737378828481}

14:13:48.481 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.internal.items.ExpireManager).

14:13:48.481 [TRACE] [hab.core.internal.events.EventHandler] - Skip event subscriber (class org.openhab.core.automation.internal.module.handler.ItemCommandTriggerHandler) because of its filter.

14:13:48.482 [TRACE] [hab.core.internal.events.EventHandler] - Skip event subscriber (class org.openhab.core.automation.internal.module.handler.ItemCommandTriggerHandler) because of its filter.

14:13:48.482 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.websocket.event.EventWebSocketAdapter).

14:13:48.482 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.thing.internal.CommunicationManager).

14:13:48.482 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.monitor.internal.metrics.EventCountMetric).

14:13:48.482 [TRACE] [hab.core.internal.events.EventHandler] - Skip event subscriber (class org.openhab.core.automation.internal.module.handler.ItemCommandTriggerHandler) because of its filter.

14:13:48.482 [TRACE] [hab.core.internal.events.EventHandler] - Skip event subscriber (class org.openhab.core.automation.internal.module.handler.ItemCommandTriggerHandler) because of its filter.

14:13:48.482 [DEBUG] [tor.internal.metrics.EventCountMetric] - Received event on topic openhab/items/dimmer1/command.

14:13:48.482 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.monitor.internal.EventLogger).

14:13:48.483 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.internal.items.ItemUpdater).

14:13:48.483 [TRACE] [hab.core.internal.events.EventHandler] - Skip event subscriber (class org.openhab.core.automation.internal.module.handler.ItemCommandTriggerHandler) because of its filter.

14:13:48.483 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'dimmer1' received command ON

14:13:48.483 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.rest.sse.internal.listeners.SseEventSubscriber).

14:13:48.483 [TRACE] [.internal.events.ThreadedEventHandler] - wait for event

14:13:48.483 [TRACE] [.internal.events.ThreadedEventHandler] - inspect event: org.osgi.service.event.Event [topic=openhab] {topic=openhab/items/dimmer1/state, source=org.openhab.core.autoupdate, type=ItemStateEvent, payload={"type":"OnOff","value":"ON"}, timestamp=1737378828482}

14:13:48.483 [TRACE] [g.openhab.core.io.rest.SseBroadcaster] - broadcast to potential 2 sinks

14:13:48.483 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.internal.items.ExpireManager).

14:13:48.484 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.websocket.event.EventWebSocketAdapter).

14:13:48.484 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.monitor.internal.metrics.EventCountMetric).

14:13:48.484 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.io.openhabcloud.internal.CloudService).

14:13:48.484 [DEBUG] [tor.internal.metrics.EventCountMetric] - Received event on topic openhab/items/dimmer1/state.

14:13:48.484 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.monitor.internal.EventLogger).

14:13:48.484 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.internal.items.ItemUpdater).

14:13:48.484 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.rest.sse.internal.listeners.SseEventSubscriber).

14:13:48.485 [TRACE] [.internal.events.ThreadedEventHandler] - wait for event

14:13:48.485 [TRACE] [g.openhab.core.io.rest.SseBroadcaster] - broadcast to potential 2 sinks

14:13:48.485 [TRACE] [.internal.events.ThreadedEventHandler] - inspect event: org.osgi.service.event.Event [topic=openhab] {topic=openhab/items/dimmer1/stateupdated, type=ItemStateUpdatedEvent, payload={"type":"Percent","value":"100"}, timestamp=1737378828484}

14:13:48.485 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.websocket.event.EventWebSocketAdapter).

14:13:48.485 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.thing.internal.CommunicationManager).

14:13:48.485 [TRACE] [hab.core.internal.events.EventHandler] - Skip event subscriber (class org.openhab.core.automation.internal.module.handler.ItemStateTriggerHandler) because of its filter.

14:13:48.485 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.monitor.internal.EventLogger).

14:13:48.486 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.rest.sse.internal.listeners.SseEventSubscriber).

14:13:48.486 [TRACE] [.internal.events.ThreadedEventHandler] - wait for event

14:13:48.486 [TRACE] [g.openhab.core.io.rest.SseBroadcaster] - broadcast to potential 2 sinks

14:13:48.486 [TRACE] [.internal.events.ThreadedEventHandler] - inspect event: org.osgi.service.event.Event [topic=openhab] {topic=openhab/items/dimmer1/statechanged, type=ItemStateChangedEvent, payload={"type":"Percent","value":"100","oldType":"Percent","oldValue":"0"}, timestamp=1737378828484}

14:13:48.486 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.rest.sitemap.internal.SitemapResource).

14:13:48.487 [TRACE] [hab.core.internal.events.EventHandler] - Skip event subscriber (class org.openhab.core.automation.internal.module.handler.ItemStateTriggerHandler) because of its filter.

14:13:48.487 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.internal.items.ExpireManager).

14:13:48.487 [TRACE] [hab.core.internal.events.EventHandler] - Skip event subscriber (class org.openhab.core.automation.internal.module.handler.ItemStateTriggerHandler) because of its filter.

14:13:48.487 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.websocket.event.EventWebSocketAdapter).

14:13:48.487 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.monitor.internal.EventLogger).

14:13:48.487 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.rest.sse.internal.listeners.SseEventSubscriber).

14:13:48.487 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'dimmer1' changed from 0 to 100

14:13:48.487 [TRACE] [.internal.events.ThreadedEventHandler] - wait for event

14:13:48.487 [TRACE] [g.openhab.core.io.rest.SseBroadcaster] - broadcast to potential 2 sinks

14:13:48.488 [TRACE] [g.openhab.core.io.rest.SseBroadcaster] - broadcast to potential 2 sinks

INCREASE command :


14:13:51.286 [TRACE] [.internal.events.ThreadedEventHandler] - inspect event: org.osgi.service.event.Event [topic=openhab] {topic=openhab/items/dimmer1/command, type=ItemCommandEvent, payload={"type":"IncreaseDecrease","value":"INCREASE"}, timestamp=1737378831286}

14:13:51.286 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.internal.items.ExpireManager).

14:13:51.286 [TRACE] [hab.core.internal.events.EventHandler] - Skip event subscriber (class org.openhab.core.automation.internal.module.handler.ItemCommandTriggerHandler) because of its filter.

14:13:51.286 [TRACE] [hab.core.internal.events.EventHandler] - Skip event subscriber (class org.openhab.core.automation.internal.module.handler.ItemCommandTriggerHandler) because of its filter.

14:13:51.287 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.websocket.event.EventWebSocketAdapter).

14:13:51.287 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.thing.internal.CommunicationManager).

14:13:51.287 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.monitor.internal.metrics.EventCountMetric).

14:13:51.287 [TRACE] [hab.core.internal.events.EventHandler] - Skip event subscriber (class org.openhab.core.automation.internal.module.handler.ItemCommandTriggerHandler) because of its filter.

14:13:51.287 [DEBUG] [tor.internal.metrics.EventCountMetric] - Received event on topic openhab/items/dimmer1/command.

14:13:51.287 [TRACE] [hab.core.internal.events.EventHandler] - Skip event subscriber (class org.openhab.core.automation.internal.module.handler.ItemCommandTriggerHandler) because of its filter.

14:13:51.288 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.monitor.internal.EventLogger).

14:13:51.288 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.internal.items.ItemUpdater).

14:13:51.288 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'dimmer1' received command INCREASE

14:13:51.288 [TRACE] [hab.core.internal.events.EventHandler] - Skip event subscriber (class org.openhab.core.automation.internal.module.handler.ItemCommandTriggerHandler) because of its filter.

14:13:51.288 [TRACE] [hab.core.internal.events.EventHandler] - Delegate event to subscriber (class org.openhab.core.io.rest.sse.internal.listeners.SseEventSubscriber).

14:13:51.288 [TRACE] [g.openhab.core.io.rest.SseBroadcaster] - broadcast to potential 2 sinks

14:13:51.288 [TRACE] [.internal.events.ThreadedEventHandler] - wait for event

Udo_Hartmann · January 21, 2025, 2:43pm

Well, to be fair, that never worked, there s simply not enough data.
Which step width for INCREASE/DECREASE?
There is simply no option to configure in openHAB, as these commands have to be handled by the linked hardware.

rlkoshak · January 21, 2025, 4:01pm

It makes as much sense to treat INCREASE as +1 and DECREASE as -1 (until you hit the boundaries) as it does to interpret ON as 100 and OFF as 0. I see no reason why autoupdate couldn’t handle these commands.

Udo_Hartmann · January 22, 2025, 12:31am

But it never did (since OH1.0).

And +/-1 will almost never be the real amount of change through INCREASE/DECREASE, as a typical fade from min to max (or vice versa) will maybe need 10 Seconds (most likely even shorter).
Now, openHAB may send one command each 300 msec, which will result in 33 IN-/DECREASE commands in 10 seconds, so one IN-/DECREASE command should add/subtract 3 instead of 1.
Maybe there are 4 commands per Second, would result in steps of 2.5 % (given the fade time is still 10 Seconds)

remisharrock · January 22, 2025, 9:40am

I agree with you that the is no consistency and that the increase decrease commands should at least change the state depending on the metadata state description: min max and step configured here ;

Udo_Hartmann · January 22, 2025, 11:31am

Yepp, would be a nice feature, though the result may or may not be correct
(same as ON → 100), but at least it would “tend to be more correct than no update at all”.

All in all, to get the correct state of a dimmer, you will need a message from the dimmer itself, and if there is a real state of a dimmer, best practice is to set autoupdate="false" to omit any “forecast” state update for the corresponding Item (even OFF → 0).

rlkoshak · January 22, 2025, 3:43pm

That doesn’t mean that it should not behave consistently going forward.

That’s going to be device dependent and in this case there is no device. This + or -1 will only apply of there is no link to a binding or the binding doesn’t define this behavior for you.

The other there is autoupdate does not have access to that information.

If there is no device, what’s “correct”? And if it’s not correct for what you want to do with this unbound Dimmer, turn autoupdate off and implement the increase/decrease in a rule.

Completely agree, but that’s not the use case being discussed here. This is an unbound Dimmer. There is no “real” device.

Udo_Hartmann · January 22, 2025, 9:18pm

Oh, my bad, I wasn’t aware of that…