MQTT sending switch command randomly as "ON" or "1"

Add-ons Bindings
,
1

Dear,
I have quite a riddle here. I have plenty of the switch type relays.

defined in the .thing file like that:

   Thing topic BF155_actor_fc_2 "BF155_actor_fc_2  - Sala Seminario 1" {
    Channels:
        Type number : temperature "Temperature" [ stateTopic="BF155_actor_fc_2/temperature"]
		Type number : signal_level "Signal Level" [ stateTopic="BF155_actor_fc_2/signal_level"]
		Type string : IP "IP" 					[ stateTopic="BF155_actor_fc_2/IP"]
		Type string : macadress "MAC Adress" [ stateTopic="BF155_actor_fc_2/macadress"]
		Type switch : relay_0 "relay_0" [ stateTopic="BF155_actor_fc_2/relay_0" , commandTopic="BF155_actor_fc_2/relay_0"]
		Type switch : relay_1 "relay_1" [ stateTopic="BF155_actor_fc_2/relay_1" , commandTopic="BF155_actor_fc_2/relay_1"]	
		Type switch : relay_2 "relay_2" [ stateTopic="BF155_actor_fc_2/relay_2" , commandTopic="BF155_actor_fc_2/relay_2"]
		Type switch : relay_3 "relay_3" [ stateTopic="BF155_actor_fc_2/relay_3" , commandTopic="BF155_actor_fc_2/relay_3"]
		Type switch : fancoil_mode "Fancoil_mode" [ stateTopic="BF155_actor_fc_2/fancoil_mode" , commandTopic="BF155_actor_fc_2/fancoil_mode"]
		
    }

And when I send a command the device (that I have full control of as it is running a python script on the RPI) is receiving a mqtt payload as either 0 or 1.
But yesterday my server had unscheduled power outage and after reboot it started sending “ON” and “OFF”’ as payload. WHY? WHY?

The best part is that I did restarted an openhab service and it is back to the state it used to be. sending 0 and 1 as payload.

And the OH log is always showing the same thing that -
Item 'BF129_actor_fc_3_relay_1' received command OFF

But the resulting payload is sometimes OFF and sometimes 0

2

What “it”? it’s really not clear if you are complaining about the openHAB end or your device/script end. Maybe an mqtt.fx log or something?

If that is a Switch type Item, that is what it does. It accepts commands ON and OFF, never 0 and 1.
It is possible to configure MQTT channels to issue commands, but no sign of that in your configuration.
Guessing then, this command is issued by rule or UI clicking.
We’d expect that to trigger a publish to commandTopic

I can’t explain why the default is changing here.
But if sending/receiving 0/1 is important to you, the binding provides on= and off= configuration parameters on switch type channels which you probably ought to set.
As I understand, by default both “ON”/“OFF” and “0”/“1” payloads incoming on stateTopic will be interpreted to ON/OFF switch channel states.
By default, ON/OFF channel commands will be published as “ON”/“OFF” payloads to commandTopic.

As a complete aside, using the same topic for stateTopic and commandTopic is umm, unusual and probably involved here. Every time openHAB publishes to commandTopic it will shortly receive the message back on stateTopic. Twice as much MQTT traffic for little purpose.

3

When I wrote IT I meant OH2 server is sending commands to my custom switches.

That statement is not true for my case. Without any on= and off= configuration my server is sending payload 0/1 and sometimes like today after hard reboot it send command “ON”/“OFF” as it should. I can adapt but I wish it was consistent.

Where is the mqtt.fx log? do I have to enable it to see what has been sent to the mqtt bus?

4

Mqtt.fx is an external tool that you can use to monitor MQTT traffic through your broker. It’s an interactive client, basically. There are other similar tools.
Seeing what is really going on sounds like a good idea here.

The on= off= parameters are bidirectional, that is to say used with incoming and outgoing payloads.
I would not expect inconsistency in default outgoing payloads - but we haven’t seen the evidence of that yet.

The only unlikely circumstance I can think of here is that the same channels are defined in both xxx.things files and in PaperUI, and have a race at load time.

5

Paper UI is my biggest enemy I’m quite confident I have never touched it on this particular system as I only use it for zwave.

My client is super simple python script based on paho mqtt library that I would believe is as accurate as any other external tool to see the payload. And given that it changes from 0/1 to ON/OFF it quite clear that it is originating from OH.

6

Not convinced yet. What topic does your script publish to, if any? I’m guessing script publishes its status upon change or something.

EDIT - I’ll explain why that question is loaded, based on -

Identical topics is nuts, as i hinted earlier.

Here’s what I think can happen.

  • command ON → openHAB Item
  • binding publishes to topic, payload “ON” by default
  • broker promptly supplies "ON’ back to binding, because we’re also subscribed to that topic
  • binding updates openHAB Item state to ON by default
  • meanwhile, broker supplies “ON” to your script, because it’s subscribed to that topic
  • script says ‘huh?’ but in response publishes its state as “1”
  • broker supplies “1” back to script because it’s subscribed to that topic
  • broker also supplies “1” to openHAB because it’s subscribed to that topic.
  • binding by default recognises “1” for ON and updates Item state

