
jjacques68
Membres confirmés-
Compteur de contenus
4 364 -
Inscription
-
Dernière visite
-
Jours gagnés
39
Tout ce qui a été posté par jjacques68
-
bon c'est fait, c'était pas la mort à faire... ça à l'air ok. mais je suis sceptique sur l'appel de la méthode "send", que j'ai peut-être trop souvent inséré dans le code... si tu as 5 minutes, peux tu y jeter un oeil ? merciiii ! --------------------------------------------------------------------------------------- -- 12/03/2020 - V1 : permet d'envoyer les infos des device vers Display Soft -- 19/03/2020 - V2 : utilise un tableau pour faire du FIFO --------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------- function QuickApp:onInit() self:debug("onInit") self:setVariable("Status", "0") self:updateProperty("value", false) self.ip = self:getVariable("IP") self.port = tonumber(self:getVariable("Port")) self.sock = net.TCPSocket() self.ListElement = {} self:connect() end --------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------- function QuickApp:connect() self.sock:connect(self.ip, self.port, { success = function() self:setVariable("Status", "1") self:updateProperty("value", true) self:debug("OPEN - connected") self:waitForResponseFunction() self:send() end, error = function(err) self:setVariable("Status", "0") self.sock:close() self:debug("OPEN ERROR - "..err) fibaro.setTimeout(500, function() self:connect() end) end, }) end --------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------- function QuickApp:close() self.sock:close() self:updateProperty("value", false) end --------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------- function QuickApp:waitForResponseFunction() self.sock:read({ success = function(data) self:debug("RX - "..data) self:waitForResponseFunction() end, error = function(err) self:setVariable("Status", "0") self:debug("READ ERROR - "..err) self.sock:close() fibaro.setTimeout(200, function() self:connect() end) end }) end --------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------- function QuickApp:send() if self:getVariable("Status") == "1" then if self.ListElement[1] then self.sock:write(self.ListElement[1].."\r", { success = function() table.remove(self.ListElement,1) if #self.ListElement > 0 then self:send() end end, error = function(err) self:setVariable("Status", "0") self:debug("WRITE ERROR - "..err) self.sock:close() fibaro.setTimeout(200, function() self:connect() end) end }) end end end --------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------- function QuickApp:AddElement(element) if element ~= "" then table.insert(self.ListElement,element) self:send() end end
-
oui j'ai compris. bon ben y a plus cas.
-
une VG avec les data séparées par un séparateur ? tant que la VG est <> "" on traite un par un ? La scène n'envoie pas directement sur la socket, mais rempli cette VG ? (super... en lua ... )
-
@Krikroff tu avais raison, c'est la commande "read" qui permet de détecter une déconnexion : "End of file". La reconnexion est donc quasi immédiate (1 seconde max). sauf que si une commande write est envoyée pendant ce temps, c'est la merde total. pas réussi à empêcher d'une manière propre le "write" si plus de connexion. la seule chose qui me fait qqch de stable, c'est : d'avoir créé une variable "Status" dans le QA, qui prend 1 ou 0 selon le status de la socket. Alors attention, surtout pas passer la variable à 0 dans la méthode "close". ça prend trop de temps de traitement. Il faut la mettre à 0 dès qu'on intercepte l'erreur. je teste, avant de faire le "write", le status de cette variable. si 1 j'envoie, si 0 j'envoie pas, le paquet est perdu ! j'ai essayé de mettre, juste avant la commande write: while self:getVariable("Status") == 0 do fibaro.sleep(100) end mais dans le cas où Status = 0, le QA se fige, pas de crash, pas d'erreur, rien ! Dommage ça m'aurait évité de perdre des paquets... punaise, j'utilise des sockets partout au boulo entre les automates et des PC pour récupérer des données !! jamais vu ça !! Voici le code, si qqun a une solution !! je suis preneur ! function QuickApp:onInit() self:setVariable("Status", "0") self:debug("onInit") self.ip = "192.168.2.8" self.port = tonumber("2000") self.sock = net.TCPSocket() self:connect() end function QuickApp:connect() self.sock:connect(self.ip, self.port, { success = function() self:setVariable("Status", "1") self:debug("OPEN - connected") self:waitForResponseFunction() end, error = function(err) self:setVariable("Status", "0") self.sock:close() self:debug("OPEN ERROR - "..err) fibaro.setTimeout(2000, function() self:connect() end) end, }) end function QuickApp:close() self.sock:close() end function QuickApp:waitForResponseFunction() self.sock:read({ success = function(data) self:debug("RX - "..data) self:waitForResponseFunction() end, error = function(err) self:setVariable("Status", "0") self:debug("READ ERROR - "..err) self.sock:close() fibaro.setTimeout(200, function() self:connect() end) end }) end function QuickApp:send(strToSend) if self:getVariable("Status") == "1" then self.sock:write(strToSend.."\n", { success = function() --self:debug("TX - "..strToSend) end, error = function(err) self:setVariable("Status", "0") self:debug("WRITE ERROR - "..err) self.sock:close() fibaro.setTimeout(200, function() self:connect() end) end }) end end
-
idem en passant par une VG
-
bon ben mon principe de sémaphore ne fonctionne pas. Manque de réactivité entre le changement d'état du QA et la scène...
-
alors : je pense avoir identifié le problème : j'ai une scène qui m'envoie tous les "value" des device sur la socket. en gros, pour chaque device, elle appelle la méthode "send" du QA. Si au premier appelle, j'ai un soucis de socket, celle-ci va donc se reconnecter. MAIS ! la scène ne réfléchit pas elle ! elle continuer d'envoyer les "value", donc de faire des "send" alors que le premier est encore entrain d'essayer d'ouvrir la socket ! le deuxième va faire de même ! ça me met un bordel terrible ! en même temps, dis comme ça, ça semble tout à fait logique et cohérant. Donc il faut que je trouve le moyen de mettre la scène en pause tant que la socket n'est pas OK. Je vais essayer de prendre la propriété "value" du QA (qui est à false si pas de socket) pour faire une sorte de sémaphore pour la scène...
-
ben moi j'inclus tous mes modules sans passer par un logiciel. Il faut que tu trouves l'adresse IP de la HC3, et tu te rends sur sa page via un navigateur. à ben voilà, c'est ce que viens de dire @mprinfo y a peut-être le logiciel Fibaro Finder qui peut t'aider à trouver l'IP... (je sais plus s'il s'appele comme ça.)
-
punaise là ça m’énerve. demain je recommence à 0. vais créé un nouveau QA et je vais utiliser le soft packetsender pour essayer de comprendre pas à pas ce qu’il se passe. mais j’ai un sérieux doute sur la gestion des socket.
-
tout à fait, c’est ce que la fonction est censée faire; mais j’ai un doute.
-
ben c’est ce que me retourne la fonction read. après je sais pas si c’est le debug, ou un message de la socket
-
attention je l’ai pas mis juste après le write, elle est en "thread" dans une fonction à côté. elle tourne dans son coin.
-
parce qu’elle me fait perdre toute stabilité de la socket. je parle pas de la reconnexion là, je parle bien quand tout est (normalement ok) elle me retourne "opération annulée". j’ai l’impression qu’on peu pas lire et écrire simultanément, comme dans leur exemple.
-
elle bug leur instruction read.
-
j'ai viré les sleep et remplacé par des setTimeout pour la reconnexion... y en a 3 maintenant (dans les 2 write et dans la boucle de read) c'est un bordel inimaginable (plein de deconnexion/reconnexion et des paquets qui manquent...) function QuickApp:onInit() self.sock = net.TCPSocket({timeout = 2000}) 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,{ success = function() self:debug("Socket opened") self.socketClosed = false self:updateProperty("value", true) self:waitForResponseFunction() end, error = function(err) self:debug("error opening socket : ",err) self.sock:close() self.socketClosed = true self:updateProperty("value", false) end }) end ---------------------------------------------------------------- function QuickApp:Close_Socket() self.sock:close() self.socketClosed = true self:debug("Socket closed") self:updateProperty("value", false) end ---------------------------------------------------------------- function QuickApp:waitForResponseFunction() self.sock:read({ -- reading a data package from the socket success = function(data) self:debug("From Server - "..data) -- handling of received data self:waitForResponseFunction() -- looping of data readout end, error = function(err) -- a function that will be called in case of an error when trying to receive data, e.g. disconnecting a socket self:debug("response error - "..err) self.sock:close() -- socket closed fibaro.setTimeout(5000, function() self:Open_Socket() end) -- re-connection attempt (every 5s) end }) end --------------------------------------------------------------- function QuickApp:Send(MaTrame) --reconnect if closed if self.socketClosed == true then fibaro.setTimeout(3000, function() self:Open_Socket() end) end --affiche la trame dans le label self:updateView("LBL_Buffer", "text", tostring(MaTrame)) --envoi la première trame d'essai self.sock:write("\n", { success = function() --self:debug("First send = OK") --envoi la data self.sock:write(MaTrame.."\n", { success = function() --self:debug("Data send = OK") end, error = function(err) self:debug("error sending data : "..err) self:Close_Socket() fibaro.setTimeout(3000, function() self:Send(MaTrame) end) end }) end, error = function(err) self:debug("error sending first : "..err) self:Close_Socket() fibaro.setTimeout(3000, function() self:Send(MaTrame) end) end }) end Je comprends même plus l'ordre des messages qui s'affichent dans le debug
-
alors je viens de faire une petite expérience : j'ai ajouté la fonction function QuickApp:waitForResponseFunction() self.sock:read({ -- reading a data package from the socket success = function(data) self:debug("From Server - "..data) -- handling of received data self:waitForResponseFunction() -- looping of data readout end, error = function(err) -- a function that will be called in case of an error when trying to receive data, e.g. disconnecting a socket self:debug("response error - "..err) self.sock:close() -- socket closed fibaro.setTimeout(5000, function() self:Open_Socket() end) -- re-connection attempt (every 5s) end }) end et bien j'ai comme réponse : quand y en a une : [DEBUG] 18.03.2020 21:47:37: response error - Operation canceled et ça tourne en boucle, donc j'ai visiblement des erreurs venant du serveur... mais y a aucune raisons !!!
-
ah mais dans leur exemple ils font une lecture continue ! faudrait pouvoir arriver à intercepter le résultat de cette fonction après le write, genre dans une variable locale... nan c’est pas le top... ton idée serait de faire ce read dans le success du write... et que si on détecte un message du serveur genre un close, on ré ouvre Mais bon sang, il devrait le faire tout seul ça ! désolé je réfléchi à voix haute
-
ben j’étais entrain de cogiter dessus, ajouter un self.sock:read() dans le write... ça fait beaucoup d’instruction asynchrone qui s’imbriquent... je suis entrain de lire pour la 100ème fois l’exemple sur le site de fibaro, je comprends bien la méthode read, mais j’ai du mal à comprendre comment l’intégrer !
-
ben je suis d’accord, c’est la solution du pauvre... mais c’est pas possible de pas pouvoir stabiliser ce truc, sur la HC2 c’était impec !
-
tiens en disant ça ! c’est nul, mais j’ai constaté que quand le QA crash, il redémarre au bout de 3 - 4 secondes... pourquoi pas provoquer un crash du QA en cas de perte de connexion ! roah j’ai honte de dire ça
-
si on pouvait réinitialiser le QA en cas de perte de connexion...
-
tu ne constates pas la même chose de ton côté ?
-
J'ai rien programmé comme réponses sur le serveur... du coup j'ai pas besoin de traité les read().
-
j'ai viré les sleep... ça change rien... [DEBUG] 18.03.2020 20:14:19: First send = OK [DEBUG] 18.03.2020 20:14:19: error sending data : Broken pipe [DEBUG] 18.03.2020 20:14:19: Socket closed [DEBUG] 18.03.2020 20:14:20: error sending first : Bad file descriptor [DEBUG] 18.03.2020 20:14:20: Socket closed [DEBUG] 18.03.2020 20:14:20: error opening socket : Operation canceled [DEBUG] 18.03.2020 20:14:20: error sending first : Bad file descriptor ...
-
J'ai l'impression que l'instruction close() ne libère pas les ressources correctement...