filtrex expressions

[bartbutenaers]

Dear,

As discussed in this issue I have integrated filtrex expressions into the Sensor node config screen.

Note that I have included version filtrex version 3.0.0-rc11 as a dependency. That is a release candidate version, but the author has planned the final 3.0.0 version in the near future. I needed that version because the author has been so kind to implement boolean values and nested expressions for us. So you can now use for example "msg.payload == true", similar to the current dropdown value in this node...

Note that this pull request determines (based on the input message) whether the expression is true or false, but that value is NOT used to filter messages for alarms. Reason why I haven't implemented that in this pull request, is that it is also not implemented yet (see here). Moreover I don't know if/how you want to implement my other feature request. Because when that would be implemented, the message always has to be processed (but the filtrex expression result value would only be used to determine whether an alarm should be triggered or not). So I propose to keep that for a separate discussion...

This pull request also offers an extra server-side endpoint, which can be called by the frontend (config screen in flow editor) to do some (basic) real-time syntax checking:

I have tried to make sure that existing nodes are not impacted, by automatically converting the old dropdown values to corresponding filtrex expressions in the following situation:

• on the client side, which is triggered when the config screens opens after the user has double clicked the node.
• on the server-side, which is used in case an input message is injected but the user hasn't opened the node's config screen.

If you would like to test this backwards compatibility, the easiest way to do it is by adding a bunch of sensor nodes on the flow (when still using the old version). Then install the new version, and test the old nodes in the above described two scenarios....

Hopefully you like it, because it was quite some work to implement it.
Thanks for reviewing !!
Bart

[macinspak]

This looks great, very clean. I've not tested, but happy to go on your say-so. Is it working really well for you? I presume so.

Great job with this, keen to try it out on my install soon after updating also.

Thanks again (on behalf of all users of the library), and I will have a look through the other proposals as well. Great to have another enthusiastic maintainer on board!

Regards,
Andrew

[bartbutenaers]

Hi Andrew,
Sorry for the delay ...

I have pushed an extra commit to handle invalid expressions and invalid input (i.e. input which is not expected by the expression) better.

Have done some extra testing and added the test results below, so you can get an idea of how it works.

Note that there are still some things todo:

1. The trigger value is not used yet to pass or stop input messages.
2. The readme page should be updated to have a link to the Filtrex readme page, so people at least know what is possible with the expressions...

Example 1

When one of the nested properties is undefined, it will not crash but instead the entire expression will become false:

Example 2

Example 3

When the input message contains invalid/unexpected values (e.g. "5" instead of 5):

Then I consider the expression as false: