Passerelle Enocean + Fhem

[PITP2]

j'avais eu le problème, je vais chercher dans mes archives la solution

[Bloug]

merci Pitp2,

 

bon, déjà  il est possible de déverrouiller le truc

[Lazer]

Je répond un peu tard, mais ça servira surement pour quelqu'un d'autre :

 

Pour modifier le fichier de configuration fhem.cfg, taper ceci dans la zone de commande en haut de la fenêtre :

attr WEB editConfig 1

Puis on fait la modif du fichier, et on clique sur Save. Cela a pour effet de redémarrer FHEM, qui recharge la config depuis le fichier.

 

 

Déjà  je trouvais FHEM compliqué à  utiliser, mais là , ça s'empire.... il y a surement une bonne raison, mais cela m’échappe.

[Bloug]

bah déjà  à  moi  

Merci !

[BenjyNet]

Milles excuses, j'avais pas updaté le premier post avec la mise jour de l'API de la v4, chose faite. J'attends aussi les quelques lignes de code de Lazer après ça trouvaille pour mettre àjour.

[Lazer]

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.

[BenjyNet]

Bon c'est nickel ça, je vais le rajouter en 1ère page. Dommage que je n'ai pas un module qui fasse l'hygrométrie aussi mais bon ça peut se garder en VG ça

[Lazer]

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

[Nico]

Bah oui, il y a de tout du coup.

Et dire que des tas de ST814 et de FGS... Miam !!! Et la dernière étape, c'est quoi du coup ?

D'ailleurs, on ne peut pas faire pareil pour un VD :)

[Lazer]

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

[BenjyNet]

Ouais attention là! Surtout si Fibaro lors d'un update ne veut pas écraser tout ça pour X raisons (genre si un module est en noeud mort depuis X temps -> le sortir de la base). Bon je dramatise surement mais avec eux tout est possible

[Lazer]

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.....)

[Nico]

Yes yes yes, ca c'est juste très très bon. J'ai hate de lire ton dernier test. Mais c'est très bon ça !

[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....

[Lazer]

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

Modifié 23 avril 2016 par Lazer

[XSRomano]

hello les amis,

 

ca veut donc dire que seul le physical virtual sensor fonctionne correctement ?

les capteurs c'est OK genre sonde de temperature, humidité etc... sont exploitables par contre les actionneurs comme les switch c'est KO pour le pilotage en natif c'est ca ?

 

@+ XSR

 

PS : Bravo Lazer pour ta découverte il y a un champ de possibilités impressionnant ca permet en effet de ne plus utiliser le plugin perso virtual sensor pour ceux qui ne veulent pas installer de plugins...

reste que le virtual Swith de Krikroff a encore de beaux jours dans ce cas

[Lazer]

Oui seul le Physical Virtual Sensor fonctionne parfaitement.

 

Pour les actionneurs, j'ai un peu avancé hier, mais ça n'est pas parfait, et c'est vraiment de la bidouille, donc je pense qu'on ne va pas trop s'éterniser là  dessus.

Pour info sur la bidouille en question, sur le module (testé avec FGD et FGRM déclarés en noeuds morts), il faut éditer les associations du module, et enlever la HC2 (ID=1). A ce moment là , la HC2 envoie l'ordre en Z-Wave, échoue, et il faut coller une scène derrière qui force la valeur du module, en même temps qu'elle réalise l'action demandée. Ce qui ne me plait pas, c'est que la box tente quoi qu'il arrive d'envoyer la commande Z-Wave, ce qui se solde forcément par échec.

[Nico]

Yes, c'est dommage. Mais au final, cela créer donc bien des VDs fonctionnel qui utilise des boutons, ce serait top pour les volets...

 

Mais bon, déjà  récupérer tous les détecteurs de ma Zibase, c'est juste déjà  excellent. Va falloir que je fasse juste joujou avec un FGK 20 fois :)

[XSRomano]

@Nico

 

t as pas un qubino tu les feras 3 par 3 ça fait que 7 fois on va dire  et t'auras 7 sondes de température en plus

 

@+ XSR

[Nico]

Yes yes, j'y ai pensé Pourquoi pas après tout. Le soucis, c'est que je vais avoir encore plus modules inutiles lol

[BenjyNet]

Ouais mais les qubino c'est des détecteurs de présences, pas des capteurs de portes,  ça dépend de ce que tu veux afficher.

[Lazer]

euh, Benjy dans l'onglet avancé tu choisis ce que tu veux, c'est exactement comme pour un FGBS, ou FGK, ou tout autre détecteur de quelque chose. La HC2 n'est pas trop mal foutue quand même hein, depuis le début on peut choisir le type d'un détecteur, c'est WAF ça

[Nico]

Yes, donc je vais devoir commander un Qubino, pfff...

[Nico]

Bon, j'ai attaqué avec un FGBS, comme ça c'est 2 àla fois. Bah ça fonctionne nickel, c'est juste top. Toute ma Zibase va transiter sur la HC2 en natif également, parfait.

[Nico]

Bon bah j'ai terminé avec les capteurs que j'ai, donc 17 modules noeuds morts de créé, toute mon alarme est désormais intégré et sur mon alarme àpart et sur la HC2, c'est juste magnifique.

Seul point : Au niveua des sauvegardes, ces modules noeuds morts ne sont pas compté, un peu étonnant. Tu as aussi le cas Christophe ?