Lazer

Je n'ai pas essayé avec le FGK, mais oui je pense que ça doit fonctionner.

ahah trop fort

Ma RAM s'est stabilisée. Bon finalement j'ai fait le dernier test, qui consiste à forcer la valeur de mon dimmer mort ressuscité. Donc avec l'API, je force la value à 50 par exemple et il se produit tout ceci : - le dimmer se met à 50% dans l'interface - la consommation est automatiquement calculée en fonction de la valeur déclarée dans les paramètres du module (affichée sous le module dans l'interface) - le panneau de consommation se met à jour en temps réel - un trigger est déclenché dans ma scène de test - et surtout : aucune erreur car la HC2 sait que le dimmer est mort, donc elle n'essaye même pas de le joindre pour lui envoyer sa nouvelle valeur => conséquence : pas de message "transfert failed" sous le module, sous LInux dans le log du moteur Z-Wave on voit qu'elle n'a pas tenté de joindre le module, et dans le log du HCServer, on ne voit que des messages propres qui résument les actions que j'ai précisé dans les points ci-dessus); Donc pour moi c'est super propre => On crée volontairement des modules morts, on les ressuscite, et non seulement on peut mettre à jour leurs paramètres d'état, mais également les piloter. Dis autrement, on a des Physical Virtual Sensor, et des Physical VIrtual Swichs. Krikroff peut aller se recoucher (je rigole bien sur je suis bien incapable d'écrire un plugin) (cette histoire de Virtual Physical est aussi tordu que les Beta Stables ) Next step : jouer avec un FGRM mort, et enfin pouvoir piloter mes Velux nativement dans l'interface HC2 Et ensuite, après une batterie de tests approfondis, viendra le tuto général. EDIT : bon en fait, pour le pilotage natif depuis l'interface de la HC2, ça ne semble pas fonctionner. L'interface Web fait un appel différent, et elle force la communication Z-Wave, qui échoue forcément, donc le mode ne change pas d'état. Dommage, ça veut dire qu'on est encore obligé de passer par un VD pour cliquer sur ses boutons

essaye d'installer un package qui doit s'appeler "php-mysql" ou quelque chose dans le genre.

Pour info voici ce qui se passe si on essaye de changer l'unité d'un module : [Error] [#1] LOADER [Device::setProperty] deviceId=<463> propertyName=<unit> device property doesn't exist, update ignored Donc dans ce cas précis, il est intelligent et t'envoie gentiment balader (et je précise que je n'ai pas tenté cette expérience, c'est lui tout seul qui essaye de changer l'unité, va comprendre pourquoi.... seul les dévs Fibaro ont la réponse, .... ou pas)

ah j'ai pas essayé avec le FGBS. Mais attention : les manipulations présentées ici (forcer la statut d'un module via l'API) ne fonctionnent que pour un module qui n'a pas de valeur (les fameux modules enfants inactifs du Qubino, ou des nœuds morts ressuscités). Donc si tu essayes de forcer le statut d'un FGBS vivant, il est probable que la valeur soit immédiatement remplacée par la vraie valeur du module (surtout pour un FGBS, qui écoute le réseau, donc la HC2 peut aller l'interroger immédiatement pour vérifier sa vraie valeur, et ainsi détecter la supercherie)

Hum j'ai la RAM qui monte en flèche.... je vais me calmer un peu et voir si ça se stabilise ou si je suis allé trop loin....

Nico va lire le topic FHEM, tu peux juste inclure des FGBS, des FGK, etc, et les mourir volontairement pour en avoir autant que tu veux, juste avec 1 seul module physique. Je suis persuadé que ça fonctionnera longtemps.

Pour te dire, j'ai un noeud mort depuis 2 ans dans ma DB Et il est toujours là , vaillant, je viens de le "démourir" et de jouer avec l'API Aucun risque de suppression, il n'y a pas de champ disant depuis combien de temps un noeud est mort, et ça serait trop risqué pour Fibaro de supprimer des modules de façon arbitraire (souviens toi des premières migrations v4.....)

Tu risques surtout de corrompre la DB avec ça ! Au mieux, il est intelligent et il vérifie les paramètres que tu lui demandes de changer. Hier j'en ai testé quelques uns et il me jetait (en allant fouiller dans les logs en root, je voyais des messages disant que les paramètres n'étaient pas reconnus) Bon courage pour ta migration !

