Skip to content

Shelly, CoAP and multicast

Jump to bottom
Alexander Rydén edited this page May 9, 2021 · 18 revisions

Update (March, 2021)

As of firmware version 1.10.0, Shelly devices now also support CoAP over unicast to work around the issues with multicast. If you experience the symptoms described below, try the following:

  1. Open the web interface of your Shelly device.
  2. Go to Settings -> Advanced - Developer Settings.
  3. Set CoIoT peer to the IP address of your device running homebridge and port 5683, e.g. 192.168.1.100:5683.
  4. Click Save. The device will now use unicast instead of multicast. No other configuration is needed.

Shelly devices use CoAP to announce their presence in a network, as well as to broadcast status updates. These announcements are sent as IP multicast messages (to IP address 224.0.1.187 and UDP port 5683). This plugin listens for these messages to automatically discover all Shelly devices and to react to changes, such as when a light is turned on or when a sensor reports a new temperature. It doesn’t however use CoAP to control Shelly devices, such as turning a light on or off. These commands are sent over HTTP.

In a simple network setup, where the Shelly devices and the device running homebridge are connected to the same Wifi router, this usually works really well. Problems may arise though in more complex setups, with multiple access points, mesh networks, switches, firewalls etc., when homebridge is running in a virtual machine, or when there are multiple subnets. In these circumstances, multicast messages may not be routed properly to all devices in the network. Accessing the Shelly devices through their web interfaces or the Shelly app will still work though as that uses HTTP, not CoAP.

Common Issues

Devices aren’t discovered

When no CoAP messages reach this plugin, devices simply won’t be discovered at all. This can be true for some or all of Shelly devices, depending on your network configuration.

Devices aren’t updated properly

In some cases, some CoAP messages are received, but most of them aren’t. This will result in your Shelly devices being discovered (at least eventually) but updates to them aren’t seen. For instance, when you turn a light on using the physical switch, the light isn’t displayed as on in the Home app.

Devices can be turned on but not off

When a device has been discovered but updates aren’t received properly, you can end up with a switch or a light that can only be turned on but not off when using the Home app. This is because the command to turn a switch or light on is sent over HTTP, but the CoAP status update telling this plugin that it actually turned on is never received. To HomeKit, the device will thus remain off, and subsequent requests to toggle the switch or light will always try to turn it on. For dimmable lights, dimming will still work as that doesn’t need a status update the same way a toggle command does.

Troubleshooting

To find out if CoAP multicast messages are properly received from your Shelly device, you can do some of the following:

  • Install the shellies library by running npm install -g shellies, then run shellies listen. It will show you when it detects a device and whenever a property on the device is changed. If you don't see any output from your device here, it most likely means you have an issue with your network.
  • Run tcpdump tcpdump -s0 dst 224.0.1.187 and port 5683. It will show you when CoAP multicast messages are being picked up. If you don't see any output, you probably have an issue with your network.
  • Run netcat nc -kluw 0 224.0.1.187 5683. The output from this command won't be easy to read, but if you do see some output, at least you are receiving CoAP multicast data (though if you have multiple Shelly devices, it can be hard to tell which one it's coming from). If you don't see any output, you probably have an issue with your network.

Run these commands on the same device that you are running homebridge on to see if it receives multicast messages, or on other devices to see if multicast messages are received in other parts of your network.

Note that homebridge-shelly describe and shellies status send unicast requests and will still work even when there is an issue with multicast messages.

Solutions

  • Your router may need to be configured to activate IP multicast routing or forwarding. If and how this can be configured varies widely between routers. Here are some examples of settings that have worked for some users:

    • Turning off Beamforming for TP Link Deco M5. #152
    • Disabling Broadcast filtering, Multicast transmission filtering and Dynamic multicast optimization. #152
    • Enabling Convert IP Multicast to Unicast for AeroHive. #147
    • Enabling Port Isolation for UniFi. #109
    • Turning off WMM for the 2.4 GHz spectrum. #104
    • Disabling Optimize multicast data. #19

    You can also find some useful points in this article. Though it covers HomeKit and Bonjour/mDNS, the same settings may be useful for Shelly devices as mDNS uses multicast data too.

  • If you can connect homebridge and your Shelly devices to the same router with as few obstacles between them as possible, that usually helps. Changing to a different router might also help.

  • If your homebridge device has multiple network interfaces, you can try setting the networkInterface configuration option of this plugin to the name (such as eth0, wlan0 or en0) or the local IP address (such as 192.168.1.2) of the interface you are using.

  • If homebridge is running behind a firewall, try opening port 5683 to local UDP network traffic.

Frequently asked questions

Why not use MQTT?

The goal of this plugin has always been simplicity. CoAP enables integrations with zero configuration and no additional software. MQTT on the other hand requires a broker and that every device is configured to communicate with that broker. Also, enabling MQTT on a Shelly device will automatically disable cloud services.

That said, it’s not impossible that this plugin will gain support for MQTT in the future, for those users that have issues with CoAP but don’t mind installing and configuring an MQTT broker.

Why not use HTTP?

Devices can’t be discovered using HTTP only, so every device would have to be added manually. Status updates would then have to be retrieved by either polling at regular intervals or setting up “URL actions” (webhooks) on each device. Polling doesn’t work well with battery powered devices that only come online sporadically, and changes aren’t seen immediately. URL actions, on the other hand, aren’t available for all device properties.

Clone this wiki locally