Lazer

Heureusement que tu as précisé

Tu as probablement inversé tout le câblage. Essaye donc d'inverser les 2 interrupteurs, et les 2 sorties moteurs.

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.

Ah je ne savais même pas que LibreNMS gérait l'onduleur, mais à la réflexion c'est logique. Ca fait un moment que je me dis qu'il faut que je le teste (suite à un de tes messages il y a quelques temps), mais je n'ai pas encore pris le temps de le faire. Quoi qu'il en soit, le VD dans la HC2 garde un intérêt, c'est que la box domotique communique en direct avec les équipements du réseau, sans dépendre d'une VM qui faut tourner un produit tiers. Reste à faire ce VD..... un jour ça viendra....

Oh punaise, j'avais pas vu que t'as mis àjour l'image de ta signature, trop fort

t'as pas essayé de mettre du talc dans le relai ?

@Nico : le tuto ça serait dans quelques jours, quand je serai certain (si on peut être certain un jour...) que c'est bien stable. Disons plutôt que ça ne rend pas la box plus instable qu'elle ne l'est déjà . En tout cas j'ai déjà plusieurs fake modules, et ça fonctionne au poil, la conso mémoire est stabilité, donc pour l'instant je dirais que c'est nickel @Benjy : t'as pas quelques modules d'avance pour ça ? J'ai toujours un peu de spare perso.

Le débat est reparti sur Jeedom, faut croire qu'on en est tous secrètement amoureux pour en parler autant

http://www.igen.fr/accessoires/2016/04/smartthings-la-crise-de-croissance-de-la-maison-intelligente-de-samsung-95577 Il n'y a pas comme un air de déjà-vu, pour nous autres power-users de Fibaro ? Je n'ai lu que cet article, et je ne suis pas allé voir les forums, mais l'herbe n'est décidément pas plus verte ailleurs. Décidément, c'est pas encore maintenant que la domotique sera grand public....

Regarde 1 ou 2 pages en arrière, on en a parlé

Ouaip, le problème c'est qu'à l'initialisation, ton velux s'est configuré sur le protocole propriétaire en CPL, car ton velux est piloté en 24V continu par un boitier (alimentation) caché. La télécommande sans-fil permet juste d'envoyer l'ordre. Il faut donc que tu vérifies que ton modèle de Velux récent peut être réinitialisé pour repasse en 24V par inversion de polarité. Si c'est possible, alors tu pourras piloter le Velux a l'aide d'un module IP tel que le VRT-IP ou l'IPX800 (mais sans calibration; donc pas de variation du slider, c'est du tout ou rien). Autrement, il y a un module parfait chez Qubino qui permet de calibrer un Velux en alimentation 24VDC par inversion de polarité, mais je ne suis pas certain qu'il fonctionne avec la HC2. Bref bon courage, Velux c'est du super matos, mais comme Somfy, une galère sans nom à domotiser. Exprès pour te faire acheter leur box domotique propriétaire.

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)