"events: state", "trigger: state" - node: unclear replacement for deprecated state_type (conversion fails in 0.79.0)

[marc965]

Hi,

in version 0.79.0 of node-red-contrib-home-assistant-websocket, the events:state and trigger:state node still contains the State Type option (string | number | boolean).
When this is set to number, everything works correctly, but the editor shows the deprecation warning:

“This feature is being phased out and will be removed in version 1.0.0. Use the output properties for state conversion moving forward.”

If I set state_type to string (to remove the warning) and try to perform the conversion via Output Properties, there seems to be no working alternative in v0.79.0:

Using Value Type: number requires a fixed number (not entity.state).

Using Value Type: expression with $number(entity.state) returns undefined.

Using Value Type: entityState outputs the raw string value (e.g. "23.5").

So currently there is no functional way to get a numeric output without the deprecated option.

Could you please clarify how this conversion is supposed to work in 0.79.x and what the intended replacement syntax will be in 1.0.0?
Thanks for your great work on this project!

[zachowj]

In the output properties, when you select entity state as the type, the dropdown beside it includes options such as as string, as number, and others. Choosing as number applies JavaScript’s Number() function to convert the state to a number.

This applies only to the events: state node. For the trigger: state node, there isn’t a built-in way to change the type for default outputs, but for custom outputs, you can use JSONata (J: Expression) with something like $number($entity().state). You were close in your earlier tests.

The trigger: state node will move into legacy mode before version 1.0 is released since the events: state node already handles similar functionality, and it will gain support for multiple conditions before v1.0.

There’s also a small bug when adding a new events: state or current state node to the workspace where the default type is set to boolean instead of string. This was unintentional and will be corrected in the next release.

[marc965]

thanks for your answer.
is it normal that the warnings "home assistant nodes with issues" is not reset when the nodes are updated?

[rolandsteinmeyer]

What you’re seeing is the core of the breaking change. Entity states will no longer be cast to the selected “state type” before conditions are evaluated, and there wasn’t a practical way to make this change backward compatible. This simplifies how conditions are checked, but it means you’ll now need to compare directly against the actual entity state values, for example, "on", "off", "open", or "closed".

https://zachowj.github.io/node-red-contrib-home-assistant-websocket/guide/breaking-changes.html#removed-state-type

I see your point. That´s why I suggest a new comparison option "Home Assistant Boolean" that compares against typical HA boolean states regardless of device_class and will catch "on", "open" etc. That would really be much more obvious to users when they migrate the flows

[zachowj]

Yes, I think that’s an option that could be added.

[Boss-man]

Basically it's HA that's not using true true/false, but is actually using strings.

So even if I have a template sensor like this:
{{ is_state('person.user1', 'not_home') and is_state('person.user2', 'not_home') }}

that returns true or false in the template editor, the binary sensor itself is on/off, and so is also on/off (as string) in Node-Red

[zachowj]

Yes, in that case the binary sensor state sent to Node-RED would be "on" or "off". You can confirm this by checking the States tab in Developer Tools in Home Assistant and finding that entity to see its actual state.

Numeric entities are handled as numbers inside Home Assistant, but when they’re serialized and sent over the WebSocket connection, they’re converted to strings. I haven’t looked at that part of the Python code in a while, but that’s how I remember it working.

edit:

So, binary sensor state is boolean internally in Home Assistant but when the state is requested is returns a string "on" or "off"

https://github.com/home-assistant/core/blob/73c941f6c5573b683c4d50402c1120cf35999bfe/homeassistant/components/binary_sensor/__init__.py#L196-L202

[AndreiArdelean1]

@zachowj Would it be possible for the node to automatically convert the entity state for comparison based on the selected If State value type (string, number, boolean, regular expression, etc.) and only if a value is introduced?

For example, if the If State type is set to number, the node could cast the entity’s state to a number before performing the comparison (while still outputting the raw data). Similarly, if the type is boolean, it could use Home Assistant’s standard mappings (e.g., on / off, open / closed) to determine the boolean value.

Alternatively, if that approach isn’t feasible (e.g., the node doesn’t have all the necessary data), could a new if_state_type option be added that applies only to the If State comparison, leaving the output properties and payload unchanged?

This could simplify migration for existing flows while keeping comparisons consistent with the selected type.

[zachowj]

Version 0.80.0 adds the ability to compare an entity’s state against the Home Assistant State Boolean list from the server config. To use this, select the in or not in operator, then choose Home Assistant State boolean from the value type dropdown.

