I was looking into the logs and at my surprise, even if it works perfectly fine on the UI ↔ MQTT side, there are error spammed within openhab logs for my Sonoff device.
Thing configuration:
UID: mqtt:topic:76a7b43223:fan-upstairs-propellers
label: Fan Upstairs
thingTypeUID: mqtt:topic
configuration:
payloadNotAvailable: Offline
availabilityTopic: tele/upstairs_fan/LWT
payloadAvailable: Online
bridgeUID: mqtt:broker:76a7b43223
location: Upstairs
channels:
- id: sonoff-fan03-mode <--- this one gives error
channelTypeUID: mqtt:switch
label: Smart mode status
description: Smart mode enabled or not (=manual)
configuration:
commandTopic: cmnd/upstairs_fan/POWER1
stateTopic: stat/upstairs_fan/POWER1
off: OFF
on: ON
- id: sonoff-fan03-speed
channelTypeUID: mqtt:number
label: Speed
description: ""
configuration:
min: 0
formatBeforePublish: "%s"
transformationPatternOut: JINJA:{{ value|int }}
max: 3
commandTopic: cmnd/upstairs_fan/FanSpeed
stateTopic: stat/upstairs_fan/FANSPEED
transformationPattern: JSONPATH:$.FanSpeed
Scenario: I use the UI of tasmota and click the toggle button it triggers a MQTT message:
topic: stat/upstairs_fan/POWER1 payload: ON (no json)
And then on the openHab side I receive the following log:
2024-10-18 16:31:20.311 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '{"POWER1":"ON"}' from channel 'mqtt:topic:76a7b43223:fan-upstairs-propellers:sonoff-fan03-mode' not supported by type 'OnOffValue': No enum constant org.openhab.core.library.types.OnOffType.{"POWER1":"ON"}
The UI on the openHab side update the state correctly however.
What is going on there?
(I would like to clean this up before integrating massively all other devices so any advice to do things properly would be very appreciated)
You don’t have a transformation and that JSON doesn’t match your on and off properties.
You need a state transformation on that channel that years JSONPATH to extract the POWER1 property from the JSON. And since “ON” can be used to command a Switch Item you don’t need the on and off properties. Those are used to convert something like 0/1 to OFF/ON and back again.
Are you sure? What’s the MQTT message received because based on the error message, the message published to the MQTT topic is {"POWER1":"ON"}. Is this the only message published to this topic? Is there only one type of message published to this topic?
It would be weird for Sonoff to publish JSON to FanSpeed topics (as indicated by the presence of the JSONPATH on that Channel) and not publish JSON on the other topics. (MQTT is case sensitive, are the topics really cmnd/upstairs_fan/FanSpeed and stat/upstairs_fan/FANSPEED?)
When addressing MQTT debugging problems like this usually involve:
Use MQTT Explorer or some other MQTT client to verify that the device is in fact publishing to the topic and exactly what is being published.
Use a text Channel with no transformations linke to a String Item to see the message exactly as it was received.
Gradually build up a transformation to extract the data you need from the message for that Channel on the text Channel. Once you have the data extracted, transfer that to the Switch Channel.
If other messages get sent to this Channel which are not to be processed by this Channel, chain a REGEX transformation before the JSONPATH to match only those messages that you want to be processed by the Channel.
It’s hard to know because I don’t have enough info (i.e. exactly what message is published by Sonoff under what circumstances). But here’s an example that processes a JSON message.
Yes this is the “strange” behaviour of Tasmota with the flag SetOption8 set to 1 and clicking on the “Toggle” blue button on tasmota UI:
It lack of consistence, I will ask the authors if it’s a bug.
Answer from Tasmota maintainers:
Certainly not a bug. SetOption90 exists to optionally not publish messages which are not JSON.
I tested and it looks much better now:
And will keep reading your answer Thank you for your help @rlkoshak I remember when I was using OpenHab 2 you were already a very helpful nice guy thank you for keeping up this community!
Note: I use the POWER1 channel to determine if I enable the “smart feature” or disable it and use the RF remote normally feel free to rename it of course.
Also important settings to enable on the Sonoff itself:
SetOption4 1
SetOption90 1
Option4 ensure that each property of the sonoff = 1 distinct channel in /stat/ (tele is not reactive and publish at a fixed interval)
Option90 ensure that the Sonoff publish only JSON to MQTT.
It lack of consistence, I will ask the authors if it’s a bug.