plruffin

Pour moi tempo est Ok car franchement le délestage il est hyper simple on coupe tous les gros consommateurs UNIQUEMENT en journée rouge le reste c’est ON pour tous bien sur en fonction de régles de délestage qui elles sont en fonction de l’intensité et de la puissance consommée instantanée pour ne pas s’approcher de trop près de la souscription et du OFF disjoncteur . Comme cela je charge même mes voitures électriques avec bornes 11kw … Coté coût oui on trouve de temps a autres des offres libres qui passe en dessous mais Franchement avec tempo tu est 300j a moins de 0.17cts , 43 jours a moins de 0.20 et 22 jours nuit uniquement a 0.17 et sur du constant sur  connu et maitrisé . En conclusion uniquement delestage sur 22 jours le jour c’est pas une affaire si tu as mode chauffage secondaire

Bon pour moi cette année fut une tempo exceptionnelle car Enedis avait perdu la synchro avec mon Linky et ils en ont « chier » donc 3/4 des jours rouges en bleu!

Bonjour,

Ds5 malheureusement non simplement.

C’est vrai que la charge MQTT du Wes grimpe allègrement (j’ai espionné avec Mqtt explorer). Cela est intrinsèque aux données du Wes que nous surveillons et transmettons en MQTT, par nature elles sont loin d’être des constantes (ex simplement l’index de conso….)

En MQTT, le protocole lui-même ne possède pas de paramètre pour définir la fréquence d’envoi des messages. MQTT est un protocole de transport de messages de type Pub/Sub (Publication/Abonnement) agnostique au contenu et au rythme des données.La fréquence de publication dépend entièrement de la configuration de votre code client (le script ou l’appareil qui envoie les données) ou du matériel (les capteurs).

Dans notre cas je ne trouve pas de parametre dans le WES qui déterminerait la periode de mise a jour et d’envoi des données ni le comment (sur spolling tout les X times ticket ou sur changement…) .
Il est  fort probable que dans le code du firmware Nicolas a mis quelques chose de la sorte il faudrait alors qu’eil le rende accessible.

Pascal

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

Bonjour Nicolas,

Dispo pour tester .

Cordialement

Pascal

Super Top , merci Nicolas.

Je vais attendre et je ne réactive pas RestFull (c’est la seule et dernière information qui me manque), cela n’est pas urgent en soit Predict est intéressant dans la période d’activation du Rouge, pour le blanc et bleu on s’en fou, donc pas avant Octobre.

Sinon MQTT c’est Ok après que j’ai tout viré, nettoyé des deux cotes puis refait une instal . Pas compris pourquoi surtout que refait l’instal idem ! (les mysteres de l’ouest)…

Bonjour,

Bizarre pour les n° de lignes, perso j’ai la numerotation a droite, mais je suis encore en beta02 donc peut etre sur la beta03 !

Une remarque 70 lignes ca risque pour ceux qui ont de la programmation avancée et sérieuse d’etre juste surtout si ils couplent le WES avec d’autres systemes comme du photvoltaique ou de la domotique (Ex HA) …Par exemple perso je suis déja a 56 lignes et de très loin au maxi de mon couplage avec HA (sens HA vers WES ) et j’ai prévu du photo …

A+

Pascal

• Cette réponse a été modifiée le il y a 4 mois et 3 semaines par 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