For the Rollotron Comfort Duofern you have the option for automatic down in the evening (dusk = Dämmerung/Sonnenuntergang) and automatic up in the morning (dawn = Sonnenaufgang). In this case you must enable the time automatic too and specify, if the time automatic shall react on a time or calculated dusk/dawn-times based on the configured date and zip code.
I use this feature and it works via FHEM (configure the values here) and openHAB (enable the auto modes) too.
After every reboot of my RasPi I had to replug the DuoFern adapter and restart the fhem container.
So I wrote a little script that rests the usb port after reboot and restarts the container for me.
I updated the first post with more information about this.
one more time “thank you @christoph_wempe” 
with your tutorial my cheap eq3 bluetooth thermostates works now in openhab…nice.
same procedure: fhem->mqtt->openhab.
Maybe this post is still alive…
Did all that and command line communication does work. but nothing from openhab. it says during boot that the broker is alive but no commands are received there or if sent, received at OH. Whats wrong? how can I debug?
Stefan
So MQTT <-> FHEM <-> DuoFern does work?!
But openHAB <-> MQTT does not work?
To debug I would start looking in openhab.log to see if there are any errors with the mqtt-binding.
Maybe set the logging for mqtt to DEBUG or TRACE to see more.
solved. “mosquitto” in the example is the brokers name. I chose originally a different one…
please better describe
You are right.
I added a short explanation.
1 Like
Christph,
did you install FHEM and Openhab on a single Raspberry?
Yes, I did.
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?
Holger
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. 
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.
Holger
1 Like
Christoph,
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:
- 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.
- 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
/Mav
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 
Best greets
Michael
There will be no DuoFern binding as far as I know. 
Christoph,
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 
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 ?