Hi all,
i hope i can make myself clear. I’m on 4.1 and using zigbee2mqtt for years now to integrate 60+ sensors, keyfobs, and actors on zigbee standard. I do integrate them via things+items that are updated via local mosquitto MQTT server.
What recently makes me unhappy is the fact when i edit the related items file, severall (all??) of my rules based on zigbee are triggered all immediately and of course like my house door is opened/closed,…and several other actions that normally are triggered from zigbee keyfobs,…
As if some old buffer was loaded again that triggers rules that are behind mqtt (zigbee) actions…
I already stopped zigbee2mqt before i saved the items file, but it happens again…so its something Openhab internal from my perspecitve.
Is this well known, any system bug, or just happens to me…
Kind Regards,
Norbert
A few things might be going on here. I don’t know zigbee2mqtt so can’t say for certain if I’m right.
When you edit a .items file, every Item defined in that file gets deleted and recreated brand new.
If the MQTT Channel is configured to treat state updates as commands and the message on the MQTT topic is retained, when the Item is recreated it will become commanded with what ever was on the MQTT topic.
Typically most services separate the state and command topics and never use retained on the command topics so that might not be happening.
If you are using the follow profile, it’s possible when the Item gets updated from a state topic (which I would expect to be retained) that update is being passed to the following Channel as a command. That’s the expected behavior.
If you have rules that trigger on changes to Items and send commands out as a result, all those rules will be triggered as restoreOnStartup and the retained messages on the MQTT topics generate Item state changes as the Items get recreated from the reload of the .items file.
I don’t know if this is still the case (I’ve been on managed configs for too long and changes/updates are much less disruptive with managed configs) but it used to be the case that when loading a .items file, all the system started/system runlevel triggered rules also get retriggered.
But none of the above is new. Thats how it’s worked since 2.5.
Which of the above are the cause here? There’s not enough information. I’d guess your rules trigger on Item changes and restoreOnStartup is causing those rules to run.
@rlkoshak as always, thanks for all your knowledge and quick reply.
i’m sure you know the basics about z2m, so for this issue its most likely not releveant at all, as for openhab its MQTT topics on my local MQTT broker.
and i guess you are right it will take retained states of the topics still at the server as an item status change when set from UNDEF to the value retained…
i’m pretty sure its not a new topic, but little annoying when i change items or update something in this item file i have a lot of action going on in my house for a few seconds…NUKI door opens, Radio turns on in the living room,…
Thanks a lot, not sure what i could do to overcome it. removing retained status for z2m messages…
Use managed configs. When you change one Item, only that one Item changes and it only changes instead of being deleted and recreated anew. This is much less disruptive.
Consider your rule triggers. Maybe you can filter out changes to ignore by using the from and to in the triggers.
Use if statements (or in managed rules use a but only if condition) to ignore changes from NULL or UNDEF where it makes sense to do that. That will filter out the restoreOnStartup triggers.
Carefully configure your rules to use commands, updates, and changes where appropriate. For example, if a switch toggles, that should end up as a command on the Item, not an update. And any rule that cares about that Item should trigger based on a command, not a change. restoreOnStartup only updates Items, never commands them.
See if there is some other event you can use to see if the changes/updates are something you can ignore.
Correct. In the UI when you change an Item, it only changes that Item. And it changes the Item, it doesn’t delete it and recreate it so restoreOnStartup never comes into play nor does retained messages come into play because the Item remains Linked to the Channel instead of becoming relinked to the Item because it’s recreated. The only thing you can’t change in this way is the Item’s name. You have to delete and recreate the Item to change it’s name.
Personally, I think this is the biggest reason to use managed configs of them all, but rarely mention it because text file users love to have to option to quickly “rename” Items for some reason (I put “rename” in quotes because, as already described, you are not renaming the Item in a .items file, you are deleting the old and creating a new one with a new name). But to me, using .items files (and .things files and .rules files) is like doing a knee replacement surgery to cure a scrape.
I use the UI only and I can rename items and things and even the rrdj4 persistence files and site map (which I don’t use anymore either).
I have a bash script I use whenever I need to do this, so it is not impossible to do.
I am sure the text file users could use that.
I ditched text files when I moved from OH2.5 to OH3.
I know it is not standard practice to do it this way and not supported but it works for me.
I suppose if you are going to use text files maybe make multiple text files and that way not all items get deleted and recreated.
You really are not changing the name. You are creating a new Item with a new name and adjusting the rest of OH to match that new Item. This approach will not work with InfluxDB for example, though I’m sure you could add to the script to change that too, it’ll have to use the InfluxDB API though.
But what it really amounts to is that you’ve automated the process of creating the new Item and adjusting everywhere the old Item was used to use the new Item. You haven’t really change the process.
And you cannot do it while OH is running.
That’s not necessarily a solution because if Groups are involved I think more than just the one file gets reloaded. I think there has been work on this front though.
The script goes through all the json files and changes every occurrence.
I only had rrdj4 persistence files and they get renamed as well so I don’t lose my graphs.
Yes, you cannot do it while OH is running. The script stops OH.
I cannot do that on the fly but I only did it a few times because I moved house and wanted to change the names of locations, items etc and didn’t want to delete and recreate everything.
Once that was done I haven’t used it since but it is good to know it can be done.
There’s not enough information. I’d guess your rules trigger on Item changes and restoreOnStartup is causing those rules to run.