jjacques68

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

bon allé, je click...

What's new: Backup Sorting backups by creation date. Block Scenes New block in Time category - Date range. Hints for blocks in the form of tooltips for what they are used for. Removed hidden devices from the drop-down lists. Conditions and actions for FIBARO RGBW 2 device (FGRGBW-442). Conditions and actions for FIBARO Intercom device (FGIC-001). Conditions (zones, inputs, outputs) and actions (zones, outputs) for Satel Alarm plugin. Climate Changed the default mode from Auto to Heating for manually added climate zones. Dashboard Drag and drop the device to the room name on the left to move it there. Icon indicating alarm status in the header with a redirection to list of zones. Current thermostat mode displayed on the device tile. Control of thermostat type devices from the right sidebar. Control of colorController type devices from the right sidebar. More possibilities to control rollerShutter type devices from the right sidebar. Changed the ON/OFF switch from toggle switch to 2-buttons switch on the right sidebar. Displaying alarm zones to which the sensor belongs and their states on the right sidebar. Closing the right sidebar by clicking outside its area. Devices Input/output mode configuration for FIBARO RGBW device (FGRGBWM-441). Protection against adding an existing or pending association. Changed range and precision of offset for value measured by temperature sensor. Favourite roller blind position configurable from device settings. Displaying parameter values greater than 999 with additional space. Possibility to force polling for device with switched off polling interface. More effective navigation through device list using the tabulator. Notification from heatDetector and rainDetector devices available for activation. Console log for requesting neighbours when adding a Z-Wave device. Support of excluding from climate panel for a specified time for all types of thermostats. Support for MCOHome MH7H-EH and MH7H-WH version 2.7. Support for MCOHome MH8-FC and MH8-FC4 version 3.2. Support for MCOHome MH9-CO2-WA and MH9-CO2-WD version 2.4. Support for MCOHome MH10-PM2.5-WA and MH10-PM2.5-WD version 2.3. Support for MCOHome MH-F500 version 1.2. Support for MCOHome MH-3900 version 1.9. Support for MCOHome MH-3928 version 1.3. Support for MCOHome MH7-WB version 4.2. Support for MCOHome A8-9 version 6.2. Support for Aeotec Siren 6 and Doorbell 6 version 1.4. Support for Aeotec Heavy Duty Switch version 3.28. Support for HeatIt Push2, Push4, Push8 version 1.26. Sound Switch CC support. General Report of current system configuration generated as a printout. History Marking today's date in the calendar (also applies to notifications). Lua Scenes New 'duration' condition - time in seconds for which the device has not changed state. New 'anyValue' operator - any change of device value. Notifications Displaying notifications of backup and update errors. Other Brand new console/debugger, common for Z-Wave communication, scenes and Quick Apps. Searching by the name of entry in the console. Filtering entries in the console by selected tag and/or type. Full-screen view of the console available as a separate page. Notifications in toasts during the addition/deletion/configuration of Z-Wave devices. Unified display of slider values within the interface. Protection against user access to unconfigured gateway. Changed LED indication on the gateway after adding/deleting a Z-Wave device. Improved stability of Wi-Fi connection. Completing and improving translations. Plugins Improved configuration of Philips Hue plugin. Added button for reloading configuration of Satel Alarm plugin keeping unchanged IDs. Profiles Removed hidden devices and hidden scenes from the list. Added manual mode of climate zones control. Quick Apps Added MQTT client support. Possibility to create slave devices. Editing code of controls in main device editor. Conversion of added Quick Apps to new format (migrating controls to separate functions). Documentation - https://manuals.fibaro.com/home-center-3-quick-apps Marketplace - https://marketplace.fibaro.com/items?kind=quick_app Scenes Activity of the run button depending on scene restart settings. Toast notification when trying to restart a running scene. Sorting scenes by name or type. Bug fixes: Alarm Scene protected from running during the alarm is performed. Block Scenes Role of the rollerShutter does not affect the list of available actions. Using the Sunrise/sunset block prevents the scene from saving. Calendar is displayed in wrong place and does not fit the screen. Redundant fields in FIBARO Intercom device blocks. Condition of running a scene using Satel Alarm disappears after reloading the page. Push notifications are always sent to all users instead of selected ones. Cameras IP camera image preview is visible in the interface from the Installer App. Climate Setpoint is not applied to a device without support for Auto mode. Activating manual or vacation mode always sets a zone in Auto mode. Unified sets of temperature colours in climate panel and displayed on thermostat icon. Dashboard Order of rooms in the list does not match the order from settings. Icon of the colorController type device is displayed incorrectly. Devices Device list does not always load after refreshing the page. FIBARO Heat Controller (FGT-001) does not support Off and FullPower modes. Inconsistent display of thermostats on the main screen and in device settings. Incorrect parameters after changing the role or key type of FIBARO RGBW device. Interface does not load after migration from HC2/HCL due to no support of some thermostats. History Linked device state change is not displayed on the list. Lua Scenes No support for fibaro.getDevicesID function. Network Access Point switches off by itself after several hours. Other LED state on the gateway does not change during addition/deletion of Z-Wave device. Drop-down list does not close and overlaps when another one is being opened. Unified content and appearance of e-mails sent from the gateway. Quick Apps Modified Quick App view is not saved. No support of special characters and emojis in Quick App view. No view update in device edit window after using self:updateView. Double checkbox section in device Advanced tab. Scenes Incorrect operation of reporting unsaved changes. No window for entering PIN code when trying to run a PIN-protected scene.

Je dois certainement m'y prendre mal, pourtant j'ai l'impression de faire les choses bien... mais ça marche pas... J'ai l'impression que api.delete ne fonctionne pas : voici le code : la VG DelayVmc est une table en fait : [{"API":{"timestamp":1586419043,"id":130},"VMC":226}] où on retrouve l'ID de la VMC ainsi que les infos nécessaires pour l'API. --récupère le contenu de la VG ListeDelay = fibaro.getGlobalVariable("DelayVmc") ListeDelay = json.decode(ListeDelay) --supprime un(ou les) précédent delay si trouve for index,value in pairs(ListeDelay) do if value.VMC == v.id then --v.id vient d'une boucle plus haut dans le code, et contient l'ID de la VMC res = api.delete(string.format("/devices/action/%s/%s",value.API.timestamp,value.API.id)) print(json.encode(res)) table.remove(ListeDelay, index) end end --mémorise la VG modifiée ListeDelay = json.encode(ListeDelay) fibaro.setGlobalVariable("DelayVmc", ListeDelay) pas de message d'erreur, rien, ... Les valeurs dans la VG sont tout a fait cohérente Mais l'enregistrement du OFF n'est pas supprimée, la VMC s'éteint au bout du temps définit lors du premier OFF si quelqu'un a une idée ?

mouai c’est ce que je craignais... bon ben ok... va pour cette solution... merci !!