Mon installation a presque 5 ans et a toujours fonctionné correctement.
Suite à des pertes de liaisons avec certains périphériques et des ralentissements zwave j'ai lancé le week-end dernier (il y a 7 jours) une optimisation nocturne des tous les périphériques de mon installation.
Depuis, le zwave n'est plus fonctionnel, quand un périphérique répond, c'est au mieux 10 mns après la commande. La plupart du temps ça ne répond pas. Les 2 premiers jours, j'ai mis ça sur l'optimisation qui continuait probablement (j'ai beaucoup de périphériques zwave), mais au bout de trois jours, j'ai jeté un œil à la table de routage : les routes prises n'ont aucun sens. Certains périphériques sur secteur sont listés injoignables par la box alors qu'ils sont a trois mètres de celle-ci et ont toujours fonctionné en lien direct avant. Pour certains il peut y avoir 4 'sauts' avant de ne pas arriver au périphérique. Sachant que certains sauts n'ont aucun sens : les périphériques concernés sont à l'opposé physiquement et plusieurs autres périphériques plus proches/directs sont disponibles et non utilisés.
Je constate également que quasiment plus aucun périphérique sur pile ne communique avec la box depuis plusieurs jours.
J'ai fait hier matin une restauration matérielle en suivant la procédure décrite ici : https://doc.eedomus.com/view/Restaurati ... 3%a9rielle
Ca n'est pas mieux.
Ci-dessous un extrait du log zwave après que j'ai lancé l'optimisation sur un périphérique seul qui utilise une route non optimale.
- Code : Tout sélectionner
[12:49:17.728] ## DEBUG: Waiting a few seconds...
[12:49:21.065] Done waiting.
[12:49:21.067] Command class asked on node #16 (controller_module_id=218960)
[12:49:21.067] ## DEBUG: Writing queue command [/var/inbox/zwave_queue/16/cmd_2020.03.21_12.49.21_66996.req]
[12:49:21.068] ## DEBUG: Read command from queued file [/var/inbox/zwave_queue/16/cmd_2020.03.21_12.49.21_66996.req].
[12:49:21.069] Creating request [/mnt/flash/puch/outbox/2020.03.21_12.49.21_68736_adm12784302_2.req]
[12:49:21.069] Executing command class on node #16 -> [12:49:21.070] ## INFO: This is a special eedomus command class for node optimization, doing it now.
[12:49:21.070] Rediscovering neighbors of node #16
[12:49:21.071] -> [01][05][00][48][10][20][82]
[12:49:21.071] <- No response from serial port
.....................
[12:49:22.787] ## DEBUG: no_response = 21, continuing.
[12:49:22.787] Soft resetting...
[12:49:22.788] -> [01][03][00][08][F4]
[12:49:22.788] <- No response from serial port
.....................
[12:49:24.601] ## DEBUG: no_response = 21, continuing.
Done.
[12:49:26.602] Rediscovering neighbors of node #16 (Attempt 2/3)
[12:49:26.603] -> [01][05][00][48][10][21][83]
[12:49:26.603] <- No response from serial port
.....................
[12:49:28.318] ## ERROR: Hard reseting Z-Wave chipset
[12:49:28.319] Creating request from 'putReq' [/mnt/flash/puch/outbox/0_2020.03.21_12.49.28_318846_cm0.req]
[12:49:28.320] Hard resetting...
[12:49:28.320] ## INFO: -> '/mnt/flash/root/zwave_reset.sh'
Reseting Z-Wave
Done.
[12:49:29.144] ## INFO: -> 'php /mnt/flash/root/puch_restart_all.php --from=daemon_zwave.php --detail=SendData'
_____________________________________________________________________________________________
[12:49:29.318] --------- Killed by killProcess() from [puch_restart_all --from=daemon_zwave.php --detail=SendData] [3836] ---------
Je vois très souvent dans les logs ce
- Code : Tout sélectionner
[12:49:28.318] ## ERROR: Hard reseting Z-Wave chipset
Ceci avant et après la restauration.
Est-ce que ça peut indiquer un souci matériel ?
J'ai ouvert un ticket auprès du support, mais si quelqu'un ici a une idée de chose à tenter/vérifier, je suis preneur.
Merci et bon courage pour les semaines à venir
.