Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document multicast support for udp component #4576

Open
wants to merge 4 commits into
base: next
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 31 additions & 4 deletions components/udp.rst
Original file line number Diff line number Diff line change
Expand Up @@ -56,6 +56,8 @@ Configuration variables:
- **port** (*Optional*, int): The destination UDP port number to use. Defaults to ``18511``.
- **addresses** (*Optional*, list of IPv4 addresses): One or more IP addresses to broadcast data to. Defaults to ``255.255.255.255``
which is the local network broadcast address.
- **listen_address** (*Optional*, IPv4 address): Changes to multicast, adding an address to listen to. Defaults to no multicast address, just
local network broadcast address ``255.255.255.255``. **NOTE**: Adding a multicast address stops it from listen on unicast address.
- **sensors** (*Optional*, list): A list of sensor IDs to be broadcast. Each entry may be just the sensor id, or may set a different id to be broadcast.

- **id** (**Required**, :ref:`config-id`): The id of the sensor to be used
Expand Down Expand Up @@ -114,8 +116,8 @@ attacks on the encryption much more difficult. This is enabled in the provider c

For further protection a ``ping-pong`` (or challenge-response) facility is available, which can be enabled in the
consumer configuration. The consumer periodically generates a 32 bit random number (a *nonce* aka "Number used Once")
and broadcasts it as a *ping*. Any provider receiving this nonce will include it in any future encrypted broadcasts as
*pong*. The consumer expects to get back its most recently transmitted *ping* in any packets it receives, and will reject
and broadcasts it as a *ping*. Any provider receiving this nonce will include it in any future encrypted broadcasts as
*pong*. The consumer expects to get back its most recently transmitted *ping* in any packets it receives, and will reject
any that do not contain it.

Use of the ping-pong feature will add to network traffic and the size of the transmitted packets (a single packet may
Expand Down Expand Up @@ -263,7 +265,7 @@ the port specified in the ``udp_external`` configuration:
- humi_rooma
- humi_roomb
- humi_roomc

- id: udp_external
update_interval: 60s
encryption: "Muddy Waters"
Expand All @@ -284,9 +286,34 @@ the port specified in the ``udp_external`` configuration:
provider: remote-node
remote_id: binary_sensor_unlock_me
on_press:
- lambda: |-
- lambda: |-
ESP_LOGI("main", "d command to binary_sensor_unlock");

The example below shows two devices communicating via multicast:

.. code-block:: yaml

# Device 1
binary_sensor:
- platform: gpio
pin: D2
id: binary_sensor_door

udp:
- id: mc_external
address:
- 239.0.60.53
binary_sensors:
- binary_sensor_door

# Device 2
binary_sensor:
- platform: udp
id: remote_door_sensor
remote_id: mc_external

udp:
listen_addresses: 239.0.60.53

.. [#f1] As known in 2024.06.

Expand Down
Loading