Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add val_tpl on HA discovery configuration - fix issue #939 #941

Closed
wants to merge 2 commits into from

Conversation

Odyno
Copy link
Contributor

@Odyno Odyno commented May 7, 2021

fix issue #939

@1technophile
Copy link
Owner

thanks for the proposal,
I would like to know how the switch goes back to OFF in this case?

@Odyno
Copy link
Contributor Author

Odyno commented May 7, 2021

This is an interesting point, it all started here.

In short:
I created one Automation on HA that reset the switch... below the code

alias: Reset All Pirs
description: ''
trigger:
  - platform: state
    entity_id:
      - switch.2741642
      - switch.11031942
      - switch.....
    to: 'on'
    for: '00:00:05'
condition: [ ... ... ... ]
action:
  - delay:
      hours: 0
      minutes: 0
      seconds: 5
      milliseconds: 0
  - service: switch.turn_off
    target:
      entity_id: '{{ trigger.entity_id }}'

With more context:
Considerations that led me to this PR:

without the "val_tpl" no automatism will change the state of the switch, even if a "pl_on" is defined (and it is equal to the value) and even if on the MQTT topic we receive the update from "the real switch". So, in the end, we have a switch created by discovery that forces me into constraints (the "pl_on") and it is always stationary ( so... in my opinion just confusing and it is useless).

On the other hand, there is no info on pl_off, but is present the cmd_t that indicate how to change the state... so finally all are free to switch manually the sensor to something that is "on" (as specified on "pl_on") or not "on" ( so.... it can be just off).

If I were to look at the configuration without the "val_tpl" (according to the point of view) it is useless. If I try to interpret this "sensor", by giving the value "val_tpl", it clearly becomes the modelling of the sensor that provide triggers.

The sensor provide just the "event on" and is up to listener reset the trigger.

Open to discuss it!

@1technophile
Copy link
Owner

ok, I see, maybe it could be nice to add to the docs (integrate/home assistant) your script that you are using with this PR so as to set the status to OFF?

@1technophile 1technophile added this to the v0.9.7 milestone May 9, 2021
@Odyno
Copy link
Contributor Author

Odyno commented May 10, 2021

ok!

@1technophile
Copy link
Owner

Thanks, could you rebase from development branch please

@Odyno
Copy link
Contributor Author

Odyno commented May 11, 2021

done

@Odyno
Copy link
Contributor Author

Odyno commented May 13, 2021

@1technophile let me stop this PR, I just discovered that this configuration create a lot of error on home assistant, because sometime the value is not present and on home assistant is raised a lot of warning and error

2021-05-13 18:37:56 ERROR (MainThread) [homeassistant.helpers.template] Template variable error: 'value_json' is undefined when rendering '{{ value_json.value | is_defined }}'
2021-05-13 18:37:56 ERROR (MainThread) [homeassistant.helpers.template] Error parsing value: 'value_json' is undefined (value: OFF, template: {{ value_json.value | is_defined }}) 

@Odyno Odyno closed this May 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants