Krikroff

Hum [emoji848] le socket doit mal gérer la déconnection. Tu as essayer sans faire le close ? Juste rejouer le send toutes les 5 secondes jusqu’à livraison. Si le QA plante il faudrait penser à faire le sens dans un pcall pour protéger le qa du plantage.

Une bonne solution serait peut-être de trouver un HCLite d’occasion, c’est facilement trouvable pour moins de 100€ [emoji4]

Quel est le contrôleur utilisé ?

Carrément je confirme ça également mais ici il me semble que la pile est neuve... enfin ça vaudrait peut-être le coup de la vérifier, une pile HS sortie du blister surtout sur ces références [emoji18] c’est du déjà vu !

Quelques remarques: 1. Il faut placer de préférence l’instanciation du socket dans le onInit ainsi que le nécessaire pour la configuration / paramétrage soit function QuickApp:onInit() self.sock = net.TCPSocket() self.ip = self:getVariable("IP") self.port = tonumber(self:getVariable("Port")) end 2. Ajouter une méthode Close_Socket() dans le QuickApp function QuickApp:Close_Socket() self.sock:close() end 3. La méthode Open_Socket ne devrait servir qu'a l'ouverture du socket + trace etc... function QuickApp:Open_Socket() self:debug("open socket") self.sock:connect(self.ip, self.port) end 4. Utiliser de préférence setTimeout (non bloquant) à la place de fibaro.sleep(xxx) car net.TCPSocket est asynchrone... soit remplacer les lignes self.sock:close() fibaro.sleep(200) self:Open_Socket() fibaro.sleep(200) self:Send(MaTrame) PAR self.Close_Socket() -- socket closed fibaro.setTimeout(5000, function() self:Open_Socket() self:Send(MaTrame) end) -- re-connection attempt (every 5s) 5. Ne pas hésiter à restituer le message d'erreur retourné comme ceci self:debug("connection error:", message) Je n'ai rien testé mais cela permettra de mieux identifier par la suite les points bloquants

A mon avis il faut envisager de passer en méthode POST de la manière suivante: http://ADMIN:xxxxxx@192.168.0.xxx/api/scenes/9/execute avec dans le body à minima: {} et si tu souhaites passer des arguments il faut alors un payload du genre: {"args": {}} Dis-moi si cela fonctionne

Faut que je regarde ça mais la dernière fois j’avais un module avec les piles H.S

Welcome on board

Voilà une question intéressante [emoji848] tu penses à la pièce en plastique sortie de son orifice ?

J’espère que tu es rodé [emoji1696] @Nico sinon nous n’avons pas fini d’en entendre parler [emoji23]

Lol oui Intercom + HC3 c’est un budget !!! Chouette pour la démo [emoji4]@Nico mets le paquet [emoji51]

L’installation ultime [emoji848][emoji1787]

Attention cette action est irréversible [emoji4] et scènes et VD à recréer sur HC3 car pas de migration pour ça. Bien que l’option proposée par Fibaro semble fonctionner très bien[emoji108]je reste quand même persuadé qu’il est préférable de faire une migration manuellement côte à côte

Oui tu m’étonnes !

Oui parfaitement ! Imaginons un QA de type "Multilevel switch" avec un ID 946 et les méthodes suivantes: QuickApp:turnOff() QuickApp:turnOn() QuickApp:setMode(mode) QuickApp:wakeUpDeadDevice() Les requêtes seront: En GET api/callAction?deviceID=946&name=turnOff api/callAction?deviceID=946&name=turnOn api/callAction?deviceID=946&name=setMode&arg1=Confort api/callAction?deviceID=944&name=setValue&arg1=90 api/callAction?deviceID=946&name=wakeUpDeadDevice En POST api/devices/944/action/turnOn body : {"args": []} api/devices/944/action/turnOff body : {"args": []} api/devices/944/action/setMode body: {"args": [ "{ 1 }" ]} api/devices/944/action/setValue body: {"args": [ "{ 90 }" ]} api/devices/944/action/wakeUpDeadDevice body : {"args": []} La possibilité également d'executer la demande avec retard ex ici 10 secondes avant l’exécution : api/devices/944/action/setValue body: {"args": [ "{ 90 }" ], "delay": 10} Tu me diras si cela fonctionne sinon je suis bon pour revoir ma copie du Quick APP Fil Pilote

C'est ça, nous sommes pas loin des plugins utilisateurs proposés à l'épode brièvement sur HC2

Il en reste encore, ils ont dû recevoir une palette entière [emoji1787]

Quand tu évoques alerte c’est quoi son état exactement dans l’interface ?

Surtout que tout ne semble pas totalement supporté sur HC3, ex avec les centralSceneEvent et des keyAttribute non supportés pour certains périphériques un exemple parmi d’autres

Comme dit, exclusion avant tout [emoji51]

C’est un problème connu, en fonction du type il y a des choses qui remontent mais de toute manière seul la tuile est accessible (ex on/off pour un binary) mais pas les boutons, sliders et labels ... Malheureusement !

Bonsoir, Une exclusion du module avant et réalisée si possible proche du contrôleur.

Tout est imaginable mais pas certain de l’intérêt, il faut comprendre le nouveau principe [emoji848]

Pas pour défendre Fibaro mais l’option bug du contrôleur me semble plus vraisemblable

Les poignets bougent encore bien mais ils font du surplace sur scène [emoji2957]