Sonoff-Tasmota linking to openhab

mqtt
sonoff
tasmota
Tags: #<Tag:0x00007fe053e660f0> #<Tag:0x00007fe053e5be70> #<Tag:0x00007fe053e5bd08>

(Chris) #1

Hello

Am sorry to have to ask, but I can seem to work out the coding for linking tasmota to openhab

I have flashed a sonoff basic with Tasmota and set up mqtt and it seems to have linked to my raspberry pi running openhab and I can control the sonoff by logging on with the ip address.

I have the Hue Bridge Emulation with a binding running and have it working with openhab but can seem to get it to work without using the Hue Bridge Emulation

the code am using is

Switch   FF_MasterBedroom_Light     "Light"            <light>         (FF_MasterBedroom, gLight)        {mqtt=">[broker:cmnd/sonoff1/POWER:command:*:default],
            <[broker:cmnd/sonoff1/POWER:state:default]" }

so I am either using the wrong code up missing something else my site map looks as follows

sitemap home label="home" {
    Frame label="Ground Floor" icon="groundfloor" {
        Group item=GF_Dining
        Group item=GF_Kitchen
        Group item=GF_LivingRoom
    }

    Frame label="First Floor" icon="firstfloor" {
        Group item=FF_Bedroom
        Group item=FF_GuestRoom
        Group item=FF_MasterBedroom
        Group item=FF_Office
    }

I have tried my hardest not to have to ask but have spend the last few days trying to work it out with no luck I don’t want to relay on using the Hue Bridge Emulation with a binding any help would be grateful


(Thomas Binder) #2

at first: You know, the Sonoff communicates via MQTT with openHAB?

So, you have to

  1. install and configure MQTT for openHAB
  2. use the same broker for openHAB and the Sonoffs.

see here for more information (ok, it’s quite a biiiig thread):

or use the Tasmota Wiki:

If there’s somthing unclear in those documentation, please don’t hesitate to ask here - we’re happy to guide you - and improve the documentation!


(Chris) #3

I have installed MQTT and set up as it says In the guide already and as far as I can understand I am using the use the same broker for openHAB and the Sonoffs. would you be able to confirm the code I have is right or is there something I am missing


(Thomas Binder) #4

ok. that’s a step further (I was confused by you saying hue emulation and stuff… :wink: ).

the code for your Switch-item Looks good so far.

so, for comparison:

  • Please provide your mqtt.cfg
  • please give us a screenshot of the WebUI of the sonoff showing the mqtt-configuration

Do you run your openHAB on a Pi? Then you should be able to SSH to it and type in:

$ mosquitto_sub -h localhost -t "+/sonoff1/#" -v

What this does is to subscribe (mosquitto_sub) to all subopics sonoff1 (+/sonoff1/#) with whatever sub-subtopics afterwards on your broker (provided it is on the same machine as your openHAB, if you’re using another one, please use this one of course.
you should then see something like this while pressing the hardware button on the sonoff:

cmnd/sonoff1/POWER OFF
stat/sonoff1/RESULT {"POWER":"OFF"}
stat/sonoff1/POWER ON

(Thomas Binder) #6

oh yes, this helps! :wink:

please be advised, the angle brackets indicate you have to completely replace them with your own names:
In your case, please replace “<broker>” with your own name-convention. I have mqttoh2 for example, so this would then read:

# Define your MQTT broker connections here for use in the MQTT Binding or MQTT
# Persistence bundles. Replace <broker> with an ID you choose.
#

# URL to the MQTT broker, e.g. tcp://localhost:1883 or ssl://localhost:8883
mqttoh2.url=tcp://192.168.1.17:1883

# Optional. Client id (max 23 chars) to use when connecting to the broker.
# If not provided a random default is generated.
mqttoh2.clientId=openhabian
<...>

Hint: the first line in your config lacks the “#”, perhaps it’s just not enough copy, but be sure, that one is commented also.


(Chris) #7

so would the code I am using then change to reflect this or stay the same


(Thomas Binder) #8

I’m not quite sure, if I catched, what you’re saying - but you have to adjust the Code (at least remove the angle brackets from <broker>.clientId=openhabian …?
please have also a look in the logs after you changed the config. It should read something like this:

2017-12-28 20:51:28.714 [INFO ] [penhab.io.transport.mqtt.MqttService] - MQTT Service initialization completed.
2017-12-28 20:51:28.722 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'mqttoh2'

(Thomas Binder) #10

ok, now I see! :wink:
yes, you’re absolutely right, the name of the broker in your mqtt.cfg is to be used everywher, in this case also in your items-configuration. Are you sure, mqttob2 is in your mqtt.cfg?

What you see in the console is more or less what you’d get with the mosquitto_sub I mentioned earlier.

What’s in your openhab.log and events.log?


(Chris) #11

sorry I got mixed up with the logs this is from the openhab log

2018-01-14 18:46:16.592 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'broker’
2018-01-14 18:47:16.592 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection ‘broker’


(Thomas Binder) #12

Sorry then for my being confusing! :wink: in that case, you have to go back to your original item configuration.
Sorry, if this was not clear enough: the name you give your broker in mqtt.cfg is the ID you have to use in every other context for openHAB.

so, if your broker names broker in mqtt.cfg you have to use broker in .items


(Chris) #13

I have tried to follow your advice this is what I have now am I anywhere near being right thank you for you patience

# Define your MQTT broker connections here for use in the MQTT Binding or MQTT
# Persistence bundles. Replace <broker> with an ID you choose.
#

# URL to the MQTT broker, e.g. tcp://localhost:1883 or ssl://localhost:8883
mqttoh2.url=tcp://192.168.1.17:1883

# Optional. Client id (max 23 chars) to use when connecting to the broker.
# If not provided a random default is generated.
mqttoh2.clientId=openhabian

# Optional. True or false. If set to true, allows the use of clientId values
# up to 65535 characters long. Defaults to false.
# NOTE: clientId values longer than 23 characters may not be supported by all
# MQTT servers. Check the server documentation.
#<broker>.allowLongerClientIds=false

# Optional. User id to authenticate with the broker.
#<broker>.user=<user>

# Optional. Password to authenticate with the broker.
#<broker>.pwd=<password>

# Optional. Set the quality of service level for sending messages to this broker.
# Possible values are 0 (Deliver at most once),1 (Deliver at least once) or 2
# (Deliver exactly once). Defaults to 0.
#<broker>.qos=<qos>

# Optional. True or false. Defines if the broker should retain the messages sent to
# it. Defaults to false.
#<broker>.retain=<retain>

# Optional. True or false. Defines if messages are published asynchronously or
# synchronously. Defaults to true.
#<broker>.async=<async>

# Optional. Defines the last will and testament that is sent when this client goes offline
# Format: topic:message:qos:retained <br/>

Switch   GF_Dining_Light            "Light"            <light>         (GF_Dining, gLight)              {mqtt=">[mqttoh2:cmnd/sonoff1/POWER:command:*:default],
            <[mqttoh2:cmnd/sonoff1/POWER:state:default]" }


(Thomas Binder) #14

yes, that sounds good! now you should have the connection to your broker - and the console of your sonoff WebGUI should see the messages you send from openHAB…

(the only thing I’m a bit confused about is, that you have set User and Password for Sonoff for MQTT - and not in your mqtt.cfg… But as I can see from the openhab.log your openHAB connects to the broker and so does the Sonoff in the console).


(Chris) #15

my log is showing this

2018-01-14 18:57:48.908 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'mqttoh2'
2018-01-14 18:57:49.505 [ERROR] [penhab.io.transport.mqtt.MqttService] - Error starting broker connection
org.eclipse.paho.client.mqttv3.MqttSecurityException: Not authorized to connect
	at org.eclipse.paho.client.mqttv3.internal.ExceptionHelper.createMqttException(ExceptionHelper.java:28) [208:org.openhab.io.transport.mqtt:1.11.0]
	at org.eclipse.paho.client.mqttv3.internal.ClientState.notifyReceivedAck(ClientState.java:990) [208:org.openhab.io.transport.mqtt:1.11.0]
	at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:118) [208:org.openhab.io.transport.mqtt:1.11.0]
	at java.lang.Thread.run(Thread.java:748) [?:?]

is this right as I still have not control over the switch from openhab do I need to add anything to the site map or anywhere else to make this work


(Thomas Binder) #16

ok. now - then you have to add your user and password to the mqtt.cfg (same one, you put in to sonoff WebGUI - as the sonoff can connect!)

# Optional. User id to authenticate with the broker.
mqttoh2.user=<user>

# Optional. Password to authenticate with the broker.
mqttoh2.pwd=<password>

(Chris) #17

thank you I have it working you have been amazing thank you for your time one last question if I may
i am using the below code i have mqttob2:cmnd should the second one say mqttoh2:stat if you can understand what i am trying to say

Switch   FF_MasterBedroom_Light     "Light"            <light>         (FF_MasterBedroom, gLight)        {mqtt=">[mqttob2:cmnd/sonoff1/POWER:command:*:default],
            <[mqttoh2:cmnd/sonoff1/POWER:state:default]" }

(Thomas Binder) #18

yes, absolutely right. the sonoff sends the actual state in the stat topic. (sorry, for not seeing this the first time).
so this one should do the trick:

Switch   FF_MasterBedroom_Light     "Light"            <light>         (FF_MasterBedroom, gLight)        {mqtt=">[mqttoh2:cmnd/sonoff1/POWER:command:*:default],
            <[mqttoh2:stat/sonoff1/POWER:state:default]" }

hint: don’t rely on looking at the BasicUI at the present. There’s a minor bug, it won’t autorefresh, so after pressing the hardware button on the sonoff please reload the UI - then you should see the correct state.


(Chris) #19

once again thank you for you support and help i have learnt a lot and its now not been a wasted weekend


(Roguestreak) #20

FYI I’m at very close to the same starting point (basic linking of tasmota’d sonoffs) and the non-refreshing of BasicUI was causing me to question whether I was coding it right; but an update I did yesterday seems to have rectified the autorefresh! (not sure which update exactly, one if the ones in openhab-config, possibly “latest stable”). My original openhabian image was only from a few days ago, so not sure what’s changed since then.
The “broker” bit did trip me up in several ways, I think as it was in the angled brackets I assumed it was some sort of dynamic link.

I still don’t understand how the icon (eg. lightbulb) is fed back a state, I do have a map etc. and it’s working but I don’t know why/how! ; ) I can see there’s “out” messages (>) and “in” listeners (<), but can’t figure it out, are both icon and toggle fed by the same data?

PS. You may want to check you have the following installed for your next progression:
installed JSONPATH and Transform addon in Openhab?
goto paperUI> Add-on> Transormations , install JSONPath Transformation and Map Transformation


(Garry Mitchell) #21

The icon & On/Off slider is updated based upon the internal state - which is (by default) updated when you press the button in BasicUI, or when the Sonoff sends a message in to OH.

To make these reflect the actual state of the Sonoff device, you can add , autoupdate=false to the end of your item, using the example given in the post a couple above:

Switch   FF_MasterBedroom_Light     "Light"            <light>         (FF_MasterBedroom, gLight)        {mqtt=">[mqttoh2:cmnd/sonoff1/POWER:command:*:default],
            <[mqttoh2:stat/sonoff1/POWER:state:default], autoupdate=false" }

This addition tells OH to not update its internal state when you press the button in BasicUI, but to wait for the update back from the Sonoff.


(Roguestreak) #22

Thanks Garry, so the icon state and the switch state are implicitly linked?

I do have autoupdate=false added, as I figured for the tasmota’d sonoff relays it’s best to actually get confirmation back as to the state change rather than just assume it’s gone through correctly.

When listing multiple “in” MQTT stats/teles, does this just result in one displayed item (eg. textfield) updated with whatever the last message was from one of the list?