Closed bartbutenaers closed 1 year ago
macinspak
commented
2 years ago 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
commented
2 years ago 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:
When one of the nested properties is undefined, it will not crash but instead the entire expression will become false:
When the input message contains invalid/unexpected values (e.g. "5" instead of 5):
Then I consider the expression as false:
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:
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