- Platform information:
- Hardware: _AMD CPU PC/8 GB RAM/ SSD
- OS: Win10
- Java Runtime Environment: zulu 11
- openHAB version: 3.1.0
- Issue of the topic: using 2 transformations on a channel needs to use the char “∩” (eg. REGEX and JSON) . It works well for a time and then the char “∩” is replaced by a “?” . After that, the transformation fails. After replacing the “∩” it works again until the next change to “?”.
Where are you looking at this?
Sounds like you need to make sure your environment is working in UTF-8
Windows , Java (Zulu 11) and OH3 are installed as default. I see ( and edit) via the standard openhab webfrontend ( xxx:8080) Is there any need to force UTF8? Why does ist work for a time and then fails?
I don’t know. What does “fails” expand to? Windows uses it’s own code pages and character sets, but I’ve had no issues in Win7.
Others have had problems not setting editors to save in UTF-8, but you’re not mentioning use of an editor.
I do not use any special editor, i am using the OH-Frontend ( http://xxx:8080) ! And in my opinion java uses UTF-8 by default. I do not edit any file manually. The files are created and written by Openhab (Java).
Okay. Can you tell us more about what “fails” look like?
In the field “Incoming Value Transformation” i am using the following expression:
"REGEX:(.*RC522.*)∩JSONPATH:$.RC522.UID"
- works fine for a while.
after some time the conversion fails and when i look at this entry, the text has changed to
"REGEX:(.*RC522.*)?JSONPATH:$.RC522.UID"
- so the ∩ changed to ?
Is it changing randomly or at a set interval or on a set day.
one way around this quickly would be to create the thing in a file so it can’t change.
what does that look like? Your openhab.log for that?
You may be focused on the ? but it might not be the best clue, it costs nothing to tell us more.
1 Like
openhab.zip.log (66.3 KB)
(please rename and unzip the logfile)
Line 11378 is the first WARN :
2021-07-09 16:13:08.106 [WARN ] [t.generic.ChannelStateTransformation] - Executing the JSONPATH-transformation failed: Invalid path ‘$.RC522.UID’ in ‘{“Time”:“2021-07-09T16:13:08”,“Switch1”:“OFF”,“Switch2”:“ON”,“BH1750”:{“Illuminance”:0}}’
This because the REGEX-Filter does not work anymore.
i cannot say, what triggers the character to change. Maybe it is related to the chaching ( when cache is written or read )
You’ve got JINJA transformation problems too, rule problems, rrd4j problems, and another MQTT channel struggling with on/off transforms, but that doesn’t look related.
It’s very curious. Let’s put together what we know;
It’s really unlikely some random thing is coming along and editing one particular character in your Things configuration JSONDB.
If it did, we might expect to see the Thing re-initializing in some way to use the “new config”. No sign of that.
Maybe the binding is updating the config, as it might do during discovery. No sign of that. There are a lot of MQTT users, many using this transformation technique, so far you are the only one with this issue. Not everyone looks in their logs for WARN though.
We do know the ∩ character gets displayed as ? is some character sets. So seeing that may sometimes be just a display artefact; equally, it may also get “put back” into the source during editing. You’re not deliberately doing any editing, but what might happen if a browser is left open on the channel edit page?
I think maybe I would check a few times when the transformation was not messing up, seeing if ? appears sometimes anyway.
Then there’s the nature of the problem; you have not said, but I guess the transformation is still working when you do get a MQTT message with the RC522 payload, and we’re just looking at a nuisance WARN here. Or no?
It’s a bit difficult to see how transformation config text could get garbled but still leave the second transform working, which is what the WARN says. JSONPATH is doing it’s thing properly (but not finding the RC522 field).
The answer on your last question is NO!. The RC22 (RFID-reader) is connected to a ESP8266 with Tasmota firmware and controls via openhab a garagedoor-opener. When the door-opening did not work anymore, i searched for the rootcause. The log from tasmota says, that it has read the RFID and sent an MQTT-Message. So i had a look at the related thing in openhab and found this strange change of the character ∩ to ?. So i changed this ? back to ∩ and saved the configuration (all in the OH-webfrontend) . After that, the door-opener worked again.
p.s.: i know the other warnigs, but the dont relate to that issue.
Okay.
What happens when you look at the related Thing in openhab when everything is working?
Transformation logging doesn’t tell us which channel it actually belongs to. Can we see your related Thing and all its channels? Can we see the sent message?
i dont know how oh-bindigs work ( i am not a developer) , but i can see wrong (german) characters in things, related to the shelly-binding. ( see picture). Is it possible, that the shelly-binding writes the whole things-file and missinterprets special characters using a wrong charset ?
There is no related output to the openhab.log when it works fine.
Still smells like codepage/encoding stuff.
Seems really very unlikely, but after all, we are looking for something we don’t understand.
So, on the Tasmota you have two similar channels listening to the same MQTT topic. In the log you provided earlier, both these channels produce a WARN. The log doesn’t tell us which channel, but we can work it out by the JSONPATH parameter.
You seem to be saying you only have to edit/save one of the channels to make it work?
That would make some sense, as the whole Thing would I think be reinitialized by any “save”.
Maybe next time, try edit/save something else - channel label, perhaps - and see if that recovers.
This is beginning to feel like a ghostly link issue. Maybe run this
Now i think to have the trigger for this character-change - as you mentioned to do the command for Removing an invisible thing, i stopped the windows-openhab service and startet the openhab directly to get the console - the command failed ( see pic)
After that, i closed openhab and started the windows service again and opend the webfrontend to have a look at the related thing - and! - the character ∩ was again converted to “?” in all related channels! So a restart seems to be the trigger for that change.
1 Like
And now - remembering OH2 i think to have the solution:
in the openhab-wrapper.conf the line “wrapper.java.additional.20=-Dfile.encoding=UTF-8” is missing.
I will add this parameter and look if it works. This parameter is not listed in the DOKU
1 Like