Läuft: Heizung mit eBus-Schnittstelle

[rob uboot]

bei mir ändert er den HwcOPMode auch nur für sehr kurze zeit.
so dinge wie die heizungspumpe kann ich damit auch nicht steuern auch wenn ich das 'done' bekomme.
denke mal es wird wirklich am 470 liegen. vaillant bietet den auch nicht mehr an
und die einzige offizielle schnittstelle bietet diese option an jedoch muss der multimatic vorhanden sein.

vielleicht ist aber auch der befehl der falsche und die rechte wurden daher nur auf lesen gesetzt.
kenne mich leider null aus.
wäre aber über eine hilfe sehr dankbar weil genau das die befehle sind die meiner meinung nach sinnvoll sind für eine smart home anbindung. 

[aia]

Hi,

ich muss leider auf einen etwas älteren Post zurückgreifen, aber ich komme auch eigentlich aus der openhab ecke
und bin nun nur zufällig hier im thread über anghängtes posting von galileo gestolpert.

grundsätzlich tut bei mir ein esera ebus ethernet adapter seinen dienst, mit sehr schlechten ergebnissen (70-90% failed).
jemand aus dem openhab forum hat dann jetzt auf den ebus 2.0 adapter gewechselt und ist begeistert - dieser spur bin ich gefolgt und hier gelandet.

neben dem interesse an dem neuen adapter, hab ich beim einlesen diesen genialen umbau von galileo entdeckt.

meine frage: hat sich der umbau bewährt und funktioniert der adpater noch?
hat ev. jemand auch die ethernet variante des adapters umgebaut?

thx!

https://forum.fhem.de/index.php/topic,29737.msg511678.html#msg511678

Nie wieder Poti einstellen !
Nachdem ich tagelang einen Fehler gesucht habe und sich danach herausgestellt hat, dass bloß das Potentiometer nicht richtig eingestellt war (obwohl ich mich an die Einstellanleitung im WIKI genau gehalten habe) habe ich mich ein wenig mit der gegenwärtigen Schaltung auseinandergesetzt. Primär war da die Frage, wieso Vaillant, der ja mit seiner Hardware auch am Bus spricht, nicht alle 2 Wochen ausrücken muss um beim Kunden ein Potentiometer nachzujustieren. Die Antwort lag auf der Hand: es gibt bei den Vaillant-Schaltungen kein Potentiometer.

Ich möchte gleich vorausschicken dass ich hier niemanden kritisieren will. Ganz im Gegenteil, das ist eine fantastische Arbeit die hier von allen geleistet wurde und ich bin schließlich auch ein Nutznießer davon. Vielen Dank dafür. Ich möchte das Folgende einfach als Anregung einbringen, aber auch erklären, warum es so ist wie es ist.

