Lazer

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.

Non, ça doit fonctionner pour n'importe quel module je pense. D'ailleurs j'ai une idée encore plus chouette, mais faut que je teste avant Pour le coup du template, mon petit doigt me dit qu'on aura les plugins avant les templates Qubino.

Bon en fait les trigger dans les scènes fonctionnent, il faut que j'apprenne à utiliser ma box (il fallait cocher la case scène active.... ohoho le gros noob) Ca fait maintenant 2h que FHEM met à jour les température de 2 Qubino sans problème, ça apparait dans la panneau de température, les valeurs remontent dans le panneau d’événement, idem pour Domocharts, les trigger se déclenchent, bref la totale, c'est juste parfait Demain je vais remplacer mes VD qui gèrent les capteurs de porte EnOcean par les Détecteur de ces Qubino, et ça devrait apparaitre nativement dans l'interface, y compris l'appli mobile. Je vais me coucher sur un petit air de j'aime ma box pour une fois (il fallait bien ça après un petit crash en pleine journée.... pffff) Bon bah du coup les plugins utilisateurs ça ne me manque plus du tout !

Alors j'ai trouvé un truc plutôt pas mal, qui peut nous aider à contourner l'absence des plugins utilisateurs Sur HC2, ce module Qubino fil-pilote crée les modules suivants : - parent - dimmer (fil pilote) => celui qu'on utilise - sonde de température (même si aucune sonde n'est raccordée, le module apparait et reste à 0°C) - 3 détecteurs de mouvement, reconfigurable en n'importe quel type de détecteur (comme pour un FGK ou FGBS), correspondant aux 3 entrées physiques du module. Et bien ce qui est intéressant, c'est qu'on peut utiliser l'API pour forcer les valeurs de la température et des 3 détecteurs. Cela fonctionne sur le même principe que la technique permettant de forcer une consommation en Watts sur un module type relai, déjà évoqué sur le forum, par exemple pour un FGS : -- Use the relay of a FGS module to simulate power consumption from a Virtual Device or Global Variable local HC2 = Net.FHttp("127.0.0.1", 11111) local currentPowerValue = fibaro:getGlobalValue("wpPower") local jtable = "{\"properties\":{\"power\":" .. currentPowerValue .. "}}" local response, status, errorCode = HC2:PUT("/api/devices/89", jtable) fibaro:log("W: " .. currentPowerValue) . J'ai fait le test depuis un Linux avec curl, car je compte piloter tout cela depuis ma passerelle EnOcean FHEM : # Température curl --request PUT --user admin:xxxxx --data '{"properties":{"value":12.7}}' http://192.168.1.1/api/devices/339 # Détecteur curl --request PUT --user admin:xxxxx --data '{"properties":{"value":true}}' http://192.168.1.1/api/devices/340 Dans le cas du détecteur, la variable lastBreached est également mise à jour avec le timestamp courant ! Par contre, je n'arrive pas à déclencher de trigger dans une scène, ce qui est bien dommage dans le cas des détecteurs. J'ai testé avec la technique du paramètre "invokeScenes" qu'on connait pour les mises à jour de variable globale, mais ça ne semble pas fonctionner. Pourtant les détecteurs remontent bien dans l'affichage du panneau d'alarme, et leur statut se met à jour immédiatement dans l'interface Web de la HC2. Je vais faire fonctionner ça pendant quelques jours depuis FHEM, on verra si c'est stable.

ESXI ok, mais tu vas perdre tes données en passant en Raid....

Oui problème connu si tu as un Os non supporté par ILO, et/ou que tu n'as pas configuré le contrôleur SAS en Raid.

Le Flir est un peu mieux que le Seek Thermal car il a un double objectif, afin de prendre une photo permettant de détecter et dessiner le contour des objets. Le problème c'est sa disponibilité, pas loin de 2 mois de délai....