I am running OH2.1 stable on a RPi3 with the KNX, MQTT Event, Pushover and Astro Binding. KNX is connected via an Enertex KNX / IP Router. I have build a dashboard and some rules with NodeRed, in parallel to the Standard OH sitemap.
Now since some weeks (I can’ really point it to something special, as I am just playing around with NodeRed and not changing anything in my Setup) I am receving a strange behaviour:
Every time I reboot the Pi, the system turns on 2 lights all by itself. Strange thing is, the log shows they are OFF and that no ON command is sent.
Some time ago, I had this behaviour seen when deploying new NodeRed rules as well. But ever since, it is only seen when a reboot occurs. So my final thought was, maybe this has something to do with the MQTT Eventbus?
thanks for your feedback, interesting to know. How do you connect to the KNX bus?
I had it again today while deploying an update to a NodeRed rule, which does not cause a full reboot of OH2.
So maybe it is some strange behaviour of the KNX binding, which gets fired somehow by a reboot OR NodeRed. Hard to tell when there is no error in the logs…
After some debugging I can say, that the command is issued by OH2 during the startup process. The configurations on KNX side are correct (I was assuming, that a status object might have been incorrectly linked in an actor, but nope).
So after playing around with NodeRed a lot yesterday, my OH2 completely went nuts. The server crashed every 2-3 hours without notice and without any useful info in logs. So I decided to reinstall the system from scratch (which I had to do 4 times, as every installation ended up with annother problem. Strange enough). So the final installation, now up and running, does not switch anything during boot.
So obviously, something got stuck in the old system which is no longer there. I am suspecting a persistence file that might have been corrupted. When read during boot to restore states, it always read the “last” status; due to it being defective, the “frozen” status might have been “ON” then and so these lights were triggered. (Just guessing ;-))
At least it is a) not a generic bug in the KNX binding or b) within the router communication. So maybe this helps you nailing it on your side as well
Have fun
I have the same issue with Node-RED where on restart of OH that I have a certain set of switches that always get turned on. (and triggers a bunch of lock related events). I also suspected persistence or retained mqtt values. Especially since you seem clean on a rebuild. Might try to clear (and stop using) persistence to see if that clears my issue too.
Unfortunately, the problem came back. Since monday it switches on one light when OH2 is rebooting (I didn’t change, add or configure anything since August, so OH2 was just sitting there and doing it’s thing, when the problem all of a sudden came back on monday).
I have done some debugging and it turned out, the problem seems to be connected to MQTT:
Unstalled all persistence bindings, cleaned up the db files and rebooted - Light on.
Uninstalled the MQTT Action binding and did a reboot - Light on.
Uninstalled MQTT binding and did a reboot - Light OFF !
Installed MapDB and set it to default persistence DB, rebooted: Light still off.
Installed RR4DJ for logging again, rebooted: Light still off
Installed MQTT binding again, soon it was up and running: Light ON again.
Just to be sure, repeated step 3 and rebooted: Light OFF again
Repeated step 6, rebooted and boom, Light ON again
I checked the MQTT.conf and experimented with “mybroker.retain=yes” or “mybroker.retain=no”, which had no influence on the problen.
I was using NodeRed to read the staus topic of the respective light, which was correctly set to “0” before and after a reboot, as long as the MQTT binding was not installed.
So now I am a little bit lost what to do. Is there some caching for the readings of the MQTT binding, so maybe there is a status that got stuck?
Interesting enough, before I reinstalled the system last time from scratch (which solved the problem then), it was the same light that had been switched on. Now, since then I have completely reconfigured my KNX system (completely new GA scheme) AND changed the respective actor from Merten to Theben. Maybe coincidence, maybe this has something to do with naming of items? I don’t know… (this time it is “Licht_Essen” only, last time it was “Licht_Essen” AND “Licht_Waschkueche”, which is using an entirely different actor)
Other than this strange behaviour, the lights are working perfectly well, either via OH2 or via the wall switches, rules and scenes.
So I would be thankful for further ideas, before I need to reinstall the whole thing again…
Finally solved it: It seemed to be the retained status of that particular item within mosquitto.
Stopped Mosquitto, deleted /var/lib/mosquitto.db, reinstalled MQTT binding and rebooted and…Light still off.
pew…
Still asking myself, why this happened twice…Bug in Mosquitto?
I found the same solution of deleting the Mosquito.db persistence file solved my restart triggering issues as well. I went from retained to nonretained as well and suspect that the last values don’t get erased when you do that
Interesting to know. In fact, I never (outside testing today) changed this config but stayed on retain=yes, so maybe the db gets damaged after some time…
Don’t think so, as this would have only made sense if the light would have been on before the reboot. I had switched the light on and off before the manual reboots, still it would switch to on.
