mosquitto als MQTT2 Server

[rudolfkoenig]

Ist dein FHEM aktuell?

In den 5 Minuten des Logs befindet sich 42-mal die Meldung "Closing second connection for...", fuer 14 unterschiedliche Geraete. Die Meldung kommt dann, wenn das Endgeraet eine zweite(!) Verbindung mit der gleichen ClientID und IP aufmacht, und danach die erste ohne "Auf wiedersehen" zu sagen schliesst. Ich vermute, dass irgendwas mit dem Netzwerk nicht in Ordnung ist.

Ich habe im Log 30 unterschiedliche IP-Adressen gezaehlt: bist Du sicher, dass du nicht das klassische "zu viele WLAN-Geraete fuer den WLAN-AP" Problem hast?

Ich sehe auch 4211 dispatch Zeilen, d.h. 14 MQTT-Nachrichten/sec. Wie ist die Auslastung (CPU) des FHEM Servers?

Beim DVES_F466C9 readingList scheint wirklich was kaputtgegangen zu sein, allerdings ist im anderen Log dieses Geraet auch merkwuerdig:
- irgendwann Verbindung zu wg. keepalive check
- CONNECT eine Minute spaeter, allerdings ohne SUBSCRIBE.
- danach EOF: Verbindung zu, ohne "Auf wiedersehen".

[riker1]

Ja, irgendwas verschluckt sich da, das erinnert mich an https://forum.fhem.de/index.php/topic,114911.msg1091325.html#msg1091325. Auch bei dem ist es so, dass das WLAN evtl. nicht optimal ist oder der ESP(32, in dem Fall) einen Hau hat.

Grundsätzlich weiß ich auch nicht, warum du unbedingt "complex" für autocreate am Server eingestellt hast (hatten wir das Themanicht schon mal? simple ist in der Regel ausreichend, den Rest kann man bei Bedarf nachsteuern); da Tasmota neuerdings (9.x?) ziemlich viele STATUSn-Pfade verwendet, wurde das halt zusätzlich angelegt, früher was dasselbe (oder etwas weniger) in INFO[1-3].

ah danke das hatte ich noch nicht gesehen.  Werde mal autocreate reduzieren auf simple.
Frage hier, wie die Abhängigkeit von device  autocreate  und in dem Attribute autocreate bei  MQTT2_DEVICES genau ist.
Device autocreate habe ich meist auf disabled 1 .
Denke das

Code Auswählen Erweitern

attr MQTT2_DEVICES  autocreate
ist unabhängig und nur für MQTT"_Devices gültig.

Danke VG T

[Beta-User]

Also, "autocreate":

Habe grade noch was in https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#autocreate_funktioniert_anscheinend_nicht.3F ergänzt; da steht es hoffentlich jetzt halbwegs verständlich, wie die einzelnen Ebenen zusammenspielen.

[riker1]

Ist dein FHEM aktuell?

In den 5 Minuten des Logs befindet sich 42-mal die Meldung "Closing second connection for...", fuer 14 unterschiedliche Geraete. Die Meldung kommt dann, wenn das Endgeraet eine zweite(!) Verbindung mit der gleichen ClientID und IP aufmacht, und danach die erste ohne "Auf wiedersehen" zu sagen schliesst. Ich vermute, dass irgendwas mit dem Netzwerk nicht in Ordnung ist.

Ich habe im Log 30 unterschiedliche IP-Adressen gezaehlt: bist Du sicher, dass du nicht das klassische "zu viele WLAN-Geraete fuer den WLAN-AP" Problem hast?

Ich sehe auch 4211 dispatch Zeilen, d.h. 14 MQTT-Nachrichten/sec. Wie ist die Auslastung (CPU) des FHEM Servers?

