Krikroff

Alors... L'idée serait de déclarer une variable dans ton init self.socketClosed = true Puis implémenter 2 méthodes: connect / closeSocket (ou les noms que tu souhaites bien évidement ) Et enfin d'utiliser une méthode principale pour ton send, afin de faire toutes les vérifications d'usage avant le socket:write exemple: function pioneer__vsx__device:send(cmd, expected, callback) if (self.socketClosed == true) then self:connect() end -- This equipments is using the 1st command's <CR> as a trigger to wake up the main CPU self.socket:write("\r", { success = function() self:debug("wake up the main CPU") -- wait 100msec fibaro.sleep(100) self.socket:write("\r"..cmd.."\r", { success = function() -- the function that will be triggered when the data is correctly sent self:debug("data sent") if (type(expected) == 'string') then self:waitForResponse(expected, callback) -- launching a data readout "loop" waitng for expected data else -- no results expected end end, error = function(err) -- the function that will be triggered in the event of an error in data transmission self:debug("error while sending data") self:closeSocket() end }) end, error = function(err) -- the function that will be triggered in the event of an error in data transmission self:debug("error while sending data") self:closeSocket() fibaro.setTimeout(2000, function() self:send(cmd, expected, callback) end) end }) end Du coup, en cas de déconnexion / reco. de ton serveur et au prochain send depuis le HC3, si ça plante le script ferme le socket, puis ré-ouvre et réexecutre la dernière commande. Il faudrait certainement encore "durcir" tout cela mais ok dans mes simulations. Amuse-toi bien

Fait ! Pour le coup je ne suis pas certain qu'il s'agisse d'un bug, à confirmer, avis aux possesseurs de HC3 avec pleins de modules la notification n'est-elle pas que sur l'action principale du module genre: opening, motion... J'ai remonté cela en demande d'amélioration.

Ok [emoji106] Je remonte ça en fin de soirée

Les points 1 & 3 sont déjà identifiés depuis un moment, le 3 en cours de résolution (espérons pour la prochaine maj). Je peux remonter les 2 et 4 Concernant l’inversion que tu évoques il s’agit de quoi comme module, le dernier rollerShutter par hasard ? Tu as bien vérifier les paramètres du module ?

Ah mince désolé de lire ça Non pas possible depuis une sauvegarde locale.

pffff c'est moche . du coup j'imagine qu'ils la change ? NB: Il faut pas oublier de noter le numéro de série de ce HC3 pour les statistiques de @Lazer !

Yeap cela évite en effet de parcourir tous les périphériques et surtout de charger la mémoire avec des infos non nécessaires Il faut penser à l'avenir, aujourd'hui ton contrôleur est très peu chargé mais d'ici 2 ans tu tourneras peut-être avec 80 devices, des scènes et des quickapp dans tous les sens.

Si tes roulants sont tous du type rollerShutter alors je te conseil très fortement de faire un get sur /api/devices/?type=com.fibaro.rollerShutter pour des questions de performance, ce n'est pas nécessaire de remonter en mémoire tous les devices de ton installation Encore mieux, tu pourrais faire un post sur le endpoint /devices/filter et remonter uniquement les périphériques de la catégortie "blinds", mais alors bon courage pour trouver la bonne syntaxe

@couillerot tu as des nouvelles ?

Cette fonctionnalité sera très probablement réintroduite dans une prochaine version.

Le tag aujourd’hui ne sert absolument à rien, la fonctionnalité n’est pas disponible aux mortels que nous sommes [emoji2957]

Hello, non malheureusement je n’ai pas trouvé le temps mais je n’oublie pas [emoji6]

Merci pour vos retours [emoji4]

Je réfléchis depuis des mois pour me prendre le pluviomètre mais tout le monde fait le même retour, ça me refroidit ! Le module d’intérieur est top mais pour le reste bof bof ! Malheureusement il n’y a pas d’alternative crédible, si ?

[emoji53] Pas cool !

Yeap l'idée est plaisante

Il va falloir faire des Quick apps

Il n'est pas possible depuis Jeedom de paramétrer le type de requête: ? tu as par exemple GET, POST, PUT, DELETE pour les plus connues, utilisées... Sinon l'autre solution que je vois c'est de faire une requête sur une Quick APP qui se chargerai alors d’exécuter les scènes.

C'est logique, comme évoqué dans ma réponse précédente il faut passer la requête en méthode POST et non en GET, tu peux essayer depuis le SWAGGER disponible via l'interface du HC3 ou bien en utilisant POSTMAN.

https://shelly.cloud/shelly-25-wifi-smart-relay-roller-shutter-home-automation/ [emoji106]

Étrange... Si je trouve le temps en soirée [emoji6]

Oui mais moi j’aime ça [emoji12]

En plus Shelly ils ont des certifications sur leurs produits si je ne dis pas de bêtises [emoji848]

Une grande partie des informations existent bien ici https://manuals.fibaro.com/home-center-3-lua-scenes/ Dans la doc: ensuite il faut extrapoler et rétro-ingéniérer et croiser les doigts

Le GetSourceTrigger est remplacé par sourceTrigger accessible directement dans le global LUA. Voici un code qui devrait t'aider à mieux comprendre le fonctionnement, do local trigger = sourceTrigger print("property:"..trigger.property) -- ex: "centralSceneEvent", "value" etc... print("id:"..trigger.id) -- l' ID de la condition. ex: 12 print("type:"..trigger.type) -- le type déclaré dans la condition ex: "device" for key,value in pairs(trigger.value) do print(key ..": ".. value) -- toutes les valeurs déclarées lorsqu'elles existent end end ex: pour une KEYFOB Fibaro / centralSceneEvent cela devrait donner quelque chose comme cela pour capter l'appui sur la touche "rond" local trigger = sourceTrigger if (trigger.property == "centralSceneEvent") then print("id:"..trigger.id) print("type:"..trigger.type) for key,value in pairs(trigger.value) do print(key ..": ".. value) end if (trigger.value.keyId==2) then print("Circle button "..trigger.value.keyAttribute) end end Dites-moi