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.