OH randomly updates items

Setup, Configuration and Use Items & Sitemaps
,
41

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.

42

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?
43

  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.

44

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.

45

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 ).

46

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.

47

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…

48

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 :slight_smile:. 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 …

49

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.

50

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 :slight_smile:
  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.