Issue getting states after 17.0 update

Hello, i have a flow that controls my heating and cooling. it had been working correctly until i upgraded to 17.0. specifically i have a function node that gets some states from different entities to correctly set things. The code below was working until yesterday:

//get the instance
var beachHA = global.get('homeassistant.beachHA');
//pull the variable states
// var awayHigh = parseFloat(global.get("homeassistant.beachHA.states['input_number.ac_away_low'].state"));
var awayHigh = parseFloat(beachHA.states["input_number.ac_away_high"].state);
var awayLow = parseFloat(beachHA.states["input_number.ac_away_low"].state);
var homeColdHigh = parseFloat(beachHA.states["input_number.ac_home_cold_high"].state);
var homeColdLow = parseFloat(beachHA.states["input_number.ac_home_cold_low"].state);
var homeHotHigh = parseFloat(beachHA.states["input_number.ac_home_hot_high"].state);
var homeHotLow = parseFloat(beachHA.states["input_number.ac_home_hot_low"].state);

Now for that node i get the below error for each of the state gets. All other state nodes on other flows are pulling information from HA, so i know the connection is good.

"TypeError: Cannot read properties of undefined (reading 'states')"

Reading the release notes i don’t see anything that changed that would impact this. anyone have any ideas?

Check the global context does beachHA exist under homeassistant? Did you change the name field in the server config?

I think the server is configured to use the global context. the server name has not changed.

Does the function node run before NR has connected to HA the first time after a restart of NR?

Does it happen after NR has connected to HA?

i believe it happens after NR has connected, but i am not 100% sure. if i make a change in that function node (i.e. add a comment) and re-deploy, the errors happen again

What deployment method do you use?

image

What starts the flow? can you share a screenshot?

i had it as full deployment, so the error is happening at startup AND during execution… but i am still unsure why. here is a screen cap of the flow:

The other nodes are connected and receiving status notifications from HA, so i know the server info is correct. I added the inject node to the flow to be able to trigger it manually and it still gets stuck at that function with the same error.

I suggest you upgrade to the latest version (17.0.1). It contains the latest version of
Home Assistant Websocket (0.62.3) which contains several bug fixes for service calls.

Thanks for the suggestion. I just upgraded, did a full reboot of HA and the issue persists.

I suggest you review the existing open Issues in the Home Assistant Websocket repository for anything that resembles the problem you’re experiencing. If there’s none then post a new Issue describing the problem.

Check the global context table under the homeassistant property and see if beachHA exists.

1 Like

Thank you!!!
Upon looking, it appears that something messed with the capitalization of the server. It is called BeachHA in the configuration, but for some reason in the global context it became beachHa… not sure how this happened or if it was always that way, not sure why it had worked for the past year or more.

Thank you @Kermit and @123 for the assist!

anyone know where Node Red is pulling the name for the homeassistant object? i’ve searched everywhere and cannot find it written as it shows in the context (beachHa), everywhere else I see it called BeachHA, so i am trying to figure out where it got that name…

Well if anyone knows it will certainly be Kermit.

The ‘something’ you refer to is naming convention.

In programming, all variable names should be set to a case convention according to the language, convention, and personal choice. Here we are in JavaScript land, and the homeassistant context variable is actually a JSON object.

{“homeassistant”: {“severName”: etc

By convension, JSON key names are lower case. Certainly they start as lower case (left over I think from Linux, written in ‘c’). There are various options for managing long and multiple words, namely:

MACRO_CASE
PascalCase
camelCase
kebab-case
snake_case
Train_Case

In HA, by observation, I would say that it has been snake_case and is now moving towards camelCase.

So, when you create a Home Assistant server in the configuration, you give it a name. Something Like BeachHA. Here, in the Name_I_Give_To_Things you can call it what you like.

This is SebastianCase - and we now need to use that ‘name’ to create the object key in the context variable. To make it match the convention, it will be parsed through a stringify thingy. I have looked, but can’t find it in the code, but it will be there somewhere.

This parser will take your name and make it JSON approved camelCase. I guess it lowercases the first letter, and looks for any UpperCase mid string, then keeps the first mid upper and lowercases the rest, as well as removing characters that should not be there. Bingo

BeachHA become beachHa.

Has it always worked like that?
Maybe. It certainly should now.

Personally I am very bad at this, and some days I like LastUpdated. Otherdays I go with lastupdated, or last_updated, or if I remember lastUpdated.

My homeassistant servers are called HA1 and HA2, which end up as ha1 and ha2, at which point we could spend hours talking about numbers in names, then punctuation in names… I am also using HA-Rev1, which ends up as haRev1, so yes “-” gets stripped out too.

What’s in a name? That which we call a rose
By any other name would smell as sweet

2 Likes

Thanks for that explanation. I guess my take on it is why change a variable i declared? That flow had been working for over a year and it made it very hard to figure out what was the issue while also having the wife not happy with me when the temperature in our room was around 62 degrees. I understand the need for some standards, but this almost felt like an April fools prank