Hallo! Hat sich jemand mal das Innenleben von diversen Homematic Komponenten angesehen? Ist ein ISP bzw. JTAG Anschlus vorhanden? Es soll ja angeblich auf einem CC1110 (von TI) und einer Atmel-MCU beruhen. Mich interessiert dabei die Frage, ob man nicht "einfach" eine neue offene Firmware für die Dinger schreiben könnte, die auch in Bezug auf Sicherheit mehr zu bieten hat. Dieses BidCos-Protokoll soll ja eher Schrott sein. Ja, ich weiß, dass Homematic völlig überteuert ist. Aber darum soll es hier jetzt nicht gehen. ;-) Gruß Christian
Niemand da, der so eine Homematic-Komponente von Conrad oder ELV mal auseinander geschraubt hat? ;-)
>Ja, ich weiß, dass Homematic völlig überteuert ist.
hab mit jetzt nur kurz 3 sachen angescheut
zentrale 500€
i/o modul (wired) 12 ein 7 aus knapp über 100€
visualisierung (html) 200€
wetterstation 300€
also billiger gehts wohl nicht mehr...
Hi! Gute Idee und auch machbar. In den Geräten steckt ein universeller CC1100-Transceiver und meist ein Atmel mit herausgeführter 6ISP Schnittstelle (6 Kontaktpunkte). Der (nicht eingesetzte) CC1110 (mit Controller) hätte bestimmt geholfen die Preise zu senken. Ich würde aber ELV ungern in Ihrer "non-open-source" Strategie unterstützen wollen und diese überteuerten Geräte kaufen. Zumal es sich auch nicht durchzusetzen scheint. Es dürfte billiger sein nützliche FS20 "auf-/umzurüsten", dazu entwickeln wir z.B. gerade einen Transceiver mit Controller: http://busware.de/tiki-index.php?page=CPM Vielleicht sollte man direkt zu ZigBee wechseln?
Hallo Dirk, ich habe mir heute mal drei Homematic-Module zum Aufmachen geholt: 1x Fenster-/Tür-Kontakt 1x Dimmaktor 1x 4fach UP-Sender Von der Hardware sähe es in der Tat sehr gut machbar aus. Ich habe bis jetzt einen ATmega32L im Dimmaktor gesichtet und einen ATmega168v im UP-Sender. Es scheint zwei unterschiedliche Bauformen von Funkmodulen zu geben. Haben aber alle die gleiche Anzahl Pins. Ich gehe mal davon aus, dass überall ein CC1100-Transceiver drin steckt, oder? Die "non-open-source" Strategie ist natürlich völlig daneben. Teuer finde ich persönlich relativ, wenn ich mir anschaue, was sowas von anderen Firmen kostet. Gut, dass ist dann zwar nicht proprietär (z.B. KNX-RF), aber teuer ist es auch. Der Vorteil einer eigener Firmware wäre hier für mich, dass ich halt sofort alles an Hardware habe. Ich muss keine Platinen machen lassen, keine Bauteile bei Farnell oder anderen Distris besorgen, bei denen man als Otto-Normal-User nicht bestellen kann. Dann das Löten dieser kleinen Bauformen, etc. Wenn ich da die Zeit und auch das Geld betrachte, komme ich vermutlich mit einer neuen Firmware schneller zum Ziel, da ich ja schon etwas zum Spielen habe. Wenn ich auf dieser Hardware-Basis anfinge, wäre ja selbst bei einem späteren Schwenk zu einer "Open-Source-Hardware" nichts verloren. Vor allem, wenn der gleiche Transceiver zum Einsatz kommt. Aber Eure Busware-Seiten kannte ich noch gar nicht. Sehr interessant! Ich habe hier noch einen Energy-Sensor ES1 von Conrad rumfliegen. Der hat auch ein extra Platinchen mit Sende-Funkmodul. Das habe ich runtergelötet, weil ich auch überlegt hatte, dort "einfach" ein anderes Funkmodul dran zu hängen. Eine Firmware für den AVR habe ich auch schon zusammen geschustert, so dass ich die Leistungsaufnahme eines angeschlossenen Gerätes messen kann. Fehlt halt "nur" noch der Funk. Ich habe hier noch div. Zigbee-Module (u.a. ZigBit) rumfliegen. Wenn ein 802.15.4 Modul, dann nur noch mit 6LoWPAN (mittels Contiki). Gruß Christan
Ich bin auch voll der Fan von Hardware die schon fertig ist. (Das Problem beim CC ist zudem, dass der nur gut mit anderen CC's kann, wenn man die coolen Features der fast automatischen Datenübertragung nutzen will. Bei ZigBee regelt das der Standard) Genau deshalb steckt auch in unserem CUL so ein CC. Der kann mit den HomaticDevices reden aber auch natives AM um die Vorgänger zu bedienen. Heisst: an der Hardware soll es nun nicht scheitern. Frage ist eher: Gibts ein offenes Protokoll, was man dann einfach implementiert? Was ist mit: http://de.wikipedia.org/wiki/Z-Wave ?
Z-Wave ist alles andere als offen! Ist faktisch so wie mit Homematic. Es kommt eigentlich alles nur von einem Chip-Hersteller. Im Internet findet man kaum technische Details darüber. Darauf würde ich auf keinen Fall setzen. Es könnte ruhig etwas eigenes sein, da es ja Open-Source sein soll. Hauptsache es bleibt schlicht und einfach. Ich fänd's halt cool, wenn die untere(n) Protokollschicht(en) möglichst unabhängig vom Sensor-/Aktortyp blieben. So könnte jeder dieses Protokoll benutzen. Ich finde es immer grausam zu sehen, dass applikationsspezifische Dinge in unteren Protokollschichten auftauchen. Ideal wäre so etwas, wie es bei vielen Dingen schon gemacht wird: Es gibt Applikationsobjekte, deren Attribute man lesen und schreiben kann. Dazu definierte Datentypen (Uint8, Strings, Float, etc.) Mehr nicht. Es bleibt dann dem jeweiligen Entwickler überlassen, wie dieses Objekt aussieht und welche Attribute es bereit stellt. Evtl. könnte man noch sowas wie ein einfaches Profil definieren, das zwingend notwendige Objekte und deren Attribute vorschreibt. So läuft es bei Zigbee (Zigbee Cluster Library). ABER: Alles viel viel abgespeckter!
Also ist die Frage eher: Welches Protokoll ist es wert implementiert zu werden. ;) Es kann und sollte auch auf anderen Medien/Kabeln laufen. Ich hatte immermal vor alles per Jabber und Messages zu machen, weil im Prinzip ja alles Events sind. Kleine BOTs können dann die Steuerung, so nötig, übernehmen ... Per Publish&Subscribe können die sich die relevanten Events abonieren. Wenn man sich darauf einläßt hat man schon ein Protokoll, muß es natürlich "binarisieren" ... Schicke eine Nachricht per Jabberclient aus dem Büro an: Heizung@beiTOSTi.zuHause T> wie geht? H< alles ok, 18 Grad T> Vorlauf: 28 Grad H< Ok auf dem Medium, Kabel oder Air natürlich etwas gepackter ...
Hallo Dirk, klaro. Es sollte auf allen Medien laufen. Das was Du mit Jabber beschreibst, ist für mich aber schon wieder eine der oberen Protokollschichten, bzw. die Oberste. Dieses könnte man ja ohne Probleme mit dem objektorientierten Ansatz lösen. Es gäbe dann halt ein Reporting-Objekt, dass Deine Jabber-Dinge sprechen könnte und das auch Publish&Subscribe unterstützt. Bei Zigbee läuft es ähnlich. Zusätzlich zu ReadAttribute und WriteAttribute gibt es dort noch so etwas wie SetReportingAttribute. Damit kann ein Attribut eines Objekts automatisch Sendungen vornehmen. Aber gut.... Mir geht es erstmal darum, wie baut man die unterste Schicht am besten auf? Addressierung? Message-Counter? Verschlüsselung mit Hinblick auf Replay-Sicherheit? Wie bekommt man das unter einen Hut mit Broadcast-Messages, etc. Über die Payload, die dann übertragen werden soll, kann man sich immer noch unterhalten. Hintergrund dabei ist: wenn die neue "Open-Source-Firmware" z.B. die Verschlüsselung nicht besser macht hinsichtlich Replay-Manko, dann kann ich auch bei der Homematic-Firmware bleiben und deren System benutzen (mal unabhängig von ideologischen und finanziellen Überlegungen). Gruß Christian
Ok, dann fangen wir unten an zu "stormen": aus Beitrag "Funkübertragungen verschlüsseln" der Vorschlag: http://de.wikipedia.org/wiki/CCMP Wie man ggfs. Schlüssel tauscht (und wo speichert) muß man sehen ... AES ist ohnehin cool, da von den neuen XMegas nativ unterstützt (falls man doch selbst löten will).
Das dachte ich doch: alles schon erfunden! Fragt sich nur wieso sich ELV so immun verhält und auf XOR setzt? Auch egal, wollen wir ja gerade für die lösen :) Also das ist Transport-Level ... Gibts echt nix fertiges für dden Payload? Wie wärs mit einfachen C-"unions": LEN,TYPE,DATA...
Für die Payload schlage ich grob sowas vor:
1 | typedef struct |
2 | {
|
3 | unsigned int direction:1; |
4 | unsigned int disableDefaultResponse:1; |
5 | unsigned int reserved:6; |
6 | } payloadControl_t; |
7 | |
8 | typedef struct { |
9 | uint8 objectId; |
10 | uint8 transActionSequencenum; |
11 | uint8 commandId; |
12 | } payloadHeader_t; |
13 | |
14 | /* ReadAttributeCommand: right after the payload header */
|
15 | typedef struct |
16 | {
|
17 | uint16 attrID; // attribute ID |
18 | uint8 dataType; // expected attribute data type |
19 | } ReadAttributeCommand_t; |
20 | |
21 | /* WriteAttributeCommand: right after the payload header */
|
22 | typedef struct |
23 | {
|
24 | uint16 attrID; // attribute ID |
25 | uint8 dataType; // attribute data type of following data |
26 | uint8 data[]; |
27 | } WriteAttributeCommand_t; |
28 | |
29 | /* Response to command: right after the payload header */
|
30 | typedef struct |
31 | {
|
32 | uint8 status; |
33 | } Response_t; |
34 | |
35 | /* Payload directions (Requester->Responder, Responder->Requester) */
|
36 | #define DIR_REQ_RSP 0x00
|
37 | #define DIR_RSP_REQ 0x01
|
38 | |
39 | /* Data Types (from ZCL) */
|
40 | #define DATATYPE_NO_DATA 0x00
|
41 | #define DATATYPE_DATA8 0x08
|
42 | #define DATATYPE_DATA16 0x09
|
43 | #define DATATYPE_DATA24 0x0a
|
44 | #define DATATYPE_DATA32 0x0b
|
45 | #define DATATYPE_BOOLEAN 0x10
|
46 | #define DATATYPE_BITMAP8 0x18
|
47 | #define DATATYPE_BITMAP16 0x19
|
48 | #define DATATYPE_BITMAP24 0x1a
|
49 | #define DATATYPE_BITMAP32 0x1b
|
50 | #define DATATYPE_UINT8 0x20
|
51 | #define DATATYPE_UINT16 0x21
|
52 | #define DATATYPE_UINT24 0x22
|
53 | #define DATATYPE_UINT32 0x23
|
54 | #define DATATYPE_INT8 0x28
|
55 | #define DATATYPE_INT16 0x29
|
56 | #define DATATYPE_INT24 0x2a
|
57 | #define DATATYPE_INT32 0x2b
|
58 | #define DATATYPE_ENUM8 0x30
|
59 | #define DATATYPE_ENUM16 0x31
|
60 | #define DATATYPE_SEMI_PRECISION 0x38
|
61 | #define DATATYPE_SINGLE_PRECISION 0x39
|
62 | #define DATATYPE_DOUBLE_PRECISION 0x3a
|
63 | #define DATATYPE_OCTET_STRING 0x41
|
64 | #define DATATYPE_CHAR_STRING 0x42
|
65 | #define DATATYPE_TIME 0xe0
|
66 | #define DATATYPE_DATE 0xe1
|
67 | |
68 | /* Command ID */
|
69 | #define COMMAND_READ_ATTRIBUTE 0x01
|
70 | #define COMMAND_WRITE_ATTRIBUTE 0x02
|
71 | |
72 | /* ------------------------------------------------------*/
|
73 | /* internal object representation */
|
74 | /* ------------------------------------------------------*/
|
75 | |
76 | /* Access Control Bitmask */
|
77 | #define ACCESS_CONTROL_READ 0x01
|
78 | #define ACCESS_CONTROL_WRITE 0x02
|
79 | |
80 | typedef struct { |
81 | uint16 attributeId; |
82 | uint8 dataType; |
83 | uint8 accessControl; |
84 | void *dataPtr; /* Pointer to "normal" program variable */ |
85 | } attributeRecord_t; |
86 | |
87 | typedef struct { |
88 | uint8 objectId; |
89 | uint16 numAttrbutes; |
90 | attributeRecord_t attribute[]; |
91 | } objectRecord_t; |
92 | |
93 | #define OBJECT_ID_SYSTEM 0x01
|
94 | #define OBJECT_ID_LIGHTCONTROL 0x02
|
95 | #define OBJECT_ID_HEATING 0x03
|
96 | |
97 | /* OBJECT_ID_SYSTEM attributes */
|
98 | #define OBJ_SYSTEM_ATTR_NAME 0x0001
|
99 | |
100 | /* OBJECT_ID_LIGHTING attributes */
|
101 | |
102 | /* OBJECT_ID_HEATING attributes */
|
Oh, payloadHeader_t müsste so aussehen:
1 | typedef struct { |
2 | payloadControl_t pC; |
3 | uint8 objectId; |
4 | uint8 transActionSequencenum; |
5 | uint8 commandId; |
6 | } payloadHeader_t; |
Alles basierend auf Zigbee-Prinzipien. Aber stark ausgedünnt.
Na los ... ich bin dabei. Was brauchen wir an Hardware? Ich denk' UARTs tun es für einen Anfang. Geht ja vorerst ums Protokoll ... Wo hosten wir das? Ganz wichtig: Hast' schon einen Namen dafür ;)
:-) Ich würde prinzipiell erst noch etwas mehr dokumentieren bzw. konzeptionieren. Ein Wiki wäre dafür am besten. Sourceforge, BerliOS? Die oberen Schichten sind für mich inzwischen recht klar vor Augen. Ich persönlich lege bei den unteren Schichten den Fokus auf Funk. Zum Testen der oberen Schicht würde die Entwicklung auch auf einem PC reichen. Man könnte es ja in UDP-Pakete packen und einen UDP-Treiber vorsehen, der über Sockets läuft. Ich mache mir momentan noch eher Gedanken, wie ich das vernünftig mit dem Funk und seinen Widrigkeiten hinbekomme. Vor allem mit der Verschlüsselung. Passt das überhaupt in die kleinen Controller alles rein?
Also den CC1101 kannst Du als Socket oder serielles Interface idealisieren (Paket basiert). Praktisch wird in eine FIFO geschrieben, LEN, DATA ... dann TX-Strobe ... und die andere Seite(n) melden sich mit INT bei empfangenen Daten und CRC ok (macht er selbst). UDP-Broadcasts treffen es am ehesten. Wiki kann ich bei busware.de bieten ... Code bei Google? BerliOS macht cvs, das ist mir lieber!
Öhm. Was ist Dir jetzt lieber? Code bei Google oder bei Berlios, weil Berlios CVS bietet? Würde SVN bevorzugen. :-)
Lieber Dirk, willst du nicht erst einmal 1 Projekt richtig fertig machen? Ich meine, nicht nur Layout, sodass es auch "benutzbar" ist. DMX, FS20, EIB, Freebus, Freebus über USB .... Jetzt CC.... Ich zweifel ein wenig, oder schreibe, dass ich mich irre.
Ich dachte gerade darüber nach als einfachen Test mal KNX-RF draufzuspielen, die HW sollte das locker können. Jedoch: Kann es sein, daß KNX-RF komplett unverschlüsselt ist?
Was haltet ihr vom one-net protokoll ? Ist verschlüsselt open-source und unterstützt verschiedene Funkchips. www.one-net.info www.one-net.info/spec Harald
Wurde dieses Projekt eigentlich weitergeführt, oder ist es wie viele Andere auch im Sande verlaufen ???
Christian schrieb: > Ich muss keine Platinen machen lassen, > keine Bauteile bei Farnell oder anderen Distris besorgen, bei denen man > als Otto-Normal-User nicht bestellen kann. Nur so nebenbei, bei Farnell kannst du als Privatperson über den hbe-Shop bestellen.
Klaus M. schrieb: > Wurde dieses Projekt eigentlich weitergeführt, oder ist es wie viele > Andere auch im Sande verlaufen ??? Also ich habe nach der Ideenphase nicht mehr weitergemacht. Es war einfach in absehbarer Zeit nicht vernünftig machbar. Aktuell gibt es ja CUL und FHEM. Für viele Dinge reicht das erstmal. Eine eigene Firmware schien also nicht nötig zu sein. Allerdings 1) finde ich die Idee natürlich immer noch recht interessant. 2) hat das AES-Signing in manchen HM-Komponenten wohl einen Bug, so dass sich Schaltzustände ändern lassen, obwohl Authentizität nicht gewährleistet ist Mit dem CUL von Dirk wäre ja jetzt immerhin eine vernünftige Schnittstelle zum PC/Embedded System per USB vorhanden, so dass man die Zentrale nicht mehr bräuchte. Vielleicht sollte man wirklich nochmal anfangen, eine alternative offene Firmware für HM-Komponenten zu entwickeln. Für mich wäre die Sicherheit auf jeden Fall sehr wichtig. Es muss von Anfang an sichergestellt sein, dass nur berechtigte Geräte Aktionen ausführen können. Von daher ist es schon löblich, dass EQ3 hier sowas bedacht hat (AES Signing). Außerdem finde ich es sehr gut, dass Sensoren und Aktoren direkt miteinander kommunizieren (können). Beim Ausfall der Zentrale funktioniert der Lichtschalter dann nämlich immer noch (im Gegensatz zu vielen anderen Systemen). Meines Erachtens wurde die Sicherheit bei vielen heutigen Funk-Systemen völlig vernachlässigt! Das Disaster wird dann irgendwann mal in der Zukunft folgen, wenn die ersten FS20, KNX-RF-Hacker durch die Gegend fahren und Unfug treiben. ;-)
Wenn ihr wirklich was offenes flexibles und professionelles sucht, dann schaut euch mal die embedded pcs und das busklemmensystem von beckhoff an. http://www.beckhoff.de/german/embedded_pc/cx5010_cx5020.htm http://www.beckhoff.de/german/bus_terminal/digout.htm
Schade, wohl wieder einmal etwas im Sande verlaufen :-(
Offenbar ist wirklich etwas in Arbeit: http://forum.fhem.de/index.php?t=msg&goto=56768&rid=0 Dort wird ein Funk-Bootloader für den Zwischenstecker-Schaltaktor beschrieben. Bin ja mal gespannt, was da noch so kommt.... Achja, zur Kommunikation benötigt man dann wohl ein CUL-Modul.
Moin,
ich hab da heute mal ein bisschen rumgefummelt, wie ich löten hasse...
Basis ist ein Unterputz-Schaltaktor (den ich gerne als Sender für eine
Hue Lampe nutzen möchte, was mit der Standard-Firmware nicht geht...)
Verbunden via BusPirate auf die SPI Ports (die 6 Lötkontakte).
Funktioniert soweit, allerdings noch ziemlich Beta. Spricht kein BidCos,
sondern ein einfaches eigenes Protokoll (CA FE 01 SEQ[0..7] SEQ[8..15]
CMD A B C), CMD z.b. F0 für button, dann A=button, B=state, C=toggle
counter.
Die Kommandos können mit CUL, HM-LAN-CFG etc. empfangen/gesendet werden.
Kompilieren/Flashen mit:
avr-gcc -mmcu=atmega644 -Os -funsigned-char -funsigned-bitfields
-fpack-struct -fshort-enums -fdata-sections -ffunction-sections \
-Wall -Wstrict-prototypes -Wundef -std=gnu99 -Wl,--gc-sections
test.c -o test.elf && \
avr-objcopy -O ihex test.elf test.hex && \
avrdude -P /dev/tty.usbserial-AD01W21E -c buspirate -p m644 -U
flash:w:test.hex:i
Hallo Moritz, ich habe Deinen Beitrag leider gerade erst gesehen. Ich habe mich diesem Thema (Alt. FW) auch wieder angenommen. Aktuell betreibe ich hauptsächlich Dokumentation von vorhandener Hardware: https://github.com/ccier/openhm/wiki Das Wiki sollte für jeden editierbar sein. Den Anfang macht bei mir der Schaltaktor PSS von RWE: https://github.com/ccier/openhm/wiki/PSS Als Firmware benutze ich diese hier: http://code.google.com/p/panstamp/ Eine Unterstützung von panStamp wird auch gerade bei FHEM eingebaut: http://forum.fhem.de/index.php?t=msg&goto=76489&rid=0 Die FW für die AVRs habe ich als Atmel Studio 6 Solution/Projekte erstellt und verwende dabei auch die Arduino CoreLib (libcore.a), die ich mit der Atmel AVR Toolchain kompiliert habe. Der SWAP-Stack von panStamp baut auf dem Arduino Core auf. Gruß Christian
Hallo Christian. Ich wollte ein TRX868 Modul mit Arduino UNO verbinden und dann die SWAP SW von PanStamp darauf flashen. Müßte doch gehen... Als Gegenstation habe ich eine Fritzbox 7390 mit FHEM und HMlan adapter. Frage: geht der HMlan adapter für SWAP oder muss ich einen CUL adapter haben? ...kämpfe aber gerade noch heftig mit Atmel Studio6. Die libcore.a habe ich jetzt.
Ein TRX868 mit Arduino geht natürlich. Ich habe hier einen 3.3V-Wattuino +TRX868 und betreibe beides mit SWAP. Einen HMLAN-Adapter kannst Du nicht benutzen. CUL wird erst gehen, wenn Du die SWAP-Unterstützung einbaust. Nimm doch lieber einen zweiten Arduino mit noch einem TRX868. Oder den panStick. Das ist dann Dein Gateway (wie bei HMLAN oder CUL). Du müsstest dann nur die panStamp-Modem-Firmware nehmen.
> Moin, > > ich hab da heute mal ein bisschen rumgefummelt, wie ich löten hasse... > > Basis ist ein Unterputz-Schaltaktor (den ich gerne als Sender für eine > Hue Lampe nutzen möchte, was mit der Standard-Firmware nicht geht...) > > Verbunden via BusPirate auf die SPI Ports (die 6 Lötkontakte). > > Funktioniert soweit, allerdings noch ziemlich Beta. Spricht kein BidCos, > sondern ein einfaches eigenes Protokoll (CA FE 01 SEQ[0..7] SEQ[8..15] > CMD A B C), CMD z.b. F0 für button, dann A=button, B=state, C=toggle > counter. > > Die Kommandos können mit CUL, HM-LAN-CFG etc. empfangen/gesendet werden. > > Kompilieren/Flashen mit: > avr-gcc -mmcu=atmega644 -Os -funsigned-char -funsigned-bitfields > -fpack-struct -fshort-enums -fdata-sections -ffunction-sections \ > -Wall -Wstrict-prototypes -Wundef -std=gnu99 -Wl,--gc-sections > test.c -o test.elf && \ > avr-objcopy -O ihex test.elf test.hex && \ > avrdude -P /dev/tty.usbserial-AD01W21E -c buspirate -p m644 -U > flash:w:test.hex:i Hallo zusammen, ich stehe vor dem Problem, dass meine Dimmaktoren eine alte Firmware installiert haben. Nun würde ich gerne die Firmware von einem neueren Aktor einspielen, ohne das alle zu EQ3 eingesendet werden müssen. Wenn ich das richtig verstanden habe müsste ich mit dem BusPirate die bestehende auslesen und dann mit der angepassten Seriennummer auf den "alten" Dimmer wieder flashen können. Richtig oder Falsch ?
@Roger: ich glaube kaum, dass Du irgendeine Firmware auslesen kannst. Die werden alle kopiergeschützt sein. Da müsstest Du schon selbst eine schreiben.
Hallo Zusammen, ich habe mal angefangen das HM Protokoll für Arduino's verfügbar zu machen. Falls jemand interessiert ist, findet ihr hier den Entwicklungs Thread. http://forum.fhem.de/index.php/topic,14140.0.html Viele Grüße trilu
Hi, ich habe die Library von trilu auf den oben genannten Aktor portiert. Wer Interesse hat kann das ganze gerne ausprobieren und mitwirken: https://github.com/jabdoa2/Asksin_HM_LC_Sw1PBU_FM Gruß, Jab
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.