HA Node-RED Integration - Strings, everywhere STRINGS!

Hi there,
I´m making heavy use of the Node-RED integration to create all kind of diverse flows. One powerful way of doing this would be making use of all the different entity states that HA constantly keeps updated within its global variables.

For what reason ever, HA decided to make all these values being formatted as “strings” which makes it almost impossible to make use of them in any sense making way (see example below) :unamused:. Anybody here had the same problem and found a smooth workaround for it (obviously beside implementing a bunch of “event: state” nodes updating self created global variables).

You can cast it to number using a function node or just multiply with 1.

1 Like

Sorry, not an answer but two questions.

Why not using the “current state” node when you need it?
What is your use case where this would be useful?

With HA and NR “linked”, it is easy to know the state of an entity when and if needed…

Hi @greengolfer, let me try to briefly address your questions.

For every room in our apartment, I have sensors installed that measure temperature and humidity (in fact they measure even more but that´s not relevant in this context). I also have at least one Alexa echo device in each room. My use case now is: As a HA user, I want to request the climate information from the room I´m currently in using my Alexa devices. If you need to use a “current state” node for each climate information in each room, you end up with something cumbersome like this:

Now to the second part of your question:

Unfortunately, it´s not that easy to know the state of an entity, as HA is storing all entities states in global variables as floats (see example above), which totally doesn’t make sense when you want to make use of numeric operators.

I think I don’t get it…
With one flow and using the room name as a variable you can query all sensors from that room (assuming you have a consistent naming convention) and then, you can do what you want.
And if you sensor output is a number using the current state node and selecting “state type” number as output then your payload will be a number. You can do the same with a state node.
I guess I must miss something obvious…
But trying to mimic all HA sensor states as global variable in NR seems rather an unusual request…
Hope someone clever than me will provide useful help and not theoretical questions :slight_smile:

Current state nodes accept inputs so there is no need for something that big.
If you pass the entity in the message to the current state node then it will respond with the values of this entity.

And even without a naming convention as greengolfer suggested then I believe you can use get entities and use the room attribute.

Hey guys, I never thought this post would become that controversial, but let´s get to it :slightly_smiling_face:

This is not a request. Home Assistant already DOES offer the state of all entities as global variables. In general, this is very useful if you make significant use of function nodes within your flows as you can directly consume the information from there and don´t have to create a “custom” variable for each and every needed entity on your own. However, the way they implemented it is very poor, as all entity states are being formated as strings, so you have to convert them into float/ int in order to use them properly (thanks to @Hellis81 I now know how :slight_smile:

Let me show you a comparison of how the guys of my second Smart Home system “homee” managed to make the NR integration way more useful in that sense:

Hope that helps to make my point clear. Anyway, as stated already, with the little extra loop of turning the HA variables into float within the function node, my use case is perfectly solved :slight_smile:

While I understand your point that you want to access all values directly inside a function node I think you didn’t get what we said about the current_state node.

Your picture shows state-change nodes not current_state ones. You would only need one current_state node like this:

[{"id":"3b6d2e6.bcde2d2","type":"api-current-state","z":"cc639dbb.119d5","name":"","server":"44b2605f.5d41","version":2,"outputs":1,"halt_if":"","halt_if_type":"str","halt_if_compare":"is","entity_id":"sensor.{{room}}.temperature","state_type":"num","blockInputOverrides":false,"outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"entityState"},{"property":"data","propertyType":"msg","value":"","valueType":"entity"}],"override_topic":false,"state_location":"payload","override_payload":"msg","entity_location":"data","override_data":"msg","x":680,"y":120,"wires":[["88f77c12.4515e"]]},{"id":"f4bdc1ec.bb3e8","type":"inject","z":"cc639dbb.119d5","name":"","props":[{"p":"room","v":"wohnzimmer","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payloadType":"str","x":390,"y":80,"wires":[["3b6d2e6.bcde2d2"]]},{"id":"839dd426.946fb8","type":"inject","z":"cc639dbb.119d5","name":"","props":[{"p":"room","v":"küche","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payloadType":"str","x":390,"y":140,"wires":[["3b6d2e6.bcde2d2"]]},{"id":"88f77c12.4515e","type":"debug","z":"cc639dbb.119d5","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":1000,"y":120,"wires":[]},{"id":"44b2605f.5d41","type":"server","name":"Home Assistant","version":1,"legacy":false,"addon":true,"rejectUnauthorizedCerts":true,"ha_boolean":"on","connectionDelay":false,"cacheJson":false}]

Imagine each inject node as a call from your echo with different rooms requested.

OK, my wording was poor… Let’s say, that from a “conceptual” point of view, I think that relying on functions and accessing the HA states that way is an unusual way to do it. Through the websocket palettes from kermit, you can, I think, use a complete different logic. And most of the users are doing it that way.
But, now, I get your point :wink:

You can actually make it even easier by capturing words from the smart speaker that you use in the current state node.
Using IFTT it can capture what room you request and pass this to HA/Node red with events node and use that in the sequence.

That’s what I meant. I just wanted to show that you can use one current_state node for multiple rooms.

@Hellis81 / @Syntox - Thanks much for the example, which looks quite interesting. However, I still prefer to only use the very same sentence in every room to request the climate data without having to add the location. Therefore I extract the speaker device from the object delivered by the Alexa node in order to determine the right sensor data for the corresponding room.

@greengolfer - I´m glad we finally came to a mutual understanding :slight_smile:
Again, making use of existing global variables doesn´t seem to be “unusual” to me but maybe I´m a little alien in this :alien: Honestly I didn´t make use of Websockets so far and couldn´t even find the palette you are referring to. Maybe I missed a great opportunity, so I´m eager to learn more about how obviously “most users” tackle those kind of issues :slight_smile:

I guess it doesn’t matter where you get the data from. Just put the current_state node behind the alexa one and adjust the room in {{room}} for example {{data.device.name}} (I don’t know the actual path)

That’s the one: node-red-contrib-home-assistant-websocket (node) - Node-RED

I think so.

With this collection of nodes interactions between HA and NR (in both ways) are really easy.
I really recommend it.

Alright, this one I already have as it comes “pre-installed” when you add the NR Add-On to HA :slight_smile:

Yes… didn’t know you are using the addon. So, with that, give it a go and forget about the function node :slight_smile: unless you are really obliged!

I wish I could share your enthusiasm about these nodes :smile: But frankly speaking I still don´t see much of an advantage over just using a function node together with the delivered information through global variables…

I’m giving up. You’re hopeless :joy: (Just kidding).
The “pleasure” of using nodered is to avoid writing code and just using what the palette offers you. At least, that’s my view. If for “simple” stuff you have functions, then it is (for me) an unnecessary hassle.
But, one good thing with HA and NR, there are many ways to do you want. Even if you have to cast strings :wink:

1 Like

Agreed :+1: And don´t get me wrong: I´m making use of these nodes for simple use cases as well. It´s just that for the more complex applications I often find myself using one function node that can do the “magic” of what I would else have needed plenty of different other nodes for.

I agree with using function nodes but I also see big benefits of using nodes as it can eliminate a few lines of code and break it up in to smaller more manageable pieces.
I mean instead of nesting ifs you pass a variable out of the function node and use the switch node to split the “code” then I could happily add a function node again but it makes for a easier way to debug the code/sequence in my opinion.

1 Like