MQTT Pilotage d'entités avec des numéros, en gros un switch à plusieurs positions

Bonjour et bonne année,

J’ai installé un PVrouter,

Il y a une entité qui est modeinfo qui renvoie un nombre à deux chiffres comme 00, 33 ou autre.

Le chiffre des dizaines représente un mode de la sortie du SSR2 du pv router qui peut avoir 5 variantes mode 1, 2, 3, 4 ou 9.

Le chiffre des unités représente un mode de la sortie du SSR1 du pv router qui peut avoir 5 variantes mode 1, 2, 3, 4 ou 9.

A la base je voulais créer un switch pour changer de mode cependant je suis limité car un switch n’a que 2 positions on et off, de plus quand le modeinfo est sur 4 je dois créer un slider qui va de 0 à 100% sous forme de float.

Selon vous que devrais-je utiliser ? un input number, une automation un blueprint ? ou autre ?
le schéma ressemble à une carte de thermostat sans sonde de température mais avec des nombres reçus et des nombres à envoyer pour changer de mode soit le SSR1 ou le SSR 2.

J’espère avoir été le plus clair possible merci de vos conseils.

Le sujet en partie traité ici m’a donné l’idée de l’approfondire MQTT regroupement sous Nom peripheriques + pilotage - #10 par Zibasedom_Seblang

Salut,

comme la suite n’est pas consécutive, un slider ça va être le bordel …(5,6,7,8 n’existe pas si j’ai bien compris)…
un input select ça me semble plus efficace

input_select:
  mode_ssr1:
    options:
      - "1"
      - "2"
      - "3"
      - "4"
      - "9"
    initial: "1"

  mode_ssr2:
    options:
      - "1"
      - "2"
      - "3"
      - "4"
      - "9"
    initial: "1"

Ensuite coté carte, les sélecteurs de base ou une carte à base de boutons
Et pour le pilotage, une automatisation qui envoie la combinaison des 2

Merci pour cette réponse, oui tu as bien compris que la suite n’est pas consécutive il n’y a que 0, 1, 2, 3, 4 ou 9.

Le input select doit être dans un fichier input_select.yaml ?

Le slider ne serait effectif que lorsque le mode est sur 4 les autres n’ont pas de commande en % juste on ou off.

par contre l’entité envoie systématiquement un nombre à deux chiffres et là je ne vois pas comment faire le tri pour dire que le chiffre des dizaines est ssr2 et le chiffre des unités le ssr1

et comment faire cette automatisation qui envoie la combinaison de nombres ?

image

Pour ça il va falloir jouer avec le code jinja

En gros ton automatisation va appeler un service (celui dédié au changement du mode) avec le recomposition

Je pense saisir l’idée, en exemple quand je vais dans outil de développement → modèle sur l’entité en question :

voici comment est le résultat {{ states('sensor.MODEINFO') }} le résultat est 33 car mes deux SSR sont sur le mode 3, mais comment détailler pour prendre le chiffre 3 des dizaines et séparément le 3 des unités afin de les approprier aux SSR1 et SSR 2?

édit: je m’auto-réponds je peux les sortir comme cela {{ states('sensor.MODEINFO') [0]}} pour le SSR1 et {{ states('sensor.MODEINFO') [1]}}pour le SSR 2. cependant il faut que je l’affecte à une entité nouvelle non pour garder la valeur ?

En fait la question c’est qui pilote qui ?

  • Pour juste de l’affichage (aka découper states('sensor.MODEINFO') et en faire une carte), tu n’as même pas besoin de faire des input_select. Très basiquement tu pourrais afficher directement 33
  • Pour contrôler/piloter/commander, il faut des input select, mais du coup, tu n’as pas forcement besoin de récupérer la valeur de states('sensor.MODEINFO'), mais juste d’envoyer à ton « module », l’info combinée des 2 input_select. Quand c’est en place, si les input valent 22, alors ton states('sensor.MODEINFO')sera à 22 après l’automatisation
  • On peut aussi faire un mix des 2, question de gout et de place

Dans mon idée c’est un mix des deux,

sur la carte je souhaite voir l’état de chaque SSR par exemple SSR1 en mode 3 = gradateur (bouton allumé en vert par exemple) et SSR 2 mode 0 éteint avec donc (bouton allumé en vert le 0 éteint) et pouvoir sélectionner pour le SSR1 le bouton 9 qui s’allume et enclenche le mode test du SSR1.

cela ressemble au thermostat ou on peut cliquer les modes auto/confort/hors-gel/Vacances tout en voyant dans quel mode il se trouve.

je ne sais pas si je suis bien clair dans mon explication.

Alors commence par faire une carte avec les input… Simples commandes avec un affichage basique :

type: entities
entities:
  - entity: input_select.mode_ssr1
  - entity: input_select.mode_ssr2

Il faut que tu vois dans ton intégration comment ça marche pour en déduire les bonnes automatisations (appel des bons services).
Là de ce que tu dis, on dirait que SSR1 et SSR2 sont pilotables indépendamment.
Donc 2 automatisations quasi identiques :

  • l’input select SSR1 en trigger
  • un appel du service dédié à SSR1 avec la valeur de SSR1
    Et pareil pour SSR2

