yves.guern

Bonjour à tous, J'espère poster ce sujet au bon endroit et qu’il est ‘original’... Je suis sur le point de finaliser une migration de HC2 vers HC3 pour laquelle je me suis fait quelques outils sous Windows (et pas linux: Je n'assume pas 100% mon côté geek, tout en étant l'heureux propriétaire d'un Synology...). Pour commencer je vous partage le dernier né de ces outils. Depuis 8 années je viens prendre de bonnes idées sur ce site. Site tellement vaste qu’au bout d’un moment on se dit que : « si on n’a pas la réponse à la question ‘konseupoz,’ c’est qu’on n’a pas su bien la poser » (mais, objectivement, yadéfoi où le moteur de recherche du site n’aide pas…). Bref ! Je vais essayer de passer de ‘profiteur’ à ‘contributeur’ en partageant un de mes outils de développement / transfert en espérant qu’il n’existe pas déjà ailleurs et souhaitant qu’il rende directement service ou qu’il donne des idées. Au départ, j ’ai plein de QA, et j’aime bien que leurs icones en reflètent l’état. Le carton entre-ouvert avec un point d’interrogation ne me suffit généralement pas , il me rappelle trop les livraisons ‘uber-style’ jetées par-dessus la clôture. Ajoutez à cela les multilevelSwitch qui demandent 11 fichiers png chacun à chaque modification/bug. Au moins en cours de développement, vous avez dû ‘souffrir’ autant que moi de devoir recharger les icones ’chéris’ de vos QA/devices. A chaque fois, on hésite à faire des retours en arrière pour lesquels il faudra redésigner 1 par 1 les icones au travers de l’interface HC3 et, du coup, devoir modifier le code des QA juste pour quelque IDs qui ont été modifiées… Donc, en lien, je vous propose un code/script Python qui permet : Une sauvegarde/scan de toutes les ‘User’ icones utilisées par les devices de votre HC3. J’ai laissé de côté les icones de ’room’ (qui ne changent pas souvent) et les icones de ‘scene’, (paskeu les scènes je ne m’en sers plus du tout, mais c’est une autre histoire). La restauration des icônes sauvegardées dans l’opération précédente Ces deux opérations ont surtout un intérêt en cours de développement lors de retours en arrière via des ‘backup / restore’ ET SURTOUT : Un moyen de maintenir/updater/upgrader/modifier/etPlusEncore, les icones d’une QA sans en toucher le code (ou presque...). C’était le but premier de ce script, les deux autres fonctionnalités ne sont que des sous-produits de l’intention initiale. C'est en Python (3.11), ne me demandez pas trop pourquoi... Je le fait tourner sous Windows(10) mais a priori ça doit aussi le faire sous linux... Le Zip HC3IconMgr1.0.2.zip joint contient : Un (Le) code python dont il est question Un fichier json de paramètres, éditable A EDITER (via notepad++ par exemple), qui vous permet d’adapter le code à vos paramètres à vous (l’IP de votre HC3, le mot de passe et le répertoire de sauvegarde) Un ‘template’ de code LUA à insérer dans vos QAs Je termine ce post par les commentaires en tête du code python qui détaillent un peu plus ce qu’il propose. C’est en ce que j’appelle de l’anglais, en vue d’une publication sur le site ‘concurrent’ . Bonne journée! PS: J'ai fait pas mal de test mais que cela ne vous empêche pas de créer une sauvegarde avant de faire les vôtres... #___________________________________________________________________________________ # HC3IconMgr.py Backup and Restore for Home center 3 # this script allows 3 tasks: # - SAVE all icons on your PC (or any python target) in png format # - RESTORE above icons to HC3 # - LOAD sets of icons defined in one HC3's globalVariable and for QA, prepare a local variable # to be able to use icons by names not by ids # # Notes about HC3 icons: # There are in fact 3 types of icon set # simple one 'unary' that consist in only one png file # (applicable for ex to "com.fibaro.multilevelSensor") # 'binary' one that have 2 icons (one for the OFF state and one for the ON state) # (applicable for ex to "com.fibaro.binarySwitch") # 'multi' one that have 11 icons ranging from 0% to 100% in steps of 10% # (applicable for ex to "com.fibaro.multilevelSwitch") # User icon sets are internally named by HC3 under Userxxxx with xxxx = id and id > 1000. # This id is the one to give in calls: "fibaro.call(self.id, "setProperty", "deviceIcon",id)" # Considering icons on your PC they must follow the 'syntax' below: # for 'unary' set : iconFName.png # for 'binary' set : iconFName_0.png and iconFName_100.png # for 'multi ' set : iconFName_0.png, iconFName_10.png, iconFName_20.png,... and iconFName_100.png # (This is the case when you SAVE HC3 icons sets) # last point to notice about HC3 icons philosophy : # Each device type has its own icon list, you may me obliged to upload a png more than once # to different devices. # # # File organization : # SAVE saves icons under a root path defined by sBackupIconsPath in the parameters json file (see below). # this path MUST exist before application is launched!!! # under this path, directories are created, one per device type found during the HC3 scan. # During scan, at text file is created in sBackupIconsPath/getHC3Icons.log, # it lists all icon sets found and where they have been saved. # # RESTORE : # * Reads all icon sets found in sBackupIconsPath subdirs. # * Checks that all required files per set are available. # * Checks if the set is not already on the HC3 and upload acordingly. # RESTORE does not reload already existing icon set! If run twice it will not do anything the second time... # Restoring icons will most probably change ids so RESTORE produces 2 files in sBackupIconsPath:: # * RestoreHC3Icons.txt (which is like a csv file) containing the old and new icon ids with the device type. Ex: # oldId newId deviceType # 1001 1001 com.fibaro.binarySwitch # 1016 -100 com.fibaro.binarySwitch # 1021 1021 com.fibaro.binarySwitch # 1003 1003 com.fibaro.doorSensor # 1046 1046 com.fibaro.doorSensor # 1065 1065 com.fibaro.electricMeter # 1066 1066 com.fibaro.electricMeter # 1071 1047 com.fibaro.energyMeter # In this file, a negative new id means that all required files for this set were not present. # * idChanges.json a json file containing a list of changes indexed by OldId, giving newId only for ids # that have changed. Ex: {"1016": -100, "1071": 1047} # # LOAD: # * First gets what is to be done by reading the globalVariable "g_Icons2Load" from HC3. # Here is an exemple for the content of this globalVar: # {"filepath":"D:/Users/........./HomeBox/Icone/", --this is a root dir where to find icons.png # "ToLoad":[ -- this is an array to be able to load many icons for different device type # {"id":348, --this is (an) id used to dertemine device type and if it is a QA or not # "icons":[ -- list of icon set to load # {"LUAname":"QuestPac","fileRoot":"Chauffage/Poele_unknown"}, --png files will be searched in filepath/fileRoot.png or filepath/fileRoot_0.png or.. # {"LUAname":"PacOff","fileRoot":"Chauffage/Poele_off_2"}]}, --LUAname is used for QA... # {"id":123, --another id with other icons set list # "icons":[ # {"LUAname":"Name1","fileRoot":"Meteo/Rain"}, if 123 is a binarySwitch the appli will look for filepath/Meteo/Rain_0.png and filepath/Meteo/Rain_100.png # ] # } # A LUA HC3 code example to generate that variable is provided in the .zip file # * For each id found trys to upload it to HC3 (if it does not exists already) # * For ids that corresponds to a QA it produces a list indexed by 'LUAname' value giving the id # (the new one or the existing one) of the loaded icon. EX: # {"QuestPac": 1098, "PacOff": 1099, "P0M0R0E0": 1100,"P0M0R1E0": 1101} # This list is then pushed to the QA in its own variable under the name "myIconIds" # The list is UPDATED not cleared, ie old 'LUAname' are not removed. # If you want to clean 'myIconIds' remove it from the QA variables before. # Then using fibaro.call(self.id, "setProperty", "deviceIcon",myIconIds.LUAname) # you will be able to change/reload icons without modifying your code!! # # LAST : # user modifications: # this script read a json file HC3IconMgrParam for user config, it may be changed using notepad (for ex), # here is an example: # { "host": "192.168.15.17", #change to you HC3 IP address # "port": 80, # doi not change (?) # "sAuthKey": "eW---blah blah blah blah halb halb---1h", #put your authentification key , # either directly (using 'F12' key result) or using result of base64 encoding of username:password # "sBackupIconsPath": "D:/Users/yv---//----/-/Icone/CurrentBackup/" #put here the root for icons backup # } # to launch application: # I run the application under a 'power shell' console using: # "py .\HC3IconMgr.py task" with task = either save,restore or load # Note that this script produces colored messages. # For Windows python under power shell, execute once the power shell cmd : # Set-ItemProperty HKCU:\Console VirtualTerminalLevel -Type DWORD 1 (and restart the console) # It enables VT (Virtual Terminal) / ANSI escape sequences # # and, I am a NEWBEE in python some of you may cry (laugh) going through this script # please forgive me :-) # # # FOR CURIOUSITY: # Most difficult part is the syntax for uploading icon sets, because of lack of fibaro's documentation (as usual). # 1) it is not a request PUT or POST but some writes to a TCP socket # 2) format of what is to be sent through this socket was really not clear to me. # Thanks to: # a) marecki_0luk1 and its (old) AID code for HC2 # b) wireshark !!! (F12 does not help for sockets) # 3) Solution (my solution) is mainly in 'uploadOneIconSet' function for the 'encapsluation' of the data # and in 'uploadIcons' function for the payload build. #____________________________________________________________________________________ HC3IconMgr1.0.2.zip

J'ai posé mon ticket (que j'espère détaillé) en soulignant (discrètement) que ce capteur existe encore sous d'autre marques... J'ai insisté sur le fait que d'autres savent faire et que cela ne semble pas bien compliqué...

Merci Lazer, Je vois mal comment motiver Fibaro à agir pour un composant qui n'existe plus, au moins sous cette marque là. Je vais quand même essayer...

Bonjour, Je n'ai pas su trouver une réponse positive ou négative sur les 2 forum fibaro... Est-il possible d'avoir des communication bas niveau sur le réseau ZWAVE à partir de la home box? Ce dont je 'rêve' c'est ce genre de code (lua) sirenDevice:zwaveNode():sendMsg(COMMAND_CLASS_NOTIFICATION, NOTIFICATION_REPORT, list.new(0x00, 0x00, 0x00, 0x00, notification_type, notification_event, 0x00, 0x00)) mais c'est pour un stick zwave (https://github.com/telldus/tellstick-lua-examples/tree/master) pas pour du fibaro Le besoin c'est de pouvoir programmer la seconde consigne d'un thermostat AEOTEC. (Note: cette consigne n'est pas dans les paramètres de configuration). J'y arrive bien avec un dongle ZWAY en utilisant la commande http://192.168.1.xx:8083/ZWave.zway/Run/devices[9].instances[0].commandClasses[67].Set(11,19) C'est la partie en gras que j'aimerais envoyer. Notez, pour finir, que fibaro sait envoyer commandClasses[67].Set(1,18) qui programme l'autre set point à 18°... Merci pour votre aide

Hi Jang, ok that sound as somthing that explains was I get! So os.clock()-T0 only gives you the Real elapsed time if your code does not contain any sleep or posted event to wake you up... I was trying to measure response time of a TCP connection . Thanks!

Bonjour, Je cherche un moyen d'avoir des temps en ms. Je me suis donc lancé sur os.clock(). Je dois être en train de regarder le doigt alors qu'on me montre la lune ... J'ai fait 2 découvertes: la sortie de cette fonction n'est pas en ms et le coefficient multiplicateur n'est pas constant ???? voici mon code: (le setTimeout est celui de fibaroExtra mais j'ai les même résultats avec des fibaro.sleep() self.Time0=os.time() self.Clock0=os.clock() function QuickApp:main() setTimeout(function() self:main() end,1000) self.ElapsedT=os.time()-self.Time0 self.ElapsedC=os.clock()-self.Clock0 print("Time:"..self.ElapsedT,"Clock:"..self.ElapsedC,'Ratio:'..(self.ElapsedT/self.ElapsedC)) end Avec un setTimeout de 1000 ms j'ai un ratio de 385, qui est déjà une valeur curieuse... [QUICKAPP78]: Time:476 Clock:1.234036 Ratio:385.72618627009 [QUICKAPP78]: Time:477 Clock:1.236577 Ratio:385.74225462709 [QUICKAPP78]: Time:478 Clock:1.239096 Ratio:385.76510617418 [QUICKAPP78]: Time:479 Clock:1.241633 Ratio:385.78227221731 [QUICKAPP78]: Time:480 Clock:1.244157 Ratio:385.8033994102.../... Et là ou cela devient étrange c'est qu'avec un setTimeout de 10000 ms le ratio est grosso modo 10 fois plus grand: [QUICKAPP78]: Time:100 Clock:0.025572 Ratio:3910.5271390583 [QUICKAPP78]: Time:110 Clock:0.028122 Ratio:3911.5283408008 [QUICKAPP78]: Time:120 Clock:0.030621 Ratio:3918.8792005486 [QUICKAPP78]: Time:130 Clock:0.0331 Ratio:3927.4924471299.../... Mes questions sont 'donc' que mesure os.clock? une explication serait que cette horloge n'avance que si la QA n'est pas en attente d'une façon ou d'une autre? Le ratio mesuré serait alors inversement proportionnel au taux d'occupation CPU. et/ou où est mon bug? PS: J'utilise une HC3 en version 5.130.64 et elle fait autre chose que le test exposé ci dessus mais elle est très loin d'être en surcharge ( <10% de CPU moyen,37% de 'ram utilisée') Merci d'avance

Ok mon message n'est pas clair... Il tentait de faire de la publicité à deux fonctions inclues dans FibaroExtra qui permettent d'échanger des données de façon simple, avec un code lisible. L'idée c'est que la QA qui a quelque chose à dire utilise une fonction publish qui va déclencher un event dans toutes les QA qui se seront abonnées au préalable avec la fonction subscribe. Il n'y a pas besoin de connaitre l'Id des destinataires ni même leur nombre, et rien ne se passe sur le 'disque'. (cf https://forum.fibaro.com/topic/54538-fibaroextra/#comment-233510) J'utilise 'beaucoup' et cela fonctionne bien. Il faut juste que le code des QA abonnées soit compatible d'une réception asynchrone des informations. Voilà voilà

Bonsoir Lazer, Chaque fonction peut recevoir les arguments de notre choix Oui, cela c'était assez clair dans mon esprit, encore que, envoyer des paramètres à une QA c'est (presque) écrit dans la doc, en recevoir c'est beaucoup moins clair pour mes premiers pas dans HC3!!. Ce que propose 'fibaroExtra' au travers de publish/subcribe/event c'est qu'une QA (ex: un arrosage) soit au courant des toutes dernières nouvelles (ex: une météo) au moment où elle sont disponibles, sans 'efforts' et sans écriture/lecture disque. Le fait que 2 (ou plus) QAs n'aient pas besoin de connaitre leur ID pour échanger est un gros plus (et pas que en court de développement). Bref, je trouve cela 'cool' (pour le 'disque') et finalement bien dans la philosophie des QA : ie complètement asynchrones, faire avec ce qui est disponible à To est plus efficace qu'attendre To+x un retour d'erreur... Et Dieu sait que mon passé de systèmes temps réel et mon cerveau ont du mal avec l’asynchrone . Bonne soirée

Bonsoir Lazer, la communication inter-QuickApps peut se faire directement par passage d'arguments lors d'appels d'une fonction Tu parles bien des publish/subscribe (et des events) de jgab (https://forum.fibaro.com/topic/54538-fibaroextra/) Ou il y a qqchose de mieux que je n'ai pas encore trouvé? Merci

Bonjour Lazer, Ton idée est la bonne... J'ai détourné le handler des parametres de configuration du module Z-wave et il n'écrit plus dans l'eeprom pour certaine adresses. Plus aucun remords.... PS : qui mériterais peut-être un nouveau sujet, à propos d'usure: Sur quoi sont sauvegardés les variables globales (et celles des QAs) ? Sur mon HC2 j'avais pris l'habitude de réécrire le moins possible les variables globales préférant utiliser les 'ui' (logtemp par ex) pour échanger entre VD et entre VD et scènes. J'ai vu parfois dans ce site (et l'officiel) des codes qui échangent 'à haute cadence' des données par variables globales, cela me chiffonne... Bonne journée

Merci à vous deux! @lazer: je suis déçu de ne pas avoir vu une zwaveInterfaceTime dans la liste ... @jojo: Le redémarrage de la box ne donne rien. La reconfiguration douce est douce mais reste un process lourd que je ne me vois pas effectuer sur une base régulière, j'ai peut être tort? Je teste depuis 48h l'utilisation d'un paramètre de configuration pour transmettre l'heure unix. Cela fonctionne plutôt bien. Finalement à part que cela use l'eeprom cela me semble une solution viable (et pérenne). Bonne soirée.

Merci Lazer, Yes! I will ask the official one. Mais bon, je suis en train de lentement changer mon fusil d'épaule pour utiliser un paramètres de configuration... Au passage, cela est mon dernier espoir, dans les devices du home Center 3 il y a un champ interfaces qui contient une liste un peu mystérieuse, on a l'impression que cela pourrait définir une liste d'UI dans l'IHM web? Quelqu'un connait la liste des interfaces possibles? A+

Bonjour, J'utilise des modules Z-Wave 'intelligents' Z-uno2 (à base d'arduino pour faire court). Ils sont équipés d'un composant RTC que j'aurais besoin de mettre à l'heure. Au moment de l'inclusion d'un module dans le réseau Z-wave du HC3 cela fonctionne, et le RTC est mis à l'heure de la HC3 par une Command Class Time Parameters (0x8B/139). Mon problème est que cette information ne semble envoyée par la HC3 que au moment de l'inclusion : Si le module est reseté ou redémarre après une perte de puissance, la mise à jour de l'heure ne se fait pas. Question: comment forcer HC3 à envoyer cette 'Command Class' ? Le sujet est pointu, je vous remercie par avance!

