How to publish a STATE on a MQTT2_DEVICE?

[jacko]

Apologies for asking such a simple question but I have been around the houses pulling my hair out for a couple of days now.

I have a simple FHEM installation running on a Raspberry Pi in my Greenhouse monitoring temperatures and controlling lights, watering etc. It works OK but is an island of automation that I would like to tie into my house system. I have been moving to a house wide implementation of MQTT and I thought it would be easy to send and receive FHEM information and commands using MQTT topics.

I have a central MQTT broker and have configured FHEM using MQTT2_CLIENT. I have set up multiple MQTT2_DEVICE's and using the setList attribute I can publish the status of various things using dedicated mqtt topics. This all works well.

I would also like to publish the temperature data from the 3 1-wire sensors on a GPIO port (which all report and work well within FHEM). Specifically the topic payload would be the temperature reading. However, I can't find a MQTT2_DEVICE attribute that allows me to do this. This is such an obvious requirement to me but the solution is not clear!

What am I missing?

A pointer to the method would be greatly appreciated.

[rudolfkoenig]

What am I missing?

The module MQTT_GENERIC_BRIDGE.
If this is too much for you, you can setup some notifies/DOIFs which execute "set mqtt2_client publish topic $EVENT" (or the like).

[jacko]

Rudolfkoenig, Thank you for the quick reply. I struggle with the documentation so having the group provide help is very important to me.

I tried MQTT_GENERIC_BRIDGE but it doesn't seem to be installed and I don't know enough to attempt to fix. Is there a simple guide somewhere? Also, as an inexperienced programmer I do find the syntax of the FHEM commands very confusing.

However, using the second method I have achieved what I need. Specifically using the command:
   define n_RoofT_publish notify roof.temp:temperature.* set TyGBroker publish TyG/Greenhouse/Roof/Temp $EVTPART1

the temperature is now published and I can see in other "subscribed" devices.

Thanks again 

[rudolfkoenig]

I tried MQTT_GENERIC_BRIDGE but it doesn't seem to be installed

That would be strange, as it predates MQTT2_CLIENT and both come with the core FHEM distribution.
For the "simple" documentation I can only point you to the fhemwiki: https://wiki.fhem.de/wiki/MQTT_GENERIC_BRIDGE, the "real" documentation is the commandref.
Note: I am not really familiar with MQTT_GENERIC_BRIDGE.

[Beta-User]

Imo, for just publishing a small numer of Readings when beeing updated, the notify+direct publish solution is quite a good choice.

MQTT_GENERIC_BRIDGE (most recent "official" docu: https://fhem.de/commandref_modular.html#MQTT_GENERIC_BRIDGE) is more inteted to be a bidirectional MQTT option and/or for a larger amount of FHEM-devices to be bridged to the MQTT world.

MQTT_GENERIC_BRIDGE acts as an "enabler" device (for easy configuration of that part see "set ... attrTemplate base_settings_to_MQTT_GENERIC_BRIDGE"), most of the configuration work then is done on the existing FHEM-Devices themselfes (e.g. representing the GPIO-temp-Sensors).
Don't hesitate to ask if you need further explanation.

[jacko]

OK, I'm learning a lot here.

Because some of the devices I want to report their status (ie mqtt publish), AND for them to respond to a command (ie mqtt subscribe) it looks like I should be using MQTT_GENERIC_BRIDGE. For example the Lights; I want when they are turned on/off locally to be published, and to be able to turn them on/off remotely using a subscription.

However, If I issue the command:
   defmod mqttGeneric MQTT_GENERIC_BRIDGE
I get the response "Cannot load module MQTT_GENERIC_BRIDGE"
Am I running an old version old FHEM? I haven't updated for a while for fear of breaking something.
The command version reports "Latest Revision 21051". I don't know if this is out of date. I do see 10_MQTT_GENERIC_BRIDGE.pm in the list if files.

I am also wondering if there is a simple option along the lines of the notify command that I found to work using a TyGBroker client subscribe command instead of the publish command? (See earlier post)

Thanks for your guidance.

[Beta-User]

Might sound surprising, but imo rev. 21051 (wrt. to newer MQTT stuff) is quite out of date, as it still requires libpluggable-perl to be installed.

So updating (as always) is highly recommended.

Using a simple notify to react on incomming commands via MQTT is possible (or even just use MQTT2_DEVICE's option to include Perl in readingList), but it's relatively complicated to design this in a secure way. Imo, it's much easier using MQTT_GENERIC_BRIDGE.

[jacko]

I understand the need to update FHEM and it's on my to-do list. But I have some hacks in the GPIO code that I don't want to lose or break anything (to do with using the RaspPi AutomationHAT).

I can't understand why a simple readingList on my MQTT2_DEVICE won't work. Shouldn't a readingList:
   TyG/Greenhouse/Light:* { { state=>$EVTPART0 } }
not change the state of the device depending on the message payload, that I can then pick up with a notify statement to turn the lights on or off?

[Beta-User]

You may use readingList/Perl, no problem:

Code Auswählen Erweitern

   TyG/Greenhouse/Light:* { { fhem("set light $EVENT") } }

Wrt. to GPIO you could try to exclude the respective modules from update (exclude_from_update), I'd espect that to work, otherwise you may use a backup .

[jacko]

After staring at the code for a hour I tried a "." in the regexp, as in the example, and it worked!
   TyG/Greenhouse/Light:.* { { state=>$EVTPART0 } }
Not sure why, but I am happy now (until the next problem).

Oh, and I now use different topics for the subscribe and publish messages.

Cheers.

PS I've looked at the backup/restore functionality ahead of an update. Thanks for the tip about the exclude_from_update attribute. I've actually made some hardware changes around the 1-wire config that have made it more reliable and now understand better how it works so I might not need the customer GPIO module any more. One for another day...

[Beta-User]

You're welcome!

Fyi: There's "somewhere around here" also an enhanced version of the GPIO-1-wire Temp module; might be worth to check that out (the old one seem to have some disadvantages).