Barelle

Je n'utilise pas les notifications, mais à la lecture du code de la scène, il me semble que les lignes : -- Définition des textes audio today_speach = Jours(tonumber(os.date("%w"))) .." : " .. jsonTable1.data[1].weather.description .. ". " .." Température entre ".. round(jsonTable1.data[1].min_temp,0) .." et ".. round(jsonTable1.data[1].max_temp,0) .." degrès. " .." Vent de ".. math.floor(jsonTable1.data[1].wind_spd*3.600) .." kilomètres par heure, en provenance ".. jsonTable1.data[1].wind_cdir_full ..". " .." Précipitations de ".. round(jsonTable1.data[1].precip,0) .. " milimètres. " tomorrow_speach = Jours(tonumber(os.date("%w"))+1) .." : " .. jsonTable1.data[2].weather.description .. ". " .." Température entre ".. round(jsonTable1.data[2].min_temp,0) .." et ".. round(jsonTable1.data[2].max_temp,0) .." degrès. " .." Vent de ".. math.floor(jsonTable1.data[2].wind_spd*3.600) .." kilomètres par heure, en provenance ".. jsonTable1.data[2].wind_cdir_full ..". " .." Précipitations de ".. round(jsonTable1.data[2].precip,0) .. " milimètres. " devraient plutôt être : -- Définition des textes audio today_speach = Jours(tonumber(os.date("%w"))) .." : " .. jsonTable0.data[1].weather.description .. ". " .." Température entre ".. round(jsonTable0.data[1].min_temp,0) .." et ".. round(jsonTable0.data[1].max_temp,0) .." degrès. " .." Vent de ".. math.floor(jsonTable0.data[1].wind_spd*3.600) .." kilomètres par heure, en provenance ".. jsonTable0.data[1].wind_cdir_full ..". " .." Précipitations de ".. round(jsonTable0.data[1].precip,0) .. " milimètres. " tomorrow_speach = Jours(tonumber(os.date("%w"))+1) .." : " .. jsonTable1.data[1].weather.description .. ". " .." Température entre ".. round(jsonTable1.data[1].min_temp,0) .." et ".. round(jsonTable1.data[1].max_temp,0) .." degrès. " .." Vent de ".. math.floor(jsonTable1.data[1].wind_spd*3.600) .." kilomètres par heure, en provenance ".. jsonTable1.data[1].wind_cdir_full ..". " .." Précipitations de ".. round(jsonTable1.data[1].precip,0) .. " milimètres. " En effet, jsonTable0.data[1] contient les prévisions pour aujourd'hui, alors que les prévisions du lendemain sont dans jsonTable1.data[1]...

Du moment que la scène "boucle" par l'utilisation des setTimeout, il n'est plus utile de la lancer depuis le VD, d'autant plus quelle est en autostart. Donc la mainloop du VD peut effectivement être vide, tout étant maintenant réalisé dans la scène

Je ne pense pas que cela vienne de l'API, mais plutôt du fait que os.date("%w") retourne une valeur entre 0 et 6, 0 étant le dimanche. Aussi, dans la fonction jour... function jour(j) if j > 6 then j = 0 end local jourSemaine = {"Dimanche", "Lundi", "Mardi", "Mercredi", "Jeudi", "Vendredi", "Samedi"}; return jourSemaine[j+1]; end -- jour

Le dimanche, vaste sujet.. Selon le dictionnaire de l'Académie (9e édition) : Donc, ce n'est pas clair, heureusement, la norme ISO 8601 est là pour nous préciser que le dimanche clôt la semaine et a pour code le chiffre 7. Le problème se complexifie dans les langages informatiques selon que l'indice de départ est "zéro" (algol, C, pascal et leur dérivés) ou "un", comme notamment le Lua. Par conséquent, pour le dimanche on peut rencontrer comme code : 0, 1, 6 ou encore 7 ! En pratique, il est prudent de vérifier au cas par cas...

Bravo ! Le VD et la scène fonctionnent bien. Je crains toutefois que pour les prévisions, la vitesse du vent soit affiché en m/s et non en km/h...

Même si je ne l'ai pas testé, le code ci-après devrait faire la même chose : --[[ %% autostart --]] function tempFunc() local currentDate = os.date("*t"); if (currentDate.hour == 18 and currentDate.min == 30) then fibaro:debug("ok envoi à venir"); api.post('/mobile/push', { ["mobileDevices"]={154}, -- ID du telephone : 154= S7 EDGE JJ ["message"]='Veux-tu prévenir la maison ?', -- La question que l'on veut posser ["title"]='Départ Travail', -- titre de la question ["category"]='YES_NO', -- 'YES_NO' ou 'RUN_CANCEL' ["data"]={["sceneId"]=66} -- ID de la scéne que l'on veut lancer } ); end setTimeout(tempFunc, 60*1000); end local sourceTrigger = fibaro:getSourceTrigger(); if (sourceTrigger["type"] == "autostart") then tempFunc(); end Quelques explications : - currentDate.wday ne peut prendre que les valeurs 0, 1, 2, 3, 4, 5, 6, ce test est donc inutile ; - pourquoi convertir les heures et minutes en chaîne de caractères avant de faire la comparaison ? - on a : local sourceTrigger = fibaro:getSourceTrigger(); ... local startSource = fibaro:getSourceTrigger(); if (startSource["type"] == "other") then if (sourceTrigger["type"] == "autostart") then -- code jamais executé Donc, on enlève, la bonne vieille technique du rasoir d'Ockham...

