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!