MQTT Binding Shelly 1 transformation map


I’m currently setting up my very first OpenHab instance (V2.5.4). I’ve built a small Testboard with two switches, two outlets and one Shelly 1 and one Shelly 1PM.

To communicate with the shellies I’ve set up a Mosquitto and the mqtt-binding in OpenHab.


Bridge mqtt:broker:testbed [ host="192.168.###.###", secure=false ]
    Thing topic tb_shelly1 {
        Type switch : relay [ stateTopic="shellies/shelly1-############/relay/0", commandTopic="shellies/shelly1-############/relay/0/command", on="on", off="off" ]
    Thing topic tb_shelly1pm {
        Type switch : relay [ stateTopic="shellies/shelly1pm-############/relay/0", commandTopic="shellies/shelly1pm-############/relay/0/command", on="on", off="off" ]
        Type number : power [ stateTopic="shellies/shelly1pm-############/relay/0/power" ]

Now… the Problem I’m facing is that the mqtt binding switch channel by default uses 0 and 1 as ON/OFF equivalent. As you can see I remapped this with on="on" and off="off". That works just fine but doesn’t really satisfy my insinde nerd :nerd_face:

I’d like to use a .map file, as this allows me to edit all shellies at once, but I just can’t get it to work.
I tried replacing the channel attributes on/off with transformationPattern="" and transformationPatternOut="".


(in transform folder of course :wink:)

But sadly after a service restart this leads to sendig 0 and 1 again. Am I missing something or is my MAP-File just wrong?
Or did I understand transformationPatterns just completely wrong?

Thanks in advance

Did you try using 0=ON 1=OFF in the map file and what do you see in the logs when sending a command to the shelly?

I tried just now. The suggestion does not work aswell :slightly_frowning_face:

This is less surprising as the log says:

2020-05-11 21:19:17.249 [WARN ] [t.generic.ChannelStateTransformation] - Transformation service MAP for pattern not found!

which is odd because the file definitely exists. But the more I read the MQTT-Binding doc, the more I think this transformation is meant to transform the state label for the sitemap and not to transform the standard 1 and 0 commands to “on” and “off” before they are send to the broker

Why do you still use MQTT with the Shelly devices instead of the native binding?
What‘s the benefit?

This message is “The MAP service isn’t installed”, not “the file isn’t found”.

but I’m pretty sure that mqtt2 will change 0 to OFF and 1 to ON. You should not need to define on="on", off="off" at all. Or is it case sensitive? I have no shellies…

1 Like

It’s not clear, but the MQTT binding definitely applies it’s “mini-transform” functions - if applicable to that channel, like the on= off= arguments - as well as any transformations you have given.

In the case of an inbound message, I think it applies transformationPattern and then takes that string result and gives to the on= off= processing. Even if you haven’t specified on= off=, it will use default settings.

The nuisance factor is that on= off= is applied to both incoming and outgoing payloads. You can have different transformationPattern and transformationPatternOut, but both must funnel through the same on/off. And what order that happens in is both important and murky?

Actually it is case sensitive, but if I do not define them the binding is publishing a raw 0 on OFF and a raw 1 on ON events. Which the shellies do not recognize.

Your hint that this is the missing service did the trick. I installed the service feature:install openhab-transformation-map and now it works fine :star_struck:

Thanks so much!

BTW… the map I’m using now:


In fact I’m not still using it but rather actively decided to do so recently.

Whil looking around how to bind thew shellies I stumbled across your binding and considered to use it first. But after taking a look at the binding code and at the shelly API doc I deceided not to use HTTP-Callbacks as the HTTP-Protocol imho does not suite IoT Applications as good as a small, TLV based, pub/sub protocol like MQTT does.

While searching around I found a Document from Allterco Robotics where they describe the adoption of the CoAP (well some flavor of it) for the shellies. I’m very excited for the future development of this.

So, long story short… I don’t like HTTP for small embedded devices I guess.

It‘s not my binding, I‘m just a user.
HTTP callbacks are just a fallback, CoIoT (CoAP) is the preferred communication within the binding. The developer is in deep contact with Alterco.