jjacques68

alors j'ai fini par y arriver ! mais je comprends pas pourquoi cela ne marche pas : res = api.delete(string.format("/devices/action/%d/%d",timestamp,id)) print(json.encode(res)) ----> réponse : nil mais ça c'est ok : local http = net.HTTPClient({ timeout = 20000 }) http:request(string.format("http://127.0.0.1:11111/api/devices/action/%d/%d",timestamp,id), { options = { method = "DELETE", }, success = function(status) print(status.status) end, error = function(error) print(status.status) end }) -----> réponse : 200 (ou 404 si inexistant) comme décrit dans l'API ???????

si tu fais allusion a l’histoire de la redondance dans le debug, c’est pas ce self:debug qui en est à l’origine... C’est que pour afficher ce qui viendrait éventuellement du serveur.

car cette socket est utilisée par d’autre QA également non, mais le simple fait d’appeler une méthode, ajoute systématiquement une ligne (pour tous les QA d’ailleurs) Et comme l’argument que je passe n’est ni plus ni point que le debug lui-même, ça fait de la redondance... Je sais pas si je me fais comprendre...

ouah !! plus de 20 000 enregistrements en 7 heures !! hé bé... ça travaille sévère la dedans...

suite et j'espère fin de cette histoire de socket : alors d'après mes analyses, il faut bien faire attention, lors des erreurs de lecture, écriture ou autre, à l'emplacement de l'instruction qui rappelle le "connect". Chose qui avant, n'était pas bien le cas. Du moins le côté asynchrone des fonctions TCP et des setTimeout fait vite perdre le nord... Donc voici le code complet qui fonctionne visiblement très bien. Tant pour la connexion, que la reconnexion (provenant d'une coupure côté serveur ou côté HC3), stable et répétitif. Je rappelle que le principe de base est d'avoir une socket ouverte vers un dispositif, en permanence. De pouvoir faire les READ (de manière à détecter la déconnexion côté serveur). Et bien sûr du WRITE (du côté client - HC3). Afin de faciliter la gestion ainsi que le risque de perdre des données lors des méthodes de reconnexion, j'utilise un tableau "tampon" qui est rempli par la méthode "AddElement" pouvant être appelée de n'importe où. L'élément ainsi ajouté, est placé en fin du tableau. L'élément envoyé par le WRITE sera le 1er élément du tableau et sera supprimé après l'envoi (FIFO). Une petite sécurité lors du remplissage de ce tableau, car si la socket ne repart pas rapidement (pour x raisons), ce tableau peut, très très vite, être énorme. Dans mon cas, j'ai fixé à 500 le nombre max de données dans le tableau. Après, le 501 ajouté, supprimera le 1er, ainsi de suite... --------------------------------------------------------------------------------------- -- INIT : -- - Le status du QA = le status de la socket (true/false) --------------------------------------------------------------------------------------- function QuickApp:onInit() __TAG = "QA_"..plugin.mainDeviceId.."_Display Soft" self:debug("onInit") self:updateProperty("value", false) --par défaut le QA = false self.ip = self:getVariable("IP") self.port = tonumber(self:getVariable("Port")) self:updateView("LBL_IP", "text", "-----> "..tostring(self.ip)) self.ListElement = {} self.sock = net.TCPSocket() self:CloseSocket() --fait un CLOSE self:OpenSocket() --lance le OPEN end --------------------------------------------------------------------------------------- -- OPEN --------------------------------------------------------------------------------------- function QuickApp:OpenSocket() --insert une première valeur qui sera envoyée par le SEND après le OPEN table.insert(self.ListElement, "open test") --fait le OPEN (connect) self.sock:connect(self.ip, self.port, { success = function() self:updateProperty("value", true) --passe le QA donc la socket à true self:debug("OPEN - connected") self:send() --lance le SEND self:waitForResponseFunction() --lance le READ end, error = function(err) self:CloseSocket() QuickApp:warning("OPEN ERROR - "..err) fibaro.setTimeout(3000, function() self:OpenSocket() end) --relance le OPEN toutes les 3 secondes end }) end --------------------------------------------------------------------------------------- -- CLOSE : par défaut, passe le QA donc la socket à false --------------------------------------------------------------------------------------- function QuickApp:CloseSocket() self.sock:close() self:updateProperty("value", false) end --------------------------------------------------------------------------------------- -- READ : permet de choper les déconnexion du serveur --------------------------------------------------------------------------------------- function QuickApp:waitForResponseFunction() self.sock:read({ success = function(data) self:debug("RX - "..data) self:waitForResponseFunction() end, error = function(err) QuickApp:warning("READ ERROR - "..err) self:CloseSocket() fibaro.setTimeout(1000, function() self:OpenSocket() end) end }) end --------------------------------------------------------------------------------------- -- WRITE : tourne en boucle tant que QA = true --------------------------------------------------------------------------------------- function QuickApp:send() --si socket OK if fibaro.getValue(plugin.mainDeviceId,"value") == true then --si element dans tableau if self.ListElement[1] then --write self.sock:write(self.ListElement[1].."\r", { success = function() table.remove(self.ListElement,1) end, error = function(err) self:updateProperty("value", false) --redondance de cette instruction car déjà présente dans CloseSocket. Mais c'est pour être sûr que le temps de cycle ne joue pas de mauvais tour... QuickApp:warning("WRITE ERROR - "..err) self:CloseSocket() fibaro.setTimeout(1000, function() self:OpenSocket() end) --relance le OPEN end }) end --et bouclage : ATTENTION A BIEN LE PLACER ICI ! sinon cela entraine un double appel (asynchrone) et ça devient un bordel sans nom !!!! fibaro.setTimeout(10, function() self:send() end) end end --------------------------------------------------------------------------------------- -- ADD ELEMENT --------------------------------------------------------------------------------------- function QuickApp:AddElement(element) if element ~= "" then table.insert(self.ListElement,element) if #self.ListElement > 500 then table.remove(self.ListElement, 1) print("purge", #self.ListElement) end end end et donc pour envoyer quelque chose : fibaro.call(ID_du_QA, "AddElement", "TESTS SOCKET")