Ich fange einmal mit dem Problem der gegenwärtigen Schaltung (http://www.fhemwiki.de/wiki/EBUS) an:

Die eBus Spezifikation sieht für die beiden Pegel Low und High vor:
Low = 8,0 bis 10,0 Volt,  High = 15,0 bis 24,0 Volt.

Das heißt, im schlechtesten Fall haben wir einen Bereich von 10V bis 15V der den Unterschied von Low zu High ausmacht.
Dieses Signal wird nun über den CNY17 Optokoppler ,,analog" übertragen. Vom CNY17 gibt es vier ,,Versionen" (-1, -2, -3 und -4) welche sich alleine in der Übertragungsrate IC/IF im Bereich zwischen 13% und 90% bewegen können. Welcher Typ hier verwendet werden soll, wurde nicht angegeben. Wegen dieses Verhältnisses ergibt sich für die Spannungsdifferenz zwischen Low und High am Eingang 2 des 4011 C-Mos Gatters:

Maximum = 15-10 * 90% = 4,5V;   Minimum = 15-10 * 13% = 0,65V

Die Spezifikation des 4011 sieht aber bei dieser Versorgungsspannung (5V) typisch vor:
Low Level Input Voltage = 2V;  High Level Input Voltage = 3V.
Worst case sogar 1,5 / 3,5 Volt. Alles dazwischen ist undefiniert, der CD4011 kann dann am Ausgang beliebiges produzieren. Die von PAH angegebene Spannung für High = 2,57V liegt aber in jedem Fall außerhalb des erlaubten Bereichs. Es ist also selbst bei optimal eingestelltem Poti möglich, dass es wegen der Verletzung der Spezifikationen zu Fehlfunktionen kommt. Insbesondere ist es auch möglich dass wegen der Temperaturabhängigkeit der Bauteile Verschiebungen während des Betriebs eintreten.

Die im Forum immer wieder aufgestellte Behauptung, die Leitungslänge des eBus habe einen Einfluss, kann ich keinesfalls nachvollziehen. Diese könnte bestenfalls auf die Signalform Einfluss haben, nicht aber auf die Spannungen. Hier geht es ausschließlich um Bauteil-Toleranzen und die Einhaltung der Spezifikationen.

Die Lösung für alle diese Probleme lautet ,,Comparator" (siehe: comparator_pah.jpg). Und zwar bereits so nahe wie möglich am Eingangssignal. Nebenbei bemerkt ist das auch die Lösung die Vaillant in seinen Geräten einsetzt.

Zuerst wird das Eingangssignal über einen Spannungsteiler R4/R5 heruntergeteilt: Aus High=15V wird 3,19V und aus Low=12V wird 2,55V. Das passt nun zur Weiterverarbeitung in einem System mit 5V Versorgung, wobei die 5V auch gleichzeitig als Referenzspannung dienen. Der Comparator ist ein ,,invertierender Comparator mit Hysterese" (Schmitt-Trigger). Das bringt diverse Vorteile bei der Bemessung der Bauteile und wegen der Hysterese auch eine Sicherheit gegen Störungen auf der Datenleitung. Die Werte von R1, R2 und R3 ergeben sich aus den Standard Formeln. Da der Ausgang üblicherweise ein Open-Collector ist, benötigt er einen Pull-Up-Widerstand. Dieser sollte klein gegenüber den Widerständen R1 R2 und R3 sein, da er sonst das Rechenergebnis verfälscht. Mit diesen Werten ergibt sich nun: Der Comparator schaltet auf Low, wenn der Eingang über 3,06V geht, und er schaltet auf High, wenn er unter 2,75V geht. Da der Comparator invertiert, wird ihm ein einfacher Inverter mit einem Transistor nachgeschaltet.

Die Wahl des Comparators ist relativ unkritisch. Ich habe hier einen LM311 gewählt, weil er gerade zur Hand war. Es können sowohl bipolare Typen als auch CMOS verwendet werden. Wenn ein Comparator mit Push-Pull Ausgang Verwendung findet, müsste man allerdings die Beschaltung in Richtung Transistor anpassen.

Ab diesem Zeitpunkt ist das Signal rein digital. Es spielt also keine Rolle mehr, welcher Klasse der CNY17 angehört, oder in welcher Position das Poti steht !! Alle kritischen Pegel wurden bereits am Comparator behandelt..

Diese Schaltung kostet ein paar Cent und kann auf einfache Weise nachgerüstet werden. Sie kann ,,statt" des 3k3 Widerstandes R1 in den Signalpfad eingefügt werden, also R1 auslöten und den Eingang (,,IN") an den Brückengleichrichter ,,+" anschließen und den Ausgang (,,OUT") an den CNY17. Wegen der für diesen Zweck etwas unglücklichen Beschaltung des CNY17 muss hier mit einem PNP Transistor etwas ,,getrickst" werden (Q1 / R7 / R8). Bei einem Neu-Design könnte man entsprechend direkter vorgehen. Die Versorgung 0 / +5V kann am 78L05 abgegriffen werden.

Ich habe diese Schaltung selbst auf einer Lochraster Platine aufgebaut, allerdings nicht in dieser Variante mit dem PNP Transistor am Ausgang sondern mit einer NPN Transistor (siehe weiter unten). Ich habe mir nämlich den ,,kommerziellen" eBus USB Koppler von e-Service geleistet. Eigentlich hauptsächlich weil der schon ein Hutschienen Gehäuse hat, welches ich benötige. Da dann aber dort auch ein Potentiometer zum Einstellen vorhanden war, sah ich  mich veranlasst, mir auch diese Schaltung genauer anzusehen. So sieht sie aus:
(EService_Schaltung.jpg)

