jluc2808

oui c'est ce que j'ai fait, j'ai eu une réponse pour demande de connexion du support et faire le ménage dans la DB j'ai vu qu'ils avaient fait un backup hier soir, ce qui m'a fait perdre une partie des modifs qui ont été réalisées pendant ou après le backup , j'ai là aussi demandé des explications et j'attends le grand nettoyage, parce que il me reste plus de 40 modules fantômes et c'est vraiment pas simple de m'y retrouver parce que j'ai repris les même noms pour simplifier le lien avec HomeAssistant je vais voir aujourd'hui la suite Maintenant pour ma migration, j'arrive au bout (jour 4) - dans un premier temps, en test unitaire je ne note pas de latence, autre que celle qu'on constate avec des modules au lieu des inters, mais ça semble être de l'ordre du 0.1s voir moins. - je constate ancussi que les éclairages avec starter réagissent moins bien que avec un inter direct. - constat sur le changement de couleur des anneaux le système réagit et permet de changer la couleur des anneaux des walli controller, via des scénarios qui sont associés aux lampes qu'ils pilotent (lampe allumées / éteintes) sauf que, il y a toujours un mais, le module walli (controller ou autre) a un acquitement en vert allumé de l'ordre donné, donc lorsqu'on appui sur le bouton, si l'ordre est correctement interprété et transmis on a un allumage en vert au bout de quelques centièmes / dixièmes de secondes qui allume puis éteint l'anneau. Ceci perturbe très fortement les scénarios, puisque dans le scénario si éclairage allumé je mets le retroéclairage + la couleur et là si cette séquence se déroule plus vite que l'acquitement , alors l'anneau clignote puis passe en rétroéclairage off. ce qui fait que ça devient pas stable et que la fonction de j'éclaire l'anneau (ou le bout d'anneau) en vert quand la lampe est allumée est lui même instable . je teste une solution qui consiste a dire que le déclencheur (lampe allumée ou éteinte) doit l'être pendant 2 secondes , pour que la fonction rétroéclairage et couleur anneau s'execute, je vais voir si ça bypass le pb .

non je n'ai pas réinitialisé la box, juste un réinit de Zwave, je ne voulais pas tout perdre avec les quickApp, scénarios LUA, plugin , user, remote user, droits , ..... j'ai procédé par un exclude de chaque noeud , OK avec ack au vert, (de tout manière cette étape est obligatoire même en réinitialisant la box) puis un include qui me donne un autre item une fois réalisé et reparamétré avec les bons nom, je voulais supprimer les entités orphelines qui restent puisque plus accrochée à un module zwave (réinit du réseau) ce que je trouve bizarre, c'est que pour certaines ça fonctionne , la suppression se fait correctement, mais pas pour d'autres, a priori sans liens entre elle, ni du même type. je précise que des items créés avec des FGS223 pour certains le process de delete est OK, mais pas pour d'autres. j'ai pas trouvé de logique du pourquoi ça marche et pourquoi non. sur mes 165 devices, j'ai pu en supprimer environ 80, j'en ai 15 récalcitrante, les autres ne sont pas encore traitées.

bon , ça y est j'ai débuté ma migration j'ai opté pour une réinitialisation zwave ==> OK ensuite j'ai repris mes modules - 1 exclusion : OK - 2 inclusion en mode non sécurisé : OK - 3 paramétrage des noms , type , pièces , .... : OK maintenant je me retrouve avec les anciens ID toujours présents (voir copie d'écran) lorsque je veux faire un delete : j'ai le message suivant dans la console en bout de course tous mes anciens modules sont toujours là même après un reboot de la HC3 ce qui perturbe la lecture et l'usage NUKI comment je peux m'en débarrasser

