Barelle

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.

Bonsoir, Depuis le passage en 4.520, cet excellent VD ce met en erreur et affiche les traces suivantes dans la fenêtre de debug de la mainloop : [DEBUG] 18:33:27: Function successfully loaded in memory [DEBUG] 18:33:31: Error : Can not connect to Yamaha, errorCode=2, status=, url=/YamahaExtendedControl/v1/system/getDeviceInfo, response= [DEBUG] 18:33:31: Warning : Can't get device info [DEBUG] 18:33:50: Error : Can not connect to Yamaha, errorCode=2, status=, url=/YamahaExtendedControl/v1/system/getDeviceInfo, response= [DEBUG] 18:33:50: Warning : Can't get device info [DEBUG] 18:34:10: Error : Can not connect to Yamaha, errorCode=2, status=, url=/YamahaExtendedControl/v1/system/getDeviceInfo, response= [DEBUG] 18:34:10: Warning : Can't get device info

Je te suggère de rajouter dans tes traces les valeurs des variables globales : fibaro:debug("Step 2, room_zone="..room_zone) fibaro:debug("Step 3, zone_heat_value="..zone_heat_value)

Où est définie la variable roomName ?

Essaie de faire http://192.168.0.200/docs/#! puis d'interroger les valeurs de l'id 166 et de t'en inspirer pour construire ton json. Je suis surpris de trouver parameters comme clé de properties, il me semble que c'est plutôt l'inverse...

Oui, mais dans le json n'est toujours pas valid : La validation par le site https://jsonlint.com/ retourne l'erreur suivante : Error: Parse error on line 16: ...ed": 1540796527 }] ----------------------^ Expecting '}', ',', got 'EOF'

Il y a au moins une erreur dans la valeur de jtable ("[" de parameters non fermé). Utiliser par exemple https://jsonlint.com/ pour la valider.

Il faudrait peut-être penser à changer la valeur de la variable Presence : if Twentycents < timestamp - delay then if Presence == "1" then Presence = "0" fibaro:debug(os.date('%d/%m/%Y').." : Absence détectée") end else if Presence == "0" then Presence = "1" fibaro:debug(os.date('%d/%m/%Y').." : Présence détectée") end end fibaro:setGlobal("Presence", Presence) fibaro:debug('Et donc je passe la valeur de Presence à: ' ..Presence)

Mais ce n'est pas une formule excel...

Dans la mesure où : temp = os.date("%x %X", 1538875398) fibaro:debug(temp) affiche : [DEBUG] 11:18:51: 10/07/18 03:23:18 ta formule est bonne !

Cela fait maintenant quelques mois... J'ai contourné le problème en définissant manuellement l'altitude et en la forçant dans le cas d'une réponse invalide. local altitudeDefault = 164; -- A adapter avec l'altitude du lieu -- Elevation Google API (Free) GoogleElevation = Net.FHttp("maps.googleapis.com") local response, status, errorCode = GoogleElevation:GET("/maps/api/elevation/json?locations=".. Latitude .. "," .. Longitude .. "&sensor=false") if tonumber(status) ~= 200 then fibaro:debug("GoogleElevation, status=".. status..", errorCode="..errorCode); fibaro:debug("Altitude forced to "..altitudeDefault.." m"); Altitude = altitudeDefault; else jsonTable = json.decode(response) if (jsonTable.results[1] ~= nil) then Altitude = jsonTable.results[1].elevation fibaro:debug("Altitude found from Google api"); else if (jsonTable.status ~= nil) then fibaro:debug("****** maps.googleapis.com status="..jsonTable.status.." ******"); end fibaro:debug("Altitude forced to "..altitudeDefault.." m"); Altitude = altitudeDefault; end end fibaro:debug("Altitude = " .. tostring(Altitude) .. " m");

Nico, oui, c'est bien ce que je disais, avec cette modification il y a du code qui devient inutile dans le cas des scènes mais il reste utile dans le cas des VD.

Pour ma part, dans la fonction Restart, j'ai remplacé les lignes : jsonTable.lua = jsonTable.lua .. "\n"; response.data = json.encode(jsonTable); par : fibaro:setSceneEnabled(id, false); fibaro:setSceneEnabled(id, true); Notification('Watchdog : '..type..' "'..(name or "")..'" ('..id..") a fait l'objet d'un disable/enable", notification); return; une partie du code qui suit devenant bien sûr mort. Et cela fonctionne depuis des mois ainsi... La fonction setSceneEnabled est apparue après l'écriture du watchdog par Lazer, d'où cette astuce qu'il a employé et qui ne se justifie plus aujourd'hui. Maintenant une scène arrêtée aussi fréquemment a manifestement un problème.

D'où ce vieil adage informatique : quand une application fonctionne, c'est parce qu’elle n'a pas suffisamment de fonctionnalités...

Pour les valeurs non affichées, je crains ne rien pouvoir, le serveur UPS du NAS ne les remonte pas, probablement car elles ne sont pas fournies par l'onduleur. Tu pourrais sans doute faire évoluer le VD (interface et code) soit en substituant ces valeurs indisponibles par d'autres susceptibles de t'intéresser, soit en les supprimant... Les définitions des différentes valeurs figurent dans un commentaires à la fin du code du bouton Update...