Ce call est une méthode d'un QA qui me permet d'envoyer la trame sur la socket. Même principe que l'on avait déjà abordé, j'ai un buffer pour faire du FIFO... histoire de pas perdre de trames... Donc le "AddElement" permet de remplir le buffer. le flag "LOG" me permet, dans le soft qui reçoit les données, d'identifier justement la trame. Je peux en avoir une autre, comme par exemple : je mémorise le compteur d'eau journalier avec la trame "EAU;123456789". Donc selon le flag, j'enregistre les données dans telle ou telle base de données. J'ai une socket pour remplir plusieurs bases (du moins 2 pour le moment). Pour info, notre histoire de socket précédente, portait sur un autre système, avec un autre logiciel, avec une autre socket, qui est que de l'IHM pur... Pas tout mélanger quand même Et je rencontre le même problème pour les 2 sockets... mais : oui tout à fait, je vais encore faire des essais et je reviendrais sur le bon topic

Bon ben voilà : function QuickApp:Check() --recupère les data de l'API local MonContenu = api.get("/debugMessages").messages --pour chaque ligne local MaData = "" for index, MaLigne in pairs(MonContenu) do --créé la chaine MaData = os.date("%d/%m/%Y %H:%M:%S", MaLigne.timestamp)..";".. MaLigne.id..";".. MaLigne.type..";".. MaLigne.tag..";".. json.encode(MaLigne.message) --l'envoie en base fibaro.call(487,"AddElement", "LOG;"..MaData) end --purge l'API que après le traitement sinon il y a redondance d'informations --car chaque ajout en base met une trace dans le debug... api.delete("/debugMessages") --relance que si le QA est activé if fibaro.getValue(plugin.mainDeviceId, "value") == true then fibaro.setTimeout(tonumber(self.TimeLoop)*1000, function() self:Check() end) end end c'est nickel !! Je range tout en base : rien à voir... Mais j'ai toujours et encore de soucis avec les sockets !! Toujours ce problème de reconnexion !! C'est pas clair ! et pas normal !! Suis obligé de relancer le QA quand ça arrive !

bon je m’y mets

c’est dommage on a pas le changement de status des device...

ben c’est pas mal ça ! on peut lire, et supprimer ! roaaa, le clavier va chauffer oui en effet !!

ah punaise ! si !! dans l’api, il y a : debugMessage...

ben déjà sur la HC2 j’avais mis en place un système, mais fais maison, donc dans chaque VD et scène. j’avais une instruction qui me permettais d’envoyer ce que je voulais dans une base HFSQL (windev). ça passait via une socket sur un petit soft installé sur un PC, qui ajoutait tout ce que je voulais en base. c’était « mon » historique quoi ! et j’avoue que je m’en suis servi plus d’une fois pour retrouver ce qu’il s’est passé...

ben, nativement je m'en doute Mais y a bien une table dans l'API que l'on pourrait checker toutes les X temps, et envoyer les data sur une socket pour y être stocker en base... Mais je vois pas ça dans l'API

oui je confirme... en même temps ça défile pas mal !! mais y aurait-il un moyen d'intercepter n'importe quel ajout dans le debug, pour peut-être le stocker dans une base de donnée annexe ?

ça veut dire quoi ça ? parce que je ne sais toujours pas comment passer une zone en vacation ou en OFF !!!!

je confirme, par exemple pour une action sur le changement d'un WallPug : { operator = "any", conditions = { {type = "device", id = 433, property = "value", operator = "anyValue", isTrigger = true} } } alors qu'avant c'était : { operator = "any", conditions = { {type = "device", id = 433, property = "value", operator = "==", value = true, isTrigger = true} {type = "device", id = 433, property = "value", operator = "==", value = false, isTrigger = true} } } et bien ça va alléger certaines scènes ça !!

rien à voir avec IFTTT ? sais pas pourquoi, quand je relis, je pense à ça !

ok d’accord, je comprends mieux, et arrive mieux à imaginer les possibilités ... oui en effet ça devient intéressant !!

j’ai fais une rapide recherche sur ce MQTT, mais j’avoue ne pas trop comprendre, et ne connais pas les cas d’usages... vous avez des exemples d’usages ?

ah oui,tout à fait, il a ajouté le code des objets dans le main. mais j’ai mal lu, je croyais que l’on pouvait changé le type du QA, mais non ... du moins pas encore...

ben j’ai,pas trouver comment convertir un QA... mais c’est peut-être que pour les nouveaux créés à partir de cette version !

et bien plutôt oui ! bon y a encore du boulo, mais c’est déjà une bonne première mise à jour !

donc si je comprends bien, en plus des : ==, >=, <=, !=, ... on a maintenant le "anyValue" ? si c’est ça c’est parfait pour les true/false... encore rien dans la doc...

sais pas, suis pas encore là

bon RAS. NICKEL le debug !!!