Rademacher DuoFern via Fhem and MQTT

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

  • :check_mark: Rademacher/Jarolift-Gateway ↔ fhem
  • :red_question_mark: fhem ↔ mqtt
  • :red_question_mark: 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 192.168.1.140:1883
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

Greet’s

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.

Hi,

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,
Frédéric

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

Hi there,

is there a way to do it with an altertative to the DuoFern stick? This is an old hardware device which is not available on the market anymore. Buying a used one without any warrenty is a risk.

BR
Malte

I don’t know.

Buying a used one without any warrenty is a risk.

The whole process of using DuoFern via FHEM and connect it via mqtt to openHAB might be be bigger risk. (But it has worked perfectly for me in the past years).

I am not sure what the alternative is.

I guess you would have to buy a DuoFern Bridge or HomePilot and find a way to connect it to any open Smarthome system like FHEM, HomeAssistant and connect that to openHAB.

I asked about the new Matter standard two month ago.

Aktuell gibt es in unserem Hause keine konkreten PlĂ€ne fĂŒr eine Integration in Matter.

So there are “no concrete plant for to integrating Matter” at the moment.

Hi there,

yes, the process is risky considering the fact that there are also major software releases between the creation date of the tutorial and now.

Running this on hardware which is/will become out of support soon won’t make it better.

Anyway, an integration through matter would be the most decent solution - but I’m not confident about a manufacturer, that provides a proprietary solution only, would be under pressure to implement such interfaces. In other words - maybe they are very interested in selling their own solutions than providing interoperability. Hence an integration to OpenHAB is not that easy :wink:

Right now I found another thread here about the integration to the 3rd gen Home Pilot via http (and JSON).

So I’m considering going for that one since I’m just starting with the DuoFern tube motors.. And the Home Pilot 3 is about 60€ more than a used DuoFern stick. See if Black Friday will bring some special offers for the „Umweltsensor“ (why is that thing so expensive?!) Question is always if the effort is worth it. I just want to have more accurate sunset/sunrise control right now. Future planning would include smoke detectors and heating control.

BR
Malte

The Rademacher Bridge should also be a solution, see here.
It is currently available for about 72€ Idealo.
So far I haven’t tried it, but I think this will be the next project.

Holger

Hello

today I upgraded to “bookworm”. Since then, the procedure described here unfortunately no longer works. The “MQTT_BRIDGE” module is no longer present and a “MQTT_GENERIC_BRIDGE” must be used instead. I have not yet been able to find out how the thing can be implemented again.

However, my understanding of FHEM is also quite limited, as I only use it for the purpose described here.

Maybe someone here is facing a similar problem and can help me out?

Thank you and best regards!

Hi,

Last time I checked, going to FHEM website a go trough the change logs will lead you to the version where MQTT has been upgraded.

You download the version prior to that one, install it and feed it with your config script and it should work fine.

At least in my case it worked, but I’m not sur sure if I was under Bullseye or Bookworm.

For the moment, I am trying to see wether I will pursue with FHEM or pass through HomePilot 2 (because I have it already).

I’d rather prefer pass through FHEM it’s way better done than Rademacher clumsy programming.

If I find howto I’ll share it :slight_smile:

++

So
 I think I am almost there with mqtt2


Let’s assume ‘Shutter1’ to be a Rolltotron configured as before and functionning under FHEM.
Let’s also assume that my topics and names could be refined ^^

define mqtt_Bridge1 MQTT_GENERIC_BRIDGE mqtt_Bridge1

in your ‘Shutter1’ detail page you to the ‘attr’ line and scroll down until you see mqtt_Bridge1Publish there you can define the publish topics
 not sure everything is correct there but here we go :slight_smile:

dawnAutomatic:topic=mqtt_Bridge1/dawnAutomatic
duskAutomatic:topic=mqtt_Bridge1/duskAutomatic
sunAutomatic:topic=mqtt_Bridge1/sunAutomatic
sunMode:topic=mqtt_Bridge1/sunMode
manualMode:topic=mqtt_Bridge1/manualMode
ventilatingMode:topic=mqtt_Bridge1/ventilatingMode
position:topic=mqtt_Bridge1/position
sunPosition:topic=mqtt_Bridge1/sunPosition
ventilatingPosition:topic=mqtt_Bridge1/ventilatingPosition
moving:topic=mqtt_Bridge1/moving
state:topic=mqtt_Bridge1/state

then more or less the same for the subribings in mqtt_Bridge1Subscribe, you might not notice but there is small nuance ‘topic’ becomes ‘stopic’ and here we go again :slight_smile:

dawnAutomatic:stopic=mqtt_Bridge1/set/dawnAutomatic
duskAutomatic:stopic=mqtt_Bridge1/set/duskAutomatic
sunAutomatic:stopic=mqtt_Bridge1/set/sunAutomatic
sunMode:stopic=mqtt_Bridge1/set/sunMode
manualMode:stopic=mqtt_Bridge1/set/manualMode
ventilatingMode:stopic=mqtt_Bridge1/set/ventilatingMode
position:stopic=mqtt_Bridge1/set/postion
sunPosition:stopic=mqtt_Bridge1/set/sunPosition
ventilatingPosition:stopic=mqtt_Bridge1/set/ventilatingPosition
up:stopic=mqtt_Bridge1/set/up
down:stopic=mqtt_Bridge1/set/down
stop:stopic=mqtt_Bridge1/set/stop
toggle:stopic=mqtt_Bridge1/set/toggle
dawn:stopic=mqtt_Bridge1/set/dawn
dusk:stopic=mqtt_Bridge1/set/dusk
getStatus:stopic=mqtt_Bridge1/set/getStatus
remotePair:stopic=mqtt_Bridge1/set/remotePair
remoteUnpair:stopic=mqtt_Bridge1/set/remoteUnpair
reset:stopic=mqtt_Bridge1/set/reset

So now.. what about the readings published ? Don’t know yet
But the command part functions when using ‘stopic’ instead of ‘topic’

I use JeeDom and not OpenHab, but there should not be much difference, the only thing is I do not use docker but I installed both programs and changed the web port so that it did not interfere with JeeDom. So everything is in localhost.

Since I don’t speak German nor Perl and that Rademacher has little penetration in foreign markets
 it was working on my nerves so I spend several hours in ‘try-error’ mode

Hoping that this can help others to make the transition to mqtt2