RPI 5 running Opehhabian version openHAB 5.1.0.RC2 Milestone Build
All devices using Z-Wave on a gen5 Aeotech Zstcik
I’ve run openhabian-config and it will not upgrade past that. I can see there is a version to upgrade but it holds it back as if it thinks I’m on a 32 bit RPI and won’t install V5.
And maybe solving that would solve this. When I use the Event viewer on the Developer sidebar for every event I get many many identical lines of the same message, sometimes up to 50 or more. Why might I get so many duplicate messages? It’s almost as if eventually the queue fills up and no messages can be added and Openhab stops working or works very slowly.
Can you post a screen shot or a copy a few of the events. Of particular interest is the timestamps of the events that appear to be duplicated.
Look in events.log. What are the sources of these events? The source was recently added to the events to trace these.
In all likelihood these are real events, not just being duplicated in the event monitor. Perhaps there is an infinite loop. The MQTT binding has a setting that I guess may have changed which can cause loops. The Items that are generating a lot of events, look to see if they are linked to an MQTT Channel and if so, make sure “postCommand” is disabled.
The source of the events in events.log should help identify which rules.
I was trying to make a couple of dimmers work like on/off switches and I was apparently trying to be to clever. The code is now much simpler and works as long as the dimmer stays at 100%. I was trying to deal with my wife occasionally holding the button long enough to turn it to 10% or so which seems off, but isn’t and leaves on and off looking the same. Below I’ve attached a Z-Wave trace of a light controlled by a switch being turned off using the OpenHab web page to control it. That trace is very verbose, far more than I need. Is there a way to make it a bit less verbose. There are 11 pieces of information for that action and I really only need one.
This is from the developer sidebar event stream? You can filter the events based on type. But all of these are the events on the Item, and they could be relevant..
Item was commanded, that’s an independent event
Autoupdate is enabled on the Item so it predicts what the new state of the Item will be based on the command (commands never update the state of an Item themselves)
Autoupdate issues an update to the Item, this is the request to update the Item
The Item was updated (this is the event that could trigger a rule with a state updated trigger), this is the result of the update
The Item’s state changed as a result of the update so that is reported as a separate event (this would trigger a rule with a state changed trigger)
The device has reported back that it’s done what the command asked it to do so the binding sends an update to the device
The Item finsihed updating
8.-11. For some reason two more state updates are sent to the Item.
You can also look in events.log which does not show any of the ItemStateEvents nor the ItemStateUpdatedEvents and only shows the commands, predictions and changes. But more importantly, the log also shows the source of the event. Depending on what you are debugging, the log might be a better option over the raw feed from the event stream.
To filter the event stream by clicking the cog icon. The first line is the “topic”. so, if for example you wanted to only see stateupdated events on the all Items you could filter on openhab/items/*/stateupdated.
So I opened up the Event Monitor and added “openhab/items/*/stateupdated” to the Filter Topic dialog and it made no difference in the display. Nothing I’ve ever put there seems to do anything. Does it work? Is there some magic incantation I need to do? Here’s what that looks like in case I did it wrong.
