Bonjour,
Le contexte:
Dans la suite de mon intégration de HA pour remplacer Domoticz, je cherche à réutiliser mes télécommandes chacon pour piloter mes volets (3 commandes on + off newkakuxxxx_idbouton + commande on ou off, avec cerise sur le gatau, un bouton on et un off all avec id 0) et quelques autres télécommandes chinoises très bien gérés avec rflink. J’ai réussi à gérer le fait que HA ne crée pas automatiquement le bouton pour « allon » (et « alloff ») en définissant explicitement les devices.
Dans domoticz, via dzvents, je récupère l’événement et le statut (on/off) à chaque fois. Parfait, mes télécommandes permettent de piloter les volets, quel qu’en soit le statut.
Je veux faire la même chose dans HA.
Le problème:
HA est trop intelligent! il gère le statut On/off des interrupteurs de la télécommande, et si on clique sur « on » sur la télécommande et que le statut de ce switch lié à cet élément rflink, il cherche pas à comprendre, pas d’événement sur l’automatisme (DZ gère aussi le statut, mais il prévient quand même et lance le script lua).
Bein oui, il est déjà à On!
Sauf que… mon volet a vécu à côté… la dernière commande était peut être « on », mais pas le volet. Donc je veux pouvoir répondre à « on », même si c’est déjà « on ».
Mon code pour rflink dans configuration.yaml:
rflink:
host: 192.168.1.158
port: 2000
logger:
default: error
logs:
rflink: debug
homeassistant.components.rflink: debug
switch:
- platform: rflink
automatic_add: false #true
device_defaults:
fire_event: true
- platform: rflink
devices:
newkaku_016dd76a_0:
name: Bouton4
newkaku_016dd76a_1:
name: Bouton1
newkaku_016dd76a_2:
name: Bouton2
newkaku_016dd76a_3:
name: Bouton3
Un exemple de l’événement qui m’intéresse dans les logs:
2023-09-19 15:42:00.280 DEBUG (MainThread) [rflink.protocol] received data: 20;ED;NewKaku
2023-09-19 15:42:00.284 DEBUG (MainThread) [rflink.protocol] received data: ;ID=016dd76a;SWITCH=3;CM
2023-09-19 15:42:00.288 DEBUG (MainThread) [rflink.protocol] received data: D=ON;
2023-09-19 15:42:00.288 DEBUG (MainThread) [rflink.protocol] got packet: 20;ED;NewKaku;ID=016dd76a;SWITCH=3;CMD=ON;
2023-09-19 15:42:00.288 DEBUG (MainThread) [rflink.protocol] decoded packet: {'node': 'gateway', 'protocol': 'newkaku', 'id': '016dd76a', 'switch': '3', 'command': 'on'}
2023-09-19 15:42:00.288 DEBUG (MainThread) [rflink.protocol] got event: {'id': 'newkaku_016dd76a_3', 'command': 'on'}
2023-09-19 15:42:00.288 DEBUG (MainThread) [homeassistant.components.rflink] event of type command: {'id': 'newkaku_016dd76a_3', 'command': 'on'}
2023-09-19 15:42:00.288 DEBUG (MainThread) [homeassistant.components.rflink] entity_ids: ['switch.bouton3']
2023-09-19 15:42:00.288 DEBUG (MainThread) [homeassistant.components.rflink] passing event to switch.bouton3
ou pour le allon:
2023-09-19 15:41:05.064 DEBUG (MainThread) [rflink.protocol] received data: 20;E9;Ne
2023-09-19 15:41:05.068 DEBUG (MainThread) [rflink.protocol] received data: wKaku;ID=016dd76a;SWITCH
2023-09-19 15:41:05.073 DEBUG (MainThread) [rflink.protocol] received data: =0;CMD=ALLON;
2023-09-19 15:41:05.073 DEBUG (MainThread) [rflink.protocol] got packet: 20;E9;NewKaku;ID=016dd76a;SWITCH=0;CMD=ALLON;
2023-09-19 15:41:05.073 DEBUG (MainThread) [rflink.protocol] decoded packet: {'node': 'gateway', 'protocol': 'newkaku', 'id': '016dd76a', 'switch': '0', 'command': 'allon'}
2023-09-19 15:41:05.073 DEBUG (MainThread) [rflink.protocol] got event: {'id': 'newkaku_016dd76a_0', 'command': 'allon'}
2023-09-19 15:41:05.073 DEBUG (MainThread) [homeassistant.components.rflink] event of type command: {'id': 'newkaku_016dd76a_0', 'command': 'allon'}
2023-09-19 15:41:05.074 DEBUG (MainThread) [homeassistant.components.rflink] entity_ids: ['switch.bouton4']
2023-09-19 15:41:05.074 DEBUG (MainThread) [homeassistant.components.rflink] passing event to switch.bouton4
L’automatisme (qui ouvre/ferme 2 volets différents sur cette télécommande) fonctionne, mais seulement si l’état du bouton n’est pas celui sur lequel on appuie.
C’est bien, mais je ne veux pas fermer les volets pour les rouvrir alors qu’ils étaient à 50%!
- id: '1695067838053'
alias: Telecommande_Salon_Volet_cuisine_ouvre
description: 'Ouvrir les 2 volets cuisine avec la télécommande du salon.'
trigger:
- platform: state
entity_id:
- switch.bouton1
condition: []
action:
- service: mqtt.publish
data:
qos: 0
retain: false
topic: volets/0/command
payload_template: '{% if is_state("switch.bouton1", "on") -%} 0 {%- else -%}
100 {%- endif %}'
- service: mqtt.publish
data:
qos: 0
retain: false
payload_template: '{% if is_state("switch.bouton1", "on") -%} 0 {%- else -%}
100 {%- endif %}'
topic: volets/1/command
mode: single
Dans ma soirée qui rallonge (cf @GDX2 ), j’ai imaginé plusieurs pistes:
- récupérer un autre événement que « state_changed » qui pourrait être lancé par rflink:
échec (et en plus, j’ai rien compris à la doc sur les events, les exemples sont pas assez explicites de mon point de vue. Si vous avez des exemples…).
J’ai vu passer « command » en me disant « chouette, une porte »… mais HA ne veut pas d’autre événement que « state_changed » dans l’automatisme. - ne pas passer par un switch ou un binary switch. Oui, mais c’est pas pris en charge par rflink. Est ce qu’on peut étendre sans refaire rflink ?
- changer le state du switch en « None » (ou autre Null) après le traitement de l’événement histoire d’être prêt à traiter un nouvel appui, ce qui l’obligerait à réaliser l’action. Oui, mais comment? (mais pas switch_on ou switch_off comme vu dans un autre thread sur les sonnettes, parce que je ne sais pas quel sera le prochain appui) .
j’ai essayé le code suivant dans la suite des actions en me disant qu’après tout, un bouton n’est qu’une variable (on peut le changer dans le menu dev/etats), mais c’est sans effet. Peut être un problème de syntaxe?
- variables:
switch.bouton4: None
Bref, vous avez compris, je cherche à faire un « bouton poussoir » sans état tout bête, et … je coince!
C’est peut être un travers dû à Domoticz et ses push button bien pratiques…
Merci pour votre aide!
Ma configuration
version | core-2023.9.2 |
---|---|
installation_type | Home Assistant Supervised |
dev | false |
hassio | true |
docker | true |
user | root |
virtualenv | false |
python_version | 3.11.5 |
os_name | Linux |
os_version | 6.1.0-11-amd64 |
arch | x86_64 |
timezone | Europe/Paris |
config_dir | /config |
Home Assistant Community Store
GitHub API | ok |
---|---|
GitHub Content | pending |
GitHub Web | pending |
GitHub API Calls Remaining | 5000 |
Installed Version | 1.32.1 |
Stage | running |
Available Repositories | 1283 |
Downloaded Repositories | 5 |
Home Assistant Cloud
logged_in | true |
---|---|
subscription_expiration | 9 octobre 2023 à 02:00 |
relayer_connected | true |
relayer_region | eu-central-1 |
remote_enabled | true |
remote_connected | true |
alexa_enabled | true |
google_enabled | true |
remote_server | eu-central-1-15.ui.nabu.casa |
certificate_status | ready |
can_reach_cert_server | pending |
can_reach_cloud_auth | pending |
can_reach_cloud | pending |
Home Assistant Supervisor
host_os | Debian GNU/Linux 12 (bookworm) |
---|---|
update_channel | stable |
supervisor_version | supervisor-2023.09.2 |
agent_version | 1.5.1 |
docker_version | 24.0.5 |
disk_total | 57.8 GB |
disk_used | 16.9 GB |
healthy | true |
supported | true |
supervisor_api | ok |
version_api | ok |
installed_addons | rtl_433 MQTT Auto Discovery (0.6.0), File editor (5.6.0), Terminal & SSH (9.7.1), AppDaemon (0.13.5), Studio Code Server (5.10.2), SSH Tunnel & Forwarding (1.2.0), InfluxDB (4.7.0), Grafana (9.0.3) |
Dashboards
dashboards | 9 |
---|---|
resources | 4 |
views | 12 |
mode | storage |
Recorder
oldest_recorder_run | 9 septembre 2023 à 02:12 |
---|---|
current_recorder_run | 19 septembre 2023 à 01:01 |
estimated_db_size | 382.34 MiB |
database_engine | sqlite |
database_version | 3.41.2 |