ok merci pour tes explications , donc à priori pas de sujet de ce côté edit: et pas de module bavard qui inonderait le réseau, le seul qui a une activité plus importante que les autres, est le module de captation/déclencheur de la luminosité extérieur, qui le matin et le soir envoi une série d'info toutes les minutes pour donner la nouvelle valeur en lux de la luminosité, ce dont j'ai besoin pour pouvoir gérer l'automate de la lumière sur seuil dans l'escalier extérieur (mais comme c'est toutes les minutes ça ne me semble pas se mettre dans la partie inondation !) .

oui ce que tu dis est parfaitement compréhensible , je pensais que la case à cocher dans la configuration de la HC3 pour chaque module était un moyen de faire dialoguer le module et le gestionnaire z-wave pour demander au module de ne pas envoyer de rapport du tout. Par ailleurs dans les paramètres HC3 pourr le walli controller il n'y a aucun paramètre qui permet de régler les envois de rapport non sollicité par le gestionnaire réseau, donc ceux déclenchés par le module j'ai l'impression que ces modules (walli controller) sont paramétrés en dur pour envoyer un rapport (dont la température) avec un seuil de delta ou / et avec une récurrence toutes les xx minutes. Je constate ces envois avec ne nouveau z-wave monitor pour tous les modules interrupteurs walli controller. Il faut que je regarde dans la doc parce que je crois me souvenir qu'il y a une séquence avec le bouton (et les couleurs des anneaux) dans laquelle on modifie ces rapports, même si c'est spécifié que cela est pour les modules qui sont sur batterie. Je vais fouiller de ce côté edit : je viens de regarder dans la doc : https://manuals.fibaro.com/wp-content/uploads/2024/07/FGWCEU-201-T-EN-f1.2-15.07.24.pdf plusieurs choses ne me semblent pas claires : indicator CC : je n'ai pas compris - 1 quoi ça sert , 2 comment on le modifie , 3 si la valeur pour la partie température est modifiable ?

pour ceux que ça branche je viens de faire un monitoring sur quelques heures et je m'aperçois que mes interrupteurs "walli controller" sur secteur (24v) qui ont un capteur de température intégré , remontent périodiquement la température alors que dans le paramétrage Z-wave dans l'onglet avancé j'ai désactivé tout pour cet Id du périphérique: - appareil masqué - appareil desactivé - Appareil exclu de l'interrogation et enregistrer dans l'historique n'est pas coché

bonjour, je commence ici un nouveau fil pour ouvrir les échanges au sujet d'un portage de HC2 vers HC3 du programme qui permet de monitorer Z-wave le fil de discussion est sur le forum anglais : https://forum.fibaro.com/files/file/184-z-wave-monitor/?do=findComment&comment=897 et les instructions de fonctionnement sont dans le 1er post : https://forum.fibaro.com/files/file/184-z-wave-monitor/ version courante : V3.2.1 installation: (rudimentaire) Téléchargement 1 - téléchargez les 2 programmes .lua Traitement du fichier Z-wave Viewer 2 - ouvrir le fichier Z-wave Viewer-vx.x.x.lua dans 1 éditeur (par exemple Notepas++) 3 - copier le contenu dans le presse-papier 4 - ouvrir un nouveau scénario LUA ==> nom suggéré "Z-wave Viewer" mais vous pouvez mettre ce que vous voulez 5 - copier (copier/coller) le contenu du fichier Z-wave Viewer-vx.x.x.lua dans la partie "ACTIONS" 6 - sauvegardez et notez l' Id du nouveau scénario ainsi créé Traitement du fichier Z-wave Monitor 7 - ouvrir le fichier Z-wave Monitor vx.x.x.lua dans 1 éditeur (par exemple Notepad++) et changez la valeur dans les variables d'entête de viewer_sceneId=322 par l'Id que vous avez noter pour le scénario "Z-wave Viewer" 8 - sauvegardez et copier le contenu dans le presse-papier 9 - ouvrir un nouveau scénario en mode LUA ==> nom suggéré "Z-wave Monitor" mais vous pouvez lui donner le nom que vous voulez 10 - coller le contenu du presse-papier dans la partie ACTIONS 11 - sauvegardez notez l'Id du scénario Lanceur Z-wave Monitor 12 - ouvrir un nouveau scénario en mode Block ==> nom suggéré "Lanceur Z-wave Monitor" mais vous pouvez lui donner le nom que vous voulez 13 - dans la partie "Puis faites" sélectionnez sur la gauche Scénario et coller dans "Puis faites" sélectionner "Z-wave Monitor" 14 - sauvegardez Variable globale (nota: les variables globales du système ne se créées pas automatiquement - ou alors je n'ai pas trouvé) 15 - aller dans paramètres/général/variables 16 - créer une variable standard avec le nom zwave_"Id-du-scénario-Z-wave Monitor" (sous la forme zwave_318) NB: si vous changez de scénario il faudra mettre à jour le nom de la variable globale ou en créer une autre avec le bon nom Voilà c'est terminer pour la partie installation Exécution: lancer le scénario "Lanceur Z-wave Monitor" Voir les résultats dans la console Les fonctions de lancement du viewer et d'arrêt du monitor sont intégrés dans les restitutions de la console NB: - à chaque nouvelle version du Monitor, il faudra mettre à jour la variable viewer_sceneId et il suffira de copier coller le contenu du fichier vx.x.x dans le scénario "Z-wave Monitor" , sauvegarder, arrêter le scénario et le relancer - à chaque nouvelle version du Viewer, il suffira de copier coller le contenu du fichier vx.x.x dans le scénario "Z-wave Monitor" , sauvegarder, arrêter le scénario et le relancer Z-wave Monitor-v3.2.1.lua Z-wave Viewer_v3.2.1.lua

