2021.4: For our advanced users ❤️

PedroLamas · May 3, 2021, 4:27pm

I’ve been using that for automations, but from some quick experiments, it doesn’t seem to work with multiple filters…

test_script:
  description: Test script
  fields:
    field1:
      selector:
        text:
  variables:
    field1_fixed: "{{ field1 | default | lower }}"
    field1: "{{ field1 | default | lower }}"
  mode: parallel
  sequence:
    - service: system_log.write
      data:
        message: "field1: {{ field1 }}, field1_fixed: {{ field1_fixed }}"
        level: error

If the above script is called like this:

service: script.test_script
data:
  field1: Test

The log output will be:

field1: Test, field1_fixed: test

So one can see that it will still take the input field instead of the variable with the same name, but the new variable (the one with different name) works just fine!

jazzyisj · May 4, 2021, 2:10pm

What you are trying to do there is a bit different than the use case I presented. My suggestion will substitute a default value if you do not provide an “optional” field parameter to suppress the variable warning.

You are redefining an already defined a field value as a variable. This can be done just by using a different variable name as you have done with field1_fixed. It can also be done by redefining the variable in the sequence block instead of the variables block.

For what it’s worth, I would have expected it to work in the variables block also, but as you discovered it appears it doesn’t. Not sure if it’s a bug or intended behaviour.

Try this example with the variable declared in the variable block and then again in the sequence block both calling it with a value defined for field1 and without.

test_script:
  description: Test script
  fields:
    field1:
      description: ''
      example: ''
  # variables:
  #   field1: "{{ field1|default('DEFAULT')|lower }}"
  mode: parallel
  sequence:
    - variables:
        field1: "{{ field1|default('DEFAULT')|lower }}"
    - service: system_log.write
      data:
        message: "field1: {{ field1 }}"
        level: error

PedroLamas · May 4, 2021, 4:07pm

We are in agreement here, I too am not sure if this is a bug or not, but as the default filter works, I would expect any other filter to work too… I think I’m going to open a bug and see what happens!

petro · May 4, 2021, 4:16pm

You can’t overwrite an incoming variable.

I.e. the incoming variable will always take precedence and you should create a new variable.

EDIT: To further clarify, your issue is this:

field1: "{{ field1
   ^            ^
   |--SAME NAME-|

not the use of multiple filters.

So what happens is, you’re getting your original input variable, not your altered variable.

PedroLamas · May 4, 2021, 4:21pm

Fair enough, I understand if that is the case, however I can’t find anything like that on the documentation - and I have tried to find something on it…

I’ve now open the issue on this matter, if it is now a bug it will at least be closed with a comment confirming that.

petro · May 4, 2021, 4:23pm

Right, but that’ll be shut down because your issue is not the filters and the use of the same variable.

Example: You provide the following variable to your script: foo: TEST and you have foo: "{{ foo | default | lower }}" in your variable section. No matter what, if foo is provided you’ll always get foo: TEST. and lower will never be applied because you cannot overwrite what’s incoming.

Ostracizado · May 4, 2021, 5:55pm

Still no one else with the excessive cpu usage and high temperature, since updating from 2021.4.5 to 2021.4.6?

As of now, and still without errors:

stevemann · May 4, 2021, 10:39pm

What sensors give you those charts?

Ostracizado · May 4, 2021, 10:58pm

Command line, for Cpu Temperature.

  - platform: command_line
    name: CPU Temperature
    command: "cat /sys/class/thermal/thermal_zone0/temp"
    unit_of_measurement: "°C"
    value_template: "{{ value | multiply(0.001) | round(1) }}"

And System monitor, for processor use.

  - platform: systemmonitor
    resources:
      - type: disk_use_percent
        arg: /home
      - type: memory_free
      - type: processor_use

stevemann · May 5, 2021, 2:54am

Thanks. I learned something new today.

mattlward · May 7, 2021, 9:16pm

Did you get this resolved? I am getting the exact error prepping to go to 2021.5. I have installed python3.8. Running supervised.

Eddie46848 · May 7, 2021, 10:04pm

Hi. Yes.
See this link, deleting this folder solved it for me.

Ostracizado · May 7, 2021, 10:18pm

I’ll be… It was the zigbee2mqtt integration. It was eating the CPU.

Moments after uninstalling it:

nickrout · May 7, 2021, 10:29pm

Its something peculiar to your setup I think.

Add-on CPU Usage 0 % Add-on memory usage 0.8%

mmiller7 · May 8, 2021, 3:10am

I see you have a long value for “id” which I’ve never seen referenced in docs before. How is this determined? Can I just duplicate the “alias” field (which I already make unique)?

I just went to try the new debug feature and it says “only available with unique ID”…I’m guessing that’s this field? How do I make it so I can use the debugger?

tom_l · May 8, 2021, 4:00am

It is a UUID generated by a VSCode plugin.

Yes.

e-raser · May 8, 2021, 7:37pm

Is it possible to configure the history size for the trace feature? Currently trace feature is “only” available for last 5 events of an automation. Couldn´t find a doc section in case it can be configured.

e-raser · May 8, 2021, 7:48pm

Is this an option to work around this?

Would need it for integrations/platforms like alarm and device_tracker (maybe also uptime, filesize, systemmonitor, command_line, etc.). “id” or “unique_id” unfortunately seems to not be accepted.

petro · May 8, 2021, 10:11pm

you have to wait for an update to the integration that allows unique_id’s.

nickrout · May 9, 2021, 12:45am

What do you think you need to work around. This is not an error.