jjacques68

et bien c'est nickel !!! juste dommage que les caméras ne peuvent pas bouger plus vite... suis déjà au max avec la vitesse... Mais niveau réactivité de la BOX (déclenchement d'une scène par les PIR, envoi de la requete HTTP pour faire bouger la caméra (à travers un QA) ...) , y a rien a dire !!

ça marche nickel ce code !!! merci encore !!!

Je sais pas faudra que j'essaye... après concernant les "Lignes", faut dire aussi, que je récupère par exemple toute les 3 secondes les infos d'un ECO-DEVICE et la nuit quand l'alarme tourne c'est une trame par seconde que je récupère... Sans parlé de l'échange que j'ai entre l'IHM perso et la box.... Tout ça, sont des "lignes" qui ne sont pas de la communication Z-Wave... Pour le moment je ne constate pas latence dans les device Z-Wave... Au contraire, elle est plutôt réactive ! Mais justement, je fais tester en créant un "mode poursuite" avec les caméra. j'avais essayé sur la HC2, ça marchait, mais alors le temps que tu passes d'un PIR à un autre, la camera avait pas encore bougée on verra...

alors avec le status des device, je dépasse les 100 000 lignes en 24 heures !!! c'est dingue comme ça travaille dans cette petite boite ! J'ai mis des filtres en place, sinon j'explose la base. Surtout que certaines infos n'étaient absolument pas utiles... Par contre en analysant les données, y a des trucs étranges... je sais pas si ça vient de ma programmation (sans doute), faut que je regarde de plus près. Par exemple : - des méthodes lancées sans raisons ???? en moyenne toutes les 30 minutes (j'ai aucun souvenir d'avoir programmé ça !!) - lors de l'allumage/extinction d'une lumières (et que les lumières) j'ai une double saisie dans l'historique (mais ce n'est pas visible dans la page "History", que dans l'API). Et j'ai bien 2 ID différent dans l'API pour ce doublon d'informations (ça vient pas de mon système...)

j'y suis parvenu avec panels/event...

Hello ! j'étais intéressé de pouvoir récupérer l'historique de ce qu'il se passe avec nos device. Ce que l'on peut voir dans la page "history". L'objectif final est de sauvegarder tout ça dans une base de données externe à la HC3... bref. donc voici dans un QA la méthode que j'utilise pour récupérer les données de l'API : Le principe est que je cherche toutes les X minutes le contenu. (pour le moment le déclenchement est manuel, il faut que je réfléchisse à l'interval de bouclage...) J'utilise une variable au QA "TimeStart" qui contient le TimeStamp de fin de la dernière recherche. Par précaution, je vérifie que l'interval de recherche ne soit pas supérieur (pour le moment) à 1 h. Si c'est le cas, je force donc à 1 heure max. --------------------------------------------------------------------------------------- -- CHERCHE LES DONNEES --------------------------------------------------------------------------------------- function QuickApp:CheckLogs() local TimeStart = tonumber(self:getVariable("TimeStart")) local TimeEnd = os.time() local http = net.HTTPClient({timeout=3000}) --Pour ne pas récupérer plus de x temps de log (cas d'un plantage, arrêt, autre...) if os.difftime(TimeEnd, TimeStart) > 3600 then TimeStart = TimeEnd - 3600 end print("<<<<<<<<<<<< start : "..os.date("%d/%m/%Y %H:%M:%S", TimeStart).." - end : "..os.date("%d/%m/%Y %H:%M:%S", TimeEnd).." >>>>>>>>>>>>") http:request("http://127.0.0.1:11111/api/panels/event?type=time&from="..TimeStart.."&to="..TimeEnd, { options = { method = "GET" }, success = function(res) Display(res.data) end, error = function(error) print(json.encode(error)) end }) --mémorise l'heure de fin pour qu'elle soit la procaine heure de début self:setVariable("TimeStart", tostring(TimeEnd)) end et voici comment je sors les données avec la fonction Display() : --------------------------------------------------------------------------------------- -- TRAITEMENT DU RESULTAT --------------------------------------------------------------------------------------- local function Display(alldata) --formate le tableau json alldata = json.decode(alldata) --pour chaque élément du tableau for k,v in pairs(alldata) do --chope le nom du device local NameDevice = api.get("/devices/"..v.deviceID).name --créé la trame local Message = v.type.." - "..os.date("%d/%m/%Y %H:%M:%S", v.timestamp).." - "..v.deviceID.." - "..NameDevice.." - "..tostring(v.event.data.newValue) print(Message) end end Pour le moment je ne fait que un print du résultat, mais celui-ci sera envoyé en base de donnée... (pas voulu en parler dans ce sujet). le résultat dans le debug donne ça : on obtient donc, le type d’événement (DEVICE_EVENT), son Timecode, l'ID du device, son nom et pour finir sa valeur. d'autres information son dispo dans l'API, mais pour le moment, celles-ci me suffisent... Je lance actuellement le process manuellement pas un bouton, mais je vais mettre un bouclage par setTimeout en place, afin de le faire boucler régulièrement.

hello tout le monde ! est ce quelqu’un sait comment éteindre le chauffage ? j’ai beau mettre la zone sur "off" elle continue sa programmation !!

nan mais je peux enventuellement mettre des filtres... A voir dans le temps... prochaine étape, l'historique des device....

en fait l'historique est très faible, si on souhaite voir si y a eu des erreurs il y a quelques heures, c'est mort !!! on les retrouve plus !!

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 !!