oui j’ai exactement les mêmes symptômes depuis la page web du routeur.
dès que j’ai un moment je recharge la conf 4-4b+Coupe_Route1
@Tochy 
J’essaye de corriger les avertissements ou erreurs qui remontent dans temps en temps dans les journaux. Je voulais tester les suggestions de Copilot mais je suis preneur d’avis avant de faire des bêtises.
Pour cette avertissement :
Template variable warning: list object has no element 1 when rendering '{{ (state_attr('sensor.msunpv_xml', 'cmdPos')|replace("a","10")).split(";")[1] }}'
Copilot indique " L’avertissement que vous recevez signifie que la liste générée par votre template n’a pas d’élément à l’index 1. Cela se produit probablement parce que la chaîne de caractères que vous essayez de diviser ne contient pas de point-virgule (; ), ou qu’il n’y a pas assez d’éléments après la division." et me suggère de corriger le template comme suit :
{% set cmdPos = (state_attr('sensor.msunpv_xml', 'cmdPos')|replace("a","10")).split(";") %}
{{ cmdPos[1] if cmdPos|length > 1 else 'Valeur par défaut' }}
Ensuite, pour celui-ci :
Template variable error: 'None' has no attribute 'split' when rendering '{{ state_attr('sensor.msunpv_xml', 'cmdPos').split(";")[7] }}'
Il me retourne " Cet avertissement signifie que l’attribut cmdPos de votre capteur sensor.msunpv_xml est None, ce qui signifie qu’il n’a pas de valeur définie. Lorsque vous essayez d’appeler la méthode split sur None, cela provoque une erreur.
Pour corriger cela, vous pouvez vérifier si cmdPos n’est pas None avant d’essayer de le diviser. Voici comment vous pouvez modifier votre template :"
{% set cmdPos = state_attr('sensor.msunpv_xml', 'cmdPos') %}
{{ cmdPos.split(";")[7] if cmdPos is not none else 'Valeur par défaut' }}
Je dois aussi avoir des moments ou le msunpv se déconnecte du réseau
Error fetching data: http://192.168.10.172/status.xml failed with Server disconnected without sending a response.
avec ce type d’erreur ou il manquerait des valeurs par défaut
TemplateError('ValueError: Template error: float got invalid input 'unavailable' when rendering template '{{ (states('sensor.msunpv_powreso')|float) }}' but no default was specified') while processing template 'Template<template=({{ (states('sensor.msunpv_powreso')|float) }}) renders=1664>' for attribute '_attr_native_value' in entity 'sensor.energie_msunpv_pow_reso'
Qu’en penses tu ?
Salut
Je suis au courant pour ces avertissements. Ils se produisent soit au redémarrage de HA soit si le msunpv ne réponds plus.
En fonctionnement normal, les valeurs vont remonter quand la lecture du XML se fera soit 30 secondes après le redémarrage de HA ou du msunpv.
Pour les sensors du peut faire afficher un 0 à la place de rien du tout en modifiant les float et les int par float(0) et int(0)
Pour la partie état des commandes il faudrait rajouter un test pour savoir si msunpvxml est égal à ok avant de les récupérer.
Perso ça ne me perturbe pas plus que cela de ne rien avoir jusqu’à la première lecture du msunpv tant que HA le permet.
Édit: une autre solution serait de rajouter un availability sur tous les sensors pour ne plus avoir les avertissements
Salut
C’est comme tu veux tu peux soit l’ignorer et ça fonctionnera quand même, soit remplacer tous les
- service: input...
Par
- action: input...
Depuis une des dernières mise à jour service a été remplacer par action, mais continue de fonctionner par mesure de rétro compatibilité (du moins pour le moment)
Merci pour la réponse aussi rapide.
Je vais le remplacer, on sait jamais si dans x mois/année ce n’est plus rétrocompatible, je ne me souviendrais plus pourquoi cela ne fonctionne pas 
J’en profite pour faire une passe dessus. Dans le même genre, cette modif doit elle bien être faite de cette manière ?
automation:
- id: 'msunpv_update_progh'
alias: msunpv - Mise à jour affichage programmation horaire
description: "Force un refresh de msunpv_proghoraire_xml après avoir charger le page correspondante du routeur à l'aide de la shell_command.msunpv_enable_progh."
trigger:
- platform: state
entity_id:
- sensor.msunpv_timerballon_1
to: unavailable
for:
hours: 0
minutes: 2
seconds: 0
modifié en
automation:
- id: 'msunpv_update_progh'
alias: msunpv - Mise à jour affichage programmation horaire
description: "Force un refresh de msunpv_proghoraire_xml après avoir charger le page correspondante du routeur à l'aide de la shell_command.msunpv_enable_progh."
triggers:
- trigger: state
entity_id:
- sensor.msunpv_timerballon_1
to: unavailable
for:
hours: 0
minutes: 2
seconds: 0
Salut
Oui il me semble que c’est la nouvelle syntaxe. Je dis semble car je ne l’ai pas encore bien en tête.
Mais c’est comme pour action, normalement aucune incidence.
Ayant un peu de temps j’ai vérifié et il n’y a pas que ça à changer dans les automatisations
Avant :
automation:
- id: 'msunpv_update_progh'
alias: msunpv - Mise à jour affichage programmation horaire
description: "Force un refresh de msunpv_proghoraire_xml après avoir charger le page correspondante du routeur à l'aide de la shell_command.msunpv_enable_progh."
trigger:
- platform: state
entity_id:
- sensor.msunpv_timerballon_1
- sensor.msunpv_timerballon_2
- sensor.msunpv_timerballon_3
- sensor.msunpv_timerballon_4
- sensor.msunpv_timerballon_jours
to: unavailable
for:
hours: 0
minutes: 2
seconds: 0
condition: []
action:
- service: shell_command.msunpv_enable_progh
data: {}
- delay:
hours: 0
minutes: 0
seconds: 5
milliseconds: 0
- service: homeassistant.update_entity
data: {}
target:
entity_id: sensor.msunpv_proghoraire_xml
mode: single
Après :
automation:
- id: 'msunpv_update_progh'
alias: msunpv - Mise à jour affichage programmation horaire
description: "Force un refresh de msunpv_proghoraire_xml après avoir charger le page correspondante du routeur à l'aide de la shell_command.msunpv_enable_progh."
triggers:
- trigger: state
entity_id:
- sensor.msunpv_timerballon_1
to: unavailable
for:
hours: 0
minutes: 2
seconds: 0
conditions: []
actions:
- action: shell_command.msunpv_enable_progh
data: {}
- delay:
hours: 0
minutes: 0
seconds: 5
milliseconds: 0
- action: homeassistant.update_entity
data: {}
target:
entity_id: sensor.msunpv_proghoraire_xml
mode: single
On rajoute triggers:
platform: devient trigger:
condition: devient conditions:
action: devient actions:
service: devient action:
Je suis en train de mettre à jour les fichiers concernés par ces changements:
msunpv_addons_progh_2_2.yaml
msunpv_addons_progh_4_4.yaml
msunpv_addons_thermostats.yaml
msunpv_scripts_2_2.yaml
msunpv_scripts_4_4.yaml
msunpv_save_sd_csv.yaml
En cas de remplacement des fichiers pensez à bien remettre votre adresse ip si necessaire.
PS: je n’ai pas pris le temps de tester, si il y a problèmes n’hésitez pas à me le dire.
Bonjour,
Etant nouvel utilisateur de HA depuis peu et du coup pas à l’aise avec les automatisations.
J’aimerais créer un scénario du genre (sans sonde).
Si cumulus 400% pendant x temps dans la journée ne pas démarrer la chauffe sur la plage horaire.
Si quelqu’un a déjà fait et veux bien partager je suis preneur.
Merci
Salut
Comment est déclenchée la chauffe sur la plage horaire ?
C’est le routeur qui gère ça par autobal ou c’est géré côté HA ?
Quelles sont les horaires de la plage horaire ?
Les scripts pour pour commander le routeur sont ils fonctionnels sur ta config ?
As tu quelque-chose sur la seconde sortie du routeur ?
Bonjour,
Le chauffe eau par le routeur sur une plage horaire de 2H à 5H30. En journée tous le surplus est envoyé dans celui-ci sauf si 400% atteint et la cadeau pour EDF car rien de branché sur la 2ème sortie.
Pour les scripts je les ai installé mais pas testé
Ok il va falloir tester si les scripts fonctionnent sinon ça va être compliqué de commander le bouton autobal du routeur.
Question subsidiaire quelle est ta puissance de panneaux installées et celle du cumulus.
Comment fait on pour tester les script?
J’ai 2.5Kw de puissance installé et le cumulus fait 3kw
Pour tester les scripts tu vas dans outils de développement/actions et tu tapes ça :
Ensuite tu cliques sur exécuter l’action.
Une fois l’action exécutée (Le bouton devient vert si tout se passe bien) tu vérifies sur la page web du routeur que autobal a bien changé d’état, passe de allumé à éteint ou l’inverse selon la position de départ.
C’est bon
J’ai tester la commande auto et manu.
pour la suite es ce qu’il y a un exemple de config a me proposer?
Oui
Voici le code qui va créer un input_boolean et deux automattisations.
Crée un fichier msunpv_bal_hot au même niveau que les fichiers du msunpv (Même manip que quand tu as installé l’intégration)
Dedans tu copies ce code :
input_boolean:
cumulus_hot:
name: Cumulus chaud
icon: mdi:water-boiler
automation:
- id: 'msunpv_bal_hot'
alias: msunpv_bal_hot
description: "Active un input_boolean si on a de l'injection de 50W pendant 5 minutes"
triggers:
- entity_id: sensor.msunpv_powreso
for:
hours: 0
minutes: 5
seconds: 0
below: -50
trigger: numeric_state
conditions: []
actions:
- target:
entity_id:
- input_boolean.cumulus_hot
data: {}
action: input_boolean.turn_off
- target:
entity_id:
- input_boolean.cumulus_hot
data: {}
action: input_boolean.turn_on
mode: single
- id: 'msunpv_bascule_autobal'
alias: msunpv_bascule_autobal
description: "Laisse le cumulus sur autobal si il n'y a pas eu de chauffe complète par les PV sinon désactive autobal avec ré_activation automatique à 5h35"
triggers:
- trigger: state
entity_id:
- input_boolean.cumulus_hot
from: "off"
to: "on"
id: Désactiver autobal
- trigger: state
entity_id:
- input_boolean.cumulus_hot
from: "on"
to: "off"
id: Activer autobal
- trigger: time
at: "05:35:00"
id: Activer autobal
conditions: []
actions:
- choose:
- conditions:
- condition: trigger
id:
- Désactiver autobal
- condition: template
value_template: "{{ states('sensor.msunpv_cmd_s1') in ['2','6','10'] }}"
sequence:
- action: script.msunpv_s1_off
metadata: {}
data: {}
- conditions:
- condition: trigger
id:
- Activer autobal
- condition: template
value_template: "{{ not states('sensor.msunpv_cmd_s1') in ['2','6','10'] }}"
sequence:
- action: script.msunpv_s1_auto
metadata: {}
data: {}
- action: input_boolean.turn_off
target:
entity_id: input_boolean.cumulus_hot
data: {}
mode: single
Tu redémarres HA et le tour est joué.
La première automatisation msunpv_bal_hot passe à On l’input_boolean.cumulus_hot si dans la journée tu as une injection réseau à -50W pendant 5 minutes, ce qui veut dire que ton cumulus a fini de chauffer.
La seconde bascule les sorties routeur manubal et autobal à Off si le cumulus à chauffer avec les PV dans la journée (cumulus_hot à On) ou laisse autobal sur On si pas assez chaud.
Elle remet en plus cumulus_hot sur Off à 5h35 (après l’heure de ta chauffe eventuelle) pour repartir sur un nouveau cycle le lendemain.
Top!
Merci beaucoup, encore une ptite question. Si je comprend bien pour la seconde automation il faut quand meme que je laisse ma prog horaire dans le routeur.
Tout à fait
tu laisses la prog horaire sur le routeur et ça active autobal au besoin ou pas.
Ps: Reprends le code au dessus, je viens de le modifier, j’avais oublier la desactivation de l’input_boolean.
Tu peux également ajouter l’input_booléan cumulus_hot sur ton dashboard, il te donnera une indication visuelle quand ton cumulus sera chaud.