
jjacques68
Membres confirmés-
Compteur de contenus
4 365 -
Inscription
-
Dernière visite
-
Jours gagnés
39
Tout ce qui a été posté par jjacques68
-
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 ! -
nan mais y a un soucis avec les mise à jour des modules ! J'ai aussi un fgms à mettre à jour (v3.3), et y a rien à faire, ça veut pas. Pourtant à chaque tentative, il clignote bleu clair, pour fini par clignoter plus vite et s'allumer en vert. Avec le debug suivant : [03.03.2021] [17:46:45] [TRACE] [ZWAVE]: ID 521: New image was successfully stored in temporary non-volatile memory The device will now start storing the new image in primary non-volatile memory dedicated to executable code. Then the device will restart itself. Donc rien indique que ça a pas marché, mais ça a pas marché.
-
alors le chiffre après numéro de l'icône dans ton cas est pour des icônes avec plusieurs status. Dans ton cas, tu as fait la manip avec un QA de type binary, donc 2 status. Si tu l'avais fait avec un type MultiLevel... tu aurai pu avoir plusieurs icônes, donc avec des chiffres, derrière le numéro de l'icône, différent (userXXXX10, userXXXX20, userXXXX30, ...) Mais ça ne marche pas pour un QA de type générique. Donc il faudrait que tu refasses la manip, en créant un QA de type MultiLevel Sensor. Tu ajoutes ton ou tes icônes une par une. Tu relèves le N° de ces icônes (ils seront bien sous la forme userXXXX.png). Dans ton QA générique, ce sera à toi de gérer l'affichage de la bonne icône en fonction des différents cas. Avec la commande que tu cites ci-dessus. J'ai fais ça pour tous mes QA le nécessitant. Mais es-tu sûr que tu as besoin d'un QA de type générique ? Je demande ça car dans mon cas, quand je me sus lancé sur la HC3, je n'avais pas fait attention, et je choisissait systématiquement "générique" alors qu'un binarySensor/switch aurait été bien plus judicieux... rien que pour la gestion de l'icône... Et perso ça me gave de ré-écrire tous les QA, donc je reste comme ça, ça marche très bien aussi. Juste que... c'est pas clean et ça rejoint les remarques de @Lazer en début du topic...
-
Concernant la récupération l'icône, normalement un click droit sur l'icône suivi de enregistrer sous, permet de visualiser le nom contenant le numéro de l'icône... exemple userxxxx.png. le xxxx est le numéro de l'icone.
-
ben ça va pour un ou deux child... regardes dans mon exemple, j'ai un QA par pièce, permettant d'activer ou non l'éclairage automatique. J'ai donc fait : - 1 QA Parent - plus d'une douzaine de Child de type binary switch. je vais pas allé modifier tous les Child un par un pour changer l'icône, j'ai codé ça une fois et terminé.
-
Un peu d'aide sur le remplacement de PUT du Net.FHttp de HC2
jjacques68 a répondu à un(e) sujet de Kana-chan dans Support
j'ai fais ça y a quelques jours pour couper le wifi de la HC3... Tu peux peut-être t'en inspirer ... http = net.HTTPClient({ timeout = 2000 }) http:request("http://localhost/api/settings/network/radio",{ options = { headers = { ["Authorization"] = "Basic user:password (en base64)", }, data = json.encode({wlan={enabled=false}}), method = "PUT", }, success = function(res) if json.decode(res.data).code == 200 then self:debug("HC3 Wifi desabled") else self:debug(res.data) end end, error = function(err) self:error(err) end }) -
tout à fait, mais les icônes par défaut ne sont pas toujours appropriées, même pour un binary qqch... et ça évite de devoir aller le faire dans propriété des QA.
-
méthode un peu bourrin je l'avoue, mais je sais pas faire autrement : Et il faut au préalable ajouter l'icone dans la HC3 en passant par un QA type générique par exemple... Et une fois fait, mémoriser le N° de l'icone (dons mes exemple N° 1011). sur les enfant, c'est à la création du child : local child = self:createChildDevice({ name = _name, type = "_type, initialProperties = { deviceIcon = 1011 }, }, CLASS) sur les parents, dans le onInit() self:updateProperty("deviceIcon", 1011) je pense qu'on pourrait rajouter cette commande dans le onInit() des child, jamais testé...