eBus Schaltung in Betrieb nehmen

[Heatseeker]

Moin,

kann mir mal einer mit einer regex helfen? bin hier am verzweifeln. Problem ist scheinbar, dass u.A. meine z1DayTemp sowohl 20 als auch 20.5 zurückmeldet, also nicht 20.0

Ich habe etwas rumgesucht und auch mit Notepad++ getestet (da kann man nach Regex suchen :-)) und war dort mit

Code: [Auswählen]

?:\d\d(?:\.\d+)?|\.\d+erfolgreich (es soll ja auch nicht die "1" in z1DayTemp gefunden werden.

Ich habe nun stehen:

Code: [Auswählen]

get RaumSollTag cmd {"r -f z1DayTemp\n"}
get RaumSollTag expect "?:\d\d(?:\.\d+)?|\.\d+"
get RaumSollTag postproc { sprintf("%5.1f",$_) }

Die Anzeige in FHEM ist auch korrekt aber im Log wird sich beschwert:

Code: [Auswählen]

EBUS: unexpected answer 20\n\n (\062\060\012\012) received (wrote r -f z1DayTemp\n (\162\040\055\146\040\172\061\104\141\171\124\145\155\160\012), expected ?:\d\d(?:\.\d+)?|\.\d+)
Kann mir da wer helfen? Danke!!!

[Reinhart]

zeig doch bitte einmal was die Abfrage in der Konsole ergibt!

Code: [Auswählen]

ebusctl -r -f z1DayTemp
so zum Beispiel:

Code: [Auswählen]

pi@eBus:~ $ ebusctl r -f ActualRoomTempDesiredHc1
21.00

LG

[Heatseeker]

Moin,

Code: [Auswählen]

root@FHEM:~# ebusctl r -f z1DayTemp
21

root@FHEM:~#

wie gesagt, leider ohne "."

[Reinhart]

ah ja, das ist eh korrekt. Wenn da nur Zahlen kommen dann laß doch einfach deine regex weg und das Log muss wieder ok sein.

Code: [Auswählen]

get RaumSollTag expect "?:\d\d(?:\.\d+)?|\.\d+"das kannst du streichen und sowas wäre nur dann notwendig wenn hier außer Zahlen noch andere Zeichen im Rückgabewert vorhanden sind. Ein Filter auf Zahlen die eh nur Zahlen sind ist sinnlos. Du formatierst ja noch zusätzlich mit sprintf auf eine Nachkommastelle, somit ist der Output ja ok wenn du schon den Dezimalpunkt haben willst.

[Heatseeker]

Mmmh stimmt!

Das könnte klappen, ich werde das am Wochenende mal probieren.

Danke!

[tlc]

Hi everyone,

I have installed the ebus adapters v3 at the location.
My setup is:
- 2 x Vaillant heaters EcoTec
- 1 x VR32 (the 2nd heater is behind this ebus coupler)
- 1 x VR630/3 controller
- 2 x ebus adapter 3 (ethernet and wifi, both connected to the same ebus line).

On software side, I use the following:
- Openhab 2.5.12 as smarthome platform, with the ebus binding installed
- Mosquitto as MQTT broker.
(I apologize for being partially off-topic, I know this forum is dedicated to FHEM, but ebusd is the same everywhere )

I succesfully created 2 instances of ebus service (this is not important at this time, as I only intend to use one singe ebus adapter). Both instances are connected to the MQTT broker.

Here are some difficulties that I encountered so far, after 2 days spent on configuring and troubleshooting:
- I am unable to retrieve all the information from the VR630; for example, I cannot retrieve HeatingCurve nor FlowTempDesired
- I am unable to get/send messages from/to the 2nd burner which is behind a VR32 coupler. However I have some very useful information from john30 on how to communicate with devices behind a VR32 coupler (https://github.com/john30/ebusd/issues/109#issuecomment-782604650) - I am planning to deal with this later.

At this time I am trying hard to fix the 1st issue, that is to be able to read and change parameters from the 1st heater (directly connected to ebus).
/etc/default/ebusd:

Code: [Auswählen]

EBUSD_OPTS1="--scanconfig --configpath=http://ebusd.eu/config/ --device=enh:10.1.0.112:9999  --port=8888 -l /var/log/ebusd1.log --pidfile=/var/run/ebusd1.pid --mqttretain --mqttjson --mqtttopic=ebusd1 --mqtthost=10.10.0.3 --mqttport=1883 --mqttuser=admin --mqttpass=xxxxxx --mqttclientid=ebus_1_eth --latency=10"
Here are some messages from /var/log/ebusd1.log (please note that currently only the VR630 is turned on, until I find a way to control the FlowTempDesired - otherwise the heaters would be burning gas in vain, as I am not at the location):

Code: [Auswählen]

2021-03-09 17:56:57.121 [update notice] received unknown MS cmd: 1023b505082b0f010a00000080 / 00
2021-03-09 17:56:57.221 [update notice] sent poll-read ui YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2021-03-09 17:56:57.452 [update notice] sent poll-read ui YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2021-03-09 17:56:57.660 [update notice] received read hc SumFlowSensor QQ=10: 17.06;ok
2021-03-09 17:56:57.782 [update notice] received poll-read ui YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2021-03-09 17:56:57.887 [update notice] sent poll-read ui YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2021-03-09 17:56:58.066 [update notice] sent poll-read ui YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2021-03-09 17:56:58.275 [update notice] received read hwc Status QQ=10: 0;off;40.12;0
2021-03-09 17:56:58.394 [update notice] received poll-read ui YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2021-03-09 17:56:58.499 [update notice] sent poll-read ui YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2021-03-09 17:56:58.670 [update notice] sent poll-read ui YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2021-03-09 17:56:58.856 [bus error] unable to open /dev/ttyUSB0: ERR: element not found
2021-03-09 17:56:58.856 [bus notice] device invalid
2021-03-09 17:56:59.364 [bus error] poll ui YieldThisYear failed: ERR: wrong symbol received
2021-03-09 17:57:00.060 [update notice] received unknown MS cmd: 1026b5050427001100 / 00
2021-03-09 17:57:00.244 [update notice] received read hc DateTime QQ=10: nosignal;02:26:38;03.01.2007;-4.250
2021-03-09 17:57:00.421 [update notice] received unknown MS cmd: 1026b5040101 / 09150500000085000000
2021-03-09 17:57:00.591 [update notice] received unknown MS cmd: 1026b505082b0f010a00000080 / 00
2021-03-09 17:57:03.063 [bus error] poll ui YieldThisYear failed: ERR: wrong symbol received
2021-03-09 17:57:03.067 [bus error] device status: eBUS comm error: framing
2021-03-09 17:57:03.856 [bus error] unable to open /dev/ttyUSB0: ERR: element not found
2021-03-09 17:57:03.856 [bus notice] device invalid
2021-03-09 17:57:07.185 [update notice] received read hc SumFlowSensor QQ=10: 17.06;ok
2021-03-09 17:57:07.363 [update notice] received read mc Mode QQ=10: 20;auto;0;0;low;inactive;night
2021-03-09 17:57:07.521 [update notice] received unknown MS cmd: 1026b504010d / 053300110115
2021-03-09 17:57:07.686 [update notice] received read hwc Status QQ=10: 0;off;39.50;0
2021-03-09 17:57:08.843 [update notice] received unknown MS cmd: 1050b5050427001100 / 00
I have extracted all "sent/received unknown MS/MM cmd" unique messages without the timestamp, in the last 48 hours (grep unknown /var/log/ebusd1.log|cut -f3- -d" "|sort -u).
The list is quite big - you will find it attached as zip archive.
Both heaters were on for approx. 45 minutes in these 48 hours.

Here is also the output of the "ebusctl find -a -d" command:

openhabian@pi2:~/scripts/ebusd_tlc_diverse $ ebusctl find -a -d
bai SetMode = water;62.0;-;-;0;0;0;1;0;0
bai Status01 = 63.5;63.5;-;-;-;off
broadcast datetime = -4.562;02:43:03;03.01.2007
broadcast id = Vaillant;VR630;0500;6301
broadcast outsidetemp = -4.562
broadcast vdatetime = 02:43:03;03.01.2007
cc Mode = 30;off;disabled;circulation;00;night
hc currenterror = -;-;-;-;-
hc DateTime = nosignal;02:43:12;03.01.2007;-4.562
hc SumFlowSensor = 16.69;ok
hwc Mode = 38;off;disabled;inactive;00;night
hwc Status = 0;off;40.12;0
mc Mode = 20;auto;0;0;low;inactive;night
mc.3 Mode = 20;auto;0;0;low;inactive;night
scan.08  = Vaillant;BAI00;0609;5502
scan.08 id = 21;16;31;0010011740;0001;005691;N2
scan.15  = Vaillant;UI   ;0509;6201
scan.15 id = 21;15;27;0020080468;0907;006125;N9
scan.18  = Vaillant;V32;0117;9802
scan.23  = Vaillant;VR630;0500;6301
scan.23 id = 21;15;27;0020092440;0907;005308;N2
scan.25  = Vaillant;VR630;0500;6301
scan.25 id = 21;15;27;0020092440;0907;005308;N2
scan.26  = Vaillant;VR630;0500;6301
scan.26 id = 21;15;27;0020092440;0907;005308;N2
scan.44  = Vaillant;VR630;0500;6301
scan.44 id = 21;15;27;0020092440;0907;005308;N2
scan.50  = Vaillant;VR630;0500;6301
scan.50 id = 21;15;27;0020092440;0907;005308;N2
scan.51  = Vaillant;VR630;0500;6301
scan.51 id = 21;15;27;0020092440;0907;005308;N2
scan.84  = Vaillant;VR630;0500;6301
scan.84 id = 21;15;27;0020092440;0907;005308;N2
ui YieldThisYear = 0;0;0;0;0;0;0;0;0;0;0;0

The 40.12 value that you see above in red is the temperature from the temp. sensor mounted on the 800L domestic hot water tank, which is heated by solar panels. The solar system is completely separated from the Vaillant/ebus eco system (actually the 1st spiral of the water tank is connected to solar panel system and the 2nd spiral is connected to the HWC of the Vaillant ecosystem).

ebusctl info:

Code: [Auswählen]

openhabian@pi2:~/scripts/ebusd_tlc_diverse $ ebusctl i
version: ebusd 21.2.v21.2-9-gb98558b
update check: revision v21.2 available
signal: acquired
symbol rate: 23
max symbol rate: 217
min arbitration micros: 1
max arbitration micros: 279
min symbol latency: 0
max symbol latency: 18
reconnects: 0
masters: 6
messages: 742
conditional: 15
poll: 1
update: 12
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0609;HW=5502", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 13: master #12
address 15: slave #2, scanned "MF=Vaillant;ID=UI   ;SW=0509;HW=6201", loaded "vaillant/15.ui.csv"
address 18: slave #12, scanned "MF=Vaillant;ID=V32;SW=0117;HW=9802"
address 23: slave, scanned "MF=Vaillant;ID=VR630;SW=0500;HW=6301", loaded "vaillant/23.vr630.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=VR630;SW=0500;HW=6301", loaded "vaillant/25.vr630.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=VR630;SW=0500;HW=6301", loaded "vaillant/26.vr630.hc.csv"
address 31: master #8, ebusd, conflict
address 36: slave #8, ebusd
address 3f: master #23
address 44: slave #23, scanned "MF=Vaillant;ID=VR630;SW=0500;HW=6301"
address 50: slave, scanned "MF=Vaillant;ID=VR630;SW=0500;HW=6301", loaded "vaillant/50.vr630.mc.csv"
address 51: slave, scanned "MF=Vaillant;ID=VR630;SW=0500;HW=6301", loaded "vaillant/51.vr630.mc.3.csv"
address 7f: master #24
address 84: slave #24, scanned "MF=Vaillant;ID=VR630;SW=0500;HW=6301"



According to the openhab ebus binding statistics, the Unresolved telegram ration is 81.8% - see attached print screen.

Can you please advise how to interpret the unresolved values?

Thanks a lot!
Cristian

[Reinhart]

Hello,

do you have a route to the broker from 10.1.0.x to 10.10.0.x  ?

Code: [Auswählen]

address 31: master #8, ebusd, conflictThe adapter has an conflict with the address "31", please set the second adapter to "01" or "ff", but no "31" (default) .

Code: [Auswählen]

--address=ff
and the latency is very small, set it to 20000!

LG

[tlc]

Yes, I have a route, I can see lots of MQTT messages on the MQTT broker, published by both ebusd instances.
In fact I have an OpenWRT  router with 2 separate VLANs which are communicating in both directions at this moment (my goal is actually to create an isolated VLAN for the smarthome devices, separated from the rest of the network, but so far it is work in progress).

I have updated the ebusd default configuration, thanks a lot for the hints

EBUSD_OPTS1="--scanconfig --configpath=http://ebusd.eu/config/ --device=enh:10.1.0.112:9999  --port=8888 -l /var/log/ebusd1.log --pidfile=/var/run/ebusd1.pid --mqttretain --mqttjson --mqtttopic=ebusd1 --mqtthost=10.10.0.3 --mqttport=1883 --mqttuser=admin --mqttpass=******--mqttclientid=ebus_1_eth  --latency=20000"
EBUSD_OPTS2="--scanconfig --configpath=http://ebusd.eu/config/ --device=enh:10.10.0.242:9999 --port=8889 -l /var/log/ebusd2.log --pidfile=/var/run/ebusd2.pid --mqttretain --mqttjson --mqtttopic=ebusd2 --mqtthost=10.10.0.3 --mqttport=1883 --mqttuser=admin --mqttpass=****** --mqttclientid=ebus_2_wifi --latency=20000 --address=FF"

I added --latency=20000 on both devices, considering that both are connected via a network interface (and not via USB).

Meanwhile I noticed that I can read the TempDesired if I specifically read the value:

openhabian@pi2:~ $ ebusctl r -v TempDesired
hc TempDesired temp1=21.0

Once I have ran this once, now the value is available with "ebusctl find" command :

openhabian@pi2:~ $ ebusctl find|grep -v "no data st"
broadcast datetime = -5.750;04:21:01;03.01.2007
broadcast outsidetemp = -5.750
broadcast vdatetime = 04:22:02;03.01.2007
hc currenterror = -;-;-;-;-
hc DateTime = nosignal;04:21:24;03.01.2007;-5.750
hc SumFlowSensor = 16.56;ok
hc TempDesired = 21.0
hwc Mode = 38;off;disabled;inactive;00;night
hwc Status = 0;off;38.50;0
mc Mode = 20;auto;0;0;low;inactive;night
mc.3 Mode = 20;auto;0;0;low;inactive;night
scan.15  = Vaillant;UI   ;0509;6201
scan.15 id = 21;15;27;0020080468;0907;006125;N9
scan.23  = Vaillant;VR630;0500;6301
scan.23 id = 21;15;27;0020092440;0907;005308;N2
scan.25  = Vaillant;VR630;0500;6301
scan.25 id = 21;15;27;0020092440;0907;005308;N2
scan.26  = Vaillant;VR630;0500;6301
scan.26 id = 21;15;27;0020092440;0907;005308;N2
scan.50  = Vaillant;VR630;0500;6301
scan.50 id = 21;15;27;0020092440;0907;005308;N2
scan.51  = Vaillant;VR630;0500;6301
scan.51 id = 21;15;27;0020092440;0907;005308;N2
ui YieldThisYear = 0;0;0;0;0;0;0;0;0;0;0;0

Please note that HeatingCurve is not listed.

I have executed the command "ebusctl r -v HeatingCurve":

openhabian@pi2:~ $ ebusctl r -v HeatingCurve
hc HeatingCurve curve=0.95

And from now on, HeatingCurve is available when running "ebusctl find" !!! :

openhabian@pi2:~ $ ebusctl find|grep -v "no data st"
broadcast datetime = -5.750;04:26:00;03.01.2007
broadcast outsidetemp = -5.750
broadcast vdatetime = 04:26:00;03.01.2007
hc currenterror = -;-;-;-;-
hc DateTime = nosignal;04:25:48;03.01.2007;-5.750
hc HeatingCurve = 0.95
hc SumFlowSensor = 16.56;ok
hc TempDesired = 21.0
hwc Mode = 38;off;disabled;inactive;00;night
hwc Status = 0;off;39.31;0
mc Mode = 20;auto;0;0;low;inactive;night
mc.3 Mode = 20;auto;0;0;low;inactive;night
scan.15  = Vaillant;UI   ;0509;6201
scan.15 id = 21;15;27;0020080468;0907;006125;N9
scan.23  = Vaillant;VR630;0500;6301
scan.23 id = 21;15;27;0020092440;0907;005308;N2
scan.25  = Vaillant;VR630;0500;6301
scan.25 id = 21;15;27;0020092440;0907;005308;N2
scan.26  = Vaillant;VR630;0500;6301
scan.26 id = 21;15;27;0020092440;0907;005308;N2
scan.50  = Vaillant;VR630;0500;6301
scan.50 id = 21;15;27;0020092440;0907;005308;N2
scan.51  = Vaillant;VR630;0500;6301
scan.51 id = 21;15;27;0020092440;0907;005308;N2
ui YieldThisYear = 0;0;0;0;0;0;0;0;0;0;0;0

Is this behaviour normal?
Is there any way to force all values to be read at once?

Thanks!
Cristian

[tlc]

Moreover, I have managed to change the HeatingCurve value with ebusctl:

openhabian@pi2:~ $ ebusctl write -c hc HeatingCurve 1
done

Again I had to run "ebusctl r -v HeatingCurve" :

openhabian@pi2:~ $ ebusctl r -v HeatingCurve
hc HeatingCurve curve=1.00

Otherwise the "ebusctl find" command would NOT list the HeatingCurve value.

Once I had specifically read the HeatingCurve value (with the above command), the "ebusctl find" is now showing again the HeatingCurve value:

openhabian@pi2:~ $ ebusctl find|grep -v "no data st"
broadcast datetime = -5.750;04:39:03;03.01.2007
broadcast outsidetemp = -5.750
broadcast vdatetime = 04:38:03;03.01.2007
hc currenterror = -;-;-;-;-
hc DateTime = nosignal;04:33:33;03.01.2007;-4.875
hc HeatingCurve = 1.00
hc SumFlowSensor = 16.44;ok
hc TempDesired = 21.0
hwc Mode = 38;off;disabled;inactive;00;night
hwc Status = 0;off;39.31;0
mc Mode = 20;auto;0;0;low;inactive;night
mc.3 Mode = 20;auto;0;0;low;inactive;night
scan.15  = Vaillant;UI   ;0509;6201
scan.15 id = 21;15;27;0020080468;0907;006125;N9
scan.23  = Vaillant;VR630;0500;6301
scan.23 id = 21;15;27;0020092440;0907;005308;N2
scan.25  = Vaillant;VR630;0500;6301
scan.25 id = 21;15;27;0020092440;0907;005308;N2
scan.26  = Vaillant;VR630;0500;6301
scan.26 id = 21;15;27;0020092440;0907;005308;N2
scan.50  = Vaillant;VR630;0500;6301
scan.50 id = 21;15;27;0020092440;0907;005308;N2
scan.51  = Vaillant;VR630;0500;6301
scan.51 id = 21;15;27;0020092440;0907;005308;N2

[Reinhart]

the HeartingCureve is not stored in "bai" Device, but in your "hc" Device!

i have seen in the old log you has an error by "USB0", is this error still there?

Code: [Auswählen]

2021-03-09 17:56:58.856 [bus error] unable to open /dev/ttyUSB0: ERR: element not found
LG

[tlc]

Yes, I know, in fact the only active device now is the VR630. Both heaters are turned off via Tasmota smart plugs. The VR630 device should be now showing "COMMS Error" on its display, but strangely I cannot detect any error with ebusd...

I think I found the solution (one hour earlier I was 150% sure it's not working), but in fact : if I add the -a switch to "ebusctl find" command, it seems to be showing all the fields (even after I change a value with the "write" command):

openhabian@pi2:~ $ ebusctl write -c hc HeatingCurve 1.2
done

openhabian@pi2:~ $ ebusctl find -d -a
broadcast datetime = -4.250;05:14:02;03.01.2007
broadcast outsidetemp = -4.250
broadcast vdatetime = 05:14:02;03.01.2007
hc currenterror = -;-;-;-;-
hc DateTime = nosignal;05:13:50;03.01.2007;-4.250
hc HeatingCurve = 1.20
hc SumFlowSensor = 16.19;ok
hc TempDesired = 4.0
hwc Mode = 38;off;disabled;inactive;00;night
hwc Status = 0;off;39.19;0
mc Mode = 20;auto;0;0;low;inactive;night
mc.3 Mode = 20;auto;0;0;low;inactive;night
scan.15  = Vaillant;UI   ;0509;6201
scan.15 id = 21;15;27;0020080468;0907;006125;N9
scan.23  = Vaillant;VR630;0500;6301
scan.23 id = 21;15;27;0020092440;0907;005308;N2
scan.25  = Vaillant;VR630;0500;6301
scan.25 id = 21;15;27;0020092440;0907;005308;N2
scan.26  = Vaillant;VR630;0500;6301
scan.26 id = 21;15;27;0020092440;0907;005308;N2
scan.50  = Vaillant;VR630;0500;6301
scan.50 id = 21;15;27;0020092440;0907;005308;N2
scan.51  = Vaillant;VR630;0500;6301
scan.51 id = 21;15;27;0020092440;0907;005308;N2
ui YieldThisYear = 0;0;0;0;0;0;0;0;0;0;0;0

I had set the TempDesired to 4 degrees, so now I can remotely turn on the heaters for experimental purposes.

Regarding the USB device, yes, the error is still present (but only on ebusd1; on ebusd2 instance I don't have such errors in the log):

2021-03-09 20:46:06.767 [bus error] unable to open /dev/ttyUSB0: ERR: element not found
2021-03-09 20:46:06.767 [bus notice] device invalid

I managed to get it to start correctly once, but I don't remember how. I think it could be related to the default naming convention for one ebusd instance only (ebusd.log, ebusd.pid etc).
I believe if I use "ebusd.log" instead of "ebusd1.log" for instance #1, it doesn't show the USB0 error.
What is weird is that the 2nd instance never gave such errors, even though all file names are suffixed with the "2" index (ebusd2.log, ebus2.pid)

Another thing that I noticed: if I do not specify the pid file in the EBUSD_OPTS1 variable in /etc/default/ebusd, the service will never start because the pid file is not found! (it is not enough to specify it in the /etc/systemd/system/ebusd.service configuration file).
I think this is a bug, but from my point of view I managed to find a workaround, i.e. to specify the pid file also in the EBUSD_OPTS1 variable.

Later edit: the problem might come from the fact that I am using /etc/systemd/system/ebusd.service for instance #1 (instead of ebusd1.service), while the rest of the files are suffixed with 1 (ebusd1.log, ebusd1.pid). Somehow it is defaulting the device to USB0 but at the same time it reads also the configuration options (pointing to the ethernet enhanced device).
The 2nd instance has all configuration and log files always suffixed with 2 (including the ebusd2.service file), hence there are no USB0 errors.

Thanks!

[DerFranke]

gelöscht

[pc1246]

Die Schaltung ist angekommen und läuft - Besten Dank John. 
2 Fragen wären da noch:
Ist das so richtig?

Moin
Bist du auch im richtigen Thread? Wenn es um die V3 geht, bitte auch da posten!
Gruss Christoph

[DerFranke]

Moin
Bist du auch im richtigen Thread? Wenn es um die V3 geht, bitte auch da posten!
Gruss Christoph

Nee, bin ich mir nicht sicher. Hat der V3 thread auch einen aussagekräftigen Titel, an dem ich das erkennen kann / hätte können?
Kann man den Beitrag verschieben?

Außerdem, Christoph, es sieht so aus, daß der Adapter ja läuft. Eine Frage nach den CSVen wäre schon hier passend.

[pc1246]

Moin
Na irgendwie hast Du es ja auch geschafft einen Adapter zu ergattern!?
Ich habe das jetzt mal fuer Dich gesucht! -> https://forum.fhem.de/index.php/topic,118143.msg1125668.html#msg1125668
Und nein, das ist hier falsch, da sich seit der Erstellung dieses Threads doch einiges geaendert hat!
Gruss und viel Spass
Christoph