Rademacher DuoFern via Fhem and MQTT

Thank you very much! Using FHEM as a “backend” works very well!
It’s very cool to be able to control all the parameters of the Rollotron with this.
I also use FHEM and OpenHab on the same Raspberry. I did not use docker but simply installed FHEM via the deb-Package. This makes the need to reset the usb port and docker container obsolete.

Controlling the Rademacher stuff from OH via MQTT and then FHEM may work, but it is not a straight forward approach.
FHEM is also a free homeautomation platform. So when they can access the Rademacher USB stick, why is this not possible for a binding in OH? Somebody in the FHEM world must have decoded the propretary Rademacher protocol.

There is some code on GIT: https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/10_DUOFERNSTICK.pm
but I am not a programmer. Does this help?


Your are totally right.
That was my first approach, too.

But I am no developer, so I had to find a way that used existing tools. :smile:

A dedicated binding would be the best solution, of cause.

I’m using that approach for about one month now and I can’t complain. It works surpisingly reliable. As long as there is no native binding it’s the only working solution.

I would be happy, if we find someone who can create a binding. I can support with testing, but not with coding.


1 Like

thank you so much for this how to!
Since it is still the case that there is no direct support for the Rademacher DUOFERN stick, I implemented your solution successfully.
But I do have 2 points which I hope you are able to solve:

  1. In terms of a rollershutter control (i.e. in HABPanel) there is a STOP command necessary… How have you implemented this? UP and DOWN are easy, since just send 0 or 100, but STOP… I am struggling with.
  2. The MQTT Binding in OH2.4. I would send mine, but I only implemented the POSITION channel since I only need this (BTW: I do not understand why more is needed if you are able to set everything with individual rules in OH - or FHEM).

Thanks again

You are right.
I actually only use the position command, too.

All the other commands might be unnecessary, but I wanted to implement everything back then.

For the stop sommand you actually would need one of the other commands.
Look in the first post.
I implemented the stop command in the Rollo_WZ_mode item.
But you can configure this like a normal switch, of cause.

Like this (not tested):

