Incoming value transformations
REGEX:(.*nrf1t1t*)∩JSONPATH:$.sensors.nrf1t1t
Applies transformations to an incoming MQTT topic value. A transformation example for a received JSON would be "JSONPATH:$.device.status.temperature" for a json {device: {status: { temperature: 23.2 }}}. You can chain transformations by separating them with the intersection character ∩.
My incoming incoming JSON does not have everytime json value - nrf1t1t and i get warnings in log if incoming json does not have this value. I want to reduce warnings using RegEx but my transformation does not work correctly. The warning apears in log. Wha i do wrong?
I just tried to set it up the same way and it looks like the behavior of the REGEX transform may have changed since the OP was posted. It looks like previously the REGEX transform would return nothing if there was no match. Now it appears to return everything if there is no match.
Good spot. Be interesting to see the outcome - while it was certainly convenient the way it worked before, it felt a bit out of character for a transform to “fail” silently.
Maybe there needs to be some way to distinguish -
“this is a filter, null output is tolerated”
from
“this is an ordinary transform, null output is unexpected”
channel profiles seem like a good place to do this kind of thing, perhaps benefiting other bindings too. Obviously they don’t support chaining yet.
But that is probably too far down the processing.
I agree, but on the other hand, it also makes sense that the we may expect a transform to return nothing on occasion. And if it does return null, it seems equally correct to pass on nothing rather than passing on the full message to the next transformation.
I do like any idea that involves Profiles over changes to bindings. I’d like to see transforms completely removed from the bindings so that all bindings can benefit. IMHO, they should have been separate from the bindings from the start. I’ll never get my wish though and that’s OK too.
But in the case of this particular binding, there is one capability of the MQTT 1 binding that requires this ability to filter in order to have feature parity, the ability to filter.
When you look at the use case used in the OP, the only way to handle that is to filter the messages.
I ran a test. When you use the REGEX transform in a Rule and there is no match it returns null. So this does appear to be a change in how the MQTT binding handles the fact that the transform returns null. If the change was to the REGEX transform itself then I would have received the full message back instead of null in the Rule.
I also looked at the code for the REGEX transformation and there is nothing there to cause it to return the full message when there is no match.
The HTTP binding doesn’t support chaining transformations. But if the binding uses the full message if the transform returns null than that too is the choice of the binding on how to handle the null and not the result of the transformation code itself.
Thanks @rlkoshak for this solution and for following up on the “bug”. I just discovered this (thanks to you) while on 2.5M5 and it seems to be working, i.e. the REGEX transformation will not return the full string upon non-match.
I wish that chaining the REGEX in front isn’t necessary and that only using JSONPATH alone would give us the same result (i.e. suppressing the warnings). Would that not be a good idea?
Given that the JSONPATH transform has worked the way it does pretty much forever and it is a very important transformation for many bindings and even used internally by some bindings I think, and change like this would have a huge impact on both the code and users and almost certainly be a breaking change that impacts thousands of users.
It looks like you are using a Things file. Maybe there is something unique about how you need to write it there. In PaperUI you would not surround the whole expression with “”.