I think it’ll settle down at that point, after an exchange of both ON and 1 payloads.

7

Is will redesign the switch to receive the comands on another topic, and will see if that eliminates the problem.

1 Like
8

@rossko57

So I now have redone that system that the thing is defined with separate status and command MQTT endpoint. Also in the meantime upgraded to the latest 2.5

	Thing topic sensorhub_2 "Sensor Hub 2" {
    Channels:
    Type switch : idr1_relay_0 "idr1_relay_0" [ stateTopic="sensorhub_2/idr1_relay_0", commandTopic="sensorhub_2/idr1_relay_0_command"]
		Type switch : idr1_relay_1 "idr1_relay_1" [ stateTopic="sensorhub_2/idr1_relay_1", commandTopic="sensorhub_2/idr1_relay_1_command"]
		Type switch : idr2_relay_0 "idr2_relay_0" [ stateTopic="sensorhub_2/idr2_relay_0", commandTopic="sensorhub_2/idr2_relay_0_command"]}

and still and again the Openhab sometimes will send is switch command over MQTT as ON and sometimes as 0 and 1

Message received: sensorhub_2/iqr1_relay_1_command : OFF
setting iqr11 0
Message received: sensorhub_2/idr1_relay_0_command : OFF

five min later after service restart it sends

Message received: sensorhub_2/idr1_relay_0_command : 0
setting idr10 0
-published-
Message received: sensorhub_2/idr1_relay_0_command : 1

General rule is that after the cold boot of the RPI it will be on/off and then on the service restart it changes.
I had to do a regular bug workaround in the python client.

9

No evidence of that in your log.

10

sorry left it without pressing send, on the post edit, it is now updated with 2 examples and way to repeat bug.

11

Not that I don’t trust your coding, but I presume this is your code reporting what it thinks it sees.
A tool like mqtt.fx (there are others) revealing actual MQTT traffic could still be of benefit.

If you show openHAB sending different message payloads (I would not be that surprised to find both payload types rattling around, in variable order) it still seems most likely you have duplicate channels defined in some way.

12

What can be wrong with that python code to do OH type conversion of 1 to “ON” and back.
But I will install mqtt.fx to show low level packets.
That is clean install of the OH 2.5 via openhabian with just 2 Mqtt things. and mosquito broker (not the one in the OH)

import paho.mqtt.publish as publish
import paho.mqtt.client as mqttClient

def on_message(client, userdata, message):
print ("Message received: " + str(message.topic) + " : " + str(message.payload.decode(“utf-8”)))

Connected = False
client = mqttClient.Client(sensor_name)
client.on_connect = on_connect
client.on_message = on_message
client.on_disconnect = on_disconnect
client.connect(OH_IP, port=1883)
client.loop_start()

while Connected != True:
time.sleep(0.1)

13

Was this ever resolved?
I’m facing the same problem: my code worked before and now it doesn’t anymore.
Initially the switch command sends ON and OFF but suddenly it sends 1 and 0.

Things file:
Type switch : switch "Output" [stateTopic="zigbee2mqtt/wcd1", transformationPattern="JSONPATH:$.state", commandTopic="zigbee2mqtt/wcd1/set/state"]

Items file:

Switch Lamp_Terrarium_Outlet "Lamp Terrarium [%s]" (gZIG, gLA, gGF) {channel = "mqtt:topic:mybroker:wcd1:switch"}

Proof using frontail (showing ON and OFF) :

2021-03-02 15:58:10.801 [ome.event.ItemCommandEvent] - Item 'Lamp_Terrarium_Outlet' received command OFF
2021-03-02 15:58:10.852 [vent.ItemStateChangedEvent] - Lamp_Terrarium_Outlet changed from ON to OFF

When using MQTT FX (or MQTT explorer) it clearly shows it received a 1 (or 0):

Clipboard01

When manually (using mqtt explorer) sending the command

> zigbee2mqtt/wcd1/set/state on

everything works like expected.

I’m convinced there is a problem with OH but don’t know how to tackle it.

HW RPI4 / Openhabian / Buster/ all uptodate
SW OH2 V2.5.12-1

-ben

14

Try adding

, on="ON", off="OFF"

to the configuration of your Thing Channel to force the Channel to send ON/OFF. Note that this will also transform the incoming messages too - presumably that should also be ON/OFF?

15

Thanks,

I’ve added your solution and it seems to work for now.

-ben

16

It could be very much that reboot or restart fixed that for a moment. have seen that before.
I resolved that with code that accepts both ON and 1 on a client but that is just a work around.
Maciej

17

Yes. From my testing (OH3), if you add or change the MQTT thing channel parameters, you need to restart. I had “OFF” appearing in MQTT.fx with off=“1” parameter until I restarted.