Shelly 2.5 + mqtt configuration

masip85 · December 9, 2019, 6:50pm

Hello

I am sorry. I’ve reading all forum post about shelly 2.5 and mqtt and I cannot find the reason it doesn’t work. I’ve configure mqtt mosquito. In this place I have the first doubt:

First I configure hass.io user. I use same user and password than the one I provide from shelly mqtt configuration :“mqtttuser”. If I stay here, I obtain this at the mosquito log:

[19:00:39] INFO: Setup mosquitto configuration
[19:00:39] WARNING: SSL not enabled - No valid certs found!
[19:00:39] INFO: No local user available
[19:00:40] INFO: Initialize Hass.io Add-on services
[19:00:40] INFO: Initialize Home Assistant discovery
[19:00:40] INFO: Start Mosquitto daemon
1575914440: mosquitto version 1.6.3 starting
1575914440: Config loaded from /etc/mosquitto.conf.
1575914440: Loading plugin: /usr/share/mosquitto/auth-plug.so
1575914440: |-- *** auth-plug: startup
1575914440: ├── Username/password checking enabled.
1575914440: ├── TLS-PSK checking enabled.
1575914440: └── Extended authentication not enabled.
1575914440: Opening ipv4 listen socket on port 1883.
1575914440: Opening ipv6 listen socket on port 1883.
1575914440: Opening websockets listen socket on port 1884.
1575914440: Warning: Mosquitto should not be run as root/administrator.
1575914478: New connection from 192.168.1.150 on port 1883.
[INFO] found mqttuser on Home Assistant
1575914480: New client connected from 192.168.1.150 as shellyswitch25-688B61 (p2, c1, k60, u’mqttuser’).

Then, the mosquito instructions says, to configure as a broker:“To use the Mosquitto as a broker, go to the integration page and install the configuration with one click:”
Here my complete lack of knowledge of mqtt and broker meaning, makes me wonder… configure it as a broker is an option? a second step? Well, I take my chances and keep configuring it as mosquitto says -> Configure mqtt broker in integrations. This way:

port: 1883
user: mqttuser (YES,I use the same I user previously for hassio user)
pass: *** (the same as shelly config, and new hass ios mqttuser)```

then , the log:
1575915853: New connection from 192.168.1.150 on port 1883.
[INFO] found mqttuser on Home Assistant
1575915854: New client connected from 192.168.1.150 as shellyswitch25-688B61 (p2, c1, k60, u’mqttuser’).
1575915914: New connection from 192.168.1.70 on port 1883.
1575915914: New client connected from 192.168.1.70 as auto-6EFAA258-BCA6-3C65-07C7-7BC772AB94EC (p2, c1, k60, u’mqttuser’).

Seems ok,isn’t it? Am I doing something wrong? Because with this configuration template:

default_config:


tts:
  - platform: google_translate

group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

cover:
  - platform: mqtt
    name: "Persiana Cocina"
    state_topic: "shellies/shellyswitch25-688B61/roller/0"
    command_topic: "shellies/shellyswitch25-688B61/roller/0/command"
    position_topic: "shellies/shellyswitch25-688B61/roller/0/pos"
    set_position_topic: "shellies/shellyswitch25-688B61/roller/0/command/pos"
    #availability_topic: "shellies/shellyswitch25-688B61/online"
    payload_available: "true"
    payload_not_available: "false"
    qos: 1
    retain: false
    payload_open: "open"
    payload_close: "close"
    payload_stop: "stop"
    position_open: 100
    position_closed: 0
    optimistic: false

and this configuration topic at shelly:
shellies/shellyswitch25-688B61/roller

the button area appears (without tilt), and doesn’t work at all. I’ve been reading about this a lot, and I still don’t figure it out.

Neptuno15 · December 10, 2019, 9:47am

Hi Vicente
I have same problem with shelly 2.5 roller. I fix it like this: If you acces to your shelly by their ip address and the go to internet and security tab, then ADVANCED - DEVELOPER SETTINGS, try to enter again your MQTT password. This work for mi setup.
JC

masip85 · December 10, 2019, 6:33pm

Tried. Nothing changed, but thanks anyway

giannella · January 25, 2020, 6:46pm

Hi, Did you find a solution? I have the same issue.

thanks,

masip85 · January 30, 2020, 10:39pm

Shelly 2.5 is fully working!!!

The fact is, any tutorial I had found is outdated, because after last firmware updates, some minor changes in mqtt paths have been done. If you want to get the last, just check here:
https://shelly-api-docs.shelly.cloud/#shelly2-5-relay-index

The main issue, in my case, is that I was using custom mqtt topic paths.When, in fact, what you need to realize is that part of the path is going to be added automatically.
When configured to operate in roller mode, MQTT topics used by Shelly2.5 are:

shellies/shellyswitch-<deviceid>/roller/0 reports the current state: open or close while in motion, stop when not moving
shellies/shellyswitch-<deviceid>/roller/0/command accepts rc (performs roller calibration), open , close and stop

For position control to work the device must be successfully calibrated, so that the time it takes for closing and opening are known.

shellies/shellyswitch-<deviceid>/roller/0/pos reports the current position in percent
shellies/shellyswitch-<deviceid>/roller/0/command/pos accepts a number between 0 and 100, which is the target position in percent

In my example, here is what I use in shelly config:

Custom MQTT prefix:
Use custom MQTT prefix <- Unchecked

And in configuration.yaml:

cover:
  - platform: mqtt
    name: "Persiana"
    state_topic: "shellies/shellyswitch25-688B61/roller/0"
    command_topic: "shellies/shellyswitch25-688B61/roller/0/command"
    position_topic: "shellies/shellyswitch25-688B61/roller/0/pos"
    set_position_topic: "shellies/shellyswitch25-688B61/roller/0/command/pos"
    #availability_topic: "shellies/shellyswitch25-688B61/online"
    payload_available: "true"
    payload_not_available: "false"
    qos: 1
    retain: false
    payload_open: "open"
    payload_close: "close"
    payload_stop: "stop"
    position_open: 100
    position_closed: 0
    optimistic: false

jytremblay · February 12, 2020, 2:52am

Thanks you!
I had the same problem, Unchecked MQTT prefix fix it.

Guesswho620 · September 29, 2021, 1:31pm

Dear Anyone, who is banging his head into the wall why Shelly Shutter is not working over MQTT after reading EVERY possible tutorial and topic:

After enabling MQTT in the Shelly device admin page, please do yourself a favour, and REBOOT YOUR SHELLY device.

I spent hours trying to find out why wouldn’t my little shelly device connect to my broker, and as a last resort I rebooted the shelly device, et voilà, bamm: shelly messages started to flow in.

Edit: wanted to mention my specific usecase: I’m going to use BOTH native shelly integration and MQTT, because I need to intercept phyisical button presses into my sun azimuth based cover automation (covers are going up and down based on Sun’s position), to introduce the Wife Factor into the equation (so my wife doesn’t kill me when she sets the cover to a certain position against my well computed sun based position, it will not stay there, aka: human override possibility of the automation).
My Shellys are used in momentary button setting, and with the shelly integration intercepting the short button presses - which are enough for the device to roll them up completely - is impossible. The button press is simply not long enough to be detected via the API, and I can’t force everyone in the family to press the button a tad longer. So I’m hoping to catch button presses via mqtt messages and binary sensors. Fingers crossed, I report back later.

UPDATE : done with button input mqtt integration, and it’s freaking INSTANT!! Awesome!! No lag at all,binary sensor reporting button state change within milliseconds.
If anyone wants to use physical button press state in any kind of cover automation, take the MQTT route. It’s Fantastic.

g-nogueira · December 20, 2021, 8:35pm

If anyone wanders by this thread, the following is my configuration seemingly working and the only missing feature is the correct state of “open” and “closed”. Currently, it is always considered open, closing, or opening. It cannot detect the closed state.

cover:
  - platform: mqtt
    name: "Livingroom Shutter"
    state_topic: shellies/livingroom/static/cover/shutter/roller/0
    state_open: "stop"
    state_closed: "stop"
    state_opening: "open"
    state_closing: "close"
    set_position_topic: shellies/livingroom/static/cover/shutter/roller/0/command/pos
    position_topic: shellies/livingroom/static/cover/shutter/roller/0/pos
    position_open: 100
    position_closed: 0
    command_topic: shellies/livingroom/static/cover/shutter/roller/0/command
    payload_open: "open"
    payload_close: "close"
    payload_stop: "stop"
    availability_topic: "shellies/livingroom/static/cover/shutter/online"
    payload_available: "true"
    payload_not_available: "false"
    retain: false

Phil5 · September 24, 2022, 1:16am

Just wondered about the same while configuring a Shelly 2.5 as a cover.

After bit of trial and error and a deep look into the manuals, this is why you don’t see the closed state, @g-nogueira:

Shellies are not reporting the open and close state. They are reporting “open” while opening, “close” while closing and stop when stopped in any position (closed, opened, or a percentage position)

This behavior matches a cover which is only reporting 3 states from the MQTT Cover manual.
You can refer to this behavior by configuring state_stop: “stop” (which you do)

In that configuration the position_topic would be used to check if state_stopped refers to state_open or state_closed based on the position value.

The payload_stop does not work properly, because you have configured state_open: "stop".
But just removing state_open from the config will not help either. This will default to state_open: “open” which happens to be the state which Shelly is using while opening.

To workaround this, just use a content that is never used by shelly. state_open: "fake" works, but I’ll call it state_open: "opened" in my example.

for the sake of consistency and readability, you can also configure state_closed: "closed", but that’s the default anyway and is not interfering with Shelly “close” for closing.
(your config wrongly uses state_closed: "stop")
Just to mention an additional learning on my end: A HA Cover does not have an intermediate state like “pause” or “stopped”. Whenever the position is not at 0%, the cover is considered open.

Working example which will detect the closed state:

mqtt:
  cover:
    - unique_id: "mqtt_s25_cover"
      name: "Leinwand"
      qos: 1
      #retain: true
      command_topic: "shellies/shellyswitch25-XXXXXXXXXXXX/roller/0/command"
      payload_open: "open"
      payload_close: "close"
      payload_stop: "stop"
      
      state_topic: "shellies/shellyswitch25-XXXXXXXXXXXX/roller/0"
      state_opening: "open"
      state_open: "opened" #won't be reported from Shelly, but at least it deviates from open
      state_closing: "close"
      state_closed: "closed" #won't reported from Shelly, but at least it deviates from close

      #needs to be configured to rely on position if stopped:
      state_stopped: "stop"
      
      availability_topic: "shellies/shellyswitch25-XXXXXXXXXXXX/online"
      payload_available: "true"
      payload_not_available: "false"

      position_topic: "shellies/shellyswitch25-XXXXXXXXXXXX/roller/0/pos"

      set_position_topic: "shellies/shellyswitch25-XXXXXXXXXXXX/roller/0/command/pos"

      optimistic: false