Der Spannungsteiler R1/R2/R3 teilt je nach Poti Einstellung von 21:1 bis 21:11. Somit ergibt sich schon einmal bei einer maximalen Eingangsspannung von 24V und voll aufgedrehtem Poti eine Spannung von 12,5V am Eingang des 4011. Weit über dessen Versorgungsspannung und eigentlich der Tod des 4011. Nicht gerade die feine Art...
Steht das Poti ,,optimal", d.h. wenn sich 12,5V Eingangsspannung auf 2,5V am 4011 abbilden, dann muss es (zusammen mit dem 1k Vorwiderstand) 4k2 haben. Bei dieser Stellung ergibt sich:

Low = 10*4,2/21 = 2V    und High = 15*4,2/21 = 3V

was zwar gerade noch den typischen Werten des 4011 entspricht, aber nicht den Worst Case Werten (1,5 / 3,5) und es setzt voraus dass das Poti um keinen Mikrometer falsch steht. Also insgesamt gesehen hätten hier zwei Festwiderstände mit den richtigen Werten einen besseren Dienst getan...

Jedenfalls bringt auch hier der Einsatz eines Comparators die Lösung aller Eingangs-Probleme. Die Schaltung muss allerdings am Ausgangs-Inverter etwas anders aussehen, um in den bestehenden e-Service Koppler integriert werden zu können (Comparator_eService.jpg). Auch hier würde man bei einer Neukonstruktion ein paar sinnlos gewordene Inverter einsparen können.

Noch eine Bemerkung zur Spannungsversorgung. Beim e-Service Konverter ist der 5-Volt-Regler nicht direkt an ,,+" des Brückengleichrichters angeschlossen. Warum ? Im schlechtesten Fall (Low am Bus) bleiben dem Regler 8-5 = 3 Volt zum Regeln was schon ziemlich nahe an den minimalen 2V liegt. Ein 10uF Kondensator (C1) dient hier als Ladungsspeicher und integriert die Spannung auf. Ein 100Ohm Widerstand begrenzt den Strom in den Kondensator und dient außerdem als Tiefpass-Filter. Die Diode D2 ist notwendig, damit der Kondensator nicht wieder über den Darlington-Transistor T1 entladen wird. Das macht Sinn weil somit die Eingangsspannung am 5V-Regler permanent höher und auch ,,glatter" ist. Eine derartige Ergänzung würde sicherlich auch der Schaltung von PAH guttun.

Also mit diesem Comparator am Eingang läuft mein Interface jetzt problemlos, OHNE irgendeine Einstellung vorgenommen zu haben. Alle Geräte am Bus wurden problemlos gefunden, was ja vorher nicht der Fall war. Ein Foto vom Umbau habe ich noch angefügt (eservice_mod.jpg). Vielleicht hilft das ja dem einen oder anderen seine Empfangs-Probleme zu beheben.

LG
Eduard

[Reinhart]

meine frage: hat sich der umbau bewährt und funktioniert der adpater noch?
hat ev. jemand auch die ethernet variante des adapters umgebaut?

Den bestehenden Adapter umbauen ist für Leute die mit dem Lötkolben umgehen können kein Problem. Chons hat das Testmuster von galileo die ganze Zeit ohne Fehler in Betrieb gehabt. Es wird jedoch wieder eine Sammelbestellung der V2 geben da kannst du dich dann dazu hängen, nur Platine kostet ja 2,50.- und ist sicher leistbar.

Die Ethernet Variante macht einige Kopfzerbrechen weil du die erforderlichen Latenzen nicht so leicht erreichst, zumindest mit einem K2 oder K3. Es gibt aber auch andere Varianten die aber größer sind und auch in den kommerziellen Adaptern verbaut sind. Wenn du dir die WLAN Variante der Platine 2.0 anschaust, da musste John extra eine neue Softwareanbindung (Firmware für Wemos) schreiben weil eine herkömmliche serielle Bridge von der Latenz her nicht ausreicht. Empfang geht, aber zum Senden bist dann zu spät und kommt nicht mehr korrekt an.
Das ist der einzige springende Punkt beim eBus Protokoll, dass man hier nicht ewig Zeit hat auf ein Signal zu antworten. Wenn der Bus ein Syn aussendet (AA) , dann sollte die Hardware innerhalb weniger msec (bis etwa 10-15 kein Problem) darauf reagierien, sonst meldet sich eventuell ein anderer oder du bist zu spät oder funkst gar mitten ins Protokoll einer anderen Übertragungsanforderung.

