Hello everybody !
I apologise for such a silly question, but I after many trials I haven't find a solution to my problem
Any help would be kind !
Situation
Communication between FHEM and HA through MQTT for IR remoting devices by both of them
FHEM controls the IR device through python scripts requests linked to perl subs
HA controls the same IR device through integration
In FHEM, the physical device is represented by a simple dummy with setlist/WebCmd attributes for state reading
Goal acheived at present
FHEM informs HA of its IR actions by publishing mqtt topics sent to HA hence MQTT_GENERIC_BRIDGE and a MQTT2CLIENT
HA informs FHEM of its IR actions by publishing mqtt topics received by FHEM hence MQTT_GENERIC_BRIDGE, the MQTT2CLIENT and a MQTT2 device
The update of a reading on the MQTT2 device (attr readingList) triggers a notify which update the state reading of the dummy
This solution works well
My problem
I would like that the reception of the HA topic by MQTT2CLIENT leads to the update of the state reading of the dummy WITHOUT THE NEED OF AN INTERMEDIATE MQTT2 DEVICE AND NOTIFY.
Something like attr <SIMPLE_DUMMY> readingList topic_HA:.* state
Is this possible ?
Thanks for your attention
Olivier
Since you already have a MQTT_GENERIC_BRIDGE, just use
attr <MY_DUMMY> mqttSubscribe state:stopic={"topic_HA/whatever"}
thank you very much for your quick answer
I am go to explore the mqttSubscribe then !
I will let you know
Good night
Just a remark:
afai understood, you have to use a rather complicated mix of dummy and notify devices and MQTT_GENERIC_BRIDGE attributes to get that working. Perhaps it is possible to simplify that using just a single MQTT2_DEVICE?
You may hand over all inputs (from HA side via readingList, from FHEM side via setList) to Perl script (in fact, you seem to already do this via notify?), and just have to make sure, you get the appropriate responses by your scripts (hashes for readingList (Readingname=>value)), publishes (topic+payload) from setList, and finally the right values to your readings when using setList...
Most likely, this is a little hard to understand, but at least the way "external MQTT-gadget" => FHEM-Perl-script is described here: https://forum.fhem.de/index.php?msg=1098434. For FHEM-setList=> Perl (with no publish at the end!), see second part of https://forum.fhem.de/index.php?msg=1111136.
Don't hesitate to ask in case you have any question on that.
Hello Beta-User!
Thank you very much for your answer
The solution you described was more or less the original idea I had
But when dealing with MQTT_GENERIC_BRIDGE, I believed it was easy to get "automatic publishing" of the state of my dummies by MQTT2Clients connected to HiveMQ or HA brokers without any intermediate MQTT2Device.
I think now that it was not a good idea.
I have problems to get "dummy" topics coming from MQTT_GENERIC_BRIDGE "automatically" published by MQTT2Clients connected to HiveMQ or HA brokers without the help of a notify or a perl script.
On the other hand, I saw that it is easy to retrieve "dummy" topics coming from MQTT_GENERIC_BRIDGE in readings of a MQTT2Device.
It also seems to me that I am not able to interface correctly MQTT_GENERIC_BRIDGE and MQTT2Clients (connected to HiveMQ or HA brokers), although I included their Ids in MQTT_GENERIC_BRIDGE DEF.
I will work on the solution you describe, which is in fact what I have began to do.
Thank you for your help and reference links, I think they will be usefull to me !
Have a good day !
Thanks for the feedback.
Some general remarks (although it's hard to understand your setup correctly, so don't mind if I didn't get everything right):
- Why do you use different MQTT servers at all? (I do so as well, but esp. Rhasspy is really special in it's usage of MQTT, so I didn't want MQTT2_SERVER to do that job for Rhasspy...) And if: Why do not bridge them wrt. to "commonly used devices"?
- MQTT_GENERIC_BRIDGE (MGB) is also a versatile tool for sending out the same info to different topics (or - with more than one of them - even to different servers), so in general, this might be a good tool in case you really need different MQTT servers. You may also "double" any MQTT2_DEVICE with settings from MGB to forward it's readings to different topics/MQTT servers.
- MGB and dummy as a combination is only forwarding updates from the MQTT side, when not configured as beeing "optimistic" (in HA teminology?). See mqttForward attribute (?). This may be the reason for some of your struggles with your current setup?
Thanks for your kind message and your interest in my project
1- about MQTT servers
I use
1- main FHEM MQTT2_SERVER,
2 - HiveMQ cloud server which is usefull for me (for example, for retreiving mqtt data from mqtt devices I don't want to connect to my private network, sharing mqtt data with other users without handling multiples connections to my private network, etc)
3- mosquito broker from HA without having implemented a mosquitto bridge (at the beginning I used FHEM MQTT2_SERVER as main HA broker)
I don't know Rhasspy but I will have a look at it
2- In fact, I don't really need to send out so many different topics to so many MQTT servers.
I wan't to keep FHEM as my core data processing system and use HA as a frontend to which I send as less as possible few clear and processed data for GUI purposes in addition to FHEM ftui. I prefer dealing with automations scripts in perl.
In most cases, the clear ad processed data I mentioned above is organised in my system through readings of dummy devices.
In case of a device which benefits of a good integration in HA, I prefer that my FHEM automation scripts send set commands and HA returns return state info rather than scripting for automation in python or in yaml for HA.
3- I tried to use mqttForward attribute but there is the drawback of possible infinite loops when dummy devices are supposed to send and publish the same topics !
I think that, as you suggested, in my case, a perl mqtt publishing script with a hash table with do the job correctly !
Have a nice day !
Zitat von: olivierbardot am 10 Februar 2024, 12:04:493- I tried to use mqttForward attribute but there is the drawback of possible infinite loops when dummy devices are supposed to send and publish the same topics !
Using the same topics for sending and receiving imo should absolutely be avoided - this is highly suspected to cause infinite loops, just as you have experienced. But still, if you use different topics, you may run into the same problem, in case you do not know what the other side of the MQTT end does - this is why mqttForward is disabled by default for dummy type devices. But in case the HA side doesn't react on the "forwarded" value, this should not cause any problems (with different topics).
Rhasspy is just an example of "abuse" of the MQTT transport layer, so I hope to not have confused you mentioning it.