Suite à la mise à jour du plugin gsh, je fais mes retours sur ce qui marche/marche pas. Ou simplement des détails qui ont changé.
Déjà, globalement la synchronisation des appareils marche sans soucis en mode standalone (je l’avais pas refait depuis juillet, il a pas bronché)
1 - Fenêtre/Porte : j’ai remarqué que le statut était inversé. Mes fenêtres sont indiquées par défaut ouvertes alors que fermées. Je dois passer dessus pour inidiquer d’inverser dans gsh l’état, pourtant la commande statut binaire a déjà la configuration inversée de coché pour être conforme dans Jeedom.
J’ai pas regarder le nouveau code, mais est-ce que cette configuration inversée de la commande est bien utilisée ? Si oui ca veut dire que par défaut ce que jeedom envoit est inversé ?
2 - VR/Stores/Rideaux : dans mon cas j’ai les 3. Sauf que j’ai plus que les rideaux qui répondent. Si je demande à fermer le rideau dans la chambre, il ferme bien que celui de la chambe, tous les rideaux, les 6 sont fermés etc. Pour les stores ou velux, il finit par répondre « je n’arrive pas à joindre jeedom » en me mettant sur l’écran du hub les 2 stores ou les 5 velux (les velux sont remontés comme VR). Et autant pour les rideaux je vois bien la commande dans les logs jeedom, pour les stores/VR j’ai rien. J’ai regardé si il y avait des différences « visible » mais rien. En renommant les Velux et Stores, puis synchronisation, ca met bien à jour jeedom. Donc un peu perdu sur ces types.
PS 1 : je vois qu’il y a une propriété de sens d’ouverture qui par défaut est définit en sens « DOWN », je pense qu’il vaut mieux l’inverser pour les VR et Stores. Quand on est en vertical c’est plutot « UP » le sens d’ouverture. Et pour les rideaux et bien on est en horizontal, donc ca serait plutot LEFT ou RIGHT, voir MIDDLE (j’ai les 3). Je pense que c’est plutot un indicateur qui servira à Google pour les affichages ?
PS 2 : j’ai essayé sur un store de cocher les options pour la commande d’ouverture partielle, accepter l’ouverture partielle. Mais c’est pas conservé à la sauvegarde.
3 - Page de conf : sur sauvegarde, sur appui du bouton de Connexion en mode standalone, ca donne maintenant une page google avec statut 502. Ca fonctionnait en juillet dernier. La synchronisation depuis Google Assistant/Google Hub fonctionne elle sans soucis, donc la liaison est bien active.
J’ai vu que sur la dernière mise à jour le bouton de test sur la page de configuration n’est plus présent, donc plus d’erreur.
Par contre j’ai tout refait ma conf cote google et j’étais incapable de lancer une synchronisation.
Déjà un retour sur le besoin d’etre connecté à l’avance sur Jeedom pour faire la synchronisation :
- il faut le faire avec Google Chrome. Etre connecté avec Firefox ou autre navigateur n’est pas suffisant, je n’ai pas pu lancer la synchro sans le réactiver (sinon message « merci de vous connecter … »)
- il faut etre admin Jeedom, détail qui pourrait jouer pour certains. Ca c’est en voyant le code que je le déduis.
Donc Chrome activé, doc suivie pour la connexion (sans jwt, pas sur que ca serve beaucoup aujourd’hui avec l’api locale)
La doc m’a fait remplir : Client ID, Client Secret, Project ID, Homegraph API
Mais impossible de faire une sync.
J’ai rajouter du debug dans l’API car stackdriver me renvoit une erreur d’auth à chaque tentative de sync.
Et j’ai trouvé que c’était la ligne 63 le problème. Le test de init secure contre gshs::authkey.
Sauf que gshs::authkey correspond à Clef d’accès sécurisé sur la page de conf et en relisant la doc rien ne dit comment la remplir.
Côté Google j’ai pas trouvé de champ qui correspond. Moi je l’ai récupéré dans les logs (en ayant ajout un print_r de $_GET)
Et là en remplissant le champ, ca marche.
Morale, ce champ doit être rempli mais pas trace dans la doc. Je me demande si avant ce n’était pas le test de connexion qui servait à la remplir par retour de Google ??
@Loic
Pour revenir au point 1, le statut des portes et fenetres.
Pour les widgets core door/window, il faut etre à 1 pour avoir l’image fermée et 0 pour l’image ouverte.
En gros les widgets représentent un true/false de l’état de fermeture.
Du coup le invertBinary sert aux commandes qui donnerait un état binaire d’ouverture.
Pour gsh, c’est bien un état d’ouverture qu’il faut envoyer et pas de fermeture. Donc il ne faut pas prendre en compte l’invertBinary ou plutot de facon opposée.
Deuxième retour, il y a un 100 - 0 fait en cas d’option inversion cochée dans le modal gsh. Sauf que cette opération est fait en dehors de la partie numérique et donc pourrait etre appliqué à des binaires (et donner 99 au lieu de 0)
salut,
je ne sais pas si c’est un bug @Loic, mais dans la dernière mise à jour du plugin , la configuration du standalone a disparue mais ça n’empeche pas le bon fonctionnement .
Ca devait être un bug ,
la configuration est revenue dans la nouvelle mise à jour ;
merci pour la correction @Loic
