Entwicklung SIGNALDuino Empfänger Firm- und Hardware V4 für Maple Mini und ESP32

[rob]

Ja, das kompilieren via Arduino IDE wird unterstützt, ich kompiliere es damit auch.

Sehr gut. Dann kann ich VS-Code noch etwas meiden 

Die Sourcen habe ich komplett unangetastet gelassen. Sollte ich da etwas auskommentieren?
Ah, wahrscheinlich schon, woher soll es sonst wissen, dass ich den MAPLE_SDUINO mit LAN-Modul möchte. Sorry, das hab ich nicht umrissen 

Habe testweise diese zwei aktiviert:

Code Auswählen Erweitern


#define MAPLE_SDUINO 1
//#define MAPLE_CUL 1
//#define BLACK_BOARD 1  // 1 - USB, 2 - serial USART2 fuer ESP
//#define SIGNALESP32 1
//#define EVIL_CROW_RF 1
//#define ESP32_SDUINO_TEST 1
#define LAN_WIZ 1


Jetzt geht es weiter, doch leider schimpft er noch mit mir:

Code Auswählen Erweitern


tools.h:85:38: error: 'eeprom_buffered_write_byte' was not declared in this scope
   eeprom_buffered_write_byte(adr, val);

Habe ich noch etwas anderes nicht beachtet/ falsch?

VG
rob

[Ralf9]

Welchen core verwendest Du?
Ich habs gerade getestet.

Ich habe den aktuellen core 2.3.0 verwendet
Dazu habe ich unter zusätzliche Boardverwalter URLs:

Code Auswählen Erweitern

https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json
eingetragen.
In dem Bordverwalter ist es dann:
STM32 MCU based boards by STMicroelectronics

[rob]

Perfekt! Das war noch der entscheidende Hinweis.
Ich hatte irgendwas altes noch drin, wo ich den Maple auch ansteuern konnte. Jetzt habe ich das richtige Board und den aktuellsten Core - wie Du geschrieben hast. Einstellungen habe ich aus diesem Post https://forum.fhem.de/index.php/topic,106278.msg1027914.html#msg1027914 übernommen. Nun läuft es durch.

Vielen lieben Dank für Deine geduldige Unterstützung 

VG
rob

[Ralf9]

Mit "get sduino raw T" kannst Du Dir die core Version anzeigen lassen.

Ich hab die Beschreibung angepasst

Edit 09.09.22:
inzwischen gibts den core 2.3.0
dazu wird in der Arduino ide unter "zusätzliche Boardverwalter URLs" folgendes eingetragen:

Code Auswählen Erweitern

https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json

wichtig, da beim core 2.x.x bei Serial noch ein bug ist, ist bei der Serial und USB Version der core 1.9.0 erforderlich
Es gibt für den core 2.x.x zwar ein workaround, dazu muß aber im core in einer Datei was geändert werden.
Beim core 1.9.0 kommt unter "zusätzliche Boardverwalter URLs" folgendes rein:

Code Auswählen Erweitern

https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json

Danach im Boardverwalter nach STM32 filtern und den core installieren.

[rob]

OT: Ich arbeite mit Linux Mint und dort gibt es die aktuelle IDE nur als Flatpak (Sandbox). Weil das Flashen direkt aus der IDE heraus nicht klappt, soll man lt. Wiki den Befehl mit sudo auf der CLI ausführen. Nur leider legt die IDE das Kompilat unter "/tmp//arduino_build_blabla" ab - innerhalb der Sandbox. Da kommt man einfach nicht dran.
Also die Arduino IDE gemäß dieser Anleitung https://docs.arduino.cc/software/ide-v1/tutorials/Linux nochmals lokal installiert, Sourcen erneut kompiliert, jetzt auch für den Host zugreifbar und per sudo den Befehl ausgeführt. Klappt sofort.

Code Auswählen Erweitern

sudo ~/.arduino15/packages/STMicroelectronics/tools/STM32Tools/2.1.1/linux/maple_upload.sh ttyACM0 2 1EAF:0003 /tmp/arduino_build_788122/SIGNALduinoAdv.ino.bin


Bisher hatten mich die Flatpak-Dinger nicht gestört. Hier kommen aber zwei Dinge zusammen: Output-Pfad fürs Kompilat in der IDE nicht konfigurierbar und Sandbox gibt keinen Zugriff auf /tmp/...

Aber jetzt ist wieder alles gut Die externe LED blinkt im Versuchsaufbau fleißig und ich kann weiter machen.

VG
rob

