Barelle

Hello, Ce quickapp correspond à une adaptation du VD UPS pour la HC2 : Il met à jour une variable globale (appelée UpsStatus par défaut) avec les valeurs "power-line" ou "battery" selon que l’onduleur est sur secteur ou sur batterie. Cette variable globale permet le lancement d’une scène (à écrire) pour prendre les mesures appropriées. Installation du QA : Importer le fichier .fqa ; Renseigner l’adresse IP du NAS connecté à l’onduleur : variable UPSip ; Si nécessaire renseigner le numéro de port du serveur UPS (par défaut 3493) ; Éventuellement changer le nom de la variable globale contenu dans la variable globalVarName (surtout indispensable si plusieurs onduleurs) ; Les username et password présents dans le code du bouton sont les valeurs par défaut pour DSM. Ne pas oublier d’activer le serveur réseau UPS sous DSM : "Panneau de configuration", "Matériel et alimentation", onglet "UPS", cocher "Activer la prise en "charge UPS" et "Activer le serveur réseau UPS"), puis ajouter l’adresse IP de la HC3 dans la liste des "Périphériques DiskStation autorisés". Configuration utilisée pour les tests : HC3 version 5.063.30 ; Onduleur : Eaton Ellipse PRO 1200 ; NAS : Synology DS1010+, DSM 5.2-5967 Update 8 ; NAS Synology DS1621+, DSM 6.2.4-25554. Le fichier .zip ci-après comprend le fichiers .fqa et les icônes que j'utilise. Nouvelle version prenant en compte la correction du problème suivant : QA UPS-0.28.zip

J'essaierai plutôt : api.get(/settings/info)[Ma_Variable]

Pas tout à fait 2021, plantage de ma HC2 le 31/12 à 19h20. Une anticipation du couvre-feu ?

Merci, correction effectuée.

"/settings/network" fonctionne bien..

Lua - Size of table returning different: https://stackoverflow.com/questions/54336703/lua-size-of-table-returning-different Je suppose qu'avec une condition comme : if element and element ~= "" then ... Le fonctionnement paraîtrait (je n'ai pas essayé) plus normal…

Une nouvelle version (0.9) intégrant notamment les index a été mise en ligne dans le premier post.

Afficher, dans un seul child les index HC et HP me semble difficile, surtout que dans le cas d'un abonnement Tempo, il faudrait y afficher six index... Par contre, il est possible de prévoir : D'afficher les index directement dans le QA, Eou de prévoir un child par index, avec la possibilité de choisir lesquels créer. Une préférence ?

