Hi,
it’s all about the warning jsonpath transformation is doing in the mqtt binding channel configuration. First, I know “all” the regex discussions in the past here and I have looked and read them up. But they doesnt work anymore in OH4 because if the regex doesnt match, it prints a warn message aswell. However, I dont want a regex filter before piping a jsonpath transform afterwards. I just want to suppress all INFO and WARN logs and just print the ERROR logs.
Thats the log which is created every few ms currently:
2024-01-31 10:56:29.918 [WARN ] [t.generic.ChannelStateTransformation] - Executing the JSONPATH-transformation failed: Invalid path ‘$.MT175.L2’ in ‘{“Time”:“2024-01-31T10:56:27”,“MT175”:{“L3”:116.00}}’
I can’t find the class to change the logging in the log4j2.xml file. I’ve tried “org.openhab.core.transform”, “org.openhab.transform.jsonpath” and a few others including try and error wildcard stuff like mqtt or jsonpath etc.
I’m not certain this is correct. I’ve set up a test and I cannot reproduce this behavior. But if the behavior has changed, that’s a regression and needs to be fixed. Not worked around through the logs.
But on OH 4.1.1 Release with the following MQTT Thing:
UID: mqtt:topic:broker:regexTest
label: Regex Test
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:broker
channels:
- id: number
channelTypeUID: mqtt:number
label: Number
description: ""
configuration:
stateTopic: test
transformationPattern: REGEX:(.*foo.*)∩JSONPATH:$.foo
When I publish
{"foo":1234}
The Linked Item updates to 1234 as expected.
When I publish
{"bar":54321}
The Item does not change and there is no error in the logs, as expected.
If you are seeing an error from the JSONPATH, the problem isn’t that the REGEX filter doesn’t work at all any more, it means the specific REGEX filter you are using is either not filtering out all the JSON strings that your JSONPATH cannot handle, or you’ve not created the REGEX expression to pass the full JSON to the JSONPATH when the match is made.
And that is in fact the case here. Your JSONPATH is $.MT175.L2. Your JSON is {“Time”:“2024-01-31T10:56:27”,“MT175”:{“L3”:116.00}}. There is in fact no L2 element, it is L3. So what’s your REGEX expression that allowed this JSON to get passed to the JSONPATH?
why? does the change of log:set command persist?
But thank you! It works perfect
@rlkoshak sadly I cant tell you anymore the pattern. I’ve configured it in the UI mqtt channel configuration Transform Values → Incoming Value Transformations. Of course the logs were already overwritten after some minutes/hours so I cant paste the regex warn message anymore. But it was different to the message in my entry post and in general the regex worked (firstly check at online regex checker and secondly I saw that the values gost parsed into the item)
Ultimately, all I can say is the REGEX filter does work where chaining is allowed. If it wasn’t working for you, you likely had a configuration error. If you’ve gotten rid of that configuration .
Just be aware that if you change the logger to not print the error, you won’t get errors from any MQTT Channels.
The regex pattern did work, but provided a warn message aswell, if the pattern did not match.
I still receive error logs from mqtt binding channel transform class, but not the warnings. And then jsonpath provides a warning and not an error of the key doesn’t match. I’m fine with this configuration. It’s what I want.
Then it wasn’t configured correctly. I cannot reproduce this warning message. There have been no changes to the REGEX transformation since OH 3.4 (probably before), at least none that I can find that are relevant.
I’m happy you have what you want. But I cannot let rumors that the REGEX filter is no longer working remain unchallenged. People will start to make radical and unnecessary changes to their configs and flooding the forum asking for help trying to fix something that isn’t broken.
Or if it is indeed broken in some edge case you’ve encountered, it needs to be fixed. This is a needed functionality. But since I cannot reproduce it and you cannot or will not show your config which could help reproduce it, . Without more evidence all I can conclude is it is not broken.
.