Hello,
I would like to develop an external integration for LG webOS (like I did for V3 back in the day).
I’ll look into starting development soon ![]()
Hello,
I would like to develop an external integration for LG webOS (like I did for V3 back in the day).
I’ll look into starting development soon ![]()
I already have something that works pretty well.
But I have two technical questions.
With this type of TV, when it’s on, you can do whatever you want. But once it’s off, to turn it back on, you need to use WOL.
My WOL works fine locally. But once it reaches the container, it’s a disaster. Indeed, the container only knows about the gladys_intégration network.
Do you know if we can make an exception for certain containers?
LG WebOS has a TV notification system.
Is there an action that takes into account a message and a broadcast channel? And consequently, which feature should I map it to?
Thanks in advance
Hi @spenceur, great news for this integration
I’ll respond in order.
1. The Wake-on-LAN
Actually, you can already do it yourself: the gladys-integrations network is a classic bridge, so a unicast packet to the TV’s IP (port 9) exits the container very well and arrives on your LAN: it’s the same path as for joining the Internet. What doesn’t work is only the broadcast: 255.255.255.255 stays in the bridge, and the directed broadcast (192.168.1.255) is not forwarded by the host. As most WOL libs send to 255.255.255.255 by default, I bet that’s your problem. Force the destination address:
wol.wake('AA:BB:CC:DD:EE:FF', { address: '192.168.1.42' });
You retrieve the IP via the medieval scan (source_ip of the responses) while the TV is on, and you remember it for later, don’t forget to advise a DHCP reservation in your docs.
The only remaining limitation is not Docker but ARP: in unicast, the host must resolve the TV’s MAC. If it still responds to ARP while sleeping, this is the case for LG with « Mobile TV On » / Quick Start+ enabled, it works. If it is completely off and the ARP entry has expired, the packet is discarded, and then only the broadcast gets through. If you notice that this case actually happens with your users, let me know: I’ll add a network/wake primitive on the core side (the core is in network=host, it can broadcast), but I prefer to wait until I have confirmation that it’s necessary rather than adding an API « just in case ».
By the way, on the LG side: WOL only works if « Mobile TV On / Turn on via Wi-Fi » is enabled in the TV settings, and it’s much more reliable over Ethernet than Wi-Fi. A good part of future feedback « it doesn’t work » will come from there.
2. Notifications on the TV
For this, we already have what we need: the text type (category text, type text), which works very well and is exactly the right mapping for « pushing a message to a screen ». Model your notification as a text feature of the TV device.
3. The select
You’re right, and this is the most interesting point of the three. There is indeed a mechanism for device options (supported_options), but it is designed for closed enumerations defined by the core: the values are integers and the labels come from Gladys’ translated catalog (air conditioning modes, fan speeds…). The integration only restricts a list that the taxonomy already knows.
A list of TV applications is the opposite: open, specific to each device, identified by strings (netflix, com.webos.app.hdmi1), and changes when the user installs an app. Above all, don’t map them to integers: you would have to maintain an index ↔ appId correspondence that will change with each rescan, and the scene « launch app 3 » would silently launch something else the next day. It’s the kind of bug that’s impossible to diagnose.
Therefore, a real « select with string values » is missing, with options published by the integration. It’s a generic gap, not specific to LG (TV sources and apps, favorites and playlists, vacuum cleaner parts…), so I want to design it properly rather than hack it together.
Will you create a feature request for this topic?
Thanks for your complete and constructive reply ![]()
WOL
I was indeed doing a broadcast to 192.168.1.255 and not a unicast. Let’s see if it works well after a long deep sleep
.
TV notifications
I’m not sure about this one, I did create a text-type feature
{
name: ‹ TV Message ›,
external_id: ids.feature(FEATURE_KEYS.TOAST),
category: ‹ text ›,
type: ‹ text ›,
min: 0,
max: 0,
read_only: false,
has_feedback: false,
keep_history: false,
}
But when I perform a ‹ control a device › action, I have no action that triggers with text, except if I send an int
In the repo I see this:
I see that only int can be set and not strings.
I must therefore not be on the right action.
Can you help me?
here is the request for item 3
For unicast, here’s my answer,
After a long wait, I confirm that my TV no longer wakes up and that I’ll therefore need to create an API via the SDK ![]()
I do have all the right parameters since I wake it up via broadcast ^^
Create a Demande de fonctionnalités ![]()
@pierre-gilles Thanks for the requests created
And regarding this point, do you have time to advise me please?
Thanks for the requests!
I thought the usage was the opposite, that you wanted to see in Gladys information coming from the TV.
So, you want to basically send a text notification to your TV? Is that right?
Well if that’s the case, I think I’ll install this integration and test what will be possible ![]()
Indeed, in this case we currently don’t have the possibility to do that! ![]()
I’d be happy if you could create a request!
fait : Action de scène : Envoyer un message sur un appareil
We therefore have 3 features on the agenda:
@spenceur What I’ve done so far for notifications is that I’ve added the management of « text » type devices on the « Control a device » action:
The PR, merged:
I think this will be useful to a lot of people ![]()
And then when the external integration of the device receives it, does it perform an action (in my case, the notification on the TV)? Is that right?
Yes that’s it!
So the release should unlock full integration with the webOS (WebOS) LG devices
Thanks
I’m not committing to anything on the dynamic « select » field. Claude is working on it, but there’s a lot of work downstream
I’m doing my best, but there are many other topics!
In any case, it will come in the next few days.