Hi all!
Does the Shelly integration support connection directly without cloud?
Yes it does
I have been using Shelly 1 and Shelly 2.5 for several months via mqtt and it has worked very well. Curious if anyone has any opinions on shifting from mqtt to the direct integration?
I had a Shelly 1 working via MQTT. Yesterday I reset it, I added again to the app, activated Cloud services, I configured Alexa and Google Home without any problem. Then I tried to use the new Shelly Integration. First I got errors in log complaining about some string so I I changed the device name from Shelly1 to ShellyOne and I got no errors in log. But no device discovered (I expect a switch in this case) even if it is on the same Wifi Network. Tried many time to reboot both device and HA, but no success. Then I tried to start integration manually, when asked being for host I typed the IP number of the device and I got the message: Aborted, Device is already configured
Am I doing something wrong or this integration it is not working ?
I did not reset my Shelly devices. I just added then new Shelly integration (and kept the Shelly’s reporting via MQTT). I have never activated the cloud service. My understanding of the new integration is that it uses the local API so the cloud service is not required.
All of the devices were discovered and appear to work fine. I am still using MQTT but I am continuing to test the integration for longer term stability before moving away from MQTT. I have not found a compelling reason to go away from MQTT at this point. The only current reason I can think of is the lack inability to use the cloud when MQTT is enabled. Given that I don’t want to use the cloud, this is not a reason to change. Granted that setup of new devices would be easier using the integration as I now have to use a Shelly discovery service to simplify using MQTT, but until I actually start adding more Shelly devices, this is not a reason to change.
I am interested if anyone else has come up with reasons to switch from MQTT to Integration?
1 Like
No reason to switch, but I think there might be a good reason to stick with mqtt.
With mqtt new values are pushed out to the broker as they occur. However I think the API (rest) method is polled on a fixed interval. I could be wrong.
just to be clear: having the Shelly on the cloud give me the possibility to control them also via Google and Alexa which is useful. My problem is trying to understand what does it mean that the device “is already configured”. I simply do not find any new device related to my ShellyOne, so I do not know how to use it.
When I search in my entities listing for “shelly” I find the MQTT versions and the Shelly Versions all show up (the integration column shows which integration the entity belongs to). I configured vi the UI integration (no entry in configuration.yaml). The integration “discovered” my devices and provides the entities.
I use the integration ShellyForHass since couples of months. Without MQTT.
So I don’t see any reason to change.
Integration via mqtt is better architecture wise. It’s easier to maintain/migrate. It’s faster, more optimal resources wise.
On the other hand ShellyForHass makes initial configuration easier. Question is what flexibility it offers when stepping out from default use cases is needed.
I’m curious about those points.
I’ve never used Shelly with MQTT but as I use MQTT for many other things I’m thinking about switching my Shelly integration to MQTT also.
What do you mean by better architecture ? And what do you mean by faster and more efficient ? Is it theoretical or real and measurable ? 
I’ve not checked Shelly MQTT integration yet. I might try it.
Architecture discipline propose some patterns which have been estabilished to be optimal for particular use cases. Separated components with limited responsibility, optimized data flow - all are applicable here. In most cases polling is considered as suboptimal but offers simplicity of implementation, that’s why used pretty widely.
Separate components provide better relibiality, better scalling or easier maintanance.
You can restart those services separatelly. Migrations are easier, more transparent for surroundings allowing shorter outages (you don’t need to migrate all at once, you can restart part of systems not impacting the rest)
Devices push messages immediately causing broker (mqtt) immediatelly informing listener(s) about it. Yes: one message sent can be received by multiple clients (ie HA and NodeRed). In case of polling you multiply communication with adding additional receivers.
Also with components separation you can play with each ones API separatelly, maximazing usage of component. With build-in Hass component, you are dependent on the last API in the chain exposed to you (ie GUI). It might turn into less flexible solution usage-wise.
Regarding reaction time: with polling there is a delay which reach pooling time. You can increase pooling frequency… but then you are waisting resources (computing, data etc) asking device for its status even if there was no change. We can agree that it might be insignificant impact even for 1000 smart home devices. But still… it remains suboptimal.
With messaging the messages are being sent once and received once when happen.
Polling has one another disadvantage. It retrieves most recent device state. Some device states might be not recorded (by HA) if state is changing too fast comparing to polling time. It might be crucial if you building some automations on tom of it (ie tracking number of button presses in short timespan).
I suppose there might be other reasons why using mqtt is better than polling.
But Hass integration has its pros too. Is a part of HA (doesn’t require to instal mqtt broker), Devices/entities configuration is pretty effort-less.
Hope it helps a bit.
2 Likes
Thank you very much for this very complete and informative answer.
I did not realize ShellyForHass relied only on polling. But that makes sense now you tell me. I did not configure anything about HA in my Shelly devices and I don’t think Shelly devices are planned to have an established connexion with a third-party software, so I guess that means HA has to poll each devices indeed.
Tanks for pointing this out.
I will try to implement MQTT on one of my Shelly devices to test.
Check your core.config_entries file. you probably have ignore the device in the past.
simply remove this entry and reboot.
I’m about to test mqtt. I have enabled mqtt on some Shelly devices. But isn’t there a way do discover them by automatic? Right now I have to create sensors and switches by yaml. I have enabled the discover function in my config.
No in native form. You can use Shelly autodiscovery script by Bieniu.
However depending on your needs this feature might bring limitations and annoyances. Especially if you want to step out of default mqtt/entities names. renaming/removing discovered entities is far more counterintuitive than gain from autodiscovery itself.
Maybe it got improved since when I tested it. But personally I found manual configuration in yaml more flexible. Today (since v0.115) you don’t even need a HA reboot to apply changes to mqtt entities.
But as I said, it’s matter of your expectations.
Ok, thank’s for the reply. At start, with the manually configuration of Shelly by MQTT I saw a lot of job ahead of me but now when I got the plug, dimmer and switch to work as it should, I will go that route.
My thinking is to go with the same id so my automation scripts don’t have to be changed. Enable MQTT at the device, add as MQTT in the configuration, test it out, remove the old ShellyForHass.
Hi,
I have a problem with Shelly integration. Works well until the Shelly device accessable…
My Shelly device sometimes drop the Wifi connection for a few sec. As a result in HA, the device goes to unreachable State. It only comes back when I restart HA.
Any suggestion to reconnect the device without HA restart?
Thanks!
I remember reading somewhere that this may have been related to a particilar firmware / version of HA.
Check that you have the latest of both.
Shelly firmware up to date. HA update 0.115.6 to 0.116.2. We’ll see…
Thanks.
1 Like