OH3 MQTT Tasmota Shelly 2.5 Rollershutter

Setup, Configuration and Use Items & Sitemaps
1
  • Platform information:
    • Hardware: RasPi 3, deconz ZigBee Module
    • OS: Linux openhabian 5.10.17-v7+ #1403 SMP armv7l GNU/Linux
    • Java Runtime Environment: which java platform is used and what version
      openjdk 11.0.11 2021-04-20 LTS
      OpenJDK Runtime Environment Zulu11.48+21-CA (build 11.0.11+9-LTS)
      OpenJDK Client VM Zulu11.48+21-CA (build 11.0.11+9-LTS, mixed mode)
    • openHAB version: openhabian 5.10.17-v7+ #1403 SMP
      Apps: mosquitto
  • Issue of the topic:
    Openhabian is running. OH3 is installed and working. I can switch lights, change colour and so on. II’m also able to switch ZigBee-Lights via deconz (but not shure whether my setup is best practise) Connection to mosquitto ist working: I can switch on/off two Tecin double plugs flashed with Tasmota.

I set up a testing environment with a Shelly 2.5 flashed with Tasmota. “Testing enviroment” means the Shelly has power and is connected to the WiFi. The Shelly is configured as rollershutter and works like this (as far as I can determine). I did the configuration with the Webinterface console of Tasmota. The Shelly therefore has good connection to the WiFi. I can hear the switching sounds of the relay when clicking the buttons in the webinterface.
I created a new MQTT Generic Thing as rollershutter and a channel (RL-CZ). Clicking on the buttons show MQTT-commands in MQTTfx. Payloads are “O” for open, “G” for closed, “S” for stop. LWT is working and tele/stat-messages are received by MQTTfx.
But the Shelly doesn’t switch.
So, how do I set up OH3 (or mosquitto, or Tasmota) that it’ll recognizes “G”, “O”, “S” and reacts accordingly?

  • Please post configurations (if applicable):
    • Items configuration related to the issue: All generic except the name
    • Sitemap configuration related to the issue: not that I’m aware of any changes.
    • Rules code related to the issue: not that I’m aware of any changes.
    • Services configuration related to the issue: not that I’m aware of any changes.
  • If logs where generated please post these here using code fences:

openhab.log

2021-05-21 16:44:14.977 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to 'localhost'. Next attempt in 60000ms
2021-05-21 16:44:14.984 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid 0ff7ceed-8909-4b37-ad9f-a763fe8bb7c5
2021-05-21 16:45:14.986 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to 'localhost'. Next attempt in 60000ms
2021-05-21 16:45:14.994 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid 0ff7ceed-8909-4b37-ad9f-a763fe8bb7c5
2021-05-21 16:46:14.996 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to 'localhost'. Next attempt in 60000ms
2021-05-21 16:46:15.005 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid 0ff7ceed-8909-4b37-ad9f-a763fe8bb7c5
2021-05-21 16:47:15.007 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to 'localhost'. Next attempt in 60000ms
2021-05-21 16:47:15.016 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid 0ff7ceed-8909-4b37-ad9f-a763fe8bb7c5
2021-05-21 16:48:15.018 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to 'localhost'. Next attempt in 60000ms
2021-05-21 16:48:15.026 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid 0ff7ceed-8909-4b37-ad9f-a763fe8bb7c5
2021-05-21 16:49:15.029 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to 'localhost'. Next attempt in 60000ms
2021-05-21 16:49:15.037 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid 0ff7ceed-8909-4b37-ad9f-a763fe8bb7c5
2021-05-21 16:50:15.040 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to 'localhost'. Next attempt in 60000ms
2021-05-21 16:50:15.048 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid 0ff7ceed-8909-4b37-ad9f-a763fe8bb7c5
2021-05-21 16:51:15.050 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to 'localhost'. Next attempt in 60000ms
2021-05-21 16:51:15.057 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid 0ff7ceed-8909-4b37-ad9f-a763fe8bb7c5
2021-05-21 16:52:15.060 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to 'localhost'. Next attempt in 60000ms
2021-05-21 16:52:15.068 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid 0ff7ceed-8909-4b37-ad9f-a763fe8bb7c5
2021-05-21 16:53:15.071 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to 'localhost'. Next attempt in 60000ms
2021-05-21 16:53:15.079 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid 0ff7ceed-8909-4b37-ad9f-a763fe8bb7c5
2021-05-21 16:54:15.086 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to 'localhost'. Next attempt in 60000ms
2021-05-21 16:54:15.095 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid 0ff7ceed-8909-4b37-ad9f-a763fe8bb7c5

Disconnects seem to be a little bit often. But the Tecin/Tasmota plug sockets are working and are switchable.

2

Yes, it’s not related to rollershutter particularly. Usually means you have an unwanted System Broker thing configured, in addition to the one required broker.

We can’t see any of that from here.

3

Why are you flashing a shelly with Tasmota ???
Shelly has native MQTT support.
There is an official Shelly Binding with autodiscovery.
No need for flashing.

4