tu peux essayer d’appeler les services dans les outils de dev et créer les automatisations avec l’ui dédiée. Par contre il te faut comprendre comment marche HA ET tes PV … là j’ai l’impression que c’est pas encore très clair pour toi

En effet ce n’est pas très clair, je débute d’ailleurs que veux dire les pv ?

oui, on peut contrôler indépendamment la sortie une de la deux et inversement, si on change le chiffre des dizaine on modifie la sortie 2 et le chiffre des unités modifie la sortie une.

L’exemple du switch montre en partie comment cela fonctionne, je copie le code fonctionnant dans le post de départ de mon idée.

mqtt:

switch:
- unique_id: ‹ PVrouter OnOff ›
name: « PVrouter OnOff »
state_topic: « PVROUTER005/DATA »
value_template: « {{ value_json.MODEINFO }} »
command_topic: « PVROUTER005/SETMODE »
payload_on: « 3 »
payload_off: « 0 »
state_on: « 3 »
state_off: « 0 »
qos: 0
retain: true
device:
name: « pvrouter »
identifiers: « pvrouter005 »
1 « J'aime »

ok donc l’intégration de ton PVrouter doit permettre de faire autre chose que juste récupérer les infos… Donc il ya des entités qui y sont rattachés et des services… Lesquels sont-ils ?

Juste au dessus je l’ai mis.

Pour récupérer les infos states('sensor.MODEINFO') qui donne un nombre à 2 chiffres qu’il faut dissocier.

Pour envoyer les infos command_topic: « PVROUTER005/SETMODE »

Pour l’instant, on va laisser la dissociation de coté, c’est juste cosmétique, le plus difficile c’est de pilote
Une carte avec

type: entities
entities:
  - entity: sensor.MODEINFO
  - entity: input_select.mode_ssr1
  - entity: input_select.mode_ssr2

Ferra le job en attendant.

Ok et quel est le format du json que tu envois ? parce que là par exemple il n’y a rien pour choisir entre SSR1 et SSR2

ça pourrait ressembler à ça

alias: Pilotage SSR1
description: ""
trigger:
  - platform: state
    entity_id:
      - input_select.mode_ssr1
condition: []
action:
  service: mqtt.publish
  data_template:
    topic: "PVROUTER005/SETMODE"
    payload: >
      {{states( 'input_select.mode_ssr1') }}
    retain: false
mode: single

Justement non le soucis est que le mqtt.publish doit se faire avec les deux chiffres

Justement pour les choisir comme je le dis depuis le début, le chiffre des dizaine est le SSr2 et le chiffre des unités le SSR1

Là on a les 2 infos contradictoires… As tu un exemple concret du payload ?

De toute façon, l’affichage CE N’EST PAS LA MÊME CHOSE que le pilotage, s’il faut envoyer 2 chiffres c’est dans l’automatisation que ça se passera…

oui il faut dans l’automation gérer les deux chiffres, mqqt.publish c’est bien l’envoi de données non ? je ne parle pas d’affichage là

Oui, mais mais le payload (le json que l’on envoi) doit respecter un format particulier…
On peut balancer 2 chiffres sur le topic, il faut juste confirmer que c’est juste ça

C’est ça le json doit envoyer deux chiffres

Donc un truc comme ça

alias: Pilotage SSR1 & SSR2
description: ""
trigger:
  - platform: state
    entity_id:
      - input_select.mode_ssr1
      - input_select.mode_ssr2
condition: []
action:
  - service: mqtt.publish
    data_template:
      topic: PVROUTER005/SETMODE
      payload: >
        {{states( 'input_select.mode_ssr2') }}{{ states('input_select.mode_ssr1') }}
      retain: false
mode: single

En mettant tout cela dans configuration.yaml j’ai un paquet d’erreurs:

input_select:
  mode_ssr1:
    options:
      - "0"
      - "1"
      - "2"
      - "3"
      - "4"
      - "9"
    initial: "3"

  mode_ssr2:
    options:
      - "0"
      - "1"
      - "2"
      - "3"
      - "4"
      - "9"
    initial: "3"

type: entities
entities:
  - entity: sensor.MODEINFO
  - entity: input_select.mode_ssr1
  - entity: input_select.mode_ssr2

alias: Pilotage SSR1 & SSR2
description: ""
trigger:
  - platform: state
    entity_id:
      - input_select.mode_ssr1
      - input_select.mode_ssr2
condition: []
action:
  - service: mqtt.publish
    data_template:
      topic: PVROUTER005/SETMODE
      payload: >
        {{states( 'input_select.mode_ssr2') }}{{ states('input_select.mode_ssr1') }}
      retain: false
mode: single
Integration error: alias - Integration 'alias' not found.
Integration error: type - Integration 'type' not found.
Integration error: action - Integration 'action' not found.
Integration error: entities - Integration 'entities' not found.
Integration error: mode - Integration 'mode' not found.
Integration error: condition - Integration 'condition' not found.
Integration error: description - Integration 'description' not found.
Integration error: trigger - Integration 'trigger' not found.

Les input_select ça doit marcher, mais les automatisations c’est pas du tout comme ça … il y a une UI dédiée (avec bascule en yaml possible)