MQTT possible ??

[FGM]

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

[KikiFUNstyle]

Pas trop compliqué ...
Il te faudra une autre machine (Rpi 0/3/4 ou mini PC) avec un broker MQTT + Node-RED

Et Node-RED qui fait le lien en MQTT et Eedomus


C'est cette passerelle ou celle ci ?
Il semble qu'elle possède une API !

MQTT and Restful API for other interfaces like NodeRED and Loxone

API -> https://emsesp.github.io/docs/Commands/#http

[Fab_Rice]

Bonsoir FGM,
Si tu as des notions en élec tu dois aussi pouvoir faire "plus simple" avec un ou deux FGS224 ou ZMNHBD1, ça permet de piloter le M/A de la chaudière, le ou les circulateurs et potentiellement la température, le tout en zwave.

[MaDomotic]

Bonjour,

Même soucis mais également pour piloter des Shelly.
Les requêtes http de ces derniers sont très consommatrices de ressources pour l'eedomus.

Aussi dans le cadre d'un autre projet, j'envisage de sortir une passerelle KNX mais aussi MQTT basée sur un Orange Pi moins onéreux qu'un Raspberry et surtout avec de la EMMC afin de ne plus être dépendant d'une SDCard.
Incluant Node-RED avec mes nodes et permettant le lien vers eedomus, elle pourrait être de 120€ clé en main ou une image gratuite à disposition pour ceux qui savent préparer un Orange Pi.

Si ça intéresse la communauté ... à suivre.

Olivier

[fanste]

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

Bonjour à priori nous sommes quelques uns à souhaiter un serveur MQTT mais cela semble complexe pour l’eedomus à priori peu d’écho dans l’ėquite de développeurs…

[MaDomotic]

Aux dernières nouvelles, c'est envisageable pour la Team car ils l'ont implémenté il y a quelques temps pour un gros client, mais aucun délai pour une mise à jour de nos box.

[2048tm]

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

I'll utilize the mosquitto_sub client utility instead of building a Python script to scan the topics. Now Using the scanner, we should be able to see that the connection status has been changed and that they are both connected. Stop sensor2 by pressing CTRL+C to mimic a network failure.

[Madoma73]

Est-ce que le mqtt va arriver sur l'eedomus ?
je suis à 2 doigts de migrer vers une autre solution pour pouvoir profiter de mqtt

[kalthen]

cette possibilité m'interesserait aussi!
Avis aux Devs

[Bart (eedomus team)]

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.

[Nico67]

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, si vous avez quelque chose de fonctionnel pourquoi ne pas le mettre en place ?
Cela pourrait être intéressant d'avoir plusieurs cordes à son arc non?
Bonne journée à vous.

[jluc2808]

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 bonjour, intéressant, je pense qu'il y a un point dans l'usage MQTT qui est assez fondamentalement en plus par rapport de l'usage HTTP (ou HTTPS)

MQTT permet à plusieurs systèmes de collaborer dans 1 centre de post commun et surtout permet d’éviter la problématique du bidirectionnel (multiple) qui fait miroir entre 1 ordre reçu et sa conséquence qui déclenche un ordre donné.

je m'explique: quand on a plusieurs systèmes actifs avec un même device, il est nécessaire de synchroniser toutes les représentations du même device sur les différents systèmes pour lequel il est connu.

Si on a pas de centre de postage unique (MQTT), alors on doit mettre en place un échange bidirectionnel (entre chaque système) de: je t’envoie un changement état, mais qui déclenche de l'autre côté, l'état a changé donc je t’envoie le nouvel état et en fonction des dialogues (ça peut) ça va créer du bagottement.

Avec le centre unique de postage (MQTT) cela règle ce problème puisque l'abonnement sur le device ne va plus diffuser de modifications pour celui qui a déjà le bon état, la référence devenant l'état dans le centre de postage.

donc OUI, 3 fois OUI à la mise en place de MQTT dans eedomus.

[misterden]

Concernant le MQTT , le fabricant CGE ELECTORNICS à un produit pour contrôler la qualité de la piscine qui peut communiquer en MQTT : Le XPOOL CONNECT
https://www.gce-electronics.com/fr/accu ... 90421.html

Je pose ça là pour suivre l'évolution si l'eedomus peut ou pas prendre en charge ce " protocole" car il existe peu d'appareil similaire ( les FLIPR et autres trucs flottants sont trop fragiles ou gadget et à des prix trop élevés , j'ai eu un FLIPR il fallait un abonnement à payer pour récupérer les infos + acheter une nouvelle batterie quasiment tous les ans ... le truc est mort il a pas tenu 2 ans , donc je veux un appareil simple , sur secteur dans le local piscine et communicant ).

[vva]

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

[misterden]

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

PAs sur qu'ils écoutent ... fais une demande de support technique ils pourront pas ne pas être au courant là

[davidsanborn24]

cette possibilité m'interesserait aussi!
Avis aux Devs

problème de sécurité qui nous a poussé à tout reprendre

[Jason967]

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

Hello FGM,
There's nothing stupid about it, your question is very reasonable as you want to make better use of existing technology.
Eedomus is a smart home system that is quite flexible and can integrate with many different devices and protocols, including MQTT

[vva]

cette possibilité m'interesserait aussi!
Avis aux Devs

problème de sécurité qui nous a poussé à tout reprendre

Bonjour,
C'est à dire ? Vous avez repris quoi ? Il y a des personnes qui travaillent dessus ?

[zanifine]

MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe network protocol that transports messages between devices. It is designed for connections with remote locations where a "small code footprint" is required or the network bandwidth is limited.