Oui, il n'y a pas de Heal Network comme en OZW.
Eventuellement si tu es en source routing, lancer une topologie permettrait de re-valider les routes, mais en Table Routing pas de moyen.
Si cela t'intéresse, tu peux regarder les tables de routage de chaque objet dans l'export JSON, par contre lance une topologie, attends que celle-ci soit terminée.
Un test très simple:
Si tu as une erreur de communication plugin -> Device, et que la communication Device -> Plugin fonctionne, cela indique que le device qui sert de routage au milieu à un soucis
Avis sur coordinateur
Re: Avis sur coordinateur
Zigbee for Domoticz - Clef zzh-p (electrolama) 45 devices.
Si vous appréciez ce que je fais, vous pouvez contribuer par un don Paypal , ce qui me permettra notamment l'achat d’équipements et de les tester/valider pour le plugin.
Wiki ici
chat sur Keybase.io
Si vous appréciez ce que je fais, vous pouvez contribuer par un don Paypal , ce qui me permettra notamment l'achat d’équipements et de les tester/valider pour le plugin.
Wiki ici
chat sur Keybase.io
Re: Avis sur coordinateur
Hello,
Je suis revenu entre samedi a.m. et dimanche matin sur le table routing avec, après le redémarrage complet du plugin dans ce mode, la manip suggérée de débranchement de tous les routeurs pour voir si cela améliorait (au moins temporairement) les choses. Ça n'a pas été le cas.
Avant ce redémarrage, après ~2j de fonctionnement en source routing, j'avais demandé un rapport de topologie: Il montrait les 3 routeurs en communication directe avec le coordinateur et aucun maillage entre eux, même pour le plus éloigné.
Pour la petite histoire cette prise la plus éloignée coupe l'alimentation de ma sectionnelle de garage la nuit et sur planning vacances, le retour de l'alimentation étant au besoin déclenché (scripté/Lua) par la désactivation de l'alarme ou du mouvement dans le garage: Genre quand on y arrive le matin par l'intérieur pour sortir un véhicule, la motorisation est alors automatiquement réalimentée si état off.
=>Ce fonctionnement fait que l'on est souvent présent quand ce rallumage se fait et vu que le PIR signale localement sa détection d'un flash rouge, on peut même voir s'il y a un délai anormal.
En table routing, j'avais assez souvent une suite de 4 ou 5 clic rapides avant que cela reste à On, cela ayant d'ailleurs visiblement provoqué le blocage d'un relais car un précédent modèle du même type était mort en quelques mois et j'avais dû le changer. Le nouveau modèle avait mieux fonctionné au départ, mais très vite ce fut idem.
Depuis que suis en source routing, j'observe que c'est pour le moment toujours 1 clic unique et probable que les séries observées avant résultaient déjà d'un problème de communication?
Ce type de prise n'est pourtant pas nouveau et je n'ai pas vu d'info sur des pb de routage...
Maintenant, je n'ai pas souvenir de pb de détection de capteurs de vibration (et avec ce type de capteur toute la communication visible de l'utilisateur c'est objet->coordinateur) ni remarqué de grosses pauses de remontée de mesures côté prises (toujours dans le sens objet->coordinateur).
Par contre côté commande des prises dans le sens coordinateur->objet il semble que l'on ait eu des retry... alors que la commande initiale (et les retry jusqu'à l'état stable On) semblait pourtant passer (sinon j'aurais à mon sens plutôt eu un clic unique mais notablement retardé vs détection PIR): Cela ressemblerait donc à un pb d'acquittement, sens objet->coordinateur qui semble pourtant globalement fonctionnel quand on n'a pas eu une commande avant.
Vu de dehors, difficile d'en dire plus, mais rien de bien clair côté sens qui poserait plus de problèmes même si à la réflexion, j'aurais peut-être pu tenter de baisser la puissance en TX actuellement réglée au max (cela rendrait peut-être plus clair un pb de bilan radio déséquilibré en RX vs TX) supporté par le coordinateur.
Au moins la conso mémoire ne dérape plus même en table, mais pour le moment je vais en rester à la configuration de routage qui fonctionne bien chez moi... A la prochaine commande d'objets, je commande également un coordinateur et cette fois avec antenne externe puis je referais ces essais avec le nouveau.
Je suis revenu entre samedi a.m. et dimanche matin sur le table routing avec, après le redémarrage complet du plugin dans ce mode, la manip suggérée de débranchement de tous les routeurs pour voir si cela améliorait (au moins temporairement) les choses. Ça n'a pas été le cas.
Avant ce redémarrage, après ~2j de fonctionnement en source routing, j'avais demandé un rapport de topologie: Il montrait les 3 routeurs en communication directe avec le coordinateur et aucun maillage entre eux, même pour le plus éloigné.
Pour la petite histoire cette prise la plus éloignée coupe l'alimentation de ma sectionnelle de garage la nuit et sur planning vacances, le retour de l'alimentation étant au besoin déclenché (scripté/Lua) par la désactivation de l'alarme ou du mouvement dans le garage: Genre quand on y arrive le matin par l'intérieur pour sortir un véhicule, la motorisation est alors automatiquement réalimentée si état off.
=>Ce fonctionnement fait que l'on est souvent présent quand ce rallumage se fait et vu que le PIR signale localement sa détection d'un flash rouge, on peut même voir s'il y a un délai anormal.
En table routing, j'avais assez souvent une suite de 4 ou 5 clic rapides avant que cela reste à On, cela ayant d'ailleurs visiblement provoqué le blocage d'un relais car un précédent modèle du même type était mort en quelques mois et j'avais dû le changer. Le nouveau modèle avait mieux fonctionné au départ, mais très vite ce fut idem.
Depuis que suis en source routing, j'observe que c'est pour le moment toujours 1 clic unique et probable que les séries observées avant résultaient déjà d'un problème de communication?
Ce type de prise n'est pourtant pas nouveau et je n'ai pas vu d'info sur des pb de routage...
Maintenant, je n'ai pas souvenir de pb de détection de capteurs de vibration (et avec ce type de capteur toute la communication visible de l'utilisateur c'est objet->coordinateur) ni remarqué de grosses pauses de remontée de mesures côté prises (toujours dans le sens objet->coordinateur).
Par contre côté commande des prises dans le sens coordinateur->objet il semble que l'on ait eu des retry... alors que la commande initiale (et les retry jusqu'à l'état stable On) semblait pourtant passer (sinon j'aurais à mon sens plutôt eu un clic unique mais notablement retardé vs détection PIR): Cela ressemblerait donc à un pb d'acquittement, sens objet->coordinateur qui semble pourtant globalement fonctionnel quand on n'a pas eu une commande avant.
Vu de dehors, difficile d'en dire plus, mais rien de bien clair côté sens qui poserait plus de problèmes même si à la réflexion, j'aurais peut-être pu tenter de baisser la puissance en TX actuellement réglée au max (cela rendrait peut-être plus clair un pb de bilan radio déséquilibré en RX vs TX) supporté par le coordinateur.
Au moins la conso mémoire ne dérape plus même en table, mais pour le moment je vais en rester à la configuration de routage qui fonctionne bien chez moi... A la prochaine commande d'objets, je commande également un coordinateur et cette fois avec antenne externe puis je referais ces essais avec le nouveau.
Re: Avis sur coordinateur
lost a écrit : 28 juil. 2025, 12:17
Avant ce redémarrage, après ~2j de fonctionnement en source routing, j'avais demandé un rapport de topologie: Il montrait les 3 routeurs en communication directe avec le coordinateur et aucun maillage entre eux, même pour le plus éloigné.
peux-tu passer un export.json ? après la topologie ? Car cela semble indiquer qu'il y a un problème de routage sur ces routers. ce qui expliquerait ton problème en mode Table de Routage.
Le rapport de Topologie interroge la table de routage , la table de voisinage, et la table de end-devices de chaque Main Powered device . Avec ces 3 éléments il en crée le maillage.
Zigbee for Domoticz - Clef zzh-p (electrolama) 45 devices.
Si vous appréciez ce que je fais, vous pouvez contribuer par un don Paypal , ce qui me permettra notamment l'achat d’équipements et de les tester/valider pour le plugin.
Wiki ici
chat sur Keybase.io
Si vous appréciez ce que je fais, vous pouvez contribuer par un don Paypal , ce qui me permettra notamment l'achat d’équipements et de les tester/valider pour le plugin.
Wiki ici
chat sur Keybase.io
Re: Avis sur coordinateur
Hello,
Refait une topologie ce soir toujours en mode source routing et là j'ai du maillage, même si je n'ai qu'un capteur de vibration sur 3 de visible (mais les 3 reportent sans pb) mais les prises ont cette fois du maillage entre elles coté graphique. J'ai des rapports plus anciens, avant changement de coordinateur en mode table qui montraient néanmoins un maillage plus riche même si dysfonctionnel.
Refait une topologie ce soir toujours en mode source routing et là j'ai du maillage, même si je n'ai qu'un capteur de vibration sur 3 de visible (mais les 3 reportent sans pb) mais les prises ont cette fois du maillage entre elles coté graphique. J'ai des rapports plus anciens, avant changement de coordinateur en mode table qui montraient néanmoins un maillage plus riche même si dysfonctionnel.
export.json- (35.84 Kio) Téléchargé 80 fois
Re: Avis sur coordinateur
Salut,
Après qq péripéties lié à un matériel livré qui n'était pas celui commandé, j'ai recu ce matin le nouveau sonoff aussi à base d'EFR32MG24 (au lieu de MG21 pour ma Zi-Stick ZGA008 actuelle) au lieu du SLZB-07MG24 initialement envisagé.
Tenté le coup de ré-écrire sa MAC comme indiqué à la page 1 de ce fil... Mais ce qui avait fonctionné pour la ZGA008 changée en SAV n'a pas fonctionné pour la nouvelle sonoff dongle plus MG24: Le plugin a planté et domoticz a suivi (interface web bloquée, plus aucun log, même si service toujours up).
Tenté de me récupérer sur la ZGA008, en restaurant juste le backup de configuration et en retirant le OverWriteCoordinatorIEEEOnlyOnce de la config et redémarrant le plugin sans réinit: KO.
Tenté de remettre OverWriteCoordinatorIEEEOnlyOnce et redémarré le plugin avec réinit: Pas mieux.
Niveau log Domoticz j'ai
Logs complets plugin avec toute la séquence depuis ce midi attachés. J'espère n'avoir rien irrémédiablement cassé...
Pour info, ce nouveau SonOff est vu ainsi au dmesg:
Et avec les outils silabs:
C'est donc vraiment a priori ce qui se fait de plus récent (et encore, sonoff semble déjà proposer un FW 8.0.2 mais laissé celui d'origine). Au moins, de ce côté ça réponds toujours, mais je ne vais peut-être pas couper à une ré-inclusion de tout avec ce dongle pourvu d'une antenne externe qui, je l'espère, va résoudre mes pb de communication même si le source routing fonctionnait bien avec le ZGA008. Sur ce dernier, par contre, bizarre d'avoir désormais tout à FF niveau MAC etc???
Après qq péripéties lié à un matériel livré qui n'était pas celui commandé, j'ai recu ce matin le nouveau sonoff aussi à base d'EFR32MG24 (au lieu de MG21 pour ma Zi-Stick ZGA008 actuelle) au lieu du SLZB-07MG24 initialement envisagé.
Tenté le coup de ré-écrire sa MAC comme indiqué à la page 1 de ce fil... Mais ce qui avait fonctionné pour la ZGA008 changée en SAV n'a pas fonctionné pour la nouvelle sonoff dongle plus MG24: Le plugin a planté et domoticz a suivi (interface web bloquée, plus aucun log, même si service toujours up).
Tenté de me récupérer sur la ZGA008, en restaurant juste le backup de configuration et en retirant le OverWriteCoordinatorIEEEOnlyOnce de la config et redémarrant le plugin sans réinit: KO.
Tenté de remettre OverWriteCoordinatorIEEEOnlyOnce et redémarré le plugin avec réinit: Pas mieux.
Niveau log Domoticz j'ai
Code : Tout sélectionner
2025-09-25 12:49:49.362 Error: Zi-Stick: Error at startup [Errno 2] No such file or directory: 'null'
2025-09-25 12:49:49.375 Status: Zi-Stick: ++ Assuming new network formed
2025-09-25 12:49:49.377 Status: Zi-Stick: ++ Network settings
2025-09-25 12:49:49.379 Status: Zi-Stick: PAN ID: 0xFFFE
2025-09-25 12:49:49.381 Status: Zi-Stick: Extended PAN ID: ff:ff:ff:ff:ff:ff:ff:ff
2025-09-25 12:49:49.386 Status: Zi-Stick: Channel: 0
2025-09-25 12:49:49.388 Status: Zi-Stick: Channel mask: []
2025-09-25 12:49:49.390 Status: Zi-Stick: NWK update ID: 0
2025-09-25 12:49:49.391 Status: Zi-Stick: Device IEEE: ff:ff:ff:ff:ff:ff:ff:ff
2025-09-25 12:49:49.393 Status: Zi-Stick: Device NWK: 0xFFFE
2025-09-25 12:49:49.396 Status: Zi-Stick: Network key: ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
2025-09-25 12:49:49.398 Status: Zi-Stick: Network key sequence: 0
2025-09-25 12:49:49.400 Status: Zi-Stick: Network key counter: 0
2025-09-25 12:49:49.404 Error: Zi-Stick: Coordinator not correctly initialized - PluginZigbee_47.log
- (519.93 Kio) Téléchargé 46 fois
Code : Tout sélectionner
[25550.929155] usb 9-1.2: new full-speed USB device number 4 using xhci_hcd
[25551.063795] usb 9-1.2: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
[25551.063814] usb 9-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[25551.063822] usb 9-1.2: Product: SONOFF Dongle Plus MG24
[25551.063829] usb 9-1.2: Manufacturer: SONOFF
[25551.063835] usb 9-1.2: SerialNumber: XXXXXXXXXXXXXXXXXXXX
[25551.065521] cp210x 9-1.2:1.0: cp210x converter detected
[25551.077189] usb 9-1.2: cp210x converter now attached to ttyUSB0
Code : Tout sélectionner
elelabs-zigbee-ezsp-utility-master$ venv/bin/python3 Elelabs_EzspFwUtility.py probe -p /dev/ttyUSB0
2025/09/25 13:06:07 Elelabs_EzspFwUtility: Generic Zigbee EZSP adapter detected:
2025/09/25 13:06:07 Elelabs_EzspFwUtility: Firmware: 7.4.5-0
2025/09/25 13:06:07 Elelabs_EzspFwUtility: EZSP v13
Re: Avis sur coordinateur
Hello,
Bon, je suis un peu emmerdé car même en tentant un démarrage, avec ou sans réinit normale pour les 2 coordinateurs, dans les 2 cas cela échoue de manière similaire (le tout, ou quasi, à FF comme ci dessus). Pb plugin, matériel lié a la manip (qui eu déjà fonctionné avec un coordinateur de remplacement strictement identique) pour tenter de migrer sans tout ré-apparier? Je sèche un peu...
Exemple de log, pas très différent de ci dessus...
Bon, je suis un peu emmerdé car même en tentant un démarrage, avec ou sans réinit normale pour les 2 coordinateurs, dans les 2 cas cela échoue de manière similaire (le tout, ou quasi, à FF comme ci dessus). Pb plugin, matériel lié a la manip (qui eu déjà fonctionné avec un coordinateur de remplacement strictement identique) pour tenter de migrer sans tout ré-apparier? Je sèche un peu...
Exemple de log, pas très différent de ci dessus...
Code : Tout sélectionner
2025-09-26 07:16:04,790 INFO :b'Z4D is starting with stable7-7.1.022'
2025-09-26 07:16:04,815 INFO :b'Z4D Database found: DeviceList-47.txt'
2025-09-26 07:16:04,816 INFO :b'Z4D Certified devices database /usr/local/lib/python3.9/dist-packages/z4d_certified_devices/'
2025-09-26 07:16:04,817 INFO :b'Z4D loads ZCL Cluster definitions'
2025-09-26 07:16:04,957 INFO :b'Z4D loaded 16 configuration from legacy database.'
2025-09-26 07:16:04,970 INFO :b'++ Overwrite standard configuration model HK-SENSOR-4IN1-A with /home/domo/domoticz/plugins/Domoticz-Zigbee/Conf/Local-Devices/HK-SENSOR-4IN1-A.json'
2025-09-26 07:16:04,972 INFO :b'Z4D loads 1 configuration from the local certified Db.'
2025-09-26 07:16:06,016 INFO :b'Z4D loads 648 certified devices from repository version [6.473]'
2025-09-26 07:16:06,018 INFO :b'Z4D loading plugin database'
2025-09-26 07:16:06,185 INFO :b'Z4D loads 7 entries from /home/domo/domoticz/plugins/Domoticz-Zigbee/Data/DeviceList-47.txt'
2025-09-26 07:16:06,236 INFO :b"Z4D is starting transport Mode: 'ZigpyEZSP' Serial: 'null' IP: '0.0.0.0 'Port: '9999'"
2025-09-26 07:16:09,643 INFO :b'Z4D starting EZSP'
2025-09-26 07:16:09,645 INFO :b"Radio model ezsp Serial Port: null, Communication specifics: {'SerialMode': 'USB', 'Baudrate': 115200, 'FlowControl': 'hardware'}"
2025-09-26 07:16:09,648 INFO :b'zigpyThread starting with a random sleep'
2025-09-26 07:16:09,650 INFO :b'Z4D starting WebUI on port 9440'
2025-09-26 07:16:09,713 INFO :b'WebUI - server starting on 0.0.0.0 9440'
2025-09-26 07:16:09,714 INFO :b'++ WebUI - create socket'
2025-09-26 07:16:09,716 INFO :b'++ WebUI - SSL Certificate /home/domo/domoticz/plugins/Domoticz-Zigbee/certs/server.crt'
2025-09-26 07:16:09,717 INFO :b'++ WebUI - SSL Private key /home/domo/domoticz/plugins/Domoticz-Zigbee/certs/server.key'
2025-09-26 07:16:09,718 INFO :b"Certificate file '/home/domo/domoticz/plugins/Domoticz-Zigbee/certs/server.crt' does not exist."
2025-09-26 07:16:09,724 INFO :b'++ WebUI - bin socket on 0.0.0.0:9440'
2025-09-26 07:16:09,725 INFO :b'WebUI Server started on 0.0.0.0:9440'
2025-09-26 07:16:10,318 INFO :b'Plugin looks to upgrade the Certified Device package'
2025-09-26 07:16:12,484 DEBUG :Using selector: EpollSelector
2025-09-26 07:16:13,745 INFO :b'++ Enables boost power mode and the alternate transmitter output.'
2025-09-26 07:16:13,751 INFO :b"++ Started radio ezsp port: null config {'device': {'path': 'null', 'baudrate': 115200, 'flow_control': 'hardware'}, 'network': {}, 'ezsp_config': {'CONFIG_TX_POWER_MODE': 3}, 'ota': {}, 'handle_unknown_devices': True}"
2025-09-26 07:16:13,771 INFO :b'++ Use of Zigpy Persistent Db'
2025-09-26 07:16:13,845 WARNING :Executing <Task pending name='Task-21' coro=<start_zigpy_task() running at /home/domo/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/zigpyThread.py:155> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7f424880a0>()] created at /usr/lib/python3.9/asyncio/base_events.py:424> cb=[_run_until_complete_cb() at /usr/lib/python3.9/asyncio/base_events.py:184] created at /usr/lib/python3.9/asyncio/base_events.py:621> took 1.293 seconds
2025-09-26 07:16:17,243 DEBUG :Using selector: EpollSelector
2025-09-26 07:16:17,270 ERROR :Couldn't start application
Traceback (most recent call last):
File "/home/domo/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/AppBellows.py", line 77, in startup
await self.connect()
File "/usr/local/lib/python3.9/dist-packages/bellows/zigbee/application.py", line 154, in connect
await self._ezsp.connect(use_thread=self.config[CONF_USE_THREAD])
File "/usr/local/lib/python3.9/dist-packages/bellows/ezsp/__init__.py", line 134, in connect
self._gw = await bellows.uart.connect(self._config, self, use_thread=use_thread)
File "/usr/local/lib/python3.9/dist-packages/bellows/uart.py", line 146, in connect
protocol, connection_done = await thread.run_coroutine_threadsafe(
File "/usr/local/lib/python3.9/dist-packages/bellows/uart.py", line 125, in _connect
transport, _ = await zigpy.serial.create_serial_connection(
File "/usr/local/lib/python3.9/dist-packages/zigpy/serial.py", line 138, in create_serial_connection
raise exc.__context__ from None
File "/usr/local/lib/python3.9/dist-packages/serial/serialposix.py", line 322, in open
self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
FileNotFoundError: [Errno 2] No such file or directory: 'null'
2025-09-26 07:16:17,321 ERROR :AppGeneric backup failed
Traceback (most recent call last):
File "/home/domo/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/AppBellows.py", line 77, in startup
await self.connect()
File "/usr/local/lib/python3.9/dist-packages/bellows/zigbee/application.py", line 154, in connect
await self._ezsp.connect(use_thread=self.config[CONF_USE_THREAD])
File "/usr/local/lib/python3.9/dist-packages/bellows/ezsp/__init__.py", line 134, in connect
self._gw = await bellows.uart.connect(self._config, self, use_thread=use_thread)
File "/usr/local/lib/python3.9/dist-packages/bellows/uart.py", line 146, in connect
protocol, connection_done = await thread.run_coroutine_threadsafe(
File "/usr/local/lib/python3.9/dist-packages/bellows/uart.py", line 125, in _connect
transport, _ = await zigpy.serial.create_serial_connection(
File "/usr/local/lib/python3.9/dist-packages/zigpy/serial.py", line 138, in create_serial_connection
raise exc.__context__ from None
File "/usr/local/lib/python3.9/dist-packages/serial/serialposix.py", line 322, in open
self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
FileNotFoundError: [Errno 2] No such file or directory: 'null'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/domo/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/AppGeneric.py", line 156, in shutdown
backup_coordinator = await self.backups.create_backup(load_devices=True)
File "/usr/local/lib/python3.9/dist-packages/zigpy/backups.py", line 143, in create_backup
await self.app.load_network_info(load_devices=load_devices)
File "/usr/local/lib/python3.9/dist-packages/bellows/zigbee/application.py", line 253, in load_network_info
await self._ensure_network_running()
File "/usr/local/lib/python3.9/dist-packages/bellows/zigbee/application.py", line 171, in _ensure_network_running
(state,) = await self._ezsp.networkState()
AttributeError: 'NoneType' object has no attribute 'networkState'
2025-09-26 07:16:20,392 ERROR : [ZigpyCom_47 258602] [ TransportZigpy] Error at startup [Errno 2] No such file or directory: 'null'
2025-09-26 07:16:20,407 INFO :b'++ Network settings'
2025-09-26 07:16:20,409 INFO :b' PAN ID: 0xFFFE'
2025-09-26 07:16:20,411 INFO :b' Extended PAN ID: ff:ff:ff:ff:ff:ff:ff:ff'
2025-09-26 07:16:20,413 INFO :b' Channel: 0'
2025-09-26 07:16:20,415 INFO :b' Channel mask: []'
2025-09-26 07:16:20,416 INFO :b' NWK update ID: 0'
2025-09-26 07:16:20,418 INFO :b' Device IEEE: ff:ff:ff:ff:ff:ff:ff:ff'
2025-09-26 07:16:20,419 INFO :b' Device NWK: 0xFFFE'
2025-09-26 07:16:20,421 INFO :b' Network key: ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff'
2025-09-26 07:16:20,423 INFO :b' Network key sequence: 0'
2025-09-26 07:16:20,425 INFO :b' Network key counter: 0'
2025-09-26 07:16:20,468 ERROR : [ZigpyForwarder_47 258603] [ Input] Coordinator not correctly initialized
2025-09-26 07:16:35,375 INFO :b'Certified Device package upgrade results'
2025-09-26 07:16:35,376 INFO :b'Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple'
2025-09-26 07:16:35,376 INFO :b'Requirement already satisfied: z4d-certified-devices in /usr/local/lib/python3.9/dist-packages (6.473)'
2025-09-26 07:16:35,377 INFO :b'Collecting z4d-certified-devices'
2025-09-26 07:16:35,377 INFO :b' Using cached https://www.piwheels.org/simple/z4d-certified-devices/z4d_certified_devices-6.473-py3-none-any.whl (448 kB)'
2025-09-26 07:16:35,378 INFO :b' Using cached https://www.piwheels.org/simple/z4d-certified-devices/z4d_certified_devices-6.472-py3-none-any.whl (448 kB)'
2025-09-26 07:16:35,379 INFO :b''
2025-09-26 07:16:35,379 INFO :b'Z4D Widgets usage is at 9.4% (231 units free)'
2025-09-26 07:16:35,381 INFO :b'Z4D started with Domoticz legacy Framework'
2025-09-26 07:16:59,228 DEBUG :Starting new HTTPS connection (1): z4d.pipiche.net:443
2025-09-26 07:16:59,768 DEBUG :https://z4d.pipiche.net:443 "GET /matomo.php?idsite=9&rec=1&apiv=1&action_name=Plugin+Action&uid=686dcc3fbf0e02b45dd8ff5ac44d78e7070d2ec9b6294ce7cebfbbc03d9e8126&e_c=Plugin&e_a=Shutdown&e_n=Plugin+Shutdown HTTP/1.1" 200 43
2025-09-26 07:17:00,088 DEBUG :Starting new HTTPS connection (1): z4d.pipiche.net:443
2025-09-26 07:17:00,576 DEBUG :https://z4d.pipiche.net:443 "GET /matomo.php?idsite=9&rec=1&apiv=1&action_name=Z4DPluginInfos&uid=686dcc3fbf0e02b45dd8ff5ac44d78e7070d2ec9b6294ce7cebfbbc03d9e8126&dimension1=2025.1&dimension3=7.1.022&dimension5=Small&dimension6=6.473&dimension7=Debian+GNU+Linux+11&dimension8=python+3.9.2+arch+64bit+machine+aarch64+processor&dimension9=1+day&dimension11=Raspberry+Pi+3+Model+B+Rev+1.2 HTTP/1.1" 200 43
2025-09-26 07:17:00,589 INFO :b'Flushing plugin database onto disk'
2025-09-26 07:17:00,602 INFO :b'onStop called'
2025-09-26 07:17:00,603 INFO :b'onStop called shutding down CIE connection and transport thread'
2025-09-26 07:17:00,604 INFO :b'Forwarder thread stop in progress...'
2025-09-26 07:17:00,604 INFO :b'++ Forwarder thread stopped. [1/3]'
2025-09-26 07:17:00,700 ERROR :AppGeneric backup failed
Traceback (most recent call last):
File "/home/domo/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/AppGeneric.py", line 156, in shutdown
backup_coordinator = await self.backups.create_backup(load_devices=True)
File "/usr/local/lib/python3.9/dist-packages/zigpy/backups.py", line 143, in create_backup
await self.app.load_network_info(load_devices=load_devices)
File "/usr/local/lib/python3.9/dist-packages/bellows/zigbee/application.py", line 253, in load_network_info
await self._ensure_network_running()
File "/usr/local/lib/python3.9/dist-packages/bellows/zigbee/application.py", line 171, in _ensure_network_running
(state,) = await self._ezsp.networkState()
AttributeError: 'NoneType' object has no attribute 'networkState'
2025-09-26 07:17:00,702 WARNING :Failed to disconnect from database
Traceback (most recent call last):
File "/usr/local/lib/python3.9/dist-packages/zigpy/application.py", line 433, in shutdown
await self._dblistener.shutdown()
File "/usr/local/lib/python3.9/dist-packages/zigpy/appdb.py", line 197, in shutdown
await self._set_isolation_level(None)
File "/usr/local/lib/python3.9/dist-packages/zigpy/appdb.py", line 215, in _set_isolation_level
await self._db._execute(lambda: setattr(self._db, "isolation_level", level))
File "/usr/local/lib/python3.9/dist-packages/aiosqlite/core.py", line 125, in _execute
raise ValueError("Connection closed")
ValueError: Connection closed
2025-09-26 07:17:04,718 DEBUG :Close <_UnixSelectorEventLoop running=False closed=False debug=True>
2025-09-26 07:17:04,724 INFO :b'Event loop closed successfully in zigpy_thread.'
2025-09-26 07:17:04,726 INFO :b'++ Zigpy thread stopped. [2/3]'
2025-09-26 07:17:04,728 INFO :b'Zigpy transport threads shutdown attempted'
2025-09-26 07:17:04,729 INFO :b'WebUI shutdown in process...'
2025-09-26 07:17:09,770 INFO :b'Closing all WebUI client connections...'
2025-09-26 07:17:09,774 INFO :b'WebUI - server stopped'
2025-09-26 07:17:49,263 INFO :b'Z4D is starting with stable7-7.1.022'
2025-09-26 07:17:49,287 INFO :b'Z4D Database found: DeviceList-47.txt'
2025-09-26 07:17:49,288 INFO :b'Z4D Certified devices database /usr/local/lib/python3.9/dist-packages/z4d_certified_devices/'
2025-09-26 07:17:49,289 INFO :b'Z4D loads ZCL Cluster definitions'
2025-09-26 07:17:49,411 INFO :b'Z4D loaded 16 configuration from legacy database.'
2025-09-26 07:17:49,418 INFO :b'++ Overwrite standard configuration model HK-SENSOR-4IN1-A with /home/domo/domoticz/plugins/Domoticz-Zigbee/Conf/Local-Devices/HK-SENSOR-4IN1-A.json'
2025-09-26 07:17:49,420 INFO :b'Z4D loads 1 configuration from the local certified Db.'
2025-09-26 07:17:50,409 INFO :b'Z4D loads 648 certified devices from repository version [6.473]'
2025-09-26 07:17:50,411 INFO :b'Z4D loading plugin database'
2025-09-26 07:17:50,577 INFO :b'Z4D loads 7 entries from /home/domo/domoticz/plugins/Domoticz-Zigbee/Data/DeviceList-47.txt'
2025-09-26 07:17:50,598 INFO :b"Z4D is starting transport Mode: 'ZigpyEZSP' Serial: 'null' IP: '0.0.0.0 'Port: '9999'"
2025-09-26 07:17:53,744 INFO :b'Z4D starting EZSP'
2025-09-26 07:17:53,746 INFO :b"Radio model ezsp Serial Port: null, Communication specifics: {'SerialMode': 'USB', 'Baudrate': 115200, 'FlowControl': 'hardware'}"
2025-09-26 07:17:53,753 INFO :b'zigpyThread starting with a random sleep'
2025-09-26 07:17:53,759 INFO :b'Z4D starting WebUI on port 9440'
2025-09-26 07:17:53,808 INFO :b'WebUI - server starting on 0.0.0.0 9440'
2025-09-26 07:17:53,809 INFO :b'++ WebUI - create socket'
2025-09-26 07:17:53,811 INFO :b'++ WebUI - SSL Certificate /home/domo/domoticz/plugins/Domoticz-Zigbee/certs/server.crt'
2025-09-26 07:17:53,817 INFO :b'++ WebUI - SSL Private key /home/domo/domoticz/plugins/Domoticz-Zigbee/certs/server.key'
2025-09-26 07:17:53,818 INFO :b"Certificate file '/home/domo/domoticz/plugins/Domoticz-Zigbee/certs/server.crt' does not exist."
2025-09-26 07:17:53,819 INFO :b'++ WebUI - bin socket on 0.0.0.0:9440'
2025-09-26 07:17:53,848 INFO :b'WebUI Server started on 0.0.0.0:9440'
2025-09-26 07:17:54,279 INFO :b'Plugin looks to upgrade the Certified Device package'
2025-09-26 07:17:56,529 DEBUG :Using selector: EpollSelector
2025-09-26 07:17:57,679 INFO :b'++ Enables boost power mode and the alternate transmitter output.'
2025-09-26 07:17:57,684 INFO :b"++ Started radio ezsp port: null config {'device': {'path': 'null', 'baudrate': 115200, 'flow_control': 'hardware'}, 'network': {}, 'ezsp_config': {'CONFIG_TX_POWER_MODE': 3}, 'ota': {}, 'handle_unknown_devices': True}"
2025-09-26 07:17:57,687 INFO :b'++ Coordinator initialisation requested Channel 20(0x14) ExtendedPanId: 0x0000000000000000'
2025-09-26 07:17:57,688 INFO :b'++ Use of Zigpy Persistent Db'
2025-09-26 07:17:57,779 WARNING :Executing <Task pending name='Task-25' coro=<start_zigpy_task() running at /home/domo/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/zigpyThread.py:155> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7f42036f10>()] created at /usr/lib/python3.9/asyncio/base_events.py:424> cb=[_run_until_complete_cb() at /usr/lib/python3.9/asyncio/base_events.py:184] created at /usr/lib/python3.9/asyncio/base_events.py:621> took 1.179 seconds
2025-09-26 07:18:01,202 DEBUG :Using selector: EpollSelector
2025-09-26 07:18:01,229 ERROR :Couldn't start application
Traceback (most recent call last):
File "/home/domo/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/AppBellows.py", line 77, in startup
await self.connect()
File "/usr/local/lib/python3.9/dist-packages/bellows/zigbee/application.py", line 154, in connect
await self._ezsp.connect(use_thread=self.config[CONF_USE_THREAD])
File "/usr/local/lib/python3.9/dist-packages/bellows/ezsp/__init__.py", line 134, in connect
self._gw = await bellows.uart.connect(self._config, self, use_thread=use_thread)
File "/usr/local/lib/python3.9/dist-packages/bellows/uart.py", line 146, in connect
protocol, connection_done = await thread.run_coroutine_threadsafe(
File "/usr/local/lib/python3.9/dist-packages/bellows/uart.py", line 125, in _connect
transport, _ = await zigpy.serial.create_serial_connection(
File "/usr/local/lib/python3.9/dist-packages/zigpy/serial.py", line 138, in create_serial_connection
raise exc.__context__ from None
File "/usr/local/lib/python3.9/dist-packages/serial/serialposix.py", line 322, in open
self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
FileNotFoundError: [Errno 2] No such file or directory: 'null'
2025-09-26 07:18:01,270 ERROR :AppGeneric backup failed
Traceback (most recent call last):
File "/home/domo/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/AppBellows.py", line 77, in startup
await self.connect()
File "/usr/local/lib/python3.9/dist-packages/bellows/zigbee/application.py", line 154, in connect
await self._ezsp.connect(use_thread=self.config[CONF_USE_THREAD])
File "/usr/local/lib/python3.9/dist-packages/bellows/ezsp/__init__.py", line 134, in connect
self._gw = await bellows.uart.connect(self._config, self, use_thread=use_thread)
File "/usr/local/lib/python3.9/dist-packages/bellows/uart.py", line 146, in connect
protocol, connection_done = await thread.run_coroutine_threadsafe(
File "/usr/local/lib/python3.9/dist-packages/bellows/uart.py", line 125, in _connect
transport, _ = await zigpy.serial.create_serial_connection(
File "/usr/local/lib/python3.9/dist-packages/zigpy/serial.py", line 138, in create_serial_connection
raise exc.__context__ from None
File "/usr/local/lib/python3.9/dist-packages/serial/serialposix.py", line 322, in open
self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
FileNotFoundError: [Errno 2] No such file or directory: 'null'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/domo/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/AppGeneric.py", line 156, in shutdown
backup_coordinator = await self.backups.create_backup(load_devices=True)
File "/usr/local/lib/python3.9/dist-packages/zigpy/backups.py", line 143, in create_backup
await self.app.load_network_info(load_devices=load_devices)
File "/usr/local/lib/python3.9/dist-packages/bellows/zigbee/application.py", line 253, in load_network_info
await self._ensure_network_running()
File "/usr/local/lib/python3.9/dist-packages/bellows/zigbee/application.py", line 171, in _ensure_network_running
(state,) = await self._ezsp.networkState()
AttributeError: 'NoneType' object has no attribute 'networkState'
2025-09-26 07:18:04,315 ERROR : [ZigpyCom_47 258815] [ TransportZigpy] Error at startup [Errno 2] No such file or directory: 'null'
2025-09-26 07:18:04,331 INFO :b'++ Assuming new network formed'
2025-09-26 07:18:04,334 INFO :b'++ Network settings'
2025-09-26 07:18:04,337 INFO :b' PAN ID: 0xFFFE'
2025-09-26 07:18:04,340 INFO :b' Extended PAN ID: ff:ff:ff:ff:ff:ff:ff:ff'
2025-09-26 07:18:04,343 INFO :b' Channel: 0'
2025-09-26 07:18:04,345 INFO :b' Channel mask: []'
2025-09-26 07:18:04,348 INFO :b' NWK update ID: 0'
2025-09-26 07:18:04,351 INFO :b' Device IEEE: ff:ff:ff:ff:ff:ff:ff:ff'
2025-09-26 07:18:04,354 INFO :b' Device NWK: 0xFFFE'
2025-09-26 07:18:04,357 INFO :b' Network key: ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff'
2025-09-26 07:18:04,359 INFO :b' Network key sequence: 0'
2025-09-26 07:18:04,363 INFO :b' Network key counter: 0'
2025-09-26 07:18:04,369 ERROR : [ZigpyForwarder_47 258816] [ Input] Coordinator not correctly initialized
2025-09-26 07:18:16,372 INFO :b'Certified Device package upgrade results'
2025-09-26 07:18:16,372 INFO :b'Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple'
2025-09-26 07:18:16,373 INFO :b'Requirement already satisfied: z4d-certified-devices in /usr/local/lib/python3.9/dist-packages (6.473)'
2025-09-26 07:18:16,374 INFO :b'Collecting z4d-certified-devices'
2025-09-26 07:18:16,374 INFO :b' Using cached https://www.piwheels.org/simple/z4d-certified-devices/z4d_certified_devices-6.473-py3-none-any.whl (448 kB)'
2025-09-26 07:18:16,375 INFO :b' Using cached https://www.piwheels.org/simple/z4d-certified-devices/z4d_certified_devices-6.472-py3-none-any.whl (448 kB)'
2025-09-26 07:18:16,376 INFO :b''
2025-09-26 07:18:16,376 INFO :b'Z4D Widgets usage is at 9.4% (231 units free)'
2025-09-26 07:18:16,377 INFO :b'Z4D started with Domoticz legacy Framework'
2025-09-26 07:18:48,505 DEBUG :Starting new HTTPS connection (1): z4d.pipiche.net:443
2025-09-26 07:18:49,043 DEBUG :https://z4d.pipiche.net:443 "GET /matomo.php?idsite=9&rec=1&apiv=1&action_name=Plugin+Action&uid=686dcc3fbf0e02b45dd8ff5ac44d78e7070d2ec9b6294ce7cebfbbc03d9e8126&e_c=Plugin&e_a=Shutdown&e_n=Plugin+Shutdown HTTP/1.1" 200 43
2025-09-26 07:18:49,223 DEBUG :Starting new HTTPS connection (1): z4d.pipiche.net:443
2025-09-26 07:18:49,702 DEBUG :https://z4d.pipiche.net:443 "GET /matomo.php?idsite=9&rec=1&apiv=1&action_name=Z4DPluginInfos&uid=686dcc3fbf0e02b45dd8ff5ac44d78e7070d2ec9b6294ce7cebfbbc03d9e8126&dimension1=2025.1&dimension3=7.1.022&dimension5=Small&dimension6=6.473&dimension7=Debian+GNU+Linux+11&dimension8=python+3.9.2+arch+64bit+machine+aarch64+processor&dimension9=1+day&dimension11=Raspberry+Pi+3+Model+B+Rev+1.2 HTTP/1.1" 200 43
2025-09-26 07:18:49,715 INFO :b'Flushing plugin database onto disk'
2025-09-26 07:18:49,727 INFO :b'onStop called'
2025-09-26 07:18:49,728 INFO :b'onStop called shutding down CIE connection and transport thread'
2025-09-26 07:18:49,729 INFO :b'Forwarder thread stop in progress...'
2025-09-26 07:18:49,729 INFO :b'++ Forwarder thread stopped. [1/3]'
2025-09-26 07:18:49,827 ERROR :AppGeneric backup failed
Traceback (most recent call last):
File "/home/domo/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/AppGeneric.py", line 156, in shutdown
backup_coordinator = await self.backups.create_backup(load_devices=True)
File "/usr/local/lib/python3.9/dist-packages/zigpy/backups.py", line 143, in create_backup
await self.app.load_network_info(load_devices=load_devices)
File "/usr/local/lib/python3.9/dist-packages/bellows/zigbee/application.py", line 253, in load_network_info
await self._ensure_network_running()
File "/usr/local/lib/python3.9/dist-packages/bellows/zigbee/application.py", line 171, in _ensure_network_running
(state,) = await self._ezsp.networkState()
AttributeError: 'NoneType' object has no attribute 'networkState'
2025-09-26 07:18:49,829 WARNING :Failed to disconnect from database
Traceback (most recent call last):
File "/usr/local/lib/python3.9/dist-packages/zigpy/application.py", line 433, in shutdown
await self._dblistener.shutdown()
File "/usr/local/lib/python3.9/dist-packages/zigpy/appdb.py", line 197, in shutdown
await self._set_isolation_level(None)
File "/usr/local/lib/python3.9/dist-packages/zigpy/appdb.py", line 215, in _set_isolation_level
await self._db._execute(lambda: setattr(self._db, "isolation_level", level))
File "/usr/local/lib/python3.9/dist-packages/aiosqlite/core.py", line 125, in _execute
raise ValueError("Connection closed")
ValueError: Connection closed
2025-09-26 07:18:53,845 DEBUG :Close <_UnixSelectorEventLoop running=False closed=False debug=True>
2025-09-26 07:18:53,850 INFO :b'Event loop closed successfully in zigpy_thread.'
2025-09-26 07:18:53,852 INFO :b'++ Zigpy thread stopped. [2/3]'
2025-09-26 07:18:53,853 INFO :b'Zigpy transport threads shutdown attempted'
2025-09-26 07:18:53,855 INFO :b'WebUI shutdown in process...'
2025-09-26 07:18:53,891 INFO :b'Closing all WebUI client connections...'
2025-09-26 07:18:53,893 INFO :b'WebUI - server stopped'
2025-09-26 07:18:54,854 INFO :b'++ WebUI shutdown completed [3/3]'
Re: Avis sur coordinateur
le fait que tout soit à FF est que on a pas réussi à lire quoi que ce soit.
Es-tu certain qu'il faille le flow control Hardware ?
si on regarde les logs, c'est la liaison série qui n'arrive pas a etre mis en place. Donc soit Y-a un soucis sur Vitesse ou Hardware flow, ou alors tu as un autre process qui a la liaison serie dejà ouverte et qui bloque.
Es-tu certain qu'il faille le flow control Hardware ?
si on regarde les logs, c'est la liaison série qui n'arrive pas a etre mis en place. Donc soit Y-a un soucis sur Vitesse ou Hardware flow, ou alors tu as un autre process qui a la liaison serie dejà ouverte et qui bloque.
Code : Tout sélectionner
Traceback (most recent call last):
File "/home/domo/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/AppBellows.py", line 77, in startup
await self.connect()
File "/usr/local/lib/python3.9/dist-packages/bellows/zigbee/application.py", line 154, in connect
await self._ezsp.connect(use_thread=self.config[CONF_USE_THREAD])
File "/usr/local/lib/python3.9/dist-packages/bellows/ezsp/__init__.py", line 134, in connect
self._gw = await bellows.uart.connect(self._config, self, use_thread=use_thread)
File "/usr/local/lib/python3.9/dist-packages/bellows/uart.py", line 146, in connect
protocol, connection_done = await thread.run_coroutine_threadsafe(
File "/usr/local/lib/python3.9/dist-packages/bellows/uart.py", line 125, in _connect
transport, _ = await zigpy.serial.create_serial_connection(
File "/usr/local/lib/python3.9/dist-packages/zigpy/serial.py", line 138, in create_serial_connection
raise exc.__context__ from None
File "/usr/local/lib/python3.9/dist-packages/serial/serialposix.py", line 322, in open
self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
FileNotFoundError: [Errno 2] No such file or directory: 'null'Zigbee for Domoticz - Clef zzh-p (electrolama) 45 devices.
Si vous appréciez ce que je fais, vous pouvez contribuer par un don Paypal , ce qui me permettra notamment l'achat d’équipements et de les tester/valider pour le plugin.
Wiki ici
chat sur Keybase.io
Si vous appréciez ce que je fais, vous pouvez contribuer par un don Paypal , ce qui me permettra notamment l'achat d’équipements et de les tester/valider pour le plugin.
Wiki ici
chat sur Keybase.io
Re: Avis sur coordinateur
Salut, sur le nouveau coordinateur (sonoff mg24), je ne sais à vrai dire pas ce qu'il en est... mais le pb est qu'en rebasculant les règles udev pour le persistent USB et en remettant l'ancien (zga008), c'est idem: Je viens de refaire l'essai ce matin et y'a même eu un redémarrage du PI depuis les précédents essais au cas ou le "udevadm control --reload" de prise en compte n'ait pas fonctionné. Mais à l'usage j'ai toujours vu le lien du ttyUSB11 persistant se faire vers le ttyUSBx du dongle branché.
Il y a peut-être eu néanmoins un gag au 1er essai: Plugin relancé avec règle udev non rechargée qui ne m'a visiblement pas fait pointer vers le nouveau mais l'ancien (que j'avais laissé branché), avec la config pour ré-écrire la MAC... J'espère que ce n'est pas cela qui a amorcé la suite d'ennuis... Cela correspond au 1er redémarrage dans le 1er log fourni ci dessus.
Ci joint les logs du ré-essai de ce matin, avec l'ancien coordinateur dont je suis certain de la config série et après avoir remis le fichier de backup sauvegardé au tout début: Idem.
Il y a peut-être eu néanmoins un gag au 1er essai: Plugin relancé avec règle udev non rechargée qui ne m'a visiblement pas fait pointer vers le nouveau mais l'ancien (que j'avais laissé branché), avec la config pour ré-écrire la MAC... J'espère que ce n'est pas cela qui a amorcé la suite d'ennuis... Cela correspond au 1er redémarrage dans le 1er log fourni ci dessus.
Ci joint les logs du ré-essai de ce matin, avec l'ancien coordinateur dont je suis certain de la config série et après avoir remis le fichier de backup sauvegardé au tout début: Idem.
- Pièces jointes
-
- PluginZigbee_47_sav250928_1.log
- (11.95 Kio) Téléchargé 44 fois
Re: Avis sur coordinateur
Les logs ci-après montre que le PATH d'acces était vide !
Code : Tout sélectionner
Started radio ezsp port: null config {'device': {'path': 'null', 'baudrate': 115200, 'flow_control': 'hardware'}, 'network': {}, 'ezsp_config': {'CONFIG_TX_POWER_MODE': 3}, 'ota': {}, 'handle_unknown_devices': True}"
2025-09-28 07:10:02,060 INFO :b'++ Use of Zigpy Persistent Db'
2025-09-28 07:10:02,149 WARNING :Executing <Task pending name='Task-1' coro=<start_zigpy_task() running at /home/domo/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/zigpyThread.py:155> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7f29e0a7f0>()] created at /usr/lib/python3.9/asyncio/base_events.py:424> cb=[_run_until_complete_cb() at /usr/lib/python3.9/asyncio/base_events.py:184] created at /usr/lib/python3.9/asyncio/base_events.py:621> took 1.383 seconds
2025-09-28 07:10:05,561 DEBUG :Using selector: EpollSelector
2025-09-28 07:10:05,589 ERROR :Couldn't start application
Traceback (most recent call last):
File "/home/domo/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/AppBellows.py", line 77, in startup
await self.connect()
File "/usr/local/lib/python3.9/dist-packages/bellows/zigbee/application.py", line 154, in connect
await self._ezsp.connect(use_thread=self.config[CONF_USE_THREAD])
File "/usr/local/lib/python3.9/dist-packages/bellows/ezsp/__init__.py", line 134, in connect
self._gw = await bellows.uart.connect(self._config, self, use_thread=use_thread)
File "/usr/local/lib/python3.9/dist-packages/bellows/uart.py", line 146, in connect
protocol, connection_done = await thread.run_coroutine_threadsafe(
File "/usr/local/lib/python3.9/dist-packages/bellows/uart.py", line 125, in _connect
transport, _ = await zigpy.serial.create_serial_connection(
File "/usr/local/lib/python3.9/dist-packages/zigpy/serial.py", line 138, in create_serial_connection
raise exc.__context__ from None
File "/usr/local/lib/python3.9/dist-packages/serial/serialposix.py", line 322, in open
self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
FileNotFoundError: [Errno 2] No such file or directory: 'null'
2025-09-28 07:10:05,647 ERROR :AppGeneric backup failed
Traceback (most recent call last):Zigbee for Domoticz - Clef zzh-p (electrolama) 45 devices.
Si vous appréciez ce que je fais, vous pouvez contribuer par un don Paypal , ce qui me permettra notamment l'achat d’équipements et de les tester/valider pour le plugin.
Wiki ici
chat sur Keybase.io
Si vous appréciez ce que je fais, vous pouvez contribuer par un don Paypal , ce qui me permettra notamment l'achat d’équipements et de les tester/valider pour le plugin.
Wiki ici
chat sur Keybase.io
Re: Avis sur coordinateur
Oh merde, merci! Pourtant j'ai pas souvenir d'y avoir touché étant en persistent USB.... Et in-fine j'avais pas vu l'éléphant dans le couloir.
Au moins ça refonctionne avec l'ancien coordinateur, je reprendrais la migration dès que j'ai un peu de temps.
Par contre, ôte moi d'un doute: A relire le message en p1 sur la migration en reprenant l'adresse d'un ancien coordinateur, le "only once" c'est que ce n'est possible qu'une seule fois car protégé visiblement. La question c'est si on recommence c'est juste refusé et on se tape les réinclusions... ou risque d'avoir effacé un inventory et matos HS?
J'ai craint un moment, ici, d'être dans le 2nd cas je dirais...
Au moins ça refonctionne avec l'ancien coordinateur, je reprendrais la migration dès que j'ai un peu de temps.
Par contre, ôte moi d'un doute: A relire le message en p1 sur la migration en reprenant l'adresse d'un ancien coordinateur, le "only once" c'est que ce n'est possible qu'une seule fois car protégé visiblement. La question c'est si on recommence c'est juste refusé et on se tape les réinclusions... ou risque d'avoir effacé un inventory et matos HS?
J'ai craint un moment, ici, d'être dans le 2nd cas je dirais...