Setup for Shelly Device

[Michael McSharry]

Installation

To get Shelly devices connected on the local network to Homeseer the following three steps are needed.

1. Run mcsShelly plug-in
2. Tell Shelly device to use MQTT
3. Connect Shelly device to local network

Run mcsShelly plug-in
The plug-in is installed from the HS Updater and enabled from the HS Plugins page. No configuration of the plugin is needed unless there is an external (i.e. not mcsShelly) MQTT broker setup on the network. In this case the HS Plugin Menu will list mcsShelly and MQTT Setup as a page. Select this page and then select General Tab. In the Broker Operations section enter the IP of the external MQTT Broker.

Tell Shelly device to use MQTT
Telling Shelly to use MQTT can be done before or after getting the Shelly device on your WiFi network, but done first for simplicity of instructions. Using a browser enter the following text in the URL, but first change the red text to that which is appropriate for you.

http://192.168.33.1/settings?mqtt_server=[COLOR=#FF0000]192.168.0.7[/COLOR]:1883&mqtt_enable=true&mqtt_update_period=[COLOR=#FF0000]300[/COLOR]

The key mqtt_server (192.168.0.7) will be the IP of the MQTT broker. This will be the same as the IP of your HS server unless there is an external MQTT Broker setup. The key update_period (300) is the periodic reporting interval in seconds for things like temperature sensors.

Connect Shelly device to local network
Shelly initially powers up in AP mode using the 192.168.33.1 as its IP. This needs to be changed to station mode with the SSID credentials to get onto your local WiFi network. The following browser URL, with text is red changed for your WiFi, is used to accomplish this:

http://192.168.33.1/settings/sta?ssid=[COLOR=#FF0000]MyWiFiSSID[/COLOR]&key=[COLOR=#FF0000]MyWiFiPassword[/COLOR]&enable=1

The Shelly device will restart and connect to MyWiFiSSID rather than setting up its own SSID. It will announce itself using MQTT. mcsShelly will create all the HS devices and these can be viewed in HS Device Management or other favorite manner within HS. Setup is complete at this point.

[popeye]

I wrote a Shelly driver for a completely different (and obsolete) automation system based on the MQTT communication interface, and quickly found that compared to CoIoT, it is very much a second class citizen. Many thing missing, and notifications that can't be disabled. Have you considered moving to CoIoT, now that the interface definition upheaval has settled out?

[Michael McSharry]

I looked at COAP in the past and did not find the advantage you allude to. It's premise is that the widget has a stable connection which is often not the case of Wifi and battery operated hosts. It is also command-response oriented rather than event oriented. What advantages to you see with the Shelly implementation of COAP?

[popeye]

You should get on/off button/input notifications. But yes, I ended up doing mqtt as well, though it is frustrating.

- Duplicate legacy notifications. I do a subscribe to "shellies/+/+/#" just to cut down on the crud.
- Button type is not included in the device info sent by mqtt, and so has to be queried through http. To check for changes, you have to end up polling. This setting is critical to know for correctly interpreting button/input notifications.
- The iX3 I believe it was, and I can't remember which else, sends updates on all inputs when one changes.
- Energy/Power notifications come in 30 second intervals, even if nothing has changed (like when zero), rather than when an actual change occurs. Plus they all come at the exact same time, on the minute and 30 second mark. This is fine for 20, 30, 40 devices, but annoying for 150 devices. And turning off periodic updates does not turn this off.
- Button/Input notifications are not at all uniform between devices. Like for the iX3, making sure the representation of the input has reset before setting it again. And the iX3 in toggle mode, you have to emulate the set/press event, as it just does not send them. For the 2.5 in Roller mode, or if the button is in Toggle/Edge/Activation/Cycle modes you also have to emulate the press event. At least if you want to provide a consistent set of events for the user. For some devices & modes getting a new input status signifies any old press/set should be released. And doing a button Hold on some devices for too long just times out.
- If inputs are already set at device power up, you will get a release with no previous set.

Anyway, you likely ran into all this. My Uni's are finally arriving, so we shall see what surprises they hold.