Switch Rollo_WZ_stop   "Rollo WZ Stop"  <switch> { mqtt=">[mosquitto:set/fhem/Rollo_WZ/stop:command:*:MAP(onoffcases.map)],
     <[mosquitto:state/fhem/Rollo_WZstop:state:MAP(onoffcases.map)]" }

You second point I do not understand. Is there a question?

Hello @christoph_wempe

Thank you for this excellent tutorial. Do you know the actual status of the “DuoFern” binding ?

I just ask before I install a seperate FHEM :slight_smile:

Best greets

There will be no DuoFern binding as far as I know. :frowning:

apologies for the very late reply but I had no time to test and implement in the meantime.
Thank you for your hint. I get it done finally with help of your hint.

Sorry for my confusing wording. This wasn´t a question. Just forget it :wink:
Thanks again for your great work!

Hello, that sounds like a great way to control FHEM by OH. Unfortunately, I’m not quite here because I use Jarolift engines and there is also a module in FHEM. The bridge is on, it seems to have worked but it stops here. Maybe you could help me with an example of my situation as I put on a bridge for the first roller blind. @christoph_wempe

This is what i have for now.

This is what happens in the log, so i dont know how to name my mqtt device bridges.

2019.05.01 09:53:31 3: JarolifCUL: Jaro_FB set stop 1
2019.05.01 09:56:27 3: JarolifCUL: Jaro_FB set stop 5

So 1 and 5 are Wohnzimer links and Esszimmer. So the device name is 1, 2 ,3 ,4 ,5 and so on ?

I think we need more info to find your problem.

  1. Are you able to control your device via fhem? Yes, right?
  2. What does your openHAB config look like?
  3. Hat happens (in the logs of openHAB and fhem) when you play around with your device in fhem or openHAB?

Here is a screenshot of my setup.
Maybe this helps you.

(no fancy theme :wink:)

Over FHEM it works fine, i can control all blinds.

In FHEM i create the MQTT connection, it works fine, status is opened
Then i create a MQTT Bridge like this

define MQTT_Jarolift MQTT_BRIDGE Jaro_FB

Jaro_FB is the device how controlled my blinds. See the screen above

So i give you the things file the first blind is change to what im thinking is working. But there is nothing happen, in FHEM log i see no action when i try to control over OH.

In OH’s log there are only this to entry:

2019-05-04 10:09:42.238 [ome.event.ItemCommandEvent] - Item ‘WZ_Jalousie_links’ received command DOWN

2019-05-04 10:09:42.239 [nt.ItemStatePredictedEvent] - WZ_Jalousie_links predicted to become DOWN

It looks like you are using the new mqtt 2.x binding.
I am still using the old opne without things.
So it looks different than mine.
And I cannot see much similarities between my fhem config and your (regarding mqtt).

This does not mean yours is wrong, but it is harder for me to check. :slight_smile:

Lets splitt the issue into smaller parts.

The whole thing works like this:

Rademacher/Jarolift-Gateway <–> fhem <–> mqtt <–> openhab

  • :heavy_check_mark: Rademacher/Jarolift-Gateway <–> fhem
  • :question: fhem <–> mqtt
  • :question: mqtt <–> openhab

You say, the first part is working.

To check the second and third part I would recommend to check what messages you can see on the mqtt broker.
You can use the command line tool ’ mosquitto_sub’ or MQTT-Explorer for example.

Next step youl be to try to control the blings without openHAB just be sending messaged direktly to mqtt. (e.g. with moquitto_pub)
Then you know the second part is working.

But back to what you already posted.

Where did you get the topics you used in the things-file?

  1. regading line 94 of your fhem config:
    I think you need a suffix after subscribeSet like subscribeSet_button
    But it needs to be according to the available Readings. I don’t know how the readings of your device work. You do not seem to have Readings like up, down, etc.
  2. The commandTopic in your things file seems to be wrong. It should look like your subscribeSet config.

Here is my fhem config:

define mosquitto MQTT
define mqtt_Rollo_WZ MQTT_BRIDGE Rollo_WZ
attr mqtt_Rollo_WZ IODev mosquitto
attr mqtt_Rollo_WZ publish-topic-base state/fhem/Rollo_WZ/
attr mqtt_Rollo_WZ publishReading_dawnAutomatic state/fhem/Rollo_WZ/dawnAutomatic
attr mqtt_Rollo_WZ publishReading_duskAutomatic state/fhem/Rollo_WZ/duskAutomatic
attr mqtt_Rollo_WZ publishReading_manualMode state/fhem/Rollo_WZ/manualMode
attr mqtt_Rollo_WZ publishReading_moving state/fhem/Rollo_WZ/moving
attr mqtt_Rollo_WZ publishReading_position state/fhem/Rollo_WZ/position
attr mqtt_Rollo_WZ publishReading_state state/fhem/Rollo_WZ/state
attr mqtt_Rollo_WZ publishReading_sunAutomatic state/fhem/Rollo_WZ/sunAutomatic
attr mqtt_Rollo_WZ publishReading_sunMode state/fhem/Rollo_WZ/sunMode
attr mqtt_Rollo_WZ publishReading_sunPosition state/fhem/Rollo_WZ/sunPosition
attr mqtt_Rollo_WZ publishReading_timeAutomatic state/fhem/Rollo_WZ/timeAutomatic
attr mqtt_Rollo_WZ publishReading_ventilatingMode state/fhem/Rollo_WZ/ventilatingMode
attr mqtt_Rollo_WZ publishReading_ventilatingPosition state/fhem/Rollo_WZ/ventilatingPosition
attr mqtt_Rollo_WZ publishReading_version state/fhem/Rollo_WZ/version
attr mqtt_Rollo_WZ stateFormat transmission-state
attr mqtt_Rollo_WZ subscribeSet_dawn set/fhem/Rollo_WZ/dawn
attr mqtt_Rollo_WZ subscribeSet_dawnAutomatic set/fhem/Rollo_WZ/dawnAutomatic
attr mqtt_Rollo_WZ subscribeSet_down set/fhem/Rollo_WZ/down
attr mqtt_Rollo_WZ subscribeSet_dusk set/fhem/Rollo_WZ/dusk
attr mqtt_Rollo_WZ subscribeSet_duskAutomatic set/fhem/Rollo_WZ/duskAutomatic
attr mqtt_Rollo_WZ subscribeSet_getStatus set/fhem/Rollo_WZ/getStatus
attr mqtt_Rollo_WZ subscribeSet_manualMode set/fhem/Rollo_WZ/manualMode
attr mqtt_Rollo_WZ subscribeSet_position set/fhem/Rollo_WZ/position
attr mqtt_Rollo_WZ subscribeSet_remotePair set/fhem/Rollo_WZ/remotePair
attr mqtt_Rollo_WZ subscribeSet_remoteUnpair set/fhem/Rollo_WZ/remoteUnpair
attr mqtt_Rollo_WZ subscribeSet_reset set/fhem/Rollo_WZ/reset
attr mqtt_Rollo_WZ subscribeSet_stop set/fhem/Rollo_WZ/stop
attr mqtt_Rollo_WZ subscribeSet_sunAutomatic set/fhem/Rollo_WZ/sunAutomatic
attr mqtt_Rollo_WZ subscribeSet_sunMode set/fhem/Rollo_WZ/sunMode
attr mqtt_Rollo_WZ subscribeSet_sunPosition set/fhem/Rollo_WZ/sunPosition
attr mqtt_Rollo_WZ subscribeSet_timeAutomatic set/fhem/Rollo_WZ/timeAutomatic
attr mqtt_Rollo_WZ subscribeSet_toggle set/fhem/Rollo_WZ/toggle
attr mqtt_Rollo_WZ subscribeSet_up set/fhem/Rollo_WZ/up
attr mqtt_Rollo_WZ subscribeSet_ventilatingMode set/fhem/Rollo_WZ/ventilatingMode
attr mqtt_Rollo_WZ subscribeSet_ventilatingPosition set/fhem/Rollo_WZ/ventilatingPosition

btw: It would be much easier if you had posted your config as text so I could just have copied the important parts. :stuck_out_tongue_winking_eye:

Now it works, there are some little bugs in my attr. config But now i can control the Blinds with mqtt.fx
In OpenHab 2.4 in the mqtt binding there is actualy a bug with the rollershutters, so for now i cant control the blinds over mqtt.

He send wrong commands to the mqtt broker.

i send /JaroFB/Set down 1

in mqtt.fx i read JaroFB/set 100

In a actual nitghly this is fixed now, but it is not good to change to nightly from stable, so i have to wait.

But thank you very much to try to help me with my problem. BIG THX


Hi. Are the devices are working for you via the mqtt 2.x binding in openhab?

How did you config your shutters there, because I can’t find a config line or anything else there… Or do I have to add some channels to the device?

I am pretty new in openhab, but the actually status for me is…

FHEM control works fine for me.
MQTT control works fine for me.
Openhab I have to config the MQTT Thing, but I don’t know where! :smile:

I did not yet migrate to mqtt binding v2.

1 Like

Thank you for this tutorial! As a newbie to OpenHAB, it took me a while to figure out that it doesn’t work any more because it still uses mqtt 1.0 bindings.

I used this tutorial to migrate the MQTTv1 items to v2.

In order to make this tutorial work, make sure that the channel type you choose in the PaperUI, exactly matches the corresponding type in fhem.items. For example, the fhem.items example uses Number for the rollershutter position, so you must add a “Number Value” channel type (even if “Percentage Value” seem to make more sense). Otherwise the elements in the BasicUI just won’t do anything.

I was debugging my MQTT connection for a while, before I found out that I just used the wrong channel value type. It may just be common sense for people more experienced with OpenHAB, but maybe it helps other newbies. :wink:

I am still using MQTTv1 (openHAB v2.4.x), too.


Thank’s for the howto… worked great for me. Great idea to use fhem to bypass the Homepilot which not the friendliest regarding it’s API.

I use JeeDom (a french project) but there are mqtt plugins so it was nearly a piece of cake!

I have nearly ten rollotrons so it was really a pain in the ass not to be able to use them as I wanted!

It’s a great Christmass today!

Merry Xmas,

PS: i installed directly fhem and mosquitto on a raspberry pi 3b (+ ?) using 127:0.0.1:1883 as mosquitto host address in fhem. JeeDom is on another RPI using ZWave (Sigma USB), EnOcean (EnOcean Gmbh USB300), RFXTRX433 and ZigBee (Zigate USB DIN rail module). And of course a mosquitto plugin, JMQTT, that points to fhem-server.localdomain:1883