That was the one I meant.
It think it was named Start+ in the beginning though, but it is that one referred to today! 
Are you the same guy who posted this exact issue on avforums?
If so, I replied to you there already, but will repost here in case it helps, since I also linked to a different github issue which seems to match your experience more closely:
There should be a setting called QuickStart+ which according to a WebOS integration github issue for HA needs to be set to OFF.
Thereâs also another suggestion to uncheck broadcast address in the integration when first setting it up, and that this only works for wired LAN.
I still havenât set up the integration myself in HA yet, so this is all second-hand information, but itâs worth a shot. Have a play around with those (you might need to uninstall & reinstall the integration to disable broadcast address).
Hi, yes Iâm the same person. I tried everywhereâŚ
The settings you mention do nothing I already tried.
Will try reinstall the integration and see if the broadcast settings help ⌠it so random that maybe works now and fail a couple days later. It a problem hard to find because of it
If you can not even ping the TV when it is offline, then there is nothing HA can do either.
Ping is a basic network utility and unrelated to HA. It is used to check connectivity on the network and the first check you do before looking at higher program layers.
Just for the record: I canât ping my LG TV and it does WOL.
edit: when itâs on standby (+ mode)
1 Like
Hmm, too many situations here.
The ping is meant to be done when the TV is on to see what happens when it suddenly register a drop out in the integration or connection.
Linuxâs ping command will run continuously when called.
Windowsâs ping command need -t added to make it continuously running.
And is posible that home assistant could do something to the tv that make it drop from network? If the only thing that could think itâs happening if all work well with homebridge per example
Never say never, but I can not see how.
It is more likely that it is an issue between the TV and the network gear. That one I can see as possible, because there are so many possibilities for errors.
It could be a Cat5 network cable that is connected to gigabit ports, it could be green ethernet that just dont work right, it could be electrical noise from other cables that eventually will make the network port shutdown on the switch/ap/router/device.
There are 2 issues. if i got this correctly:
-
WOL sometimes doesnât work.
There seems to be an issue with the +Mode or the WIFI/LAN connection. Some say you need to turn +Mode off, then back on, some say it canât be +Mode, some say you need to turn it off, then back on, then reenable WOL in the tv settings. Some say it only works on LAN, some say it only works on WIFI.
I say: LG TVs are a pain and change in behaviour from OS version to OS version. You have to try them all. -
Automation turns the lights off after 9 seconds, as it assumes the TV is off.
This could be solved within the automation or maybe with the ping.
Maybe the two are connected.
I meant there were too many situations the tests could be done in, but you are correct.
There are two situations that needs to be handled.
Maybe it is just a typical WoL issue.
Wake-on-Lan have some requirements that can influence here.
First it needs to be enabled on the interfaces of the device.
Secondly the device that triggers the WoL needs to be able to find the device that will receive the WoL packet and here are many issues to stumble into.
Firstly the WoL packet is being sent to a MAC address.
This MAC address is looked up in the network gears ARP table, but ARP tables are maintained by the network device according to the rules made by the manufacturer. Only the more expensive devices allow changing of some of these ARP table settings.
ARP tables are lists of IP - MAC address relations. When a MAC address is regularly seen on the network it is marked as active in the list. If it has not been seen for some specific time, then it is marked as stale and after some time more with out being seen it is removed.
If it is activein the ARP table, then the device is on, so no need for a WoL packet.
If it is stale, then the device is off and a WoL packet can be sent to wake it up. Here a MAC address can be used or an IP address, because the ARP table can be used.
If it is removed, then a WoL packet can be sent, but only a MAC address can be used, because there is no entry in ARP table to translate an IP address to a MAC address.
The times for when a device is removed can be quite low on some network gear.
Another issue is with WiFi, which is a somewhat new thing with WoL and often not supported that well.
The issue here is that the device that is going to woken up will have to maintain a WiFi connection even though it is turned off.
This means it will have to run in a semi-off state. This semi-off state is just not really a standard and many APs have no implementation of any version of it, so when a device goes into the semi-off state, then the AP will keep the device listed for a while and then decide that device probably died and disconnect it completely, which thereby kills all options for WoL to function thereafter., until the device is reconnected again, starting the cycle over again.
This might (!) be prevented by pinging the device, not for having it found, but for telling the AP itâs still relevant. Just an idea.
It does not work.
The ARP table is only updated with the sender addresses not receiver addresses.