I have a TV group item with “television” alexa-metadata and related groupitems for power state, volume, channel, etc, which all have Alexa metadata assigned.
Controlling TV via Alexa was working fine but it stopped a few days ago and Alexa told me always, that the TV does not support the command (even a simple turn on / off was not working anymore).
Withing Alexa app I removed the TV from my devices, started rediscovering and the TV was not discovered anymore (event it was found before and I have not changed my metadata).
I checked the forum and did not found anyone posting similar issues recently.
I checked GitHub and found out that with version 3.1.0 updates to channel management were performed (maybe @jeshab knows the details).
I did a test and removed Alexa metadata from my channel item: TV is discovered and can be controlled.
If I remove the TV from Alexa app again, add metadata to the channel item, rediscover again the TV is not found anymore.
Therefore from my perspective I can now nail down the issue: If the channel item in my TV group has alexa meta data added, the TV group is not working or discovered by Alexa.
For the channel item I’m using Television.Channel metadata.
Here I have posted my ites definition 3 weeks ago.
It’s a LG WebOS device.
I was having problems getting alexa discoverr my TV items I added as well. so I deleted everything and started over and added all the items and metadata again then tried to discover devices again with alexa app and it didn’t work that time either. in frustration I deleted them all again and this time I only added the items of functions I plan on using . so Volume, Mute, Power, and Playback were the only ones I added as I don’t ever change the actual tv channel and it was discovered no issues. I don’t want to tempt fate so i’m not going to try and add the Channel Item back but I think the OP is right with his observation
Correct. You can see the announcement here. Part of this change includes support for string-based channel now opposed to just numerical channel for all supported item types.
You are on the right track. The new channel integration requires the channel mappings to be configured for String item. However, it will fallback using the state description options as mentioned in the documentation. The difference now is that previously it would remove any non-numerical values from it and now it will retain them for String item. Could you confirm how many entries that are listed in your state description options for your channel item?
Also, were you able to control your TV channel previously with Alexa? Some of the changes I introduced were based on your use case. You should be able to use ChannelStep linked to your LG WebOS binding channel up/down actions to control channel adjustments.
Wondering about new support for string-based channels, as my channel is string based and already worked before.
Maybe that’s part of my issue, that I have not configured any mapping in state description metadata nor any state mapping in the alexa meta data. The webOS binding is automatically populating any channel mappings without the need to manually configure it. However if I provide a mapping in the alexa metadata controlling the TV is working again, but changing the channel will obviously only work for the channel especially configured in the metadata.
Also with defining the channel name via metadata I can only change the channel based on the name, while in the past I could also used the channel number and say e.g. “Alexa, change TV to channel < channelNumber >” and not only “Alexa, change TV to channel < channelName >”
BTW: Thats maybe something webOS specific:
If I (independently of alexa integration) set the channel items state to a number, the TV will switch to this specific channel, even the real channel value is not a number.
E.g. the “Das Erste” tv-channel is on position 1 and if I set the channel item to 1, the TV will automatically select the correct channel and the item state will change accordingly
Thats from the item definition:
"value": "7_70_1_0_1019_10301_1",
"label": "1 - Das Erste HD"
Thats what happening if I change channel e.g. to “1” (directly via a script, working as expected)
2022-01-15 19:25:20.082 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'EGWohnzimmerFernseher_Channel' received command 1
2022-01-15 19:25:20.084 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'EGWohnzimmerFernseher_Channel' predicted to become 1
2022-01-15 19:25:20.098 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EGWohnzimmerFernseher_Channel' changed from 7_66_2_0_1011_11110_1 to 1
2022-01-15 19:25:20.688 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EGWohnzimmerFernseher_Channel' changed from 1 to 7_70_1_0_1019_10301_1
I have not configured any mapping manually. But using the rest interface to get the item description I see 797 channels populated by the binding.
This is the item I am using: channelItem.json (159.6 KB)
Yes, it was working before, even the thing channel & item for for TV-Channel a were / are string based.
Unfortunately, as per my knowledge, the webOS binding does not have a channel up/down actions, but only the channel itself.
Bottom line:
For me (and most likely any other webOS TV owner) the new update is more like a downgrade.
Before: No channel configuration needed.
After: Every channel must be configured manually in state description or alexa metadata mapping
Before: I could change channel either by name or channel number.
After: I can only define channel name in the mapping and changing a channel based on the number is not working anymore
Also wondering why an missing channel mapping is preventing the entire TV for not working with the alexa skill. I would understand that the channel is not working, if channel definition is not as expected, but that even discovery or other commands like power on, volume, mute, etc, are not working is a surprise for me.
Last but not least:
Even I am a bit disappointed that I have these issues (as from my point of view its a breaking change caused with the latest update), thanks for your work on the binding and your support here.
That’s fine but I didn’t foresee that the list of channels could be that big. This is probably why the discovery is failing when using the state description options populated by the binding.
That’s interesting. Looking closer at the LG webOS binding documentation, it clearly indicates that it can take the channel number or id. As a matter a fact, I have only found two bindings using a single String item to control channels and in both cases, it supports number and name commands. All other implementations have a separate channels for number and name (if supported).
So the first change will be to add back channel number support for String item and remove the channel mappings requirement. The second one is that I think it might be wise to not fallback to the state description options for that specific attribute or maybe limit the number of mappings that are loaded.
rule "Channel Adjustment"
when Item ChannelUpDown received command
then
val actions = getActions("lgwebos","lgwebos:WebOSTV:xxxxxxxxxxxxxx")
if (null === actions) {
logInfo("actions", "Actions not found, check thing ID")
return
}
switch receivedCommand {
case "UP": actions.increaseChannel()
case "DOWN": actions.decreaseChannel()
}
end
No worries. The changes around the channel attribute were not meant to be breaking in the way it is affecting you. I do appreciate the level of details you provided which makes it easy to understand what changes need to be done.
I must have missed the sitemap example as I was only looking at the provided channels.
For now I have defined most important tv- channels in the metadata, which is solving most of the pain. Looking forward for any next release of the skill
Maybe it’s worth for @albinoman887 to also check if defining a tv-channel mapping either in the alexa or state description metadata will solve the same issue.
