jjacques68

Mais si mes parents veulent se connecter, ils utiliseront le user que j'aurai créé dans le groupe admin ! nan ? mais du coup ça soulève la question, quel compte vont-ils utiliser sur le téléphone ? c'est compliqué tout ça... tu as peut être raison, vaut mieux créer un compte spécifique pour eux...

si c'est juste pour télécharger les QA et les scènes, j'ai développé un petit soft (sous windows) sans prétention pour le faire. Cela permet de mettre au moins de côté les scripts. Je sais pas si c'est vraiment utile avec les backup cloud et locaux... Si ça intéresse qqun : https://github.com/jjacques68/HC3-Download

Hello ! Petite question : Si j'installe une HC2 chez mes parents, est ce que je peux la déclarer sur mon propre compte Fibaro ID ? Je pourrais du coup y accéder à distance ? Il faudra alors créer un autre compte pour mes parents que je mettrais dans le groupe admin de la HC2, afin qu'ils puissent également créer des scénarios ? J'ai juste dans mon raisonnement ? Cela n'aura pas d'impacts sur la HC3 chez moi ? Cela ne va pas mettre le foutoir dans les notifications ? Merci pour vos conseils !

ben si j'ai compris ça Mais suis curieux (ou fou...) et oui, tout à fait, faut que je commence à m'intéresser aux autres colonnes du sniffer...

je faisais le réveil depuis le bouton à l'intérieur... donc c'est normal. - ok je n'ai pas de problèmes de lenteur. je me base sur la réactivité de l'allumage des lumières aux passages devant les PIR. J'ai vraiment pas à me plaindre (entre 1/2 et 1s) certain sont même quasi instantanés. Et pourtant je passe par une sacré usine à gaz de code Vu que je fais tout par le refreshState. Mais je persiste et signe à dire que certains modules n'ont absolument pas la route décrite dans l'API. Et je parle pas de mon analyse sur les routes "raccourcies". Certaines sont plus longues, d'autres plus courtes. Donc ça lève pas mal d'incohérence. c'est troublant;.. Après je découvre la chose, y a certainement des explications... Sinon je vois vraiment pas l'intérêt du "lastWorkingRoute". Et j'aimerais bien que l'API soit en phase, c'est censé l'être alors J'aimerais arriver à reconstruire 1 route déjà, et me rendre compte que le sniffer et l'API sont cohérent et le reste !

nan veux pas, après c'est un bon vieux FGK, donc peut-être... Je viens d'essayer avec un autre device et ça marche. Mais la route ne se modifie pas. J'avais déjà discuté de ça, j'avais fini par réussir en cassant la route existante du device (débrancher un device intermédiaire) avant de cliquer sur remesh... Mais là ça devient pénible...

oui oui ! Mais j'ai même pas ces infos dans le trace de la box... attends je réessaye...

nan justement... je pensais voir qqch passé mais rien.

quoi sur le fait qu'elle servent à rien ou que je vais me faire gronder ?

si si, après avoir cliquer sur remesh avec le bon N° de device, je réveille le module, mais rien... aucune réaction...

eeeeuh je ne sais pas du tout... J'ai envie de dire oui...

@TonyC : je confirme, j'ai déplacé le sniffer, plus de soucis de CRC, mais alors plus aucun.

alors je pense comprendre 1- truc (une chose à la fois ) cette route 36 -> 33 -> 1 ne correspond pas à ce que j'ai dans l'API qui devrait être : 36 -33 - 34 - 71 - 73 - 1 MAIS : le deuxième noeud (33) qui est utilisé dans cette route est lui même directement lié au contrôleur. Donc la route s'arrête au 33, pas la peine de passer par tous les autres ! Il prends un raccourci et ça se vérifie dans plusieurs cas ! Mais la question qui tue, pourquoi le contrôleur ne corrige pas les routes, quand les device eux-mêmes empruntent des raccourcis !! J'ai envie de dire que les routes inscrites dans le "lastWorkingRoute" ne servent à rien du coup !! oulà je me vais me faire gronder... Mais alors pour faire reconstruire une route avec un device sur pile... bonne chance pas encore réussi...

oh put... j'avais pas pensé à ça !! dommage pour moi...

ah oui poubelle, j'ai gardé l'aiment c'est tout.

étrange de faire appel au onInit() à chaque appuis bouton...

En effet, depuis le re-paramétrage du FGRM, je n'ai plus de soucis. cette affaire de FGRM, m'a emmener sur l'histoire du maillage, qui m'a emmener sur le fait que de temps à autre j'ai des freeze de la box, qui m'a emmener sur l'histoire de sniffer le réseau. Comme quoi ça a fait une sacré route Pour pinailler, j'ai, rarement, une tête Danfoss qui ne réagit pas à l'envoi d'une consigne de la box. Alors je tourne autour, je découvre et finirai par trouver

nickel ça, merci beaucoup !!

j'ai connu le même scénario, plus de détection, mais tout ok niveau communication. Pareil, j'avais galéré à le démonter. En forçant je pense que j'ai du claqué l'ILS (si c'est bien ça qu'il y a dedans)

@TonyC : oui en effet, les erreurs de CRC ne viennent pas forcément du device en lui même, mais plutôt d'une mauvaise réception du sniffer... j'ai percuté à tard cela dit, les têtes Danfoss sont quand même montrées du doigt, et pas qu'une... je vais tenter un remesh d'une tête, mais c'est jamais évidemment pour les modules sur pile (réveil, portée, ...) Le reste semble vraiment bien...

@kioneoranga : oui tout à fait https://www.mouser.fr/ProductDetail/Silicon-Labs/ACC-UZB3-E-STA?qs=PqoDHHvF64%2B4K0jzr4qA%2BQ%3D%3D

Bon visiblement, J'ai un soucis avec une tête Danfoss (Node 26), à chaque fois qu'un échange se fait (en moyenne exactement toutes les 10 min = correspond au temps de réveil que j'ai fixé), j'ai des erreurs de CRC.

Pas sûr de comprendre ce que tu veux... J'ai donc refait le test avec le device en question, le node 28 (tête Danfoss). J'ai donc modifier sa consigne depuis la box et voici l'échange, avec le retour : Et toujours cette route 28 -> 2 -> 1 au lieu de 28 -> 3 -> 1. edit : pas sûr que l'erreur soit dans l'échange, elle est apparue 2 secondes plus tard...

Le soft pour sniffer ne vient pas de moi, mais de Silicon Lab...

Ben c'est l'exemple donné dans le paragraphe "1ère lecture", les routes sont identiques et sont justes (du moins en phase avec ce que je lis dans l'API) Et dans les 2 sens..