Standardizing - NON Standard UDP Discovery Methods

[jeeftor]

A Standard for Non-Standard discovery

The current auto-discovery methods are ZeroConf, DHCP and SSDP. Various devices often support what I will call "Standard" "non-standardized" methods for discovery. What I mean is they use a common "flow" to discovery devices.

Existing Options: vol.Optional

Goal

• 1. See if HA Core could be modified to accommodate some of these discovery flows
• 2. If HA Core can support this discovery process, consider whether we could add another form of "Custom Auto Discovery" to allow for better user experience - with IoT devices that don't support the existing stadards

Proposed Solution

Off the top of my head it would be nice to have some standardized functions which could perhaps help with this:

The first would be something like this:

def _async_send_discovery_broadcast(
	ports: List[int],
	payload: str
):
	"""Send a Discovery payload on a set of UDP Ports."""

which would allow an integration to send out a Discovery Payload/Packet on a specific set of Ports

And then we could use a listener function like this

def _async_listen_for_broadcast_discovery(
	ports: List[int], 
	discovery_callback: Callback, 
	discovery_timeout: int=10):
	"""Register a callback to listen for incoming messages on UDP Ports."""

to register some sort of DiscoveryCallback to process any incoming messages in a given timeout to discovery devices. In the case of Automatic Broadcast we would only need this function I would think

Automating Discovery

• Assuming that HA had some sort of "standard discovery" hooks (which it already dose for DHCP/SSDP/ZeroConf) I would be interested in seeing if there was a way to automate the calling of these 1-2 functions hourly/nightly etc to enhance the User Experience by detecting additional devices...

Addressing @thecode - some sort of function could also be defined - which potentially could use the perviouslly defined async_listen_for_broadcast and async_send_discovery_broadcast functions if they were implemented..

def _async_has_discoverable_udp_devices() -> bool:
	"""Perform Discovery and return true if any devices are discovered."""

Examples and Flows

I've gathered a few examples of various integrations that use these types of flows. The two types of flows I see here are an automatic broadcast flow and a call & response flow.

Integration	Flow Type
Gree	Call & Response
IntelliFire	Call & Response
Switcher	Automatic Broadcast
WeatherFlow	Automatic Broadcast

Gree Climate

This is not my Integration so I'm just looking at the source code

Gree uses a Call & Response type of flow.

• 1. Broadcast a UDP message {"t":"scan"} on port 7000
• 2. Listen for incoming UDP Packets
  • The incoming IP from the packet will point to the device
  • The payload will contain a description of the device See Backing Lib for details)

{"pack": {
    "mac": "",
    "cid": 1,
    "name": "",
    "brand": "",
    "model": "",
    "ver": "1.0.0",}}

• After a Timeout collect all discovered devices ....

IntelliFire

IntelliFire uses a Call & Response type of flow.

• 1. Broadcast a UDP message IFT-search on port 3785
• 2. Listen on port 55555 for incoming messages of the format:

{"mac": "58:8E:81:92:52:7B",
"bssid": "B6:B9:8A:62:3C:E9",
"channel": 1,
"ip": "192.168.1.69",
"ssid": "SSID",
"rssi": -40,
"remote_terminal_port": 2000,
"time": 1665662949795,
"version": "BBBBBBB-SOMECODE-0.0.0.1, 2019-10-23T20:22:36Z, ZentriOS-W-3.6.3.0",
"uuid": "36413041000000004D0026001251373036363735"}

• 3: After a time out collect the IPs of all the discovered devices and configure ....

Switcher

This is not my Integration so I'm just looking at the source code

• 1. Open UDP Ports 20002 10001 20003 10003
• 2. Listen for Status messages in the form of:

{'auto_shutdown': '03:00:00',
'device_id': 'aaaaaa',
'device_state': <DeviceState.OFF: ('0000', 'off')>,
'device_type': <DeviceType.V2_ESP: ('Switcher V2 (esp)', 'a7', <DeviceCategory.WATER_HEATER: 1>)>,
'electric_current': 0.0,
'ip_address': '192.168.1.33',
'last_data_update': datetime.datetime(2021, 6, 13, 11, 11, 44, 883003),
'mac_address': '12:A1:A2:1A:BC:1A',
'name': 'My Switcher Boiler',
'power_consumption': 0,
'remaining_time': '00:00:00'}

It would appear Switcher Devices broadcast status every 4 seconds

Weatherflow

Tempest Weatherflow stations use an Automatic Broadcast flow

• 1. Listen on port 50222 for 10 seconds
• 2. Parse incoming packets to determine whether they are WeatherFlow packets

An example packet looks like:

{"serial_number":"ST-00084623",
"type":"rapid_wind",
"hub_sn":"HB-00068684",
"ob":[1695925434,0.88,169]}

[elupus]

What you are describing is ssdp...

[jeeftor]

well I need to read it then :)

[jeeftor]

SSDP is an established protocol that devices need to support correct -> or is it fully customizable?

[jeeftor]

SSDP is a text-based protocol based on HTTPU, which uses UDP as the underlying transport protocol. Services are announced by the hosting system with multicast addressing to a specifically designated IP multicast address at UDP port number 1900.

[Jc2k]

I think they misinterpreted your question.

My reading of it is: I assume you mean you want a way to have automatic discovery of devices (like with zeroconf), crucially where you don't control those devices to add SSDP, and instead need to support random UDP packet beacons. This may include sending some UDP broadcasts on an interval.

And I agree, SSDP is not that.

[Jc2k]

On the one hand I'd like this (it would be useful for my aircon and maybe fan).

On the other hand we probably don't want HA sending UDP packets for hundreds (or even tens) of random vendors that a user will never have?

[robloh]

This could be mitigated by doing it only on startup for example, or, by adding a "start discovery" (and stop) feature. This would also work great for things like BLE discovery where you may not want to discover every car tire rolling by your house (BLE discovery is always on currently).

[jeeftor]

Or maybe daily ... I dont think it matters how often (it can be very slow - or just on startup) but it would potentially increase the usability of HA

[thecode]

Switcher also uses UDP based discovery but not as described in this post, devices are using broadcast and it is enough just to listen to a port.

I would like to suggest a different solution which can cover multiple integrations and provide better flexibility.
Allow integrations to set a hook that will run and do some discovery and return True/False if full integration init should be done, similar to DHCP/SSDP/Zeroconf but allowing the integration to decide how to discover devices.

Since this is fragile and can slow down HA, there should be rules to limit the impact on the system. The discovery method should be limited to a small method, maybe limited by a short timeout and what is allowed and not allowed and maybe run it after HA has fully started.

[jeeftor]

I updated the proposal ... does that kind of hit on what you suggested?

[thecode]

Your updated suggestion looks good, the discovery can include the two methods _async_send_discovery_broadcast and _async_listen_for_broadcast_discovery and integrations can skip implementing _async_send_discovery_broadcast if they only need to listen.

With your suggestion the code can be limited to simple parsing & sending functions that only does the minimum to decide if a device discovered than it would start config flow and let the user approve adding the device and do a full init

[jeeftor]

That's kinda my thought process... Implement if you want ... dont if you dont -> but it would give at least some way forward standardization wise - to make things a tad more uniform

[issamwahbi]

Hey,
Do you think this proposition will comes to lives one day ?
I have a use case for some ev charging station that doesn't support SSDP or mDNS. By reverse ingeniering their APK I can see that at initialisation they are just broadcasting an UDP packet on a specific port and wait for the response. The IP and PORT are then updated from the received response for further controls.