MQTT and Restful API for other interfaces like NodeRED and Loxone
FGM a écrit:Bonjour,
Je ne suis pas un geek et je vais poser une question qui est peut être stupide.
J'ai une box eedomus pour contrôler un certain nombre de choses à distance dans une résidence secondaire (température quand hors gel etc..) et tout marche bien .
Il y a une chaudière fioul que je voudrais pouvoir piloter à distance ; j'ai trouvé une passerelle (BBQKees) qui permettrait de faire cela mais cette passerelle utilise le protocole MQTT . D'où ma question : y a -t-il un moyen (pas trop compliqué.... ) de faire communiquer eedomus et cette passerelle ?
Merci par avance.
FGM
FGM a écrit:Bonjour,
basketball stars
Je ne suis pas un geek et je vais poser une question qui est peut être stupide.
J'ai une box eedomus pour contrôler un certain nombre de choses à distance dans une résidence secondaire (température quand hors gel etc..) et tout marche bien .
Il y a une chaudière fioul que je voudrais pouvoir piloter à distance ; j'ai trouvé une passerelle (BBQKees) qui permettrait de faire cela mais cette passerelle utilise le protocole MQTT . D'où ma question : y a -t-il un moyen (pas trop compliqué.... ) de faire communiquer eedomus et cette passerelle ?
Merci par avance.
FGM
Bart (eedomus team) a écrit:Nous nous interrogeons sur MQTT depuis quelques temps.
En domotique, ce protocole est surtout utilisé en "intrabox" (entre un driver et le système, zigbee2mqtt par exemple).
Nous n'avons pas besoin de cette couche en plus. Ce protocole lancé par IBM est en vogue, mais nous ne voyons pas d'avantages clairs de MQTT vis à vis de HTTP. HTTP est aussi rapide unitairement.
Il est facile à tester dans un browser. La sécurisation de HTTPS est robuste. Côté cloud, HTTPS tient la charge.
Les périphériques proposant MQTT sont généralement compatibles HTTP (Shelly par exemple).
Cela dit, nous sommes ouverts à l’implémenter dans la box eedomus s'il y a des besoins importants MQTT qu'on ne pourrait pas couvrir avec HTTP.
D'un point de vue technique c'est faisable, nous avons un prototype fonctionnel qui ne prend pas trop de ressources à la box.
Bart (eedomus team) a écrit:Nous nous interrogeons sur MQTT depuis quelques temps.
En domotique, ce protocole est surtout utilisé en "intrabox" (entre un driver et le système, zigbee2mqtt par exemple).
Nous n'avons pas besoin de cette couche en plus. Ce protocole lancé par IBM est en vogue, mais nous ne voyons pas d'avantages clairs de MQTT vis à vis de HTTP. HTTP est aussi rapide unitairement.
Il est facile à tester dans un browser. La sécurisation de HTTPS est robuste. Côté cloud, HTTPS tient la charge.
Les périphériques proposant MQTT sont généralement compatibles HTTP (Shelly par exemple).
Cela dit, nous sommes ouverts à l’implémenter dans la box eedomus s'il y a des besoins importants MQTT qu'on ne pourrait pas couvrir avec HTTP.
D'un point de vue technique c'est faisable, nous avons un prototype fonctionnel qui ne prend pas trop de ressources à la box.
Bart (eedomus team) a écrit:Nous nous interrogeons sur MQTT depuis quelques temps.
En domotique, ce protocole est surtout utilisé en "intrabox" (entre un driver et le système, zigbee2mqtt par exemple).
Nous n'avons pas besoin de cette couche en plus. Ce protocole lancé par IBM est en vogue, mais nous ne voyons pas d'avantages clairs de MQTT vis à vis de HTTP. HTTP est aussi rapide unitairement.
Il est facile à tester dans un browser. La sécurisation de HTTPS est robuste. Côté cloud, HTTPS tient la charge.
Les périphériques proposant MQTT sont généralement compatibles HTTP (Shelly par exemple).
Cela dit, nous sommes ouverts à l’implémenter dans la box eedomus s'il y a des besoins importants MQTT qu'on ne pourrait pas couvrir avec HTTP.
D'un point de vue technique c'est faisable, nous avons un prototype fonctionnel qui ne prend pas trop de ressources à la box.
vva a écrit:Bart (eedomus team) a écrit:Nous nous interrogeons sur MQTT depuis quelques temps.
En domotique, ce protocole est surtout utilisé en "intrabox" (entre un driver et le système, zigbee2mqtt par exemple).
Nous n'avons pas besoin de cette couche en plus. Ce protocole lancé par IBM est en vogue, mais nous ne voyons pas d'avantages clairs de MQTT vis à vis de HTTP. HTTP est aussi rapide unitairement.
Il est facile à tester dans un browser. La sécurisation de HTTPS est robuste. Côté cloud, HTTPS tient la charge.
Les périphériques proposant MQTT sont généralement compatibles HTTP (Shelly par exemple).
Cela dit, nous sommes ouverts à l’implémenter dans la box eedomus s'il y a des besoins importants MQTT qu'on ne pourrait pas couvrir avec HTTP.
D'un point de vue technique c'est faisable, nous avons un prototype fonctionnel qui ne prend pas trop de ressources à la box.
Bonjour @Bart, et donc quelle est votre stratégie à court terme concernant MQTT? Vous déployez ou pas sur nos box ? Pour ma part, j'en aurai besoin pour les produits Zendure (https://forum.eedomus.com/viewtopic.php?f=50&t=12225&hilit=zendure) . Merci
kalthen a écrit:cette possibilité m'interesserait aussi!
Avis aux Devs
FGM a écrit:Bonjour,
Je ne suis pas un geek et je vais poser une question qui est peut être stupide.
J'ai une box eedomus pour contrôler un certain nombre de choses à distance dans une résidence secondaire (température quand hors gel etc..) et tout marche bien
Il y a une chaudière fioul que je voudrais pouvoir piloter à distance ; j'ai trouvé une passerelle (BBQKees) qui permettrait de faire cela mais cette passerelle utilise le protocole MQTT . D'où ma question : y a -t-il un moyen (pas trop compliqué.... ) de faire communiquer eedomus et cette passerelle ?
Merci par avance.
FGM
davidsanborn24 a écrit:kalthen a écrit:cette possibilité m'interesserait aussi!
Avis aux Devs
problème de sécurité qui nous a poussé à tout reprendre
Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 4 invité(s)