Beim DVES_F466C9 readingList scheint wirklich was kaputtgegangen zu sein, allerdings ist im anderen Log dieses Geraet auch merkwuerdig:
- irgendwann Verbindung zu wg. keepalive check
- CONNECT eine Minute spaeter, allerdings ohne SUBSCRIBE.
- danach EOF: Verbindung zu, ohne "Auf wiedersehen".

Hallo Rudi,
vielen Dank erstmal.

ich habe 6 Unifi APs , denke das sollte nicht das Problem des WLANs sein, würde ich aber dann gerne eingrenzen wollen. Hast du da einen Tipp?
Ja es sind viele Tasmotas im Einsatz.
Einige auch noch als ESP_Easy Devices, die aber über Mosquitto oder der ESPBridge.
Um Fhem zu entlasten wollte ich ja Mosquito auslagern.

Fhem ist aktuell, bis auf einige HM Module die zurückgehalten sind wegen TSCULF.

Bezüglich redundanten Clients forsche ich mal. Denke es entsteht durch nicht korrekte LW Status Werte.

die Auslastung muss ich mal genau schauen. Es läuft eigentlich nur FHEM und Unifi controller auf dem Linux Server. Alte HW.

Danke VG T

[Billy]

Auch ich habe u.a. viele esps 8266 mit Tasmota im Einsatz.
In Kombination Mosquitto (auf Synology) --> MQTT2_CLIENT --> MQTT2_DEVICE
und auch in Kombination Mosquitto --> MQTT2_CLIENT --> MQTT_GENERIC_BRIDGE

Die Umstellung auf MQTT2_CLIENT --> MQTT2_DEVICE hat bei mir problemlos funktioniert.
Anmerkung: ich verwende kein autocreate.

Letzte Woche hatte ich grössere Probleme mit meinem WLAN nachdem ich meinem UNIFI Controller ein Update verpasst hatte.
Dies hatte auch Auswirkung auf FHEM.

Beim Update wurde mir angeboten für 2,4GHz und 5GHz die gleiche SSID zu verwenden.
Seitdem ich diese Änderung rückgängig gemacht habe läuft wieder alle bestens.
Vielleicht hifts?

[riker1]

Auch ich habe u.a. viele esps 8266 mit Tasmota im Einsatz.
In Kombination Mosquitto (auf Synology) --> MQTT2_CLIENT --> MQTT2_DEVICE
und auch in Kombination Mosquitto --> MQTT2_CLIENT --> MQTT_GENERIC_BRIDGE...


Beim Update wurde mir angeboten für 2,4GHz und 5GHz die gleiche SSID zu verwenden.
Seitdem ich diese Änderung rückgängig gemacht habe läuft wieder alle bestens.
Vielleicht hifts?

Hatte auch schon diverse Probleme mit Unifi, wurden aber nie gelöst. Meist lag es wohl an den ESP8266, bei dem einen, der sich laufend auslogged hatte ich gestern die gleiche Firmware noch mal drauf gemacht, dann ging es wieder besser.

das mit den SSID 2.4 und 5 verstehe ich nicht ganz, die ESP8266 verbinden sich doch eh nur mit dem 2.4? hast du dann 2 SSIDs für 5 und 2.4 Ghz?

bezüglich:

--> MQTT2_CLIENT --> MQTT2_DEVICE
und auch in Kombination Mosquitto --> MQTT2_CLIENT --> MQTT_GENERIC_BRIDGE...

hier bin ich noch am Schauen. Denke werde auch wieder zu Mosquitto wechseln, dann dann ich das besser kontrollieren als in FHEM mit dem MQTT2_Server . Allerdings habe ich noch nicht den richtigen Migrationspfad heraus. Wie sind deine Erfahrungen mit der generic Bridge?

Merkwürdigerweise hat er bei mir gestern, nachdem ich das Device MQTT2_CLIENT mit Type MQTT2_CLIENT , dann noch MQTT2_Devices  mit Prefix MQTT2_MQTT2_CLIENT als MQTT2_DEVICE angelegt.

