Support converting (state) values

[RobertMe]

Is your feature request related to a problem? Please describe.
Currently when using for example the events: state node and the underlying entity is for example a binary_sensor or input_boolean you get an on or off value as string, and the same for sensors which have numbers as state which also get the value as string. This means later on in the message sequence you most likely need to handle this specifically. A switch needs == 'on' instead of is true, when using JSONata expressions you need to use $number() etc.

Describe the solution you'd like
I think it would be nice if the Events: state node etc have a dropdown from which you can select the payload type you like to use. So the default can then still be string which contains for example the on/off etc, but that you could also select Boolean and you get true/false as payload value. An extra option would then be to have a Number choice which converts numbers and so on.
In case a conversion fails (because of for example selecting the wrong type) I think no message should be send. The same as when using a switch node with a JSONata expression, which also is neither true nor otherwise when for example doing "1" < 2. If this case should result an in error which can be handled using a catch node is up for debate (switch + JSONata don't seem to do this).

Describe alternatives you've considered
As described above you can work around it by using == 'on', $number() etc. But I think that converting the values beforehand would reduce the chance of bugs, and speaking for myself when I started using this module (or actually the REST version) I expected the values to be already of the "correct" type, so binary sensors and input booleans being true or false, other (numeric) sensors containing a number, etc.

Note: if this is a desired feature I most likely will be able to make the necessary changes myself, but if this feature isn't accepted, or some other direction is requested, I'm of course not going to spend my time on making the changes first.

[zachowj]

I don't see any negative reasons why we can't add this in. It probably could work with the events: state, trigger-state, poll-state, and current-state nodes.

How do you see the output handled? For the events: state and trigger-state nodes the 'current state' is buried inside the event object msg.payload.event.new_state.state. Were you thinking of replacing that value with the converted value or something more like when boolean or number is the chosen conversion method move the whole payload object to msg.data and then just make msg.payload the converted value?

You're more than welcome to work on this feature or I can add it to my todo list.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[zachowj]

#48 adds this