Shelly updates needs internet connection to Shelly. For obvious reasons I don’t like having my IoT connected to the outside world. Tasmotas can be updated via a file from the “inside”.

5

Thanks!
I deleted the second broker. The reconnects occure less often (as long as I only run MQTT Explorer and not MQTTfx at the same time):

2021-05-21 18:57:16.504 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to 'localhost'. Next attempt in 60000ms
2021-05-21 18:57:16.513 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid 0ff7ceed-8909-4b37-ad9f-a763fe8bb7c5
2021-05-21 18:58:16.519 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to 'localhost'. Next attempt in 60000ms
2021-05-21 18:58:16.527 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid 0ff7ceed-8909-4b37-ad9f-a763fe8bb7c5
2021-05-21 18:59:16.529 [INFO ] [.reconnect.PeriodicReconnectStrategy] - Try to restore connection to 'localhost'. Next attempt in 60000ms
2021-05-21 18:59:16.537 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid 0ff7ceed-8909-4b37-ad9f-a763fe8bb7c5

But this didn’t fix the rollershutter issue. Sending the command “O” or “G” (via MQTTfx) to RL-CZ brings (in MQTT Explorer)
{“Command”:“Unknown”}
{“Shutter1”:{“Position”:100,“Direction”:0,“Target”:100}}

How to provide you with more helpful information?

6

Hi,
I think, we need further details like thing and item definition.
I have Tasmota rollershutter devices running with a rollershutter channel.
I use the tasmota “backlog” command with payloads “shutterclose1, shutteropen1 and shutterstop1”.
Joerg

7

What makes you think Tasmota will accept those as shutter commands?

8

If You configure shelly to use Your MQTT server, the connection to shelly cloud is not established any more.

/SaĆĄ

9

The OH3 item for rollershutters i found and use sends “O”, “G”, and “S”.
The Shelly with Tasmota sends {“Command”:“Unknown”} back.

I don’t think that the Tasmotas accept those commands. I’ve read the Tasmota commands sheet. I’m looking for the best practise how to translate the commands (payloads) from the OH3-item rollershutter to Tasmota.

That’s why I asked “So, how do I set up OH3 (or mosquitto, or Tasmota) that it’ll recognizes “G”, “O”, “S” and reacts accordingly?”

I don’t care whether the Tasmota will recognize “G”, “S” or “O” or OH3 (or mosquitto) transforms these commands (payloads).
Unfortunately I couldn’t find the solution (from Joerg_Schreiner) to make OH3 to send ““backlog” command with payloads “shutterclose1, shutteropen1 and shutterstop1””.
The rollershutter item I use looks like
Items:
RL-CZ
Group * Equipment>Blinds

  • click -
    RL-CZ
    Tags
    tag_fill
    Blinds
    Semantic Classification

    class
    Equipment_Blinds
    hasPoint
    RLCZ_RLCZ
    hasLocation

Does this help?

10

That would be very unusual.
openHAB RollerShutter type Items would not accept those commands from rule or UI.

Not much. I think it is the Item RLCZ we’d be interested in, not the semantics.
There isn’t currently a ‘code’ view for Items,but you can get much the same thing from API Explorer, so a look at that might be useful to confirm real Item type etc.

You might also look in your events.log to see what commands really arrive at it. For a real RollerShutter type you might expect OPEN, CLOSE STOP or similar.

We still really need to see your Thing and channel definition. This is where you will probably need to use a transformation to convert whatever commands openHAB is passing around, into whatever your Tasmota would like to see instead.

That won’t help with this -

which is beyond openHABs control. To use mqtt.fx, you must send messages the Tasmota understands.

Okay, so you’ll know what commands you want to send to what topic. If you share that, it would help.

Have you seen example

11

Strange. I don’t use rules or scripts right now. The only things done were configuring automatically recognized items with names, location and so on using I think PaperUI. So, no deeper hacking with texteditors or SQL 'til now.

I found the REST API.

{
    "members": [],
    "link": "http://192.168.233.209:8080/rest/items/RLCZ",
    "state": "NULL",
    "editable": true,
    "type": "Group",
    "name": "RLCZ",
    "label": "RL-CZ",
    "category": "rollershutter",
    "tags": [
      "Blinds"
    ],
    "groupNames": [
      "Computerzimmer"
    ]
  },

Will this be enough or are information hidden elsewhere?

I found the “Show opening percentage 
” thread sometime ago. But I feel like I’m one or two steps behind.

12

It’s not a RollerShutter Item. I guess this is some ‘Equipment’ that you made in MainUI - you are using OH3, yes? There is no PaperUI in OH3.

In the semantic stuff, ‘Equipment’ is just a Group type Item with tags.
‘Point’ is just an Item with tags.
Bindings don’t care about any of that, they talk with Items with or without tags 
 except Group type Items.

You won’t be linking this to any device at all.

13

Took me a little bit of time more than I thought. Four Shellys are flashed with Tasmota 9.5.0 and connected to their rollershutters, now.

  1. Shutters go up and down using switches connected to the Shellys.
  2. Webinterface moves shutters.
  3. Console of Webinterface moves shutters using Shutteropen1, ShutterStop1 and ShutterClose1
  4. Publishing in MQTTfx moves shutters using cmnd/
/RL-CZ/Shutteropen1, ShutterStop1 and ShutterClose1

Yes, I’m using OpenHab3 with MainUI. It works fine for Hue and deCONZ lights as well as with MQTT (Teckin switched double outlets, flashed with Tasmota).

I deleted everything with “RL” from Things and Items.

Then I created a Thing, a generic MQTT Thing, UID: mqtt:topic:xxxx:RL-CZ, Label: RL-CZ, Location CZ, Bridge MQTT Broker, Thing Type Generic MQTT Thing, Availability topic tele/
/RL-CZ/LWT with Online and Offline and it went green (Online).

On the next Tab (Channels) I added a rollershutter channel type. Identifier: RLCZC, Label: RL-CZ-C.
MQTT State topic: stat/
/RL-CZ
MQTT State topic: cmnd/
/RL-CZ

With “Advanced”

  • Up Value: ShutterOpen1
    A string (like “OPEN”) that is recognised as UP state. You can use this parameter for a second keyword, next to UP.
  • Down Value: ShutterClose1
    A string (like “CLOSE”) that is recognised as DOWN state. You can use this parameter for a second keyword, next to DOWN.
  • Stop Value: ShutterStop1
    A string (like “STOP”) that is recognised as stop state. Will set the rollershutter state to undefined, because the current position is unknown at that point.

Clicking “Create” brought me back to Things/RL-CZ and showed the new Channel RL-CZ-C, RLCZC (Rollershutter)
The code

UID: mqtt:topic:xxxx:RL-CZ
label: RL-CZ
thingTypeUID: mqtt:topic
configuration:
  payloadNotAvailable: Offline
  availabilityTopic: tele/.../RL-CZ/LWT
  payloadAvailable: Online
bridgeUID: mqtt:broker:xxxx
location: CZ
channels:
  - id: RLCZC
    channelTypeUID: mqtt:rollershutter
    label: RL-CZ-C
    description: ""
    configuration:
      commandTopic: cmnd/.../RL-CZ
      qos: 0
      stop: ShutterStop1
      stateTopic: stat/.../RL-CZ
      off: ShutterClose1
      on: ShutterOpen1

Under “Items” now there is a “RL-CZ”, Group Equipment>Blinds, RLCZ with the number 100 to the right (which probably means that the shutter is open, which it is).

Clicking on that item I get
RLCZ
Icon Shutters (or blinds?)
RL-CZ
Group
at the top on an orange background.

Next below is a white field with the number 100 in it. Clicking on the field brings a label? RL-CZ, the three rollershutter buttons vertically, and the text: "This group has no members. ".
Clicking on one of these buttons doesn’t bring up cmnd subscriptions in MQTTfx and the shutters aren’t moving as well.
Closing this window shows further below:

Tags
tag_fill
Blinds
Semantic Classification

    class
    Equipment_Blinds
    hasLocation
    Computerzimmer

Direct Parent Groups
Computerzimmer
Direct Group Members

Metadata

With another try MQTTfx received cmnd/
/RL-CZ messages with payload “ShutterOpen1”, etc. but the shutter won’t move. MQTTFx declared “Unknown command”. But that setup had a link. With the new setup I didn’t link to anything, yet.

Which step did I miss?

14

Semantic ‘Equipment’ is a kind of Group type Item with a fancy tag.
Semantic ‘Point’ is a regular kind of Item with a fancy tag.
Semantics likes to think a Thing maps to ‘Equipment’, and any individual channels map to ‘Points’.

Bindings take no notice of any of that, only Items.

You can send a command to a Group type Item, but that never directly ends up at any binding. It just gets passed to member Items, if any. I think the Group has to be given a subtype for this to work, though.

openHAB Rollershutters accept various commands, UP/DOWN/STOP and also numeric position targets. Real shutters may only do a subset, though.
A UI presentation offering numerical positioning is useless if your real shutter offers only UP/DOWN.

How an Item gets presented in MainUI (and so any controls made available to you) depends by default on Semantics, and may not be what you want at all. People commonly fall into that trap with Temperature setpoints, getting presented as “sensors” with no user user controls.
The point is, you may be fighting with the UI and not with device configuration.

I don’t have an answer for you, just pointing out that there is a lot going on here that you need to pin down a bit.
Which Item exactly is linked to the channel with the cmnd topic? Never mind the Equipment stuff. What type is that Item?
Use API Explorer to send it exactly the commands you want, cutting out any UI fiddles or Group issues. Does it work? If not, look to channel config.

15

Hi,
SHUTTERSTOP, -OPEN,-CLOSE are no payload, but Part of the command in Tasmota.
To use it in Openhab nomenclature, you have to “missuse” the “backlog” command and then use SHUTTERSTOP, -OPEN,-CLOSE as payload.
So just add “/backlog” to your MQTT command in channels and it should work.
At least it does for me :grinning_face_with_smiling_eyes:

2 Likes