MQTT - Creating a pure MQTT device

[cce66]

This request concerns this discussion

Mode alarme - 2 questions

Maintenant que nous avons un super Mode alarme, je vais pouvoir paramétrer et mettre en service mon système d’alarme. Deux questions : Quelle est la syntaxe complète de l’URL quand on a rajouté « ?fullscreen=force » à xxxxxxxxxxxxxsistant.com/dashboard/123-alarme? J’ai « tout » essayé et je n’arrive pas à avoir le plein écran sur mon iPad ! J’ai une sirène HEIMAN, et je ne sais pas comment la déclencher. [image] [image] Merci pour votre aide

and doesn’t seem quite the same as this one because here it’s in the scenes, hence this request

Nouveau déclencheur : arrivée d’un message MQTT

Feature description Suite à notre discussion ici Une scène doit pouvoir être déclenchée quand un message MQTT arrive sur un topic particulier.

So the idea would be to have the ability to create a device in the MQTT integration that would react to a dedicated MQTT subscription to transform it and use it in Gladys and allow Gladys to publish to it without having to go through Node-RED

so move from a « text » device

to a pure MQTT device

There you go — I hope I’ve been clear! Cast your votes

[pierre-gilles]

I don’t know if this request is very clear and if it makes sense…

[cce66]

I’m replying here; it seems more appropriate
Hello @pierre-gilles,

@pierre-gilles

You’re mixing everything up @cce66

The only solution here is simply to integrate the siren into Gladys; it’s not a huge job, it just needs someone to do it

@cce66

I created a feature request that should meet your need (and others’, I think! )

No, that won’t meet the need; the solution here is simply to integrate the siren into Gladys.

I’m not mixing everything up, at least I hope so …But as Lao-Tzu said « If you give a man a fish, he will eat for a day. If you teach him to fish, he will eat forever. »

The idea is that, via this feature request, it would allow using any device that isn’t yet integrated without having to go through Node-RED (now, if it’s hard to do or not part of the short-term objectives I understand that it won’t be done; there’s no ambiguity about that).

MQTT - creation d'un appareil MQTT pur

Cette demande concerne cette discussion et me parait pas tout à fait similaire à celle-ci car ici c’est dans les scénes, d’où cette demande Donc l’idée serait d’avoir la possibilité de créer un appareil dans l’intégration MQTT qui réagirait à un suscribe mqtt propre pour le transformer et l’utiliser dans gladys et permettre depuis Gladys de publier vers lui sans devoir passer par Node-red donc passer d’un appareil « texte » [image] à un appareil MQTT pur [image] Voila j’espère avoir ét…

There, I hope I’ve been clearer and have given some meaning to this request…

[pierre-gilles]

You’re confusing the MQTT integration and the Zigbee2mqtt integration

These two integrations are not connected to each other; you would like the user to be able to send manual commands to the Zigbee2mqtt server.

I don’t think that’s in the project’s philosophy — why not just add the missing siren (which is a small task)?

[cce66]

So unless I’ve already slipped into senility and am a candidate for a nursing home, but when I reread

MQTT, un protocole pour tous les rassembler - Partie 1 : le broker

MQTT, un protocole pour tous les rassembler - Partie 2 : publier et souscrire

I understand that on one side we have devices (sensors, plugs, etc.) that communicate using a radio protocol, Zigbee, which is hardware-wise to a gateway dedicated to the vendor or to a generic dongle (Conbee, Deconz, Sonoff) which allows bypassing the vendor gateways to a TCP protocol which is MQTT (similar to a network card on a PC).
I understand that this MQTT protocol transmits TCP frames to a broker (dedicated http server) MQTT and does so bidirectionally.
That this broker works in the manner

• I receive such an MQTT message (topic) with content (payload) I forward to the people who subscribed to that message(topic) in the list of subscriptions that I have the value of the message (payload).
  In the case of the alarm, looking at the docs I see
  
  

So you must send (publish) to the topic
zigbee2mqtt/FRIENDLY_NAME/set
the message
{"warning": {"duration": 10, "mode": "emergency", "strobe": false}}
Isn’t it?

@pierre-gilles

These two integrations are not connected to each other, you would like the user to be able to send manual commands to the Zigbee2mqtt server.

No, I would like the user to be able to send manual commands to the MQTT server

I sometimes feel like I’m annoying you @pierre-gilles

[_Will_71]

Currently the MQTT broker of the MQTT integration is not connected to the MQTT broker of zigbee2mqtt.
These are two completely different integrations with no link between them

[cce66]

@_Will_71

However, if I look at the docs…

MQTT | Zigbee2MQTT

Or maybe I don’t understand everything

[spenceur]

