Pas de réponse, semble-t-il Oo
Par contre après il relie l’état après le changement
Mais je vous avoue que c’est la première fois que j’utilise WireShark ou autre outils analyse réseau.
Benjamin ! prend le temps qui est nécessaire, c’est déjà très très gentil de t’impliquer dans ce projet, surtout sans être concerné ! donc tu implémenteras quand tu auras le temps
Avant que femme et enfants soient réveillés, j’ai pu récupérer les commandes suivantes :
Dans l appli Il a fallu que j’allume pour modifier les paramètres ( limitation applis ?)
{« sprj »:1} Allumage Lumiere
{« prcn »:2} Couleur Bleu
{« prcn »:3} couleur lagon
Vitesse pour les séquences
{« pspd »:0} lent
{« pspd »:1} moyen
{« pspd »:2} rapide
Puissance éclairage
{« plum »:0} faible
{« plum »:1} moyen
{« plum »:2} forte
{« plum »:3} max
{« sprj »:0} extinction projecteur
J’ai envoyé en powershell les commandes ‘{« prcn »:16} ‘ ,‘{« pspd »:0}’,{« plum »:0}’
Avec la lumière éteinte ça fonctionne les paramètres sont changés et ça n’allume pas la lumière pour autant
Arrêt de la filtration thermoreguler {« mfil »:0}
Filtration On {« sfil »:1}
Filtration Off {« sfil »:0}
Mise en marche de la filtration thermoreguler {« mfil »:1}
je continuerai très bientôt (peut êtres dans l après midi) ,je dois arrêter pour le moment
Je me suis occupé d’implémenter pas mal de trucs :
la lumière et la filtration sont maintenant manipulable depuis l’interface
j’ai viré la notion de « pompe » qui est en réalité la même chose de la filtration
pour la couleur et l’intensité de la lumière, je ne sais pas encore comment implémenté ces choix dans l’entité lumière, donc pour le moment, j’ai fais des services
j’ai corrigé un bug dans l’attribut des IDs uniques d’entités qui empêchait leur édition depuis l’interface
Il faudrait tester tout ça et vérifier qu’on est bon pour la détection de l’état de la lumière et de la filtration, car ça risque de faire buguer un peu l’interface si l’état récupérer après changement n’est pas celui attendu. D’ailleurs, pour la lumière, on récupérait son état au niveau du bit 34 qui devait normalement fournir l’état de la filtration & de la lumière et la liste des codes connus était incomplète. J’ai tenté ma chance en la complétant avec 1 = filtration seule en sachant qu’on avait déjà 0=tout off, 2=lumière seule, 3 = tout on. À tester…
Par ailleurs, j’avais pas vu dernier message, avant de faire tout ça, donc pour le moment, après chaque changement, je déclenche une mise à jour des infos des entités. Au final ici, vu qu’on récupère ça directement, je vais pouvoir améliorer mon code pour :
vérifier que ce qu’on a demandé a été fait
mettre à jour directement les entités
J’arrête pour le moment et vous laisse déjà tester tout ça en sachant que je vous conseille de virer l’intégration et de la remettre, car vous aller avoir des changements d’IDs d’entités.
re
il y a un truc bizare que j essaie de comprendre
quand j envois {"bios":201}
je recois une tram abituelle
mais aussi une seconde avec le numero de serie !
que je ne récupère pas pour le moment en powershell
les modifications de l’intégration fait que l on peut allumer la lumière. mais, vu que le retour d état ne fonctionne pas correctement, on ne peut pas l’éteindre
déjà c’est cool, ça a plus avancé en 1 semaine quand 1 an
Cool Il faudrait qu’on arrive à trouver le bon bit d’état pour la lampe. Pourrais-tu refaire des relevés en allumant/éteignant juste la lampe (sans le mode pour forcer la filtration en même temps de la lumière) ?
Sinon pour ton histoire de « bios 201 », effectivement, ça pourrait être sympa de comprendre ce qu’il y a dans cette trame, si on avait le numéro de série on pourrait peut-être mieux nommer/identifier le device. Jusqu’ici, je gère pas vraiment la possibilité d’avoir plusieurs appareils. Si tu as la possibilité de m’envoyer (en MP) ton relevé wireshark, je pourrais jeter un œil.
Sinon, j’avais posé une question sur le forum dev d’HA pour la bonne solution pour implémenter une entité lumière avec des choix pré-définis d’intensité et de couleurs et à priori, vu que ça rentre pas dans un cas géré nativement par HA, la bonne solution serait d’ajouter des entités de type « select » qui permettait de sélectionner l’intensité et la couleur. Je vais voir à implémenter ça de cette manière.
Je me suis occupé de gérer la réponse du Tild après chaque modification et j’ai remplacé les sensors pour la couleur & l’intensité de la lumière ainsi que l’offset de la température par des entités selects. J’ai également ajouté un switch pour la thermorégulation de la filtration, même si pour le moment, on ne sait pas du tout détecter son état.
La suite logique maintenant se serait d’arriver à démystifier la chaine d’état pour arriver à remonter correctement l’état de la lumière, de la filtration et de la thermorégulation de celle-ci. Par ailleurs, si tu trouves comment on peut changer l’offset de la température, on pourra également finaliser ce switch.
Pour finir, ce serait cool d’avoir un retour sur le bon fonctionnement de la gestion de la couleur et de l’intensité de la lumière. À ce niveau-là, on devrait être bon normalement.
Faudrait aussi que je regarde pour traduire un peu toute l’intégration. D’ailleurs à ce sujet, je pense que le mieux c’est d’adopter le « vocabulaire » et les choix de l’application officielle. Du coup, si vous voyez des trucs qui faudrait renommer pour coller à l’application officielle, n’hésitez pas à me le dire.
L’intégration ne fonctionne toujours pas bien sur le retour d’état au moins de la lampe !
Bon , c’est une journée productive pour le développement du tild
Un collègue est venu pour me donner un coup de main sur l’analyse des trams et le dev en powershell !
Tout d’abord tant que la connexion TCP est active le tild envois une tram d’état à chaque changement, ce qui arrive au minimum toutes les minutes, car le temps passe et donc l’heure du statut de tram change.
Ensuite à chaque fois que l’on passe une commande, si l’état est déjà positionné le tild ne renvoie pas de tram de changement d’état et oui le statut reste le même donc faut attendre 1 minute pour avoir la réponse.
Nous avons réalisé un petit script en Powershell qui me permet de lancer la commande (que je récup avec Wireshark en passant les commandes de ma VM ) puis je les passe en script
Lui me fait une analyse des valeurs modifiées cf screenshot
OK, je vois l’idée. Bon par contre, je pense pas que se soit une bonne idée de rester connecté au boîtier en permanence pour attendre qu’il nous remonte les changements. Ça risquerait d’être problématique si on a des connexions en parallèle depuis l’appli mobile. Par contre, des fois j’ai l’impression que tu te retrouves avec les infos d’état en double : j’imagine qu’il faut dans ce cas se concentrer sur les 160 derniers caractères qui doivent correspondre à l’état le plus « récent ». Tu confirmes ?
Hum, si je comprends bien, tu dis que, par exemple, si on demande l’allumage de la lumière et que celle-ci est déjà allumée, le Tild ne va rient retourner immédiatement, mais qu’il finira par envoyé son état au max une minute plus tard ?
Si c’est le cas, je pense qu’il va falloir prévoir le coup et donc, par exemple, mettre un timeout sur la réception du résultat d’une action et passé ce timeout, renvoyer un « Begin » pour récupérer l’état sans attendre et valider si notre action est « effective » (même si c’était déjà le cas). On pourrait aussi partir du principe que s’il renvoie rien c’est bon, mais je suis pas fan de l’idée.
OK, intéressant ! Par contre, je comprends pas à quoi correspondent les trois modes de programmation de l’éclairage : dans l’interface j’ai l’impression qu’on peut juste activer ou désactiver la programmation de l’éclairage, donc ON/OFF, ok, mais à quoi correspond 2=Minuteur Ou alors c’est soit programmation, soit minuteur, et alors:
0 = prog & minuteur OFF
1 = prog ON & minuteur OFF
2 = prog OFF et minuteur ON
OK, je vois l’idée, mais juste pour comprendre : 23:30min ça veut dire que la lumière s’arrêtera à 23h30 ou dans 23h30 ?
Pour le reste de la programmation de l’éclairage, je suis pas sure de bien comprendre comment tout ça fonctionne et du coup, comment traduire ça dans HA. Tes screenshots aident bien, mais tu pourrais m’expliquer ce que signifie chaque switch dans l’interface et comment ils se combinent entre eux ? N’hésite pas à me dire au passage ce que tu imaginerais en terme d’entités équivalentes dans HA.
Sinon, j’ai codé la détection de l’état de la lumière en fonction du bit 70 qui me semblait être le bon. Pour le bit 33, j’avais émis l’hypothèse qu’il s’agissait de la durée de filtration prévue : si le mode « filtration en même temps que lumière » est activé, c’est possible, mais tu pourrais faire des tests et relevés de ce côté là pour confirmer ?
Pour finir, je me suis rendu compte que je n’avais pas poussé hier soir mes derniers modifs sur github, du coup le tout y est à présent. Dis-moi
re
je suis 100 % d’accord de ne pas garder la connexion ouverte !
Nous l’avons fait dans notre script de debug , pour bien voir passer toutess les trams et mieux comprendre comment ça marchait.
pour le timeout a toi de voir je pense que c’est la solution, mais je ne parierais pas ma piscine
dans la programmation éclairage c’est bien soit l’un soit l’autre soit rien le minuteur permet l’extinction auto de l’éclairage de la piscine X temps après l’allumage
Je n’ai pas bien compris le test que tu veux que je fasse !
Pour le détail des screenshots je vais essayer de te faire ça, mais ne serait-il pas plus simple que l’on fasse un teams ou autre (maintenant que j ai une VM avec l’application) ?
À toi de voir.
Pour l’intégration a HA c’est beaucoup mieux ! mais il y a un comportement bizare en faite il ne ce rafraîchi pas bien, mais ce met bien si j’exécute le service après l’action je n’ai pas le temps de tout tester ce soir , mais c’est de la bombe !
Même si sur les couleurs ce n’est pas bon, ça les change quand même !
En choisissant « orange » j’ai eu du « chaud » dans le tild le select offset ne fonctionne pas !
je vais voir à implémenter quelques choses en ce sens, on verra bien ce que ça donne. C’est sûr que je sais pas si le Tild va savoir gérer une requête « Begin » après une action…
OK, donc je verrais bien :
une entité select pour choisir le mode de programmation de la lumière : Off, Programmation ou Minuteur (état dans le bit 71, changement via « mprj » 0, 1 ou 2). Ceci dit, on pensait jusqu’ici que le bit 71 correspondait à l’intensité de la lumière. Tu pourrais refaire des relevés à ce niveau qu’on essaye de voir quel bit change en fonction de l’intensité choisie ?
une entité select pour choisir la durée du minuteur par pas de 15 minutes (état dans les bits 72 & 73, changement via « pret » de 1 à 95 pas de 15min)
un switch pour activer/désactiver le mode crépusculaire (bit d’état ???, changement via « aprj » 0 ou 1 j’imagine)
un switch pour activer/désactiver le mode weekend (bit d’état ???, changement via « mprw » 0 ou 1 j’imagine)
une entité select pour la durée d’allumage après le crépuscule du lundi au vendredi (bit d’état 26 & 27 (entier en base 16), changement via « prjl » de 1 à 95 pas de 15min ou 255 pour OFF)
une entité select pour la durée d’allumage après le crépuscule le week-end (bit d’état ???, changement via « prwl » de 1 à 95 pas de 15min ou 255 pour OFF)
Concernant le mode crépusculaire, s’il n’est pas activé, on choisit l’heure d’allumage en plus de la durée c’est ça ? Et s’il est activé, l’heure d’allumage est calculée automatiquement en fonction de l’heure du couché du soleil ? Si c’est ça, tu dois pouvoir me dire comment changer l’heure d’allumage lorsque le mode crépusculaire est désactivé et on pourrait prévoir un select pour ça aussi. Il me faudra également le bit d’état d’ailleurs.
Si tu parles du test à propos du bit 33, l’idée est de voir si la durée de filtration prévue affiché dans l’appli suit la valeur du bit 33, donc faudrait voir si on a la main là-dessus pour la faire varier.
J’y ai pensé en l’écrivant effectivement. J’aurais du temps demain après-midi de mon côté si c’est bon pour toi ?
Hum, faudra que tu me montres ou que tu m’expliques. Ça me laisse penser qu’on détecte pas bien l’état après un changement. Ça pourrait être à cause de l’histoire des multiples états envoyés après une action. Je viens de pousser un patch pour ça, dis-moi si ça aide. Tu as ça sur une entité en particulier ?
Ah OK, je m’étais basé sur le mapping que tu avais fourni dans ton code d’origine, il faudra donc le revoir :
Si tu veux dire qu’il ne change rien côté Tild, c’est normal, car tu ne m’as pas encore dit (sauf erreur) quel ordre envoyé au Tild pour changer sa valeur . Pour le moment, le select ne fait qu’« afficher » la valeur récupérée dans le dernier état connu du Tild.
Belle avancée ce soir avec Ricky : on a repéré toutes les commandes possibles depuis l’application :
Pour l’identification des bits d’état de chacun des paramètres, on a également établi un plan d’action : je viens d’implémenter de quoi loguer à chaque changement d’état les différences par rapport au dernier état connu du Tild. Ainsi, en jouant avec les différences switchs & selects dans l’interface de HA, vous devriez pouvoir récupérer les bits qui change directement dans les logs de HA. Je vais m’occuper en parallèle d’implémenter toutes les entités pour vous permettre de tester les changements d’état depuis l’interface d’HA.
Ceci dit, lorsque vous allez déclencher un changement depuis HA, celui-ci ne connaîtra pas forcément l’état courant au niveau du Tild. Pour cela, je vous conseille avant tout test, d’aller dans Outils de développement > Onglet États pour définir l’état courant de l’entité.
J’ai par ailleurs temporairement désactivé la vérification des changements d’état après les actions dans HA en espérant que ça vous aidera durant les tests (pour les changements soit pris en compte dans HA, même si on connaît le bit d’état pour vérifier que le changement a bien eu lieu). Attention ceci dit, mettez une fréquence de rafraîchissement importante dans la configuration de l’intégration lorsque vous faites vos tests, pour pas que cela vienne les perturber.
À vous de jouer désormais, en espérant que ce que nous avons imaginé pour la détection des bits d’état soit fonctionnel
Note : Je me rends compte au passage que l’ID des entités remontées par l’intégration sont à nouveau pas correcte, car il leur manque le préfixe « tild_ ». Je vais voir à corriger ça.
Salut
malheureusement, j’ai eu que peux de temps pour tester !
j’ai des bonnes et des moins bonnes !mais dans l’ensemble ça évolue très bien
primo : quand je regarde ma filtration j arrive a avoir un résultat pertinent et probable
ça, c’est cool
en ce qui concerne la lumière pareille
par contre dans le choix de la couleur , ce n’est pas ça !
la lecture du code couleur (retour d’état ) semble OK,
mais la sélection n’est pas la bonne, les commandes sont
je vais voir à implémenter quelques choses en ce sens, on verra bien ce que ça donne. C’est sûr que je sais pas si le Tild va savoir gérer une requête « Begin » après une action…