Trying to use the current temperature from weather.home
but I only seem able to grab the ‘sunny’
Anyone able to advise how I get the attributes?
Thanks
Msg.payload in the settings only has the entity state. The full data return (entity) is set (see ‘output properties’ in the UI) to end up in msg.data, which is an object containing everything including the attributes.
You can change msg.payload to be the entity rather than the entity state Another easy way to get this back into msg.payload is to use a change node to set msg.payload to msg.data.attributes.temperature (or whatever you want - just msg.data.attributes gets the entire attribute object).
Naturally, if you want to see all the non-payload stuff in the message, you need to switch debug from msg.payload to ‘complete msg object’
Change node:
It took me quite a while to grasp how powerful the change node actually is. Rather than using function node I try to manipulate data in that, and quite a lot can be done in sequence.
Using the ‘standard’ output from the ‘entity state’ node, where the entity state is in msg.payload, and the full attributes etc are in msg.data, it is easy to use first Jsonata to set msg.payload to a new object, with the msg.payload state as the ‘current weather’, then to add in attributes such as ‘temperature’ and ‘pressure’, thus easily building your own data object.
Great fun!
1 Like
Thanks for much for the detailed response… still processing (and trying to avoid overcomplication!)
I’ve now understood that I can change the msg.payload to entity rather than entitystate - and see the output in the debug
I’m still not sure if it’s possible to just use that in the current_state node? I.e. can I use current_state weather.home.attributes.temperature > 25 (or whatever)?
I’m guessing by your second half explanation that this is not possible and I need to make it more complex?
It took me a little while to do, but yes you can do the test inside the state node. For myself I find it less complicated to turn the output of the state node msg.payload into what I want, and then add a switch node afterwards. My preference is to do the conditional testing outside of the state node so I can see what is going on!
Anyway, here is the setup to do what I think you are trying to do. Tested it at my end, so I believe this is correct.
What is going on:
The current state node has an option to do testing on the ‘state’ (see ‘if state’ section). If this is blank, no testing is done and there is one output to the node.
If testing is set up, the node will set up two outputs, and as a result of the test the standard node output will either go to one output (true) or the other (false) depending on the Boolean result of the test.
Usually testing is done on the entity state, but here I have set the ‘if state’ testing type to JSONata. This is (yet another) language that is very useful in many of the Node RED nodes as it allows for in-line computation. The JSONata then expects a JSONata valid expression that processes (in this case) to a result of true or false. Using the ‘…’ at the end of the entry line opens an editor with a testing tool and function reference.
I have used the $entity() function to get the current entity that is going through the node, and thus $entity().attributes.temperature gets me the weather temperature. >27 or whatever turns this into a Boolean expression.
At the output, just so as I have something to use, I have first set msg.data with the entity information. Much the same as $entity(). Then I have set msg.payload to data.attributes.temperature. The order of these two is important, as the second references msg.data, which is only set up in the first line. You can have as many lines and do as much coding as you like, so another option would be to do the conditional test and set msg.payload to data.attributes.temperature>25 down there - thus msg.payload would be a Boolean true/false.
Which option is the least complex is probably open to debate. 
And the documentation reference for JSONata in the HA nodes is at
https://zachowj.github.io/node-red-contrib-home-assistant-websocket/guide/jsonata.html
1 Like
Once learned this method can be used quite easily to do complex and/or comparisons of multiple attributes across multiple entities and can really simplify flows that might otherwise need a number of current state nodes, switch nodes etc. to achieve the same result.
I would recommend documenting what you’ve done in the description tab of the node, for later reference.
This is quite neat what you have shown Geoff.
The only thing i would add is that for a newbie - JSONATA is a bit of a black art and they will be scratching their heads and looking at this in 6 months and thinking what is this node doing ?
Unless someone is planning on doing a lot of work ongoing in JSONATA i usually tell them to stay away from it and instead use multiple Visual nodes to enable better understanding and debugging.
(But that approach does obviously make the flow more visually dense - and some people like the minimalist approach regardless of ongoing supportability !)
Craig
Thank you. I take that as a compliment! I don’t usually manage to do any ‘quite neat’ kind of code.
Seven months ago I was a newbie to the whole of Home Assistant. Believe me, everything past the glossy UI front is a black art. I have past experience in writing commercially in such dire languages as Basic (compiled), Pascal, C (when the only reference was Kernighan and Ritchie) so I fully appreciate the value of maintainability. LISP is the nearest thing I have ever come across that is definitely a ‘read only’ programming language…
I applaud the writers and developers who put so much time, effort, and passion into getting HA and Node-RED etc. working. However, the documentation does leave a little to be desired, and much of what is around is, for my liking, a little to brief. In six months I have had to learn some Python, JavaScript, yaml, moustache templates, JSON, JSONata, Jinja, as well as lots of Node-RED stuff.
As I said in my post above, my personal preference (at least at the moment) is to use a switch node and externalise the decision. However I share the tension between the complexity of cluttered visibility (spaghetti code), and the complexity of one, simple, neat line of (incomprehensible) JSONata. In my support, answering the original poster’s follow up request to remove the additional node meant more learning and reinforcement of my understanding, as well as answering his request. After a lot of silent learning, I now respond to selected questions where a) I sincerely believe I can add value and b) I know I can also improve my own understanding. Nothing like trying to explain something to someone to really understand a subject yourself (not that I am in anyway trying to ‘teach’ here, more ‘help’).
OK, so yes in such sites as these there is always a race to minimalisation. Who can do it shorter and neater? I wrote my second reply above thinking, having stuck my head above the parapet, how long would it be before someone came up with ~foo.?bar$${{{//.
Having worked with the Vienna Development Method, and as a fan of Jackson Structured Programming, I continue to strive to improve my nascent use of Node-RED. I believe it to be vastly superior to the use of ‘hard code’, much as the development of third and fourth generation languages lifted us from machine code and assembler. I cannot understand why so many rush to use Python in github (another dark arts-and-crafts movement) when one node in Node-RED does all the work. I would like to see much more use of Node-RED, and much better use of it, and to this end, better documentation.
Node-RED seems to me to be poor at iteration. It is also easier to use a ‘function’ node to do much of the hard lifting when lack of knowledge or experience precludes the use of other nodes. I note that we are encouraged to use existing node(s) rather than function node(s), and I have set myself the challenge to avoid (unnecessary) function nodes where possible. To do this almost certainly requires use of the change node, and JSONata expressions. I am also using subflow nodes, which are almost never discussed, but provide neatness as well as much needed structure.
I am considering how / if I could lend practical support towards better documentation, but first I want to try cutting my teeth on trying to answer a few newbie (or even oldie) questions on here. I am attempting to add an explanation beneath any answer that explains what is going on. Over the past six months I have searched a great deal in here for answers to my own questions, only to have to go off and do further research to find out what the given solution was actually doing.
Anyway, if you look at the read numbers for past “Node-RED” posts, no one actually reads this stuff!
Cheers
Nice explanation thanks Geoff. yes it does appear that many people would rather mess with extensive templating and the like to get something done - i look at the template (moustache), Jinja code etc and think this stuff is crazy - they need to embed a scripting language within the system to open it up to a wider audience.
Yes there are some things NR is weak at - but there is such a wealth of knowledge in Javascript it is easy to find a code to put in a function node as you find your feet and then later come back and tidy it up with Visual nodes once you learn your way.
I started my home automation with Picaxe Microcontrollers and Basic years ago (had previously been on the periphery with programming in Cobol, Pascal, C etc etc) - i then migrated that system to Arduinos with the Arduino IDE and the finally moved it all to Node Red when i discovered it about 4 years ago.
Have done away with nearly all the custom peripherals now and use Sonoff/ESPs everywhere running Tasmota.
If you want to find better ways of doing things in NR (not HA related - but generally) you should spend some time in the Node Red Discourse forum - great bunch of very friendly and helpful people there - including the authors and architects of NR
Craig
Just wanted to chime in and say thank you again for the help!
Looking at all the above I think I now understand the change node, and also used it to learn subflows as well 
Well done !!!
Usually you would use a subflow if you were going to call the same routine from multiple flows (for instance i calculate the checksum for my inverters for my battery system across multiple flows so i do that in a subflow and just call that whererver i need it)
But good learning exercise for you
Craig
Hey everyone - this has recently stopped working for me - for some reason the temperatures aren’t pulling in from Weather.Home any more
They’re still shown in the integration, but not in NodeRed - anyone know why that might be?!
Breaking change. Weather is now a service, the old attributes have been removed.
For what it is worth, the following bit of sensor config works nicely for me (and I had to change weather provided too).
######################### to call weather forecast service to get hourly into a new entity Dec 2023 ################
- trigger:
- platform: time_pattern
hours: "/1"
action:
- service: weather.get_forecasts
data:
type: hourly
target:
entity_id: weather.forecast_home
response_variable: hourlyforecast
sensor:
- name: "Forecast Home Hourly"
icon: mdi:weather-cloudy-clock
state: "{{ now().isoformat() }}"
attributes:
forecast: "{{ hourlyforecast['weather.forecast_home']['forecast'] }}"
There are other ways to fix this, and much discussion regarding the change.
https://community.home-assistant.io/t/petition-dont-delete-the-forecast-attribute/609298
1 Like
Oh man. What a pain.
I don’t have time to parse this right now - what a ridiculous decision
Assuming there is no easy way to just call that value in a node in a similar manner?
I guess I’ll just flip tomorrows low to today’s low for now using OpenWeatherMap
Well, there is much debate about that; when it was first announced, during the interregnum, and if you look, a flurry of posts over the past couple of months as the chickens come home to roost post March 2024.
The bottom line, for anyone who reads this stuff later, is that, this is the way HA is going - service calls that return stuff, and if you want the stuff you need to call the service. Look on the bright side - at least you avoided the forecast / forecasts confusion!
But of course there is.
Weather is now a service (look at your integration for your weather and check that it has a ‘service’ as well as one ‘entity’). To get weather you just need to call the service, referencing the weather entity, and then deal with the return.
The call service node has been updated to process call service returns - hence call the service (you have a choice of ‘daily’ for the five days, ‘hourly’ for an array of hours etc). You just have to make sure that your Weather integration is up to date (I’m using Meteorologisk institutt (Met.no)).
Assuming that you just want ‘weather today / tomorrow’ then the following call service will do the trick. Just check the get_forecasts service is available and use the correct entity for your setup.
The output properties have to be set to use the ‘results’ (so here msg.results has the entire return object, and then we can either use it later or directly in the following output properties).
For your convenience, the msg.payload can be set using the following JSONata so as to produce an object for today / tomorrow, and it is just a case of picking, for example,
msg.payload.today.temperature if that is what you want.
(
$a:=results.*[0].forecast;
{"today": $a[0], "tomorrow": $a[1]}
)
Simples.
2 Likes
Legend. Good to learn this stuff if this is the way things are going
I’m not even going to ask about forecast vs forecasts - i see them both there!
I’m guessing your Forecast Home entity is Weather.Home? (I’m using met.no too btw)
The integration is in the ‘Weather’ domain, and configuration allows you to name it (default is ‘Home’). I guess you can have more than one weather integration instance with a different location (work?) so you would need to name the second/third ones something else…
1 Like
Just to mention as it seems that some weather integrations may provide different features. Open weather still supplies forecast sensors for temp, cloud cover, humidity etc. There are 2 settings with that integration, daily or hourly.
With daily you will get sensors that will show the next day’s forecast. If it is set to hourly, your forecast sensor will reflect the next hour. These entities are disabled by default and need to be enabled.
Thanks for the help guys.
However how do you reinject the results into HA ?
I cannot find a way to create a new sensor with the right values from my different weather entities.
I have dredged the HA site for months to find a way to do what I wanted to do (and I have had so many things I have tried doing), and casting around with Yaml solutions and other options before trying other Node Red ideas but after finding this thread I have only just signed up to say “Thank You” Biscuit / Geoff guy…! …your posts were so help after so many nights reading, trying, testing, failing. I now have a nice flow that daily captures Date, 6am Temp and 3pm Temp and links it to the end of day energy use across Hot Water, Heating (cooling in Summer) and General Power. it captures what I want to know about our energy use and where I can now focus on more efficiency. Cheers, Chris J.
2 Likes
When I first started with HA (and Node-RED) two plus years ago, I spent the first six months just reading thread after thread, trying to get my head around Home Assistant (and Node-RED). I was very grateful for this forum and for those who had posted solutions and explanations!
I am pleased to be able to constructively contribute and help support the community.
Good luck with your future projects!
2 Likes