HI, using these for my command line switches:
sw_dorm_cl:
friendly_name: Dorm (cl)
command_on: >
curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"[OID]", "prop":"command", "value":"on"}}' http://[IP]/iungo/api_request
command_off: >
curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"[OID]", "prop":"command", "value":"off"}}' http://[IP]/iungo/api_request
# command_state: >
# curl -X POST -d '{"seq":1, "method":"object_prop_get", "arguments":{"oid":"[OID]", "prop":"state"}}' http://[IP]/iungo/api_request
value_template: >
{% if value_json.rv.value == 'on' %}
{{ true }}
{% else %}
{{ false }}
{% endif %}
couldnât I just rewrite the last value_template like this: {{ value_json.rv.value == 'on' }} ?
Well, strictly speaking, you can change it to anything because itâs not used (because command_state is commented out.) 
But, yes, both templates will have the same effect.
yes!
I think you have made a very important discovery⌠State has always been a bit of a struggle for these switches, and Ive been developing from these command_line to template switches using the on and off of the command line switches, and binary sensors for state since using the command line was to stressing for the host (of my zwave switches)
sw_dorm_template:
friendly_name: 'Dorm'
value_template: >
{{ is_state('binary_sensor.dorm_state_bin', 'on') }}
# value_template: "{{ is_state('sensor.dorm_state', 'on') }}"
turn_on:
service: switch.turn_on
data:
entity_id: switch.sw_dorm_cl
turn_off:
service: switch.turn_off
data:
entity_id: switch.sw_dorm_cl
could I take them out completely , or would that cause unexpected behavior? maybe even an invalid config? as far as I understand this https://www.home-assistant.io/components/switch.command_line/#configuration-variables the state is optional?
For a command line switch, if you donât specify command_state then the state will be âassumed.â That is, when you turn it on, it will remember it is on. When you turn it off, it will remember it is off. At startup it will assume it is off. Also, when you donât specify command_state then value_template isnât used, even if you specify it.
thanks, ive made adjustments in the yaml.
what surprises me though is that I had these loose templates, and many of them,
value_template: >
{% if value_json.rv.value == 'on' %}
{{ true }}
{% else %}
{{ false }}
{% endif %}
in the files forever, and never has an error been logged.
I would not expect an error. Thereâs absolutely nothing wrong with that. There is just a simpler, better way to implement it.
when one has this in the yaml files:
sw_dorm_cl:
friendly_name: Dorm (cl)
command_on: >
curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"[OID]", "prop":"command", "value":"on"}}' http://[IP]/iungo/api_request
command_off: >
curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"[OID]", "prop":"command", "value":"off"}}' http://[IP]/iungo/api_request
# command_state: >
# curl -X POST -d '{"seq":1, "method":"object_prop_get", "arguments":{"oid":"[OID]", "prop":"state"}}' http://[IP]/iungo/api_request
value_template: >
{% if value_json.rv.value == 'on' %}
{{ true }}
{% else %}
{{ false }}
{% endif %}
You wrote it is not used, because the command_state is committed outâŚThats what made me wonder about the validity of the loose template.
re-reading the docs I donât think that is true, the command_state and the value_template are both individual options? So even without the command_state the value_template is a valid option. Not sure where it reads its value from though, unless the on and off commands provide that value
testing with this:
sw_dorm_cl:
friendly_name: Dorm (cl)
command_on: >
curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"[OID]", "prop":"command", "value":"on"}}' [IP]/iungo/api_request
command_off: >
curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"[OID]", "prop":"command", "value":"off"}}' [IP]/iungo/api_request
# command_state: >
# curl -X POST -d '{"seq":1, "method":"object_prop_get", "arguments":{"oid":"[OID]", "prop":"state"}}' [IP]/iungo/api_request
value_template: >
{{ value_json.rv.value == 'on' }}
Ah, ok, I guess I didnât understand what you meant by a âloose template.â
Yes, command_state and value_template are individual options, but I can tell you from reading the code, if command_state is not specified then value_template is not used, even if it is specified.
ok, trying to read that codeâŚ
if I use the state command (just tested and it returns the value alright, would I still need to use the template for it to get a state value at startup, or would the state_command suffice?
Also, how often would this command_state be issued? only on the state changes?
When using state_command, the state determination will depend on whether or not you specify value_template. If you donât, then the state will be determined by the status code returned by the state_command: zero (which means âsuccessâ) -> âonâ, anything else -> âoffâ. If you do specify value_template, then the state will be determined by the template.
Like most anything else in HA, the state will be polled periodically, controlled by scan_interval. For switches the default polling interval is 30 seconds.
right, thanks
Now that you remind me, it was that polling behavior that was the reason I went for template switches using the value of the power meter of the switch (which is sent by the Zwave hub anyhow).
The state command issues an Api call and considering it does that each 30 seconds, for all switches , that produces a lot of extra polling traffic that hub doesnât likeâŚ
1 Like
Hi Phil, been a whileâŚ
might I re-ask you Ince more about this please, it has become relevant again in my setup, and I need to take out as much overlap as possible.
I understand that for the switch to be able to use a value_template for its state determination (as you have explained above). What I am nut sure about is, if the value_template would be a completely different one, and not use the status code returned by the state_command, but use another entity eg like this:
sw_kantoor_cl:
friendly_name: Kantoor
command_on: >
curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"f64f93ed", "prop":"command", "value":"on"}}' http://192.168.1.27/iungo/api_request
command_off: >
curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"f64f93ed", "prop":"command", "value":"off"}}' http://192.168.1.27/iungo/api_request
command_state: >
curl -X POST -d '{"seq":1, "method":"object_prop_get", "arguments":{"oid":"f64f93ed", "prop":"state"}}' http://192.168.1.27/iungo/api_request
value_template: >
{{is_state('sensor.kantoor_state','on')}}
# {{value_json.rv.value == 'on'}}
would it still be issuing the command_state each scan_interval? (which is what I am trying to prevent)
I fear it does reading this:
def update(self):
"""Update device state."""
if self._command_state:
payload = str(self._query_state())
if self._value_template:
payload = self._value_template.render_with_possible_json_value(payload)
self._state = payload.lower() == "true"
which really would defeat the purpose of any other value_template. Could this be changed somehow, so the command_line switch could use an already available state and need to query the resource?
Hope you can have a look, thanks!
The way the code is written, the value_template wonât be used unless you specify command_state, and if you specify command_state, it will be sent periodically.
I think what you might want to do is move the commands from command_on & command_off into individual shell_commandâs. Then you can replace the command_line switch with a template switch that uses the shell_commandâs, and a value_template of your choice.
A yes, that would be a fine solution. Adding to the above command_line switch sw_kantoor_cl, nd my current template switch, using the command_line command_on and command_off:
sw_kantoor_template:
friendly_name: 'Kantoor'
value_template: >
{{is_state('sensor.kantoor_state','on')}}
turn_on:
service: switch.turn_on
data:
entity_id: switch.sw_kantoor_cl
turn_off:
service: switch.turn_off
data:
entity_id: switch.sw_kantoor_cl
I could do this:
sw_kantoor_template_shell:
friendly_name: 'Kantoor'
value_template: >
{{is_state('sensor.kantoor_state','on')}}
turn_on:
service: shell_command.sc_kantoor_on
turn_off:
service: shell_command.sc_kantoor_off
using these shell_commands:
sc_kantoor_on: >
curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"6e537045", "prop":"command", "value":"on"}}' http://192.168.1.27/iungo/api_request
sc_kantoor_off: >
curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"6e537045", "prop":"command", "value":"off"}}' http://192.168.1.27/iungo/api_request
For which no data is sent, unless a switch is necessary, and the state keeps being read via the mqtt topic. Nice!
Thanks for the suggestions Phil. Will test per click on Reply