I have a preliminary test version of the Shelly driver I’m making available on my test channel here:
Caveats:
- Limited communication retries for now, so if device doesn’t respond after two attempts, it gives up.
- 1, 1PM, 2.5 relay, 2.5 roller, and Motion devices can be created; all others will result in a ‘not implemented’ message
- No temperature add-on support for 1 and 1PM …yet!
- NO actual testing has been done other than on the motion sensor, so don’t expect miracles!
- Regarding above, CLI logging output will be necessary to see where the problems are
Instructions
- Perform an Add device / Scan nearby and a new device will be created in your ‘No room assigned’ room called ‘Shelly Device Creator’.
- Go to the new creator device’s details page and tap the button ‘Select Device Type to Create’ and select one of the implemented device types. You’ll get a message that the device was created, or ‘not implemented’
- Find the new device in your ‘No room assigned’ room and go into device settings by clicking on the 3 vertical dot menu in the upper right of the device details screen.
Each device will have a field to provide the IP address of the Shelly device. Once you enter it, the driver will attempt to get status from the device. - Return to the device details screen to see if the various fields have been initialized with what looks like valid data. If nothing seems to be getting filled in, then getting status from the device probably failed. To force a retry, go back to settings and set the IP address to something else and press OK. Wait 10 seconds then change the IP address back to the correct one. Check the details screen again.
Feedback needed
Obviously anything you can provide is welcome, but here are some specific things that will need decisions:
- For the relay-type devices, is it valuable to include a contact in addition to a switch? Another option might be to include the contact so it is available to automation routines, but not display it on the device details screen, since it’s redundant information.
- How do you like/dislike the multi-component aspect of the 2.5 devices? The earlier posts on this topic raise some interesting issues regarding other applications being able to access secondary components. Is this an issue for you? For the 2.5, it is only a matter of the second relay and associated energy info.
- Regarding energy: in order to maintain a current value for total energy, there would have to be polling out to the device on some frequency. This is not yet implemented - the values are updated only when an action is sent or received.
- Some of the Shelly devices have quite a number of configuration options. I did not try to reproduce those in this driver, but rather for now I’ve stuck with what I considered to be the primary function. Philosophically, I think it would be best to use the Shelly app to do ‘deep’ configuration of the device, but let me know what you all think. If there are any key things that seem to be missing that are important to you, let me know what they are.
- I’m not quite sure of the 2.5 roller functionality, so I had to make some assumptions there. The API doesn’t clearly distinguish, for example, between ‘closing’ and ‘closed’ or ‘opening’ and ‘opened’ when it comes to the state. However the position is available and I use it to set the shade level. I fully expect there’s some more work needed to get this working correctly.
Let me know what you think!