[quote=« cce66, post:7, topic:8455 »]
Or else I don’t understand everything :up

[_Will_71]

To summarize, yes there are 2 MQTT brokers.
1 dedicated to zigbee2mqtt and another for the MQTT integration.

[cce66]

Indeed, I thought the configuration in zigbee2mqtt pointed to the MQTT server installed by Gladys, but in fact it points to the MQTT server that the container itself hosts.
By looking at the open ports I understood that there was port 1883 for the MQTT broker of the MQTT docker

and port 1884 for the MQTT broker of the Zigbee2Mqtt container

I hadn’t grasped the need for the duplicate MQTT broker, then I understood by looking at the different integration codes on GitHub that the MQTT broker of the zigbee2mqtt docker only serves to translate between Gladys’s own syntax and that coming from zigbee2mqtt in the zigbee2mqtt container.
So basically, when a device is integrated in the zigbee2mqtt integration of Gladys there is a correspondence made between (to reuse the alarm example) the Gladys syntax

gladys/master/device/mqtt:Heiman/feature/mqtt:Heiman/text

and the zigbee2mqtt syntax
the sending (publish) to the zigbe2mqtt broker with the topic
zigbee2mqtt/FRIENDLY_NAME/set
and payload
{"warning": {"duration": 10, "mode": "emergency", "strobe": false}}
at least when the device has been integrated, is that correct?

To repeat @spenceur’s sentence

@spenceur

Il y a l’intégration mqtt qui a son broker pour communiqué avec node red ou alors avec gladys lui meme avec ces virtual device.

There is the MQTT integration which has its broker to communicate with Node-RED or else with Gladys itself with its virtual devices.

The MQTT integration serves as a kind of API or means of communication between Gladys and Node-RED, am I right?

Whatever the devices created in the different integrations (Hue, Xiaomi, zigbee2mqtt, MQTT, etc.) they become and are treated as virtual devices inside Gladys, the integration layer serving as an interface (like an API) between Gladys and external protocols — is that correct or am I still mistaken?

I’m sorry for being a pain, but understanding how the internal workings operate also helps to grasp the external functionality and to know what can be requested or obtained as features or even to try to help with the code! This may seem obvious to those who have understood Gladys’s internal workings, but for others it’s not easy to apprehend… Knowing how Gladys works can also attract competent developers to join the current team.
I looked at the code on GitHub and I must say that it’s not very explicit or not well documented, that’s my opinion and mine alone…

[pierre-gilles]

@cce66

I sometimes feel like I’m annoying you @pierre-gilles

Don’t take it the wrong way, but sometimes you jump into threads where a beginner asks a simple question with a very simple answer, and you respond with a very complicated and incorrect answer

In Gladys 4 I really had the goal of simplification and of building a consumer product without developer jargon. Sometimes in your interventions you steer new users in the opposite direction which as a result can indeed irritate me a little (but I try to remain courteous ).

[cce66]

I don’t take it badly; when I step in to answer it’s also with what I think I understood (on the MQTT container / Zigbee2MQTT side I screwed up, I admit) and in the solution I propose I can be wrong (the forum is made for that, to make progress, right?), in this case suggesting to go through Node-RED seems appropriate (but your approach of saying it would be better to develop it further is the right one) but in the meantime how does @Isage do it? With my IPX800V5 I struggled to interface it with Gladys via MQTT, I found and made a mini-tutorial for that while waiting for this integration to be done someday if it is (it exists in Home Assistant (HA) and Jeedom), by making this mini-tutorial which I also published on the IPX800 forum, it’s to introduce Gladys and show that even if the hardware is not supported by Gladys you can work around it by going through Node-RED just like for this alarm.
I know the forum can be time-consuming for you sometimes but it’s also a source of inspiration

• hey, a good idea!
• hey, someone didn’t understand, maybe they’re not the only one or it’s unclear

@pierre-gilles

(but I try to remain courteous ).

My almost sixty you know it (but I wonder about the « courteous », is it about the term « irritate » or about me? No, I’m joking but it shows that between what we express and what is interpreted there’s plenty to debate and to digress about! )

[pierre-gilles]

I am closing this request in favor of:

MQTT - Recevoir une valeur sur un topic personnalisé

Bonjour à tous, Suite à mon précédent post (Ores - Compteur électrique intelligent - #10 par pierre-gilles), je me suis rendu compte qu’il était nécessaire de passer par Node-RED pour transformer une information reçue par un capteur MQTT vers Gladys. Pour faire simple, mon capteur envoie avec un topic (ex: « dsmr/reading/phase_currently_delivered_l3 ») et Gladys ne me permet que d’écouter sur un topic généré automatiquement et non modifiable (ex: « gladys/master/device/mqtt:consommation_instan…