command_line integration: inconsistent handling of shell commands with templates

9R commented 3 weeks ago

The problem

The command_line integration has various platform that in their core offer the same functionality to easily interact with hard- and software without their own integration. The core of these platforms to execute a shell command and make it possible to process stdout of that command to create sensors, switches and other entities.

Unfortunately the way how the supplied command is preprocessed varies largely between the different platform. The sensor & binary_sensor platforms share an implementation for preprocessing the shell command and allow the use of templates while the other platforms mostly just pass the command string to a shell.

There also seem to be some to be some larger inconsistencies and errors in how templated commands are handled by the sensor and binary_sensor platforms.

When addressing the missing command templating capability of command_line switches, covers etc on the forums a common recommendation is to use the shell_command integration together with one of the various template integrations. This brings it's own problems because then the response_variable of shell_command is not available for processing in a value_template of for example a template_switch which makes it necessary to create another, separate command_line sensor to get the state of said switch entity.

I think it would be desirable to have a single implementation to handle shell commands with templates to have consistent behavior in all platforms of the command_line integration.

What version of Home Assistant Core has the issue?

core-2024.9.3

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Core

Integration causing the issue

command_line

Link to integration documentation on our website

https://www.home-assistant.io/integrations/command_line/

Diagnostics information

No response

Example YAML snippet

command_line:
  - binary_sensor:
      name: working template sensor
      command: echo {{ 1 }}
      value_template: {{ value == 1 }}

  - switch:
      name: non working template switch
      command_on: echo {{ 1 }}
      command_off: echo {{ 0 }}
      value_template: {{ value == 1 }}

Anything in the logs that might be useful for us?

No response

Additional information

No response

home-assistant[bot] commented 3 weeks ago

Hey there @gjohansson-st, mind taking a look at this issue as it has been labeled with an integration (command_line) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `command_line` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign command_line` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

command_line documentation command_line source _{^{(message by IssueLinks)}}

home-assistant[bot] commented 3 weeks ago

Hey there @home-assistant/core, mind taking a look at this issue as it has been labeled with an integration (shell_command) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `shell_command` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign shell_command` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

shell_command documentation shell_command source _{^{(message by IssueLinks)}}

gjohansson-ST commented 2 weeks ago

This issue can mean everything and nothing. It's not intended for command_ljne to solve all use-cases and for example the one with using WoL to wake up the NAS won't be covered by this integration as it depends off an action related to another integration.

I'm not sure exactly what you want to say with this issue or why it's not on the forum instead as it's not an issue (nothing is broken here) and you seem more to want to extend the coverage and functionality of the integration?

9R commented 2 weeks ago

This is not about "solving all use cases" but about having consistent behavior across various platforms of one integration.

I think the use of templates in shell command should be either possible or it should not be possible.

Since the binary_sensor & sensor platforms of the command_line integration already allow the use of commands with templates it seems the cause why this is missing from the other platforms is just the lack of a general implementation and it was not an active design choice to exclude switches, shutters etc from having templates in their commands, right?

Before addressing it here I discussed the current state with other home-assistant users and all of them found it confusing. That is the reason why I raised this issue. The feature is already there, just not consistently over all platforms of the integration.

Currently template processing happens in the commandSensorData class in sensor.py and in binary_sensor.py it is borrowed from there.

My approach would be to move that command template processing to i.e. utils.py and generalize it so it can be used by all platforms of the command_line integration. But I am neither a developer nor to familiar with the home-assistant code base so I might need guidance and help. There might be better solution to resolve this, too.

For background: My specific use case

tldr: I have a device that requires an irregularly changing argument to work.

I own a device that has multiple switch-type entities that can be addressed via a binary from the command line. For the communication to be successful an ID has to be passed as an argument. This ID changes irregularly over time. I'm guessing that there exist a couple 100k of these devices but probably only a fraction is used together with home-assistant. A specific integration for this device does not seem sensible, since it would ultimately just be a wrapper to run the shell binary with one of three interaction arguments (on, off, get_state) plus the id argument. I'm also guessing that there are many other devices with obsure protocols that would benefit from a consistent template functionality in the command_line integration.

Currently available options to use such a device with home-assistant:

Annoying solution A: Hard code the ID into yaml and restart HA after manually updating the ID when a change is required. (Cost: 1 integration, 1 switch + irregular manual intervention)
Complicated workaround solution B that is suggest on the forums when people ask for templatable command_line switches: Fetch currently valid ID with a command_line sensor. Have shell_command actions with templates for the on and off commands. Combine those in a template switch. Create another command_line sensor to monitor the state of the hardware switch. Add that sensor to the template switch via value_template because template switch does not provide the return_response of shell_command (like it would be in a command_line switch). Multiply that by the number of switches in the device and you get a lot of ugly yaml (Cost: 3 integrations with 2 sensors, 2 actions & one template switch per actual switch that is operated).

Preferred Option:

Solution C: Fetch currently valid ID with a command_line sensor (This is already possible). Pass the valid ID to command_line switch commands via template (this is currently not possible because templating does not work in command_line switches). (Cost: 1 integration with 1 sensor & 1 switch)

gjohansson-ST commented 2 weeks ago

I mean what you're requesting is an addition of a feature e.g. change the command_* fields in command_line switch to accept template. Not sure why you're not writing it as simple as that (and also mixing in shell_command which has nothing to do with command_line).

9R commented 2 weeks ago

On one hand I mentioned shell_command, since it is de facto the recommended way to work around command_line platforms that lack template support. On the other hand it may even be sensible in the long run to combine the shell_command and command_line integrations since at least parts the code are very similar and to my understanding they both provide interaction with the same resource in a similar way.

Even though my personal use case is on the switch platform I think all platforms should provide command templates in the same way.

home-assistant / core