Aber da bin ich noch am Aufschlauen. Richtig einfach ist das nicht mir den Readings die teilweise entstehen.

Muss aber erstmal die Stabilität wieder hinbekommen.Momentan zu viele MQTT disconnects.

VG Thomas

[Beta-User]

das mit den SSID 2.4 und 5 verstehe ich nicht ganz, die ESP8266 verbinden sich doch eh nur mit dem 2.4? hast du dann 2 SSIDs für 5 und 2.4 Ghz?

...hier im Haus sind auch schon viele verwundert über die vielen WLAN-Netze, die man so haben kann...
Aber wenn man so einem ESP ziemlich genau sagen kann, auf welchen AP er sich aufschalten soll, hilft das ungemein (es sei denn, der AP ist zu weit weg, dann bekommt man uU. komische readingList-Einträge, s.o.).

dann dann ich das besser kontrollieren als in FHEM mit dem MQTT2_Server .

Besseren support als durch Rudi wirst du vermutlich kaum bekommen, mein Verdacht ist eher, dass mosquitto viele Probleme versteckt und du irgendwann aufwachen wirst mit einem genauso großen Stall voll Probleme, wenn sich mal jemand daran macht, mosquitto "exakter" zu machen und du danach ein update von dem Teil machst .
Jedenfalls ist mir völlig unklar, wie man einen mosquitto "kontrolliert".

Allerdings habe ich noch nicht den richtigen Migrationspfad heraus. Wie sind deine Erfahrungen mit der generic Bridge?

Nochmal: in deinem setup brauchst du keine MQTT_GENERIC_BRIDGE... Du kannst damit allerdings mit ihr und dem unbedachten Setzen von ein paar Attributen richtig "Spaß" erzeugen. Lass also bitte erst mal die Finger weg von diesem Modul, im mindesten Fall bis dir klar ist, wann man sie wofür braucht.

Merkwürdigerweise hat er bei mir gestern, nachdem ich das Device MQTT2_CLIENT mit Type MQTT2_CLIENT , dann noch MQTT2_Devices  mit Prefix MQTT2_MQTT2_CLIENT als MQTT2_DEVICE angelegt.

Das ist nicht merkwürdig, sondern die ganz normale Folge, wenn man MQTT2_CLIENT betreibt und autocreate aktiviert.
Auch wenn es ggf. sehr verwirrend ist: du musst dich im Wiki mit dem MQTT2_CLIENT-Artikel vertraut machen und dann auch passende ignoreRegexp setzen, sonst gibt das heilloses Chaos, wenn du autocreate weiter verwenden willst.

(Kopfschüttel)

[riker1]

Besseren support als durch Rudi wirst du vermutlich kaum bekommen, mein Verdacht ist eher, dass mosquitto viele Probleme versteckt und du irgendwann aufwachen wirst mit einem genauso großen Stall voll Probleme, wenn sich mal jemand daran macht, mosquitto "exakter" zu machen und du danach ein update von dem Teil machst .
Jedenfalls ist mir völlig unklar, wie man einen mosquitto "kontrolliert".

Hallo
ja der support ist absolut super, mit ist der MQTT2 Server nur etwas intransparent...liegt sicher an meinem mangelnden Wissen.
Mosquitto kann ich halt auf einen anderen Server verlagern und als eigenen unix process monitoren und einfacher eine Testinstanz betreiben.
Wie kann ich denn die Auslastung des MQTT2 Servers monitoren? Wahrscheinlich habe ich hier was verpasst?

vielen Dank dir auch für deine Darstellungen und die WIKI Einträge.