[Ralf9]

Bei der IDE gibts auch bei Sketch den Menüpunkt "Kompilierte Binärdatei exportieren" dann ist die bin Datei im Sketchordner.

P.S.
Mich interessieren auch Rückmeldungen über WMBus, ab der Version 4.2.2 wird auch WMBus unterstützt.
Hat schon mal jemand getestet was mit den WMBus rfmodes alles empfangen wird?

[rob]

Och menno, da siehst mal wieder was ich mich auskenne 
Hab mehrmals auf den Menüpunkt gehackt - ich erwartete irgendeine Art Datei-Speichern-Popup-Menü. Weil es scheinbar nix tat, tat ich es abhaken. Du hast natürlich recht, ich finde dort die gewünschte Binärdatei.

Mit welchen Gerätschaften bzgl. WMBus sollte man sich denn angesprochen fühlen?

Vielen Dank und beste Grüße
rob

[Ralf9]

Mit welchen Gerätschaften bzgl. WMBus sollte man sich denn angesprochen fühlen?

Wasserzähler
Wärmezähler
PV Wechselrichter
u.a.

[meier81]

Hallo Ralf,

mal ne Frage. Ich habe bei mir den SIGNALDuino mit ranseyer´s Platine im Einsatz. Zur Zeit nur den 433MHz Empfänger aufgelötet, ich steuere damit lediglich meine Jarolift-Rollläden.
Ich hätte nun vor meine Wärmemengenzähler beim Austausch mit WMBUS auszustatten, was ja mittlerweile mit der Firmware geht. Ist es jetzt möglich das ich hier das 868MHz Modul einfach auflöte bzw. funktioniert WMBUS auf dem Modulplatz?

Falls ja was muss ich den speziell dafür konfigurieren, zur Zeit läuft bei mir die "Standard-Konfig"

Gruß Markus

[Ralf9]

Hallo Markus,

WMBus funktioniert auf den cc1101 Modulen A-C, aber nur auf einem Modul.
Es ist bei allen Modulplätzen egal ob Du ein 433 oder 868 MHz Modul auflötest.
Zum Aktivieren musst Du nur die entsprechende Registerkonfiguration (rfmode) übertragen.

Gruß Ralf

[rob]

Hallo Ralf.

Ich hab jetzt endlich meinen Mapleduino auf der Hutschiene in Betrieb und die Signalduinos (434+868) + Jeelink außer Betrieb nehmen können. Funktioniert soweit alles supi

Ein Haar in der Suppe habe ich noch und hoffentlich nix überlesen: auf 433MHz habe ich ein paar Taster (IT V3; Smartwares), ansonsten ist der Maple nur mit Sensorik beschäftigt. Ein Tastendruck wird tw. erst nach 10-20 sec. ausgeführt.
Habe ich eine Möglichkeit es wieder so flink zu bekommen wie mit einem dedizierten S'duino@434? Der ganze andere Sensorik-Krams ist ja nicht so zeitkritisch, Taster leider doch.

Vielen Dank und beste Grüße
rob

[Ralf9]

Ein Tastendruck wird tw. erst nach 10-20 sec. ausgeführt

Wird ein Tastendruck der IT Fernbedienung vom Signalduino erst verzögert erkannt
oder wird eine IT Steckdose nach einem Sendebefehl erst verzögert geschaltet?

[rob]

Wird ein Tastendruck der IT Fernbedienung vom Signalduino erst verzögert erkannt oder wird eine IT Steckdose nach einem Sendebefehl erst verzögert geschaltet?

Erstes. Beobachtet mit IT Taster und IT Fernbedienung.
Ich habe das mit einer Uhr nachgestellt: Uhr und FB nebeneinander. Erst alle 20 sec. off gedrückt und die nächste Minute alle 10 sec. - auf der FB wurde jeder kurze Tastendruck mit einer LED bestätigt.
Nebenher ließ ich den Event Monitor laufen, eingeschränkt auf die Taste der FB.

So schauts aus:

Code Auswählen Erweitern


gedrückt um         Monitor
08:30:00                2022-10-12 08:30:01 IT IT_00F0F0FFFF off
08:30:20                2022-10-12 08:30:25 IT IT_00F0F0FFFF off
                2022-10-12 08:30:25 IT IT_00F0F0FFFF long
08:30:40                2022-10-12 08:30:57 IT IT_00F0F0FFFF off
                2022-10-12 08:30:57 IT IT_00F0F0FFFF long