Quick App HC2 Devices Contexte Vous avez une HC2 (ou HCL) qui ronronne paisiblement et vous venez d’acquérir une HC3. Vous hésitez sur la stratégie de migration : Le big-bang par Fibaro : tous les dispositifs z-wave seront connectés à la HC3 et vous aurez perdu les scènes et les VD ; Commencer par convertir les VD en QA (en fait, il s’agit pour bien faire les choses d’un redesign complet), puis migrer les dispositifs (devices) z-wave soit par exclusion puis inclusion sur la HC3, soit par le big-bang Fibaro, mais en ayant déjà préparé les nouveaux QA et scènes. Ce QA s’adresse donc à ceux qui ont fait ce second choix. Mais les autres aussi peuvent l’essayer… Note : n’en possédant pas, je n’ai pas testé ce QA avec une HCL, mais, en toute logique, cela devrait fonctionner. Fonction Ce QA permet de voir sur la HC3, un ensemble de devices (dispositifs) physiques de la HC2. En effet, développer scènes et QA sur une HC3 sans device et parfois un peu gênant. Paramétrage lors de l’installation Il est nécessaire de créer pour le QA les variables suivantes : HC2IP : l’adresse IP de la HC2. HC2userPass : <codeutilisateur>:<mot de passe> de la HC2, cet utilisateur devra avoir les droits de modifications sur les devices à voir sur la HC2. Note : après une connexion réussie à la HC2, le QA effacera la variable HC2UserPass et créera la variable HC2Authorization (soit HC2userPass en base 64). Optionnellement : La variable refreshPeriod permet de modifier la période (en secondes) d’interrogation de la HC2 (par défaut 60 secondes), ce qui parait suffisant pour un emploi en développement, une période trop courte pourra se traduire par une consommation CPU plus conséquente. Une variable iconId permet d’affecter une icône au QA HC2Devices. Comme vous le savez bien, il y a sur la HC2 un tas de devices que nous considérons sans intérêt (device master, second relais inutilisé, etc.) le QA ne prend pas en compte que les devices physiques (donc pas les VD) qui en plus : Sont enabled. Sont visibles. Ne sont pas des masters. Qui sont d’un type pris en charge (cf. la table HC2Types pour en avoir la liste), seuls certains ont été testés. Qui sont affectés à une pièce. Qui n’ont pas été explicitement exclus par ajout de leur id dans la table HC2IdExcluded en tête de programme. Interface utilisateur Le device de la HC2 en cours. Affiche le device de la HC2 précédant. Ajoute le device de la HC2 en cours sur la HC3 (child). Supprime le device de la HC2 en cours sur la HC3 (child). Affiche le device de la HC2 suivant. Affiche dans la fenêtre de log le device en cours. Affiche dans la fenêtre de log les devices présentes sur la HC3. Affiche dans la fenêtre de log les devices non présentes dur la HC3. Affiche dans la fenêtre de log tous les devices de la HC2 connus du QA. Ajout/suppression sur la HC3 (d’un child reflet d’un device de la HC2) On le sélectionne par son nom et son id à l’aide des boutons (2) et (5), puis par le bouton (3). Pour la suppression, on utilisera le bouton (4). Lors de l’ajout le child sera affecté à une pièce du même nom que celui de la HC2, si elle existe dans la HC3, ou dans une pièce du même nom qui sera créée dans la section de nom "Fibaro HC2". Synchronisations HC2/HC3 et HC3/HC2 Les changements de valeur des principales propriétés (properties) des devices de la HC2 sont reportés sur les childs de la HC3), lors de chaque rafraîchissement.. Les ordres donnés à partir des devices de la HC3 sont transmis à la HC2 (pour les types implémentés). Le retour d'état sera affiché lors du prochain rafraîchissement (60 secondes par défaut). Limites Tous les types de devices n’ont pas été testés. Il n’est pas possible de récupérer par le QA les icônes de la HC2. L’utilisateur n’a pas accès à la modification des variables crées par le QA (en version 5.050.13), mais il peut les supprimer ou les modifier par l’API du swagger. Le manque de robustesse de la HC3 qui permet ainsi de tester de manière approfondie le mode de récupération… Des redémarrages aléatoires du QA, sans cause identifiée, heureusement sans impact sur son fonctionnement. La sagesse de Fibaro qui a su conserver une réserve d'améliorations considérable pour les possibilités de personnalisation de l'interface. Les bugs que vous ne manquerez pas de découvrir. Téléchargement HC2_Devices.fqa

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, empêchant ainsi le respect de la graphie du système international (pour kWh notamment). 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. Tt 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.1597 - CoutKWHPHC : 0.1798,0.1344 (dans l'ordre HP,HC) - CoutKWEJP : 0.1518,0.3114 (dans l'ordre HN,HPM) - CoutKWTEMPO : 0.1548,0.1246,0.1757,0.1397,0.6389,0.1491 (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 décembre 2020 pour une puissance de 9 kVA), si non défini, les coûts ne tiendront pas compte du prix de l’abonnement : - CoutAnnuelBASE : 152.64 - CoutAnnuelHPHC : 172.08 - CoutAnnuelEJP : 152.16 - CoutAnnuelTempo : 169.56 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) displaySimul : pour simuler les coûts pour un abonnement BASE, il faudra impérativement renseigner les variables CoutAnnuelBASE et CoutKWBASE Les unités, pour chaque child, on peut modifier la valeur des unités de l'index et des valeurs affichées. Ainsi on pourra définir les variables : - C1IndexUnit et C2IndexUnit pour préciser l'unité de l'index du compteur (on peut également définir T1IndexUnit et T2IndexUnit, même si cela a un sens qui m'échappe) ; - Suivant les valeurs à afficher, les multiples d'unités pourront être affichées (k, m³, kVA, kW, k€, kWh...), dans ce cas la valeur affichée est arrondie à la première décimale. La simulation d’un tarif "BASE" Cette simulation n’est disponible que pour les abonnements HPHC, EJP et TEMPO. Les variables CoutAnnuelBASE et CoutKWBASE devront respectivement préciser le coût de l’abonnement "BASE" et le tarif du kWh. Les coûts simulés pourront être affichés sous la forme d'enfants ("children"). Les valeurs possibles pour la liste de la variable "childs" sont : Les "Enfants" Comme il faut bien découvrir, je me suis lâché… Même si la gestion des quatre types d’abonnement est à l’origine de l’inflation. Ne possédant qu’un abonnement HPHC, je n’ai pas pu tester les autres cas, 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, T1Index = index total (somme des index si plusieurs périodes tarifaires) Coûts par période : * T1JourEuro = coût pour le jour en cours, * T1MoisEuro = coût pour le mois en cours, * T1AnneeEuro = coût pour l’année en cours, * T1SimuBaseJour = coût simulé (tarif base) pour le jour en cours, * T1SimuBaseMois = coût simulé (tarif base) pour le mois en cours, * T1SimuBaseAnnee = coût simulé (tarif base) pour l’année en cours ; Consommation abonnement BASE par période * BASEHeure = Conso. BASE heure, * BASEJour = Conso. BASE jour, * BASEMois = Conso. BASE mois, * BASEAnnee = Conso. BASE année, * BASEIndex = index BASE ; 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, * HPIndex = index HP, * HCHeure = Conso. HP heure, * HCJour = Conso. HC jour, * HCMois = Conso. HC mois, * HCAnnee = Conso. HC année, * HCIndex = index HC ; 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, * EJPHNIndex = index EJPHN, * EJPHPMHeure = Conso. EJPHPM Heure, * EJPHPMJour = Conso. EJPHPM jour, * EJPHPMMois = Conso. EJPHPM mois, * EJPHPMAnnee = Conso. EJPHPM année, * EJPHPMIndex = index EJPHPM ; 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, * HPJBIndex = index HPJB, * HCJBHeure = Coût HCJB heure, * HCJBJour = Coût HCJB jour, * HCJBMois = Coût HCJB mois, * HCJBAnnee = Coût HCJB année, * HCJBIndex = index HPCB, * HPJWheure = Coût HPJW heure, * HPJWJour = Coût HPJW jour, * HPJWMois = Coût HPJW mois, * HPJWAnnee = Coût HPJW année, * HPJWIndex = index HPJW, * HCJWHeure = Coût HCJW heure, * HCJWJour = Coût HCJW jour, * HCJWMois = Coût HCJW mois, * HCJWAnnee = Coût HCJW année, * HCJWIndex = index HCJW, * HPJRHeure = Coût HPJR heure, * HPJRJour = Coût HPJR jour, * HPJRMois = Coût HPJR mois, * HPJRAnnee = Coût HPJR année, * HPJRIndex = index HPJR, * HCJRHeure = Coût HCJR heure, * HCJRJour = Coût HCJR jour, * HCJRMois = Coût HCJR mois, * HCJRAnnee = Coût HCJR année, * HCJRIndex = index HCJR; 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, T2Index = index total du compteur. 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, Installation/mise à jour Pour une première installation : Importer le fichier ".fqa" ci-dessous, puis : Renseigner les variables ipEcodevices, globalVarName, toBeDisplayed, displayChilds et childs. Remarque : une variable créée par le QA n’est pas modifiable par l’interface. Il suffit de la supprimer et de la recréer. Pour une mise à jour : Il est nécessaire de vérifier que l’interface du QA possède des labels jusqu’à "Lbl_25", sinon en rajouter sans trous dans la numérotation ; Puis il suffit de copier le contenu du fichier lua dans l’onglet main du QA. Version 0.800 (ajout de la variable portEcodevices, correction de divers bugs...). Version 0.900 : Eco-Devices-0.90.fqa Ajout des enfants pour les coûts globaux : T1JourEuro, T1MoisEuro, T1AnneeEuro ; Ajout de la simulation d'un abonnement "BASE" et possiblement des enfants T1SimuBaseJour, T1SimuBaseMois, T1SimuBaseAnnee ; Ajout de l’affichage des index et des enfants : BASEIndex, HPIndex, HCIndex, EJPHNIndex, EJPHPMIndex, HPJBIndex, HCJBIndex, HPJWIndex, HCJWIndex, HPJRIndex, HCJRIndex, T2Index ; Other minor bug fixes. Version 0.92 : Eco-Devices-0.92.fqa Amélioration de la robustesse du code (gestion de quelques cas tordus) ; Corrections cosmétiques. Version 0.95 : Eco-Devices-0.95.fqa Traitement du cas sans téléinfo ; Ajout des variables pour les unités pour les childs ; Amélioration de la robustesse du code (gestion de quelques cas tordus). Version 0.96 : Eco-Devices-0.96.fqa Gestion du cas du changement d'abonnement ; Correction du cas où une variable du QA se termine par une espace ; Multiples dans unités dans les valeurs affichées ; Corrections des anomalies. Eco-Device-0.96.fqa Ecodevices-0.96.lua.zip

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...

os.time() retourne un temps en secondes écoulé depuis le 1er janvier 1970 à minuit. Je te suggère d'essayer : fibaro:setGlobal('time_last_rain', os.time{year=2020, month=6, day=17, hour=0}) cf.la doc Lua pour mieux comprendre...

Dans le code on trouve : WindStrength = { type = "com.fibaro.windSensor", unit = "m/s", conversion = function(value) return value/3.6 end }, Il suffit de remplacer 3.6 par 1 (ou de supprimer la fonction conversion...) et de changer "m/s" en "km/h.