+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.
Using MQTT ?
Thanks gbuico, after reading your post I spent more time looking at the default integration and am realising why I am having so many issues.
Would you be able to share your MQTT configuration for a Shelly device and the associated sensor?
I’ve got my MQTT broker running for my sonoff devices, just not sure how to configure it for Shelly
Update: I tried Shelly for HASS, after reading others experiences. Installed it via HACS, it immediacy discovered by Shelly devices and has a sensor for the detached switches running on my Shelly 1PM.
I also tested the speed, immediate. The detached reed switch instantly updates as does the device status.
I’ll convert it into a cover (for the aesthetics in HASS) and my garage door controller is done! I’ll probably skip MQTT looking at how much manual configuration is required for the moment.
Sure… check my answer to mitch which includes configuration from my HA
If you are ok with the integration you better continue that way.
Same thing on my side… I worked a lot so far and I have no time to review everything without added value.
Just for the sake of sharing… here is a sample of a Shelly 1 definition in my config.yaml
This is the Shelly 1 as device with detached SW:
binary_sensor:
- platform: mqtt
name: "Garage 1 Magnetic Contact"
state_topic: "shellies/shelly1-012345678901/input/0"
payload_on: "0"
payload_off: "1"
qos: 0
unique_id: mqttbs01
switch:
- platform: mqtt
name: "House Garage"
state_topic: "shellies/shelly1-012345678901/relay/0"
command_topic: "shellies/shelly1-012345678901/relay/0/command"
availability_topic: "shellies/shelly1-012345678901/online"
payload_available: "true"
payload_not_available: "false"
qos: 0
payload_on: "on"
payload_off: "off"
retain: false
unique_id: mqttsw02
Definition for the same device allowing status monitoring:
sensor:
- platform: mqtt
name: "Shelly 1BT Garage 1 CurFW"
state_topic: "shellies/shelly1-012345678901/info"
value_template: "{{ value_json['update']['old_version'].split('/')[1] }}"
icon: mdi:check-decagram
- platform: mqtt
name: "Shelly 1BT Garage 1 NewFW"
state_topic: "shellies/shelly1-012345678901/info"
value_template: "{{ value_json['update']['new_version'].split('/')[1] }}"
icon: mdi:new-box
- platform: mqtt
name: "Shelly 1BT Garage 1 FWupdate"
state_topic: "shellies/shelly1-012345678901/info"
value_template: "{{ value_json['update']['has_update'] }}"
- platform: mqtt
name: "Shelly 1BT Garage 1 IP"
state_topic: "shellies/shelly1-012345678901/info"
value_template: "{{ value_json['wifi_sta']['ip'] }}"
Hope this can help someone
2 Likes
Strangely I couldn’t get anything on the /info topic.
Shelly docs point to /announce topic which works for me.
Regardless, thanks for pointing me in the right direction 
Whaaaaaaat !!?
I just read that I can trigger a mass firmware update by publishing update_fw to shellies/command
Thats’ going to save some time.
It pays to read the instructions eh !
Glad to have shared something interesting.
Let me add a couple of suggestions:
Depending on your installation you may miss an announce after a restart or for some other reason.
In my installation I added these two automations issuing an announce command after a HA restart and, anyway, at 5am evry day
- id: '1621181848759'
alias: Shelly MQTT Restart Fix
description: ''
trigger:
- event: start
platform: homeassistant
condition: []
action:
- service: mqtt.publish
data:
topic: shellies/command
payload: announce
mode: single
- id: '1621194818678'
alias: Shelly MQTT Daily
description: ''
trigger:
- platform: time
at: 05:00:00
condition: []
action:
- service: mqtt.publish
data:
topic: shellies/command
payload: announce
mode: single
type or paste code here
Another suggestion is to install MQTT Explorer, a freeware that allows you to visualise the MQTT traffic and also to issue (and test) MQTT commands.
I did not implement the mass upgrade in HA because I like more to deploy it gradually, but, when needed, I used MQTT Explorer to trigger the mass upgrade
1 Like
I know this is a little old. But, to the detached switch mode, if you look at the entities for your shelly you will see the integration automatically disables most of the available entities. If you view the disabled entities you can re-enable the binary_sensor input entity to get the status of your reed switch on the SW port (assuming the detached mode is for something like a garage door where a reed switch is used to show open/close status).
What’s the overall opinion on this “custom vs. official Shelly integration” thing?
I’m still with the custom one but I
- have an issue (made by my own) https://github.com/StyraHem/ShellyForHASS/issues/696
- fear issues (see few of them currently already) with updating to HA 2022.7 as Python 3.10 is now used and there are many open issues related to this like
So I was thinking of finally switching to the official integration. But I don’t want to loose all my history. And how to migrate?
- Remove custom integration
- Use official one
- Change entity IDs to the ones used like before with the custom integration
Is it that easy? Any experiences of users already migrated?
Is there a feature comparison table?
-
provide switch entity -
provide sensor “over power”
-
provide sensor “over temperature”
-
provide sensor “device temperature”
-
provide sensor “current consumption”
-
provide sensor “total consumption”
-
allow to update device firmware directly from HA (update switch entity or similar)
That’s my basic requirement list based on what I know from ShellyForHASS custom integration.
Recently I moved all my Shelly devices to official integration due to growing number of unresolved issues on the ShellyForHass addon (one of them blocked me from updating to new version of S4H). It was a bit of manual work but in long term it is worth the step.
The process is exactly as you wrote (remove S4H, restart, setup new devices, change ids). There is no automatic migration. But if you change ids to old ones you will have the history.
And to all your question marks the answer is yes.
1 Like
Great news! Thanks for sharing. So just to make myself 100 % migration confident:
- all entities you had before now exist too (including the update switches/entities - once there‘s an update available)?
- you did not loose any history because removing the integration did not delete the entities, right?
I have 10 Shellies - types 1, 1PM, 2.5 and 3EM and all of them have update available sensor and update firmware button.
I keep a history of default 10 days and all is there. The only interval you lose is time after the removal of S4H up to the change of ids to the old ones. The transfer took me one hour or so.
1 Like
@Rossez How exactly did you remove S4H (step-by-step)?
For me I cannot remove it from HACS, see:
Looks like I need to manually remove it. Looking for help at HACS - Cannot Remove Integration - #9 by e-raser for now. Feel free to assist if you can.
Update: With HA Core >= 2022.7.7 the remove button in HACS is working again (HACS still v1.26.2).
Update: Migration finished.
- One of the best decisions ever made when it comes to stability.
- Absolutely no lack of features, some things (attributes, updates etc.) are just a bit different.
- Not missing any historic data except for the migration downtime itself (roughly one hour).
Summary: I see absolutely no reasons for staying with the custom Shelly integration - except fearing the migration work itself maybe. It hurts once a bit depending on the amount of devices - but resolves so many (unresolved) issues and feels just good to drive the default highway now.
1 Like
It is necessary to change the IDs from the UI, or from some configuration files?
Also, it is necessary to change the entity ID, or the unique ID?