[solved]Listening on MQTT topics to set values in actuator

[tomaszG]

Dear all,

I am looking to set some setpoint through MQTT on actuators.

I currently have multiple Enocean valves (EEP A5-20-04). I am currently forwarding all data from my valves to a central database through MQTT using an MQTT2_CLIENT and an MQTT_GENERIC_BRIDGE to send the readings. I control a Mosquitto broker on another machine that listens to the topics and forwards the data to the script that writes to the database.

I now am interested to use the same Mosquitto broker to send commands to the valves:
1) setting new temperature setpoint, in other words executing fhem commands such as

Code Auswählen Erweitern

set <dev> setpointTemp <value>
2) setting new attributes values, such as for example:

Code Auswählen Erweitern

attr <dev> blockKey <value>

I get the impression from various topics on the forum and reference that I should be able to do at least 1) by using MQTT2_DEVICE or MQTT_DEVICE objects, but could not piece the information together to understand how to do it. I am still looking for a solution for 2).
I'd really appreciate it if you could share the config I should use.

Best

[rudolfkoenig]

The "old" way is using the MQTT FHEM Module to connect to a broker, and either using MQTT_DEVICE or (MQTT_GENERIC_BRIDGE with other/dummy FHEM Devices).

In the current/more actively supported scenario you use MQTT2_CLIENT instead of MQTT to connect to the external MQTT server and MQTT2_DEVICE instead of MQTT_DEVICE to represent the physical device. MQTT_GENERIC_BRIDGE works with both interfaces.
In MQTT2_DEVICE you set the readingList attribute to convert topics to FHEM Readings/Events, and the setList attribute to publish FHEM-Commands as MQTT Topics with payload.

For MQTT2_DEVICE there are a lot of predefined attrTemplates, which can be set via dropdown, to set readingList/setList attributes for a given MQTT device (like Tasmota).

You can replace (mosquitto+MQTT2_CLIENT) with MQTT2_SERVER, in this case the MQTT2_DEVICE will be automatically created, together with its readingList.
setList has still to be set by attrTemplate or manually.

Edit:
Setting attributes via MQTT is done via publishing a topic with its payload, which results in a set command in FHEM.

[Beta-User]

@Rudi:

Seems tomaszG has already some knowledge in using the MQTT_GENERAL_BRIDGE .

Imo, it shouldn't be too hard to also use this module to issue set commands to his valves. hexenmeister has writen some instructions on how to use it, see thread here: https://forum.fhem.de/index.php/topic,91642.msg841368.html#msg841368 - unfortunately in german.
@tomaszG: you might especially havea look at the

Code Auswählen Erweitern

attr <device-name> mqttSubscribe <set-befehl>:stopic=<topic>
that should already be available at your valve devices. Perhaps you add a link to this thread here at the mentionned thread and ask for help in english; might be helpful for other users also.

[tomaszG]

Hi,

thanks for the reply. Just to clarify: I have a EnOcean device called myDevice. I saw it does not accept mqttSubscribe attributes. Does it mean I have to create an MQTT2_DEVICE. Basically I dd not understand where I should attach the mqttSubscribe attribute

Best

[Beta-User]

If MQTT_GENERIC_BRIDGE is loaded and configured correctly, there should some kind of ".*subscribe" attribute be available for "myDevice". The exact name depends on settings configured at your MQTT_GENERIC_BRIDGE device.

You may add some lists of at least the EnOcean "myDevice" and the Generic-Bridge-Device.

But I only have very limited experience with MQTT_GENERIC_BRIDGE, in case of further questions I highly recommend asking hexenmeister (or other users having more experience with it) for support.

As far as I understood, additional (MQTT2-) devices are not needed.

[tomaszG]

For full details, I am defining the MQTT_GENERIC_BRIDGE and MQTT2_CLIENT as follows

Code Auswählen Erweitern


define locmqtt MQTT2_CLIENT xxxx.xxx.ch:9883
setuuid locmqtt 5c7fba12-f33f-31d1-0d46-2eb4a2db7bd3bfb3
attr locmqtt SSL 1
attr locmqtt clientId rpn001
attr locmqtt subscriptions 1

