
jjacques68
Membres confirmés-
Compteur de contenus
4 346 -
Inscription
-
Dernière visite
-
Jours gagnés
39
Tout ce qui a été posté par jjacques68
-
Sécuriser l'arrivée d'eau et contrôler sa consommation
jjacques68 a répondu à un(e) sujet de jjacques68 dans Tutoriels
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...
-
Topic unique Fibaro - Capteur D'ouverture Fgk
jjacques68 a répondu à un(e) sujet de Moicphil dans Modules Fibaro
oh put... j'avais pas pensé à ça !! dommage pour moi... -
Topic unique Fibaro - Capteur D'ouverture Fgk
jjacques68 a répondu à un(e) sujet de Moicphil dans Modules Fibaro
ah oui poubelle, j'ai gardé l'aiment c'est tout. -
QuickApp - Chauffage Fil Pilote Qubino
jjacques68 a répondu à un(e) sujet de fredokl dans Quick App Developpeur
é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
-
tutoriel Détecter les erreurs et protéger l'exécution d'un script LUA avec pcall()
jjacques68 a répondu à un(e) sujet de Lazer dans Tutoriels
nickel ça, merci beaucoup !! -
Topic unique Fibaro - Capteur D'ouverture Fgk
jjacques68 a répondu à un(e) sujet de Moicphil dans Modules Fibaro
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..
-
Hello tout le monde, Merci à ceux qui prendront le temps de lire ces quelques lignes... Je me suis donc mis à sniffer les trames zwave... C'est très intéressant, mais pas toujours compréhensible... (à mon niveau) J'espère ne pas montrer des infos "confidentielles" avec les captures... 1ère découverte à laquelle je ne m'attendais pas, et bien c'est plutôt calme... Je pensais à voir plein de trames dans tous les sens (cf, sniffer LAN avec Wireshark), et bien pas du tout ! Donc c'est plutôt une bonne nouvelle j'imagine. 2ème découverte, et bien faut pas se mélanger les pinceaux avec les ID des modules (colonne Src et Dst) qui sont les "nodeID" et nom l'ID du device dans la base de donnée de la HC3. Certain le savait certainement déjà.. J'ai donc amélioré mon application qui me lister le maillage du réseau zwave, en interrogeant l'API, afin d'afficher les infos nécessaires. Les lignes en grises sont simplement les device qui servent de passerelle pour un autre device. 1ère lecture : Là je viens d'actionner un switch : On voit clairement le chemin que prend la trame avec les sauts de device en device. Ainsi que le retour d'état. Si je compare avec mon soft de maillage : Tout est nickel. 2ème lecture : Là on voit que visiblement, une route n'a pas fonctionnée ?? 28 -> 2 ne répondait pas... donc il a pris 28 -> 3 Par contre je comprends d'où il sort la route 28 -> 2 ?? Parce que clairement, d'après ce que je lis dans mon soft (donc dans l'API), c'est bien 28 -> 3... Et ça revient presque à chaque fois (le node 28 = une tête Danfoss, je dis ça parce que j'ai l'impression que c'est le bordel avec eux... je surveille ça du coin de l'oeil) 3ème lecture : là je constate une erreur (y en a quand même de temps en temps...) cette route n'est pas bonne : elle aurait du être (d'après l'API) : (36) -> 33 -> 34 -> 71 -> 333 -> (1) d'ailleurs quand je vois la ligne CRC_ERROR, tu peux être sûr que je comprends plus la route, comme si elle était perdues 4 ème lecture : Je comprends pas du tout ce scénario ?? qui revient souvent... Surtout que le Node 22 est en lien direct selon l'API... (et au passage, encore une tête Danfoss...) Ben voilà c'est quel le début des aventures Si qqun a des réponses/remarques/explications ... merci d'avance !!
-
tutoriel Utilisation de net.HTTPClient() asynchrone dans une scène
jjacques68 a répondu à un(e) sujet de Lazer dans HC2
ben ça fallait le savoir !! dans ce cas précis, vaudrait peut-être mieux utiliser une variable QA (self.xxxx) du coup... du moins si y a un risque que le contenu de la table soit modifier par une autre fonction...- 58 réponses
-
tutoriel Utilisation de net.HTTPClient() asynchrone dans une scène
jjacques68 a répondu à un(e) sujet de Lazer dans HC2
mais que ce passerait-il si 2 méthodes de ce QA sont appelées "simultanément" avec la variable http déclarée dans le onInit() ?- 58 réponses
-
tutoriel Utilisation de net.HTTPClient() asynchrone dans une scène
jjacques68 a répondu à un(e) sujet de Lazer dans HC2
toujours aussi clair tes explications @Lazer- 58 réponses
-
comportement étrange avec les retours d'état
jjacques68 a répondu à un(e) sujet de jjacques68 dans Support
et voilà, mes clé zwave sont arrivées, ça sniffer grave ce week-end -
moi, au meilleur moment, il a jamais dépassé ... ... 0 %
-
oui pas qu'un fgms covidé passe par là...
-
ah ah j'avais pas fait gaffe !!
-
super , 3 variantes de bug...
-
Modeste installation de débutant
jjacques68 a répondu à un(e) sujet de ToTo Buzet dans Mon installation domotique
d'ailleurs on a pas la possibilité, sur le forum, dans les propriétés du profil, de sélectionner "HC3" ou maintenant, "HC3L" bon, c'est pas gênant, mais... Si un admin pouvait ajouter ces 2 valeurs dans la liste box... merci d'avance !