Barelle

La variable globale EcoDevices contient les dernières valeurs calculées, et la periode en cours, illustration : { "teleinfo1": { "abonnement": "HPHC", "hourTotalIndex": 43177383, "HCIndex": 16806364, "monthTotalIndex": 42984543, "HChourTotalIndex": 16806364, "HPIndex": 26371262, "yearTotalIndex": 42984543, "puissanceApparente": 1020, "lastTotalIndex": 43177626, "HCdayTotalIndex": 16795809, "HCmonthTotalIndex": 16736947, "HPhourTotalIndex": 26371019, "dayTotalIndex": 43163591, "HPdayTotalIndex": 26367782, "HPmonthTotalIndex": 26247596, "periode": "HP..", "HCyearTotalIndex": 16736947, "consoActuelleWh": 13, "HPyearTotalIndex": 26247596 }, "firstUpdate": 1596054883, "lastUpdate": 1600593556, "compteur1": { "consoActuelle": 0, "monthIndex": 631288536, "lastIndex": 631307338, "hourIndex": 631307338, "yearIndex": 631288536, "dayIndex": 631301392 }, "compteur2": { "consoActuelle": 0, "monthIndex": 669708259, "lastIndex": 669740960, "hourIndex": 669740960, "yearIndex": 669708259, "dayIndex": 669735562 }, "teleinfo2": { "abonnement": "BASE", "hourTotalIndex": 0, "monthTotalIndex": 0, "dayTotalIndex": 0, "periode": 0, "yearTotalIndex": 0, "BASEIndex": 0, "puissanceApparente": 0, "consoActuelleWh": 0, "lastTotalIndex": 0 } } Pour l'icône des QA, c'est compliqué, car toujours non prévu par Fibaro. Je l'ai ajoutée pour un capteur de température et ai relevé son numéro.

A ma connaissance il n'existe pas, et il n'existera probablement jamais d'outils permettant la migration d'un VD vers un QA, l'architecture logicielle de l'un étant fondamentalement différente de celle de l'autre. A titre d'illustration, dans le VD que tu montres, il est quasiment certain que le code de chacun des boutons 1, 2, 3, 4, 5 est identique hormis quelques caractères. Lors d'une réécriture des fonctions d'un VD sous forme de QA, tout ce qui est interface utilisateur, mais aussi requêtes vers d'autres systèmes change ; en revanche le traitement des données (logique purement applicative - ou "métier") peut lui être repris.

Toi seul à le pouvoir d'apporter une réponse

Je viens de faire le test, tout s'est bien passé...

As-tu fais l'essai en changeant le 1.2 en 1.1 ? Juste pour voir (ou savoir)...

Si tel est le cas, la créativité du développeur stagiaire de Fibaro mérite toute mon admiration

Début de réalisation en 5.040.37, actuelle 5.040.37, la dernière... Je vois mal l'intérêt de cette info

Je viens de diffuser une nouvelle version corrigeant un certain nombre de dysfonctionnement, pourrais-tu refaire un essai ? En cas de nouveau problème, en plus d'une copie des log, merci de joindre une copie d'écran des différentes variables du QA utilisées.

HC3-00003400 mai 2020

Il me semble que le contexte est différent : L'EDRT2 possède des relais (comme un IPX), la question du retour d'état se pose. En terme d'implémentation, ton choix me semble pertinent ayant reçu un ordre, l'EDRT2 rend compte de son exécution, sinon, il eut fallu que l'HC3 interroge l'EDRT2 pour s'assurer de sa bonne fin ; Pour les valeurs de consommation, ce qui m’intéresse se sont les index qui, par la différence entre deux valeurs, me permettent de savoir l'énergie (en kWh) qui me sera facturée, en n'oubliant que le nom de la variable d'index change en fonction de l'abonnement, soit 11 index possibles et 6 utiles pour un abonnement Tempo. La puissance apparente (en kVA) ne sert qu'à vérifier que l'on est bien en deçà de la valeur de son abonnement. En tant que particulier, la valeur du cos phi ne m'importe absolument pas, surtout qu'elle varie en fonction des heures de filtration de la piscine. J'avais plutôt prévu d’utiliser le type com.fibaro.energyMeter, mais je n'ai pas réussi à obtenir l'affichage des données (non élucidé à ce jour), ma table childsConfig est conçue pour permettre de choisir le type pour chacun des childs. Quand je maîtriserai ce domaine, des évolutions seront sans doute possibles...

