Mqtt switch in UI reverts back to off

bulletprooffool · January 1, 2018, 9:16pm

I have a very simple config - tryinf to manage some Sonoff devices that have been flashed with the Tasmota firmware.
I can see instuctions / feedback, but whenevr I switch an item ON, it reverts back to off.

Logs show the following:

cmnd/sonoff-kieraroom/POWER OFF
stat/sonoff-kieraroom/RESULT {“POWER”:“OFF”}
stat/sonoff-kieraroom/POWER OFF

cmnd/sonoff-kieraroom/POWER ON
stat/sonoff-kieraroom/RESULT {“POWER”:“OFF”}
stat/sonoff-kieraroom/POWER OFF

Note that even when I send an ON command, the return status is still off.
Weirdly, if it is ON already, it switches off?

Openhab logs show the following when I attempt an ON in the sitemap:

21:09:38.081 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘kiera_heating’ received command ON
21:09:38.088 [INFO ] [smarthome.event.ItemStateChangedEvent] - kiera_heating changed from OFF to ON
21:09:38.127 [INFO ] [smarthome.event.ItemStateChangedEvent] - kiera_radiator_status changed from 0 to 1
21:09:38.227 [INFO ] [smarthome.event.ItemStateChangedEvent] - kiera_heating changed from ON to OFF
21:09:38.255 [INFO ] [smarthome.event.ItemStateChangedEvent] - kiera_radiator_status changed from 1 to 0

The switch in the sitemap appears to switch on and off as per logs above.

The Sonoff device shows only an OFF instruction.

