Hello hello
je suis dans ma découverte de HA (en fait c’est pour migrer de GH vers HA) et j’ai un souci avec LocalTuya que j’arrive pas à installer, je m’explique :
je suis dans la fenêtre de Configuration du compte Cloud API
je rentre les mêmes infos que pour Tuya (ID Client & Secret)
mon adresse email
mon mot de passe
(tout cela donc à l’identique de la configuration dans Tuya)
et j’ai en retour :
”Échec de la récupération de la liste des appareils. Erreur 1106 : autorisation refusée.”
D’où ma question.
Ma config à toutes fins utiles
Version
core-2024.6.4
Installation type
Home Assistant Container
undefined
-—
Développement
false
undefined
-—
Supervisor
false
undefined
-—
Docker
true
undefined
-—
Utilisateur
root
undefined
-—
Virtual environment
false
undefined
-—
Python version
3.12.2
undefined
-—
Operating system family
Linux
undefined
-—
Operating system version
6.12.34+rpt-rpi-v8
undefined
-—
CPU architecture
aarch64
undefined
-—
Fuseau horaire
Europe/Paris
undefined
-—
Configuration directory
/config
undefined
-—
Home Assistant Community Store
GitHub API
ok
GitHub Content
ok
undefined
-—
GitHub Web
ok
undefined
-—
HACS Data
ok
undefined
-—
GitHub API Calls Remaining
5000
undefined
-—
Installed Version
2.0.5
undefined
-—
Stage
running
undefined
-—
Available Repositories
2154
undefined
-—
EDIT : je m’aperçois aussi que j’ai ce LocalTuyaIR Remote Control Disponible en téléchargement
Tuya universal remote control device Home Assistant integration
Tu as les informations du projet iot avec le id client et secret , puis les identifiants que tu utilises pour l’application Tuya ( pas ceux pour te connecter à tuya iot ).
C’est bien ça que tu indiques ?
Bon… eh bien pas mieux.
J’ai récupéré la liste de mes devices en format json.
Savez vous comment je peux les injecter dans HA ? Dans LocalTuya ça marche pô.
En demandant
”Do not configure a Cloud API account”
J’ai cette réponse :
”Unknown error occurred” :)
Et en même temps j’ai :
”ImportError: cannot import name ‹ VacuumActivity › from ‹ homeassistant.components.vacuum › (/usr/src/homeassistant/homeassistant/components/vacuum/_init_.py)”
Ça c’est dans le log de HA.
Voui. Bien sûr. 1,2 et 3 tout est bon.
Je me demande si ce n’est pas le fait d’avoir une version de LocalTuya incompatible avec ma version de HA.
Tu tournes avec lesquelles toi ?
Alors je vais te suivre avec ce Fork. Mais je ne pas encore certain.
Déjà je vais désinstaller mon HA et le réinstaller dans un version récente stable et compatible.
Mais laquelle me conseillerais-tu ?
C’est ce VacuumActivity qui mettait le zinzin dans LocalTuya et ça m’inquiète un peu.
Du coup, je me demande si je prends LocalTuya ou le Tuya de base.
Attention, dans son comparatif , le local tuya, n’est plus trop maintenu. Enfin, il est toujours maitenu mais peu mettre du temps à mettre a jour.
Le fork que j’utilise, est bien maintenu ( 1 maj / mois en général ). Mais a la base ce sont les mêmes intégrations, sauf que le fork est plus à jour et évoluer :
Sinon Tuya Local est très bien aussi.
Utilise HAOS 16.0 ( la 16.1 a un bug pour les RPI/ HA Yellow, si tu n’as pas de RPI/HA Yellow, tu peux mettre la 16.1 ).
Ben nan : j’utilise l’application seule dans Docker sur mon RPI 4 qui embarque sans broncher d’autres serveurs.
J’avais installé home-assistant:2024.6.4. ayant vu je sais plus où que c’était une version stable.
Sauf, manifestement, que LocalTuya n’est plus compatible avec celle-ci.
Donc, si je prends le fork que tu m’indiques quelle version de HA me conseillerais-tu ?
Pareil, et c’est pour cela que je parle de tuya local car c’est vraiment mieux maintenu que tuyatout court et aussi à ne SURTOUT pas confondre avec local tuya, car c’est le jour et la nuit… mais j’ai l’impression que personne ne réalise vraiment à quel point c’est différent, c’est juste qu’avec tuya local tu mets tes identifiants et tout se configure sans rien faire (ou presque), pas d’api, pas de compte dev, etc… et c’est beaucoup plus robuste que la solution tuya seule selon mon expérience. Seule « ombre » au tableau, je ne suis pas sûr que ce soit une bonne idée de faire cohabiter les différents modules (je l’avais fait, mais j’ai l’impression qu’il y a des interférences pas top top, donc au final j’ai désactivé tout ce qui n’était pas tuya local).
Pour avoir testé les différents forks (je n’ai cité effectivement que l’original non maintenu), je maintiens mon affirmation, même avec les forks maintenus c’est vraiment le jour et la nuit par rapport à tuya local, pas besoin de gymnastique compliquée de création de compte dev sur tuya serveur europe et tout le reste des manips à rallonge, tout est automatisé dans tuya local… Et en plus ça marche vraiment mieux dans les configurations par défaut (la liste des appareils et configurations est maintenue pour de « vrai » dans tuya local contrairement aux différents forks de local tuya, j’en ai fait l’expérience malheureusement…)
Ah oui ! Mais pour mon projet immédiat, ça ne conviendra pas.
L’intégration tuya-local a été conçue pour contrôler des appareils Wi-Fi qui sont directement connectés à mon réseau. Mes capteurs actuels Sonoff utilisent le protocole Zigbee et ne sont pas directement accessibles sur mon réseau Wi-Fi.
Donc, comme c’est pour manger tout de suite, je vais faire au plus pressé : Tuya.
c’est ce qui me semblerait le + simple aussi, et ça devrait permettre de conserver l’interface propriétaire par ailleurs (comme avec un pont philipps hue par ex.)
