'unknown' value for command_line stdout template sensor

Configuration
1

Hi Community,

I’ve been trying to create a sensor which displays a shell stdout output as a value, so I can parse it to fetch some relevant info only, and to store it input_text helper (for example) so I can display it in the dashboard or manage it through templates. Basicaly, I would like to extract the date/time from the first line so I can monitor whether the command is executed everyday.

However, I cannot even manage to get the full stdout into a sensor value. Upon creating the sensor according to documentation, sensor always displays “unknown”. This is what I have done so far:

This is the shell_command:

shell_command:
  check_certs_asus: !secret check_certs_asus

Such secret contains the relevant command, which I know it works fine because if I call the shell_command service shell_command.check_certs_asus from the service developer tool, the output is the expected content:

stdout: |-
  Wed Feb 21 16:00:00 MET 2024
  # INFO: Using main config file /tmp/mnt/USB_ASUS/entware/etc/nginx/config
  Processing domain1.com
   + Checking domain name(s) of existing cert... unchanged.
   + Checking expire date of existing cert...
   + Valid till Mar 27 20:42:47 2024 GMT (Longer than 30 days). Skipping renew!
  # INFO: Using main config file /tmp/mnt/USB_ASUS/entware/etc/nginx/config
  Processing domain2.com
   + Checking domain name(s) of existing cert... unchanged.
   + Checking expire date of existing cert...
   + Valid till Mar 27 20:43:31 2024 GMT (Longer than 30 days). Skipping renew!
  # INFO: Using main config file /tmp/mnt/USB_ASUS/entware/etc/nginx/config
  Processing domain3.com
   + Checking domain name(s) of existing cert... unchanged.
   + Checking expire date of existing cert...
   + Valid till Mar 27 20:43:17 2024 GMT (Longer than 30 days). Skipping renew!
  Wed Feb 21 16:00:06 MET 2024
stderr: Pseudo-terminal will not be allocated because stdin is not a terminal.
returncode: 0

As for the sensor template, this is what I have:

command_line:
   - sensor:
        command: !secret check_certs_asus
        name: "Comprobar SSL"

From this point, I understand that the sensor.check_certs_asus should be updated to the stdout output above, but it is not happening. Is this the right way to achieve this or should I try another approach? Any advice, please?

Thanks!

2

that’s not a sensor template, that’s a comand_line sensor.

The stdout is more than 255 characters. Entities have a 255 character state limit.

You’ll have to parse the information that you want out of the command line sensor using the value_template field.

1 Like
3

Noted with thanks.

Updated the command_line to the following and everything is working as I wanted (get the first line of text containing the last date/time update):

command_line:
   - sensor:
        command: !secret check_certs_asus
        name: "Comprobar SSL"
        value_template: >
          {{ value | regex_replace('[\n\r].*') }}

Now, sensor value is as follows:

Wed Feb 21 16:00:00 MET 2024

Now, I will try to convert it to a format that can be operated with now(), so I can create a binary_sensor for the purpose of checking whether the certificates were checked in the last 24 hours with no errors, but that’s another story.

Thanks for your help!

4

if that’s your local timezone…

command_line:
   - sensor:
        command: !secret check_certs_asus
        name: "Comprobar SSL"
        device_class: timestamp
        value_template: >
          {{ strptime(value | regex_replace('[\n\r].*'), "%a %b %d %H:%M:%S MET %Y") | as_local }}
1 Like
5

Hey! That worked!

It is my timezone indeed (MET: Middle European Tiime - UTC+1). However, that’s the way the router script returns the timezone, although it is more common (at least in Spain) to use CET (Central European Time) for standard time and CEST for daylight saving time (Central European Summer Time - UTC+2).

Anyway, the result value is in timestamp format [2024-02-22T15:00:00+00:00], which is what I needed for the purpose explained earlier.

Thank you so much!