Lost on rule using switch/case statements

Hello, I’m stuck trying to create a rule using the switch and case statements. context as follows:
I’m using the lg-webos-binding to connect to my TV. I’m using the DenonMarantz binding to connect to my AVR. my goal is to automatically switch to a sound profile, depending on the TV usage. think of: using the game console, watching nexflix, watching youtube, watching TV, etc.My issue is that although the item OLED_TV_Application is changed, I’m not able to execute the statements for the case representing that state (the rule below is only for 1 state, but I have the problem for all states.

rule "Set Sound Settings AVR"

when
    Item OLED_TV_Application changed

then
    logInfo("test1: Set AVR MainZone_Input", "OLED_TV_Application: ["+ OLED_TV_Application.state + "]"
    switch(OLED_TV_Application.toString) {
        case "com.webos.app.hdmi1": {
            logInfo("test2: Set AVR MainZone_Input", "OLED_TV_Application: ["+ OLED_TV_Application.state + "]")  
            AVR_MainZone_Input.sendCommand("TV")
            Thread::sleep(1000)
            AVR_SurroundProgram.sendCommand("DOLBY SURROUND")
            Thread::sleep(1000)
            AVR_MainZone_Volume.sendCommand(55)
            logInfo("test3: Set AVR MainZone_Input", "Einde instellen voor HDMI1")
        }
    }
end

When I switch the TV from HDMI2 to HDMI1 the following is logged:

==> /var/log/openhab/openhab.log <==
2022-06-12 11:58:25.331 [INFO ] [script.test1: Set AVR MainZone_Input] - OLED_TV_Application: [com.webos.app.hdmi1]

==> /var/log/openhab/events.log <==
2022-06-12 11:58:25.326 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OLED_TV_Application' changed from com.webos.app.hdmi2 to com.webos.app.hdmi1
2022-06-12 11:58:26.710 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'AVR_MainZone_Input' changed from GAME to TV
2022-06-12 11:58:26.829 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'AVR_SurroundProgram' changed from DOLBY SURROUND to MCH STEREO

I don’t understand this. I expect at least output in the log for “test2” and “test3”. Which makes me believe that the case value that I’m expecting is wrong or is of different type. The Item value displayed in openhab is confusing me even more:
OLED_TV_Application-HDMI1
… which obviously is different to “com.webos.app.hdmi1”

The fact that I still have item changes for AVR_MainZone_Input and AVR_SurroundProgram is due to HDMI control cause the devices to talk to each other directly, which as far as I’m aware cannot be avoided without loosing the ability to interact with a single remote control.

Does anyone spot a mistake in my approach?

Such long thread:sleeps can have unwanted side effects.
Try removing them, or use expire timers instead.
See Design Pattern: Expire Binding Based Timers - Tutorials & Examples - openHAB Community
Note, expire is now part of Core, not a binding anymore (OH3)

Shouldn’t it be OLED_TV_Application.state.toString?

1 Like

Yes, definitely.

@fennepa
As it’s openHAB3, Thread::sleep() should not be a problem. Would be better to show the whole rule, as there should be no command at all…

Please be aware that there is no log “test2…” - and it’s wrong to use the log command this way.
the better log command:

logInfo("set_avr", "OLED_TV_Application: [{}]", OLED_TV_Application.state)
...
case...
    logInfo("set_avr", "Set AVR MainZone_Input - detected hdmi1 Input")

Be aware that “set_avr” is the last part of the Logger Name, it’s not part of the message!

I’ll try to address some of the unanswered questions.

As already mentioned, OLED_TV_Application is an Item. An Item has all sorts of stuff beyond the Item’s state. You are looking at just the state though so you need to use OLED_TV_Application.state.toString as Jörg suggested.

Bindings will sometimes insert their own State Description metadata for Items linked to certain Channels. That is probably what’s happening here so that MainUI shows “HDMI`” but, as the logs indicate, the Item’s actual state is “com.webos.app.hdmi1”. The binding supplied a mapping between the longer state and the more human friendly display state.

Always trust events.log as the true state of the Item over what you see in the UI.

It’s always been that way but it seems to work now. The line

logInfo("test1: Set AVR MainZone_Input", "OLED_TV_Application: ["+ OLED_TV_Application.state + "]"

resulted in

2022-06-12 11:58:25.331 [INFO ] [script.test1: Set AVR MainZone_Input] - OLED_TV_Application: [com.webos.app.hdmi1]

It appears that if a logger name is not supplied, “script.” is used. That appears to be new(ish) behavior on the logger. I know there was some work done on this for JS Scripting but perhaps I’m missremembering and it was done on behalf of JS Scripting but was implemented in core.

Thx for pointing this out. I actually used @rossko57 own post as my starting point, but I failed to notice that the entire topic was using a variable rather than an Item.

As I’m just waiting for 1 or 2 seconds to make sure the AVR device has processed the command and is ready for the next, I decided to use the thread:sleep. It fits my need. I will look into the expire timer if it would give me control of throwing the next command as soon as the previous command changed the item…