Barelle

En auto-hébergement, la solution NTFY me paraît présenter de nombreux atouts. Pour l'utiliser depuis au moins deux ans cela fonctionne bien dans une VM Debian sur mon NAS Synology.

line 49: attempt to index field 'fields' (a nil value) Cela devrait provenir de la ligne : if jsonTable[j].fields.annee_scolaire ~= nil then et signifie que la table jsonTable ne contient pas de clé fields. Il serait toujours possible d'éliminer ce cas d'erreur, en écrivant : if (jsonTable[j].fields ~= nil) and (jsonTable[j].fields.annee_scolaire ~= nil) then cela supprimera l'erreur, mais ne corrigera pas le problème qui vient probablement de la conversion du fichier XML en table LUA. N'ayant plus de HC2 en état de fonctionnement, je ne pourrais pas aller plus loin dans la recherche de la cause.

Comme déja dit, il s'agit d'un json contenant un tableau à plusieurs dimensions, l'utilisation d'un site pour le reformater (ici https://jsonlint.com/) permet de le mettre en évidence : [ { "nombreJours": 22, "libelle": "TEMPO ROUGE 2024 2025", "premierJourExclu": null, "nombreJoursTires": 6, "etat": "OUVERTE", "dernierJour": "2025-03-31", "dernierJourExclu": null, "typeJourEff": "TEMPO_ROUGE", "premierJour": "2024-11-01" }, { "nombreJours": 43, "libelle": "TEMPO BLANC 2024 2025", "premierJourExclu": null, "nombreJoursTires": 12, "etat": "OUVERTE", "dernierJour": "2025-08-31", "dernierJourExclu": null, "typeJourEff": "TEMPO_BLANC", "premierJour": "2024-09-01" }, { "nombreJours": 300, "libelle": "TEMPO BLEU 2024 2025", "premierJourExclu": null, "nombreJoursTires": 96, "etat": "OUVERTE", "dernierJour": "2025-08-31", "dernierJourExclu": null, "typeJourEff": "TEMPO_BLEU", "premierJour": "2024-09-01" } ] On constate que chaque ligne du tableau (qui correspond à la seconde dimension) ne possède pas d'index et qu'elle est identifiée par le contenu de la variable "typeJourEff". L'on va donc parcourir le tableau et pour chaque "typeJourEff" retenir la valeur recherchée à savoir le contenu de la variable "nombreJoursTires". Et l'on obtient ; -- Pour le test on récupère le json () local jsonStr = '[{"nombreJours":22,"libelle":"TEMPO ROUGE 2024 2025","premierJourExclu":null,"nombreJoursTires":6,"etat":"OUVERTE","dernierJour":"2025-03-31","dernierJourExclu":null,"typeJourEff":"TEMPO_ROUGE","premierJour":"2024-11-01"},{"nombreJours":43,"libelle":"TEMPO BLANC 2024 2025","premierJourExclu":null,"nombreJoursTires":12,"etat":"OUVERTE","dernierJour":"2025-08-31","dernierJourExclu":null,"typeJourEff":"TEMPO_BLANC","premierJour":"2024-09-01"},{"nombreJours":300,"libelle":"TEMPO BLEU 2024 2025","premierJourExclu":null,"nombreJoursTires":96,"etat":"OUVERTE","dernierJour":"2025-08-31","dernierJourExclu":null,"typeJourEff":"TEMPO_BLEU","premierJour":"2024-09-01"}]'; local jsonTable = json.decode(jsonStr); -- On transforme la chaîne de caractères en tableau local bleustires, blancstires, rougestires = 0, 0, 0; -- Déclaration et initialisation des variables for _, jsonRow in ipairs(jsonTable) do -- On parcourt la première dimension du tableau, la seconde dimension sera le tableau jsonRow if (jsonRow.typeJourEff ~= nil) and (jsonRow.nombreJoursTires ~= nil) then -- On s'assure que les index que l'on va utiliser sont bien présents if jsonRow.typeJourEff == "TEMPO_BLEU" then bleustires = jsonRow.nombreJoursTires; elseif jsonRow.typeJourEff == "TEMPO_BLANC" then blancstires = jsonRow.nombreJoursTires; elseif jsonRow.typeJourEff == "TEMPO_ROUGE" then rougestires = jsonRow.nombreJoursTires; end else print '"typeJourEff" ou "nombreJoursTires" pas trouvé'; end end print (bleustires, blancstires, rougestires); La meilleure façon de progresser et de comprendre le code et la logique de programmes existants.

Il s'agit d'un tableau à deux dimensions, il n'y a qu'une variable nombreJoursTires par typeJourEff.

Je te propose d'essayer avec : --[[ %% autostart %% properties %% globals Jour_Nuit --]]

Absolument, un bébête contacteur comme ceux utilisés pour les chauffe-eaux pour le passage HP/HC, et pour un prix comparable, devrait être plus résistant et plus sûr.

Théoriquement oui, mais n'utilisant plus l'Ecodevice v1 je ne peux le tester et donc le garantir... Fais le test, c'est sans risque. De rien.

RTE semble avoir un problème et n'a pas encore publié la couleur de demain : https://www.services-rte.com/fr/visualisez-les-donnees-publiees-par-rte/calendrier-des-offres-de-fourniture-de-type-tempo.html

La syntaxe est plutôt : http://<user>:<pwd>@<ip box>:80/api/callAction?deviceID=<deviceID>&name=<method>

@Lazer Juste une remarque sur la dernière courbe, d'autres sources fournissent des résultats bien différents : Ou encore avec on peut lire : Source National Geographic Tout en affirmant que les concentrations actuelles sont d'origine anthropiques. Ceci dit sans vouloir troller.

Peut-être en changeant le câble réseau…

Je sui désolé d'être d'accord avec @Lazer, mais après un rapide coup d'œil au code du QA, il y a bien un bug : La variable self.UrlTempoDate n'est initialisée que dans la fonction QuickApp:onInit, donc, l'interrogation n'est réalisée que pour la date de démarrage du QA. Correction suggérée : Copier les lignes -- URL couleur Tempo self.UrlTempoDay = "https://particulier.edf.fr/services/rest/referentiel/searchTempoStore?dateRelevant=" self.UrlTempoDate = self.UrlTempoDay..os.date("%Y-%m-%d") -- URL Jours restants self.URLTempoDayRest = "https://particulier.edf.fr/services/rest/referentiel/getNbTempoDays?TypeAlerte=TEMPO" self.HeureURL = json.decode("[0,6,"..self:getVariable("Refresh")..",22]") de la fonction QuickApp:onInit au début de la fonction QuickApp:Mainloop.

Le problème : Les champs "Input voltage", "Fréquence", "Power" et "Real power" ne sont pas renseignés. La cause : Les valeurs "VAR UPS input.voltage", "VAR UPS input.frequency", "VAR UPS ups.power", "VAR UPS ups.realpower" ne sont pas retournées par l'Eaton Ellipse ECO 1200 au serveur UPS du Synology et donc au QA. Détours possibles : Pour "Input voltage" et "Real power" on ne peut pas faire grand chose à part supprimer les labels de l'interface et leurs mises à jour dans la fonction "updateLabels". Pour "Fréquence", il serait possible dans la fonction "updateLabels" de remplacer "input.frequency" par "output.frequency.nominal". Pour "Power", il serait possible dans la fonction "updateLabels" de remplacer "ups.power" par "outlet.power", de modifier le titre du label et les valeurs du child "power" (dernières lignes de la fonction "processData"). Toutefois, je ne sais pas très bien à quoi correspond la valeur "outlet.power" (25 VA pour un NAS 4 baies me parait faible, sauf s'il n'ya qu'un disque...).

Bonsoir, Il faudrait vérifier si les valeurs manquantes figurent bien dans le json retourné par le serveur UPS du Synology.

Le format de la variable globale est propre au QA, un changement de version ne peut être la cause. Peut-être essayer de désactiver le QA, de supprimer la variable globale, puis de réactiver le QA.

Oui...

Pour le délai, ce n'est pas tant la longueur du script ou les ressources consommées sur la HC3 que si nous sommes des centaines de milliers à faire des requêtes inutiles, le service deviendra soit dégradé, soit inaccessible ou tout simplement supprimé.

C'est un peu plus compliqué, la journée Tempo commence à 22h00, et la couleur du lendemain peut être connue à partir de 11h00, donc : - à 22h00 la couleur du lendemain devient inconnue, - à partir de 11h00, tant que la couleur du lendemain est inconnue, on peut interroger le site EdF, - une fois la couleur connue, il faut attendre 22h00. PS : 1) Pour être prudent, il vaut mieux utiliser la trame de téléinformation du compteur pour connaître le tarif en cours. 2) Il me reste à identifier quand est décrémenté le compteur de jours restants.

Pour le QA, une interrogation toutes les 60 secondes (soit 1440 fois par jour) pour récupérer des données mises à jour une fois par 24 heures, cela n'est-il pas un peu beaucoup ?

EDF propose une API avec la couleur du jour et celle du lendemain, la mise à jour a lieu entre 11h00 et midi : https://particulier.edf.fr/services/rest/referentiel/searchTempoStore?dateRelevant=2023-03-14 qui retourne : {"couleurJourJ":"TEMPO_BLEU","couleurJourJ1":"TEMPO_BLEU"} Une autre API permet de connaître le nombre de jours restants : https://particulier.edf.fr/services/rest/referentiel/getNbTempoDays?TypeAlerte=TEMPO qui a pour réponse : {"PARAM_NB_J_BLANC":11,"PARAM_NB_J_ROUGE":0,"PARAM_NB_J_BLEU":158}

Même si je ne fais pas directement le lien avec le problème rencontré, et étant donné que tu sembles n'utiliser ton Eco-device que pour récupérer les données de la téléinformation de ton compteur, pourrais-tu changer la variable "toBeDisplayed" (actuellement "T1,C1,C2") pour lui donner la seule valeur "T1". De même, il devrait être possible de simplifier la variable "childs" avec la valeur "T1WhActuel,T1kWhJour,T1JourEuro,T1MoisEuro,T1AnneeEuro,T1SimuBaseJour,T1SimuBaseAnnee,T1SimuBaseMois". Cela supprimera les childs relatifs à C1 et aux index heures pleines et heures creuses.

Il faut que la variables maxLabels correspondent au nombre de labels du QA. Peux-tu essayer d'importer à nouveau le QA (supprimer l'actuel n'est pas nécessaire).

Pour ajouter une temporisation "sauvage" de 3 secondes, il convient d'ajouter la ligne : fibaro.sleep(3 * 1000); Au début de la fonction QuickApp:onInit. Une autre piste, si tu as juste fait la mise à jour du code du QA sans le réimporter, vérifie que le nombre de champs "labelxx" est bien cohérent avec la valeur de la variable maxLabels

Cette erreur a-t-elle lieu : Seulement après un redémarrage de la box ? La solution proposée par @mprinfo devrait apporter une correction. Après un redémarrage du QA ? Ou Systématiquement ? Peut-être qu'avec la trace depuis le démarrage du QA l'on pourrait essayer d'en comprendre la cause.

Avec self.email = { 5 } (sans guillemets), cela devrait fonctionner.