Hallo, CAN glaube ich grundsätzlich verstanden zu haben. Bei den Überlegungen zu einem Hausbusprojekt bin ich jetzt am Punkt der Festlegung von CAN-IDs. Mit dem Standard 2.0A (Also 11 bit identifier) sollte ich da auskommen. Das MSB der CAN-ID will ich für hochpriore Telegramme nutzen. Bleiben noch 10 bit. Die nächsten 5 bit sollen den CAN-Knoten selbst identifizieren => 32 eindeutige Knoten. Bleiben noch 5 bit für Informationen => 32 Möglichkeiten. Als Bild siehe Anhang. Damit lassen sich bei mir wohl 95 % des CAN-Verkehrs mit Telegrammen ohne Nutzdaten (DLC 0 byte) lösen (als Information z.B. "Bewegungsmelder_aus", bleiben noch 31 weitere mögliche Informationen). Und nun die Frage: Das ist ja jetzt ein sehr kleines Projekt und wird so funktionieren. Zumal hier auch kaum ID-Filter gebraucht werden. Aber ist das grundsätzlich der richtige Weg in echten/größeren Projekten? CANopen ist mir bekannt; sowas meine ich nicht. Wie bei allen Projekten muß man sich ja erstmal Gedanken machen und nicht einfach drauflosprogrammieren.
Angehängte Dateien:
Furz schrieb: > Die nächsten 5 bit sollen den CAN-Knoten selbst identifizieren => 32 > eindeutige Knoten. Das brauchst du eigentlich nicht. CAN ist ein Message-basiertes Protokoll, da ist es egal, wer die Nachricht sendet oder empfängt; auf den Inhalt kommt es an. Also z.B. Identifier 35 ist Fenster Schlafzimmer offen und Identifier 36 ist Fenster Schlafzimmer zu. 37 ist Türe SZ offen und 38 Türe SZ zu. Man kann die Zustände allerdings auch in den Daten verstecken: ID 35 ist Schlafzimmer, Data 1 ist Türe offen, Data 2 ist Türe zu, Data 3 ist Fenster offen und Data 4 Fenster zu. Welcher Sensor was sendet, ist dann egal, es kommt auf die Messages an. Und wie du schon festgestellt hast, verwendet man normalerweise die ID, um die Priorität der Nachricht festzulegen. Allerdings sollte (darf) es nur einen Sender pro ID geben, sonst gibt es Kollisionen.
1. Bei meinem Hausbus kommen allein von der Zentralheizung so viele verschiedene Daten zusammen, dass ich mich entschieden habe, alle Sensorwerte textuell als JSON-Objekte zu übermitteln. 2. Ich verteile auch neue Software über CAN auf die Knoten. Wenn du ähnliche Anforderungen haben könntest, dann solltest du das u.U. in deinem Id-Konzept berücksichtigen. LG, Sebastian
@Helmut Danke. Die Grundlage, daß die CAN-ID den Inhalt des Telegramms beschreibt, ist mir bekannt. Irgendwie kann ich meine Frage nicht verständlich formulieren. Meine Frage zielt eher einen Schritt später auf den Fall ab, wie in einem "größeren" System die Anzahl der zur Verfügung stehenden Filter am effizientesten ausgenutzt wird. Ein simpler Sensorknoten ist da ja nicht das Problem, sondern eher der "Master" (den es ja nicht gibt, ich weiß). Gemeint ist eher z.B. der Pi, der die allermeisten Telegramme auch lesen und verarbeiten muß. Man kann ihn natürlich per Filter einfach alle Telegramme akzeptieren lassen. Und dann in einer riesigen switch-Anweisung weiterverarbeiten?
1 | switch (CAN-ID) |
2 | {
|
3 | case 35: printf("Fenster Schlafzimmer wurde geöffnet"; break; |
4 | case 36: printf("Fenster Schlafzimmer wurde geschlossen"; break; |
5 | ...
|
6 | }
|
Ich stelle mir das so vor, daß z.B. - Schlafzimmer beginnt immer mit CAN-ID 0b011000. - Wohnzimmer beginnt immer mit CAN-ID 0b011001 Die nächsten 5 bit codieren dann z.B. "Fenster geöffnet", "Fenster geschlossen" usw.. Dann könnte ich nach dem Ort filtern, aber auch nach "Fenster geöffnet". Also grundsätzlich irgendwelche (für mich) logischen Gruppen bilden. Oder macht man es in großen Systemen anders? Ich will da eher die Grundlagen des logischen "Designs" eines größeren Netzes verstehen. Und da ist die CAN-ID ja das Schlüsselelement. @Sebastian Ja, Update via CAN habe ich auch vor. Das soll einer der o.g. 32 möglichen "Informationen" sein. Ich habe nur Angst, daß mein System wächst und ich mit dem o.g. Design dann an die Wand fahre und ein komplett neues KOonstrukt der CAN-IDs machen müßte. Das ist der Hintergrund meiner Frage.
Schwierig schrieb: > Die nächsten 5 bit codieren dann z.B. "Fenster geöffnet", "Fenster > geschlossen" usw.. ?? Eine CAN-MSG hat nicht nur die ID, sondern im Standard-CAN auch bis zu 8 BByte Daten. Informationen, ob ein Fenster geschlossen wird oder geöffnet gehören ins Datenfeld, nicht in die ID. Prinzipiell kann man versuchen eine Systematik in die IDs zu bringen, nötig ist das nicht. Man muss nur seine verwendeten gut dokumentieren. Die Priorisierung ist manchmal praktisch, wird aber oft auch überschätzt. Solange die Buslast rel. gering bleibt kommt eh so gut wie alles im 1.Versuch an. Und wenn es ne wenige ms später wird spielt bei dem was du vorhast keine Rolle.
Oder Du die Frage nicht. Er WILL es in den Identifier bauen um sich das lesen zu ersparen.
Alexander schrieb: > Oder Du die Frage nicht. Er WILL es in den Identifier bauen um sich das > lesen zu ersparen. Schwierig schrieb: > Bleiben noch 5 bit für Informationen => 32 Möglichkeiten. Man kann sich auch von hinten durch die Brust in Auge schießen... Adressen zum Transportieren von Daten zu verwenden, obwohl im Protokoll extra Datenbytes vorgesehen sind, ist widersinnig. Kann man machen, sieht aber aus, als hätte da jemand was doch nicht verstanden.
Richtig. Es soll natürlich möglichst effizient sein, also so wenig Bits über den Bus wie nötig. Das ist hier zwar überhaupt nicht nötig, aber mir geht es hier um die Designstrategie bei grôßeren Netzen. Ich kann bei > 32 Informationen später auch auf 29 Bit (2.0B) erweitern,weiß ich. @Max Schön, daß du auch was konstruktives beigetragen hast...
@Rahul Kann man drüber streiten, will ich aber nicht. Ein Datenfeld kann/muß man zusätzlich nutzen, wenn man Variablen (z.B. Temperatur) übertragen will. Eine Statusänderung braucht es nicht. Das spart Bits und damit auch Zeit. Auch das meine ich mit Designstrategie
:
Bearbeitet durch User
> Die Grundlage, daß die CAN-ID den Inhalt des Telegramms > beschreibt, ist mir bekannt. > sondern eher der "Master" (den es ja nicht gibt, ich weiß). Wenn du das doch alles weißt, dann löse dich gedanklich auch von diesem falschen Verständnis von Mastern, CAN-IDs für Empfänger, etc. > Das MSB der CAN-ID will ich für hochpriore Telegramme nutzen. Das ist Unsinn. Mit wievielen Hoch-Prio-Nachrichten rechnest du denn? 50 Stk? Dann reserviere die CAN-IDs 1-127 für diese. > - Wohnzimmer beginnt immer mit CAN-ID 0b011001 > Die nächsten 5 bit codieren dann z.B. "Fenster geöffnet", "Fenster > geschlossen" usw.. Falsches Konzept: Die Nutzinformationen wie "Fenster sofort öffnen" und "Fenster offen" gehören nicht in die ID sondern in die Datenbytes. > CAN glaube ich grundsätzlich verstanden zu haben. Beim Lesen zweifle ich etwas.
Schwierig schrieb: > Man kann ihn natürlich per Filter einfach alle > Telegramme akzeptieren lassen. Und dann in einer riesigen > switch-Anweisung weiterverarbeiten? Ja, warum nicht? Alternativ geht auch ein Array aus Funktionszeigern. > switch (CAN-ID) > { > case 35: printf("Fenster Schlafzimmer wurde geöffnet"; break; > case 36: printf("Fenster Schlafzimmer wurde geschlossen"; break; > ... > } Ich würde hier eher z.B. ID 35 als "Status Schlafzimmerfenster" definieren und dann in den Nutzdaten übertragen, welchen Status es hat. Außerdem werden CAN-Botschaften meist eher zyklisch übertragen. Wenn du immer nur beim Zustandswechsel eine einzelne CAN-Botschaft versendest und die verloren geht oder mal der Strom ausfällt und keiner mehr was vom Zustand aller anderen weiß, bekommt der Empfänger den neuen Zustand erst wieder beim nächsten Wechsel mit. Bei zyklischer Übertragung (+ sofort bei einer Änderung) synchronisiert sich der Status immer automatisch. Schwierig schrieb: > Richtig. Es soll natürlich möglichst effizient sein, also so wenig Bits > über den Bus wie nötig. Das macht nicht so viel Unterschied, weil eine CAN-Botschaft recht viel Overhead hat. Ein Nutzdatenbyte mehr ist da nicht wirklich viel. Abgesehen davon funktioniert das nur, wenn du wirklich nicht mehr als nur ein einziges Bit übertragen willst. Im Gegenzug "explodiert" die Zahl der nötigen CAN-IDs. Wenn dein Fenster mal nicht nur "offen" und "geschlossen", sondern auch "gekippt" sein kann oder der Jalousien-Status dazu kommt, brauchst du haufenweise CAN-IDs, um das alles abzubilden, statt einfach eine ID für "Status Fenster Schlafzimmer" und ein Nutzdatenbyte, das alle Status-Informationen enthält. > Das ist hier zwar überhaupt nicht nötig, aber mir geht es hier um die > Designstrategie bei grôßeren Netzen. Du kannst davon ausgehen, dass sonst keiner das so macht, wie du es planst.
:
Bearbeitet durch User
Schwierig schrieb: > Eine Statusänderung braucht es nicht Ein einziges Bit sind auch Daten... Deine Idee wird dich halbwegs zwangsweise in den Wahnsinn treiben. Prinzipiell kann es mit sehr eingeschränktem Umfang so funktionieren wie du das planst, sinnvoll wird es nicht. Und das Effizienzgeschwurbel ist völliger Quark, rechne dir mal die Prozente Gewinn aus.... Im Gegenzug dafür erhälst du ein völlig kastriertes Sytem. Wirst du wohl alleine zu Ende bringen müssen.
Die Vorredner haben es ja alle schon formuliert, Du hast dich komplett verrannt. Als jemand, der seit ca. 30 Jahren beinahe täglich mit dem CAN-Bus zu tun hat, tränen einem wirklich die Augen bei dem Konzept. Es fängt schon bei dem Prio-Bit an, bereits das führt das CAN Konzept ad absurdum. Gerne kannst Du alles so machen, die Du es möchtest. Aber wenn Du schon hier nachfragst, wirst Du vermutlich nicht beratungsresistent sein (wollen). Wenn Du es einfach halten willst ist die ID der Teilnehmer und die Information gehört in das Datenfeld. Jedes Gerät bekommt evtl. noch 2..3 weitere IDs im höheren ID Bereich z.B. für Firmware-Updates. Prioritäten benötigst Du bei einem Hausbus nicht, die Verlagerung von z.B. Firmware-Update-IDs in den oberen Bereich sorgt schon dafür, dass nicht einmal solche Updates die Performance in keinem Augenblick gefährden. Das mit den Firmware-Updates kann ja erstmal ein gedankliches Konzept bleiben, man muss es nicht direkt umsetzen. Und wenn Du ein netter Mensch bist, denke insbesondere bei einer solchen Infrastrukturmaßnahme an deine Nachfolger bzw. Erben und gestalte es so, dass man es wieder zurück bauen kann. Klar, kann einem selbst grundsätzlich völlig schnurz sein, nachhaltig ist dann aber etwas anderes. In diesem Sinne ist dein eigenes älteres Ich auch schon als Nachfolger zu sehen.
:
Bearbeitet durch User
Wie schon oben mehrfach erwäht ist es keine so super Idee nur mit der CAN-ID zu arbeiten. Als erstes müsstest du wissen dass tiefere CAN ID's (kleinere Nummern) höher priorisiert über den Bus übertragen werden. Dann würde ich das Telegram so aufbauen (11 Bit) 10: 0=Wichtig / 1=Unwichtig 9..5: CAN Konten (damit könnte man 32 Devices haben) 4..0: Telegram je Knoten. (32 unterschieldiche) Dann hätte man noch 8 Bytes Daten, das würde ich auf Addr 0 bei "Telegram je Knoten" legen 0..3: bis zu 4 Bytes Daten (Bit, Byte, Integer, Float Werte) 4..5: 2 Bytes für eine Parameternummer 6: 1 Byte mit Info über Typ der Daten, Gültigkeit der Daten, oder Bit der Leseanforderung 7: 1 Byte Reserve Die anderen 31 "Telegram je Knoten" würde ich für indivituelle Telegramme nutzen, indem man bis zu 8 Byte (64 Bit) an Infos gleichzeitig übertragen kann. Mit deiner ID Basierten Übertragung wären bei z.B. 64 Senoren 64 CAN Telegramme nötig, das kann man bequem in 64 Bit eines einzigen CAN Telegramms rein bekommen. Somit kann das Haus Projekt mit der Zeit wachsen und man hat noch genügend "Luft" nach oben. Ich kenne selbst gebaute Haus Projekte die haben mehrere huntert Werte, Temperaturen usw. zum Austauschen. Da würde dein Prinzip schon zusammen brechen und du müsstest alles von 0 beginnend neu erfinden. Daher mache es gleich richtig.
:
Bearbeitet durch User
Es gibt jede Menge mögliche Design-Philosophien, wie man CAN-IDs definieren kann. Z.B. die klassische Methode als Message Identifier (wie z.B. im Auto): Hier werden verschiedenen Nachrichten eine ID zugeteilt. Die Nachricht wird von einem Busteilnehmer gesendet und alle anderen Teilnehmer entscheiden anhand der ID, ob der Inhalt der Nachricht sie interessiert (z.B. Message-ID 0x23: Fahrzeuggeschwindigkeiten, Message-ID 0x24: Motordrehzahl, Message ID 0x82: Umgebungstemperatur). Die ID hat also weder mit dem Sender noch mit dem Empfänger direkt zu tun. Der gegenteilige Ansatz ist es, Sender und/oder Empfänger in die ID zu kodieren. Damit kann man dann Topologien definieren, die anderen Bussystemen wie z.B. KNX entsprechen. Die Daten der Nachricht enthalten dann in der Regel einen Befehl mit dazu gehörenden Parametern. Also z.B. MessageID 0x64: Sender 6 (Lichtschalter) schickt an Empfänger 4 (Lampe) eine Nachricht, in der dann z.B. steht, dass das Licht auf 50% gedimmt werden soll. In der Regel sind hier dann aber 11 Bit nicht ausreichend und das extended Format (29 bit) wird verwendet. Und dann gibt es noch alle Möglichkeiten dazwischen, inklusive dynamischer Vergabe der Adressen beim Start des Systems (oder Hinzufügen von Komponenten während der Laufzeit). Wichtig ist, die für die eigene Anwendung sinnvolle Definition zu finden. Dabei ist ein entscheidender Faktor, dass CAN Controller die Möglichkeit haben, beim Empfang auf die ID (oder bestimmte Teile davon) zu filtern. Dadurch müssen nicht alle Botschaften von jedem Teilnehmer von der Software ausgewertet werden, was eine erhebliche Einsparung an Ressourcen bedeutet.
Ihr, die ihr alle gegen mein Konzept seid, habt doch alle keine Ahnung davon. Nur ich habe als einziger Ahnung davon. Da die Wahrscheinlichkeit, daß viele einer Meinung, und nur einer seiner Meinung ist, ist nicht so hoch. Also wird es wohl leider auch nicht stimmen... Thomas F. schrieb: >> Das MSB der CAN-ID will ich für hochpriore Telegramme nutzen. > Das ist Unsinn. Mit wievielen Hoch-Prio-Nachrichten rechnest du denn? 50 > Stk? Dann reserviere die CAN-IDs 1-127 für diese. Mit einer Handvoll. Das MSB mit 1048 bit dafür zu opfern, ist wohl eher der Einfachheit geschuldet gewesen. Sind ja noch 10 bit für den Rest da. Aber genau das ist das Problem: Mit solchen Großzügigkeiten befürchte ich, mir die Zukunft zu versauen. Rolf M. schrieb: > Schwierig schrieb: >> Richtig. Es soll natürlich möglichst effizient sein, also so wenig Bits >> über den Bus wie nötig. > > Das macht nicht so viel Unterschied, weil eine CAN-Botschaft recht viel > Overhead hat. Ein Nutzdatenbyte mehr ist da nicht wirklich viel. Wohl wahr. > Abgesehen davon funktioniert das nur, wenn du wirklich nicht mehr als > nur ein einziges Bit übertragen willst. Im Gegenzug "explodiert" die > Zahl der nötigen CAN-IDs. Wenn dein Fenster mal nicht nur "offen" und > "geschlossen", sondern auch "gekippt" sein kann oder der > Jalousien-Status dazu kommt, brauchst du haufenweise CAN-IDs, um das > alles abzubilden, Das ist auch meine Befürchtung. Harald A. schrieb: > Es > fängt schon bei dem Prio-Bit an, bereits das führt das CAN Konzept ad > absurdum. Siehe oben. Irgendeine Prio muß ja rein, und das geht bei CAN eben nur über den Identifier. War halt der faule Weg. > Gerne kannst Du alles so machen, die Du es möchtest. Aber wenn Du schon > hier nachfragst, wirst Du vermutlich nicht beratungsresistent sein > (wollen). So ist es. > Und wenn Du ein netter Mensch bist, denke insbesondere bei einer solchen > Infrastrukturmaßnahme an deine Nachfolger bzw. Erben und gestalte es so, > dass man es wieder zurück bauen kann. Eigentlich will ich nichts steuern usw., nur Informationen übertragen. Daher wäre Abschalten kein Problem. Das Wort "eigentlich" ist aber ein sehr schönes Wort. Bekanntermaßen wird es am Ende immer mehr, als man am Anfang geplant hat. Und da will ich mir nicht gleich alles verbauen. Markus M. schrieb: > Ich kenne selbst gebaute Haus Projekte die haben mehrere huntert Werte, > Temperaturen usw. zum Austauschen. Da würde dein Prinzip schon zusammen > brechen und du müsstest alles von 0 beginnend neu erfinden. Daher mache > es gleich richtig. So ist der Plan; drum frage ich. Danke an (fast) alle. Ich werde das Thema noch ein wenig bebrüten.
Noch so einer, der seine krumme Lösung gesund beten lassen will, obwohl alle Vorschläge in Zusammenschau davon weg zeigen. mfg mf
Will er doch gar nicht mehr, nicht gleich vom ersten halben Satz triggern lassen....
Jetzt erkenne ich es! Mach mal so, wie Du es geplant hat. Es wird gut.
Sebastian W. schrieb: > 1. Bei meinem Hausbus kommen allein von der Zentralheizung so viele > verschiedene Daten zusammen, dass ich mich entschieden habe, alle > Sensorwerte textuell als JSON-Objekte zu übermitteln. Kommen dabei nicht große Datenmengen (2 byte pro char) zusammen oder habe ich das falsch verstanden? Harald A. schrieb: > Wenn Du es einfach halten willst ist die ID der Teilnehmer und die > Information gehört in das Datenfeld. Jedes Gerät bekommt evtl. noch 2..3 > weitere IDs im höheren ID Bereich z.B. für Firmware-Updates. Prioritäten > benötigst Du bei einem Hausbus nicht, Eigentlich (das schöne Wort...) hatte ich das mit dem verschmähten PRIO-bit vor: Mit PRI_LOW hätte der CAN-Knoten eine höhere ID, mit PRIO_HIGH eben eine Niedrigere. Auch wenn das für dieses Projekt wohl nicht wirklich relevant ist, möchte ich das Prinzip der Priorisierung schon grundsätzlich zu Lernzwecken einbauen. Und wenn ich die beiden MSB für PRIO nehme, könnte ich auf diese Weise 4 verschiedene IDs pro Knoten erzeugen. Somit wären die PRIO-bits doch "eigentlich" nur ein Werkzeug, um systematisch diese unterschiedlichen CAN-IDs für einen Knoten zu erzeugen, oder bin ich wieder falsch abgebogen? Beim Erzeugen der CAN-ID für ein Telegramm würde ich der Funktion die gewünschte PRIO einfach als Parameter mit übergeben. Das die Idee mit den PRIO-bits wohl zu sehr beschränkend (ID-verschwendend) ist, habe ich ja gefressen. Ich plane jetzt, diese Informationen ins erste Datenfeld packen. Damit könnte ich dann schon gleich 256 Informationen kodieren.
Schwierig schrieb: > Ihr, die ihr alle gegen mein Konzept seid, habt doch alle keine Ahnung > davon. Nur ich habe als einziger Ahnung davon. Warum fragst Du dann hier?
Schwierig schrieb: > Kommen dabei nicht große Datenmengen (2 byte pro char) zusammen oder > habe ich das falsch verstanden? 2 Byte pro char vwrstehe ich nicht. Aber ja, die JSON-Nachrichten sind schnell ein paar hundert Byte groß. Zum Beispiel hier die Statusberichte zweier Knoten:
1 | {"topic":"garage","ms":685054107,"id":19212,"no":12,"sw":"t5_garage01.ino,Jul 22 2023 17:38:53,10819","hw":"iom328p.h,8000000L,8000000,SPI","bootspif":0,"cycle":11171,"tim":"23:39:07","timgotms":685047904,"ci":1,"c0t":6.2,"c0f":86.5,"c1t":13.6,"c1f":54.1,"c2t":10.4,"c2f":63.2,"c3t":13.5,"c4t":14.5,"c5t":13.8,"fan":0,"msend":685064306}
|
2 | {"topic":"haus","ms":1536189675,"id":12811,"no":11,"sw":"t5_haus02.ino,Jun 18 2022 20:57:25,10813","hw":"iom1284p.h,16000000L,8000000,SPI","cycle":25604,"valve":"ON","vflt":0,"vref":74,"vsen":37,"hlst":1,"hlms":1496210593,"hl":6,"oelus":6778,"oelmm":1162.0,"oelliter":1331.6,"S1F":38.9,"S1T":20.1,"S4F":38.9,"S4T":20.6,"S6F":83.9,"S6T":6.0,"S7F":86.9,"S7T":5.9,"S8F":41.1,"S8T":18.1,"S9F":1.0,"S9T":6.8,"VoT":44.8,"RuT":24.1,"oams":1536179675,"oems":1536181272,"Tim":"2024012201234203","AuT":8.5,"KeT":50.9,"SpT":49.3,"AuI":8.3,"AuG":7.5,"KeI":51.0,"SpI":49.4,"MaT":170.5,"BrU":0,"BrE":0,"W1A":3,"Sp1":0,"Py1":0,"Fr1":255,"SpS":50,"ci":3}
|
Solche Nachrichten brauchen dann schon einige CAN-Frames. Aber der volle Status wird pro Knoten nur einmal pro Minute gesendet. LG, Sebastian
:
Bearbeitet durch User
Schwierig schrieb: > Harald A. schrieb: >> Es >> fängt schon bei dem Prio-Bit an, bereits das führt das CAN Konzept ad >> absurdum. > Siehe oben. Irgendeine Prio muß ja rein, und das geht bei CAN eben nur > über den Identifier. Muss sie wirklich? Es wäre erst mal zu klären, was für dich Prio in diesem Fall bedeutet bzw. was du damit erreichen willst. Beim CAN ist es am Ende so, dass im Falle, dass zwei oder mehr CAN-Botschaften exakt gleichzeitig gesendet werden sollen, die mit der höheren Prio (also niedrigeren ID) durchkommt und die anderen warten müssen. Im Zweifelsfall ist also die mit der niedrigen Prio um eine Millisekunde oder so später da. Und wenn der Bus hoffnungslos überlastet sein sollte, so dass gar nicht mehr alle Botschaften durchkommen können, dann werden auch die mit höherer Prio bevorzugt.
Ich würde die Prioritäten bei CAN so nutzen dass es hardwaremäßig Sinn ergibt. Prio hoch Systemnachrichten intern mittel Schalter/Lichtschalter niedrig Fensterkontakte Dann die Datenstruktur, IDs, Räume, Funktionen, Zustände in den ersten Datenbits ansiedeln...
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.