Je teste depuis un an le plugin Thermostat associé à thermoalternateview pour un joli affichage en mode web.
Il me manquait cependant un hardware pour intervenir sur les réglages, avec un petit afficheur et un relevé de température local.
En effet, pénible de devoir sortir son téléphone dès que l’on veut ajouter un degré ou voir la température de la pièce. De plus les capteurs de température sans fils ont la fâcheuse tendance à tomber en panne de batterie.
Du coup, pour un meilleur WAF et une bonne fiabilité, je me suis lancé dans le prototypage d’un petit objet connecté qui sera alimenté sur secteur sur la base d’un ESP8266 avec un capteur de température, un petit écran OLED et 2 petits boutons tactiles. Le tout sera placé au dessus de l’interrupteur de la pièce par exemple.
Je partagerai le projet avec plaisir dès qu’il sera un peu plus avancé. Ci-dessous, une photo du proto pour illustrer en attendant mieux.
Pour intégrer le gadget au plugin Thermostat de Jeedom, je me suis paluché un virtuel, un script et un scénario. Ca fonctionne, mais c’est franchement lourd, surtout si on a de nombreux radiateurs à piloter.
Du coup, je me suis dit qu’un plugin dédié pourrait être la solution. Me voici alors en pleine lecture du tuto pour débuter le développement d’un plugin fait maison.
Mais avant de partir tête baissée dans le développement, je me dis que l’excellent plugin Thermoalternateview fait déjà une partie du boulot en interfaçant le plugin thermostat.
Il me semble que l’idéal serait plutôt de pouvoir piloter ce plugin de l’extérieur en exposant une API qui serait appelée lors de l’envoi d’une nouvelle consigne ou lors d’un relevé de température par l’objet physique. Ensuite, il faudrait que le plugin soit capable d’appeler l’API de mon gadget lors de tout événement (changement de consigne, de mode, chauffage on/off, fenêtre ouverte,…). En clair, il faudrait une interface bidirectionnelle entre le gadget physique (mon projet) et le gadget virtuel (thermoalternateview).
Pensez-vous que cette approche ait du sens ou voyez-vous meilleure solution ?
Merci de m’avoir lu jusqu’au bout
C’est une très bonne idée et ça fonctionne bien, je viens de le tester.
Cependant il me reste à résoudre le sens inverse. C’est à dire quand je pousse du hardware vers Jeedom.
En utilisant un virtuel intermédiaire, je peux passer par la JeeApi de ce virtuel. Mais je ne trouve pas s’il est possible de pousser directement vers l’Api du thermostat.
Merci bcp pour tes réponses rapides
Ca, pour le coup, j’avais essayé mais à la différence du push sur un virtuel ça coince qq part.
Dans la log de jeeEvent j’ai un message du type « Vous n’êtes pas autorisé à effectuer cette action, IP : XXX.XXX.XXX.XXX ».
J’y avais pensé au début mais ce ne sera pas plus simple d’interfacer le plugin Thermostat de Jeedom.
Mais quand je m’occuperai du portail de configuration de l’objet (pour le moment tout est en dûr), pourquoi pas proposer les deux protocoles.
Oui, c’est bien celle-ci que j’essaie d’utiliser et elle est bien activée.
Cependant, j’ai une piste. Je suis en Beta (4.2.5) et il me semble avoir lu quelque part qu’il ont changé un truc au niveau de la gestion des Api pour augmenter la sécurité. Va falloir que je fouille un peu.
Intéressant !
Ca passe en update ? tu ajoutes un « &value=XX » à la fin de ton url ?
genre : /core/api/jeeApi.php?api=XXXXXXXXXXXXXXXX&type=cmd&id=1234&value=23
Arf, je passe forcément à côté d’un truc.
Je vois dans le log que l’api reçoit bien ma requête. Mais il n’update pas la valeur.
Demande sur l’api http venant de : 192.168.0.1 => {« api »:« XXXXXXXXXXXXXXXX »,« type »:« cmd »,« id »:« 1234 »,« value »:« 23 »}
Je vais creuser encore. En tout cas, sympa d’avoir pris du temps.
Oui pour le WAF, je te l’accorde, c’est pas encore ça
Mais le proto, Madame ne le verra pas.
La prochaine étape, ce sera le design du support en 3D, puis impression, puis le PCB qui va bien.
Je vais essayer de faire un truc joli, j’ai déjà 2 ou 3 idées.
Pour Tasmota, j’ai jamais creusé mais j’avais déjà utilisé ESPEasy. Je ne saurais pas comparer les 2 solutions.
Ceci dit, ce qui m’a manqué côté ESPEasy c’est d’être libre dans la gestion de mon afficheur OLED et avoir la possibilité d’y mettre des Bitmaps, changer les polices…
En codant moi-même, je fais ce que je veux.
La gestion bidirectionnelle du chauffage, c’est galère.
En effet, un changement de consigne dans le virtuel doit changer la consigne de vanne.
Un changement de la consigne depuis la vanne doit mettre à jour la consigne du virtuel sans renvoyer une consigne identique à la vanne : attention à la boucle. Même idée pour la consigne de la consigne de la chaudière.
Je comprends
Un écran en MQTT qui donne accès à toutes infos et actions utiles de la pièce, ce serait cool. Pourquoi se limiter au chauffage ?
En fait ça dépend du cas d’usage. Et puis faut bien commencer par quelque chose. J’ai aussi expérimenté l’écran tactile Nextion. Il a ses avantages et ses inconvénients. Là, j’ai besoin de concevoir un projet pour lequel je limite le coût de réalisation à 15€ par bête car j’ai 10 radiateurs à commander. De plus, je veux une solution avec une fiabilité plutôt haute.
A la base, j’avais commencé sur de l’arduino avec MySensors. Cependant la mémoire vive de l’atmega328 ne me permettait pas de faire tourner mon code. Du coup, l’ESP8266 est un bon compromis.
Pour le design, c’est vrai que le X-Display de CGE est élégant.
Mais je pense partir plutôt sur un design rond de type NEST avec une façade noire brillante, juste histoire de me compliquer un peu la vie
Moi aussi je suis super intéressé par un petit écran simple pour avoir un thermostat dans chaque pièce, avec on/off, + - et choix mode auto ou manuel, ( auto serait géré par plugin thermostat, manuel on prend la main le temps que agenda repasse en gestion auto) , fonction avec pile donc écran économique, en zigbee ou zwave ou enocean
