Bonjour,

J'ai vu dans votre vidéo de présentation des évolutions prévues pour 2026 que vous pensiez intégrer les prévisions météo pour l'automatisation du pilotage des relais en HC.

Un développeur propose déjà cela sur sa branche de tasmota/teleinfo en passant par les API de https://forecast.solar/. Il faut entrer ses coordonnées GPS, l'orientation et l'inclinaison des panneaux ainsi que la puissance crête installée. Avec ça, les prévisions suivantes sont alors disponibles : puissance produite instantanée (pas très intéressant ici), énergie produite aujourd'hui et énergie produite demain (en kWh).

Je ne sais pas dans quelle mesure son implémentation pourrait être réutilisée sur ce projet, mais je mets le lien vers sa branche ici : https://github.com/NicolasBernaerts/tasm...r/teleinfo.

En espérant avoir été utile. 

Une nouvelle version V17.11 est dispo en téléchargement. 
Quelqu'un sait quelles sont les evols/ correctifs par rapport à le V17.10 ?

Bonjour

Je suis en routage relais avec une unique période de 0 à 24h, Seuil PW 0, Ouvre Max 0 Temp <=60. Mon but est d'envoyer au routeur le surplus solaire qui, pour mon cas, est égal à la valeur de la donnée maison injectée (Rendu Enedis).

Dans mon automatisation je mets:

action: mqtt.publish
metadata: {}
data:
  evaluate_payload: false
  qos: 0
  retain: false
  topic: routeur1_rms/Chauffe_Eau
  payload: >-
    {"Mode":"Multi","Periode":1,"SeuilOn":0,"SeuilOff":{(states('sensor.surplus_solaire')|int)}},"OuvreMax":100}

Qui pour moi veut dire "démarre le Chauffe Eau avec une valeur max (Seuil Off) égale au surplus solaire et en utilisant toute la puissance (Ouvre Max)" sachant que cette commande ne sera PAS exécutée si la  temp du Chauffe Eau est > 60 degrés.

Mon raisonnement est il correct? Je m'interroge car dans l'onglet Accueil je vois bien l'action à 100% mais aucune donnée concernant le seuil.

Aussi, si mon raisonnement est correct, la valeur donnée maison injectée devrait être à zéro puisque normalement consommée. Est ce à dire que la valeur affichée est à comprendre "voici ce que l'on injecterai si l'action n'était pas exécutée" ou cela veut dire que ma commande n'est pas prise en compte?

Merci pour toute information

Daniel

Depuis la semaine dernière, une limitation préjudiciable est intervenue suite à la mise à jour intervenue par APsystems.
En effet, certaines fonctionnalités substantielles comme la limitation de l'injection sur le réseau sont désormais inaccessibles depuis une connexion sur l'interface web ECU-C via le réseau local.
Il est donc devenu impossible de modifier certains paramètres comme le Zero Export, Threse phase balance, .... de même il n'est plus possible de voir le comportement de chacune des phases tant en production, consommation, exportation.
A priori, ces accès sont seulement mis à disposition des installateurs professionnels.
Certaines URL cachées fonctionnent encore comme la coupure des micro-onduleurs, l'exportation, sous excel, de la production des panneaux.
Voila qui est bien embêtant ! si vous disposez d'informations complémentaires, merci d'avance, à tous,  de les partager.

Bonjour André 
Bonjours tous, 

Pouvez vous m'aider:
  Est il possible de faire varier l'ouverture du SSR en utilisant Mqtt ?

j'utilise la version 17.11 et je suis novice !
En configuration Normale cela fonctionne bien.

Dans un cas particulier  : je souhaite piloter le SSR uniquement par Mqtt

ce qui fonctionne :

- {"tOnOff":24} fonctionne et utilise "ouverture si forcé" xx % ( 30..100%)

ce qui ne fonctionne pas :

- {"Mode":"Multi","Periode":1,"OuvreMax":65} ne fonctionne pas
    Données Brutes ==> Action MQTT : routeur_rms/SSR1 | {"Mode":"Multi","Periode":1,"OuvreMax":65}

il doit me manquer une information !  

Je pense que le routage est prioritaire sur Mqtt sauf en forçage (d'où sont nom)

Bonjour à tous,
Une question avant de passer commande : 
Les Kits préassemblés (je suis intéressé par le Kit E) sont-ils testés avant expédition selon la procédure décrite dans la documentation ? Ou faut il faire ou refaire les tests décrits ?
Merci pour vos réponses 
J'aurai 3 bornes de charge à équiper, en faisant un premier essai avec le Kit E (bornes triphasées qui seront adaptées au routeur VE.
Patrick

Bonjour depuis l'upgrade de 17.06 en 17.08
HA derniere version m'indique des problèmes sur des capteurs qui n'ont plus de classe d'état définis
les capteurs sont les suivants :
- sensor.routeur_rms_tension_t
- sensor.routeur_rms_intensite_t
- sensor.routeur_rms_frequence
- sensor.routeur_temperature_canal_0
- sensor.routeur_rms_esp_32-on

Merci

Bonjour André,
Bonjour tout le monde,
Je suis en train de peaufiner les réglages des actions de mon routeur qui fait déjà superbement le job.
Ma question ou demande :
Est il possible de mettre les données de la seconde sonde comme déclencheur d'une action? Je suis en ulx2.
Par exemple, si PW seconde sonde>500 alors gpio14 off à on
Merci d'avance pour les réponses,
Bonne journée,
Gabriel

Bonjour,
Je rencontre un problème avec le choix d'un pourcentage d'ouverture inférieure à 100% en monde On/Off avec un SSR : j'ai toujours 100% de puissance sur ma charge (Je le constate sur l'indication de Puissance active routée et sur le graphe de pourcentage d'ouverture).
Alors qu'avec le triac en Demi-sinus (ou autres découpe), pas de problème ça fonctionne bien.
Je rencontre le même problème avec le paramétrage " Ouverture si forcée [xx] %" ; quand je force en manuel ("Forçage" On sur la page d’accueil) j'ai toujours 100% de puissance avec les SSR.
Deux hypothèses :
- il y a un problème
- on ne peut pas réduire la puissance en mode On/Off malgré le paramétrage laissé disponible.

Je me pose aussi la question comment peut-on limiter la puissance délivrée en mode On/Off ? Sans découpage, je ne vois comment c'est possible.

Remarque : j'ai un Triac et deux SSR pour commander séparément les trois résistances de mon chauffe-eau en répartissant la puissance pour limiter le découpage de tension.
Je suis dans une logique expérimentale, je teste le routeur dans toutes ses possibilités.

Merci pour vos éclairages.

   

Dans son message  Incohérence MQTT sortie relais temporisée , Bendu13 mentionnait que l'état de la sortie transmis par MQTT ne semblait pas prendre la temporisation de la sortie.

Il me semble que j'ai le même comportement en utilisant l'état d'une action d'un ESP externe.
Si je mets une temporisation dans l'ESP qui émet son état, je note bien le changement d'état de l'action après une temporisation (qui ne semble pas être exactement au temps voulu, mais ce n'est pas le sujet) mais sur le récepteur, l'état de l'action est reçu et changé (à peu près 30 secondes après le changement d'état) bien avant la fin de la temporisation .

C'est normal et voulu, où je délire? D'autres ont déjà noté ça?
Je m'attendais à ce que l'état transmis soit l'état réel, cad l'état après la temporisation.