Switches created in NR marked unavailable in global context after node red restart

[dpgh947]

Describe the bug

This is a strange problem, not sure where the problem lies, so I'm starting here: I use the "expose as" settings on nodes that support it a lot, it creates a switch in HA which can be used to disable the node (for example, events: state node), this gives an easy way to turn NR automation routines on/off from HA.

I also make use a lot of the entity states available under global context (for example, global.homeassistant.homeAssistant.states["switch.automatic_study_light_control"].state) to get an entity state in various nodes without having to use a separate "current state" node. I have noticed that the state of all these switches created by "expose as" is showing "unavailable" in the global context after a node red addon restart (EG: for an upgrade). Any explicit get for a state returns the current setting in HA as expected, it is just the global context value that is out of step. If I then restart HA, they all get set correctly.

To Reproduce

Create an "expose as" switch on an events state node. Look at the state in HA and in the global context (Global - homeassistant - homeAssistant - states). Note how the switch disables the node. Then restart the node red addon, and look at the states again. HA will say ON or OFF as expected, the context will say unavailable. If you toggle the switch in HA, it corrects the context, as does an HA restart.

Expected behavior

The global context values for these switches should reflect the HA values after a node red restart, shouldn't be "unavailable".

Screenshots

No response

Example Flow

No response

Environment Information

Version: 0.65.1

Home Assistant version: 2024.8.1
Companion version: 4.0.1

Node-RED version: 4.0.2
Docker: yes
Add-on: no

Node.js version: v18.20.3 arm64 linux
OS: Linux 6.6.31-haos-raspi arm64

Additional context

No response

[dpgh947]

I have had this happen twice, today I figured it was after a restart to upgrade node red, but I have been testing how to find all the unavailable global context states, I have that working but now I cannot reproduce the problem by restarting node red, so I don't know what causes this...

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[inguy24]

Has there been any movement on this at all?

I'm hitting this same issue and it's a significant problem for my use case — I'm running a home security alarm system through Node-Red.

Setup: I have several Companion-created entities (switch and number types) that my alarm flows read via global.get("homeassistant.homeAssistant.states[...].state") to determine things like exit delays and whether sensor bypass is enabled.

Problem: After restarting Node-Red, these entities show as "unavailable" in the global context even though they display the correct state in HA (Developer Tools > States confirms correct values). This persists indefinitely — I tested 10+ minutes after restart with heartbeat enabled. Non-Companion entities (e.g., sun.sun) sync correctly.

Impact: Because the bypass switch reads as "unavailable" instead of "on", the alarm refuses to arm (treats open sensors as errors instead of bypassing them). The delay values return NaN from Number("unavailable"), which breaks downstream JSONata expressions. For a security system, silently failing to arm is a serious issue.

Workaround: Currently adding || 0 fallbacks for numeric values and planning to migrate critical entities to HA native helpers (input_number, input_boolean) to avoid the bug entirely. This is not a good workaround though as this now completely eliminates a delay someone may count on resulting in an alarm when there should not be and a fine from the local police department.

Environment:

node-red-contrib-home-assistant-websocket: 0.80.3
Node-Red Companion (hass-node-red): 4.2.3
Home Assistant: 2026.3.4
Would appreciate any movement on this — happy to provide logs or help debug if needed.

[dpgh947]

I solved this with a flow that runs when the home_assistant_client event with a state of "running" is seen. It fetches all states with a GET for http://(HA address):8123/api/states and then compares everything with the context - global.get("homeassistant.homeAssistant.states") - and updates anything in the context with a state that doesn't match HA. It usually corrects about 70-80 states after a restart.