Zitat
Merkwürdigerweise hat er bei mir gestern, nachdem ich das Device MQTT2_CLIENT mit Type MQTT2_CLIENT , dann noch MQTT2_Devices  mit Prefix MQTT2_MQTT2_CLIENT als MQTT2_DEVICE angelegt.
Das ist nicht merkwürdig, sondern die ganz normale Folge, wenn man MQTT2_CLIENT betreibt und autocreate aktiviert.
Auch wenn es ggf. sehr verwirrend ist: du musst dich im Wiki mit dem MQTT2_CLIENT-Artikel vertraut machen und dann auch passende ignoreRegexp setzen, sonst gibt das heilloses Chaos, wenn du autocreate weiter verwenden willst.

Deswegen hatte ich ja eigentlich immer autocreate als Type disabled. nur wenn ich ein neues Device einhänge mal kurz an. Ich war nur überrascht das der MC Client auch als eigenes MC Device angelegt wurde. Bei den anderen Devices war es mir klar.
Hatte auch die entsprechenden Ignore Regex gesetzt.
...eventuell ging durch die Fehlersuche auch einiges Durcheinander.

Zitat von: riker1 am Heute um 17:19:17
das mit den SSID 2.4 und 5 verstehe ich nicht ganz, die ESP8266 verbinden sich doch eh nur mit dem 2.4? hast du dann 2 SSIDs für 5 und 2.4 Ghz?
...hier im Haus sind auch schon viele verwundert über die vielen WLAN-Netze, die man so haben kann...
Aber wenn man so einem ESP ziemlich genau sagen kann, auf welchen AP er sich aufschalten soll, hilft das ungemein (es sei denn, der AP ist zu weit weg, dann bekommt man uU. komische readingList-Einträge, s.o.).

Ich hatte hier extra bei Unifi eigene SSID für die ESPs eingerichtet, damit ich die gut kontrollieren kann. Leider ist die WLAN Stabilät der ESP manchmal auch schlecht. Hängt wohl auch oft mit mangelnder Stromversorgung zusammen. Hatte früher alles mit ESPEASY , die schienen mir aber instabiler als die Tasmotas in Bezug auf WLAN und Load.
Da bin ich weiter am experimentieren.


Vielen Dank nochmal an Dich und Rudi, und natürlich allen im Forum echt Klasse

[Beta-User]

Du kannst ohne weiteres eine Instanz mit FHEMWEB+MQTT2_SERVER bauen und "sonst nichts", dann kannst du nach Belieben testen oder schauen, wie viel Speicher+CPU das  in etwa benötigt.

Tendenziell ist es so, dass FHEM die Daten so oder so (unabhängig von MQTT/MQTT2_CLIENT oder MQTT2_SERVER) irgendwann entgegennehmen soll/muss, um sie zu verarbeiten. So wie ich das verstanden habe, beschränkt sich der eigentliche Overhead von MQTT2_SERVER auf die Verwaltung der offenen TCP/IP-Verbindungen (wenn man den Server nur für FHEM-Zwecke nutzt).
Einzig, dass das alles innerhalb des FHEM-Hauptprozesses abläuft, kann ein Problem darstellen, aber das tendenziell auch nur, wenn entweder sehr große Datenmengen umhergeschaufelt werden (sehr uncool via MQTT, das lightweight sein will!)  oder viele Events erzeugt werden, die dann zudem noch in FHEM ineffizient verarbeitet werden (fehlende NOTIFYDEV und so).

Von daher wäre es interessant, mal mit den top von außen zu sehen, wie der tatsächliche Unterschied ist, und zum anderen mit freezemon&Co zu checken, ob es Hänger gibt, die mit SERVER in Verbindung stehen könnten.

Ansonsten scheint es einfach so zu sein, dass die ESP-Dinger eben nicht nur billig, sondern auch schlecht designed sind, weswegen es jetzt geschlagene 5+ Jahre gedauert hat, bis die halbwegs stabil laufen (die beobachteten  Instabilitäten dürften nicht unbedingt nur von der jeweiligen Variante ESPEasy oder Tasmota (oder Shelly) abhängen, sondern eher von der Version das zugrundeliegenden Frameworks...).

[riker1]

Hallo Rudi,

