OH randomly updates items

[abal (Attila)]

The second case:
This is more complicated as it could not be constantly reproduced and multiple items are affected. I’ve tracked yesterday down one issue, which is quite easy as there are not so many dependencies.

What happened:
My wife was using OH mobile app (android) to open and then close the front gate. This is one switch button in the app. The opening was fine, but when she closed the gate, suddenly the rollershutters went down. The rollershutters can be triggered from the following places:

1. When the sun is down (Channel ‘astro:sun:local:set#event’ triggered END) → the rule sets IsDarkOutside.sendCommand(ON) → logged
2. Through alexa command → logged
3. Manually from the mobile app/habpanel

Sunset rule:

rule "Sunset Rule" 
when 
	Channel 'astro:sun:local:set#event' triggered END 
then 
    logInfo("scenes.rules", "SUNSET triggered")
    if(IsDarkOutside.state != ON){
	    IsDarkOutside.sendCommand(ON) 
    }
end

When sunset happens:

rule "Turn on external lights when main door opens"
when
    Item IsDarkOutside changed
then
    logInfo("scenes.rules", "Is dark outside triggered: " + IsDarkOutside.state.toString)

    // close the shaders in the kitchen
    if(IsDarkOutside.state == ON){
        sendCommand(Rs_AllRoom, DOWN)
    }
end

Alexa rule:

rule "Alexa rollershutters"
when
    Item Shader_Alexa_Ctrl received command
then
    var currentState = Shader_Alexa_Ctrl.state.toString
    var cmd = receivedCommand.toString

    logInfo("scenes.rules", "Shader_Alexa_Ctrl >> State: " + currentState + "; Command: " + cmd)

    if(cmd == 'Up'){
        Rs_AllRoom.sendCommand('UP')
    }
    if(cmd == 'Down'){
        Rs_AllRoom.sendCommand('DOWN')
    }
end

And the logs:

In OH log, nothing is indicating, that the rollershutters are triggered, only by the incorrect status update. This is caused by the wrong implementation on the nodeMCU, as it is trying to return the state “opened”, “closed”, which is not allowed by the rollershutter item. So you can ignore the error, I’ll correct it.

2022-04-12 18:38:07.244 [INFO ] [enhab.core.model.script.xiaomi.rules] - FrontGate managed state: OFF
2022-04-12 18:38:07.247 [INFO ] [enhab.core.model.script.xiaomi.rules] - FrontGate contact state: OPEN
2022-04-12 18:38:09.251 [INFO ] [enhab.core.model.script.xiaomi.rules] - Sending update to managed state: ON
2022-04-12 18:38:14.469 [INFO ] [enhab.core.model.script.scenes.rules] - Open front gate - managed >> ReqState: ON
2022-04-12 18:38:14.472 [INFO ] [enhab.core.model.script.scenes.rules] - Open front gate - managed >> CurrState: OPEN
2022-04-12 18:38:59.205 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command 'closed' from channel 'mqtt:topic:myMQTTBroker:nodemcu_SRC_Thing:AllRoom' not supported by type 'RollershutterValue': Cannot call update() with closed

Mosquitto log (the command is going to front gate, but then also to rollershutters)

2022-04-12T16:38:52: Received PINGREQ from otatest
2022-04-12T16:38:52: Sending PINGRESP to otatest
2022-04-12T16:38:53: Received PUBLISH from myMQTTClient (d0, q0, r0, m0, 'cmnd/frontgatectrl/gate', ... (3 bytes))
2022-04-12T16:38:53: Sending PUBLISH to frontgatectrl (d0, q0, r0, m0, 'cmnd/frontgatectrl/gate', ... (3 bytes))

-> The message is sent to controller
2022-04-12T16:38:54: Received PUBLISH from myMQTTClient (d0, q0, r0, m0, 'cmnd/somfyctl/roomAll', ... (1 bytes))
2022-04-12T16:38:54: Sending PUBLISH to somfy-remote (d0, q0, r0, m0, 'cmnd/somfyctl/roomAll', ... (1 bytes))
2022-04-12T16:38:59: Received PUBLISH from somfy-remote (d0, q0, r0, m0, 'stat/somfyctl/ack', ... (15 bytes))
2022-04-12T16:38:59: Received PINGREQ from mqttjs_d1e94687
2022-04-12T16:38:59: Sending PINGRESP to mqttjs_d1e94687

-> The ACK is published by the controller
2022-04-12T16:38:59: Received PUBLISH from somfy-remote (d0, q0, r1, m0, 'stat/somfyctl/roomAll', ... (6 bytes))
2022-04-12T16:38:59: Sending PUBLISH to myMQTTClient (d0, q0, r0, m0, 'stat/somfyctl/roomAll', ... (6 bytes))
2022-04-12T16:39:01: Received PUBLISH from tasmota_POW02 (d0, q0, r0, m0, 'tele/tasmota_POW02/STATE', ... (294 bytes))
2022-04-12T16:39:01: Sending PUBLISH to myMQTTClient (d0, q0, r0, m0, 'tele/tasmota_POW02/STATE', ... (294 bytes))
2022-04-12T16:39:01: Received PUBLISH from tasmota_POW02 (d0, q0, r0, m0, 'tele/tasmota_POW02/SENSOR', ... (231 bytes))
2022-04-12T16:39:01: Sending PUBLISH to myMQTTClient (d0, q0, r0, m0, 'tele/tasmota_POW02/SENSOR', ... (231 bytes))
2022-04-12T16:39:04: Received PINGREQ from frontgatectrl
2022-04-12T16:39:04: Sending PINGRESP to frontgatectrl

This is only one of the mysteries.

[rossko57]

@abal

So based on these logs, it seems to me, that OH is triggering the “received update” channel

For this case, remember this rule knows nothing about channels. It responds to updates of the Item state.
You’ve just reloaded the xxx.items file defining this Item, essentially re-defining it. I’m not surprised if that triggers an Item update event. I think you’re chasing a red herring here.

Although I still have doubts as well, that you may have a retained message associated with this in your broker. We would get exactly the same effects if ‘rebooting’ the Item caused it to issue a REFRESH to any linked channels. That would cause the MQTT binding in turn to go fetch any retained message from the broker, I think. And you may have one lurking there …

@rossko57

Even if you have now set the device not to send messages with 'retain" instruction, the broker will keep the last retained message indefinitely.

“the device” from the broker’s viewpoint is the zigbee2mqtt service.

---

@abal

The item changed is not a deal, as I can press the same button multiple times, the rule should react to it.

Understood. It’s an unwanted consequence of representing button-push events in the form of an Item steady-state, it’s just not a good fit.
In ye olden days, there was no other choice. It could be improved by having an “un-push” event as well - if the device does not offer one, we can automate a simulated un-push via rule or expire. Then the Item state more usefully represents pushed and not-pushed. Still pants if you look for long or double presses etc.

A better solution is to treat the button push event as an event, not as a state.
openHAB already has internal events - Item commands - that are a good logical fit.
Unlikely as it seems here, a better approach is to set postCommand=true in your MQTT button channel.
Now, when the button is pushed, a command is issued to the Item. It’s a discrete event, we can send as many as we like of the same command in succession. Every MQTT message produces a new command.
In this situation the Item steady state is completely irrelevant and not used. You’d have to overhaul your rules to use command not state.

A variation on this approach is to use the trigger=true option on the MQTT channel. Don’t link any Item to it all, no Item is required. When MQTT message received, the binding will put a channel trigger event on the openHAB bus. You’ll see that in the log.
There’s not much you can do with that apart from directly trigger a rule, but if that’s all you need to do then it takes away lots of confusion with Item states and commands.

[abal (Attila)]

@rossko57

A variation on this approach is to use the trigger=true option on the MQTT channel. Don’t link any Item to it all, no Item is required. When MQTT message received, the binding will put a channel trigger event on the openHAB bus. You’ll see that in the log.
There’s not much you can do with that apart from directly trigger a rule, but if that’s all you need to do then it takes away lots of confusion with Item states and commands.

Oh man, that’s amazing! I was not aware of this possibility. I’ve converted my tradfri rule to use the channel trigger and also removed the associated item. Now, I cannot repro the unwanted trigger even if I restart the zigbee2mqtt or OH. I’ll watch it for a longer time, but based on the facts you have shared it seems to be a correct final solution.

Do you have any idea for the second case?

[rossko57]

@abal

Mosquitto log (the command is going to front gate, but then also to rollershutters)

You have to be explicit. None of the messages are labelled “front gate” or “rollershutters”.
I think this is the one you didn’t expect?

@abal

2022-04-12T16:38:54: Received PUBLISH from myMQTTClient (d0, q0, r0, m0, 'cmnd/somfyctl/roomAll'

And I guess MQTT client “myMQTTClient” is openHAB?

We can be very sure openHAB is not publishing random commands to random topics that just happen to target a particular device, so we can be sure this about something deliberately configured.

Step one - look through all your MQTT channels to see which have commandTopic cmnd/somfyctl/roomAll There may be more than one.

Then find out what these channels are linked to. Usually some Item, or possibly multiple Items for any given channel.
But as hinted at earlier, if you use any ‘follow’ profiles on channel links these also offer a backdoor for commands, check for that too.

Then you look in your events.log to see which Item got a command at 18:38:54.

Note that your MQTT broker seems to be using a clock two hours different from your openHAB service, just take care about log timestamps.

[abal (Attila)]

@rossko57

And I guess MQTT client “myMQTTClient” is openHAB?
I think this is the one you didn’t expect?
2022-04-12T16:38:54: Received PUBLISH from myMQTTClient (d0, q0, r0, m0, ‘cmnd/somfyctl/roomAll’

Yes and yes.

@rossko57

Step one - look through all your MQTT channels to see which have commandTopic cmnd/somfyctl/roomAll There may be more than one.

I have only one command on one channel, with topic ‘cmnd/somfyctl/roomAll’.

However there are two rules, which are directly publishing this topic. The reason is, that a in the past different command (payload) was sent to my rollershutter controller to go fully up and I was not able to pass that command through the item.
Both rules are starting with a log message, what I do not see in the OH log, so I assume, the topic was not published by them.

Type rollershutter : AllRoom                            [ stateTopic="stat/somfyctl/roomAll" , commandTopic="cmnd/somfyctl/roomAll", on="u", off="d", stop="s" ]

rule "Alexa morning routine"
when
    Item Switch_Alexa_morning_routine changed to ON
then
    logInfo("dev.rules", "Alexa morning routine exec ...")

    val mqttActions=getActions("mqtt","mqtt:broker:myMQTTBroker")
    // open all shaders
    mqttActions.publishMQTT("cmnd/somfyctl/roomAll", "u")
end

@rossko57

Then find out what these channels are linked to.

There is only 1 item is linked:

@rossko57

if you use any ‘follow’ profiles

I’m not using this feature, I was also not aware of it :). I’ve searched through the item definitions and nothing was found.

@rossko57

Then you look in your events.log to see which Item got a command at 18:38:54.

2022-04-12 18:38:04.199 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Switch_FrontGate_OnOff2' received command ON
2022-04-12 18:38:04.209 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Switch_FrontGate_OnOff2' predicted to become ON
2022-04-12 18:38:04.220 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Switch_FrontGate_OnOff2' changed from OFF to ON
2022-04-12 18:38:05.738 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Contact_FrontGate_Status2' changed from CLOSED to OPEN
2022-04-12 18:38:05.747 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Notification_Setting_FrontGate' changed from OFF to ON
2022-04-12 18:38:08.138 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Switch_POW01_Voltage' changed from 240 to 239
2022-04-12 18:38:09.256 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Switch_FrontGate_OnOff_Managed2' changed from OFF to ON
2022-04-12 18:38:38.148 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Switch_POW01_Voltage' changed from 239 to 238
2022-04-12 18:38:52.096 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Date' changed from 2022-04-12T18:37:52.118+0200 to 2022-04-12T18:38:52.119+0200
2022-04-12 18:38:53.714 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Switch_FrontGate_OnOff2' received command OFF
2022-04-12 18:38:53.723 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Switch_FrontGate_OnOff2' predicted to become OFF
2022-04-12 18:38:53.734 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Switch_FrontGate_OnOff2' changed from ON to OFF
2022-04-12 18:38:54.456 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Rs_AllRoom' received command DOWN
2022-04-12 18:38:54.468 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Rs_AllRoom' predicted to become DOWN
2022-04-12 18:39:07.929 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Switch_POW01_Voltage' changed from 238 to 240
2022-04-12 18:39:11.746 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Contact_FrontGate_Status2' changed from OPEN to CLOSED
2022-04-12 18:39:11.754 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Notification_Setting_FrontGate' changed from ON to OFF
2022-04-12 18:39:12.559 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SWeather_Outdoor_temperature' changed from 20.27 °C to 19.76 °C

Okay, so the rollershutter call was published from the linked OH item “Item ‘Rs_AllRoom’ received command DOWN”. The Rs_AllRoom is set from 5 rules (4 from 5 are executed by Amazon Alexa). All rules start with a log.

NOTE: I have persistence enabled on my MQTT broker (however based on the docu, it should not affect Q0 messages).

@rossko57

Note that your MQTT broker seems to be using a clock two hours different from your openHAB service

Yes, it is using UTC, most probably I did not configured the timezone for the container. Will fix this.

[rossko57]

@abal

Okay, so the rollershutter call was published from the linked OH item “Item ‘Rs_AllRoom’ received command DOWN”

Alright, so everything worked exactly as configured after that. No point looking at MQTT further, the openHAB command is the culprit. Where did this command come from? We have to infer from a limited list.

Not surprised you do not use ‘follow’ profile, but seeing this command event completes the ruling out. The “command like” happenings produced by ‘follow’ do not get logged as Item events. Cross one off.

Is this Item a member of any Groups? Remember, Groups cascade commands to member Items. However we would expect any commands to the parent Group to be visible in the events.log just a few milliseconds prior. No sign of that, cross that one off.

Some bindings can issue commands, e.g. KNX, and MQTT when using postCommand option. That should have been evident from your look at that already.

GUIs send user pokings to openHAB as Item commands. Only you know how likely that s to have happened.

Hackers, bogeymen, and carefully built external scripts and devices can use the REST API to issue commands to Items. Again, only you can judge how likely it is that a bogeyman has gained access to your system but only places carefully targeted nuisance commands.
Some deliberately set up external script or service is more likely, but you should remember setting that up.

The ‘expire’ option on an Item can be configured to send commands to itself. That would be a result of some long-ago event, so such commands would look like “spontaneous” in the events.log. Simple look at Item detail should/has rule that out, it only works on this Item itself.

Talk of delayed action has I hope triggered thoughts of delayed rule-initiated action … rules can create timers that carry out actions in the future, like sending commands. Unless you put tell-tale logs inside such timer blocks, you can’t see when they run. Any tell-tale from the spawning rule could be long ago.

It still all feels like an overlooked effect in a rule to me. This supposedly spontaneous command happens within a second of other deliberate expected actions.
Remember searching rules for Item names is not enough - rules can address Items indirectly, deriving a target from say a Group membership or associated name conventions, e.g.
sendcommand(someString, someVariable)
where someString has been constructed as the Item name elsewhere in the rule. Or constructs like
triggeringItem.sendCommand(xx)

[abal (Attila)]

@rossko57

Is this Item a member of any Groups?

No, this is the definition of it. Last time I’ve removed most of my groups to near down the possible factors.

Rollershutter Rs_AllRoom "All" <rollershutter> { channel="mqtt:topic:myMQTTBroker:nodemcu_SRC_Thing:AllRoom"}

@rossko57

Some bindings can issue commands, e.g. KNX, and MQTT when using postCommand option.

The postcommand is only used only for the tradfri link. Here is the channel definition:

Type rollershutter : AllRoom                            [ stateTopic="stat/somfyctl/roomAll" , commandTopic="cmnd/somfyctl/roomAll", on="u", off="d", stop="s" ]

@rossko57

GUIs send user pokings to openHAB as Item commands. Only you know how likely that s to have happened.

Yes, this is also one of my biggest question. It would be very good to have a log somewhere is an item update is triggered from any app. Not sure, if that is possible and also I’m not sure if all the apps are using the same API.

@rossko57

Hackers, bogeymen, and carefully built external scripts and devices can use the REST API to issue commands to Items.

My OH installation is behind an OpnSense firewall, the only port allowed from outside is the VPN (using cert authentication). My OH is connected to the OH cloud, so the external systems (Alexa) are connected through OH cloud. The second thign, why I do not think it is triggered externally is the fact, that some other action is always triggered before (garage door open, …). An the happenings are not predictable or constantly reproducable. This is also the question, if it would be a rule, then why not the same happens always?

@rossko57

The ‘expire’ option on an Item can be configured to send commands to itself.

I’m not using the expire binding. I’ve also search through my item definitions.

@rossko57

rules can create timers

I’m using couple of timers, but none of them is working with the rollershutters. Also, each delegate is writing a log.

@rossko57

It still all feels like an overlooked effect in a rule to me. This supposedly spontaneous command happens within a second of other deliberate expected actions.
Remember searching rules for Item names is not enough - rules can address Items indirectly, deriving a target from say a Group membership or associated name conventions, e.g.
sendcommand(someString, someVariable)
where someString has been constructed as the Item name elsewhere in the rule. Or constructs like
triggeringItem.sendCommand(xx)

I’ve searched for sendCommand in all my rules. Non of these calls are using a string variable for a target. Everywhere the items is specified as a fixed string, or the item object is used directly. I’ve also searched again for the Rs_AllRoom and all rules, where this item is a target has a log.

[rlkoshak (Rich Koshak)]

@abal

Yes, this is also one of my biggest question. It would be very good to have a log somewhere is an item update is triggered from any app. Not sure, if that is possible and also I’m not sure if all the apps are using the same API.

There is no tracing for events that are placed on the event bus. But there are some things you can know. The UI will never send an update. They only send commands. All of the UIs use the same REST API.

@abal

I’m not using the expire binding. I’ve also search through my item definitions.

Expire isn’t a binding. It’s built into OH. It’d be worth a quick grep through the metadata jsondb file to confirm there is no Expire metadata defined on any Items.

I’ve not fully followed the whole thread but with what I know right now, I would try to totally eliminate MQTT as the source of the commands by either disabling the MQTT Broker Thing or unlinking the Items in question from the MQTT Channels. If the commands keep happening we know for certain that it’s OH really generating these commands or if it’s something happening with MQTT.

One avenue I’ve not seen explored here (I apologize if I missed it) is whether the MQTT topics involved are using retained messages. What could happen is something publishes a message that results in a command with retained set to true. The next time that OH connects to the MQTT Broker that retained message gets sent back to OH even if it’s received that message before; even if that message was sent days ago.

So if your connection to the MQTT broker is a little flakey you could be receiving these messages over and over, each time OH reconnects to the MQTT broker. Depending on how the topics and messages are configured to be interpreted, they could result in a command.

Note that a non-retained message sent to the topic does not clear out the old retained message. You have to send an empty retained message to clear out an old retained message. So if there has ever been a retained message sent to one of these topics by any publisher, it’s still there until you explicitly clear it out.

You should be able to tell if there are retained messages on a topic in MQTT Explorer (you can even clear them out from there). Or you can take MQTT out of the picture entirely and see if the problem persists.

[abal (Attila)]

Hi Rich,

Thanks for your response here on hunting the ghost :).

@rlkoshak

The UI will never send an update. They only send commands

This is exactly my case, something is calling unexpected actions.

@rlkoshak

grep through the metadata jsondb

I know, there is not Expire binding anymore, just used the wrong terminology (again :(). I’ve searched through the jsonDB, as suggested, only for the googletts was found the “expire” keyword, but that is of the oauth token.

@rlkoshak

I’ve not fully followed the whole thread but with what I know right now, I would try to totally eliminate MQTT as the source of the commands by either disabling the MQTT Broker Thing or unlinking the Items in question from the MQTT Channels. If the commands keep happening we know for certain that it’s OH really generating these commands or if it’s something happening with MQTT.

Unfortunately I cannot disable the MQTT as all my action items are using MQTT. Some of the sensors are using other bindings. BUT, we have already neared down from the logs, that the action is coming from OH and not from MQTT. Here is one log:

Mosquitto log:
2022-04-12T16:38:54: Received PUBLISH from myMQTTClient (d0, q0, r0, m0, ‘cmnd/somfyctl/roomAll’

OH log:
2022-04-12 18:38:54.456 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Rs_AllRoom' received command DOWN

myMQTTClient is the OH MQTT client.

@rlkoshak

One avenue I’ve not seen explored here (I apologize if I missed it) is whether the MQTT topics involved are using retained messages.

From the above Mosquitto log, you can see, that the message is not retained (second parameter: q0)

@rlkoshak

Note that a non-retained message sent to the topic does not clear out the old retained message.

Hmm, okay I did not know that, but as we have found out above, the issue is not triggered by the MQTT, but by OH.

What is new and happened in the last two days, is that my wife uses her phone to open the front gate, and again the roller shutters were going down and the external lamp was turned on. The same behavior happened yesterday and today. So that’s why it would be very good to somehow trace down, from where the action is coming. She is using the Android OH app, while I’m using the iOS one. I’ll try to repro it with her cell. Other that that I’m not having any other idea, what else I could check

[rlkoshak (Rich Koshak)]

@abal

From the above Mosquitto log, you can see, that the message is not retained (second parameter: q0)

That message isn’t retained but has there ever been a retained message on that topic. Once published, a retained message is kept forever, even when non-retained messages are published afterward. And if OH disconnects from the broker and reconnects it will receive those retained messages again and again, every time it reconnects. And if those messages become commands, it will look like your devices are being commanded from out of nowhere.

From what I’ve seen, you’ve determined that the messages are not actively being published to MQTT, but if you’ve a retained message on the topic that’s been there for months… Your tests thus far, as far as I can tell, have not eliminated that possibility.

[abal (Attila)]

Okay, so I found a way how to list retained messages and yes, there are some. I’m using 3 main topic paths:

• stat [output]: status information from the device (turned on/off etc.)
• tele [output]: telemetry information from the device
• cmnd [input]: triggering an action on the client device

When I list the retained topics, then the stat and tele topics are containing retained messages, but not the cmnd ones.

Why I thought, the action is triggered by OH? Because of these two lines from the mosquitto log:

2022-05-02T08:17:12: Received PUBLISH from myMQTTClient (d0, q0, r0, m0, 'cmnd/somfyctl/roomAll', ... (1 bytes))
2022-05-02T08:17:12: Sending PUBLISH to somfy-remote (d0, q0, r0, m0, 'cmnd/somfyctl/roomAll', ... (1 bytes))

In the log “myMQTTClient” is OpenHab, so it is publishing the action to close the rollershutters to the client “somfy-remote”.I have analyzed all places from where this action can be triggered and all are rules. I’ve added info logs into all my rules, to make sure, these are not the ones, which are triggering the action. When this unwanted action is published, I do not see any log from the rule, which could signalize it was executed from there.

BUT, yes, the retained messages theoretically could cause issues when there is an invalid state retained, which is then sometimes sent to OH, which could then react wrongly. I’ll try to double check all my device code to make sure, the messages are not retained, then I’ll clear the broker.

[abal (Attila)]

So, I’ve cleared all retained items from the /stat/# topic and left only the /tele/#/LWT topics there. But I’m still thinking about, how if this really could cause the ghost switches? If the retained message would cause, then:

1. If the device would get the topic because of the disconnect, then I would not see this in the log:
   Received PUBLISH from myMQTTClient (d0, q0, r0, m0, ‘cmnd/somfyctl/roomAll’
2. If OH would get the retained topic because of a disconnect, then why it would not get all the retained messages?

[rlkoshak (Rich Koshak)]

1. You would see a PUBLISH message in the Mosquitto log because nothing published a message to the broker at that time.

2. OH would receive the retained messages on all topics subscribed to that have a retained message.

[lobb (Gertjan Lobbens)]

Oh my god! I have the exact same issues here… Been searching the forums for months now.
No apps or webpages running, my wife turns on a light (with the switch) and 5 other lights are turning on. In the logs: ‘Item xxx received command ON’ for each of those 5 lights.
If i restart openHAB this issue is gone for a few days, then it returns. Sometimes once a week, sometimes 3 times a week, until i restart openHAB.
Yesterday it turned all the lights on and opened my gate!
I’m terrified to leave openHAB running unattended now…

This also started after updating to openHAB 3, never had this issue with any version before that.
I recently upgraded from 3.0 to 3.2 in the hope off getting rid of this behaviour but no dice.
When i started using 3.0, i started fresh, so no old configurations can be triggering this.

My setup involves a Siemens PLC connected to OphenHAB as a Windows service.
I have no rules running, all logic is in my Siemens PLC.

[Wolfgang_S]

@lobb

No apps or webpages running,

Just to make sure - as others were hit by this - is your OH instance exposed by intent or not to the internet by opening the OH port on your router ? Check on shodan.io if your ip address and your OH instance is listed there ( as long as you have a static ip address ).

[abal (Attila)]

Hi @lobb,

Sorry to say this, but I’m happy, that I’m not the only one having these horror issues. I was investigating it for months and it seems, the issues are gone. At least I did not experience such ghost switches for a longer time. Franky, I do not know, what was the solution, but the cases were significantly decreasing when I’ve removed retained messages from the MQTT broker as suggested by Rich.
Are you using OH cloud for remote access? Because I was also thinking, what if there is an issue between the cloud instance and my local instance, that some of the event are getting somewhere stuck in the channel and are then later (in a random time) propagated to a local instance? That’s why I was trying to find a way to get know, which device (mobile, habpanel, alexa, …) is triggering these ghost events. But nothing.

Oh and yes, the only mystery what was solved (with the help of rossko) was the tradfri remote, there the solution was to react on action channel instead of an OH item command.

[lobb (Gertjan Lobbens)]

Well i was tired of it. I had set myself the goal of trying 1 more time setting everything up from scratch and if it didn’t improve things i would’ve gone with another software.
So i bought a Raspberry Pi 4 and set everything up on that instead of the pc i was running it on.
I can say after a few weeks i haven’t had any issues so far. No more ghosts turning on my lights or opening my gate.
To reply to your question; i was using OH cloud only for Google Home (still am) but no items where exposed and i don’t use MQTT.
I’m sorry to not have found a definitive answer, but i’m glad i can sleep now without worrying my garage will open any time…

[abal (Attila)]

Thanks for your feedback here. This information is also helpful as all my candidates - what I thought could cause the issues - were disproved by you . I’m also running on RPI 4. Previously I was using OH 2.5 then updated to 3.0, 3.1 then 3.2. I also moved to a containerized environment from a bare metal. So, lot of changes in the past, what could theoretically break something in my OH configs, but I also cannot answer what solved the problems.
I can just pray, that it is really gone/solved forever …

[CFI (Christophe Fieu)]

Hello Everybody,
Same issue here with randomly changes of my temperature setpoints and turning lights on or off.
Sometimes it is like a discotheque and sometimes, we come home with 10 lights on !!!
i run OH3.4.4 with IP Camera Binding and Bticino Openwebnet binding.
i removed the IP camera binding, but still the same behaviour.
How did you fix this problem?
thank you very much.

[abal (Attila)]

Hi @CFI,

Franky? I do not know. I think, I had several issues, which were causing this strange behavior, and I think, the same will happen at you.

This is what I did and I think, helped:

1. I have replace the changed event for Tradfri Remote to a channel trigger. The change event was triggered unexpectedly by the Tradfri, which was causing some of the ghost switches. The event channel is working well
2. I have cleared up the retained MQTT messages (you really need to override them to clear up)
3. I’ve created a special sitemap for my wife with minimum options, what she is using from her cell. I had a feeling, that sometimes she was miss-clicking also
4. I have removed the unnecessary group dependencies (I think, this had nothing to do …)

In the last 6-9months, I did not have any ghost switching, so I think I was finally able to solve this problem. What is bad, I do not exactly know, which of these changes were really solving the problem. The Tradfri was definitely one of these changes.

This is a really long and boring process to find it out.