J’ai fait une rapide comparaison - test croisé avec home assistant :
Pour le fun j’ai ajouté deux sondes de température DS18x20
J’espère que Gladys va être upgradé
Je prends le merci pour moi ??? Lol
J’aime bien tester des trucs d’ailleurs si cela permet de faire évoluer Gladys,
C’est presque plus intéressant que quant cela fonctionne du premier coup…on s’ennuie vite (lol)
il faut pas aider à me chahuter et me solliciter
Bonjour,
Gladys ne dépend pas du standard homeassistant 
Nous souhaitons éviter de devoir modifier la configuration par défaut du firmware (sauf pour du debug). En revanche, s’il est conseillé d’appliquer certaines options, nous le proposerons via Gladys.
En effet, l’intégration des devices se fait au cours de l’eau, n’ayant pas le matériel pour tester, et ne surveillant pas les nouvelles intégrations dans Tasmota au fil de l’eau, nous attendons que la communauté le demande.
J’ai regardé le ticket sur Github, le hack est d’ajouter le préfixe StatusSNS comme clé sur le dernier argument de la méthode.
Merci à @Barbudor de participer aux discussions autour de Tasmota, nous sommes preneur des bonnes pratiques à appliquer que nous aurions mal interprétées.
Merci @Titou43 pour tes retours, nous allons intégrer ton device ASAP. Nous avons la même demande pour le BL09XX.
Bonjour @AlexTrovato
Merci pour ton feedback
Concernant la limitation sur les capteurs DHT11/AM2301 (les pire possibles sur le marché😁) pourquoi ne pas juste ignorer la clé du nom-du-chip ? Actuellement vous filtrer mais vous n’utilisez pas la valeur de la clé nom-du-chip. Pourquoi ne pas passer directement à \\..+\. ?
La majorité des utilisateurs de Tasmota utilisent le DS18x20 pour la temperature (j’ai vu jusqu’à 20 DS18x20 sur un Tasmota) ou les BME280/HDC1080 pour temperature+humidité.
Quand on utilise + que un DS18x20 par exemple, les clés sont "DS18B20-1":{...}, "DS18B20-2":{...}
Voir même (via une option) DS18B20-XXXX utilisant les 4 derniers chiffres du numéro de série du chip (« id ») afin de régler les problèmes d’ordre aléatoire au redémarrage.
Les BL09XX sont des capteurs de consommation électrique dont l’intégration dans Tasmota est au niveau de la clé ENERGY. Le type de composant utilisé est complètement invisible pour l’utilisateur.
Donc pas sur de comprendre ce qui vous manquerait à ce niveau.
A disposition si vous avez des questions sur Tasmota
A+
Bonjour
Je viens un peu aux nouvelles, si je peux aider à faire des tests…
Merci de vos aides
Bonjour
Petit up vers les développeurs , vous avez pu trouver un peu de temps pour ce sujet ?
Merci !!
Pour info il y a une PR en cours ( Add more temp devices by atrovato · Pull Request #1570 · GladysAssistant/Gladys · GitHub )
@AlexTrovato Il y a une image Docker de test ?
Je viens d’en générer une à jour atrovato/gladys:tasmota.
Amusez vous bien
1 « J'aime »
Bonsoir
Il faut m’en dire un peu plus…désolé pour moi qui suis nouveau !!
Que dois je faire pour tester ?
Merci
Salut @Titou43 !
J’avais fais un post à l’époque qui explique comment lancer une image de test:
Par contre je te préviens, on est en mode « développement » là, c’est pas un process facile pour un novice complet et c’est à faire dans un environnement séparé de ta production !
Le but ici est de tester que le développement répond au problème avant de déployer ça en production. La mise à jour en production elle se fera automatiquement sans aucune action requise
Bonjour…
Et ARG je n’arrive à lancer le serveur MQTT depuis l’image atrovato/gladys:tasmota
Si je coches MQTT dans un container Docker cela ne veut pas
Si je vais chercher sur le MQTT de mon Gladys fonctionnel il ne s’y connecte pas non plus
Dans les logs de docker j’ai cela :
2022-09-14T18:56:44+0200 service.start.js:44 (Service.start) Unable to start service mqtt PlatformNotCompatible [Error]: DOCKER_CGROUP_CONTAINER_ID_NOT_AVAILABLE
Pour la config :
je suis sur un PI 4 8Go avec Debian 11 en 64Giga
Va falloir nous en dire plus sur ce que tu as fait pour en arriver là ( on avait prévenu 
)
@VonOx Je ne comprends pas le sens de « on avait prévenu… » mais bon
Pour éviter de « perturber » mon installation Gladys sous Docker/Portainer (qui est sur un Pi 4 8Go actuellement sous Pi Os Bullseye 64 bits) j’ai voulu installer cette image de test sur un second raspberry
J’ai sur une autre table un PI 4 8Go qui est sous Debian 11 en 64 bits et sur lequel j’ai Docker/Portainer
J’ai suivi l’image atrovato/gladys:tasmota avec quelques adaptations :
–name gladys-tasmo
-e SERVER_PORT=1033
et bien sur le chemin vers le dossier de stockage
J’ai un message d’erreur dans les logs de l’image (log que je trouve depuis portainer…)
D’ou mon message de ce soir …
Après le temps de la pause du soir, j’ai décidé de ne pas mixer les genres et pour permettre d’avancer j’ai décidé de mettre l’image sur le PI 4 avec Pi Os portant déjà mon Gladys
Ainsi cela permet de vérifier les adaptations de cette image de test et de ne pas avoir en doute des interactions/variables comme le changement d’OS, de matériel et autres sujets
J’ai connecté le serveur de l’image gladys-tasmo sur le MQTT de l’image gladys v4
A priori ce point fonctionne…
Par contre impossible de trouver le périphérique Tasmota THR320 en MQTT (en appuyant sur découverte MQTT…)
Mais je le trouves sur la découverte HTTP et il apparait comme suit :
Je parlais de ça.
Quelle commande as tu utilisé pour créer le conteneur gladys ?
Edit: j’avais pas vu l’édit, ma question porte sur le pi de test
Bonsoir
Comme indiqué plus haut je repars de la même base de Pi 4 (celui qui porte la version production…)
ce n’est pas grave si la version prod devient bugguée, je n’avais rien fait dans l’attente de voir remonter les températures des tasmota…
Je viens de refaire un essai : la découverte MQTT ne semble pas fonctionner mais la découverte HTTP est OK
@VonOx
Sur le PI de test pour créer le docker gladys atrovato/gladys:tasmota j’ai utilisé :
docker run -d \
connexion en SSH sur le Pi de Test
Je complètes mes test de ce soir
Je suis sur mon PI de production (PI4 8Go sous Pi Os 64 bits)
Environnement Docker/portainer
J’ai desactivé/arrêté toutes les images liés à mon gladys production y compris mosquitto Eclipse
J’ai arrêté la première image de test y compris supprimé l’image et le dossier sur le PI 4 des données
J’ai relancé l’image avec Docker Run
Je pensais que la nouvelle installation me créerait un nouveau container MQTT Eclipse, non il a relancé celui arrêté, il a fallut simplement que je rentre le login et MDP
Et là la découverte MQTT s’opère bien…
Peut être que les deux install se contrariaient…
Je peux faire des tests à la demande
Par contre petit souhait complémentaire :
Sur mon tasmota THR320 j’ai 3 sondes DS18B20 et il y a en plus celle qui est interne (temp device)
A l’issue de la découverte on a normalement cela :
Ce serait bien pour arriver à cela d’avoir des identifiants qui remontent
Autant c’est facile de trouver la sonde sur un tasmota avec une seule sonde, autant sur un tasmota avec 3 sondes c’est un peu plus casse tête
Mais merci aux développeurs de tous ces pas effectués !!
Je viens de rajouter autour de mon container de test un sonoff Tasmota THR320 et une sonde THS01 (température, point de rosée, humidité)
Il ne trouve que la température de la sonde ESP :
Voilà, merci de me dire si il faut tester des manips, laisser la main sur ce PI…
Salut, le point de rosée n’est pas géré pas Gladys, mais pour les autres, on va faire ce qu’il faut pour qu’ils soient intégrés !
Merci pour ce retour…
Si cela est nécessaire pour le forum, l’évolution de Gladys, il faut pas hésiter à me solliciter pour faire des test…
1 « J'aime »
Les fix liés aux capteurs de température Tasmota de la PR ( Tasmota: Add more temp devices by atrovato · Pull Request #1570 · GladysAssistant/Gladys · GitHub) ont été intégré dans Gladys Assistant v4.11 !