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.
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?
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.
The commandTopic in your things file seems to be wrong. It should look like your subscribeSet config.
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!
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.
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
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.
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.
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.
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.