jjacques68

yes !! merci @Krikroff ! ça marche nickel ! Mais où as tu ces informations, elles ne sont pas renseignées dans les pages d'aide de Fibaro ?

Hello tout le mode ! On a visiblement plus le getSourceTrigger dans la HC3 du coup pour une scène qui a comme trigger ce genre de chose : { operator = "any", conditions = { { type = "device", id = 10, property = "value", operator = "==", value = true, isTrigger = true }, { type = "device", id = 12, property = "value", operator = "==", value = true, isTrigger = true } } } et qu’on cherche à savoir qui à déclenché la scène ? comment fait-on ? merciiiii !

J'ai fais comme tu dis : function QuickApp:onInit() self.sock = net.TCPSocket() self.ip = self:getVariable("IP") self.port = tonumber(self:getVariable("Port")) self:Open_Socket() end function QuickApp:Open_Socket() self.sock:connect(self.ip, self.port) self:debug("Socket open") end function QuickApp:Close_Socket() self.sock.close() self:debug("Socket close") end function QuickApp:Send(MaTrame) --affiche la trame dans le label self:updateView("LBL_Buffer", "text", tostring(MaTrame)) --envoi la trame self.sock:write(MaTrame, { success = function() self:debug("data sent") end, error = function(err) self:debug("error : "..err) self:Close_Socket() fibaro.setTimeout(5000, function() self:Open_Socket() self:Send(MaTRame) end) end }) end Le comportement est vraiment étrange : - tout est toujours ok au démarrage du QA. - mais après redémarrage du serveur TCP, pareil la 1ère trame envoyée me répond "data sent", mais je vois toujours rien ! - à la 2ème trame, j'ai l'erreur "Broken Pipe" (logique je comprends...) - et le setTimeout semble prendre après très très longtemps (plus que les 5 secondes) : j'ai le "Socket Open" qui arrive après 10 s !! - et la trame n'a pas été renvoyée étrange tout ça

Bonjour à tous, Pour ceux qui ont commencé à jouer avec la HC3, j'ai une petite question : J'ai un QA qui envoie des trames sur une socket TCP vers un serveur. ça marche avec ce code (je vois mes trames arriver sur le serveur) : function QuickApp:onInit() self:debug("onInit") self:Open_Socket() end function QuickApp:Open_Socket() self.ip = self:getVariable("IP") self.port = tonumber(self:getVariable("Port")) self.sock = net.TCPSocket() self.sock:connect(self.ip, self.port) end function QuickApp:Send(MaTrame) --affiche la trame dans le label self:updateView("LBL_Buffer", "text", tostring(MaTrame)) --envoi la trame self.sock:write(MaTrame, { success = function() self:debug("data sent") end, error = function(err) self:debug("error while sending data") self.sock:close() fibaro.sleep(200) self:Open_Socket() fibaro.sleep(200) self:Send(MaTrame) end }) end Donc en gros, J'ouvre la socket au démarrage du QA, et j'envoi la trame sur appel de la méthode Send(MaTrame) Actuellement je passe par un bouton dans le QA pour déclencher l'envoi, plus tard ce sera fait par scène, bref... le problème est pas là. Le soucis est que si le serveur TCP redémarre, je n'arrive plus à relancer la connexion depuis le QA ! malgré ces lignes : self.sock:close() fibaro.sleep(200) self:Open_Socket() fibaro.sleep(200) self:Send(MaTrame) où je ferme la précédente socket, je la ré-ouvre, et je renvoi la trame (le tout temporisé) ! Et bien au premier essai, après redémarrage du serveur TCP, il me répond que la trame a bien été envoyé. Et biensûr j'ai rien vu arriver sur le serveur. Au deuxième essai il boucle indéfiniment en me disant "error while sending data". Comment peut-on réinitialiser la socket proprement, et relancer la trame qui n'a pas pu être envoyée !! des idées ???? merciiiiiiiiiiiiii !

j’attends surtout avec impatience le bluetooth pour virer jeedom

trop fort, je pilote l'IPX depuis la HC2, et je reçois le retour d'état sur la HC3 bon je sais c'est pas vraiment le but...

j'ai rien dit !!! fallait mettre tostring dans l'affichage function QuickApp:essai(arg) self:updateView("label", "text", tostring(arg)) end et ça marche nickel ! @Krikroff @Lazer, oui j'ai la tête qui explose d'idées

alors je pense pas que ce soit un problème d'accès car je vois bien dans l'icone en haut à droite, le user créé pour l'IPX. J'ai bien accordé les droits d'accéder au QA pour ce user... mais il se passe rien... et rien dans le debug... J'utilise ça dans le message push de l'IPX : /api/callAction?deviceID=28&name=essai&arg1=1 où "essai" est : function QuickApp:essai(arg) self:updateView("label", "text", arg) end

mouai, j'ai craqué, suis entrain d'essayé, mais ça marche pô

alors je peux pas essayer maintenant, mais est ce qu'on peut appeler les méthodes de QA depuis l'extérieur ? genre depuis un IPX (V2 = pas de POST) j'ai ça dans les commande push des sortie (pour actionner un bouton d'un VD) : /api/callAction?deviceID=266&name=pressButton&arg1=1 on peut imaginer : /api/callAction?deviceID=266&name=Ma_Methode_QA&arg1=1 ????

ah, j'espère qu'ils vont corriger ça !! parce ces QA semblent être vraiment de la bombe !!! On déclare une fonction dedans, et on accède à cette fonction depuis les scènes et le passage d'arguments -----> on va économiser un paquet de VG avec ce système !! c'est nickel ça !!

allé c'est parti Pour les heureux possesseur d'une HC3, arrivez-vous à afficher les QA dans l'application Mobile ?

Ben moi ça y est je suis en plein de dedans... Viens de la recevoir...

ah ben punaise oui tu as raison ! je viens de relire les doc vite fait... et bien ça va simplifier les choses ça cool !!

ha bon ? depuis toujours ça ?

Ouuuiiii mais ! Un petit peu d’aventure ne fait pas de mal !! Envoyé de mon iPhone en utilisant Tapatalk Pro

Et ben non ! Mais je vais y aller tranquillou... Sauf si ça va comme je veux et je sens que je vais y passer des soirées, nuits, week-end entier dessus !! Envoyé de mon iPhone en utilisant Tapatalk Pro

bah ! ce doit être à cause des utilisateurs de jeedom

tien c’est étrange, le taux de rebond est pas un peu élevé ? après on peut l’interpréter de plusieurs manière...

ben on connaît pas le mask... peut être du /16

Bon alors, éteins laHC2 en restant très longtemps sur le bouton power. Attend quelques secondes. Et rallume là puis test. ça sent la pile du bios qui est vide...

je dis ça bêtement, mais : tu as essayer de taper cette adresse ip dans un navigateur ? et surtout de purger le cache du navigateur

pas de soucis, tu nous feras un retour d'expérience

oui oui, j’ai vu le setTimeout est toujours là

je n’osais pas le dire ...