Tuya : Intégration chauffage et climatiseur

Bonjour @pierre-gilles ,

Je pense être prêt pour une review de cette PR qui met à jour l’intégration Tuya en préparant la base pour la nouvelle connexion et la détection locale :

Merci à toi par avance.

EDIT : Après un recheck complet, j’ai vu que la PR aurait dû etre découpée en plus d’éléments. J’ai donc préféré la mettre en standby. Je viens de la réouvrir. @pierre-gilles elle est prête à review.

EDIT 2 : Pierre-Gilles, pour tester toutes les PR Tuya, je peux tout à fait partager mon compte si tu le souhaites.

2 « J'aime »

Une fois la précédente valide, je mettrais à jour les PR suivantes :

  • Ajout du protocol 3.5 nécessaire pour les équipements récents. Gros avantage par rapport à HA, ceci fera partie intégrante de Gladys alors que pour HA il faut passer par une intégration externe HACS :
  • Mise en place de la base de mapping des appareils cloud vs local. J’ai pris les Smart Socket pour travailler cette base qui permettra d’ajouter plus simplement les futurs appareils / fonctionnalités :

Elles sont également prêtes et n’attendent que la 1ère ^^

Ensuite j’ai séparé une PR pour l’intégration des création automatiques des issues github.

1 « J'aime »

Merci beaucoup pour les PRs, je te tiens au courant quand j’ai pu regarder !

@Papashultz et @GBoulvin, je viens de relancer une construction sur la meme image de test, je serais très interessé de votre nouveau test et de vos retours.

Pour info @GBoulvin j’ai ajouté la prise en charge de ces issues :

Je pense et j’espere que la derniere gère également le fil pilote de @Papashultz

Et pour info, voici à quoi ressemble les Issues dorénavant :

Nouvelle issue traitée en PR :

  • Appareil :

  • Dashboard

  • Balayage horizontal :

  • Balayage vertical :

  • Mode :

  • Vitesse de ventilation :

1 « J'aime »

Hello !

Merci pour cette update !

Pour ma part, le “Smart meter” est toujours indiqué comme “non pris en charge” :

Pour les prises LSC, Une des deux (protocole 3.5) est fonctionnelle et proposée en tant que prise en charge (avec sécurité enfant !):

Par contre la seconde (protocole 3.4) me retourne une erreur (en local).

J’ai créé une issue GitHub à l’aide du bouton et voilà le résultat (ça fait pro !) :

Si je puis aider , n’hésite pas !

Edit : Pour la seconde prise, après re-test le cloud fonctionne mais pas le local.

1 « J'aime »

Bonjour @GBoulvin,

Merci pour tes tests

Quelle déception … J’espérais qu’il match du 1er coup celui-ci ^^

Re-test avec l’image du jour !

Pour le Smart Meter, les virgules sont manquantes :

Mais toutes les fonctionnalités apparaissent correctement :

Par contre, les appareils ont disparu du tableau de bord après avoir mis à jour en local (c’était résolu, non ?)

Est-ce que le scan local doit absolument être séparé du scan cloud ou ça pourrait être automatique ?

Parfois, je dois mettre les adresses IP manuellement et je n’arrive pas à déterminer pourquoi ou et pourquoi non…

Et je confirme que les protocoles 3.3, 3.4 et 3.5 sont bien fonctionnels en local !!!

1 « J'aime »

Salut @GBoulvin

Désolé pour le contre temps, c’était un test … malheureusement non concluant !! Enfin il y avait un oubli surtout. L’image est mise à jour et en cours de construction => 5 à 20 minutes.

Oui pour le coup là ça peut être normal, j’ai changé des choses dans la feature donc ça à surement cassé l’ancien device (pas de migration automatique). Comme on est en dev, je ne fais pas de migration qui casserait l’ancien device en cours de modification ^^

Oui, c’est volontaire pour l’instant. Le scan UDP local est plus long et dépend du réseau local, donc j’ai préfèré le garder en action manuelle pour ne pas ralentir la découverte cloud.

C’est cohérent avec le fonctionnement UDP local: selon le réseau (AP isolation, VLAN, filtrage broadcast/multicast, device qui broadcast peu), l’IP peut ne pas remonter automatiquement.
Dans ces cas, la saisie manuelle reste nécessaire. Il ne s’agirait pas d’un appareil sur un réseau différent ou qui metterait plus de temps a répondre à ton avis ?

1 « J'aime »