Hallo zusammen, Ich habe vor einigen Tagen an meinem Gaszähler (Honeywell BK-G4M) einen Reedkontakt (ELV ES-GAS-2) angeschlossen. Der Sensor beinhaltet einen Reedkontakt der bereits im Sensor mit Widerständen versehen ist. Mein Problem ist nun folgendes: Der Sensor zählt falsch. Beispielsweise habe ich folgende Zählerstände abgelesen: Start: 145.637m3 Ende: 153.647m3 Verbraucht: 9.01m3 Bei 0.01m3 per Reed/Impulse würde dies 901 Impulse ergeben. Der Sensor hat aber 933 übermittelt. Ein fehler von 32 Impulsen und somit 0.3m3. Was aber das Spannende ist: Es handelt sich mit Sicherheit NICHT um einen Prellefekt da ich folgende Logik im MCU verbaut habe: - Interrupt "Fallend", das bedeutet der Zählimpuls wird erst aufgenommen wenn der Magnet "vorbeigefahren" ist. - Nach Interrupt einen Debounce von 10 Sekunden. - Nach Ablaufs des Debounce prüfung auf "Eingang == Low", um sicherzustellen das der Magnet nicht per Zufall noch auf dem Sensor "steht" - Setzen eines neuen Impulses Somit ist meiner Meinung nach ausgeschlossen, das es sich um ein elektrisches Prellen handelt. Betrachtet man den Kontakt des Reeds mit dem Oszi, ist er auch aussergewöhnlich gut (nahezu kein Prell). Zusätzlich: In meiner Auswertung per MQTT habe ich mir die jeweiligen Einzelimpulse welche übermittelt werden angesehen, auch dort kein Hinweis auf Prellen, da nie ein Impuls direkt nach dem Ablauf des Debounce kommt. Zwischen jeder Übermittlung vergehen >20 Sekunden (30s wenn man den Debounce zählt), bis hin zu Minuten. Die Minimale Zeit zwischen Impulsen die ich gesehen habe, ist ca 20 Sekunden unter "Vollast". Beim theoretischen maximalen Gasverbauch von 1.8m3/h wären es genau alle 20s ein Impuls Daher ist es für mich schon sehr fragwürdig an was das noch liegen könnte. Hat jemand eine Idee die man noch probieren könnte?
Johnny S. schrieb: > Es handelt sich mit Sicherheit NICHT um einen Prellefekt da ich folgende > Logik im MCU verbaut habe: HAHA! > - Interrupt "Fallend", das bedeutet der Zählimpuls wird erst aufgenommen > wenn der Magnet "vorbeigefahren" ist. Soso, und du kannst hellsehen? > - Nach Interrupt einen Debounce von 10 Sekunden. Jaja, Angstenprellung, weil man keine Ahnung hat. > - Nach Ablaufs des Debounce prüfung auf "Eingang == Low", um > sicherzustellen das der Magnet nicht per Zufall noch auf dem Sensor > "steht" Aha. > - Setzen eines neuen Impulses Kaum, denn das macht der Reedkontakt. > Somit ist meiner Meinung nach ausgeschlossen, das es sich um ein > elektrisches Prellen handelt. Träumer. > Betrachtet man den Kontakt des Reeds mit > dem Oszi, ist er auch aussergewöhnlich gut (nahezu kein Prell). soso, "nahezu". Was ist "Prell"? oder meinst du eher Prellen? > Daher ist es für mich schon sehr fragwürdig an was das noch liegen > könnte. > Hat jemand eine Idee die man noch probieren könnte? Machs mal Old school, OHNE Flanken-Interrupt, mit normalem Timer-Interrupt und der Entprellroutine aus dem Artikel Entprellung. du wurst Staunen.
Johnny S. schrieb: > Hat jemand eine Idee die man noch probieren könnte? Zeichne mal für alle erkannten Impulse einen Zeitstempel mit auf. Oder untersuche die Impulse mit einem PC-Logikanalysator der einen längeren Zeitraum aufzeichnen kann. LG, Sebastian
@falk b. In seinem Szenario kann diese sehr langsame Entprellung durchaus funktionieren, voraus gesetzt sie ist korrekt implementiert . @jonny: Es muss sicher gestellt sein, das ein impuls nie doppelt gezählt wird, auch wenn mehrere Impulse nahezu direkt hintereinander kommen , z.b. noch während der Abarbeitung der ISR. Kannst du das sicher Ausschließen? Wird sicher gestellt, das die Register, in welchen der interrupt vermerkt ist, sauber zurückgesetzt werden und das weitere Interrupts sofort nach eintreffen des ersten blockiert werden ? Ansonsten empfehle ich dir auch, vorzugehen, wie es Sebastian vorgeschlagen hat. Dann sollte sich doch schnell zeigen, was hier das Problem ist.
Falk B. schrieb: > Johnny S. schrieb: > >> Es handelt sich mit Sicherheit NICHT um einen Prellefekt da ich folgende >> Logik im MCU verbaut habe: > > HAHA! > >> - Interrupt "Fallend", das bedeutet der Zählimpuls wird erst aufgenommen >> wenn der Magnet "vorbeigefahren" ist. > > Soso, und du kannst hellsehen? Nein, das lässt sich mit einem Oszilloskop gut sehen, immer wenn sich das Zählerrad auf der letzen Stelle über 0 dreht, wird ein Impuls ausgelöst. Der Kontakt wird geschlossen und öffnet sich wieder. Das Signal wechselt von 0V auf 3.3V und dann wieder auf 0V >> - Nach Ablaufs des Debounce prüfung auf "Eingang == Low", um >> sicherzustellen das der Magnet nicht per Zufall noch auf dem Sensor >> "steht" > > Aha. Dies hatte ich festgestellt, wenn der Verbauch zufällig beim wechsel von 9 auf 0 sich stark verlangsamt, dann bleibt der Eingang mehre Sekunden auf 3.3V >> Betrachtet man den Kontakt des Reeds mit >> dem Oszi, ist er auch aussergewöhnlich gut (nahezu kein Prell). > > soso, "nahezu". Was ist "Prell"? oder meinst du eher Prellen? > Ich erkenne beim Wechsel des Eingangs von 0 auf 3.3V ein leichtes Prellen, dies zeigt sich aber nur durch abfallen der Spannung auf ca. 2.5-2.7V, nicht komplett auf 0. Da der ESP32 logisch-null erst bei 0.25*3.3V registiert, sollte dieses prellen keinen Einfluss haben, und ist ja auch über den Code abgefangen. Sebastian schrieb: > Johnny S. schrieb: >> Hat jemand eine Idee die man noch probieren könnte? > > Zeichne mal für alle erkannten Impulse einen Zeitstempel mit auf. Oder > untersuche die Impulse mit einem PC-Logikanalysator der einen längeren > Zeitraum aufzeichnen kann. > > LG, Sebastian Die Zeitstempel habe ich grundsätzlich, da diese ja beim Einfügen in die Datenbank des Telegramms genommen werden. hacker-tobi schrieb: > @falk b. In seinem Szenario kann diese sehr langsame Entprellung > durchaus funktionieren, voraus gesetzt sie ist korrekt implementiert . > > @jonny: Es muss sicher gestellt sein, das ein impuls nie doppelt gezählt > wird, auch wenn mehrere Impulse nahezu direkt hintereinander kommen , > z.b. noch während der Abarbeitung der ISR. > Kannst du das sicher Ausschließen? > Wird sicher gestellt, das die Register, in welchen der interrupt > vermerkt ist, sauber zurückgesetzt werden und das weitere Interrupts > sofort nach eintreffen des ersten blockiert werden ? Das habe ich so gut wie möglich versucht zu verhindern, auch habe ich keinen Impuls gefunden, der direkt nach Ablauf des Debounce übermittelt wurde, es sind immer mindestens 20-30 Sekunden dazwischen. Hier die Codeauschnitte:
1 | void IRAM_ATTR ISR() { |
2 | detachInterrupt(12); |
3 | isInterrupted= true; |
4 | }
|
1 | void handleInterrupt(){ |
2 | if(isInterrupted){ |
3 | client.publish("sensors/gas01/count", "1"); |
4 | client.publish("sensors/gas01/rssi", String(WiFi.RSSI()); |
5 | isInterrupted = false; |
6 | isDebounce = true; |
7 | lastDebounce = millis(); |
8 | }
|
1 | void handleDeboune(){ |
2 | if(isDebounce){ |
3 | if(millis()> (lastDebounce+10000){ |
4 | if(digitalRead(12) == LOW){ |
5 | isDebounce = false; |
6 | attachInterrupt(12, ISR, FALLING); |
7 | }
|
8 | }
|
9 | }
|
10 | }
|
Johnny S. schrieb: > Es handelt sich mit Sicherheit NICHT um einen Prellefekt da ich folgende > Logik im MCU verbaut habe: prust *gacker* Ich hole mir schon mal eine Portion Popcorn.
Vielleicht empfängst du Radiowellen. Beim Schalten von induktiven Lasten entstehen manchmal ziemlich starke Wellen, die ungewollte Reaktionen in deiner Schaltung auslösen können. Ich hatte auf diesem Weg mal ungewollt sporadische Resets bei einem Mikrocontroller. Damals hatte ich nicht erwartet, dass 5 cm offene Leiterbahn so eine gute Antenne sein können. Solche Fehler macht man nur einmal, wenn man sie verstanden hat. Zeige mal den Schaltplan. Verwendest du ein abgeschirmtes Kabel, und wie lang ist es?
Hallo, genau dieses Problem habe ich auch mit meinem Zähler. Derzeit hatte ich beim Bau keinen Reedkontakt rumliegen und habe einfach ein Reedrelais genommen. Ähnlich wie dieses: https://www.reichelt.de/reedrelais-1-wechsler-200-v-dc-0-5-a-litt-he721c1200-p241002.html?CCOUNTRY=445&LANGUAGE=de&trstct=pos_12&nbc=1&&r=1 Es kommt darauf an, den Kontakt möglichst genau zu positionieren. Am Monatsende weicht der Zählerstand im ATtiny jedoch meistens leicht vom Gaszählerstand ab. Das ist jedoch so gering, das es mir egal ist. Das Programm ist in Assembler geschrieben. Ausgewertet wird eine Flanke. Die Zählerwerte werden ausschließlich im ATtiny gespeichert und bei Bedarf abgefragt. Die Uhr läuft mit dem 2,.. Mhz Quarz erstaunlich genau. Gruß Carsten
Angehängte Dateien:
-
log.png
4,8 KB
Hier auch noch ein kurzer Ausschnitt aus dem Log der letzten Stunde in Klammern die Zeit seit dem letzten Impuls
Johnny S. schrieb: > Start: 145.637m3 > Ende: 153.647m3 > Verbraucht: 9.01m3 Hm, sind das nicht eher 8.010m³ ???
Johnny S. schrieb: >
1 | void handleDeboune(){ |
2 | > if(isDebounce){ |
3 | > if(millis()> (lastDebounce+10000){ |
4 | > if(digitalRead(12) == LOW){ |
5 | > isDebounce = false; |
6 | > attachInterrupt(12, ISR, FALLING); |
7 | > } |
8 | > } |
9 | > } |
10 | > } |
Die 10 Sekunden Abfrage muss so aussehen:
if((millis() - lastDebounce) > 10000){
Sonst hast du ein Problem, wenn der millis() Zähler den Bereich von
(2^32 - 10000) erreicht. Ab da gibt es dann kein Debouncing mehr,
solange bis millis() wieder auf 0 geht.
Beispiel:
handleInterrupt(): lastDebounce = millis() = 2^32 - 10000
handleDebounce(): if((2^32-10000) > (2^32-10000 + 10000 = 0) ist immer
true
Als 7400 noch fünf Mark kostete, war Entprellung ein Problem. Aber im Jahre 2022?
Johnny S. schrieb: > Es handelt sich mit Sicherheit NICHT um einen Prellefekt da ich folgende > Logik im MCU verbaut habe: Ein Gaszähler bleibt ja auch mal stehen. Und wenn der Magnet dann gerade zwischen Nord und süd steht so kann ein Reed-Kontakt auch nach 10s prellen. Ein bipolarer Hall-Sensor sollte da besser funktionieren: https://www.tme.eu/Document/6752077a094d36387c89e99dd4fb98eb/SS41-datasheet.pdf
Johnny S. schrieb: > - Nach Interrupt einen Debounce von 10 Sekunden. Du bist nicht der erste, der Delay mit Entprellen verwechselt. Man muß schon verstehen, wie ein externer Interrupt in der CPU arbeitet. Ein arme Leute Entprellen mit Delay geht eingeschränkt, wenn man nach dem Warten erstmal das Pending Flag rücksetzt, bevor man den Interrupt wieder freigibt. Dabei beachten, daß manche CPUs das Flag verzögert löschen, d.h. nochmal etwas warten. Ein Entstören (Schaltpulse in der Nähe) erfolgt allerdings damit nicht, das kann nur eine korrekte Entprellung mit Mehrfachabtastung per Timerinterrupt.
Winnie schrieb: > Die 10 Sekunden Abfrage muss so aussehen: > if((millis() - lastDebounce) > 10000){ +1 Johnny S. schrieb: > Hier auch noch ein kurzer Ausschnitt aus dem Log der letzten Stunde in > Klammern die Zeit seit dem letzten Impuls Läuft dein Zähler tatsächlich so "unrund"? Was hängt da alles dran? Carsten-Peter C. schrieb: > Am Monatsende weicht der Zählerstand im ATtiny jedoch meistens leicht vom > Gaszählerstand ab. Das ist jedoch so gering, das es mir egal ist. Diese Denkweise ist in der SW-Entwicklung inzwischen anerkannt.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Läuft dein Zähler tatsächlich so "unrund"? Was hängt da alles dran? Meine neue Gastherme - 1,5 Jahre alt - regelt tatsächlich kontinuierlich die Leistung. Solche Sprünge im Gasverbrauch sind da normal.
Lothar M. schrieb: >> Am Monatsende weicht der Zählerstand im ATtiny jedoch meistens leicht vom >> Gaszählerstand ab. Das ist jedoch so gering, das es mir egal ist. > Diese Denkweise ist in der SW-Entwicklung inzwischen anerkannt. In der Tat 8-(
dem Entprellen und überhaupt dem Reedkontakt kann man aus dem Weg gehen indem man den Zählerstand mit ESP32Cam und AI ausliest, da gibt es ein Projekt auf github das sich schon vielfach bewährt hat.
J. S. schrieb: > dem Entprellen und überhaupt dem Reedkontakt kann man aus dem Weg gehen > indem man den Zählerstand mit ESP32Cam und AI ausliest, da gibt es ein > Projekt auf github das sich schon vielfach bewährt hat. LOL! Und du meinst ernsthaft, jemand, der schon mit einer trivialen Kontaktentprellung softwaretechnisch überfordert ist, bekommt die Software-Module für Kamera und AI zur Bilderkennung ans Laufen?
Lothar M. schrieb: > Diese Denkweise ist in der SW-Entwicklung inzwischen anerkannt. Hallo, die gleiche SW nutze ich für die Auswertung der S0 Schnittstelle vom Stromzähler. Da läuft sie fehlerfrei. Es kommt auf die möglichst genauue Position des Reedkontaktes an. Gruß Carsten
Winnie schrieb: > Sonst hast du ein Problem, wenn der millis() Zähler den Bereich von > (2^32 - 10000) erreicht. Ab da gibt es dann kein Debouncing mehr, > solange bis millis() wieder auf 0 geht. Da hast du vollkommen recht, ist aber eher ein "Schönheitsfehler" da dieses Problem erst nach über 3 Jahren ununterbrochenem Betrieb auftritt ;) Lothar M. schrieb: > Läuft dein Zähler tatsächlich so "unrund"? Was hängt da alles dran? Es hängt die Heizung (Heizkörper) und Warmwasser dran und läuft tatsächlich ziemlich "unrund", was ja aber auch nicht falsch ist. Es gibt z.b. auch Abschnitte wo eine ganze Stunde nicht geheizt wird wenn z.b. kein warmes Wasser benötigt wurde, und die Temperatur im Haus stabil ist Thorsten S. schrieb: > J. S. schrieb: >> dem Entprellen und überhaupt dem Reedkontakt kann man aus dem Weg gehen >> indem man den Zählerstand mit ESP32Cam und AI ausliest, da gibt es ein >> Projekt auf github das sich schon vielfach bewährt hat. > > LOL! > Und du meinst ernsthaft, jemand, der schon mit einer trivialen > Kontaktentprellung softwaretechnisch überfordert ist, bekommt die > Software-Module für Kamera und AI zur Bilderkennung ans Laufen? Diese Projekte kenne ich und wären auch kein Problem zu realisieren, hatte bei unserem alten Stromzähler schon vor Jahren mit einm Raspi und einer Webcam gemacht, bevor dieser auf einen digitalen getauscht wurde. Als nächsten Schritt werde ich jetz mal einige Stunden den Zähler mit einer Kamera aufzeichnen, um dann herauszufinden welche Impulse mit welchem Zeitstempel als "falsch" gezählt wurden, vielleicht gibt das ja Aufschluss.
Johnny S. schrieb: >> Sonst hast du ein Problem, wenn der millis() Zähler den Bereich von >> (2^32 - 10000) erreicht. Ab da gibt es dann kein Debouncing mehr, >> solange bis millis() wieder auf 0 geht. > > Da hast du vollkommen recht, ist aber eher ein "Schönheitsfehler" da > dieses Problem erst nach über 3 Jahren ununterbrochenem Betrieb auftritt > ;) Das mit den Grundrechenarten müssen wir dann wohl noch ein wenig üben. Eine 32 Bit Variable hat einen Maximalwert von 2^32-1, macht 4294967295. Bei einer Zählfrequenz von 1kHz erfolgt nach 4294967295 ms 4294967,295 s 1193,05 h 49,7 d ein Überlauf.
Johnny S. schrieb: > Lothar M. schrieb: >> Läuft dein Zähler tatsächlich so "unrund"? Was hängt da alles dran? > Es hängt die Heizung (Heizkörper) und Warmwasser dran und läuft > tatsächlich ziemlich "unrund", was ja aber auch nicht falsch ist. > Es gibt z.b. auch Abschnitte wo eine ganze Stunde nicht geheizt wird Schon klar, mir fällt da nur dieses 1 Event mit 30 Sekunden inmitten der Minuten sehr ins Auge. Johnny S. schrieb: > Bei 0.01m3 per Reed/Impulse würde dies 901 Impulse ergeben. Der Sensor > hat aber 933 übermittelt. Ein fehler von 32 Impulsen Also 1 fehlerhafter zusätzlicher Impuls unter 30 Pulsen. Sowas zeigt in etwa auch dein Screenshot vom Log...
:
Bearbeitet durch Moderator
...einen externen Interrupt für einen prellenden Kontakt zu verwenden ist ein ganz schlechter Ansatz. Den Pin mit maximal 1 ms pollen und vernünftig in Sofware entprellen, dann geht das auch. VG JJ
Falk B. schrieb: > Machs mal Old school, OHNE Flanken-Interrupt, mit normalem > Timer-Interrupt und der Entprellroutine aus dem Artikel > Entprellung. du wurst Staunen. Wie heftig prellen denn solche Reedkontakte? Und im Vergleich dazu: Wie problematisch ist das Prellen bei benetzten Reedkontakten? Vielleicht reicht ja schon ein kleines C / RC? Aber Achtung: Reedkontakte reagieren allergisch auf kapazitive Belastung!
habe vor Jahren den Gaszaehler per Hall Sensoren ausgelesen (inzwischen Gas abgeschafft). Das hat erst dann sauber funktioniert, als ich zwei Sensoren ca. 90Grad versetzt angebacht habe (einen unter Zaehlerfenster und einen weiteren vorn auf Zaehlerfenster). Der Controller faengt an, die Umdrehung zu registrieren, wenn vom unteren Sensor der Zustand von H nach L wechselt, zaehlt aber nur 0.001m3 dazu, wenn darauffolgend auch der vordere Sensor von H nach L wechselt. Sobald der vordere Zaehler wieder L -> H geht, werden beide Sensorzustaende wieder auf Anfangslage zurueckgesetzt (Quadratur-Auslesung ???). Das Hauptproblem vorher war, das wenn der Zaehler auf der letzten Stelle auf "6" stehen blieb (da wo der Magnet drunter ist), und dann prellt das wie verrueckt.
ul5255 schrieb: > Das Hauptproblem vorher war, > das wenn der Zaehler auf der letzten Stelle auf "6" stehen blieb (da wo > der Magnet drunter ist), und dann prellt das wie verrueckt. Die magneto-mechanische Kontruktion muss schon stimmen, sonst kann sich das Problem recht sportlich gestalten. Reedkontakte haben eine amtliche Hysterese fest eingebaut. Bei Hall-Sensoren ist das nicht sicher, kommt auf den genauen Typ an. Gestörte Betriebsspannung tut dann schnell den Rest ...
dann wuerde ich mit meinen Erfahrungen trotzdem zu zwei Reed-Kontakten mit aehnlicher Auswerte-Logik greifen, wenn ich das nochmal implementieren muesste (Gott sei Dank nicht notwendig)
Nachtrag: wurde weiter oben bereits angesprochen, aber bei mir habe ich die Zustaende der Sensoren mit 1kHz (oder 100Hz ?, schon lange her) ausgelesen. Wenn die Brennwert-Therme den WW-Boiler beladen hat, hat die ziemlich viel Gas gezogen. Sonst "fliegt" das Zaehlrad am Sensor vorbei, ohne dass es der Controller bemerkt.
ul5255 schrieb: > Das Hauptproblem vorher war, > das wenn der Zaehler auf der letzten Stelle auf "6" stehen blieb (da wo > der Magnet drunter ist), und dann prellt das wie verrueckt. Das dürfte dann ein analoger Hall-Sensor gewesen sein, d.h. die Spannung ist proportional zur Feldstärke. Den mußt Du mit einem ADC-Pin einlesen und eine Hysterese programmieren.
ul5255 schrieb: > wieder L -> H geht, werden beide Sensorzustaende wieder auf Anfangslage > zurueckgesetzt (Quadratur-Auslesung ???). BINGO! Siehe Drehgeber. Dann darf das Ding auch auf der Kippe stehen bleiben, die Schritte vor/zurück summieren sich nicht! > Das Hauptproblem vorher war, > das wenn der Zaehler auf der letzten Stelle auf "6" stehen blieb (da wo > der Magnet drunter ist), und dann prellt das wie verrueckt. EBEN! Also braucht man zwei Reedkontakte für eine "kippelsichere" Auswertung.
ul5255 schrieb: > Das Hauptproblem vorher war, > das wenn der Zaehler auf der letzten Stelle auf "6" stehen blieb (da wo > der Magnet drunter ist), und dann prellt das wie verrueckt. Klingt unglaubwürdig. Reed-Kontakte zeigen deutliches Hystereseverhalten. Siehe auch https://www.conrad.de/de/o/reed-kontakte-0200190.html#charakteristik
HolgerT schrieb: > Klingt unglaubwürdig. Reed-Kontakte zeigen deutliches > Hystereseverhalten. ich hatte Hall-Sensoren verwendet, die hatten auf der Platine bereits die Auswerte-Logik mit OpAmp und Sollwert-Vorgabe als Poti
ul5255 schrieb: > ich hatte Hall-Sensoren verwendet Tschuldigung, hatte ich übersehen. Hast aber auch geschrieben: ul5255 schrieb: > dann wuerde ich mit meinen Erfahrungen trotzdem zu zwei Reed-Kontakten > mit aehnlicher Auswerte-Logik greifen, wenn ich das nochmal > implementieren muesste (Gott sei Dank nicht notwendig)
Angehängte Dateien:
-
schnitt.png
76 KB
Mittlerweilen habe ich herausgefunden, das die Fehlerhaften Impulse immer ca. bei der Zahl 3 auf dem Zähler generiert werden. Auch habe ich heraugefunden, das der Sensor welcher vom Hersteller angeboten wird, als Standartversion und Version mit Alarm-Kontakt angeboten wird, der Alarmkontakt soll ermitteln wenn der Sensor demontiert wird. Hierzu gibt es wohl einen zweiten Magnet und zweiten Reed. Rein vom Bild her, scheint mir der Kontakt vom ELV-Sensor anderst positioniert als der Orginalsensor. Ich vermute daher, das des dazu kommen könnte, das aus dem "vorbeifahrenden" Magneten und dem Sicherheitsmagneten irgendwie ab und zu der Reed Kontakt geschalten wird. Ich werde nun einen Orginalsensor verbauen und prüfen.
Beitrag #7264418 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.