C'est une très bonne question, même s'il vaudrait mieux parler de choix d'architecture logicielle, le protocole d'échange n'étant qu'un moyen (mais qui selon sont type va permettre un choix d'architecture , bref c'est compliqué). L'important est de réaliser un choix sur l'interlocuteur qui sera à l'origine de la communication, dans notre cas, soit la HC3, soit l'Ecodevice. Je n'ai pas fait le choix d'utiliser le M2M de l'Ecodevice car : Les informations les plus utiles pour mon usage sont portées par la trame de la télérelève et, pour les obtenir, il convient de les énumérer explicitement dans l'Ecodevice ce qui se traduirait par un paramétrage différent pour chacun des types d'abonnement ; Tel qu'implémenté par GCE, le M2M ne me satisfait pas, j'eu préféré que l'information soit envoyée lors d'un changement d'état (nouvelle valeur d'un compteur par exemple) même si cela peut se traduire par un afflux important de message. En cela le report de consommation des modules Fibaro est pertinent avec les définitions d'intervalle et de niveaux ; Par souci de simplification, il est plus facile (surtout avec le Lua bridé par Fibaro) de traiter une réponse à une question que l'on a posé, plutôt qu'être disponible dans l'attente d'un message... Par culture colbertiste , une centrale domotique centralise (sic) et dirige ses opérations, il me paraît plus optimisé de récupérer l'information quand on en a besoin, plutôt que filtrer le "bruit informationnel" ; Ce dernier point est plus général : les objets communicants, doivent-ils envoyer périodiquement leurs données (par exemple à un message broker comme Mosquito) même si elles n'intéressent personne ? Dans une architecture client/serveur, c'est le client qui effectue les requêtes, la HC3 dans notre cas. Avec la vision IoT actuelle ,le broadcast se généralise avec des architectures ressemblant au jet d'une bouteille à la mer (la mer s'appelant Mosquito), ou au fonctionnement des réseaux sociaux : publions ! même si cela n'a aucun intérêt... Je ne crois pas que la question ait été tranchée, pour chaque contexte une réponse peut-être plus adaptée qu'une autre. Enfin, à ma connaissance MQTT n'est pas disponible sur les produits de GCE, donc la question de l'usage d'un Message Broker (ouais je sais ça fait pédant) ne se pose pas dans ce contexte. Toutefois, histoire de s'amuser et de pimenter un peu notre domotique, rien n'interdit de confier à Node-RED la tâche de récupérer les informations de l'Ecodevice et de mettre à jour la HC3 par l'API. Au delà de la satisfaction personnelle de la découverte d'une solution à la mode, cela permettrait de fragiliser la solution par l'ajout de serveurs logiciels et physiques.

Quick App - Ecodevice v1 Gestion de la consommation en kWh, de la puissance en VA Pour les abonnements de type BASE, HPHC, EJP, TEMPO. Permet l’affichage de la puissance apparente, de l’énergie consommée durant la dernière minute, l’heure en cours, la journée en cours, le mois et l’année. Permet également d’afficher les coûts pour la journée, le mois et l’année. Ne possédant qu’un abonnement HPHC, je suis preneur des résultats de tests pour les autres abonnements, afin de vérifier la bonne adéquation entre la théorie et la pratique. Limites : les cumuls de consommation et les coûts ne sont calculés que pour T1, par défaut les unités de C1 sont en m3 ou litres et celles de C2 en kWh ; une éventuelle future version permettra peut-être de les personnaliser. Problèmes rencontrés : L’indigence de la documentation ; Le swagger qui plante régulièrement (get/plugins/getView par exemple) ; Les unités ne sont affichées qu’en lettres capitales et quand un child est agrandi, elles disparaissent ; Curieusement les childs apparaissent dans l’application portable et pas le QA. Configuration pour le fonctionnement Celle-ci est effectuée par la définition de variables (attention au respect des majuscules et minuscules) : ipEcodevices : adresse IP de l'Eco-Devices <========= OBLIGATOIRE portEcodevices : numéro de port de de l'Eco-Devices (80 par défaut) debug : pour tracer plus copieusement le déroulement du programme (true ou false) Préférences Il s'agit de choix concernant les types de données que l'on souhaite afficher : refreshDelay : intervalle de relevé des mesures en secondes (60 recommandé et par défaut) iconId : numéro de l'icône à attribuer au QA et oui, on peut attribuer une icône à un child mais pas au QA globalVarName : nom de la variable globale utilisée pour mémoriser les valeurs d'index afin d’en permettre l’accès à une scène ou un autre QA toBeDisplayed : compteurs à afficher sous forme de liste (par exemple : T1,C1,C2) par le QA CoutKW<abonnement> : sous la forme d'une liste des coûts TTC des kWh comme ci-dessous (cf. https://www.kelwatt.fr/prix/edf) : - CoutKWBASE : 0.1587 - CoutKWHPHC : 0.1781,0.1337 (dans l'ordre HP,HC) - CoutKWEJP : 0.1506,0.3100 (dans l'ordre HN,HPM) - CoutKWTEMPO : 0.1531,0.1242,0.1738,0.1392,0.6371,0.1488 (dans l'ordre HPJB,HCJB,HPJW,HCJW,HPJR,HCJR) CoutAnnuel<abonnement> : le coût annuel TTC de l'abonnement comme ci-dessous (exemple : valeurs de juin 2020 pour une puissance de 9 kVA), si non défini, les coûts ne tiendront pas compte du prix de l’abonnement : - CoutAnnuelBASE : 143.64 - CoutAnnuelHPHC : 163.44 - CoutAnnuelEJP : 141.96 - CoutAnnuelTempo : 160.08 childs : liste de childs à lancer sous forme de liste (par exemple : T1kWhJour,C1,C2) voir chapitre ci-après. displayChilds : si les childs doivent être affichés (true ou false) Les "childs" Comme il faut bien découvrir, je me suis laché… Même si la gestion des quatre types d’abonnement est à l’origine de l’inflation. Il va de soi que je n’ai pas pris le temps de tout tester, merci de vos retours Les valeurs possibles pour la liste de la variable "childs" sont : Compteur T1 : T1VA = T1 puissance, T1WhActuel = Conso. actuelle, T1WhHeure = Conso. heure, T1kWhJour = Conso. jour, T1kWhMois = Conso. mois, T1kWhAnnee = Conso. année, Consommation abonnement BASE par période * BASEHeure = Conso. BASE heure, * BASEJour = Conso. BASE jour, * BASEMois = Conso. BASE mois, * BASEAnnee = Conso. BASE année, Coûts abonnement BASE par période * BASEJourEuro = Coût BASE jour, * BASEMoisEuro = Coût BASE mois, * BASEAnneeEuro = Coût BASE année, Consommation abonnement HPHC par période * HPHeure = Conso. HP heure, * HPJour = Conso. HP jour, * HPMois = Conso. HP mois, * HPAnnee = Conso. HP année, * HPHeure = Conso. HP heure, * HCJour = Conso. HC jour, * HCMois = Conso. HC mois, * HCAnnee = Conso. HC année, Coûts abonnement HPHC par période * HPJourEuro = Coût HP jour, * HPMoisEuro = Coût HP mois, * HPAnneeEuro = Coût HP année, * HCJourEuro = Coût HC jour, * HCMoisEuro = Coût HC mois, * HCAnneeEuro = Coût HC année, Consommation abonnement EJP par période * EJPHNHeure = Conso. EJPHN heure, * EJPHNJour = Conso. EJPHN jour, * EJPHNMois = Conso. EJPHN mois, * EJPHNAnnee = Conso. EJPHN année, * EJPHPMHeure = Conso. EJPHPM Heure, * EJPHPMJour = Conso. EJPHPM jour, * EJPHPMMois = Conso. EJPHPM mois, * EJPHPMAnnee = Conso. EJPHPM année, Coûts abonnement EJP par période : * EJPHNJourEuro = Coût EJPHN jour, * EJPHNMoisEuro = Coût EJPHN mois, * EJPHNAnneeEuro = Coût EJPHN année, * EJPHPMJourEuro = Coût EJPHPM jour, * EJPHPMMoisEuro = Coût EJPHPM mois, * EJPHPMAnneeEuro= Coût EJPHPM année, Consommation abonnement TEMPO par période : * HPJBHeure = Coût HPJB heure, * HPJBJour = Coût HPJB jour, * HPJBMois = Coût HPJB mois, * HPJBAnnee = Coût HPJB année, * HCJBHeure = Coût HCJB heure, * HCJBJour = Coût HCJB jour, * HCJBMois = Coût HCJB mois, * HCJBAnnee = Coût HCJB année, * HPJWheure = Coût HPJW heure, * HPJWJour = Coût HPJW jour, * HPJWMois = Coût HPJW mois, * HPJWAnnee = Coût HPJW année, * HCJWHeure = Coût HCJW heure, * HCJWJour = Coût HCJW jour, * HCJWMois = Coût HCJW mois, * HCJWAnnee = Coût HCJW année, * HPJRHeure = Coût HPJR heure, * HPJRJour = Coût HPJR jour, * HPJRMois = Coût HPJR mois, * HPJRAnnee = Coût HPJR année, * HCJRHeure = Coût HCJR heure, * HCJRJour = Coût HCJR jour, * HCJRMois = Coût HCJR mois, * HCJRAnnee = Coût HCJR année, Coûts abonnement TEMPO par période : * HPJBJourEuro = Coût HPJB jour, * HPJBMoisEuro = Coût HPJB mois, * HPJBAnneeEuro = Coût HPJB année, * HCJBJourEuro = Coût HCJB jour, * HCJBMoisEuro = Coût HCJB mois, * HCJBAnneeEuro = Coût HCJB année, * HPJWJourEuro = Coût HPJW jour, * HPJWMoisEuro = Coût HPJW mois, * HPJWAnneeEuro = Coût HPJW année, * HCJWJourEuro = Coût HCJW jour, * HCJWMoisEuro = Coût HCJW mois, * HCJWAnneeEuro = Coût HCJW année, * HPJRJourEuro = Coût HPJR jour, * HPJRMoisEuro = Coût HPJR mois, * HPJRAnneeEuro = Coût HPJR année, * HCJRJourEuro = Coût HCJR jour, * HCJRMoisEuro = Coût HCJR mois, * HCJRAnneeEuro = Coût HCJR année. Compteur T2 : T2VA = T2 puissance, T2WhActuel = T2 Conso. actuelle, T2WhHeure = T2 Conso. heure, T2kWhJour = T2 Conso. jour, T2kWhMois = T2 Conso. mois, T2kWhAnnee = T2 Conso. année, Compteur C1 : C1Index = C1 Index, C1Actuel = C1 Conso. actuelle, C1Heure = C1 Conso. heure, C1Jour = C1 Conso. jour, C1Mois = C1 Conso. mois, C1Annee = C1 Conso. année, Compteur C2 : C2Index = C2 Index, C2Actuel = C2 Conso. actuelle, C2Heure = C2 Conso. heure, C2Jour = C2 Conso. jour, C2Mois = C2 Conso. mois, C2Annee = C2 Conso. année, Le QA version 0.600 : Version 0.800 (ajout de la variable portEcodevices, correction de divers bugs...) : Eco-Devices-0.800.fqa

Oups, la photo ci-dessus est celle du pluviomètre. En fait, je suspecte plus un problème de condensation car je n'ai pu identifier une quelconque erreur de conception. Mettre du gel électrique pourrait-être effectivement une solution, sous réserve qu'il ne s'écoule pas vers le compartiment des piles.

J'ai eu également ce souci au bout de 4 ans avec l'anémomètre, la plaque était oxydée...