LG

[aia]

Bei der nächsen Adapter Bestellung bin ich dabei, das ist schon mal klar.

Trotzdem möchte ich diesen esera auch noch zum laufen bringen, ...

Den Lötkolben kann ich halten, komme aber grundsätzlich aus einer anderen Ecke, deshalb muss ich nochmals im Detail nachfragen.

Du schreibst in den kommerziellen Adaptern sind Varianten verbaut, welche entsprechende Latenzen erreichen können,
somit sollte dies auch im esera adapter passen ?
Soweit ich das jetzt sehe ist das Latenzproblem auch unabhängig von der neuen Schaltung statt dem Poti.

Fazit: der Umbau des esera sollte auch mit der Ethernet Variante klappen, da hier ja nur das Signal entsprechend angepasst wird?

Lieg ich da noch richtig ?

[john30]

Du schreibst in den kommerziellen Adaptern sind Varianten verbaut, welche entsprechende Latenzen erreichen können,
somit sollte dies auch im esera adapter passen ?

Leider nein, der Ethernet Koppler ist bekannt für immer wieder auftretende Probleme. Das liegt zum Teil eben daran, dass der verbaute Serial-Ethernet Wandler nicht unbdeingt das beste Modell ist. Dieses verursacht Latenzen bis 100ms, was dann das eBUS Protkoll ruiniert.

Soweit ich das jetzt sehe ist das Latenzproblem auch unabhängig von der neuen Schaltung statt dem Poti.

das schon, ja.

Fazit: der Umbau des esera sollte auch mit der Ethernet Variante klappen, da hier ja nur das Signal entsprechend angepasst wird?

es macht die Einstellung natürlich leichter, löst aber nicht das Latenzproblem.

[aia]

ok, alles klar!
danke für die infos, schön langsam verstehe ich die sache auch ein wenig auf der technischen seite.

teures stück plastik/elektro schrott

[galileo]

Hallo aia,

meine Geschichte beginnt auch bei dem esera/eservice Adapter, und zwar bei der Ethernet Variante. Dort habe ich allerdings auch die von dir beschriebenen Erfahrungen gemacht. Ging nur selten...

In meiner Verzweiflung und wegen der Berichte in diesem Forum (alle mit USB/Seriell Wandler) habe ich mir dann auch noch die eservice USB Variante besorgt. Damit konnte ich von meinen vier eBus Teilnehmern zwei erkennen und zwei nicht (lag wohl an unterschiedlichen Pegeln am Bus). Bin dann John30 auf die Nerven gegangen  der mich dann auf das Problem mit dem Poti gebracht hat. Mit der "Mikrometer-Schraube" gings dann und das war letztlich der Auslöser für meine Überlegungen zu diesem Posting.

Ich habe dann zwei Dinge gemacht - einmal den eservice Adapter umgebaut (ich glaube, das wolltest du eigentlich wissen) und dann noch die Schaltung entworfen, die jetzt unter eBus Adapter 2.0 dank Chons, Reinhart und John30 mit so viel Mühe und Herzblut publiziert wird (an dieser Stelle danke an Euch und Hut ab für diese Arbeit!)

Der umgebaute eservice Adapter (USB) hat bei mir viele Monate klaglos funktioniert, ich habe ihn erst entfernt als ich den eBus Adapter 2.0 getestet und dann verwendet habe. Die Ethernet Variante
habe ich nie wieder angeschaut und heute weiss ich auch dass der Grund für das Nicht-funktionieren mit höchster Wahrscheinlichkeit das Latenzproblem ist.

Also leider kann ich dir auch keinen besseren Rat geben, als die Ethernet Variante zu vergessen. Wenn du nicht nocheinmal auf esera (USB) zurückgreifen willst dann kann ich dir nur den Adapter 2.0 ans Herz legen.
LG Eduard

P.S. Wenn du willst kann ich dir meinen umgebauten eservice-USB Adapter "borgen", bis es wieder Adapter 2.0 gibt. Liegt sonst eh nur bei mir herum. Schreib mir eine PM.

[hanske]