Bonjour à tous, Je ne suis probablement pas au bon endroit, mais: Je m'attaque douououcement au portage de HC2 vers HC3. J'aurais voulu commencer par faire la Maj du firmware, et à vous lire je m'étais dis que la 120 c'était bien. Mon interface HC3 ne me propose que 130.64 ou 132.9. Il y a-t-il un moyen de récupérer/installer d'autres version? Merci d'avance

Bonsoir à tous, Le topic initial est ancien mais j'en ai eu un vrai besoin et j'ai essayé de faire quelque chose d'équivalent avec les défauts signalés en moins, en particulier la capacité de logger des messages rapprochés de façon la moins intrusive/plus transparente possible pour le code 'envoyeur'... C'est ma première contribution à ce forum, dont j'ai abondamment profité, c'est mon premier retour. J'espère bénéficier de votre indulgence, au moins sur la forme. (quand j'y pense :j'espère ne pas avoir réinventé ici l'eau tiède d'un autre post?) Et, en attendant : Bonne Année à tous Le post initial reste valide et une base solide. Les différences sont: # il n'y a pas (plus) besoins de scène complémentaire à la VD. # La VD utilise TCP plutôt que UDP pour côser au syno (c'est donc à modifier dans le paramétrage des journaux de synology, cf 1er post de ce sujet, c'est la seule modification de ce côté). Pourquoi?: UDP n'est pas fait pour ASSURER la réception d'un message et encore moins la date de réception et encore moins l'ordre de réception. C'est fait pour émettre un flux sans se poser de question sur la réception. TCP c'est le contraire :-) # L'idée est de stocker rapidement les message à envoyer dans une pile (FIFO) pour pouvoir s'assurer d'avoir tous les messages à envoyer # Les messages empilés sont dépilés par bloc toutes les 3s (c'est la seule solution que j'ai trouvée pour ne pas avoir de conflit read/write, mais je suis à l'écoute..) Vu de l'extérieur: Les messages à envoyer sont json.encodés dans le champ 'logTemp' de la VD puis 'empilés' en appuyant sur le bouton 'Empil' (voir plus bas code à ajouter), le reste se passe tout seul : Ils sont dépilés régulièrement (tte les 3s): # vers le NAS si leur niveau de sévérité est égal ou dépasse ce qui est indiqué dans le label 'MinLevel', # poubellisés sinon. Le Label MinLevel peut être changé en cliquant sur les bouton '+' ou '-'. Cela permet de moduler la charge des journaux selon que l'on est en train de tester quelque chose ou non... Le bouton 'reset' est au fond un bouton de debug. Mais il est recommandé d'appuyer dessus avant de tenter d'envoyer un 1er log. La 'nouvelle' VD se présente ainsi: pour envoyer quelque chose au journal, la base est d'ajouter dans la scène/VD où cela est nécessaire le code suivant : local vd_id = 175 -- id de VI_SynoLog (à remplacer................) msg={sev = "warning", Time=os.time(), orig= "Test Syslog Message", mess = "Text for a warning"} --évidemment à ajuster au besoin, selon toute logique orig devrait permettre d'identifier la scène ou la VD qui émet le message. fibaro:call(vd_id, "setProperty", "logTemp", json.encode(msg)) --La VD utilise intensivement les 'champs' log et logTemp, ne pas les utiliser à autre chose SVP fibaro:call(vd_id, "pressButton", 1) (voir plus loin pour les pb de synchro) Ce code 'empile' le message (daté de son heure propre, pas de l'heure d'émission vers le synology) il sera envoyé un peu plus tard, mais il s'agit d'un journal! (journal finalement lu plus tard histoire de comprendre les 'scoops' dont on a été informé par ailleurs :-) on n'est pas sur BFM!) La pile contient 10 messages (10 message/3secondes) Il est très simple d'augmenter ou diminuer cette dose dans le code associé au bouton 1 Le label 'In' est le nombre de message empilés, le label 'Out' est le nombre de messages envoyés vers le synology (ou filtrés vers la poubelle par 'MinLevel'). Si les deux valeurs sont égales c'est que tout a été traité. Si In est < Out cékia1bug!!! "plus loin pour les pb de synchro" c'est ici: Pour les puristes ou ceux qui pensent avoir à envoyer plein de log importants à leur NAS je recommande: local vd_id = 175 -- id number of VI_SynoLog (à remplacer................) Time= os.time() while ((fibaro:getValue(vd_id, "logTemp") ~= "") and (os.difftime(os.time(),Time) < 2)) do fibaro:sleep(100) end msg={sev = "warning", Time=os.time(), orig= "Test Syslog Message", mess = "Text for a warning"} fibaro:call(vd_id, "setProperty", "logTemp", json.encode(msg) fibaro:call(vd_id, "pressButton", 1) Les très puristes pourraient ajouter un if ((fibaro:getValue(vd_id, "logTemp") ~= "") avant d'appuyer sur le bouton, dans la pratique les choses vont tellement vite mon brave monsieur... Dans mon cas j'ai intégré ces lignes dans un code générique d’encapsulation de fibaro:debug, activé si une variable 'severity' est non nulle Installation: charger le vfib (sur une HC2 :-)), Renseigner IP du NAS et Port (514), cliquer sur le bouton 'Reset', envoyer un message de test (le plus simple est de copier un des codes ci dessus dans une scène test) PS1: en cours de fonctionnement le label 'Data' contient le dernier lot de messages envoyés, cela permet de se faire, par sondage, une idée de la nécessité d'augmenter la taille de la fifo. PS2: J'ai forcé le champ 'host' à HC2 dans dans le bouton 'Send' (2). Rien n’empêche de modifier... PS3: 'évidement' ce qui est json.encodé par l’émetteur doit être intelligible par ce qui est lu en appuyant sur le bouton 'Send'... Mais le fait de d'encoder json garanti que le reste est étanche aux modifications J'ai decouvert 2 bug (lecture de l'IP et timeout pas efficace). c'est corrigé par cette version 0.2 VI_SynoLog0.2.vfib

Bonjour, Yves, 57 ans, Ingénieur (beaucoup d'informatique). Je me suis lancé dans la HC2 il y a déjà six mois (c'est donc une présentation tardive ) pour quelques automatismes "de base": mise en route (et extinction) automatique de la hotte aspirante dans la cuisine allumage extinction de la lumière dans le cellier et la cave gestion de vérins d'ouverture de porte ,... Je suis en train de faire passer l'arrosage du jardin sous contrôle de la HC2 en utilisant les données d'une station météo... Mes impressions Très déçu: de ne pas pouvoir écrire de plugins des capacités pratiques HTTP très limitées dans les scènes une documentation très dispersée "over the web" Mais: c'est quand même puissant agréablement surpris par la stabilité du fonctionnement, (bien sûr une fois que l'on est venu à bout des bugs que l'on a écrit ) Un très grand merci à ce site, et à ses animateurs! PS:J'ai également une IPX800