define mqttGeneric MQTT_GENERIC_BRIDGE mqtt subType=hvac.04
setuuid mqttGeneric 5c54553c-f33f-d38f-19c2-06b4ddb36f166b9c
attr mqttGeneric IODev locmqtt
attr mqttGeneric globalDefaults base={"enocean/$device"}
attr mqttGeneric globalPublish *:topic={"$base/$reading"}


The attr locmqtt subscriptions 1 was just designed to avoid unnecessary subscriptions, does it need to change ?
On the other hand, I realized that the EnOcean devices have a userattr that contains mqttSubscribe, eg:

Code Auswählen Erweitern


define EnO_019AC3A8 EnOcean 019AC3A8
setuuid EnO_019AC3A8 5ca31d29-f33f-3d86-9e7a-021df6cc029d9742
attr EnO_019AC3A8 userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr EnO_019AC3A8 IODev TCM_ESP3_0
attr EnO_019AC3A8 comMode biDir
attr EnO_019AC3A8 destinationID unicast
attr EnO_019AC3A8 eep A5-20-04
attr EnO_019AC3A8 manufID 045
attr EnO_019AC3A8 room EnOcean
attr EnO_019AC3A8 subDef FF902D0C
attr EnO_019AC3A8 subType hvac.04
attr EnO_019AC3A8 teachMethod 4BS
attr EnO_019AC3A8 webCmd setpointTemp


I guess this hsould change but I cannot find out how since the syntax seems different from the ones from the link above. Any ideas ?

[Beta-User]

On the other hand, I realized that the EnOcean devices have a userattr that contains mqttSubscribe, eg:

I guess this hsould change but I cannot find out how since the syntax seems different from the ones from the link above. Any ideas ?

The mqttSubscribe userattr has been added by the MQTT_GENERIC_BRIDGE. So imo it should work just as described in "stopic" (or settopic?) in commandref to MQTT_GENERIC_BRIDGE and the examples in the already mentionned thread.

[hexenmeister]

Hello,

Unfortunately, I can not test right now (I moved to another apartment, all systems including the test system are not online). Therefore something 'blind flight'.

I would say the definition 'attr locmqtt subscriptions 1' is wrong. Here is a list of the subscribed topics. '1' is certainly not a desired topic list. Simply delete for testing or set to '#'.

I do not know if 'subType=hvac.04' works that way, it looks right, but simplifies it for testing, so remove it.

The command to send commands to a device is, as already written by Beta-User:

Code Auswählen Erweitern

attr <device-name> mqttSubscribe <set-command>:stopic=<topic>
So, for example:

Code Auswählen Erweitern

attr EnO_019AC3A8 mqttSubscribe setpointTemp:stopic=enocean/EnO_019AC3A8/setpointTemp

then send a desired value to Topic 'enocean/EnO_019AC3A8/setpointTemp' using MQTTSpy or other software.

hope that helps

[tomaszG]

In the end, it works, for example I am using

Code Auswählen Erweitern

attr <device_name> mqqtSubscribe setpointTemp:stopic=cmd/$device/setpointTemp displayOrientation:atopic=cmd/$device/display blockKey:atopic=cmd/$device/block

Thanks to all for your help

[Beta-User]

Thanks for your reply, glad you got it working as desired!

Please mark the thread as [solved] (just edit the title in your first post).

As atm we're about to develop some attrTemplate functionality to somehow standardize the process (and also the topics): feel free to contribute (also wrt. to documentation). It's still in an early stage, but most likely, we'll make some progress the comming weeks, as now the basics (at least to me) seem to be clear.

[tomaszG]

Hi,
Happy to contribute if I can. where should I go to do that ?
I have justnoticed an unexpected effect (maybe). Here is an example:
I have two valves EnOcean EnO_019A9CD7 & EnO_019AA2C6

And I define the attr