Alors la dernière étape : Prenez un module mort, décocher la case "marquer comme mort" dans les propriétés du module. La HC2 essaye de la joindre, échoue, mais ne le marque pas comme mort. Et maintenant on peut lui updater ses propriétés. Je viens d'essayer avec un Dimmer sur lequel j'ai changé la valeur de consommation power. Avec le graph qui se mettait à jour en temps réel dans la panneau de consommation !!!!!! Je vais vous la faire autrement pour que ma pensée soit plus claire : - on inclue un module (du type qu'on souhaite (consommation, température, détecteur, etc)) - on le reset (via appui long sur le bouton, selon la méthode décrite dans la doc) sans l'exclure de la HC2 - il passe en noeud mort - en décoche la case 'marquer comme mort' => le module ne sera plus jamais mort, même si il n'existe plus - en peut l'utiliser à vie pour updater ses propriétés via l'API - Puis on recommande la procédure décrite ci-dessus autant de fois qu'on souhaite, afin d'avoir une infinité de modules, qui remplacent parfaitement les plugins. C'est pas génial ? Reste à voir sur la durée si il n'y a pas d'effet de bord à jouer ainsi avec des noeuds morts. Bon maintenant j'ai encore un autre test à faire.......

@Nico c'est plus qu'une propriété, un module d'un type donné a plusieurs paramètres dans les tables de la DB. Bref il faut oublier la transformation, et rester dans du standard, afin de ne pas avoir de problème (surtout lors des mises àjour de firmware, car il y a des scripts qui nettoient la DB, cf les plugins)

Exactement, le but ce n'est pas de transformer un module existant, mais juste d'utiliser les modules existants qui sont inutilisés. Et ce Qubino est génial car il nous crée des modules de Température et 3 Détecteurs, qu'on peut utiliser àloisir grâce àma méthode

exactement : un VD qui transforme les GET en PUT Un truc dans le genre : local value = 20 -- Ici il faut réussir à lire la données depuis l'URL.... je pense que le plus simple doit passer par la mise à jour d'une variable globale via l'API. local ID = 339 -- ID du module à mettre à jour local HC2 = Net.FHttp("127.0.0.1", 11111) local data = '{"properties":{"value":'..value..'}}' HC2:PUT("/api/devices/"..tostring(ID), data)

Ahahah j'aime ma box Humidité OK Fastoche => Tu prends un ST814, et depuis la v4 tu as du remarquer qu'il y a 2 modules de Hum et 2 de Temp. Donc tu peux utiliser ceux qui ne servent à rien car il restent toujours à 0. Je viens de tester ça fonctionne. C'est juste énorme Bon la suite maintenant, si ça fonctionne ça sera le summum .... à suivre

Je suis en 4.080 Attention, le pressButton que tu montres, c'est du GET. Là il faut faire du PUT, je ne sais pas si Zibase sait faire ça ? Sinon comme tu dis, passerelle intermédiaire. En fait non, tu cliques sur le bouton du VD (avec pressbutton en GET), et c'est le LUA du bouton qui fait le PUT (avec un Net.FHttp classique)

Oui une commande PUT via l'API ça suffit Tout simple ! J'utilise curl dans l'exemple ci-dessus pour effectuer les requêtes PUT

Nico t'as tout compris je vais ouvrir un topic dédié, mais j'attends de faire des tests complémentaires, mais si ça fonctionne ça ira encore plus loin que ce que j'ai présenté ci-dessus. J'y travaille....

tout àcommencé par le module Qubino Fil Pilote

mouarf, quelque chose me dit que cette serrure n'est pas prêt de s'ouvrir (tentative de jeu de mot.... ) aux autres solutions domotiques.

Héhé cool Tiens tu devrais aller jeter un oeil au topic FHEM, il y a quelque chose qui pourrait t'intéresser toi qui a une Zibase et qui attend les plugins en vain.

@Nico : oui ESXi c'est une sacré techno, ils ont bien réussi leur coup chez VMware.... il y a peu de clients qui arrivent à résister. @Shad : même pour une bonne bière bien fraiche du Nord tu ne viendrais pas ?

Lien vers la suite de la configuration détournée de ce module sur le topic FHEM.

Ceci fait suite au message porté dans le topic Qubino Fil Pilote. Alors pour mettre à jour la température, cela fonctionne bien chez moi : define TempCuisine notify EnOcean_Sensor_Cuisine.* { my $temp = ReadingsVal("EnOcean_Sensor_Cuisine","temperature", "");; system("curl --silent --output \'/dev/null\' --request PUT --data \'{\"properties\":{\"value\":$temp}}\' --user admin:xxxxx http://192.168.1.1/api/devices/339 &");; } J'en ai déjà 3 comme ça. Aucun problème à signaler depuis hier soir. Evidemment, les Noms, IP, Device ID, etc sont à adapter à votre propre config. Dans ces exemples j'ai uniquement partagé la ligne de "notification", qui doit être associée à un module EnOcean (ou autre...) déjà configuré dans FHEM. Attention, on est obligé d'utiliser le compte admin, car j'ai essayé avec un autre compte qui avait les droits sur le module, sans succès. Et pour les contacts d'ouverture, cela fonctionne : define porte_cellier_open notify EnOcean_Contact_Cellier:open { system("curl --silent --output \'/dev/null\' --request PUT --user admin:xxxxx --data \'{\"properties\":{\"value\":true}}\' http://192.168.1.1/api/devices/340 &");; } define porte_cellier_close notify EnOcean_Contact_Cellier:closed { system("curl --silent --output \'/dev/null\' --request PUT --user admin:xxxxx --data \'{\"properties\":{\"value\":false}}\' http://192.168.1.1/api/devices/340 &");; } J'en ai 2 comme ça depuis ce midi, et ça fonctionne. Attention cependant, même en l'absence de changement d'état (température identique, ou porte qui reste fermée), les modules EnOcean (Nodon et Tryo2Sys) envoient à intervalle régulier leur statut. Donc cela déclenche une notification FHEM qui vient mettre à jour la HC2 via son API. Et par conséquent, cela déclenche un Trigger au niveau des scènes (ce qui inclue forcément GEA puisque c'est une scène). Donc à prendre en compte dans vos scénarios => Un trigger au moment où la porte s'ouvre et/ou se ferme, mais aussi un trigger à intervalle régulier.

Comme dis en MP, je suis candidat Départ de la région parisienne (93, je suis proche de l'A3, c'est direct vers Lille en évitant les bouchons), si y'a des intéressés pour covoiturer. Bon par contre ça dépendra de mes dispos et de la date commune qui reste àdéfinir. Du coup, je ne pense pas que j'aurai le temps de dormir sur place.