bin weiter am Schauen und hatte nun noch folgende Fehlermeldungen:

Code Auswählen Erweitern

2020.12.11 07:07:56.045 1 : ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.6.101_62780
2020.12.11 07:07:56.492 1 : ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.6.101_62780
2020.12.11 07:07:56.662 1 : ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.6.101_62780
2020.12.11 07:07:57.929 1 : ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.1.177_64980
2020.12.11 07:07:58.036 1 : PERL WARNING: Use of uninitialized value $pid in pack at ./FHEM/00_MQTT2_SERVER.pm line 359.
2020.12.11 07:07:58.037 1 : stacktrace:
2020.12.11 07:07:58.037 1 :     main::__ANON__                      called by ./FHEM/00_MQTT2_SERVER.pm (359)
2020.12.11 07:07:58.037 1 :     main::MQTT2_SERVER_Read             called by ./FHEM/00_MQTT2_SERVER.pm (430)
2020.12.11 07:07:58.037 1 :     main::__ANON__                      called by ./FHEM/97_timerTS.pm (60)
2020.12.11 07:07:58.037 1 :     main::HandleTimeout                 called by fhem.pl (677)
2020.12.11 07:07:58.037 1 : ERROR: addToWritebuffer for MQTT2_TR_UB9_192.168.1.177_64980 without FD
2020.12.11 07:07:58.037 1 : callstack: addToWritebuffer:219 MQTT2_SERVER_out:359 MQTT2_SERVER_Read:430 __ANON__:60 HandleTimeout:677
2020.12.11 07:07:58.037 1 : FD closed in  TcpServer_Close:105 MQTT2_SERVER_Undef:3810 CallFn:2244 CommandDelete:426 MQTT2_SERVER_Read:430 __ANON__:60 HandleTimeout:677
2020.12.11 07:07:59.244 1 : ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.6.101_62780
2020.12.11 07:08:04.023 1 : ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.1.150_62377
2020.12.11 07:08:04.526 1 : ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.150_62377
2020.12.11 07:08:06.658 1 : ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.157_57206
2020.12.11 07:08:06.982 1 : ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.150_62377
2020.12.11 07:08:07.092 1 : ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.157_57206
2020.12.11 07:08:07.147 1 : ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.1.157_57206


Danke T

[rudolfkoenig]

- "Unhandled packet": der Server liest Muell. Entweder durch Netzwerkprobleme (unwahrscheinlich), oder durch Programmierfehler im MQTT2_SERVER Modul (wahrscheinlich).
- "uninitialized value": Seiteneffekt beim "Muell verstehen". 97_timerTS.pm sagt mir nichts, und es gefaellt mir nicht, dass es hier involviert ist, da ich nicht sicher sein kann, dass es nicht der Verursacher ist.
- "ERROR: addToWriteBuffer": da wird versucht noch was zu parsen, nachdem die Verbindung zugemacht ist. Es fehlt mir z.Zt. die Fantasie vorzustellen, wie das sein kann.

Ich vermute die Clients ueberlasten den Server, debuggen wird aufwendig (sowohl fuer dich, wie fuer mich).
Wenn Du trotzdem Lust dazu hast (oder netter vormuliert: dem Community helfen willst, ein Bug zu finden): bitte "attr MQTT2_SERVER verbose 5" setzen, und ein FHEM-Log Ausschnitt hier anhaengen: ich brauche ca 5 Minuten vor der ersten Meldung, und bitte nichts dazwischen loeschen, damit ich nicht auf die falsche Faehrte gefuehrt werde.

[riker1]

Hi Rudi,

Danke

klar mache ich den Mitschnitt.
Kannst du das Device einschränken welches den Müll sendet?

Dann könnte ich gezielter loggen?

VG T

[rudolfkoenig]

Alle "unhandled Packet" Meldungen deuten auf Muell hin, kannst eins aussuchen, IP/Name des Clients ist hinten in der Meldung enthalten.

