-
Compteur de contenus
350 -
Inscription
-
Dernière visite
-
Jours gagnés
19
Tout ce qui a été posté par Barelle
-
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.
-
-
tempo QuickApp - Suivi Abonnement TEMPO (EDF)
Barelle a répondu à un(e) sujet de mprinfo dans Quick App Developpeur
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é. -
tempo QuickApp - Suivi Abonnement TEMPO (EDF)
Barelle a répondu à un(e) sujet de mprinfo dans Quick App Developpeur
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. -
tempo QuickApp - Suivi Abonnement TEMPO (EDF)
Barelle a répondu à un(e) sujet de mprinfo dans Quick App Developpeur
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.
-
Désolé , mais c'est inexact : {"name":"Fibaro"} est un json valide qui ne commence pas par [ et ne se termine pas par ], par contre les accolades encadrantes sont obligatoires... Mais on peut très bien avoir un json avec un format tel que : [ { "name": "Le premier" }, { "name": "Le second" } ] Pour approfondir : https://www.w3schools.com/js/js_json_intro.asp
-
QA VMC DF Duolix -> Pilotage Multi-vitesses (humidité et CO2)
Barelle a répondu à un(e) sujet de TitiXsi dans Chauffage et Energie
Dans les champs avec l'indication "Choisir", il faut choisir la condition ou l'action... -
topic unique GCE Electronics EcoDevice RT2 - Gestionnaire d'énergie
Barelle a répondu à un(e) sujet de Lazer dans GCE Electronics
Si on lit 573 m3 (et pas m² ) pour 80 litres cela ferait plutôt une erreur de 0,014 %... -
"VariableMeteoConso1" n'est pas une variable définie, il faudrait plutôt VariableMeteo1. fibaro.getGlobalVariable ( " VariableMeteoConso1 " ) il ne faudrait pas d'espace autour du nom de la variable
-
Et en testant si ce n'est pas une fonction : if jsonResponse["body"][1]["dataset"][1].key == today and type(jsonResponse["body"][1]["dataset"][1].value) ~= "function" then ou encore en s'inspirant de cette solution : https://forum.fibaro.com/topic/57408-nil-null/
-
AEON TEC RGBW BULB et commandes en LUA sur HC3
Barelle a répondu à un(e) sujet de GINOUX DEFERMON dans Aeon Labs / Aeotec
La fonction attend des valeurs et non des strings... hub.call(306, "setColor", 255, 255, 0, 55) -
Récupération valeurs XTHL
Barelle a répondu à un(e) sujet de Samuel Q dans Périphériques et matériels autres
data["THL1-TEMP"] -
La librairie javascript est chargée par le script PHP, donc le NAS doit avoir accès à internet. Une cause possible d'une défaillance du script : un nom de device avec une apostrophe.
-
Are the QA variables well populated ? A trial should be done with the administrator’s user ID and password for the HC2userPass variable.
-
Coupure ballon d'eau chaude par Linky
Barelle a répondu à un(e) sujet de Nico dans Chauffage et Energie
Afin de s'affranchir des effets d'annonces, il me parait plus prudent de se faire sa propre idée en analysant soi-même des données nettement plus fiables disponibles sur le site https://www.rte-france.com/eco2mix -
Coupure ballon d'eau chaude par Linky
Barelle a répondu à un(e) sujet de Nico dans Chauffage et Energie
Pour en savoir plus sur le compteur Linky, je vous recommande cet article sérieux : https://www.canardpc.com/hardware/dossier-hardware/compteurs-linky/ -
Il devrait suffire de changer le type des childs dans la table childsConfig en "com.fibaro.energyMeter", puis de supprimer le child et de relancer le QA qui devrait le recréer avec le bon type. De mémoire, quand ce QA a été écrit, cela ne fournissait pas des résultats satisfaisants. Désolé, n'utilisant plus ce QA, je ne peux tester cette possibilité.
-
Si vraiment la limite est atteinte, c'est une solution. Il sera toutefois nécessaire de créer une seconde variable globale si l'on ne souhaite pas perdre les valeurs historiques.
-
Et en essayant de cette façon : function QuickApp:command(address) local cmdon='<SupplementLight><enabled>true</enabled><brightnessRegulateMode>manual</brightnessRegulateMode><mode>schedule</mode><Schedule><TimeRange><beginTime>00:00:10</beginTime><endTime>23:59:55</endTime></TimeRange></Schedule><brightness>80</brightness><filteringTime>5</filteringTime><sensitivity>4</sensitivity><maxBrightness>80</maxBrightness></SupplementLight>' self.http = net.HTTPClient({timeout=3000}) print(address) self.http:request(address..'/ISAPI/System/externalDevice/supplementLight', { options={ headers = { Authorization = self.credentials, }, checkCertificate = false, method = 'PUT', data = ('<?xml version="1.0" encoding="UTF-8"?>'..cmdon) }, success = function(response) self:debug("response status:", response.status) --self:debug("headers:", response.headers["Content-Type"]) end, error = function(error) -- self:debug('error: ' .. error) end }) end
- 1 631 réponses
-
- topic unique
- surveillance
-
(et 2 en plus)
Étiqueté avec :