Hallo,
ich weiß nicht, ob der Thread noch länger werden soll, aber bei mir läufts leider auch nicht rund.
Ich hab den den Ebus Adapter über den Wemos am Raspi hängen (Wheezy).
Wenn ich den Wemos resette, bekomme ich für maximal 5-10 Minuten eine Kommunikation mit meiner Vaillant Therme hin. Danach meldet ebusctl "no signal".
In dieser Zeit kann ich z.B. über die Konsole mit:

Code Auswählen Erweitern

ebusctl r StorageTemp die Temperatur abfragen.
Über FHEM klappt es aber nicht. Da bekomme ich von Anfang an keine Antwort:

Code Auswählen Erweitern

2018.01.28 17:55:56 3: EBUS device opened
2018.01.28 17:55:59 2: EBUS: second attempt to read timed out, this is an unrecoverable error.
2018.01.28 17:55:59 1: EBUS: no answer received (wrote r -f StorageTemp\n (\162\040\055\146\040\123\164\157\162\141\147\145\124\145\155\160\012), expected \d+\.\d+\n\n)
2018.01.28 17:55:59 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 2363) line 1.
2018.01.28 17:55:59 3: eval: { sprintf("%5.1f",$_) }
Meine Funktion ist wie folgt definiert:

Code Auswählen Erweitern

# StorageTemp
get StorageTemp cmd {"r -f StorageTemp\n"}
get StorageTemp expect "\d+\.\d+\n\n"
get StorageTemp postproc { sprintf("%5.1f",$_) }

Wäre schön, wenn die Ergebnisse erst mal auch bei FHEM ankommen würden.
Vielleicht hat da jemand einen Tipp.
Warum der Wemos später aussteigt, kann ich selbst nochmal weiter untersuchen.
Danke

[aia]

@galileo:
solange ich den traffic am bus niedrig halte, klappt das meiste eigentlich recht gut.
teilweise bekomme ich zwar über 5 minuten überhaupt keine antwort, in summe ist es aber noch erträglich (meistens lese ich ja nur).
wenn ich mir die failed ratio anschaue kommen mir allerdings die tränen - 85% aller telgramme sind für den kanal

ich komme gerne auf dein angebot zurück für ein paar wochen mal die usb variante zu testen - der direkte vergleich ist sicher sehr interessant.

bekommst eine pm.

[Reinhart]

@hanske

du versuchst den String "ok" in eine Zahl zu verwandeln, das klappt nicht!
Warum holst du nicht nur die Temperatur als Zahl vom Bus?

Code Auswählen Erweitern

pi@Raspberry2:~ $ ebusctl r -f StorageTemp
36.38;ok

das ist das Ergebnis wie du sie holst, inkl. dem String "ok"

Code Auswählen Erweitern

pi@Raspberry2:~ $ ebusctl r -f StorageTemp temp
36.25

und so separierst du nur die Temperatur.

das schaut dann so aus:

Code Auswählen Erweitern

get StorageTemp cmd {"r -f StorageTemp temp\n"}
get StorageTemp expect  ".*\n*"
get StorageTemp postproc {$_}

Betreffend dem Wlan, hast du ein halbwegs gutes Signal zum Wemos?
Ich habe bei den Tests die verschiedenen Übetragsungsmodi getestet und konnte bis 802.11b problemlos über mehrere Tage kommunizieren. Das Empfangssignal sollte jedoch in halbwegs guter Qualität sein und keine Aussetzer haben. Oft genügt eine neue Positionierung des Wemos für besseren Empfang.

LG

[hanske]

Hallo Rainer,
danke für den Tipp mit dem temp.
Ich hatte mich erst am Wiki orientiert, dann aber festgestellt, dass bei meiner Therme die Befehle anders sind und mir die Strings aus dem CSV geholt. Dabei habe ich das temp wohl vergessen.
Muss man immer "temp" schreiben, wenn man das "ok" nicht haben will?
Im Wiki steht auch mal "temp1.0"
Ich habe jetzt deinen Vorschlag implementiert:

Code Auswählen Erweitern

get StorageTemp cmd {"r -f StorageTemp temp\n"}
get StorageTemp expect  ".*\n*"
get StorageTemp postproc {$_}

bekomme aber immer noch keine Antwort.

Code Auswählen Erweitern

2018.01.28 21:21:32 1: EBUS: no answer received (wrote r -f StorageTemp temp\n (\162\040\055\146\040\123\164\157\162\141\147\145\124\145\155\160\040\164\145\155\160\012), expected .*\n*)