Je suis surpris, dans la mesure où les trames EDF, décodées par l'Ecodevice, n'ont pas changé, il n'y a aucune raison pour une quelconque incompatibilité technique avec le compteur Linky. Aussi, avec le RT2 cela ne devrait également pas fonctionner. Le problème provient probablement du paramétrage du compteur qui ne laisse pas passer les trames. Après une rapide recherche il semblerait nécessaire de paramétrer le compteur avec les "Trames de télé-information du mode historique"...

Si tout le monde met en oeuvre cette politique, personne n'aura le loisir et le plaisir de trouver les anomalies qui nous permettent d'autant échanger sur ce forum. En synthèse, le bug c'est ce qui rapproche aussi bien les geeks que les geekettes...

Ben, moi aussi, elle tourne depuis maintenant plus de 3 heures, je ne trouve rien à en dire. Selon le forum Fibaro : https://forum.fibaro.com/topic/42880-4540-temporarily-unavailable-i-managed-to-update/ Traduction :

Problème rencontré lors de l'écriture d'un VD comportant plusieurs étiquettes : Le changement de l'ID de l'étiquette n'est pas pris en compte s'in comporte le caractère underscore , par exemple si le nouvel ID est "lblEV_1_8", il est systématiquement remplacé par : - "label_0_0" pour une étiquette en première position, - "label_1_0" pour une étiquette en deuxième position, - "label_x_0"pour une étiquette en position x. Cette capacité à casser ce qui fonctionne est assez remarquable chez Fibaro...

Oui, "%d+" retourne le premier nombre, "%d" retourne le premier chiffre rencontré de la gauche vers la droite, le + indiquant qu'il faut prendre aussi les suivants. Non, "%s" indique toutes les espaces (et oui, féminin en typographie...), ainsi : s=string.gsub("Nuit claire étoilée", "%s", "%%20"); print(s); -- retourne Nuit%20claire%20étoilée Pour ne remplacer que la première espace il eut fallu faire : s=string.gsub("Nuit claire étoilée", "%s", "%%20", 1); print(s); -- retourne Nuit%20claire étoilée -- ou encore : s=string.gsub("Nuit claire étoilée", " ", "%%20", 1); print(s); -- retourne Nuit%20claire étoilée Remarque : le signe "%" a un sens réservé dans les patterns, aussi est-il nécessaire de le doubler dans '%%20".

Pour remplacer tous les espaces par "%20", il faudrait plutôt faire : weather = string.gsub(weather, "%s", "%%20");

Avec : local s="aujourd'hui : 11°c - Nuit claire"; -- on extrait les chiffres local temperature = tonumber(string.match(s, "%d+")); -- "- " est considéré comme séparateur, on cherche sa position pos= string.find(s, "- "); -- on extrait la chaîne commençant en pos+2 local weather=string.sub(s, pos+2); print(temperature); print(weather); on obtient : 11 Nuit claire De rien...

Pour aider en restant dans le thème : print(string.gsub("moi c'est pareil, les pattern me perdent, -.......et j'en passe .mon cerveau n'est pas fait pour les pattern...", "-.*", " http://wxlua.free.fr/Tutoriel_Lua/Tuto/Strings/strings6.php"));

Je propose, pour utiliser gsub : s = "mercredi 12.05.2019 - Travail" t = "Vacances d'hiver" ns = string.gsub(s, '-.*', "- "..t) print(ns) Ce qui affiche : mercredi 12.05.2019 - Vacances d'hiver

La ligne : local status, json = pcall(function() return json.decode(response) end) déclare la variable json qui ne possède pas la méthode encode utilisée dans l'affichage Encodage2. En lui donnant un autre nom, toto par exemple, cela fonctionne: local status, toto = pcall(function() return json.decode(response) end)

Dans le premier pavé, currentTime est déclarée en tant que variable globale de la scène lors de son premier emploi dans la fonction findTimeZone. Après une autre variable déclarée elle locale, avec le même nom, est initialisée.