attr EnO_019A9CD7 mqttSubscribe setpointTemp:stopic=cmd/$device/setpointTemp displayOrientation:atopic=cmd/$device/display blockKey:atopic=cmd/$device/block

Then , if I send messages on
cmd/EnO_019A9CD7/setpointTemp then the setpointTemp of EnO_019A9CD7 gets adjusted which is normal
But if I send
cmd/EnO_019AA2C6/setpointTempt then the setpointTemp of EnO_019AA2C6 gets adjusted
even though I did not define an mqttSubscribe for both objects.

I am not sure if this is the intended behaviour. It suggests that the one mqttSubscribe actually works for both. In my case, it is actually useful so I don't need to define a mqttSubscribe for all devices: a single one would work apparently but it would make sense to define it not in an individual device but somewhere"higher-level"
Let me know what you think. I should mention I am not really up-to-date in FHEM version.

[Beta-User]

Imo messages sent to the wrong topic never should affect devices not subordinated to the MGB.

Is the second device also marked as subordinated, if you issue a get "get ... devinfo"?

And which versions/modules do you use? (also as IO: 00_MQTT or MQTT2_CLIENT?)

[tomaszG]

Latest Revision: 20457

File                      Rev   Last Change

fhem.pl                   20415 2019-10-27 17:23:55Z rudolfkoenig
96_allowed.pm             20069 2019-08-27 08:36:02Z rudolfkoenig
98_autocreate.pm          19372 2019-05-11 15:13:59Z rudolfkoenig
10_EnOcean.pm             20251 2019-09-26 12:04:39Z klaus.schauer
91_eventTypes.pm          14888 2017-08-13 12:07:12Z rudolfkoenig
98_fheminfo.pm            19895 2019-07-24 17:32:31Z betateilchen
01_FHEMWEB.pm             20400 2019-10-23 17:50:05Z rudolfkoenig
92_FileLog.pm             20435 2019-11-01 14:23:30Z rudolfkoenig
98_help.pm                19915 2019-07-29 20:01:16Z betateilchen
00_MQTT.pm                18719 2019-02-24 20:20:51Z hexenmeister
00_MQTT2_CLIENT.pm        20184 2019-09-17 16:25:01Z rudolfkoenig
10_MQTT_GENERIC_BRIDGE.pm 19737 2019-06-28 15:56:35Z hexenmeister
99_SUNRISE_EL.pm          18732 2019-02-25 13:15:34Z rudolfkoenig
00_TCM.pm                 19607 2019-06-13 08:06:53Z klaus.schauer
98_telnet.pm              17529 2018-10-14 12:57:06Z rudolfkoenig
99_Utils.pm               18920 2019-03-16 09:58:52Z rudolfkoenig
98_version.pm             15140 2017-09-26 09:20:09Z markusbloch

AttrTemplate.pm           20425 2019-10-30 08:33:31Z rudolfkoenig
Blocking.pm               17553 2018-10-17 15:56:35Z rudolfkoenig
DevIo.pm                  20174 2019-09-16 18:04:03Z rudolfkoenig
GPUtils.pm                19666 2019-06-20 11:17:29Z CoolTux
HttpUtils.pm              20375 2019-10-17 22:52:43Z rudolfkoenig
RTypes.pm                 10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm          19208 2019-04-17 19:27:09Z rudolfkoenig
TcpServerUtils.pm         19138 2019-04-07 10:17:21Z rudolfkoenig

f18.js                     20069 2019-08-27 08:36:02Z rudolfkoenig
fhemweb.js                 20226 2019-09-22 07:51:07Z rudolfkoenig

[tomaszG]

and the devInfo seems to return nothing for the device EnO_019AA2C6

[Beta-User]

Seems your installation is rather "outdated", especially wrt. to MQTT modules.

Any important reasons not to update?

And as you have both IO modules on your list (MQTT and MQTT2_CLIENT): I assume, MQTT2_CLIENT is used as IO for 10_MQTT_GENERIC_BRIDGE? Then updating both is strongly recommended.