plruffin

Nicolas,

Ok merci pour les switchs virtuels ce serait TOP , les variables moins importants mais si on peut augmenter ce ne sera que mieux.

Après c’est sur que quand le design hard a été fait meme si vous aviez prevu de la marge pas forcement envisagé entrevu a l’époque tant d’ouvertures – extensions donc une memoire peut etre un peut courte Today .

A+

Pascal

Bonjour Nicolas,

Je précise.

En premier il a été necessaire de faire la configuration MQTT plusieurs fois et pour que cela passe correctement j’ai envoyé le discovery non pas global mais entité par entité …

avec la necessité de tout effacer coté HA pour repartir de quelques chose de propre , remarque les parametres coté WES sont strictement les memes depuis le debut et le classique standard par defaut!

Au debut avec MQTT explorer aucune trame de message en dehors de celale de la description! Puis maintenant c’est Ok environs toutes les 10s une trame avec des paquets de datas…

Pour ce qui est de la latence :

sens HA vers Wes , j’active un SW virtuel par exemple , c’est disons quasi instantané (j’ai deux fenetre ouverte une sur le WES l’autre sur le HA ) quand je clique sur l’inter HA il est de suite mis a jour coté WES.

Dans l’autre sens du wes vers le HA la première fois que ca a connecté la latence était horrible , tu change l’état coté wes et plus de 2 minutes après enfin HA est mis a jour (sous explorer MQTT le paquet arrive après ce temps) tandis que sous mon API rest Full il était a jour dans la minute (60s c’est le time update que j’ai mis, pour ne pas surcharger de requete). J’ai tout virere desisntaller les instances MQTT du Wes et recommencer une nouvelle fois et la maintenant disons que c’est correct dans les 15/20s…

Je vais donc laisser quelques jours en doublon et test pour voir si stable . Si ok alors je deconnecterais mon API pour passer sous MQTT . c’est pas mal de boulot car toutes les instances devront etre reprises… Bon après tu coupe l’API et tu cherche celle qui sont inconnues…

une remarque demande je l’avais déja faite me semble t’il: Serait il possible d’augmenter les switchs virtuels par exemple doubler le nombre? je m’explique si on veux faire une programmation avancée évoluée on en utilise forcement pas mal en intermediaire (resultat d’une condition reprise en entrées d’autres conditions) mais aussi si on veux faire communiquer intelligement deux systemes entre eux on devra passer par des « variables intermediaires » et les SW virtuels seront la solution! En effet pour moi le WES en qualite de gestionnaire d’energie c’est lui et uniquement lui qui decide si il commute ou pas une charge ! Donc pas question que HA pilote directement un relais du WES qui lui commande un dispositif . Le HA doit faire une demande au WES par un SWV et c’est le WES qui en lisant dans une regles ce SWV décide en fonction de ces regles de sécurité et de gestion si oui ou non il execute la demande . dans l’autre sens c’est moins critique le HA lit simplement le WES . Donc les 24 sont rapidement FULL. Exemple dans mon cas et pas encore toutes les regles de pilotage coté WES j’ai déja 18 variables intermediaires pour les regles …

Coté MODBUS je vais acheter des modules DIO de Waveshare et je vais tester prochainement des extension surtout pour le cote inputs qui est le point faible actuellement du WES cote output le module extension est parfait et plusieurs possibles donc on a de la marge. Comme dit deja si on veux faire de la gestion avancé il est necessaire d’avoir des retours d’informations des equipements vers le WES et cela ne peut se faire que soit materiellement, soit par connexion virtuelle avec MQTT et Modbus ce coté c’est grandement amélioré pour les équipements complexes. Toutefois pour les equipements simples non connecté du marché electrique l’usage du cablé est encore necessaire.

A+

Pascal

@Nicolas, Predict a priori Ok j’ai bien Rouge Rouge et les bonnes valeurs .

Pour info ceux qui suivent mon anomalie tempo : Changement Cpt pas mieux je suis Bleu alors que rouge (tant mieux pour la facture) et devinez ENEDIS 3 mois plus tard par mail m’indique « On a vu que dans votre coin il y a des pertubations sur le reseau qui genes le concentrateur on ne peut donner de date de rétablissement »

Ce que je disais le CPL ENEDIS (Ex EDF) pourri par des clients qui injecte plein de parasites. Un point a approfondir il y a ces derniers temps beaucoup de solaire qui c’est intallé…les Onduleurs Solaire (surtout ceux pas cher) ont la facheuse tendance a faire de la « Merde ».

A+

Fra,cky 77,

Tu as mis quoi comme app, appareils et service coté HA car moi avec Mqtt brooker en APP et l’aplli/service Mqtt je n’ai rien de remonté et toujours qu’une partie des données du WES comme modèle entité remonté par le discovery!

Nicola, j’ai bien On les pinces , les capteurs , les relais y compris extension….

Bon je verrais pour tout supprimer, nettoyer HA puis réinstaller

A+

moi j’ai le 05 pour le bin et le O6 pour le web

Coté MQTT pour le moment pas vu grand chose, mais regardé rapidement

C’est ce que je voulais dire coté MQTT  dans le dialogue entre les deux .

Le discovery est en simplifiant la description et le nommage des entités communes pour le dialogue (fourni et envoyé par le client, comme cela ca évite de les rentrer a la mano coté Broker et normalement No Error)  .

comme dans beaucoup de processus de dialogue tout ce qui est spécial ce n’est pas trop aimé

J’imagine que vous avez pris le name WES et comme nous on aime bien des nommages parlant et bien ca fou le bordel.

ca va etre un peu « chiant » de filtrer/parser pour modifier quid quoi pour l’espace quoi pour le éèêë…..

le plus simple serait peut etre de les supprimer tout betement!!!!

belle moulinette en vue pour faire des ID

• Cette réponse a été modifiée le il y a 2 mois et 4 semaines par plruffin.
• Cette réponse a été modifiée le il y a 2 mois et 4 semaines par plruffin.

Nicolas, espaces caractères spéciaux j’imagine que cela pose aussi souci!