Template Switch or command_line - How do you combine

Hi All,

I have a nas that I can switch off via a Command Switch

platform: command_line
switches:
  switch_nas_off:
    command_off: "ssh -l sshd 192.168.1.30 'sh /usr/sbin/shutdown.sh'"
    command_state: binary_sensor.nas
    friendly_name: "Switch Off NAS"

And then call a service to switch it on:

service: wake_on_lan.send_magic_packet
data:
  mac: 00:90:a9:e1:70:fe

How could I combine these two in a single switch?

Additionally is there a way to add SSHPASS or a similar package that allows you to pass the password via the shell to the HA instance as the Remote loses the ssh-keys at restart, WD does not have a persistent home directory and entware is also a hit and miss.

Create a WoL switch.

Add the off command here: Wake on LAN - Home Assistant

Provide the host ip address if you can too (assign it a fixed IP). This way the switch can check the state of the NAS.

The switch state may bounce back to off in the front end after you turn it on, however once the NAS wakes it will display as on.

Thanks @tom_l.

But could I get it as a single entity, i.e. combining the two actions? Having the turn_on using the WOL switch and the on using command_line, or does it need to be two single entities? Can you combine the two entities into one then?

Yes. That is exactly what I (apparently poorly) described.

The WoL switch uses the WoL magic packet to turn the switch on, and the turn_off option of the WoL switch is specified as your command_line command. So something like this:

switch:
  - platform: wake_on_lan
    name: "NAS"
    mac: "00:90:a9:e1:70:fe"  # used to turn on the switch with a magic packet
    turn_off: command.switch_nas_off # used to turn off the switch
    host: <nas_ip_address_here> # used to get the state of the NAS in case something outside HA turns it on or off
1 Like

Got that, thanks @tom_l , however then it would present itself as two entities, right?
switch.nas
switch.switch_nas_off

Could this be then either

  • consolidated the above two switches into a single entity? (end state is 3 entities Switch On, Off, and template switch calling the two entities with homeassistant.turn_off and homeassistant.turn_on
  • or combined into single switch without the need to create 3 different entities?

Hope this clarify my ask?

Oh! I see what you are saying. I missed that your off command was a switch, sorry. Change this:

platform: command_line
switches:
  switch_nas_off:
    command_off: "ssh -l sshd 192.168.1.30 'sh /usr/sbin/shutdown.sh'"
    command_state: binary_sensor.nas
    friendly_name: "Switch Off NAS"

To a shell command.

Something like this (no idea it it will work like this):

shell_command:
  switch_nas_off: "ssh -l sshd 192.168.1.30 'sh /usr/sbin/shutdown.sh'"

You will probably need to read this:

Though if it is working for the switch, it should work for the shell command.

Then this part of the WoL switch will be valid:

turn_off: command.switch_nas_off # used to turn off the switch

You will then have created one entity switch.nas and one service command.switch_nas_off, rather than two entities.

Thanks @tom_l , works like a charm almost… I still need to find a way to either set a persistent home directory to retain the authorized_keys or pass a password via the command line without the expect command in the home assistant instance.

Here is the final working example had to modify the turn_off section a bit:

switch:
  - platform: wake_on_lan
    name: "NAS"
    mac: "00:90:a9:e1:70:fe" # used to turn on the switch with a magic packet
    turn_off:
      service: shell_command.switch_nas_off # used to turn off the switch
    host: 192.168.1.30 # used to get the state of the NAS in case something outside HA turns it on or off

and the shell command:

shell_command:
  switch_nas_off: "ssh -l sshd 192.168.1.30 'sh /usr/sbin/shutdown.sh'"

Thank you very much!

1 Like

If it wasn’t figured out yet… You can add the specific key you wish to use as an ‘-i’ flag in your ssh command, for example in my case:
“ssh -i /config/keys/hasskey user@ip …” → you can then store your key in your regular hass config directory which you should keep persistent anyway.