08:31:00                2022-10-12 08:31:03 IT IT_00F0F0FFFF off
08:31:10                2022-10-12 08:31:20 IT IT_00F0F0FFFF off
08:31:20                2022-10-12 08:31:29 IT IT_00F0F0FFFF off
                2022-10-12 08:31:29 IT IT_00F0F0FFFF long
08:31:30                2022-10-12 08:31:30 IT IT_00F0F0FFFF off
08:31:40                2022-10-12 08:31:50 IT IT_00F0F0FFFF off
08:31:50                2022-10-12 08:32:00 IT IT_00F0F0FFFF off
                2022-10-12 08:32:00 IT IT_00F0F0FFFF long
08:32:00                2022-10-12 08:32:01 IT IT_00F0F0FFFF off

Die Verzögerungen lassen sich ganz gut erkennen. Sie sind nicht gleich. So erlebe ich es auch beim Schalten mit dem Taster:
  Raum betreten, An-Taste drücken, dauert - Licht an.
  Aus-Taste drücken - Licht geht fast sofort aus.
  erneut, An-Taste - Licht sofort an.
  Aus-Taste drücken - dauert gefühlt 20 sec. - Licht aus.

(Die long-press Events sind so nicht richtig. Dürfte aber ein anderes Thema sein, das an der FB liegen dürfte.)

Meine Aktoren sind in keinem Fall IT-Geräte, sondern einmal SonOffs --> Wifi oder Zwave-Aktoren. Ich kenne den Verzögerungseffekt bei IT-Funk, wenn man Geräte mit selbem Medium indirekt steuert. Das dürften wir hier ausschließen können.

Antennen, Anschluss und Position sind beim Maple im Vergleich zu den S'duinos die selben. Wo vorher die 3 Geräte saßen, sitzt jetzt der Maple. Mit den dedizierten S'duinos hatte ich obiges Phänomen nicht. Die mussten sich ja auch nur um einen CC1101 kümmern 
Kurioserweise bekomme ich von meiner Wetterstation (WH1080@868) sehr viel öfter Daten, als mit dem S'duino zuvor, sodass ich am event-on-change-reading noch nachschärfen muss (mein SVG lädt etw. länger als vorher).

Der Maple schaltet doch zw. den Radios um, oder?  Wir oft/ schnell macht er das? Bin ich der einzige mit dieser Beobachtung?
Wenn ich die Taster auf 434 priorisieren könnte, wäre das ggf. hilfreich. Der Krams, der über die anderen Radios kommt, ist eher Temperaturgedöns und nicht zeitkritisch. Zur Not müsste ich die Taster abschaffen oder den S'duino@434 zusätzlich wieder einsetzen 

Viele Grüße
rob


Mein Maple ist via LAN angebunden. Hier ein List:

Code Auswählen Erweitern


Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt:FS10: :CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SD_GT:LaCrosse:KOPP_FC:PCA301:SD_Rojaflex:SD_Tool:SIGNALduino_un:
   DEF        192.168.0.108:23
   DMSG       W84#035A1077F6
   DevState   initialized
   DeviceName 192.168.0.108:23
   EQMSGCNT   0
   FD         132
   FUUID      633f4a25-f33f-a385-7eb4-35ed20872e6bcde5
   FVERSION   00_SIGNALduino.pm:v3.4.6-s347/2021-06-24
   IDsNoDispatch 2,43.1,72.1,82
   ITClock    250
   LASTDMSG   W84#035A1077F6
   LASTDMSGID 84
   LASTInputDev myMapleDuino
   MSGCNT     109849
   NAME       myMapleDuino
   NR         447
   NR_CMD_LAST_H 1
   PARTIAL   
   RAWMSG     MU;P0=-22184;P1=329;P2=-922;P3=626;P4=248;P5=-609;P7=-252;CP=4;R=249;D=0123232324545454545453737453745373745374545454537454545454537373745373737373737374537373;e;
   RSSI       -77.5
   STATE      opened
   TIME       1665557844.16277
   TYPE       SIGNALduino
   a_ccconf   b=0 rx=0 freq:868.400MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000]
   b_ccconf   b=1 rx=0 freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0100*]
   c_ccconf   b=2 rx=0 freq:868.350MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:17257.69Baud) [boffs=0140]
   c_ccconfFSK ccmode=4 sync=2DD4 Modulation:2-FSK (SYNC_MODE:16/16 + carrier-sense above threshold) DEVIATN:88.867kHz
   cc1101_frequency 433.920
   eventCount 6310
   myMapleDuino_DMSG P9#FF6A15100A2C44A0248B24
   myMapleDuino_DMSGequal 2
   myMapleDuino_MSGCNT 161
   myMapleDuino_Protocol_ID 9
   myMapleDuino_RAWMSG MU;P0=-32001;P1=497;P2=-978;P3=1462;CP=1;R=225;D=012121212121212123212123212321232323232123212321232323212323232323232323212321232323212321212323232123232321232321232123232323232323212323212323212323232123212123232123232123;e;
   myMapleDuino_RSSI -89.5
   myMapleDuino_TIME 2022-10-12 08:05:23
   sendworking 0
   unknownmessages
   version    V 4.2.2-dev220712 SIGNALduinoAdv LAN cc1101 (R: A0 B1* C2) - compiled at Sep  9 2022 17:18:59
   versionmodul v3.4.7-ralf_24.06.
   versionprotoL v3.4.7-ralf_24.06.
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2}
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|20|24|26|29|30|34|46|56|68|69|76|78|81|83|86|90|91|91.1|92|93|95|97|99|104|105|201)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79|96|98|112)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     29:SD_GT   ^P49#[A-Fa-f0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     30:LaCrosse ^(\S+\s+9 |OK\sWS\s)
     31:KOPP_FC ^kr..................
     32:PCA301  ^\S+\s+24
     33:SD_Rojaflex ^P109#[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     90:SD_Tool ^pt([0-9]+(\.[0-9])?)(#.*)?
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2022-10-09 02:11:46   state           opened
   XMIT_TIME:
     1665553979.37612
   getcmd:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     18
     43
     47
     52
     57
     58
     96
   mnIdList:
     100
     101
     102
     103
     107
     108
     109
     112
   msIdList:
     1
     3
     3.1
     4
     7
     13
     13.2
     14
     15
     17
     20
     23
     25
     32.1
     33
     33.1
     33.2
     41
     49
     51
     54.1
     55
     65
     68
     74.1
     90
     91.1
     93
     106
   muIdList:
     8
     9
     13.1
     17.1
     19
     21
     22
     24
     26
     27
     28
     29
     30
     31
     32
     34
     36
     37
     38
     39
     40
     44
     44.1
     45
     46
     48
     49.1
     49.2
     50
     54
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     73
     74
     79
     80
     81
     83
     84
     85
     86
     89
     91
     92
     94
     95
     97
     98
     99
     104
     105
     110
     111
     200
     201
   rfmodesets:
     rfmode     Avantek_433_FSK,DP100_WH51_17241,HoneywActivL_SlowRf_FSK,KOPP_FC_4785,Lacrosse_mode1_17241,Lacrosse_mode2_9579,PCA301_mode3_6631,Rojaflex_433_GFSK,SlowRF_ccFactoryReset,WS1600_TX22_mode5_8842,bresser_5in1_8220
   sendAslowrfID:
Attributes:
   blacklist_IDs 0,0.1,0.2,0.3,0.4,0.5,6,12,16,35,42,53,87,88,72,78
   verbose    0


Ping sagt:

Code Auswählen Erweitern


ping -c 10 -D -i 0.5 192.168.0.108
PING 192.168.0.108 (192.168.0.108) 56(84) bytes of data.
[1665558124.632706] 64 bytes from 192.168.0.108: icmp_seq=1 ttl=128 time=0.362 ms
[1665558125.151034] 64 bytes from 192.168.0.108: icmp_seq=2 ttl=128 time=0.236 ms
[1665558125.662985] 64 bytes from 192.168.0.108: icmp_seq=3 ttl=128 time=0.250 ms
[1665558126.174987] 64 bytes from 192.168.0.108: icmp_seq=4 ttl=128 time=0.246 ms
[1665558126.686970] 64 bytes from 192.168.0.108: icmp_seq=5 ttl=128 time=0.235 ms
[1665558127.199045] 64 bytes from 192.168.0.108: icmp_seq=6 ttl=128 time=0.263 ms
[1665558127.711061] 64 bytes from 192.168.0.108: icmp_seq=7 ttl=128 time=0.282 ms
[1665558128.222961] 64 bytes from 192.168.0.108: icmp_seq=8 ttl=128 time=0.213 ms
[1665558128.735062] 64 bytes from 192.168.0.108: icmp_seq=9 ttl=128 time=0.228 ms
[1665558129.247058] 64 bytes from 192.168.0.108: icmp_seq=10 ttl=128 time=0.231 ms