[riker1]

Alle "unhandled Packet" Meldungen deuten auf Muell hin, kannst eins aussuchen, IP/Name des Clients ist hinten in der Meldung enthalten.

Hi Rudi, sorry, ich bin blind ......

[riker1]

- "Unhandled packet": der Server liest Muell. Entweder durch Netzwerkprobleme (unwahrscheinlich), oder durch Programmierfehler im MQTT2_SERVER Modul (wahrscheinlich).
- "uninitialized value": Seiteneffekt beim "Muell verstehen". 97_timerTS.pm sagt mir nichts, und es gefaellt mir nicht, dass es hier involviert ist, da ich nicht sicher sein kann, dass es nicht der Verursacher ist.
- "ERROR: addToWriteBuffer": da wird versucht noch was zu parsen, nachdem die Verbindung zugemacht ist. Es fehlt mir z.Zt. die Fantasie vorzustellen, wie das sein kann.

Ich vermute die Clients ueberlasten den Server, debuggen wird aufwendig (sowohl fuer dich, wie fuer mich).
Wenn Du trotzdem Lust dazu hast (oder netter vormuliert: dem Community helfen willst, ein Bug zu finden): bitte "attr MQTT2_SERVER verbose 5" setzen, und ein FHEM-Log Ausschnitt hier anhaengen: ich brauche ca 5 Minuten vor der ersten Meldung, und bitte nichts dazwischen loeschen, damit ich nicht auf die falsche Faehrte gefuehrt werde.

Hallo Rudi,

hier mal paar Fehler.
Log ist dann von 14:55 bis 15:05 im Anhang

Code Auswählen Erweitern

zwh100@ub9:/opt/fhem/log$ sudo grep --binary-files=text 'nhandled' 0-fhem-ub9-2020-12-11.log.error_unhandled
2020.12.11 14:58:46.454 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.201_57160
2020.12.11 14:58:48.986 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.201_57160
2020.12.11 15:00:17.879 1: ERROR: Unhandled packet PUBREL, disconneting MQTT2_TR_UB9_192.168.1.201_57160
2020.12.11 15:00:29.336 1: ERROR: Unhandled packet PUBREC, disconneting MQTT2_TR_UB9_192.168.6.105_53418
2020.12.11 15:00:29.992 1: ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.6.105_53418
2020.12.11 15:00:30.043 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.6.105_53418
2020.12.11 15:00:31.481 1: ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.6.105_53418
2020.12.11 15:00:35.662 1: ERROR: Unhandled packet PUBREL, disconneting MQTT2_TR_UB9_192.168.1.163_50786
2020.12.11 15:00:35.757 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.163_50786
2020.12.11 15:00:37.103 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.163_50786
2020.12.11 15:00:39.466 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.163_50786
2020.12.11 15:00:43.818 1: ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.1.167_53733
2020.12.11 15:00:44.933 1: ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.1.156_52165
2020.12.11 15:00:45.122 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.167_53733
2020.12.11 15:00:45.133 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.156_52165
2020.12.11 15:00:45.269 1: ERROR: Unhandled packet PUBREL, disconneting MQTT2_TR_UB9_192.168.1.156_52165
2020.12.11 15:01:34.389 1: ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.1.167_53733
2020.12.11 15:01:34.400 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.156_52165
2020.12.11 15:01:40.503 1: ERROR: Unhandled packet PUBREC, disconneting MQTT2_TR_UB9_192.168.1.130_54467
2020.12.11 15:01:40.669 1: ERROR: Unhandled packet PUBREC, disconneting MQTT2_TR_UB9_192.168.1.130_54467
2020.12.11 15:01:40.814 1: ERROR: Unhandled packet PUBREC, disconneting MQTT2_TR_UB9_192.168.1.130_54467


Wenn ich noch Daten liefern soll mache ich das gerne. Hoffe du kannst etwas finden.


VG T