As you can see I use {“value”:"{{payload}}"} as the JSON entry. I am sending it a payload of “charging”.
However the input_text entity is updated to {“value”: charging}
What’s going on? (newbe)
Generally the HA websocket nodes support mustache templates, and these do work with simple strings.
However mustache templates are not good when working with objects.
See the WARNING on page
https://zachowj.github.io/node-red-contrib-home-assistant-websocket/guide/mustache-templates.html
As you are trying to insert an object here the solution is to use JSONata rather than templating to do the work.
Change the Data field option back to the J: (JSONata expression) default, and use
{"value":payload}
The JSONata expression will be evaluated, and payload is replaced with its value, leaving you with the result you want.
1 Like
That’s great. Thank You.
Could you help me with how I would I go about extracting the “charging” from {“value”: charging} ?
I don’t understand your question.
{“value”: charging} is not valid JSON - the key is a string ‘value’ and the value is not a string when it needs to be.
If “charging” is the value (a string) to get to a value in JSON you use the key. How you use a JSON pathway reference depends very much on where you are using it.
Try {"value": "{{payload.value}}" }
{“value”: “{{payload.value}}” } just gives {{payload.value}}
I don’t yet understand what Geoff said, but I will look into it.
Thanks for all your help!
Thanks Geoff!
I understand now (I think). The input_text.pylonstate object has a property “value” instantiated with “charging”.
So I guess my question really is how to display the instantiated value in Lovelace, but that’s a different forum.
In HA almost everything is an ‘entity’, and entities have states (values) as well as belonging to one of several types.
My assumption therefore is that you have used the UI to create a helper, type input text. Your entity is called ‘input_text.pylonstate’. The ‘input_text’ is the type of entity, and the ‘pylonstate’ is the name you gave it.
You are using Node-RED, with a ‘service node’ to call the HA ‘input_text : set_value’ service to set the value of your input text entity. The service call sets the state value of the entity.
Your entity ‘input_text.pylonstate’ now has state value of “charging”.
Technically, within HA this is represented by input_type.pylonstate.state, being the type of entity, the name of the entity, and the state value (other bits and pieces include attributes and last-update times etc)
You can display this [entity state] in the dashboard (formally known as Lovelace) using any ‘entity’ card. The basic ‘entity’ card will work fine - just add a new card (select entity card), and in the entity box type in your entity name (input_text.pylonstate). The card will find the entity (it helpfully does a dynamic search as you type) and display the state of the entity, which is likely to be the text string “charging”.
As a note, you have chosen to use ‘input_text’, which is a special type of entity normally used where direct manual update of the state from the UI is required. It is there to allow you to “input text” into the state value of an entity. You will find that you can edit the entity (state) from the dashboard.
If you are just trying to get a text string from something and display it in the dashboard, then you might find just using a normal sensor entity would be better, since these entities can be created and updated using Node-RED, but cannot be manually amended in HA.
Using a ‘Home Assistant Sensor’ node would allow you to create a new entity (something like sensor.pylonstate) and update the state more easily just from the msg.payload. The HA sensor nodes are there to create sensor entities and manage the state update, and the sensor state would be just the text string from msg.payload. Displaying this sensor in HA is just the same, as it is just another entity.
Hope this helps - it does take a while to get to understand what HA is and how it works.
Wow, that is amazing Geoff.
Thank you for taking the time to explain that to me so clearly.
I had been using input_number as a way to save updateable parameters and just used input_text because it was just another helper.
Yes I now understand that use of a sensor is more appropriate.
I am indebted to you. You are very kind!
Thanks
Martin