I would be happy, if we find someone who can create a binding. I can support with testing, but not with coding.
Holger
I would be happy, if we find someone who can create a binding. I can support with testing, but not with coding.
Holger
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:
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 ?
I think we need more info to find your problem.
Here is a screenshot of my setup.
Maybe this helps you.
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.
Lets splitt the issue into smaller parts.
The whole thing works like this:
Rademacher/Jarolift-Gateway <–> fhem <–> 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?
subscribeSet
like subscribeSet_button
up
, down
, etc.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.
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!
I did not yet migrate to mqtt binding v2.
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.
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
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