https://zachowj.github.io/node-red-contrib-home-assistant-websocket/guide/issues.html#updating-if-state-conditions

[rolandsteinmeyer]

Another gotcha that might be related to the change: state node that has comparision againt a home assistant zone (which counts the number of occupants of that zone). I can compare if State zone.home > numeric 0 (at least one person is at home). But there is no option to comapare if state = numeric 0 (no one at home). When I uses comparision if state in (numeric) 0 this does not lead to the expected behaivior. Only thing that works is if state is string 0. This is kind of odd.

[zachowj]

Can you create a new issue so i remember to look into why this is happening?

[rolandsteinmeyer]

see here

[Dakhaasje]

What happens if I do not 'fix'these?
I don't get why there is suddenly a problem.
my nodered primarily does the rf2mqtt translation.

Seems that the HA parts I can now delete again and go back to the stone age when all worked fine independent.

fixed them like this : oldschool.
``

[
{
"id": "3a4d543ea9c5bec3",
"type": "mqtt in",
"z": "e8c1d00af083fb50",
"name": "",
"topic": "home/ha/light/straler_socket_1/state",
"qos": "2",
"datatype": "auto-detect",
"broker": "9033341cee3a15e6",
"nl": false,
"rap": true,
"rh": 0,
"inputs": 0,
"x": 980,
"y": 3280,
"wires": [
[
"141b68d93b73cdf0"
]
]
},
{
"id": "c6ff5f244a52ca7b",
"type": "change",
"z": "e8c1d00af083fb50",
"name": "glo-straler",
"rules": [
{
"t": "set",
"p": "straler",
"pt": "global",
"to": "payload",
"tot": "msg"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 1420,
"y": 3280,
"wires": [
[]
]
},
{
"id": "141b68d93b73cdf0",
"type": "change",
"z": "e8c1d00af083fb50",
"name": "on=true",
"rules": [
{
"t": "change",
"p": "payload",
"pt": "msg",
"from": "off",
"fromt": "str",
"to": "false",
"tot": "bool"
},
{
"t": "change",
"p": "payload",
"pt": "msg",
"from": "on",
"fromt": "str",
"to": "true",
"tot": "bool"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 1240,
"y": 3280,
"wires": [
[
"c6ff5f244a52ca7b"
]
]
},
{
"id": "4e41eb05a7a9dcbd",
"type": "inject",
"z": "e8c1d00af083fb50",
"name": "",
"props": [
{
"p": "payload"
}
],
"repeat": "",
"crontab": "",
"once": true,
"onceDelay": 0.1,
"topic": "",
"payload": "false",
"payloadType": "bool",
"x": 1190,
"y": 3360,
"wires": [
[
"c6ff5f244a52ca7b"
]
]
}
`]```

npm remove HA

[AndreiArdelean1]

Hi @marc965,

Would it be possible to apply the same logic used for number comparisons (commit 3bede3ec
) so that when the comparatorType is is or is_not and the comparatorValueDataType is boolean, the value is first converted to a Home Assistant Boolean before performing the comparison?

I know there’s already an in / not in comparison option that handles Home Assistant Booleans, but having this logic also apply to the is / is_not comparator would make configurations clearer and reduce the likelihood of misconfigurations.

Thanks for your work, it’s much appreciated!

[jbhorner]

I received 11 warnings today after updating Node-Red in Home Assistant. Every single one of them had the message, "Warning: The 'State Type' setting will be removed in version 1.0. Please update your configuration accordingly." Every one of these is for a numeric output (light level, temperature, humidity). I'm at a loss as to what I could possibly change them to.

This feels more like a regression / defect versus a rationale of a correct path forward.

[rolandsteinmeyer]

You probably missed this. So just invest 5 minutes of your time and move on. (I had 150 nodes to adjust)

[moyuehan]

Hi @zachowj I did the update Node Red 20.0.0 to 20.2.2 yesterday evening and found my Node Red program filled up with 248 warnings and 6 errors. The warnings are similar to @jbhomer. 248 times I replaced the suggested state type "string" by "number". The warnings did not disappear. By using the 3th small icon on the left (the eye) they were still there but no longer counted for. The errors however I could not solve at all and I have no solution for this : I receive a message " the entity ID is not unique". When I look in HA the ID's are unique.
As my automation was not working anymore, I decided to restore the backup taken before the update. Now all runs smoothly again. I decided to "skip" the update to 20.2.2. If there is any information you need, please let me know.