j'ai très rapidement fait un portage sur HC3 des 2 programmes c'est basique et on a les résultats sous la console mais a ce stade les progs ne plantent plus vous trouverez les 2 progs : https://forum.fibaro.com/files/file/184-z-wave-monitor/?do=findComment&comment=897 @Lazer lorsque je regarde le monitor (tel qu'il est maintenant dans la console) j'ai énormément d'events de type "transfert OK" , est-ce normal ?

la page PHP pour le maillage est ici : @Lazersinon tu as un lien vers la scène HC2 pour voir l'activité, je suis preneur pour regarder si je ne peux pas la reprendre en PHP pour la mettre sur HC3

@jojo comme l'a dit @Lazer la fonction qu'il a proposé est équivalente à celle que tu listes et est aussi simple d'usage, donc comme ça fait le job je l'ai utilisé ma contribution avec ce LUA porte sur le complément autour de cette récupération de l'IP public, cad de stocker le résultat de la requête et le comparer périodiquement à un nouvel appel pour transférer par mail le nouvel IP s'il a changé

en bout de course j'ai simplifié pas mal ton script et j'ai opté pour 3 fonctions - 1 variable globale qui reste et est consultable y compris en dehors des scripts / scènes ==> stored_ip (à créer 1 fois au début à la main) - 1 scène en LUA qui fait les appels pour aller chercher l'IP public courante de la HC3 ==> pas de récurrence et se lance sans condition ni déclencheur, 1 email fixe à changer au début dans les variables locales (pour faire simple c'est l'Id du user. - 1 scène qui n'a pour objectif que de déclencher le lancement de la scène au dessus ==> ça permet de mettre ce que l'on veut comme récurrence L'objectif : - être informé du changement et de la valeur de l'IP public de votre box (orange ou autre) et stocker l'adresse IP dans la HC3 (cela nécessite que la box internet héberge la HC3 sur le même LAN ou un autre mais que l'accès à internet de la HC3 passe par cette box) Le fonctionnement : - lancer via un scénario UI le programme LUA qui va chercher l'adresse IP public - envoyer une notification par mail - stocker la nouvelle valeur. l'installation: 1- créer une variable globale du nom de "stored_ip" la mettre à "" 2 - importer le LUA dans 1 scène vide LUA dans la partie action - copier/coller 3 - aller chercher l'Id du user que vous voulez voir notifier par email lors des changements d'IP public de la box internet qui héberge la HC3 4 - affecter directement dans le LUA la valeur numérique de l'id à la variable locale "id" 5 - sauvegardez 6 - test avec un lancement direct de la scène ==> contrôle de la reception du mail avec la valeur de l'IP public 7 - créer 1 scène via l'interface UI des scénarios, mettre dans les déclencheurs celui que vous voulez , j'ai mis un déclencheur temps à 11h00 (tous les jours) et dans les actions le lancement de la scène LUA créée pour aller chercher IP public Scene Check Public IP Address v1.0.lua

d'abord merci pour ce partage (je suis exactement dans la situation que tu décris, box orange qui change d'IP quand elle reboot) ouahh c'est chiadé ta scène !! quelques questions pour être certains de bien comprendre toutes les variables dans User variables sont en dur ? si oui tu récupères les infos ou ? -- User variables local URL = "http://ip-api.com/json/?fields=country,countryCode,region,regionName,city,zip,isp,org,as,reverse,mobile,query,status,message" local conditions = { ["mobile"] = {equal = true}, ["org"] = {match = "Mobile"}, ["reverse"] = {nomatch = "subs.proxad.net"}, -- lfbn -- LFbn } local intervalle = 60 local userID = {"Christophe"} -- Mail notification local smartphoneID = { -- Push notification "Google Pixel 5", "Google Pixel C", } local sms = { -- SMS notification ["VD_ID"] = 99, -- Virtual Device ID ["VD_Button"] = "1", -- Virtual Device Button ["VG_Name"] = "SMS" -- Global Variable Name } le Check(intervalle) c'est 60 quoi secondes / minutes /heures ? pour le tester j'aurais besoin de changer quoi à minima ?

bonjour , je ne sais pas si ça existe, mais je souhaiterais récupérer l'adresse IP public du LAN qui héberge la HC3 et envoyer un mail à chaque fois que cette adresse change. est-ce que ça existe ? ou comment je peux faire pour réaliser ce module ? merci d'avance

tous les modules sont des fibaro

@jojo ça a été mon premier réflexe, j'ai mis de la temporisation entre chaque ordre, puis j'ai mis une tempo à la fin pour reprendre les mêmes ordres avec 2 minutes d'attente, mais même comme cela j'ai encore quelques loupés