State type is deprecated and will be removed in version 1.0

[Mikefila]

Yes change it to a string

[Kermit]

@Biscuit

In an Event:state node, using JSONata as the condition test-option, yes the return from $entity().state is a number when State Type is “number”, and a string when “string” [and boolean likewise]. Using the raw returned value thus has to change, for example $entity().state>300 works for “number” but generates the expected JSONata error,

The values “351” and 300 either side of operator “>” must be of the same data type

and needs changing to $entity().state>"300" or alternatively $number($entity().state)>300

I agree that almost no-one will be doing this, but I mentioned it just in case.

Comparing strings like $entity().state > "300" isn’t doing what you might expect. In JavaScript, when both sides of the comparison are strings, the comparison is lexicographic, not numeric. So "2" > "10" evaluates as true, because "2" comes after "1" when compared as text, not as numbers.

You can test this yourself here: https://try.jsonata.org/nDUyMOXNj

[Biscuit (Geoff)]

Oops, yes. Corrected, thanks.

Possible to compare string time (hhmmss) and date (ddmmyyyy) as strings but only if they are fully formatted with leading zeros and ordered.

[Canedje]

I changed the node to:

But then as the PIR is triggered it is not triggering the next node anymore.

If i change state type to boolean again it is working again.
What do I need to put into the new state node to get the next node triggered again?

[Biscuit (Geoff)]

“If State” >
is >
you are testing for true. However, this probably does not work since the HA state value will now be the string value “on” or “off” for a motion sensor, so you now have to test for: string as on.

Also:
The output properties >
The entity state >
The as boolean >

should be as Home Assistant boolean

This is a now difference, see notes above. Unless you have a particular reason to, use “as Home Assistant boolean”, not “as boolean”, for the entity state to be cast as before the change.

[Canedje]

Thanks for the answer.
It is working.

I only don’t understand why the outputproperies should as Home Assistant Boolean and not also string?

[Biscuit (Geoff)]

You can certainly set the Output Property to string
msg.payload = entity state as string

Before the change, using the State Type set to boolean would mean that msg.payload, on leaving your node, was either true or false

After the change (State Type set to string) msg.payload on leaving the node will be

• “on” or “off” if the Home Assistant state was “on”/“off”, and you set the entity state to as string
• true or false if you set the entity state to as Home Assistant boolean
• false all the time if you set the entity state to boolean

The question is, do you use the msg.payload value after this node?

• no, then it does not matter what the setting is
• yes, then it does matter what the setting is

You could probably just delete the three output properties if you don’t use msg.payload, msg.data, msg.topic… It all depends on what happens later in your flow, which means I actually can’t answer your question.

[poldim]

thanks for making sense of this for me!!

[Oscar1]

THANK YOU SO MUCH
The number of “errors” had me in shock for a bit.
It’s so good to know that my numeric comparisons will still be done on the input.

I don’t understand why this will benefit people after version 1.0
The node internally still does the conversion from “string” that was sent over from HA to the numeric value.
Do you know or expect what the user will see in future release, where we now select
string
number
boolean
.* regular expression
J expression
flow.
global
entity

Will we still be able to compare the HA string to a flow variable for example?

Thanks again

[Biscuit (Geoff)]

I notice today that the Node-RED add-on update to 20.1 is out, and this bundles in the latest v.0.79.4, so I am guessing that there will be many similar surprises over the next few days!

As for the why and wherefore, you need to ask Kermit, not me!

In the past the settings allowed for casting the state up front, meaning that the node was working entirely on a different state (number) to the real HA entity state (string). OK if you kept track of what was going on.

In the If State settings it was possible to set to test a number against a string literal, which does not work. In the new arrangement, you can test using the numerical operators - < > = etc and the node then forces you to use a numeric literal (no string option is available) and the node does the work of locally casting string state to number in the background, and just for this operation.

As this is moving towards a situation where the/some/all impossible settings cannot be selected, it must be better I would suggest.

Enjoy!

[Mikefila]

@Biscuit

here will be many similar surprises over the next few days!

If I understand correctly you can no longer click outside the node settings panel to save and close it. You must click the save/cancel button to close the panel. I am not looking forward to that.

[Biscuit (Geoff)]

I updated my development Raspberry Pi to the latest Node-RED v4.1.0 and node.js to v22, and yes you can’t close a node edit window except by clicking on save or cancel.

I am still constantly clicking outside the window to close it (cancel) and nothing happens. It will take a long time to get used to this change…

[Tom-Heitbrink]

Still confused about what this means for current state checking on numeric values.

How do I test the situation where the temperature has to be above 10 degrees to trigger the next action?
A temperature of 2 degrees will trigger it since 2 is higher than 1.
I can specify the number of digits on the right side of the equation, but not on the left side (defined by the integration)…

[Biscuit (Geoff)]

When, in the conditions, you use one of the numerical operators, such as “>” the right hand test value options do not permit a string. So you have to enter a number, as you are doing.

The node now (as I understand) does the work of managing the comparison between the entity state (string) and the condition literal (number) by, in this situation, temporarily turning the state to a number.

This removes the opportunity for error, since now all states are strings, and literals are typed according to the condition operator used.

In the past, we had to think
“I am testing the entity against a number 10, using > so I have to change the entity state from string to number myself in the State Type”

Now the node will cast the entity state automatically as and if required, for each condition.

Numerical operators work as expected, so 2>10 is false (even if the entity state is actually “2”).

String comparisons are certainly another matter.

It certainly works for me.

[Nerdix]

Well, this still let’s me struggle a lot. I have a lot of checks like this with a boolean comparison in the “If State”, and it obviously does not work as expected now:

I would expect that an entity state “on” results in a positive result, but it runs into the wrong path:

when doing the comparison string-based, it works as expected. But I am hesitant to adjust all my 170 places where i do a boolean comparison

Is this a bug or am I missing something?

[Biscuit (Geoff)]

The node is doing what it should.

The entity state is now a string “on” or “off”
The condition should now be tested against “on” not ‘true’

The only part of the data in the node that is ‘true’ is the output property msg.payload, as the entity state string is only cast to a Boolean value at the very end, using the settings you have.

[Nerdix]

Ok if this is really the case I have to adjust all the occurrences of Boolean comparisons

That more or less means this entry is useless, I thought the mapping from home assistant values would not only affect the output but also the comparison:

[Mikefila]

@Nerdix

all my 170 places where i do a boolean comparison

You might want to think about editing the flow file. Copy flows.json from the addon config folder.

I did a quick comparison of a current state node only, event state etc may be different. It seems you would need to search for

"halt_if": "true",
"halt_if_type": "bool",

and replace it with

"halt_if": "on",
"halt_if_type": "str",

[Nerdix]

For sure it will be possible to adjust all the places, but if this is what we have to do I feel this is not an improvement.
It’s not just changing “on” comparisons, it’s also all the others which were converted to a Boolean automatically before:

Now I have to take care of comparing the state string correctly which was done for me in the background previously

[sender]

When

I get:

And as soon as I change it to string there’s nothing. I tried a few thing but don’t know what to change when changing the deprecated from string to number…