Mark accessories as not working when Tahoma API is down

[iRonin]

Couple of weeks ago Tahoma API was down a couple of times and it wasn't clear why my accessories are not responding. When the Tahoma API is down the accessories should be reported as not responding. See https://github.com/nfarina/homebridge/issues/1651

[lboue]

Bonjour,

Pourriez-vous me dire si la tentative à fonctionné ? En effet, j'au vu un commit https://github.com/dubocr/homebridge-tahoma/commit/165c4474ea6dfea324dec984bb59e1492ccb8c3f il y'a 3j à ce sujet.

Je n'ai ai pas de mise hors ligne du device lors d'une mise hors tention du volet par exemple:

[2018-8-5 23:55:19] [Connexoon] [Velux ch.] setClosure[61]
[2018-8-5 23:55:19] [Connexoon] [Velux ch.] setClosure INITIALIZED
[2018-8-5 23:55:19] [Connexoon] Register listener
[2018-8-5 23:55:21] [Connexoon] [Velux ch.] setClosure IN_PROGRESS
[2018-8-5 23:55:23] [Connexoon] [Velux ch.] setClosure ACTUATORNOANSWER
[2018-8-5 23:55:23] [Connexoon] Unregister listener

Pas non plus lorsque l'API n'est plus joignable :

[2018-8-6 00:16:47] [Connexoon] [Velux ch.] setClosure[68]
[2018-8-6 00:16:48] [Connexoon] There was a problem requesting to Overkiz : Error: connect ETIMEDOUT 178.32.15.131:443
[2018-8-6 00:16:48] [Connexoon] [Volet Velux] setClosure Error: connect ETIMEDOUT 178.32.15.131:443
[2018-8-6 00:17:08] [Connexoon] There was a problem requesting to Overkiz : Error: connect ETIMEDOUT 178.32.15.131:443
[2018-8-6 00:17:08] [Connexoon] { Error: connect ETIMEDOUT 178.32.15.131:443
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1162:14)
  errno: 'ETIMEDOUT',
  code: 'ETIMEDOUT',
  syscall: 'connect',
  address: '178.32.15.131',
  port: 443 }

Ludovic

[dubocr]

Bonjour,

Pour les volets roulants, les commandes transmises sont temporisées afin d'obtenir un comportement acceptable avec le curseur HomeKit (choix de l'ouverture entre 1 et 99%). De ce fait, la réponse de l'API ne peut pas être prise en compte d'où l'absence de message d'erreur.

Si tu souhaites remplacer ce comportement pour privilégier la gestion d'erreur, tu peux remplacer la ligne 38 : this.targetPosition.on('set', this.postpone.bind(this, this.setClosure.bind(this))); par this.targetPosition.on('set', this.setClosure.bind(this));

Sinon, il faudrait trouver comment indiquer une erreur à HomeKit de façon désynchronisée à l'envoi d'une commande. Ce que je n'ai pas trouvé. J'ai essayé this.updateReachability(false) ce qui n'à pas d'effet sur HomeKit.

[lboue]

C'est curieux, le Bridge V2 Philips Hue est capable de marquer certains accessoires (ampoules Hue) lorsque l’alimentation électrique est coupée et ils ne répondent plus au niveau radio (Zigbee).

On devrait pouvoir reproduire un comportement identique, non ?

Ludovic

[dubocr]

Je ne dis pas que ce n’est pas possible mais qu’il a fallut choisir entre cette fonction et une autre car le fonctionnement de l’API tahoma n’est pas forcément adaptée à l’utilisation avec Homebridge.

Pour reproduire le comportement observé avec les ampoules, tu peux comme indiqué modifier la ligne 38.

Par ailleurs, le hub Hue est « nativement » compatible HomeKit et ne passe donc pas par homebridge. Toutes les fonctions HomeKit ne sont pas forcément disponibles sur HomeKit (c’est le cas des scénarios il me semble).

Enfin si tu ouvres Home, que tu coupe l’alimentation de l’ampoule et que tu essaie de l'allumer/éteindre tu constateras qu’aucun message d’erreur n’apparaît. Je pense que celui que tu observes n’apparait que losque tu ouvres à nouveau l’app après un certain temps.

Pour obtenir ce comportement, il faudrait implémenter l’interrogation du capteur à chaque requête homekit (au lieu de retourner le dernier état connu) mais là encore je pense que cela ne fonctionnerait que pour l’API down et pas dans le cas d’un volet débranché (car seule une action sur le volet nous permet de savoir si il est OK/KO). On retombe alors dans le cas d’une action pour laquelle je ne trouve pas comment indiquer l’état en différé.

[dubocr]

Voici ce que j’ai trouvé dans le code d’une librairie :

debug('Reachability update is no longer being supported.');

Ce qui pourrait expliquer le problème. Je continue de chercher.

[lboue]

Merci pour tes explications très détaillées :-). Je vais tester ça. C'est vrai la documentation HAP n'est pas très claire à ce sujet.

Oui je suis d'accord le Hue n'utilise pas Homebridge. Justement, je cherchais à savoir s'il existe un outil qui permette de visualiser/déboguer l'état des variables d'un accessoire HAP afin de reproduire le comportement.

Par exemple en l'associant avec un outil de debug. J'avais commencé à regarder cet outil : homekit_python, a python implementation to work as both HomeKit controller and accessory.