Die Konsole liefert aber:

Code Auswählen Erweitern

pi@raspberrypi ~ $ ebusctl r storageTemp temp
19.44

Da muss doch noch was anderes schief laufen?

Btw:
Wlan ist gut (Fritzbox ist nur 2 Meter entfernt) und der Raspi hängt am LAN.
Läuft jetzt gerade auch schon 1 Stunde stabil.
Beim Wemos hängt sich auch häufig der Webserver auf.

[rob uboot]

hallo nochmals!

habe noch eine frage betreffend 470 und 700 regler von vaillant.
vielleicht hat ja jemand diesbezüglich erfahren gemacht oder kennt sich mit dem ebus perfekt aus. 

laut csv file kann man in der 470 variante weder den HwcOPMode noch den Hc1Pump schreiben.
stellt man das händisch um geht der befehl zwar als 'done' durch nur tut sich dabei eben nichts.
laut dem csv file am multimatic 700 ist das original schon auf schreiben.
würde mal daher davon ausgehen dass man eine 700 haben muss um den befehl auch durchführen zu können.
muss oder kann man das mit der hardware lösen oder geht das doch mit der software?

[Sven77]

Hi,
zur 700 gibt es ja leider keine offiziellen Datenbanken mehr. Alles was da drin steht, wurde von Usern durch try&error zusammengetragen.
Den HwcOpMode kann man dort ganz normal und ohne Umstände schreiben.

Ich habe jedoch bei Vaillant auch einige Kuriositäten entdeckt:

a) Manche Informationen sind über verschiedene Nachrichten les-/schreibbar. So habe ich bei meinem icoVIT 156 beobachtet, dass mit einer zweiten Nachricht immer die aktuelle Einstellung gespiegelt ist. Dort kann man sie sogar schreiben, jedoch hat das überhaupt keinen Einfluss - nach einer gewissen Zeit steht dort wieder der aktive Wert drin. Erst wenn man die "richtige" ID beschreibt, ändert sich der Wert aktiv und wird widerum auf die Kopie gespiegelt. Ich vermute, dass intern so eine Kopie gehalten wird, um ein "Abbrechen" der Änderung von Einstellungen über das Bedienfeld zu ermöglichen. (daran musste ich denken, weil das Schreiben ja erfolgreich ist - später aber doch der alte Wert wieder in der 470 steht)

b) Im 700 ist der "special function mode" in 2 Registern zu lesen: 00007400 kann gelesen und geschrieben werden, danach steht auch in 00007800 der aktuell gültige Modus (z.Bsp. QuickVeto oder Party). Das Schreiben des 00007800 führt jedoch nicht dazu, dass der Modus aktiviert wird... mit einer Ausnahme: ist ein SpecialMode aktiv, kann der 00007800 auf 0 gesetzt werden, um diesen Modus abzubrechen! Es kann also zum AUS- nicht aber zum EINschalten eines Modus benutzt werden.
(das hatte ich aber mit dem VRC700/1 getestet und dann nie wieder mit dem /2 oder /4 überprüft)

Also vor dem Hintergrund kann ich nur empfehlen, sämtliche andere Nachrichten für eine 470 nochmal zu prüfen (es gab mal irgendwo ein allregisters.sh von John!). Eventuell findet sich ja eine ID, die auch immer dem HwcOpMode entspricht und deren Schreiben mehr Erfolg bringt.

Viel Erfolg,
Sven

[Reinhart]

@hanske

schau bitte einmal ins Log nachdem du FHEM neu gestartet hast ob da irgendwelche Fehlermeldungen von der baixx.cfg kommen das er was nicht laden kann?

Ist das jetzt nur der eine Wert der über FHEM nicht geht oder alle?

LG

[hanske]

 Hallo Rainer,
im FHEM log kommt keine Fehlermeldung bei shutdown restart.
Es funktioniert keine Abfrage über FHEM.
Allerdings habe ich im Gegensatz zum Wiki nicht für jeden Parameter ein eigenes ECMD Device erstellen müssen.
Ich kann mit einem ECMD Device über "get" auf alle in der .cfg Datei definierten Befehle zugreifen.
Leider funktionieren sie aber nicht.
Schöne Grüße
hanske