--- 192.168.0.108 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 4614ms
rtt min/avg/max/mdev = 0.213/0.254/0.362/0.043 ms

Sollte eigentlich OK sein.
Die Firmware ist selbst kompiliert. Geändert ist aber nur der LED-Pin für eine externe LED (geändert auf Pin #1).

[Ralf9]

Das mit den Verzögerungen bei IT Fernbedienungen habe ich so noch nie gesehen.
Dies "IT_00F0F0FFFF" sieht nach IT V1 aus, ich habs bei mir mit einer IT V1 Fernbedienung auch mal getestet, ich habe keine Verzögerung.
Wenn Du bei fhem ein "set myMapleDuino close"  machst, kann Du es Dir auch mit "telnet 192.168.0.108" anschauen.
Beim drücken der Taste müssten solche Nachrichten kommen:

Code Auswählen Erweitern

MS;P1=-1105;P2=1030;P3=-414;P4=306;P5=-11204;D=45412341414141414141414141414141414141412341234123;CP=4;SP=5;R=82;e;b48;m0;
MS;P1=-1105;P2=1030;P3=-414;P4=306;P5=-11204;D=45412341414141414141414141414141414141412341234123;CP=4;SP=5;R=82;Q;e;m1;
MS;P1=-1105;P2=1030;P3=-414;P4=306;P5=-11204;D=45412341414141414141414141414141414141412341234123;CP=4;SP=5;R=82;Q;e;m2;
MS;P1=-1105;P2=1030;P3=-414;P4=306;P5=-11204;D=45412341414141414141414141414141414141412341234123;CP=4;SP=5;R=82;Q;e;m3;

Ist Dein Netzteil ok?

Die radios sind alle immer aktiv. Bei ASK/OOK löst jede Signalflanke einen Interrupt aus und bei FSK gehts über den FIFO des cc1101

[rob]

Ich hätte eine Info erwartet á la "... muss so, weil er halt die Radios durchrotiert ..." o.ä. 
Nun nehme ich aber die wichtige Info mit: Darf so garnicht sein. Sehr gut. Also muss bei mir irgendwo das Problem sitzen.

Telnet habe ich gemacht. Die Nachrichten kommen quasi verzögerungsfrei.

Ist Dein Netzteil ok?

Eigentlich schon. Hängen zwar ein paar Dinge dran, ist mit 12V/ 7,5A aber auch recht üppig leistungsfähig.
Mmmh, aber Du bringst auf etwas: Ich habe einen Step-Down zur Versorgung das Maple im Einsatz. Mit ein paar von denen hatte ich schon Probleme. (bei meinen MySensors@RFM868 wollten die RFM69HW ums Verrecken nicht arbeiten. Eine Diode sekundärseitig tat es dann)
Bei meinem Maple gibt es offensichtl. auch ein Problem, wenngleich es sich anders äußert. Vielleicht sind die RFM69HW empfindlicher als die CC1101?

Also Testaufbau mit Spannungsversorgung via USB direkt am Maple:

Code Auswählen Erweitern


gedrückt um             Monitor
20:54:20                2022-10-12 20:54:19 IT IT_00F0F0FFFF on
20:54:30                2022-10-12 20:54:29 IT IT_00F0F0FFFF on
20:54:30                2022-10-12 20:54:29 IT IT_00F0F0FFFF long
20:54:40                2022-10-12 20:54:39 IT IT_00F0F0FFFF on
20:54:40                2022-10-12 20:54:39 IT IT_00F0F0FFFF long
20:55:00                2022-10-12 20:54:59 IT IT_00F0F0FFFF on
20:55:00                2022-10-12 20:54:59 IT IT_00F0F0FFFF long
20:55:10                2022-10-12 20:55:09 IT IT_00F0F0FFFF on
20:55:20                2022-10-12 20:55:19 IT IT_00F0F0FFFF on
20:55:20                2022-10-12 20:55:19 IT IT_00F0F0FFFF long
20:55:30                2022-10-12 20:55:29 IT IT_00F0F0FFFF on
20:55:30                2022-10-12 20:55:29 IT IT_00F0F0FFFF long

* diesmal on, sonst wurd's arg dunkel 

Fazit: Es scheint tatsächlich an der Spannungsversorgung zu liegen. Also statt der 12V-Speisung den Stepdown raus und 5V direkt gespeist. Bis jetzt reagieren die Taster wieder wie vorher/ gewünscht 

Werd' es noch beobachten, aber ich denke das könnte nun passen.

Vielen Dank für Deine Unterstützung.

Beste Grüße
rob