I am using openHAB 2. I view the log, but the settings do not show all the text, it truncates the text on the left, effectively right hand justifying. Here is information on my settings, the file and an example of the text.
2022-06-11 09:00:42.281 [vent.ItemStateChangedEvent] - InTemp changed from 84 to 85
So, the first word in the bracketed information is “vent”. That is short for “Event,” I trust. I am trying to implement a manual override and need to see the complete description to make sure that my code correctly identifies the source of the command so that the manual override will work properly.
Is there an easy way to expand the bracketed text so that I can see the entire entry. There has to be a simple setting limiting the displayed text. Alternatively, is it easier to have a separate log output that is customize to have a longer text string?
Perhaps you need to elaborate more on what you are doing because I can’t think of any case where watching events.log would be the best or even a good way to implement a manual override.
That part of the log statement is defined in $OH_USERDATA/log4j2.xml (I think it was XML back in OH 2, maybe it’s still .properties.
The [%-36.36c] part of the pattern layout defines how much of the class that generated the log statement is shown.
But every single ItemStateChangedEvent comes from the same class no matter what Item the event came from. If you expand it in the log4j2 config, all you’ll discover is that they all read something like org.eclipse.smarthome.core.items.event.ItemStateChangedEvent (IIRC, in OH 3 it’ll read org.openhab.core.items.events.ItenStateChangedEvent). A command would show org.eclipse.smarthome.core.items.event.ItemCommandEvent. Updates do not by default appear in events.log.
events.log shows the activities of the event bus so no matter what Item or Thing generated the event, the log comes from the same class. So the 36 characters you are already seeing in that log statement is already the unique part of that field. Expanding it is not going to give you any additional information.
Because openHAB is event based, you don’t need to look at events.log anyway to trigger a rule. Any rule with an Item InTemp changed trigger will run when a statement like the above appears in events.log. So why not just use the event directly instead of indirectly by watching the logs?
Furthermore, a manual override implies a state (i.e. the behavior is automated or overridden), not an event. So a more straight forward approach is almost certainly to have a Switch Item to represent the state, a rule that triggers when conditions change such that the mode needs to change and updates the Switch accordingly, and rules that implement the behavior check that switch first to see if it’s overridden.
Thanks. You are correct, I am fumbling around and was hoping I could see in the log what initiated the event and I was planning to use that to create the rule that would trigger the override. For example, I see ItemComandEvent, ItemStatePredictedEvent, and ItemStateChangedEvent when I use the UI to change the state of a switch. I was hoping that by seeing more of the log, I might be able to draft a better rule to design an override. So if a rule changed the switch state it is treated differently than if the UI changed the switch or the switch itself was manually triggered. I probably need to spend energy learning more about modes and states.
The use case is to permit overriding a fan by pressing the on/off WIFI wall switch or by triggering the switch through the user interface. If either happens, it would stay in the override state for a set period of time and then the automated system would take back over.
See Design Pattern: Manual Trigger Detection for several techniques. Determining where an event came from is challenging in OH. The most foolproof is the proxy Items approach described at that link.
Thanks. I had seen Design Pattern: Manual Trigger Detection, but I was confused because one of the solutions depended on the use of a better naming convention than I have. I used code to change a proxy when a rule sent a command. Then I could compare the state of the thing to the proxy. If they were the same, the rule starting or stopping the fans was in control. If they were different, then I implemented an override timer that stopped automation from controlling until after the time for the override was over.
