Get_forecasts dont have results as output option

Hi all,
I can’t find the root cause of this.
When I create a call service to get a forecast on the output properties, I cannot select results as returned value(see attached image).
If I call the service directly, the developer tools work without issues.
I checked on another person’s home assistant server, and it works fine for them.

What I have tried:

  • Restart Home Assistant
  • Removed the entity “Amadora” and recreated it
  • Using a newly created entity with another name.

I’m running the latest version of everything:
Core 2024.10.1
Supervisor 2024.10.0
Operating System 13.1
Frontend 20241002.2

Node-RED 18.1.1
Node-RED Companion 4.1.1

Any suggestions?

Thanks in advance


I se you have the updated version of NR but that is an old node. Do you have a blue button at the top by deploy, that says update home assistant nodes? If there was did you restart NR after clicking it?

1 Like

Thanks for the tip.

I found there were some nodes in the pallet that needed to be updated( this does not update automatically?)

and after that, the button to upgrade the homeassistant nodes appear on top:
image

now that I have upgrade them is working fine :smiley:

For future reference and for anyone doing ‘updates’ and having ‘issues’.

There is a Home Assistant tab in the Node-RED debug window. This includes sub-tabs for servers, entities, devices, and issues.

Right at the very bottom, at the very right, is a small gear icon. Clicking on this will bring up the environment summary - this is the information required to describe in full all the various component versions that are associated with the WebSocket nodes functioning correctly in Node-RED.

Version: 0.74.0

Home Assistant instances: 2
Server: ff8a17debdab7d91
Home Assistant version: 2024.9.3
Companion version: 4.0.0
Server: 9c455fb81b6d9bb3
Home Assistant version: 2024.10.1
Companion version: 4.1.1

Node-RED version: 4.0.3
Docker: yes
Add-on: 18.1.1

Node.js version: v18.20.4 arm64 linux
OS: Linux 6.6.46-haos arm64

The first line shows the current version of the WebSocket nodes themselves.
Then there is the HA server(s) (configuration nodes), and the corresponding HA version (core) and the Node-RED Companion (integration in HA) that the server is connecting to via the WebSocket.

Then you get the Node-RED version (Node-RED itself, not the ‘add-on’), is Node-RED is running in a docker container, and if it is running as an HA Add-on and the NR add-on version.

Finally, the underlying Node.js version inside Node-RED (inside the add-on), and the hardware and operatiing system.

… except the WebSocket node (see palette) which are now 0.74.0. The change from Call Service to Action happened quite recently. The change that added the service call return was quite a while back, so I presume you had a version from several months ago. As you have noted, easily addressed in this case by manually updating the nodes in the palette.

I updated Node-RED add-on only yesterday from 18.0.5 to 18.1.1 under controlled conditions (holding my lucky rabbit’s foot). The HA WebSocket nodes were at 0.63.1, and I pre-checked the release history before updating (both Node-RED add-on releases, and the HA WebSocket node releases). I noted that the add-on (18.0.5 → 18.1.0) increased the WebSocket dependency version, in several stages, up to 0.73.0

I can confirm that the add-on update did not bring in the latest WebSocket node version and I had to go to the palette and do this manually. In this case, the HA WebSocket nodes had already gone further forward to 0.74.0 (Kermit is tireless).

In the past there have been issues with manually updating the palette version, and some care is required to avoid moving the WebSocket node version too far ahead of the dependent version for the currently installed NR add-on. Where a change to the WebSocket nodes has a dependency on things like the Node-RED version (breaking change) for example, we have to wait for the add-on to update to a new Node-RED version before updating the WebSocket nodes.

My past recollection is that the add-on update does update the WebSocket nodes, but most definitely, for me yesterday, it did not, and in this case a manual palette update was required for the WebSocket nodes (and Themes, Email, and Modbus).

And finally, if anyone actually reads any of this and has spotted it - yes I have two Home Assistant servers. This is almost always an issue and causes problems with the WebSocket connection back to Home Assistant. You should not have two HA servers trying to both connect to HA at the same time. Before anyone writes in (postcards to…) I have two machines with Home Assistant, and my servers here are connecting firstly back to the local machine (via supervisor to Node-RED as an add-on) and secondly back to the remote machine (via ip:port and long-term token). Hence two different WebSockets on two different Home Assistants.

I am going to check specifically next time I update Node-RED HA add-on to see if it does update the WebSocket nodes as part of the update!

1 Like