Deprecated settings change in 0.79.4 breaks some state comparison tests

[dpgh947]

Describe the bug

I admit this is a bit of a niche problem. I had a few current state nodes with a numeric state test in them which broke on this level when setting the deprecated setting to "string" in order to remove the warning. The test was comparing a state (for example a light level in lux) against a value in an input_number helper, accessed by using the global context - for example selecting "global." in the pulldown and then 'homeassistant.homeAssistant.states["input_number.sideboard_light_threshold"]'. When you set the deprecated setting to "string" instead of "number", this comparison doesn't work. This may be to do with the value in an input_number having a decimal point in it, I don't know.

I had to change to using the "J:" pulldown and '$number($globalContext('homeassistant.homeAssistant.states["input_number.sideboard_light_threshold"].state'))'. I understand why, this is not so much a bug, maybe, as pointing out that there are some cases where this deprecation and eventual removal is going to break stuff.

Put another way, when using the global. or flow. (and possibly msg. too?) options in the pulldown to specify what is to be used in a numerical compare against the current state, I can't see after this change how to tell it that the data is numeric.

To Reproduce

No response

Expected behavior

I would say "it should just work", but I can't see how it can deduce in this case that the intended comparison needs to be numeric without me telling it, as I was previously by setting the deprecated setting to "number".

Screenshots

No response

Example Flow

Environment Information

Version: 0.79.4

Home Assistant version: 2025.11.1 Companion version: 4.1.3

Node-RED version: 4.1.1 Docker: yes Add-on: 20.2.1

Node.js version: v22.16.0 x64 linux OS: Linux 6.12.51-haos x64

Additional context

No response

[zachowj]

I am currently rewriting the conditional system that will be used across all nodes that support conditions. Entity state is one of the few condition types where you do not have control over the left side of the logic. In my initial design I planned to use the right side of the logic to automatically cast the left side to the same type. This is still a work in progress while I determine which approach will hold up best and remain manageable long term.

I understand that using Node-RED is meant to be less code and more click and select. For your current use case with the tools available today, you can switch the condition to full JSONata and use something like:

$number($entity().state) > $number($entities("input_number.sideboard_light_threshold").state)

Within the Home Assistant nodes there are custom JSONata functions that give easier access to certain data, such as $entities() and $entity().

https://zachowj.github.io/node-red-contrib-home-assistant-websocket/guide/jsonata/#home-assistant-functions

[deece]

I have similar issues with boolean state tests.

Neither "is (bool) true" nor "is (bool) false" matches unless state type is set to boolean.

I suggest the deprecation check be relaxed so that if the state type matches the type of the conditional, the deprecation is suppressed (at least until the conditionals work without state type being set)

[zachowj]

@deece If you want to compare to a boolean the same way it worked when State Type was set to boolean, use the in operator with Home Assistant State Boolean.

Set Value Type to Home Assistant State Boolean if you want to check whether the state matches one of your configured boolean values.

Home Assistant State Boolean comparisons are only available with the in and not in operators.

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

[deece]

@deece If you want to compare to a boolean the same way it worked when State Type was set to boolean, use the in operator with Home Assistant State Boolean.

Set Value Type to Home Assistant State Boolean if you want to check whether the state matches one of your configured boolean values. Home Assistant State Boolean comparisons are only available with the in and not in operators.

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

Thanks, is there reason why is/boolean can't be supported? That seems like the obvious choice for boolean-like entities such as binary sensors and switches.

[deece]

Hmm, selecting 'Home Assistant Boolean' as a type under 'in' won't let me select a value to compare against. I'm hoping it's a rendering error and not me misunderstanding how it's supposed to work.

[later] I had to re-read the link above a few times to understand what it's trying to say. I think it means that "Home Assistant Boolean" is a shortcut for the list of valid states considered true (on, open, present, etc) for different sensor types. IMHO I don't think this is intuitive, and would prefer that if a boolean comparison is selected, that the state is implicitly cast.

[systemofapwne]

I am currently rewriting the conditional system that will be used across all nodes that support conditions. Entity state is one of the few condition types where you do not have control over the left side of the logic. In my initial design I planned to use the right side of the logic to automatically cast the left side to the same type. This is still a work in progress while I determine which approach will hold up best and remain manageable long term.

I was just about to come here to propose your "implicit casting" idea. I am extensively using "If State" expressions in hundreds of nodes, where I compare to boolean or numbers. Implicitly casting the HA state depending on the operation and/or on the right side's type should be the most elegant way:

• <,<=,>,>=: Always implicitly cast to number.
• is, is not: Cast to right side's type (bool, string, number, ...) and perform the operation

[systemofapwne]

Hmm, selecting 'Home Assistant Boolean' as a type under 'in' won't let me select a value to compare against. I'm hoping it's a rendering error and not me misunderstanding how it's supposed to work.

[later] I had to re-read the link above a few times to understand what it's trying to say. I think it means that "Home Assistant Boolean" is a shortcut for the list of valid states considered true (on, open, present, etc) for different sensor types. IMHO I don't think this is intuitive, and would prefer that if a boolean comparison is selected, that the state is implicitly cast.

I absolutely agree here.

• There should not be a Home Assistant Boolean that mimics the behaviour of the atomic boolean type (why would one need two types that do the same?)
• With the current implementation of Home Assistant Boolean meaning On/Open etc (aka true) , we cannot check for false states that easily. One might consider the is not operation to help you out here, but "a number state also is not a Home Assistant Boolean". An explicit check for If State is false would now require a Home Assistant False Boolean (please do NOT add that!)

IMHO the Home Assistant Boolean type should not get exposed to the user. Cast to the atomic boolean tyoe with the same logic, that the now deprecated State selector did, if

• Output: entity state if as boolean is selected
• If State: See my previous comment