Bonjour,
J’ouvre cette discussion sur l’idée de créer des antennes déportées afin de placer des dispositifs techniques a proximité de capteurs ou d’actionneurs à l’image de ce que fait le plugin « bluetooth » Blea et ses antennes.
J’ai typiquement le besoin de contrôler des têtes thermostatiques (Danfoss Eco et Eurotronic comet blue) qui sont pilotables en bluetooth.
Au départ, j’ai essayé de le faire de manière centralisée à partir de jeedom avec un dongle bluetooth réputé + antenne (Sena). Mais j’ai constaté des problèmes de fiabilité ce qui était embêtant pour du chauffage.
J’ai donc disposé des « antennes déportées », soit des petits raspberry zéro wh a proximité des radiateurs : ils communiquent en buetooth avec une bonne fiabilité avec les têtes thermostatiques, et sont pilotés en ssh/wifi avec jeedom via le plugin script.
Je voudrais améliorer la communication entre « ces antennes » et jeedom.
J’ai regardé jeelink, mais cela impose d’installer tout un jeedom, si c’est encore envisageable sur un raspberry zéro, sur d’autres dispositifs tels que des pycom, etc ce n’est pas envisageable.
L’idée que j’ai serait de remplacer la communication ssh/wifi par du mqtt/wifi. Je cherche donc à identifier quelles technologies utiliser pour créer des « petits serveurs mqtt » muliplateformes qui deviendraient le système nerveux de ces « antennes déportées ».
Merci pour vos pistes.
Bonjour,
ESP32 ne serait il pas une solution ?
il y moyen de le mettre en client mosquitto. Après pour faire la passerelle il faut que je regarde, je n’ai jamais fait j’utilise de l’esp8266 pour le moment ça suffit pour mes utilisations mais pas de buetooth .
Je te tien informé
Salut,
Je vois bien l’idée de ta solution, mais je me pose une question : quels sont les critères qui te font choisir de ne pas remplacer les têtes thermostatiques par les même en zwave par exemple ?
Le défaut que je vois à ton idée, c’est la chaîne de commande : wifi → bluetooth avec les intermédiaires électroniques (wifi saute, souci d’alim des antennes…mise à jours de composants)
J’ai bien quelques réponses en tête mais je suis curieux
@PanoLyon Oui ESP32 comme esp8266, pycom ou des raspberry pi zero sont autant de plateformes matérielles pour réaliser des « antennes déportées ».
Il y a beaucoup de technologie matérielle qui peuvent être envisagées.
Au delà de l’aspect matériel pour ces antennes, je me pose surtout des questions sur la plateforme logicielle à concevoir pour ces plateformes matérielles pour devenir une « antenne jeedom ».
J’ai envie d’orienter la communication avec jeedom sur la base de mqtt, mais il reste à concevoir le dispositif logiciel ad hoc, c’est à dire avec une empreinte mémoire aussi légère que possible, une portabilité sur différents matériels assez grande et une adaptabilité aux différents capteurs. Dans mon cas, mes têtes thermostatiques bien qu’en bluetooth sont de marques différentes et ne parlent pas le même « bluetooth ».
@naboleo, c’est pas toujours facile de faire des choix complètement homogènes. Dans mon cas particulier, j’ai une dizaine de radiateurs à piloter, j’ai donc pris comme critère celui du coût des têtes et je me suis fixé un budget de 20€ par radiateur. Cela m’a amené à acquérir des têtes de 2 constructeurs différents : eurotronic comet blue et danfoss eco qui rentrent dans ce budget. L’hétérogénéité était déjà présente au niveau des vannes : j’ai du giacomini et du comap. Les giacomini et les comap sont incompatibles au niveau de leur raccordement physique et aucunes de ces vannes ne supportent le standard M30. Il faut donc mettre des adapteurs M30 pour les raccorder à des têtes qui sont toutes en standard M30. Parfois le seul coût de ces adaptateurs est proche de 10 €…donc pour un budget de 20€, cela peut être difficile.
Au delà du prix, je suis très content de ces 2 têtes.
@naboleo, pour compléter ma réponse, l’idée d’antenne déportée est celle d’une architecture distribuée vs une architecture centralisée. Les 2 types d’architecture sont pertinentes, l’architecture centralisée est plus simple à mettre en oeuvre en général, mais elle trouve aussi ses limites : saturation du point central, efficacité globale.
Typiquement le protocole zigbee a plutôt une approche distribuée : chaque noeud du réseau pouvant servir de relais pour créer un réseau maillé…
Merci pour ces précisions @Minscof
J’imaginais bien une série de contrainte budgétaires et techniques. Facile puisque j’ai eu les mêmes : têtes thermostatiques hétérogènes et achat immobilier qui plombe un peu le budget.
Je suis moins convaincu par l’aspect distribuée la solution. Il faut quand même convenir que la saturation est assez peu risquée dans le cas d’une installation domotique personnelle (j’ai aussi une 10aine de points de chauffage). Et la partie maillage/répéteur se traite également assez bien en zwave. Et pour ma part, j’ai placé avant l’aspect résilience : moins de matériel = moins de risque de panne même si plus grave.
Mais ta démarche est intéressante ! je vais suivre les progrès
Donc avec l’ESP32 tu as une passerelle ble2mqtt
https://github.com/shmuelzon/esp32-ble2mqtt
j’ai aussi trouvé un forum sur les paserelles https://community.openmqttgateway.com/c/gateways/5 (l’interface de celui-ci ne devrait pas te dépayser 
)
pour ma part j’utilise zigbee2mqtt sans problème.
@PanoLyon, en iot, mqtt est largement supporté, et c’est pour çà que je réfléchis à utiliser ce protocole pour dialoguer avec jeedom.
La question qui reste entière est celle du logiciel qui va faire l’interface entre mqtt vers jeedom d’un côté, et les capteurs/actionneurs de l’autre, un peu à la manière de ce que fait jeedom. Bref c’est faire un mini jeedom pour ces « antennes déportées ».
Jeedom a par exemple fait le choix du langage php, sans framework et le code de jeedom est très important.
Ici l’idée serait d’identifier les technologies logicielles à utiliser en plus de la brique mqtt.
Quel langage : php ? python ? javascript ? java ? C ?
Au delà du langage, y a t il des frameworks tels que pybytes/micropython à privilégier etc…
Ce sont ces technologies qui me questionnent pour ne pas réinventer les choses et peut-être partir d’un développement déjà existant.
ha ! ha ! si j’ai bien compris tu voudrais un réseau mono ou multi antennes, dédié, indépendant et autonome, qui s’interfacerait sur jeedom via mqtt ?
c’est ça ?
Oui, c’est cela, et ton lien sur openmqttgateway est très intéressant car c’est exactement l’idée que j’avais en tête : disposer de gateway « universelle » capable de traduire différent protocole : bluetooth/danfoss, bluetooth/eurotronic, bluetooth/nut, mais aussi lora, sigfox etc… et de dialoguer de manière bi-directionnelle avec jeedom via mqtt.
En fouillant, cela m’a permis de découvrir le projet homie qui est aussi très intéressant.
Si certains ont expérimenter ces plateformes logicielles : opengatewaymqtt, homie ou d’autres, je suis preneur de leur expérience avis. J’aimerais bien aussi avoir l’avis de @Loic sur ces projets et leur intégration dans jeedom.
je vais donc suivre cette idée titille ma curiosité