Items file is very simple for this:
Switch kiera_heating “Kiera Room Heating”
{ mqtt=">[broker:cmnd/sonoff-kieraroom/POWER:command:*:default],
<[broker:stat/sonoff-kieraroom/POWER:state:default]" }

I have tried running this with ZERO rules in place!

Any ideas?

idkpmiller · January 1, 2018, 9:41pm

I have no magic answer, I do think that you may want to troubleshoot from the startinging point of the sonoffs and then the MQTT mesages. Rather than jumping in at what I see as the final hurdle which is ibntegrating to OH.

I setyup two items for each of my switching sonoffs,
one is a simply Power command, and the other is the collection of the local switch on the sonoff unit vbeing pressed.

Depending on the version of tasmota the local switch result can be 0.1 and on the later firmwares it is ON/OFF I have rules setup that will work with either.

I usually start by checking the sonoff configuration. you may want to provide that here if you are stuck.

The nxty stage and the one that needs to be correct before I move onto OH integration is the MQTT requests and responses.

I use MQTT.fx on windows to monitor the sonoff under investighation and then typicall start by pressing the local button on the device and seeing if I get a message and observing its syntax, this I then check with what I have configured in OH items file.

I unfortunatley have changed the full topic on my devices, and I have configured my broker to be called MQTT, taking that into consideration my item entry for recieving the local switch change is this

Switch MQTTBR1Fan_local { mqtt="<[MQTT:tasmota/BR1SO3/stat/POWER:state:default]" }

if I am using an earlier tasmota which I think you may be using I will need to make the element type a Number rather than a Switch.

btw, I am currently using 5.10c tasmota.

let us know how you get on, interested to help if I can.

Regards

Paul

bulletprooffool · January 1, 2018, 9:49pm

Wow - thanks Paul.
I have definitely had it working before and comma work OK.
When I use the console interface / button from the Tasmota side, everything works great. The OFF command from openhab also works fine.
It’s only when I send an ON instruction, that it seems to switch on in OH - then Off, but only the off instruction works it’s way to the Sonoff.

When I get home, i’ll run through your message again and see if I can get any further

idkpmiller · January 1, 2018, 10:57pm

As I said earlier my configuration is not ‘Normal’ so you will need to translate some of the names and syntax structure order to get the same results. In order to assist wit that translation I have included my settings. It is best IMO you translate and do not try and emulate them.

While playing just now with MQTT.fx publish I noticed that sending the wrong message to the sonoff resulted in it being ineffective although it looks correct.

Take a look at the publish command with the message sent as a 1 (one). This command works to switch on my sonoff.

Changing the message to be a 0 (zero) will switch off the sonoff, if I send a message of ON or OFF although the message looks correct it is not actioned by the sonoff. I have no explanation, just thought I would pass it along in case it sends you down a wrong track.

The image below shows my topic format which is most likely different than yours, no particular reason except I felt it was better for me when viewing the structure.

On the sonoff web page under ‘information’ the topics are seend as this:

MQTT Topic HOSO3
MQTT Group Topic sonoffs
MQTT Full Topic tasmota/HOSO3/cmnd/

The items for this device are shown below, note that I have used a ‘broker’ name of ‘MQT’ so you need to change it.

Switch MQTTHOFan "Direct"   {  mqtt=">[MQTT:cmnd/HOSO3/POWER:command:*:default],<[MQTT:stat/HOSO3/POWER:state:default]" }
Switch MQTTHOFan_local { mqtt="<[MQTT:tasmota/HOSO3/stat/POWER:state:default]" }

As OH uses ON and OFF I asume that a mapping must be being used, to convert an ON to a 1 and an OFF to a 0. Although I cannot see one in the transforms directory that would seem to apply.

The rule I use to keep OH aligned with a local press of the sonoff button is shown below for completeness.

rule "MQTTHOFan_local toggled"
when
Item MQTTHOFan_local changed
then
	if (MQTTHOFan_local.state == 1 || MQTTHOFan_local.state == ON) {
		postUpdate(MQTTHOFan,ON)		
		logInfo("mqtt.rules", "MQTTHOFan Sonoff turned On")
	}
	else if (MQTTHOFan_local.state == 0 || MQTTHOFan_local.state == OFF) {
		postUpdate(MQTTHOFan,OFF)		
		logInfo("mqtt.rules", "MQTTHOFan Sonoff turned Off")
	}
end

Hope something shows up when you sift through the details above, after verfication fails to resolve then we must look carefully at the interaction of MQTT.fx with the sonoff and confirm the mqtt interface of the sonoff is behaving as expected.

Regards

Paul

bulletprooffool · January 1, 2018, 11:23pm

Thanks again Paul,

That is very helpful. I changed my default state messages using the cmd console on the Sonoff to 1/0 earlier, then back to ON/OFF.

I am guessing the changes have messed with the correct mapping values being returned and therefore I am sending invalid commands. Since I did this on all 3 of my Sonoffs I could not test - but you have confirmed that a valid target with invalid content does not error (does it default to null/OFF ?) In theory I should just work out what it is expecting.(I’ve only been running Sonoff for a few days)

I am running 5.9.1 on all 3 right now.
Your code looks pretty close to what I’m doing, I may just redo this ground up and see what happens. I’ll let you know when I have - thanks again

bulletprooffool · January 1, 2018, 11:58pm

ERghhh,

I figured it out (user error)
In trying to amend my mappings to use 1/0 rather than on / off (and thus make graphing easier), I edited some firmware settings as per https://github.com/arendst/Sonoff-Tasmota/wiki/Commands

But… I had set it this way:
00:50:27 CMD: StateText1
00:50:27 MQT: stat/sonoff-kayleeroom/RESULT = {“StateText1”:“ON”}
00:50:35 CMD: StateText2
00:50:35 MQT: stat/sonoff-kayleeroom/RESULT = {“StateText2”:“OFF”}

Of course the firmware uses StateText1 as the OFF identifier and 2 as ON.
So - whenever I sent an ON message, the state was being changed on the Sonoff - which I turn fired a status update of OFF to mqtt, which got openhab to respond again and cycle back off!!

Updated the text using the console - voila! learnt a lot today… thanks Paul