Okay, so that rule explains the -L1 and -L2 commands, so we can now ignore those.
Who/what can command Switch_LampsIndoorAll is the next thing to look for.
@rossko57 what did you exactly mean by this? Do you have any suggestion what I could do to find out more about my mystery?
I mean that in your original post, you talked a lot about updates. But the events.log (and well done for including it) shows that the unwanted actions are really commands. These are different things in openHAB, like cause and effect.
Already made my suggestion to find out what can issue commands to Switch_LampsIndoorAll, likely that will be rules, or GUI.
I’ve searched through all my rule files (luckily I’m writing the rules in files), and the only place where the ‘Switch_LampsIndoorAll’ was found is that rule, I’ve posted earlier, but this is also just reading but not writing the item.
When searching the whole OH strucuture, here are the results:
rules\scenes.rules - Found in that only rule, mentioned above
sitemaps\watch.sitemap - There is a switch item defined
sitemaps\ _quickaccess.sitemap - There is a switch item defined
items\scenes.items - Definition of the item
Have you ever, at any time, created a rule in the UI which you may have forgotten about?
This link will help you make sure rule activity gets logged.
Alright, then that leaves any GUI as suspects for issuing commands. What was open at the time? Includes phone apps and MainUI in a browser window at the back.
- I have a wall mounted tablet where habpanel is running (always), but habpanel does not control this switch
- I’m using the OH mobile app (iOS), but was not used at that time
- I’m using the OH iWatch app, but was not used at that time - this is quite new, the issues were happening also in the past
- My wife is using the OH mobile app (android) - she was triggering the garage close event
BUT, this is the situation what happened today. Sometimes the same or similar happens also when the app (or her app) is not used.
Frankly, I have a feeling, that OH server is triggering it and not the apps.
Yes and no. I have also some test rules created on the UI, but I have also checked them (have only 3-4).
Searching for this special item-name is not enough! The item is member of group in more then one level. Do you have rules that act upon changes to those groups, possibly sending commands to members of the group? That way the item-name would not show in the rule!
It’s really unlikely that you would have the only OH server in the world that spontaneously issues commands to non-random devices.
Get yourself a good idea of what Items exactly are affected. As @opus points out, “parent” Group hierarchies are meant to pass commands down the line.
We should see commands to Groups in your events.log, no sign in the sample shown, but do keep it in mind.
Check in your MainUI that your Item has no unexpected links - Items defined from file with no links may later be given links from UI. This is an unlikely source of commands, though.
1 Like
Sorry for the long quiet here, I did not have much time for OH. In the meanwhile, I’ve removed the hierarchies for groups as these were not used for anything and could complicate the life.
I’ve also checked the group rules, but did not find anything yet.
Yes, I know and most probably you are right, but the facts, that these strange things does not happen every time and always some other switch is getting an action lead me to this conclusion. If there would be a rule which is wrongly implemented, then always the same would happen. But this is not true.
Never mind, I’ll check all the group actions and items to see, if there is no duplicate assignments and will give here a feedback.
Hi guys,
An update here! I was able to see a very similar issue, when I save my item file, which holds all my MQTT items. In such case some of my items are receiving a command. What is strange, that not all items are receiving a command. Do you have any answer what the hell is going one?
Here is the result of one save on the mqtt.items file:
2022-03-15 12:01:16.588 [INFO ][el.core.internal.ModelRepositoryImpl] - Loading model 'mqtt.items'
==> /var/log/openhab/events.log <==
2022-03-15 12:01:18.279 [INFO ][openhab.event.ItemCommandEvent ] - Item 'Switch_LampsIndoorAll' received commandOFF
2022-03-15 12:01:18.282 [INFO ][openhab.event.ItemStateChangedEvent ] - Item 'Switch_LampsIndoorAll' changed from ON to OFF
2022-03-15 12:01:18.295 [INFO ][openhab.event.ItemCommandEvent ] - Item 'Switch_LampsL1_OnOff' received commandOFF
2022-03-15 12:01:18.302 [INFO ][openhab.event.ItemCommandEvent ] - Item 'Switch_LampsL2_OnOff' received commandOFF
2022-03-15 12:01:18.304 [INFO ][penhab.event.ItemStatePredictedEvent] - Item 'Switch_LampsL1_OnOff' predicted to become OFF
2022-03-15 12:01:18.311 [INFO ][penhab.event.ItemStatePredictedEvent] - Item 'Switch_LampsL2_OnOff' predicted to become OFF
2022-03-15 12:01:18.321 [INFO ][openhab.event.ItemCommandEvent ] - Item 'Switch_GarageLight2_OnOff' received commandON
2022-03-15 12:01:18.323 [INFO ][openhab.event.ItemStateChangedEvent ] - Item 'Switch_LampsL1_OnOff' changed from ON to OFF
2022-03-15 12:01:18.324 [INFO ][openhab.event.ItemStateChangedEvent ] - Item 'Switch_LampsL2_OnOff' changed from ON to OFF
2022-03-15 12:01:18.326 [INFO ][hab.event.GroupItemStateChangedEvent] - Item 'gLampsIndoor' changed from ON to OFF through Switch_LampsL2_OnOff
2022-03-15 12:01:18.328 [INFO ][penhab.event.ItemStatePredictedEvent] - Item 'Switch_GarageLight2_OnOff' predicted to become ON
==> /var/log/openhab/openhab.log <==
2022-03-15 12:01:18.274 [INFO ][enhab.core.model.script.scenes.rules] - Main door remote >> State: toggle; Command:
2022-03-15 12:01:18.284 [INFO ][enhab.core.model.script.scenes.rules] - All lights on-off triggered OFF
2022-03-15 12:01:18.299 [INFO ][enhab.core.model.script.scenes.rules] - External remote >> State: brightness_up_click; Command:
I would guess that is likely the work of rules.
When you reload an xxx.items file, it reinitializes the changed Items, as it should. They will get NULL state as a consequence.
A while later, a remote device might check in with a routine status report or similar, and Item will get updated to a sensible value. The delay of some minutes from items file load would support that theory, and also tend to rule out buggy GUI widgets.
Note, that will be a state change event, and will trigger any rules listening for Item changes.
You will not see the reinitialize to NULL in your events.log, but if the theory is correct you would see the later NULL-to-whatever changes. Have a closer look in your log before the time of the snippet shared.
The standard initialization process you mentioned above is known also by me, I’ve seen that couple of times in the log when the OH server was restarted, but I did not see when a file item file was re-saved. I’ve checked the event log and I do not see initialization to null before the save event (BTW: the snippet I’ve shared above start with the save event → loading model ‘mqtt.item’).
For example ‘Switch_LampsIndoorAll’ is a virtual switch, it is not connected to a physical device.
Switch Switch_LampsIndoorAll "Switch lamps (All indoor)" (gLampsIndoor, gHouse)
The “Main door remote” and “External remote” are IKEA Tradfri remotes. Why are these receiving actions (which is a button press on the device)? Also if you see, both are receiving different commands. I think these were the last actions from these remotes.
String Rmt_EntryDoor_Action "Entry door remote [%s]" <button> (gHouse) {channel="mqtt:topic:myMQTTBroker:tradfri_rmt_1:Action"}
Thing topic tradfri_rmt_1 "Tradfri Remote 01"
{
Channels:
Type string : Action "Action" [ stateTopic="zigbee2mqtt/tradfri_rmt_1/action", postCommand=false ]
Type number : Battery "Battery" [ stateTopic="zigbee2mqtt/tradfri_rmt_1/battery" ]
Type number : Linkquality "Link quality" [ stateTopic="zigbee2mqtt/tradfri_rmt_1/linkquality" ]
}
Another anomaly is, why only these items are getting updates? In the mqtt.items file I have more than 40 items defined.
NOTE: I’ve a persistence service enabled, which is restoring some items states, but these items are not a part of it.
I’ve restarted my OH container and now, when I save the mqtt.items file, then no action is executed… That’s why I think, there will be a problem in the OH as the behavior is not consistent. :S
Okay, some more information. It seems, the behavior I see is somehow related to last commands. After the OH server restart, when saving the items file, nothing happened. Then I clicked a button on one of my Tradfri remotes, which was switching my external lamp on, then I pushed another button, which was turning off my lamp. The lamp is turned on/off through a rule, which is executed, when the button on the remote it pushed.
2022-03-15 16:55:51.257 [INFO ] [enhab.core.model.script.scenes.rules] - Main door remote >> State: brightness_down_click; Command:
2022-03-15 16:55:51.258 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Rmt_EntryDoor_Action' changed from brightness_up_click to brightness_down_click
2022-03-15 16:55:51.262 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Switch_ExtLamp_OnOff' received command OFF
2022-03-15 16:55:51.264 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Switch_ExtLamp_OnOff' predicted to become OFF
2022-03-15 16:55:51.268 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item 'gLampsOutoor' changed from ON to OFF through Switch_ExtLamp_OnOff
2022-03-15 16:55:51.269 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Switch_ExtLamp_OnOff' changed from ON to OFF
Now, when I re-save my mqtt file, then it is re-sending the Tradfri remote comand.
2022-03-15 16:59:15.716 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'mqtt.items'
2022-03-15 16:59:15.946 [INFO ] [enhab.core.model.script.scenes.rules] - Main door remote >> State: brightness_down_click; Command:
2022-03-15 16:59:15.954 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Switch_ExtLamp_OnOff' received command OFF
2022-03-15 16:59:15.967 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Switch_ExtLamp_OnOff' predicted to become OFF
Again, consider how likely that only you see this special openHAB behavior.
I expect you saved the items file because you made changes.
Some bindings are not very good about dealing with changes in-flight, especially when using old style items and things files, and a restart of binding or system will be required.
Exactly what might happen is very dependent on the change and on the binding.
What actions? I don’t see any activity on those Items (or are they trigger channels?) in the events.log provided.
I can see your rules producing some log messages. I cannot see how those rules are triggered.
Is the offending Item linked to MQTT channel by definition in the items file? (most likely)
Is the remote device publishing it’s MQTT messages with a ‘retained’ tag?
What do we think might happen if an Item is reinitialised and an associated MQTT topic is retained? (I don’t know the answer to that, but you might be finding out)
I was not changing the items directly I just added a space to the end of the items file. But okay, I can understand and live with that fact. In the last weeks I was not seeing these “strange” things too frequently, but are still there (mainly in the last week) and are very dangerous. So, what I did yesterday, I’ve removed most of my groups and left only for the status items (temp sensors, etc.). Non of the current groups have subgroups nor parent groups. I’m trying to eliminate the complexity.
This is a very good question! I was not aware of that, and it could answer some observations. The Tradfri devices are proxied to MQTT through the Zigbee2mqtt library. It was not clear from the documentation if these messages are then proxied as persisted or not, but from the behaviors I saw seems to be as persistent. So now, I’ve explicitly disabled the persistence for all messages.
I’ve a couple of tasmota flashed switches, where the power retain was also enabled. So I’ll disable these as well.
What I also did, I’ve enabled the logging on the mosquitto broker. The reason was to see, who is triggering these unwanted actions. Yesterday I was analyzing another strange thing, and I did not see, any special message from MQTT side, so it was not the one, which was triggering the “unexpected” command. So it really seems, it is coming from OH.
What is hard, I cannot constantly repo any of these things, everything happens randomly and every time something else happens. I do not see any connection between them 
Summary till now:
- I’ve added logs to every rule, to see, if the rule is not the one which is triggering, but non of the analyzed issue was containing a rule log.
- I’ve closed HabPanel for a week, the issues were still happening.
- I’ve minimized the groups and removed the group relationships, so I think this factor is eliminated. - that was only yesterday, so will see
- I’ve removed the Tradfri rule code as it was very often making issues - the isses are still happening. The Tradfri issues could be caused by the message retain, what I have explicitly disabled now in zigbee2mqtt - will see
- I’ve enabled MQTT logging to see, if the “unwanted” action is not triggered by a device - I was not seeing it in the logs, so I think not.
What would be nice if I could enable a logging for the mobile apps. AFAIK, these are comunicating with OH through the REST API. Am I right? If yes, then is it possible to turn on logging there as well? I want to eliminate, that not the mobile app is the one who is changing something.
I can’t see any reson to implicate Group usage from what you have shared so far. Group involvement in commands when recieved is merely to pass them along to all members. Both Group and members would log such shared commands. Rules or GUI may issue commands to Groups, so you’d already be looking at that source.
I don’t know how you trap everything recieved by REST, but not sure it helps. You already know when commands are recieved because they are logged, regardless of source. You’re telling us you have put tell-tale logging in rules that could issue commands? By elimination then, from REST. Assuming affected Items are not configured by binding to recieve command (e.g. postCommand=true in MQTT, other bindings possible too).