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.
ZitatWhat 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).
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 :)
ZitatI 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.
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.
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.
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.
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?
You may use readingList/Perl, no problem:
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 ;) .
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...
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).