Des nouvelles, des bonnes en plus.
Suite à un petit souci décrit ici SensorBinary report non reçu avec Fibaro Motion Sensor
J’ai utilisé l’info Burglar (classe 113) au lieu du Sensor Binary (classe 48) pour connaître l’état du capteur de mouvement de façon plus sûre que 99.5% 
Ensuite, je me suis rappelé que pour ces modules Fibaro Motion Sensor, j’avais rajouté dans le fichier config ceci
<!-- COMMAND_CLASS_ALARM (0x71) AlarmCmd_Get not supported -->
<CommandClass id="113" getsupported="false"/>
Et bien, il n’y a pas de AlarmCmd_Get lors du réveil du module comme prévu mais openzwave continue de recevoir les valeurs des paramètres de la classe 113. Donc, avec un getsupported="false dans la config du module, ça fonctionne tout de même 
Ainsi, j’ai fait de même pour tous les capteurs de portes. Même avec un getsupported="false pour la classe 113, les valeurs 22 et 23 du paramètre Acces Control remontent bien. D’ailleurs, cela solutionne le problème des portes qui se ferment toutes seules lors du premier réveil en évitant que Access Control prenne la valeur foireuse de 254 Door/Window Sensor 2 se ferme tout seul lors du 1er réveil - #2 par Domatizer
Lors du permier réveil, je vois bien l’info dans le log indiquant que ce n’est pas supporté, logique.
Info, NodeXXX, AlarmCmd_Get Not Supported on this node
Mais, ensuite, openzwave récupère de tout même ces infos.
Je ne comprends vraiment pas bien la logique.
Finalement, le nombre d’erreurs qui font bloquer la queue plusieurs secondes se rapproche de zéro…
Remarque : j’ai fait la dernière mise à jour openzwave croyant qu’il ne s’agissait que de la doc. Tous mes modifs des fichiers config on été écrasées ! Je m’en sui aperçu plus tard lorsque j’ai refait des inclusions. Les dépendances n’ont pourtant pas été relancées. Arrff