Home Assistant, and therefore the Node-RED service call node, can only apply services to entities that support that particular service.
When you select a domain, the node will list just the services that can be applied to that domain.
When you select a service call, the node will list just the entities that can be targets of that call.
If you tried ‘cover: close_cover’ you will probably see all your covers (blinds). However, unless your covers / integration support positioning (mine do not) then this service call cannot be used.
Thanks for the tip, but that didn’t do the trick. There is a work around. If I send the service as {{payload}}, then I can chose the entities. This always requires an additional node, where I change the message payload to the service I want to call.
If I choose any service in the node, the entity choice will disappear, no matter what. This is quite annoying.
In that case, if it does not work with any service / entity, it may be something to do with your Home Assistant server connection.
The HA server configuration node sets up the WebSocket connection, and this node has settings to capture the HA state and to save it in global context. Also there are settings for the ‘Cache Auto Complete results’.
As a first step, check your NR Global Context for a variable ‘homeassistant’ and look in this for your HA object, and for the ‘services’. This is where the node gets the service values from, and it then looks in HA for the entities.
Sometimes the Autocomplete Cache needs to be toggled (if on - off, if off - on) just to try and see if that fixes the issue.
Otherwise, the usual - have you updated HA, Node-RED addon, WebSockets, Companion to the latest versions - applies.
This is where the home assistant configuration node can be found (I just happen to have two) Your one will probably be called Homeassistant.
The ‘Enable heart beat’ sometimes helps with keeping a dodgy connection alive.
The ‘Enable global context store’ is required to keep an HA state copy in global context (see below)
The ‘Cache autocomplete results’ helps with speed of getting the drop down lists populated, but caching can cause issues…
This is where to find the global context - there should be a nice homeassistant variable in there with all the states and the services - this is what is used for the service auto complete!
In my experience, although I have many covers (blinds) none of them are suitable for ‘set_position’ and therefore do not show as they cannot be selected.
This may be the root of the problem. The positioning of the cover is done by measuring the runtime and compare it to the total opening and closing time. This is done by the actuator, not by the cover itself. It works perfectly fine with my work-around.
What suprises me is that also the close_cover and open_cover services have no target defined.
Home Assistant will only let you run services on entities to which that service can be applied.
When you get a brand new HA out of the box, it has no entities and it has no services. True, there are a few building block services, and HA adds a few entities of its own.
After that - when you an an integration, that integration is responsible for creating and registering entities, as well as the services that can be used on some of these entities. At this point, HA knows about these entities, and the services, and the relationship between them.
I have added my Somfy TaHoma (which knows about my blinds) using the Overkiz integration (which knows about covers). This integration has added entities for my blinds, and has added the various services that can be used with covers. All ‘cover’ services have been added, although only some of these services can be used in reality since my blinds are all of the dumb RTS type, not the IO type.
If you are controlling your covers using something like a native Zigbee and home-flashed controller, then all that HA knows about is your Zigbee integration, which has clearly not added any entities and services for anything specific.
It is all down to what your integration has added to HA.