jjacques68

sur jeedom oui, ce que j'utilise actuellement, pour un G-Tag pour faire de la détection de présence, ainsi que pour des mi-flora pour les plantes vertes. La portée est assez "étrange", le G-tag est capté depuis l'extérieur à plusieurs dizaine de mettre de l'antenne !!! alors que des fois à 1m, il capte rien du tout. !! Je sais pas si c'est le bluetooth ou jeedom qui déconne... En plus j'ai une antenne qui fonctionne plus, celle qui est directement branchée dans la smart (USB SENA) Et puis de toutes façons, je n'aime pas du tout cette box. Merci à ceux qui ont développé des pluggins (je pense à BLEA), mais voilà... Je vais en faire râler certain, voilà, c'est dit. C'est ce qui me fait peur avec la HC3 : sa portée... Comme tu dis, l'emplacement de l'a box va être, et l'est déjà, déterminante. Surtout qu'on peut pas déporter l'antenne bluetooth vu qu'elle est interne. Donc chez moi, à la cave, dans la baie info... ça va être chaud... Suis impatient de voir. Après, c'est surtout pour le G-TAG de présence, si j'ai plus les plantes vertes... tampis... de toutes façons le chien les bouffe et que celles où j'ai un capteur mi-flora !!! va comprendre

Oh ben moi ça me suffirait largement... Envoyé de mon iPhone en utilisant Tapatalk Pro

et concernant le bluetooth ? des news ?

il me semble que les données dans les VG sont de type string et non de type number. il faut ajouter un tonumber(): local ConsigneBureau = tonumber(fibaro.getGlobalVariable("Consigne_Bureau")) + 1 fibaro.setGlobalVariable("Consigne_Bureau", ConsigneBureau)

euh... moi-meme je me suis pas compris

elles sont physiquement compatible ?

@Krikroff, @Lazer, vous parlez de quoi là ?

MAJ effectuée, RAS pour le moment... J'ai l'impression que la CPU est encore moins sollicitée...

super interessant ces articles. d'après ce post https://forum.fibaro.com/topic/48365-hc2-repair-maintenance-guide/, le bouton "remesh" permettrait bien de reconstruire une route à la demande, pour un device spécifique... Bon y a plus qu'à se lancer dans un sniffer zwave... clé usb déjà commandée

très bien, donc la route s'est reconstruite d'elle même. peut -être que je n'étais pas assez patient...

ben en tout cas c'est ce que j'ai constaté avant de faire un remesh. Clairement, j'ai débranché le wallplug, fait fonctionner le volet, qui fonctionnait très bien. Interroger l'API pour avoir la route, qui n'avait pas bougé. C'est seulement après avoir cliqué sur remesh que la route s'est reconstruite. Je peux essayer de refaire la manip (sans qu'il faut que je trouve un module qui passe par un wallplug, c'est plus facile à faire )

maintenant que tu le dis, je l'avais fait aussi ça... et j'ai étrangement pas constaté de modification de la route... chose que j'attendais. Où alors j'ai pas été assez patient (5min max avant de cliquer sur remesh)... pourtant le volet fonctionnait très bien avec la route "cassée".

alors le bouton permettant de faire un remesh d'un device fonctionne. Mais visiblement, il faut "casser" la route existante avant de le faire. Par exemple : J'avais un volet (au Rdc) qui passait par un WP (etage) pour aller sur la box (cave). J'ai dans un premier temps éteint le WP de l'étage, puis demandé un remesh de ce volet. Aucun changement... J'ai donc carrément débranché le WP de l'étage. Redemandé un remesh. Et là, la route à été reconstruite. De 4 rebonds je suis passé à 2 pour ce volet. autre chose, durant la nuit, des routes ont été clairement reconstruites, je ne fais aucune action la nuit... mise à part le redémarrage de la box suite au backup auto. Mais si j'ai bien compris, cela n'a aucune influence sur le maillage des modules. alors encore une fois : EDIT : Je viens d'écrire une petite scene toute simple pour trigger sur le changement de la property lastWorkingRoute, mais je pense pas que ça va marcher...

absolument, et je vérifie avec le script php... histoire d'être sûr que je me plante pas dans l'algo. Et bien c'est tout à fait identique (juste moins visible avec le php)

alors j'ai ajouté quelques icones dans l'arborescence, et ça montre un truc encore plus fou : Je sais pas si vous allez comprendre, ou c'est moi qui est pas compris... le device 121 (icon orange) : Sa propre route passe par le 118. alors qu'il est en 1ère position (icone dossier jaune) dans la route du device 88 ! Pourquoi sa propre route n'est directement relié au contrôleur ?? ???

tu rigoles, mais je le pensais, je coupe le courant partout et alimente que les modules FGRM... en plus il sont sur le même disjoncteur

je vais quand même pas tout réinclure !!

ça je comprends bien ! Mais les FGRM sont à 2 mètres vol d'oiseau !! si je peux l'éviter, je préfère si je peux la remettre après à son emplacement d'origine, je veux bien, mais qui me dit que le maillage ne va rechanger après ça !? J'ose poser la question, (vais me faire gronder je le sens... ) si je force un remaillage complet du réseau. et que c'est pire, un bordel sans nom quoi... est ce qu'un recovery me remet les routes comme avant ?

en même temps, la HC3 est à la cave... Pas de chance, pas de bouteilles dans la cave !

je reviens avec mon histoire, après avoir pris le temps d'analyser les choses... Je me suis permis de refaire le script php sous une application windev histoire d'enrichir un peu les infos... Bon malheureusement j'arrive pas à avoir le rendu graphique du plugin en php, donc c'est une arborescence classique, mais le résultat est le même (et pas besoin de serveur http ou autre ) voilà le résultat : [id] - name - (room - section) si on regarde un des mes FGRM, celui du volet 3 (ID 47), et qu'on regarde de plus près le chemin en partant du module : RDC ---> CAVE ---> CAVE (encore ??) ---> ETAGE (incroyaaaable !) ---> CAVE ---> CAVE nan mais c'est quoi ce maillage ? J'ai du mal a croire que c'est le seul chemin qu'il ait trouvé !! et c'est de loin pas le seul !! Franchement, ça me dérange vraiment de voir ça, ça fait mal aux yeux !

alors je viens de me rendre compte, que sur les 6 FGRM, 1 n'avait pas les paramètres 40, 42 et 43 à 0. cela vient du fait que j'ai du le ré-inclure il y a quelques temps... Suite à une galère profonde pour inclure un Qubino FP, ce FGRM avait disparu de la circulation... ?¿? bref... Je n'avais pas penser à ces 3 paramètres à ce moment là. Je les ai modifiés, on va voir si ça va jouer un rôle... J'ai un doute vu que ce bug de remonté d'info, était aléatoire sur les 6. Apres peut-être qu'il bombarde sa conso sur le réseau et sature celui-ci et du coup j'ai des retours d'état qui se perdent...

j'ai encore une fois essayé ce matin. Toujours rien. Voici ce qui apparaît dans le debug : Mais il se passe rien, j'ai forcer des réveils, il reste en version 3.3.

@mprinfo, c'est une idée, mais pffffff faut que je le démonte, le branche à proximité, me retaper tous les scripts pour mettre à jour les ID... franchement... bof

les 6 FGRM sont justes au-dessus de la box, mais à l'étage au-dessus. désolé, mal lu. Mon FGMS n'est pas tout à côté. Mais j'ai pris soin de le rapprocher pour faire des essais, mais sans résultat non plus...