Default values for script parameters?

Configuration
21

I have to say I agree with Daniel.

I also thought default provided a value if a field was not specified when the script was called. Now I know why my script was behaving as I expected.

22

Now that you both know how it works, you can team up and re-phrase the documentation’s description so that it’s clearer to you and to anyone else who misunderstands the meaning of “as shown in the UI”.

1 Like
23

I think there were a misunderstanding between us. From what I quoted I see that you understand default parameters like I do: If not provided, then default is used. In fact you pointed it out as a bug and I thought it was intentional, therefore my confusion. Do I make sense now?
Since we all agree that default values should be used if you don’t provide that value to the script, I think this should be reported as a bug rather than a documentation update. No?

Also, from your example I noticed that the fields will not appear on the UI unless you specify a selector type. I expected it to use the text one as default, which is not the case

24

Hang on a minute…

(Firstly, is the default new? I don’t remember seeing it)

Are you saying that this:

  my_script:
    description: My script which does something
    fields: 
      some_field:
        description: Meaningless variable passed in
        example: True
    sequence:
      - choose:
          - conditions:
              - condition: template
                value_template: "{{ some_field | default(false) }}"

Can now be done like this:

  my_script:
    description: My script which does something
    fields: 
      some_field:
        description: Meaningless variable passed in
        example: True
        default: False
    sequence:
      - choose:
          - conditions:
              - condition: template
                value_template: "{{ some_field }}"
2 Likes
25

Literally, “as shown in the UI” and nothing more than that.

tl;dr
This FR was never implemented.

26

That is what I thought, and what I think makes more sense.
But no, seems that it is only a documentation feature, which makes it, from my perspective, useless. You can just write that down on the description already, no need to introduce a new field that has no real use.

2 Likes
27

For Developer Tools > Services:

  • The value of example is shown in YAML mode.
  • The value of default is shown in UI mode.

Try it.

28

Topic of long time ago, but that just what I’m looking for.

In this example, can something like this be done (it is not working…) ?

  - service: notify.notification_devices
    data:
      title: >
        {% if title | length | int > 0 %}
           "{{ title }}"
        {% else %}
           "No title"
        {% endif %}
29

This probably answers the original question…
You can have variables in scripts & script Blueprints as well as fields, so…

fields:
  thing_1:
    ---
variables:
  thing_1: >
    (% if not thing_1 | default('') %}
      "default value"
    {% else %}
      thing_1
    {% endif %}

There is actually a default in fields: now as well, but I am trying to determine the difference between example and default

1 Like