Tu dois faire un demande de fonctionnalité pour que ça soit intégré. Pour le moment, interrupteurs, lampes et températures seulement (si je n’en ai pas oublié)
En effet ces capteurs là ne sont pas encore gérés par l’intégration HomeKit. Je vais le noter pour la prochaine version, et n’hésite pas à écrire une demande de fonctionnalité comme l’a conseillé @GBoulvin pour qu’on ai une trace
Après quelques jours d’utilisations j’ai fait des changements pour améliorer l’intégration. Cette nouvelle PR
- ajoute les capteurs d’ouverture (porte, fenêtres…) suite à la demande de @bouillou7
- fix la plage de luminosité des ampoules. Aujourd’hui avec les Philips Hue par exemple, quand on met la luminosité à 100% depuis l’application Maison, on est en réalité qu’à ~40% côté Gladys
- fix la réception des nouvelles valeurs côté HomeKit. À l’heure actuelle, les nouvelles valeurs des appareils de Gladys ne sont pas directement reçu par le réseau HomeKit, c’est l’application qui doit demander ces nouvelles valeurs (quand elle démarre, qu’on change de vue sur l’app…). Avec ce développement Gladys émet un « notification » sur le réseau HomeKit à chaque nouvelle valeur d’un appareil compatible, l’affichage côté application Maison devient réellement en direct et cela permettra d’améliorer les automatisations de l’application Maison qui sont dépendantes des capteurs
Pour ceux qui veulent voir ou tester, la PR :
Une image docker est disponible bertrandda/homekit
Génial ça!
Je t’ai mis une remarque sur la fréquence d’envoi des nouveaux états, envoyer tous les états c’est vraiment trop agressif, j’ai fais un peu différemment sur l’intégration Alexa/Google Home
Dans le cas de Google/Alexa c’est parce qu’on fait des appels API et à leurs serveurs, si ça reste en local n’est ce pas inutile ?
J’ai regardé un peu le code, peux tu me confirmer que j’ai bien compris le fonctionnement s’il te plait : dès qu’on reçoit un évènement de nouvel état d’une feature, on lance un timeout de 5 sec si aucun nouvel évènement n’est arrivé pour la même feature on envoi l’info sinon on recommence un timeout avec la nouvelle valeur
Si c’est bien ça 2 questions :
- que se passe t il si un appareil envoi une nouvelle valeur automatiquement toute les 2 secondes (je n’ai pas d’exemple mais j’essaie d’imaginer des cas extrêmes par exemple avec le module zigbee du Linky), ne va t on pas être dans une boucle sans jamais envoyer la nouvelle valeur ?
- ne peut on pas réduire un peu le timeout car par exemple si l’utilisateur a programmé une alarme/alerte dans les automatisations HomeKit qui se déclenche sur un capteur d’ouverture de Gladys il se peut qu’il y ai un cas où la fenêtre/porte ai été ouverte puis fermé en moins de 5 seconde et que l’alarme ne se déclenche pas. N’est ce pas quelque chose qu’on veut éviter question sécurité ?
Effectivement en t’envoyant le bout de code je me suis dis la même chose C’est un bug, il faudrait qu’il y ait une « tempo max » en sorte.
ça fait vraiment énormément de traffic, et on l’a vu sur le développement de l’intégration InfluxDB, ça consomme vraiment beaucoup de CPU côté Gladys de gérer chaque event individuellement sans mettre aucune limite.
Même si la limite ça serait 1 event max par 1 seconde, c’est déjà top. Certain device sont très verbose.
Effectivement dans ce cas là on peut descendre la tempo. Après la tempo peut-être différente pour certain type d’appareil « critique » et peu verbose (ouverture de porte par exemple)
Mais je t’assure que sur les installations de certains utilisateurs de ce forum, envoyer tout va tuer leur network et leur instance Gladys
Autre question, tu n’envoie bien que les états des appareils qui sont « compatible Gladys-Homekit », pas tout ?
Ok j’essayerai en mettant le double comme maximum (si la tempo est de 5 sec, et qu’on est dans un cas avec un évènement tous les 2 sec, la nouvelle valeur sera envoyé avec l’évènement émis 10 seconde après le premier)
Donc par défaut je mettrai 5 sec et dans le mapping du service j’ajouterai un champs pour personnaliser cette temporisation si nécessaire
Oui, seulement les nouvelles valeurs des appareils exposés à HomeKit sont envoyées
J’ai mis à jour l’image bertrandda/gladys:homekit
avec les derniers changements pour réduire le nombre d’évènements envoyés
Top merci @bertrandda pour le fix
Preneur de retours maintenant pour vérifier que ça marche et que ce n’est pas trop aggressif. Si vous testez, je veux bien une comparaison « usage CPU avant/après »
Un petit up pour tout ceux qui peuvent tester ce sujet pendant les vacances
Sinon @bertrandda, rien à voir mais on a un gars sur le forum anglais qui pose des questions sur Node-HAP (aucun rapport avec Gladys), si jamais tu veux lui donner un coup de main :
Je vais voir ce que je peux faire
J’ai mis à jour l’image pour utiliser maintenant Node 18, pour rappel l’image bertrandda/gladys:homekit
permet de tester les changements suivants :
- recevoir les données en casi temps réel dans HomeKit
- fix la luminosité des ampoules
- ajoute la gestion des capteurs d’ouvertures.
Bonjour,
J’ai cette erreur dans les logs
2023-01-10T17:45:47+0100 <warn> functionsWrapper.js:15 (EventEmitter.<anonymous>) Error while executing function () { [native code] }
2023-01-10T17:45:47+0100 <warn> functionsWrapper.js:16 (EventEmitter.<anonymous>) TypeError: Cannot read properties of undefined (reading 'notifDelay')
at HomeKitHandler.notifyChange (/src/server/services/homekit/lib/notifyChange.js:23:71)
at EventEmitter.<anonymous> (/src/server/utils/functionsWrapper.js:13:13)
at EventEmitter.emit (node:events:525:35)
at Event.emit (/src/server/lib/event/index.js:18:16)
et cette erreur sur iPad quand j’essaye de rajouter Gladys (alors que je l’ai bien supprimé)
Après, suppression des variables dans t_variables dans la base, j’ai pu réassocier Gladys.
Les capteurs d’ouverture remontent bien (et on peut les afficher en tant que portes).
Mais toujours les mêmes erreurs dans Gladys et l’état des capteurs d’ouverture ne change pas dans HomeKit (il a l’air inversé d’ailleurs)
Déjà merci @cicoub13 pour tes tests. Ça montre la limite de l’environnement de développement avec de faux appareils.
Je pense savoir ce qu’il s’est passé, tu peux me donner la référence de ton capteur de porte s’il te plait ?
Je vais vérifier ce point
Sur les forum HomeKit j’ai vu pas mal de cas comme ça. J’ai l’impression que la directive de suppression ne remonte pas toujours jusqu’à l’appareil donc l’appareil disparait de ton app Maison mais pas de la configuration interne de l’appareil. Je vais ajouter un bouton réinitialiser
dans la page de l’intégration pour supprimer le dossier de configuration, ça devrait permettre de ne pas avoir à rentrer dans la table si on rencontre se message.
Celui-ci Aqara MCCGQ11LM control via MQTT | Zigbee2MQTT
C’est une bonne idée, mais il faut bien expliquer ce que fait le bouton (et le mettre en rouge peut-être).
Parce qu’il y a déjà un bouton lorsque l’ajout d’un appareil ne se fait pas dans HomeKit pour « Rafraichir le service »
Ça y est je t’ai créé une image avec le fix de la valeur inversée et de l’envoi de la valeur en direct. Tu peux me dire si c’est bon ?
Tout bon pour moi, merci pour la correction
Bon pour moi niveau code, juste une question avant de merge, je peux déployer ça en prod sans souci, l’utilisateur n’aura pas à re-associer quoi que ce soit ?
Normalement non, Gladys est considéré comme un pont, les nouveaux appareils sont automatiquement ajouté à HomeKit, il faudra juste configurer les noms/pièces des nouveaux appareils (ils ont une pièce par défaut en attendant).
Le problème dont on parlait avec Cyril, c’est un cas particulier que je traiterai dans une autre PR. Il faut gérer le cas ou l’utilisateur essai de dissocier Gladys de HomeKit mais qu’il n’est pas accessible à ce moment là sur le réseau. Côté app Maison Gladys est oublié mais côté Gladys il ne sait pas qu’il faut supprimer l’association donc un reset est nécessaire (voir FAQ · homebridge/HAP-NodeJS Wiki · GitHub).
Ok nickel !
Je viens de voir un truc dans le code je t’ai mis un commentaire ici :