Cela signifie : Qu'il parvient bien à joindre le cloud Netatmo Que le cloud Netatmo signale que le service demandé n'est pas disponible Qu'il serait sans doute prudent de tester le contenu de response.data : si la clé error existe alors afficher sa valeur et arrêter le traitement, sinon tester la présence de la clé body avant l'utiliser serait prudent. Je viens d'essayer à nouveau, cela fonctionne, le problème était bien chez Netatamo... [DEBUG] 15:39:58: {"body":{"modules":[{"_id":"xx:xx:xx:x:xx:xx","main_device":"xx:xx:xx:x:xx:xx","type":"NAModule1","data_type":["Temperature","Humidity"],"module_name":"Jardin","firmware":44,"last_message":1547649156,"last_seen":1547649111,"rf_status":68,"battery_vp":5860,"dashboard_data":{"time_utc":1547649111,"Temperature":12.2,"Humidity":66,"min_temp":2.9,"max_temp":12.2,"date_min_temp":1547609793,"date_max_temp":1547647316,"temp_trend":"stable"},"date_setup":{"sec":1454015933,"usec":0}},{"_id":"xx:xx:xx:x:xx:xx","main_device":"xx:xx:xx:x:xx:xx","type":"NAModule3","data_type":["Rain"],"module_name":"Pluviom\u00e8tre","firmware":8,"last_message":1547649156,"last_seen":1547649150,"rf_status":79,"battery_vp":5874,"dashboard_data":{"time_utc":1547649150,"Rain":0,"sum_rain_24":0,"sum_rain_1":0},"date_setup":{"sec":1454149713,"usec":0}},{"_id":"xx:xx:xx:x:xx:xx","main_device":"xx:xx:xx:x:xx:xx","type":"NAModule2","data_type":["Wind"],"module_name":"An\u00e9mom\u00e8tre","firmware":18,"last_message":1547649156,"last_seen":1547649156,"rf_status":120,"battery_vp":5067,"dashboard_data":{"time_utc":1547649150,"WindStrength":6,"WindAngle":141,"GustStrength":15,"GustAngle":168,"max_wind_str":27,"max_wind_angle":158,"date_max_wind_str":1547637096},"date_setup":{"sec":1475322877,"usec":0}}],"devices":[{"_id":"xx:xx:xx:x:xx:xx","type":"NAMain","co2_calibrating":false,"date_setup":{"sec":1454015949,"usec":0},"firmware":132,"last_status_store":1547649162,"last_upgrade":1454945187,"module_name":"Indoor","station_name":"Maison","place":{"altitude":164,"city":"yyyyyyyyyyy","country":"FR","timezone":"Europe\/Paris","location":[0.00000000000,0.0000000000]},"wifi_status":57,"data_type":["Temperature","CO2","Humidity","Noise","Pressure"],"dashboard_data":{"time_utc":1547649153,"Temperature":21.8,"CO2":740,"Humidity":65,"Noise":39,"Pressure":1010.7,"AbsolutePressure":991.2,"min_temp":19.7,"max_temp":21.8,"date_min_temp":1547624273,"date_max_temp":1547647946,"temp_trend":"stable","pressure_trend":"stable"},"modules":["xx:xx:xx:x:xx:xx","xx:xx:xx:x:xx:xx","xx:xx:xx:x:xx:xx"]}]},"status":"ok","time_exec":0.21196794509888,"time_server":1547649597}

Avec : fibaro:debug(response.data) func(json.decode(response.data)) J'obtiens : [DEBUG] 11:52:29: {"error":{"code":503,"message":"Service Unavailable"}} Ce qui explique l'erreur : [DEBUG] 11:52:29: 2019-01-16 11:52:29.466092 [ fatal] LUA error: /opt/fibaro/scenes/107.lua:61: attempt to index field 'body' (a nil value)

Dans le premier cas, currentTime n'est pas initialisé et vaut donc Nil lors de son premier emploi. Dans le second cas, cette variable a bien une valeur. En Lua, il y a une déclaration implicite des variables, et dans tous les langages de programmation, une variable non initialisée ne contient aucune valeur...

Comme disaient mes interlocuteurs américains : work as designed. Ce à quoi je répondais invariablement : bad design.

Vous exagerez, cet écran est utilisé pour se logger en local soit avec le port 80 (sauf si root de la HC2). Pour une connexion distante il faut utiliser le Fibaro Id... Et là, rien ne fonctionne !

fibaro:call(i, "setArmed", "1")

Suite à la lecture de la documentation, la fonction n'admet que deux paramètres action et filters, le second paramètre devant être un tableau, l'erreur est donc conforme aux spécifications. Cette fonction est manifestement prévue uniquement pour des devices physiques...

@Lazer Désolé, fausse alerte ! En fait le VD fonctionne toujours, un effet de la loi de Murphy : un mauvais contact dans le câble réseau de l'ampli est apparu au même moment que la mise à jour de l'HC2.