Values from ioBroker to espeasy via mqtt

[MarcoS]

Hello everyone,

I have a question. I managed to send data to the ioBroker from an espeasy node using MQTT OpenHAB without any problems. The data are temperature, humidity or the status of GPIOs etc. I have also succeeded in set GPIOs on an espeasy node from the ioBroker in the direction to the espeasy node.
For this I use e.g. "Module1 / SET / GPIO / 4" as the MQTT message to set the GPIO 4 on the node named "Module1".
But now I would like to send a setpoint value to a dummy task on an espeasy node Modue1 with the taskname Setpoint and the variable name "Dummy" . I have already tried different versions of e.g. "Module1 / SET / Setpoint / Dummy" and so on. I get the current value of the dummy back to the ioBroker, but the new value is ignored. Various expressions with SET / TaskValueSet also did not lead to success.
I can manipulate the value via the browser with "192.168 .... / control? Cmd = TaskValueSet ....". But I am not addressing an IP via Mqtt, am I?
Can you tell me how the expression in the ioBroker would have to look like in order to manipulate the variable in a dummy device? Thanks.

[TD-er]

Yep, it does seem like the MQTT receive filtering via OpenHAB is a bit limited.
As far as I can see, it does seem like you can only receive commands that accept 2 parameters of which the last one is a numerical value.

