Good to know it is working!
The basics of using Node-RED with Home Assistant should be easy, but there are lots of little things that matter.
HA keeps a lot of entity state values as strings, and for the most part avoids using true and false as primitive Boolean values. You will find that integrations support state values as âonâ and âoffâ or âhomeâ and ânot homeâ. Even âinput_booleanâ switches have state âonâ and âoffâ.
The WebSocket nodes do a lot of work to deal with this for you. The Events: state node (and others) have a âState Typeâ setting. This pre-processes the state value from whatever it is to what you want it to be, within reason. So strings can be turned into numbers, and also into Boolean. The âtranslation ruleâ for this is defined in the configuration server settings, and only applies for these WebSocket nodes. If you look at the configuration nodes, and the homeassistant server, you will find a setting for âState booleanâ.
This all gets set up for you with Node-RED as an addon, but is usually
y|yes|true|on|home|open
so when the âState Typeâ is set to âbooleanâ, if the incoming entity state value (string) matches any in the list, it is true, otherwise false. It may seem picky, but there is a difference between âtrueâ and true.
This means that you have options! Use the default string and test for âonâ and âoffâ, or switch to state type âBooleanâ and test for true or false. I do find that it is very helpful to be consistent though!
Services do give rise to a great number of questions. Services are added by integrations. When an integration is added to HA it usually adds one or more sensor entities, and some integrations will also add services that can be used (called) to change or update various entities. In general, for any particular entity you need to look at the integration to see what services it provides, and when you select that domain / service combination, HA and the WebSocket node will only provide entities to which that service can be applied in the option selection list.
Somewhere I have an integration that has added âswitchâ, and it works for me on my switch I was using to test my code. Clearly you may not have that integration and service, or you may have âswitchâ but it works on other entities, or your switches have another âgoveeâ domain under which all the service calls for these devices sit.
That said, Home Assistant comes with a few in-built services out of the box, and has âturn_onâ and âturn_offâ and âtoggleâ that will work with anything that, to HA, looks like a switch.
And as an extra:
There was a comment earlier in the discussion suggesting it was easier to do things like this in HA rather than Node-RED. Since you now have this working, here is my minimalist solution, that I submit as being easier than HA automation.
This works, with just two nodes, and almost no settings. The Event: state node has a test condition to check that the (string) state value is in [âonâ, âoffâ], so this will ignore state changes that go to âunknownâ or âunavailableâ, and the usual setting is there to stop the node firing unless the state value has actually changed.
Then, the output properties use a bit of JSONata to set the msg.payload object to run the service call.
{"domain": "homeassistant", "service": "turn_" & $entity().state}
This sets the domain and the service, so nothing has to be set in the Call service node. The service is set to âturn_onâ when the entity state value is âonâ and âturn_offâ when the entity state value is âoffâ.
The Call service node now only needs the target entity (although you could also set that in the JSONata code as above if you wanted to).
[{"id":"12e40ed423404fb7","type":"server-state-changed","z":"e6f8ea0317d4f26a","name":"","server":"","version":5,"outputs":2,"exposeAsEntityConfig":"","entityId":"switch.t2_2","entityIdType":"exact","outputInitially":false,"stateType":"str","ifState":"[\"on\", \"off\"]","ifStateType":"jsonata","ifStateOperator":"includes","outputOnlyOnStateChange":true,"for":"0","forType":"num","forUnits":"minutes","ignorePrevStateNull":false,"ignorePrevStateUnknown":false,"ignorePrevStateUnavailable":false,"ignoreCurrentStateUnknown":false,"ignoreCurrentStateUnavailable":false,"outputProperties":[{"property":"payload","propertyType":"msg","value":"{\"domain\": \"homeassistant\", \"service\": \"turn_\" & $entity().state}","valueType":"jsonata"}],"x":330,"y":3880,"wires":[["a1dc4a4690c7c30f"],[]]},{"id":"a1dc4a4690c7c30f","type":"api-call-service","z":"e6f8ea0317d4f26a","name":"","server":"","version":5,"debugenabled":false,"domain":"","service":"","areaId":[],"deviceId":[],"entityId":["switch.t3_2"],"data":"","dataType":"jsonata","mergeContext":"","mustacheAltTags":false,"outputProperties":[],"queue":"none","x":590,"y":3880,"wires":[[]]}]
The power of using Node-RED is the increased flexibility it brings - this is a very simple case, but the JSONata can be extended to perform more complex conditional testing and to build parameters that would (I submit) be harder to do in Home Assistant.
Enjoy Node-RED!