Bonjour, j’ai chez moi des modules sonoff mini que j’avais flasher avec tasmota et il m’en restait un non flashé que j’ai pu tester avec le module ewelink ce qui m’a permis de comparer un peu. J’ai remarqué un petit bug sur le retour d’état dans l’interface gladys. Quand j’allume mon sonoff mini depuis l’interrupteur le retour ce fait bien dans l’interface mais pas quand j’éteins le sonoff. J’ai essayé de changer les délais dans les réglages rien ne change mis a part quand je met toutes les secondes où plus rien ne marche.
Salut @adrien-cardinale, je tag ici @Pti_Nico qui est le développeur du service eWelink. Merci pour tes retours !
1 « J'aime »
Merci pour le retour 
Pour info, je viens de corriger un bug de détection qu’on m’avait remonté et j’en profite pour apporter des améliorations au service.
Peut-être pourras-tu tester cette nouvelle version une fois qu’elle sera dispo ?
1 « J'aime »
@pierre-gilles petite question technique concernant les modules Sonoff avec plusieurs canaux (image ci-dessous).
Doit-on créer 4 devices avec 1 feature “Power” ou 1 device avec 4 features “Power” ?
Bonjour à tous,
Je viens de recevoir mes sonoff mini R2, et je me demandais quelle était la différence entre le service Ewelink et Tasmota? En utilisant Ewelink, les requêtes sont envoyées sur des serveurs chinois, alors que Tasmota tout se passe en local, c’est bien ça?
Du coup je pense utiliser Tasmota. Est-ce que mon raisonnement est le bon ?
C’est tout à fait ça. Il faut que tu les flash avec Tasmota.
Super merci pour la réponse rapide!
Pour flasher le Sonoff mini R2 j’ai vu qu’il fallait passer en mode développeur. J’ai trouvé un tuto (en français) qui explique comment faire pour ce modèle là, si jamais ça peut aider quelqu’un : Sonoff DIY Mini R2 - Objets connectés - Communauté Jeedom
Il serait possible de commander les modules sans utiliser le cloud, ni flasher Tasmota :
1 « J'aime »
Oui, avec une API Rest sur le réseau local.
Du coup, c’est moins cool pour le retour d’état, faut constamment poller…
@AlexTrovato, sinon, un avis concernant ma question posée plus haut, à propos des devices multi canaux ?
@Pti_Nico : Pour moi il faudra 4 devices
Si j’ai bien compris le fonctionnement de Gladys, un device est lié à une pièce. Sauf que l’on pourrait imaginer que les 4 devices pilotés sont dans des pièces différents.
Du coup, un device ne peut avoir qu’une seule feature de chaque type…
Oui je te tiendrais au courant ça sera dans la prochaine mise a jour de gladys ?
En théorie on devrait avoir un device avec 4 features, mais pour l’instant on n’a pas encore résolu le problème du « si ces 4 features sont dans 4 pièces différentes », qu’on veut résoudre avec les devices virtuels. cf:
Donc à toi de voir si c’est bloquant pour l’instant. Si oui, on peut faire une première approche « 4 device avec 1 feature » et migrer vers l’autre dès que le sujet device virtuel a avancé, si c’est pas si grave en attendant, tu peux partir directement vers l’approche 1 device avec 4 feature"
tu en pense quoi ?
Je suis d’accord avec le fait qu’un device est un appareil physique et qu’il peut donc avoir 4 features du même type.
Mais si on considère un device comme l’appareil qui est commandé, du coup, ça change la donne, car les 4 features peuvent être dans des pièces différentes et donc il faut 4 devices.
L’idée des devices virtuels permettraient de gérer ce cas (1 device physique et 4 virtuels associés chacun à une feature).
Pour info, j’ai essayé de créer un device avec 4 features du même type et j’ai rencontré un problème avec la fonction “getDeviceFeature” (pour le polling) qui ne retourne que la première feature d’un type pour un device.
Pour le service eWeLink, j’ai opté pour 1 device par feature du même type.
N’utilise pas la fonction dans ton cas, c’est une fonction qui fait une ligne de toute façon ^^
Avec un peu de retard, pour moi il ne faut pas prendre la responsabilité de créer 4 devices à partir d’un seul, cela va porter à confusion.
1 « J'aime »