Nikko

I don't have Danfoss LC13... Is this device battery powered ? In this case this device is sleeping most of time. The HC2 send order only at the the device's wakeup. That's a suggestion, maybe I'm wrong... You have to check in API if the order to adjust temperature is 'setValue': * http://homecenter_ip/api/devices/20 * Find actions and which order are allowed

Hi @basklj, I think a "s" is missing at the end of the "Day" parameter. :-) GEA.add(Home, 1, "", { {"Days", "Weekday"}, {"Time", "6:01", "8:00"}, {"Value", id["Library_therm"], 20}}) Nicolas

@pepite , ne t'inquiètes pas pour l'ip ou la clé dans mon script ;-) Il n'est peut être pas nécessaire de passer par un virtuel. J'avoue que je débute encore et les solutions sont peut être nombreuses. Je préférais procéder de cette façon car au moins je sais que l'état qui s'affiche est quasi immédiat et correspond au véritable état. Nicolas

Salut @pepite, Je ne sais pas si ça peut servir mais voilà comment je commande mes wallplug géré par mon HC2 via Jeedom: * Sur Jeedom, je crée via le plugin script les commandes On et Off du wallplug pour allumer et eteindre via l'api (ça à priroi c'est OK pour toi) * Ensuite je crée un virtuel pour le wallplug, avec le On, le Off , l'etat et la conso actuelle; Ce qui dans les grandes lignes donne ça: Au niveau propriétés cela donne ça: Le On utilise ma commande script d'allumage et le Off idem pour l'arret. Concernant le retour d'état, j'uilise un scene sur le HC2: --[[ %% properties 915 value 915 power 917 value 917 power 978 value 978 power %% events %% globals %% autostart --]] -- Flag Debug pour afficher dans les logs de la scene fibaro local debug = true local sourceTrigger = fibaro:getSourceTrigger() local JEEDOM = { IP = '192.168.100.200' , KEY = 'MU44RWMCaPasBZxLaYPBonNne9cLe' } -- -- Définitions des modules -- local MODULES = { -- WallPlug Lampe Oeuf [915] = { value = 953, power = 955, } , -- WallPlug Lampe Noire [917] = { value = 936, power = 937, } , -- WallPlug Ampli [978] = { value = 973, power = 977, } , } local idJeedom, property , value if (sourceTrigger['type'] == 'property') then property = sourceTrigger['propertyName'] value = fibaro:get(sourceTrigger['deviceID'], property) idJeedom = MODULES[sourceTrigger['deviceID']][property] if (debug) then fibaro:debug('ID HC2: '..sourceTrigger['deviceID']..' | Property: ' ..sourceTrigger['propertyName']..' | ID JEEDOM: '..idJeedom..' | Value: '..value) end local http = net.HTTPClient() response = http:request("http://"..JEEDOM['IP'].."/core/api/jeeApi.php?apikey="..JEEDOM['KEY'].."&type=virtual&id="..idJeedom.."&value="..value, { options={ method ='POST', ---timeout =5000 }, success = function(response) if debug then print('ACK ID '..sourceTrigger['deviceID']..'/'..idJeedom..' | Status: '..__convertToString(response.status)) end end, error = function(err) fibaro:debug("Error: " ..err) end }) elseif (sourceTrigger['type'] == 'other' or 'autostart') then print("Manual Trigger | Refresh Variable Status in Jeedom") for index in pairs(MODULES) do for k , v in pairs(MODULES[index]) do local value = fibaro:get(index, k) print('Module: '..index..' | Property: '..k..' | ID Jeedom: '..v.. ' | Value: '..value) local http = net.HTTPClient() response = http:request("http://"..JEEDOM['IP'].."/core/api/jeeApi.php?apikey="..JEEDOM['KEY'].."&type=virtual&id="..v.."&value="..value, { options={ method ='POST', ---timeout =5000 }, success = function(response) if debug then print('ACK ID '..index..'/'..v..' | Property: '..k..' | Status: '..__convertToString(response.status)) end end, error = function(err) fibaro:debug("Error: " ..err) end }) end end else print('No Matching Trigger') print(sourceTrigger['type']) end Pour faire simple: Dans l'entete tu met en déclencheur le value et power du wallplug (là j'ai 3 wallplug) Ensuite dans ma table MODULES je déclare quelle propriété du module va sur quelle id de jeedom; Exemple Mon Module Wallplug dont l'id est 978 sur mon HC2 met à jour l'id 973 de jeedom quand son état change (ce qui correpond à "Etat" dans ma première capture) et l'id 977 de jeedom pour la puissance. Au niveau HomeCenter, la scene est en automatique avec 10 instances. Comme ça au démarrage scene ou autre (ou démarrage manuel de la scene) , les variables sont de suite mises à jour. Tu peux meme au niveau Jeedom créee avec script une commandes qui déclenche la scene pour tout mettre à jour (au démarrage jeedom par exemple). A toi d'adapter pour un simple éclairage. Mes 2 cents.... Nicolas

Recopie le dernier code que je t'ai mis, car c'est ce que je t'expliquais, tu n'a pas les guillemets sur ton On. De plus ton label ne sera mis à jour que la première fois puisque: Si tu arrives à faire le Get alors label On et Variable globale à 1 Sinon variable globale à 0 Mais jamais tu ne demandes à ton label de mettre un autre état que on Donc si ton get aboutit alors ton label passe sur on mais au coup d'après si la requète n'aboutit pas, tu restes quand même sur on vu que tu ne modifies pas le label par la suite... Il aurait fallu un truc du genre: local HC2 = Net.FHttp("192.168.0.199", 54243); local result, status, errorCode = HC2:GET("/device.xml"); if tonumber(errorCode) == 0 then if tonumber(status) == 200 then fibaro:debug('Status: ON') fibaro:setGlobal("FbxHD_etat", 1) fibaro:call(fibaro:getSelfId(), "setProperty", "ui.EtatFbxPlayer.value", "On") else fibaro:debug('Status: OFF or In Standby Mode') fibaro:call(fibaro:getSelfId(), "setProperty", "ui.EtatFbxPlayer.value", "Off") fibaro:setGlobal("FbxHD_etat", 0) end else fibaro:debug('Connection refused') fibaro:setGlobal("FbxHD_etat", 0) fibaro:call(fibaro:getSelfId(), "setProperty", "ui.EtatFbxPlayer.value", "Refused") end

As tu toujours l'erreur ou est ce juste ton label qui n'est pas mis à jour???? local HC2 = Net.FHttp("192.168.0.199", 54243); local result, status, errorCode = HC2:GET("/device.xml"); if tonumber(errorCode) == 0 then if tonumber(status) == 200 then fibaro:debug('Status: ON') fibaro:setGlobal("FbxHD_etat", 1) fibaro:call(fibaro:getSelfId(), "setProperty", "ui.EtatFbxPlayer.value", "On") else fibaro:debug('Status: OFF or In Standby Mode') fibaro:setGlobal("FbxHD_etat", 0) end else fibaro:debug('Connection refused') fibaro:setGlobal("FbxHD_etat", 0) end

Bonjour, Ce que @Berale24 t'écris c'est que dans cette ligne: fibaro:call(EtatFbxPlayer, "setProperty", "ui.EtatFbxPlayer.value", On) tu n'as pas définit EtatFbxPlayer, qui est juste après le call. fibaro:call(id , "setProperty", "ui.Label.value", texte) id est un nombre, représentant le numéro du VD; Dans ton cas EtatFbxPlayer, doit renvoyer vers un nombre; que tu auras définit, par exemple EtatFbxPlayer = fibaro:getSelfId() ou EtatFbxPlayer = 55 si ton device est le numéro 55 "ui.Label.value" est le nom du label; ici "ui.EtatFbxPlayer.value"; ok texte est de type string. Ici tu as mis On sans les guillemets, ce qui veut dire que tu inscrit le contenu d'une variable On que tu auras définit auparavant. Je pense que tu as oublié les guillemets

Pour le retour json du x-thl, je n'ai pas d'infos car je n'en ai pas.... Pour le cablage des LM, c'est simple, cf les datasheet des composants. Pour le bus, il est bien en parallèle: sur la doc il se servent du bornier de chaque module pour faire 1 depart/1 arrivée, mais ils auraient très bien pu tout faire partir de l'ipx. Le mieux est je pense de tirer un cable entre chaque module et ipx. Dans leur exemple, les modules sont tous cote à cote donc autant les relier comme ils ont fait. Si un module tombe HS ce n'est pas grave, ce qui intéresse ici c'est le bornier: même si le module tombe l'intégrité du bus est conservée, par contre le point faible devient la connectique (encore plus que d'habitude): si tu es mal serré au 1er module alors tout le reste risque de ne pas répondre

Sur la doc il est précisé: "Alimentation préconisée : de 3,3V à 5V continus (non fournie) Max : 12V". Donc tu branches où tu veux., soit 3.3 ou alors +12V Pour le bus, oui tu n'as qu'un connecteur mais ce n'est pas un problème, tout est en parallèle. Regardes dans la doc d'installation de l'ipxV4 c'est indiqué par des photos:

Salut, Les modules X-THL sont connecté sur un bus commun (ipxV4) et non sur les entrées analogiques. Ils sont donc gérés indépendamment doivent te laisser au niveau interface tes 6 entrées libres. Pour les capteurs filaires. Si tu veux pouvoir te connecter sur les entrées analogiques de l'ipx, tu peux utiliser des capteurs analogiques par exemple LM35D ou LM335Z qui ont une précision de l'ordre du degrés à 25°C. L'avantage de ces composants est qu'ils ont une réponse linéaire et que la formule de sortie est 10mV/°C, ce qui au niveau de l'ipx est simple à convertir. Le LM335 peut être alimenté en +12V avec une résistance série de 10k par exemple. Sa sortie ne dépasse jamais 3.3V contrairement au LM35 auquel pourrait falloir une protection en sortie du LM35 pour éviter que tu ne dépasses 3.3 sur l'entrée analogique (genre zener). Ce qui est lourd, c'est qua quant tu intéroges l'api de l'ipx, les valeurs analogiques sont retournées non pas en volts mais en conversion Analogique/numérique, soit un nombre entre 0 et 1024, donc sur ta HC2 tu devra reconvertir en volt puis ensuite en °C. Exemple: J'ai un LM335D sur l'entrée AN1 de mon IPX. Pour obtenir le statut de entrée en json, il faut interroger: http://ipx800/api/xdevices.json?cmd=30 On obtient: {"product":"IPX800_V3","AN1":873,"AN2":0,"AN3":0,"AN4":0,"AN5":0,"AN6":0,"AN7":0,"AN8":0,"AN9":0,"AN10":0,"AN11":0,"AN12":0,"AN13":0,"AN14":0,"AN15":0,"AN16":0} J'ai donc 873 alors que mon panel affiche 2.82 Volts (bien sûr on peut demander au panel d'afficher en numérique mais j'aurais préféré récupérer des volts) Donc au niveau virtual device: HC2 = Net.FHttp('192.168.0.41') local id = 1034 local reponse, statut , code = HC2:GET("/api/xdevices.json?cmd=30") if statut and tonumber(statut) == 200 then reponse = json.decode(reponse) local analogValue = reponse.AN1 local volts = (analogValue * 3.3)/1024 -- 0°K = -273.15 donc 0°C = 273.15°K -- la sonde envoie 10mV pour 1°C; Il faudra soustraire 2.7315V local tempK = 100*volts local tempC = string.format('%.02f°C',(tempK - 273.15)) fibaro:debug('V: '..volts..' | Temp K: '..tempK..' | Temp C: '..tempC) fibaro:call(id, "setProperty", "ui.ANA.value", analogValue) fibaro:call(id, "setProperty", "ui.TEMP.value", tempC) end fibaro:sleep(5000) Il existe bien d'autres composants, ces 2 là ne sont qu'une possibilité, et pour une mesure intérieure la plage est large (mais identique à celle du X-THL) EDIT: Je viens de corriger car 'javais écris une connerie

@pepite: sous Windows (10 en tout cas mais à mon avis depuis bien longtemps), tu peux aussi le faire en ligne de commande avec certutil: Tu écris le couple login:pass sous un fichier infile.txt, mais sans espace ou CR à la fin Depuis un shell, dans le même répertoire que infile.txt: certutil -encode infile.txt outfile.txt Tu as ton ensemble en base 64 dans outfile.txt Et bien sûr le résultat est le même quel que soit l'OS: Bref des méthodes il en existe des tas ;-)

@pepite: Source: https://gist.github.com/bortels/1436940 local b='ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/' -- encoding function enc(data) return ((data:gsub('.', function(x) local r,b='',x:byte() for i=8,1,-1 do r=r..(b%2^i-b%2^(i-1)>0 and '1' or '0') end return r; end)..'0000'):gsub('%d%d%d?%d?%d?%d?', function(x) if (#x < 6) then return '' end local c=0 for i=1,6 do c=c+(x:sub(i,i)=='1' and 2^(6-i) or 0) end return b:sub(c+1,c+1) end)..({ '', '==', '=' })[#data%3+1]) end print(enc('pepite@domotique-fibaro.fr:jolipassword'))

Bonjour Mise à jour: Suite au passage en 4.101 et plus, l'API a changé concernant les backups; voici donc un résumé en fonction des versions API pour Version < 4.101 BACKUP: URL: http://ip/api/settings/backups TYPE: POST DATA: action=create&description=monbackup HEADER: Content-type: application/x-www-form-urlencoded RESTORE: URL: http://ip/api/settings/backups TYPE: POST DATA: action=restore&id=1051 (par exemple) HEADER: Content-type: application/x-www-form-urlencoded DELETE: URL: http://ip/api/settings/backups?id=xxxx (xxx: id du backup) TYPE: DELETE DATA: id=xxxx HEADER: Content-type: application/x-www-form-urlencoded API pour Version >= 4.101 BACKUP: URL: http://ip/api/service/backups/ TYPE: POST DATA: {"action":"create","params":{"name":"Le descriptif de mon backup"}} HEADER: Content-type: application/x-www-form-urlencoded Authorization: Basic xxxxxxxxxxxxxxxx (mot de passe encodé en base64) RESTORE: URL: http://ip/api/service/backups/ TYPE: POST DATA: {"action":"restore","params":{"id":1054}} (1054 est un exemple) HEADER: Content-type: application/x-www-form-urlencoded Authorization: Basic xxxxxxxxxxxxxxxx (mot de passe encodé en base64) DELETE: URL: http://ip/api/service/backups/ TYPE: DELETE DATA: n/a HEADER: Authorization: Basic xxxxxxxxxxxxxxxx (mot de passe encodé en base64) Encodage Base64 Pour le couple login/password, ils doivent être encodés en base64; Pour ce faire: Sous linux: echo -n 'monlogin@fai.com:motdepasse' | base64 Sous windows: une scene en lua sur le HC2 : taper base64.lua sous google Le toolkit de @Krikroff (https://www.domotique-fibaro.fr/topic/239-hc2-toolkit-application-v1203/) Advanced RESTful client: faire une requete sur une url de l'api, le couple login/mdp sera demandé et sera affiché ensuite encodé. Exemple de Scènes Pour des requêtes externes, cela ne change pas vraiment. En revanche pour ceux qui comptent réaliser des scènes de backup/delete, ces requètes ne sont plus gérées pareil (avant en local, nous utilisions 127.0.0.1:11111 qui est géré par le process HCServer; maintenant il faut utiliser 127.0.0.1 et pointer sur un php) Donc pour les scènes lua, pas de api.post ou api.get et authentification nécessaire. Voici 2 scènes exemples; Les scène ne sont pas forcèment optimisées. Elles montrent juste l'utilisation de l'api Scène de Backup: performBackup.lua --[[ %% properties %% events %% globals --]] -- Message Descriptif du Backup local descriptif = 'Backup du '..os.date("%d/%m/%y - %HH%M") -- Password admin encodé en base64 local password = 'aWRpb3RAZ3Z1bGF2aWVyZ2UuY29tOnR1X3lfY3JveWFpc19oZWlu' local url = 'http://127.0.0.1/api/service/backups' local datas = '{"action":"create","params":{"name":"'..descriptif..'"}}' local httpClient = net.HTTPClient() httpClient:request(url , { success = function(response) if tonumber(response.status) == 201 or tonumber(response.status) == 202then print("Backup Created at " .. os.date()) else print("Error " .. response.status) end end, error = function(err) print('error = ' .. err) end, options = { method = 'POST', headers = { ["content-type"] = 'application/json', ["Authorization"] = 'Basic '..password }, data = datas } }); Scene d'effacement du backup le plus ancien: deleteBackup.lua --[[ %% properties %% events %% globals --]] -- Flag dryrun; Si true, la requete sur api pour effacer le backup n'est pas effectuée local dryrun = true -- Password admin encodé en base64 local password = 'aWRpb3RAZ3Z1bGF2aWVyZ2UuY29tOnR1X3lfY3JveWFpc19oZWlu' function sortBackup(data) local backups = json.decode(data) -- Vérification de présence Backup if (backups and type(backups == 'table') and #backups > 0) then if #backups > 1 then print(#backups .. ' Backups présents') else print('1 Backup présent') end for i in ipairs(backups) do fibaro:debug('ID: '..backups[i]['id']..' | TIMESTAMP: '..backups[i]['timestamp']..' | DESCRIPTION: '..backups[i]['description']) end else print('Pas de backup ou erreur lors de la récupération de la liste') fibaro:abort() end -- Pour chaque Backup on stock le timestamp de la date de réalisation dans une table -- On classe ensuite les timestamps par ordre croissant local timestamp = {} for i in ipairs(backups) do table.insert(timestamp, backups[i]['timestamp']) end table.sort(timestamp) -- Le 1er timestamp de la table est le plus petit donc le plus ancien en epochtime -- Dans la table de backup on recherche le backup ayant ce timestamp local id = false for i in ipairs(backups) do if (tonumber(backups[i]['timestamp']) == tonumber(timestamp[1])) then id = backups[i]['id'] end end if id then print("ID du backup le plus ancien: "..id) deleteBackup(id) else print("Erreur lors de la récupération de l'ID") fibaro:abort() end end function deleteBackup(id) -- Requete via API pour effacer le backup le plus ancien if (not dryrun) and (id) then print('Effacement du backup '..id..' en cours. Cela peut prendre 30s') local url = 'http://127.0.0.1/api/service/backups/'..id local httpClient = net.HTTPClient() httpClient:request(url , { success = function(response) if tonumber(response.status) == 200 then print("Backup deleted at " .. os.date()) else print("Error " .. response.status) end end, error = function(err) print('error = ' .. err) end, options = { method = 'DELETE', headers = { ["content-type"] = 'application/x-www-form-urlencoded;', ["authorization"] = 'Basic '..password }, data = 'id='..id } }) end end -- Récupération de la list des backups local GETClient = net.HTTPClient() if dryrun then print('Mode DryRun -> La requète pour effacer ne sera pas éxécutée') end GETClient:request('http://127.0.0.1/api/service/backups', { success = function(response) if tonumber(response.status) == 200 then sortBackup(response.data) else print("Error " .. response.status) end end, error = function(err) print('error = ' .. err) end, headers = { ["content-type"] = 'application/x-www-form-urlencoded;', ["authorization"] = 'Basic '..password } }); Nicolas

Quelles commandes ? L'api pour backup et restore? Si c'est le cas normal, j'ai mis les commandes pour une 4.101. Pour une 4.100: BACKUP: http:/ip/api/settings/backups POST Data: action=create&description=monbackup RESTORE: (pas sûre) http:/ip/api/settings/backups POST Data: action=restore&id=1051 (par exemple) De plus j'ai modifié le tuto, en effet le fichier sql que j'avais mis était correct si l'on passais en 4.101, mais en cas de restore du backup sur une 4.100, cela posait des problèmes (exemple: unité de température marquée en undefined). J'ai donc mis 2 fichiers sql en fonction de la version sur laquelle on veut rester Nicolas

@djtic: J4ai écris vite fais une procédure dans la section tuto: https://www.domotique-fibaro.fr/topic/9552-mise-à-jour-4100-4101-les-boules-bleues/ Par contre c'est pour une HC2, mais je pense que HCL ça marche aussi Nicolas

Bonjour, Suite aux soucis de certains avec "les boules bleues" lors de la mise à jour 4.100 vers 4.101 beta, voici une procédure qui permettra de réparer les dégats. Ma version est la 4.101, les commandes API sont donc legèrement différentes pour la version précédente. N'étant plus en 4.100, je ne peux pas les tester J'ai écris cette procédure en partant d'une base vérollée et au final ça marche. La méthode n'est peut être pas universelle et est à vos risques et périls. En cas de doute, s'abstenir MISE A JOUR: La procédure de mise à jour de la base de données est correcte si l'on veut rester en 4.101, mais si on veut rester en 4.100, les champs sont un peu différents. Je mets donc 2 fichiers à disposition, 1 pour la 4.100 et 1 pour la 4.101 Si on remet à jour une 4.100 avec le fichier de la 4.101, visiblement la bdd se corromt à nouveau et disparition du device 13 Quand est on concerné ? Mise à jour 4.100 -> 4.101 La box semble fonctionner mais l'accès à l'interface est impossible L'url http://ip/api/weather ne renvoie rien L'url http://ip/api/devices/3 ne renvoie rien un F12 lors de l'affichage de l'interface met en évidence une erreur javascript sur la propriété Temperature lors de l'appel de la fonction onWeatherDataBuild Quels sont les outils nécessaires ? SQLITEBROWSER, pour éditer/modifer la base de donnée: http://sqlitebrowser.org/ Le fichier texte sql qui est un fichier contenant les données à rajouter dans les tables: property_4100.sql property_4101.sql Un calculateur de checksum MD5, lorsque windows, par exemple winMD5Free http://www.winmd5.com/ ETAPE 1 : Le backup Réaliser un backup à l'aide de l'api. Pour ma part sous CHROME j'utilise Advenced RESTful Client. URL: http://homecenter/api/service/backups TYPE: POST CONTENT-TYPE: application/x-www-form-urlencoded Dans la partie RAW PAYLOAD, entrer: {"action":"create","params":{"name":"SQL HS"}} Attendre une minute puis vérifier l'id du backup en utilisant l'api: http://homecenter/api/service/backups Eteindre proprement le HomeCenter Prendre la clé USB et la brancher sur le PC Dans le répertoire backups\ se trouvent tous les backups réalisés par le HC2 Sélectionner le dernier réalisé et vérifier dans le fichier info que ce backup correspond à celui réalisé Copier maintenant tout ce répertoire sur votre PC (voire même toute la clé), afin d'avoir une sauvegarde en cas de problème ETAPE 2: Modification de la base de données Ouvrir SQLITEBROWSER Fichier / Ouvrir une base de données / Sélectionner dans le répertoire de backup le fichier nommé "sql" Fichier / Importer / Base de données à partir du fichier SQL Sélectionner le fichier de requète SQL: property_4100.sql property_4101.sql Au message "Voulez Vous Créer une base de donnée pour gérer les données importées", répondre NON Si l'import se passe bien on obtient le message Import terminé Fichier / Enregistrer les modifications Fichier / Quitter ETAPE 3: Correction Checksum Ouvrir WinMD5Free, et sélectionner le fichier sql modifié Au bout de quelques secondes le checksum apparait: Ouvrir le fichier checksum dans le répertoire de backup, et remplacer le checksum sur la ligne sql par celui calculé Démonter la clé, la rebrancher sur le HC2 et lancer le boot Attendre quelques minutes que le HomeCenter Démarre ETAPE 4: Restauration Backup Si il s'agit d'un recovery, au moment de sélectionner le backup, prendre le backup modifié Sinon, Il est possible d'utiliser l'api pour restaurer le backup: URL: http://homecenter/api/service/backups TYPE: POST CONTENT-TYPE: application/x-www-form-urlencoded Dans la partie RAW PAYLOAD, entrer: {"action":"restore","params":{"id":1054}} (l'id à entrer est celle du backup donc elle diffère) => Le backup est normallement en cours de restauration; cela peut prendre plusieurs minutes Nicolas

L'api a changée avec cette version. Le script n'est plus valable. Je mettrai à jour le topic dédié ce soir

Bonjour, Ce qui est le plus triste dans tout ça, c'est que l'interface était plantée à cause........ de la météo... qui faisait partie de la mise à jour Le premier problème de @flamalex était que son répertoire backups était absent lors de l'upgrade. Donc répertoire backups sur la clé regénéré puis sauvegarde via l'API. @jojo, je crois que tu cherchais: pour exécuter différents types de requètes avec différents paramètres, une appli chrome pas mal: Advanced RESTful Client Concernant les boules bleues: En activant le F12, nous avons vu une erreur sur un javascript et qu'une exception se produisait dans le fichier SystemServiceSettings.js lors de l'appel de la fonction onWeatherDataBuild qui ne renvoyait pas la propriété Temperature. En parralelle, l'API était disponible mais par contre un controle sur api\weather ne renvoyait rien; @flamalex avait refait un recovery jusqu'en 4.101 et tout à flanché lors de la restauration de son backup précédement effectué => Le problème venait de la bdd La partie Weather de l'api est en fait complétée à l'aide du device weather qui est le device 3. Sur un HC2 fonctionnel, http:\\ip\api\devices\3 renvoie bien des infos mais sur son install, device 3 inconnu. Donc il a fallu éditer la bdd pour créer dans les Tables NEW_Device et NEW_Properties les champs nécessaires. Ensuite regénération du checksum pour le fichier sql. Remise en place des fichiers checksum et sql dans le backup; Recovery, upgrade puis réinstall backup Ce qui est dommage c'est que les gars de Fibaro auraient pu trouver ça rapidement si ils avaient prit la peine de regarder plutôt que de faire une réponse bateau "faire un recovery" sans même être sûre que l'utilisateur possède une sauvegarde viable Nicolas

Disons que l'adhésif derriere les rubans a tendance a ne pas tenir. Et puis ça fait tout de suite plus propre Sur la photo on ne voit pas très bien, mais c'est le dessous du meuble de cuisine; le ruban est à qq centimètres devant la plinthe.

Salut, Idem que @peter, j'en ai sous mes meuble de cuisine. Pour la fixation des rubans, j'utilise des profilé alu ( https://www.amazon.fr/gp/product/B01CP494MI ) Pour l'alimentation/module rgbw, placés derrière les plinthes, sur support pour ne pas être en contact avec le sol (on ne sait jamais avec les inondations) Nicolas

Tu édites les paramètres du VR possédant l'inter Onglet Avancé Descend jusqu’à trouver le bouton association Ensuite GROUPE 1; Puis dans la liste à droite tu coches (colonne S) le module qui sera associé au premier Ensuite descend en bas de la liste pour faire SAVE L'association est lancée de suite. Une fois associés, les modules seront synchronises au niveau des ordres lors de l'appui sur le bouton de ton VR (et ce même si la box est HS)

oui tu cables les 2: 1 sur chaque module.

Salut, Si tu prends 2 modules FGRM-222, tu cables chaque module à un VR puis tu associes un module avec l'autre (via le HC2). Ensuite avec 1 seule commande, tu pilotes les 2.

@971jmd, L'api ou l'utilisation de l'interface fibaro ne permet pas de le faire. Il existe des possibilités en ayant l'accès root sur la box, mais je ne m'étendrai pas sur le sujet

Salut, Le code fonctionne chez moi, mais comme je n'ai pas pu l'utiliser chez plusieurs personnes, j'ai mis une "sécurite": la variable dryrun. Si sur true le delete n'est pas executé si sur false le delete se fait. C'est justement pour vérifier que l'id retournée correspond bien au backup le plus ancien: ça évite de supprimer si erreur. as tu bein basculé le flag dans le script ?