You can however add a MQTT import task which can subscribe to a topic.
The received messages must be a numerical value for this plugin (there is a pending PR to allow for more, but that's not yet merged)
This can be used in the rules to act on the received value.

[MarcoS]

Hello TD-er,

thanks for your very fast respons . I will try it in the afternoon and will report, if it is working. See you.

[MarcoS]

Good Morning,
it was late, but I tested the MQTT import. Unfortunately without success. Creating the device was easy. But no matter which string I sent from the broker, the values of the four variables remained 0.00.
The following MQTT import settings were:
ESPeasy Module Name: Grillsensor
Task name: sniffer
Topic: cmdMQTT
Value1 name: Setpoint

I tried the following subscrib strings:
Grillsensor/SET/cmdMQTT
Grillsensor/SET/cmdMQTT/Setpoint
Grillsensor/SET/Setpoint
Grillsensor/cmdMQTT
Grillsensor/cmdMQTT/Setpoint
Grillsensor/setpoint
All without reaction of rules and/or variable value. In the rules, I waited for a change under both sniffer#cmdMQTT or sniffer#Setpoint and wanted to set the value of the dummy variable to 99. But it remained unchanged at the currently set value of 30.

The controller subscribe string is:% sysname% / SET / #
The controller publish string is:% sysname% / GET /% tskname% /% valname%
At the moment I don't see where my mistake could be. Thanks.

[TD-er]

What subscribe topics did you use on the MQTT import task?
Also you can't do compares like that in the rules.

The event is "Grill_Innenraum#Temperature_Grill=123"

So you can write blocks handling the event like this:

Code: Select all

on Grill_Innenraum#Temperature_Grill=123 do

on Grill_Innenraum#Temperature_Grill do

on Grill_Innenraum do

(3 examples of the on...do line)
In the rules block you must make the compare like this:

Code: Select all

on Grill_Innenraum#Temperature_Grill do
 if %eventvalue1%>[Sollwer#Dummy]
  GPIO,16,1
 else
  GPIO,16,0
 endif
endon

[MarcoS]

Hello TD-er

the Grill_Innenraum ... works. Here I compare the value of the temperature sensor with the specified target value in the variabledDummy from the dummy device "Sollwert" value. The problem is that I could not set the Sollwert#Dummy from the outside via the ioBroker. I was only able to do this via IP ... / controll? Cmd = TaskValueSet .....
Then I understood that I should use the MQTT import. At first I just wanted only to try to transfer the value to the varaible Setpoint inside the MQTT Import device. I tried to get triggered under "on sniffer # ... do" and before I process the value further, I first simply set the value Dummy to 99. Just so I can see if anything has arrived at all.
I hope I got that across in an understandable way.
For my problem with MQTT you can ignore the first two rules with trigger "Grill_Innenraum".

[TD-er]

In the MQTT import task, you must configure which topic to subscribe to for importing a specific value.
You can set upto 4 topics (per MQTT import task) which correlate to each output value of this MQTT import task.

Have you set a subscribe topic there?

[MarcoS]

Yes, I set the name of the MQTT Import to "sniffer", the first topic to "cmdMQTT" (like in the showed example in the documentation) and the value 1 name to "Setpoint". In the sampel you listen to cmdMQTT as a trigger event. Is this the topic or the value name (it is the same in the example)? If i understand it right, is has to be the topic.
In my case, I triggered in the rules with different combinations and also with "on sniffer#cmdMQTT do" and this must be correct combination. But I'm not sure, if the subscribed string form ioBroker "Grillsensor/SET/sniffer/cmdMQTT" or "Grillsensor/sniffer/cmdMQTT" is this, what the MQTT Import expected.

[TD-er]

The controller does only accept a very limited set of commands on the topic the controller subscribes to.

Maybe we should first make a step back to describe what each part does.

MQTT Controller:
- Stores credentials for connecting to the broker (also used later for MQTT import, more on that later)
- Does subscribe to a topic (or set of topics using wildcards like # ) to receive a (very) limited set of commands
- Does receive values from a connected task and publishes these to a set topic (or topic template using %tskname% etc.)

Task: (any task, not just the MQTT import)
- Gets sample values from somewhere, most often from a sensor
- Can send these samples to 0 ... 3 connected controllers

MQTT import (task) :
- Use credentials of first enabled MQTT controller and shares MQTT connection to the broker with this controller
- Allows to subscribe to other topics (upto 4 topics per MQTT import task)
- Does gather numerical values published to these topics it is subscribed to.
- Generates an event with the new value as soon as someone published to the topic it subscribed to.


So if for example you let your MQTT import task subscribe to this topic:

Code: Select all

this/is/my/topic

and someone else publishes the value "123" to this topic, then the task value of the MQTT import task will contain "123"
But remember it has to be a numerical value, thus 123.4 will also work, but "bla" will not.


So what you need to do, is add a topic to subscribe to in the MQTT import task and publish a message to that topic from anywhere (connected to the same broker)

[MarcoS]

ufff,

I will try to get this information into my brain
After this , I will try to get a working MQTT Import and will inform you about my results.
At the moment I did understand it in this way:
My ESPeasy modul has the name Grillsensor; my MQTT Import has the name sniffer and the first topic inside is called cmdMQTT. If the ioBroker send Grillsensor/sniffer/cmdMQTT 123 - the value in the first variable (called Setpoint) will be or should be 123.

We will see . See you.

[Ath]

The name of the ESPEasy module doesn't come in any of the equations of the MQTT Import plugin, 'just' the topic that is configured there is taken into account.
Do not subscribe to anything with a wildcard (#) there, that won't work.

[MarcoS]

Good Morning,

first of all, I got it right. But I still don't quite understand why it only works this way. By chance I noticed that when the topic was created in the MQTT import, an element with the same name was created in the ioBroker. When I assigned the value to this, it was correctly transferred to the topic and thus to the linked variable.
But I thought that under the setting "Controller subscrib" I would react with the string %sysname%/Set/# to everything that was sent with the name of the unit followed by /SET/ and the corresponding topic. Apparently it only works if only the topic is sent. What would happen if I ran different units with identical content and functions and only different names. If I want to setup the value in only one of the units, then everyone would react to the same topic or they would all have to get different MQTT import topics. But that wouldn't be a nice. With the GPIOs I also address the correct unit directly with %sysname%/SET/#.
It works for the first time, but I have the feeling that I haven't understood it yet.
It now also works in the rules.
On that note, have a nice weekend and thank you for the help. I'll keep trying, but it's family time.

Marco.

[MarcoS]

This is worth a coffee to me!

[Ath]

But I thought that under the setting "Controller subscrib" I would react with the string %sysname%/Set/# to everything that was sent with the name of the unit followed by /SET/ and the corresponding topic. Apparently it only works if only the topic is sent. What would happen if I ran different units with identical content and functions and only different names. If I want to setup the value in only one of the units, then everyone would react to the same topic or they would all have to get different MQTT import topics. But that wouldn't be a nice. With the GPIOs I also address the correct unit directly with %sysname%/SET/#.

Every MQTT Import plugin registers its own topics with the MQTT server. It does support variables like %sysname% (For a complete list see the Tools/Variables page), so you can still address a single unit/variable directly.

The subscription requested by the MQTT Controller for %sysname%/SET/# is to receive all topics in that group, to be processed by the controller, independent from the MQTT Import plugin. If that should receive one of the topics in the group, it would have to start a subscription for that too (no wildcards allowed there, though).

[MarcoS]

Now it becomes a little more understandable for me. I have now changed Topic1 of the MQTT import to "%sysname%/Grill_soll_temp". This gives me a clear assignment in relation to the unit name. It is now working as intended. Thanks for all the help.

Marco.

[Ath]

You're welcome.

You could have a look at PR #3424 to see what I've got cooking for extending the MQTT Import plugin