[network] Add Wake-on-LAN support

[wborn]

It would be great to have native support for Wake-on-LAN (WoL) in an OH2 binding.

One approach could be to create a new OH2 binding for this replacing the OH1 Wake-on-LAN Binding. We've already seen some (now closed) PRs for this (https://github.com/openhab/openhab2-addons/pull/2759, https://github.com/openhab/openhab2-addons/pull/3796).

Another approach could be to add support for sending the WoL magic packet to an existing binding such as the Network Binding. This binding already has support for OH2 features such as (pingable) Things, discovery and monitoring the online status (using ping).

If a new WoL binding would utilize all the new OH2 features such as discovery and Thing status it may start duplicating code for discovering and pinging devices that is already in the Network Binding. As a user I would also rather just use one binding for monitoring the online status of network devices.

What are your thoughts on this @kaikreuzer and @davidgraeff?

[kaikreuzer]

I agree that from the functionality it would fit nicely to the network binding. So if WoL support does not require any additional libraries that are otherwise irrelevant for the network binding, I think it would be a good idea to add the feature to the network binding.

[davidgraeff]

Could be implemented with UDP wol packets yes. But we need the destination Mac address. The current autodiscovery only notifies about IP addresses.

[wborn]

What do you think would be the best way to implement this in the Network Binding @davidgraeff?

I'd prefer first adding basic WoL support so there is feature parity with the OH1 WoL Binding. After that new PRs can be created for adding more functionality.

• Should we add an optional MAC Address configuration parameter on both thing types (pingdevice, servicedevice)? Or would you rather create a new thing type for supporting WoL?
• We could add a trigger channel to the things to start sending the WoL magic packet. When the MAC address is not configured it could log a warning. If trigger channels cannot be used with Switch items we'd better use a Switch channel for this.
• The original WoL Binding also allows for configuring the broadcast address. The pingdevice and servicedevice have an IP address configuration parameter. If WoL support is added to these types and the IP address remains a required parameter, it could perhaps automatically determine the broadcast address from the network interface information. When the IP is not part of any local subnet it could unicast the magic packet to the IP instead.

---

In additional PRs we could add:

• MAC address discovery. After receiving packets from machines (on local subnets) the arp -a command can be used to obtain the MAC addresses for IPs.
• Additional WoL configuration parameters, e.g.:
  • Broadcast address configuration parameter to override the broadcast address detection logic
  • Wake-on-LAN port number
• Adding vendor lookup from MAC Addresses could perhaps also be added one day. Though the files with all the required information tend to take up several MBs (see Wireshark sources aggregation).

---

When adding configuration parameters on the existing thing types it would help to group the existing and new parameters in groups such as "Presence detection" and "Wake-on-LAN".

[asvilabs]

When the IP is not part of any local subnet it could unicast the magic packet to the IP instead.

Just a suggestion here from our experience with directed unicast WOL, it works only till target unicast IP is in ARP caches along the way. ARP caches usually have TTL (Time To Live) of couple of minutes I believe. Subnet directed broacast should be preferred over unicast, the original biding documentation from us does make this clear to user.

[wborn]

The unicast will probably be most useful for people who want to do WoL through the Internet. Did you ever experience UDP packet loss while sending magic packets @asvilabs? Some implementations send several magic packets as a workaround for this.

My LIFX lights that also use a UDP based protocol also suffer from packet loss. Those packets are sent via WiFi which could increase the packet loss.

[asvilabs]

WOL is basically UDP and boadcast/unicast. When its unicast we did experience packet losses mainly because in low power states the targets don't respond to ARP requests, nobody knows how to convert unicast IP to MAC targeted Ethernet frame. Thats why broadcast works. Local broadcast 255.255.255.255 will work for most users, but for us, since we have complex network, we had to use subnet broadcast (e.g 192.168.1.255), to get around ARP cache timeout issue.

Additionally some motherboard firmwares are designed to respond to WOL packets only if additional authentication/pattern matches, but we didn't implement that.

[asvilabs]

FTR we have added discovery support for Linux based openhab systems using shell script and standard tools lke ip, systemd-resolve, host, ping, nmblookup[optional], avahi-resolve[optional], and avahi-browse[optional]. Primary focus was getting hostname using many fallback techniques as IPs tend to change often.

https://github.com/asvilabs/esh-oh-legacy/blob/master/org.openhab.binding.wakeonlan.2.3.0.64-MULTIHOME.tar.gz?raw=true
Refer to Discovery section under README.md for description and optional dependencies.

Discovery Shell script is here:
https://github.com/asvilabs/esh-oh-legacy/blob/master/wol-discovery.sh

You may use it partially or as a complete binding as it is under EPL. Or maybe someone could publish a market entry till official WOL support is implemented in network binding. We will maintain it there for bug fixing / feature requests from users.

[wborn]

Thanks for sharing all the code under EPL @asvilabs! 👍 It certainly comes in handy for checking implementation details and exploring options so we don't have to reinvent the wheel. 😉

[asvilabs]

I am hoping bash4 gets adapted everywhere soon. I am a big fan of bash. Perl is also good, but too much magic there sometimes. Scripting language is key in any automation platform, things get prototyped very fast. I wish we can do some cleaner integration with Perl/Bash from Java/OH.

[asvilabs]

https://angryip.org

I like angryip scanner. Java based, cross platform. But its GPL. Is there a chance the authors could allow OH/ESH to link that with rest of the EPL? Its a great tool for discovery. Although I didn't check the level of their IPv6 readiness.

[Keltere]

Any news on WOL support?

[Simonthorsted]

look here 👍
https://github.com/asvilabs/esh-oh-legacy/

[Keltere]

@Simonthorsted thanks.
Sorry to bother but does it works? I've tried adding to the addons directory but i can't seem to install it.

[davidgraeff]

Anybody involved here: Is there still demand for WOL in the network binding and is anybody going to work on it?

[wborn]

I'd definitely like a OH2 binding with WoL support. :-)
How do you think it should be implemented in the Network Binding @davidgraeff?
Can you comment on my implementation ideas in https://github.com/openhab/openhab2-addons/issues/3799#issuecomment-411801123?

[davidgraeff]

Wol is best implemented as an action now I guess