Hi,
So Shelly has now a proper official integration in HA.
Currently I was using ShellyForHass custom components from HACS: does anyone know if it is suggested to migrate to the new integration and how to do it?
2 Likes
Also very keen to get peoples thoughts on this
I also looked into it, but I see very little documentation and the support seems to be limited to a few devices. I think I’ll wait for a few weeks. Don’t fix what isn’t broken 
Hello I just tried to switch my shelly2.5 (used as double relay) from mqtt integration to the new one offered natively by HA.
It works but I’ve noticed that is slower than mqtt.
Does somebody knows as the new HA integration works?
For sure it does not use mqtt since I have disabled it from the shelly device and from HA.
So maybe is using http protocol.
It’s a matter of fact that with mqtt the activation is almost immediate while with HA integration some latency is noticeable.
Ignazio
Can I ask what entities were exposed with the 2.5 ?
Out of curiosity I connected a shelly 1 via the integration and only the relay was exposed as an entity.
Maybe this is just a first step and other entities will be exposed as the integration develops.
On shelly 2.5 i have:
2 swithces
1 Temperature sensor
1 Overtemperature sensor
2 energy sensor
2 power sensor
2 Overpower sensors
I switched from MQTT to the official integration and while it works, the Shellies also become unavailable from time to time, forcing me to reload the integration manually.
The devices in question are all hard wired (not battery powered) and the problem seems to occur when they for whatever reason reconnect to wifi after a brief dropout.
Hello all, maybe a stupid question, however can someone tell me which credentials I have to fill in at the homescreen of the new Shelly integration?
See the screenshot for extra information.
Thanks
This screen looks strange… never had a look like this, maybe mobile app specific?
With this new Version, is it still possible to configure the shellies over the configuration.yaml? I really liked this way in the ShellyForHass, because I can select sensors for each shelly as wished.
I hope it will be configurable again some point (or maybe it is already but lacking the documentation to do it?)
I used something like this, would that work for the new one as well? or with minor changes?
shelly:
host_ip: !secret HomeAssistant_IP
discovery: false
username: !secret Shelly_User
password: !secret Shelly_Password
sensors: #general setting for all devices
- current_consumption
- total_consumption
- rssi
attributes: #general setting for all devices
- ip_address
- shelly_type
- shelly_id
- rssi
- has_firmware_update
- cloud_status
- switch
devices: #devices to be added
- id: "the ID of the shelly..."
name: Shellytest
light_switch: true
...
The point of the GUI integrations is that you DONT need to edit yaml.
On the upside, we’re not forced to use the new integration. Personally I’m still using MQTT for all my Shellies.
Absolutely agree that it’s perfect that we have the choice as well!
However I disagree that GUI integrations are better in every situation. They are mostly just easier understandable for the simple user who wants to do one single setup for himself.
Some advantages of configuration.yaml:
-> Easier transferrable from device to device
-> Build up of a standard config for sharing
I’m sure there is more.
Which is why I’m not using the integration in its current state.
Well, my 2 cents.
I have several Shelly 1 and Shelly 2.5 and I se them in HA using MQTT.
I was obviously glad to see the new integration and I decided to give it a try with a spare 1 and a spare 2.5
So far what I found is the following:
2.5 : I use them to control rolling shutters. The integrations adds a cover for the open/close/stop buttons and a binary switch for overtemperature. A third entity (actual temperature is added but disabled)
While using them I loved the fact that when the shutters are moving a directional arrow appears as status icon to represent the direction of the movement,
This is the only plus compared to my MQTT implementation
The delay between a manual activity and the update of HA GUI is about 1 second, much much slower than the one seen with MQTT.
1 : I immediatly tested my most complicated usage of Shelly 1, meaning when the Switch is “detached”. Big delusion. Only one entity is added to HA to control the relay… no trace of the SW status… and this is for me a showstopper.
As already said the connection between Shelly and HA is direct but must be done with a sort of network polling so we can’t expect to have the same reaction time of the MQTT solution… unless there si a rabbit in the hat in one of the next releases.
Side comment. If I cut the electricity to these Shelly they become unavailable… this is ok… but thy remain unavailable if you don’t do a Restart or disable/enable the device. There is already a bug report open and several people reporting the same issue.
Bottom line… good to ave a native integration but too young to even think of migrating
Btw, is there a formal way to submit issues related to this integration?
Giacomo
+1 on the on detached mode. Have you raised an issue yet?
Shelly firmware allows configuration of http requests for specific events like long press of second switch. Theoretically this can be used for avoiding polling over http. Any idea?
Comparison with ShellyForHass?
1 Like
I was using the REST methon in the configutaion.yaml file, but found the integration.
I was able to add two of my four units thus far. For the other two units, the Shelly Integration keeps reporting " Aborted, Device is already configured ". However, it is NOT. Only the two units show up and the other two refuse to be added reporting the error above??
Where does the integration keep this information?
FOUND where Shelly configurations are hiding …
Using windows File Explorer I went to: \\your.ip.addrees.here\config\.storage
Here you will find a file named: core.config_entries
Once opened in your favorite editor, I use notepad++, you can search for the IP address of the Shelly that refuses to be added by the integration.
{
"entry_id": "ent ID here....",
"version": 1,
"domain": "shelly",
"title": "Ignored",
"data": {
"host": "192.168.1.132"
},
"options": {},
"system_options": {
"disable_new_entities": false
},
"source": "ignore",
"connection_class": "local_poll",
"unique_id": "shellyuniqueidhere"
},
You will note the two entries that have “ignored” and “ignore”. Not sure how that happen.
All I did was delete this section from { to }, and now I could add it using the Shelly Integration.
Hey, did you manage to solve how this works as a detached sensor? I’ve just installed a Shelly 1 with the exact same setup and I can’t see the sensor state in HASS (confirming working as expected in the Shelly app)
No, @mitch , I never tried again the integration because I’m very happy interacting with them via MQTT.
At the moment I have several Shelly 1, Shelly 2.5, Shelly RGBW2, and Shelly i3 in my house and I never had a problem.
In addition to the normal operation setting, I defined additional sensors for each of them in order to monitor their status, the availability of new firmware etc.