Zlinky_TIC
Zlinky_TIC copied to clipboard
fairecasoimeme
Deconnexion du Zlinky_TIC de mon réseau Zigbee
Bonjour,
Je l'utilise avec un dongle USB Conbee depuis quelques semaines. J'ai pu le connecter avec mon réseau Zigbee sans problème et ai configuré Deconz de façon a récupérer les données. Tout fonctionnait correctement jusqu'à il y a quelques jours. Mon ZLinky_TIC est complètement déconnecté du réseau Zigbee et donc ne remonte plus les données. La lampe bleu reste allumée mais plus de communication. Y-a-t-il une solution pour éviter cette déconnexion ?
D'avance merci.
Bonjour, Est-ce qu'il se reconnecte lorsque vous le débranchez puis rebranchez physiquement ?
Bonjour,
Oui, je l'ai fait hier et il s'est reconnecté après à mon réseau. J'ai constaté parfois que pendant plusieurs heures les infos ne remontaient pas. Voir ici: https://forum.phoscon.de/t/lixee-zlinky-tic-ddf-file/1164/60.
Info obtenues via deconz concernant mon Zlinky_TIC:
Je ne sais pas si cela vient de ma configuration avec Deconz. Sinon, produit super qui remplace mon Ecodevice avec sans aucun doute une consommation moindre.
Bonjour, de quand date votre achat ? pouvez-vous me contacter par mail ? Si c'est un matériel acheté avant mi Février, il est possible qu'il faille faire une modification matérielle ? Fred
Bonjour, ma question est peut etre hors sujet, mais il semblerait que la cause pourrait provenir d'une surcharge de requête sur l'appareil. Il y aurait des valeurs conseillées pour le polling / reporting, pour éviter ce genre de probleme ?
Bonjour, il est conseillé de poll toutes les minutes. Pour le reporting, on peut en créer 20 maximum et pareil que le poll, éviter de passer en dessous de la minute. Cependant, s'il manque le condensateur sur le ZLinky_TIC, le problème peut quand même apparaître. Pour vérifier s'il y a le condensateur voir : https://github.com/fairecasoimeme/Zlinky_TIC#errata-hardware Fred
Bonjour,
Je viens de le démonter pour vérifier la présence du condensateur. Il est bien présent:
Très bien. Je pense que cela confirme un problème de configuration. Avec les réglages suggérés par @Smanar, je n'ai pas observé de déconnexion pour le moment. Donc c'est sur la bonne voie. Merci de votre aide.
Hello , je rencontre le meme soucis de deconnection, avec condensateur. Je retrouve le module led etteinte au bout d'un certain temps. J'en demande sûrement trop au module, mais c'est problématique dans mon cas. J'ai besoin d'avoir les changements de puissance et courant quasi instantané. Je fais du delestage avec ma borne de recharge, et si je passe à un update toutes les 60 sec pour les push , j'ai bien peur que cela fasse sauter mon compteur avant.
Hello , je rencontre le meme soucis de deconnection, avec condensateur. Je retrouve le module led etteinte au bout d'un certain temps. J'en demande sûrement trop au module, mais c'est problématique dans mon cas. J'ai besoin d'avoir les changements de puissance et courant quasi instantané. Je fais du delestage avec ma borne de recharge, et si je passe à un update toutes les 60 sec pour les push , j'ai bien peur que cela fasse sauter mon compteur avant.
Cette méthode est contre productive, inutile de saturer son réseau zigbee en polling. Il suffit de faire un config report sur un des champs:
- ADPS en historique mono,
- ADIRx en tri
- en standard, je laisse @fairecasoimeme compléter la variable changera si dépassement. Pour la config, suffit de mettre des temps long et un changement à 1.
C'est exactement ce que je fais, le polling est repoussé à 600 sec. Je ne mets que le courant et la puissance en config report ( de 1s à 600sec max ) , pour qu'il me renvoie au plus vite la valeur en cas de changement. Le reste tourne à peu près dans les 300sec.
Ce n'est pas ce que j'ai écrit. Avoir le changement de puissance ou d'intensité rapidement n'est pas utile à des fins de suivi de consommation, il faut allonger les temps ou la valeur du changement. Pour du délestage en mono par exemple, il faut utiliser ADPS, celui vaut 0 en temps normal et prends la valeur consommée si dépassement, il suffit donc d'attendre son changement (!=0) et d'appliquer un délestage immédiatement.
je comprends bien mais dans mon cas ca fonctionne comme ça, le delestage est particulier. J'ai différents scenarios, selon il va delester le chauffage electrique dans différentes pièces, l'eau chaude etc, ou envoyer des commandes à l'EVSE pour dimminuer le courant de charge ( je peux le controller par pas de 1A ), ou remonter à fond quand tout est libre. J'ai besoin de connaitre ces valeurs en direct pour calculer combien j'attribue à l'EVSE et au reste de la maison selon les differents scenarios prévus. Car tout en même temps en hiver, même sans le chargeur, ca saute. L'ADPS ne me permet que de constater qu'on est déjà en surcharge, pas d'avoir un controle intelligent de l'ensemble avant même le depassement.
Pour l'instant ça à l'air de tenir en l'état en enlevant tout les polls et en limitant les reports sur la plupart des valeurs. Je laisse tourner pour voir.
ps: je suis sous Deconz, avec un DDF complètement modifié, en TIC historique pour l'instant ( demande faite ) .
Justement, par peur de tout faire sauter, ça devient une usine à gaz. Lorsque l'on a debug l'ADPS avec Lixee, j'ai eu le voyant au Linky un moment sans que ça ne saute. L'information utile est vraiment l'ADPS, tant qu'il n'arrive pas, il ne faut rien faire, ou du moins, une régulation lente. Il faut commencer à réagir de manière rapide lorsqu'il déclenche (c'est le fonctionnement du BMS schneider que j'ai, il fonctionne en slow tant que le seuil n'est pas atteint et passe en fast report ensuite). Donc ce que je fais chez moi, tant que je ne dépasse pas, je laisse vivre et ensuite, si dépassement, je coupe tout le monde et je remets par zone progressivement avant de tout remettre si la conso le permet.
Je confirme, en mode historique, l'étiquette ADPS sert à contrôler le dépassement de puissance souscrite. En mode standard, c'est l'étiquette STGE qui regroupe un ensemble de status. Lorsque la puissance souscrite est dépassée, ADPS ou STGE change mais le compteur laisse, me semble-t-il une trentaine de seconde (minimum) afin de permettre aux appareils de délestage d'agir sur la consommation.
Bonjour, il est conseillé de poll toutes les minutes. Pour le reporting, on peut en créer 20 maximum et pareil que le poll, éviter de passer en dessous de la minute. Cependant, s'il manque le condensateur sur le ZLinky_TIC, le problème peut quand même apparaître. Pour vérifier s'il y a le condensateur voir : https://github.com/fairecasoimeme/Zlinky_TIC#errata-hardware Fred
Même limite atteinte de mon côté : j'ai réglé les bindings de puissance apparente entre 5 et 120 secondes, avec "Reportable change" à 50 (Watts) pour avoir du quasi temps réel et je perds la connexion tous les 1 ou 2 jours... Je vais passer sur du 30 secondes en intervalle minimum (voire 60 comme préconisé, si cela ne suffit pas).
Y a-t-il une explication technique pour ces déconnexions ?
Ca a tenu 20j de mon coté avant de lâcher; après avoir remonté beaucoup de parametres, et limité au maximum les updates . Obligé de redebrancher le module, attendre un peu puis le rebrancher pour qu'il reparte.
Je me demande si le fait que les fonctionalités de routing zigbee soient activée ne ferait pas susrconsommer.
Ca serait possible d'essayer un firmware sans routage pour comparer ? Comme vous pouvez voir ici il est maillé un peu partout, ça ne ferait pas jouer sur la conso ?
Bonjour, Je vais regarder pour faire un firmware en limitant la fonction "routeur" et voir l'impact. je vous tiens au courant. Fred
Bonjour, Je vais regarder pour faire un firmware en limitant la fonction "routeur" et voir l'impact. je vous tiens au courant. Fred
Ah merci. N'hésites pas à le publier que je puisse tester aussi.
Bonjour, Je vais regarder pour faire un firmware en limitant la fonction "routeur" et voir l'impact. je vous tiens au courant. Fred
@fairecasoimeme Serait-il possible de rendre cela configurable via le cluster spécifique fabricant ? Car j'ai peur que la suppression du routage impacte négativement la durée de vie des capteurs sur pile que j'ai placé à côté de mon compteur Linky. Et je n'ai plus de perte de connectivité depuis que le condensateur a été rajouté à mon module Zlinky_TIC par tes soins.
Le rendre configurable, à mon avis c'est compliqué. Mais peu importe, si j'y arrive ce sera un firmware spécial pour ceux qui ne veulent pas de routage, genre une nouvelle branche. Ce sera la même version qu'actuellement. En gros, c'est juste des directive de compilation qui vont changer
Pouvez-vous essayer avec cette version ? ZLinky_router_v5.0_noRoute.zip
Tu l'as compilé pour ota ? Cureusement ça reste bloqué à 0.04% chez moi. Je l'avais déjà mis à jour avant.
merci. C'est installé. On verra bien. Il est toujours identifié comme routeur, mais il faut peut etre que je le reappaire.
@KipK tu as fait comment pour l'OTA? Meme avec le force a true il veut pas update via Z2M.
J'ai du incrementer le numero de version dans le package ota sinon ca upgradait pas.
@tolriq, essaye celui là ZLinky_GpProxy_Ota_OM15081_V5.zip C'est le même qu'au dessus mais edité en V6 au lieu de V5 avec deconz. Une fois chargé, le n: de version reste 5, c'est juste pour tromper le moteur ota
Pareil ca continue de me dire que ca utilise le normal :(
ota:
zigbee_ota_override_index_location: index.json
[
{
"url": "ZLinky_GpProxy_Ota_OM15081_V5.ota",
"force": true
}
]
Debug 2022-06-14 21:04:02Is new image available for 'xxxxxxx', current '{"fieldControl":0,"manufacturerCode":4151,"imageType":1,"fileVersion":5}', latest meta '{"fileVersion":5,"fileSize":240478,"url":"https://github.com/fairecasoimeme/Zlinky_TIC/releases/download/v5.0/ZLinky_router_v5.0.ota"}'
Debug 2022-06-14 21:04:02Update available for 'xxxxx': NO
Info 2022-06-14 21:04:02No update available for 'Linky'
Je doit rater un truc a la con.