Info: Dieser Thread gehört zum Wiki-Artikel Hausbus Diskussion Für unsere Hausautomation haben wir ja schon über eine Bediensoftware diskutiert, ich habe auch ein wenig rumexperimentiert in Java. Mein aktueller Stand: Es gibt verschiedene Perspektiven (z.B. für verschiedene Stockwerke), die eine Übersicht über alle Sensoren und Aktoren in Symbolform enthält. Ausserdem gibt es zwei Modi: Den Betriebsmodus und den Konfigurationsmodus. Im Betriebsmodus sieht man die Zustände der einzelnen Sensoren/Aktoren und kann diese beeinflussen. Im Konfigurationsmodus kann man neue Symbole der Arbeitsfläche hinzufügen, Adressen oder andere systemnahe Einstellungen verändern. Neue Knoten können dabei einfach von der Symbolleiste auf die Arbeitsfläche gezogen werden. Soweit meine Idee, jetzt hätte ich gerne Vorschläge und Ideen von Euch! Wie stellt man die Eigenschaften der Knoten am besten dar? Meine Idee wäre es, an der rechten Seite des Programms eine aufklappbare Leiste einzubauen, in der listenartig alle Variablen und deren Werte stehen - bestimmte Werte davon sind eben nur im Konfigurationsmodus editierbar. Links am Programm könnte man eine baumförmige Übersicht aller vorhandenen Knoten / Gruppen, etc. anzeigen lassen, ebenso aufklappbar. In einer späteren Version des Programmes fände ich es ausserdem sinnvoll, die Fenster andockbar zu machen, damit man sie an anderer Stelle positionieren oder floatend machen kann. Was habt Ihr noch für Ideen/Vorschläge? Was ist sinnvoll, gleich in den ersten Versionen des Programms zu realisieren, was erst später?
Hallo Ithamar, das ganze klingt für mich nach Delphi IDE. Die Parallelen sind da: es werden auch einzelne Objekte mit unterschiedlichen Eigenschaften verwaltet die untereinander verknüpft sind. Die Fenster für die Eigenschaften und Objekthierarchei sind dort zwar standardmäßig übereinander auf der linken Seite, aber wenn man die Anwendung als MDI programmiert wären die Fenster ja sowieso ja nach Lust und Laune anzuordnen. Vielleicht sollte man sich an ´ner aktuellen Version orientieren. Warum das Rad ständig neu erfinden ;-)
Schaut euch mal das an: http://www.dehof.de/eib/otto.htm Ist zwar für EIB, kann aber sicher einfach an ein eigenes System angepasst werden. Man müsste ja nur die unterste (Hardwarebezogene) Schicht ändern. Kann zu mindestens als Ausgangsbasis herhalten!
@Guido: Du meinst den Aufbau der Programmierumgebung oder? Jo so in etwa habe ich mir das vorgestellt, zumindest von den Eigenschaften der Objekte her... MDI habe ich momentan nicht drin, zumindest noch nicht, die einzelnen Bereiche sind momentan Tabs im Hauptpanel. Aber das kann man ja noch ändern... @Hardy: Schaut nicht schlecht aus, zum Orientieren auf jeden Fall geeignet, auch wenn ich nicht alles so machen würde.
Hallo Zusammen, da ich zur Zeit auch an ein Haussteuerungs System arbeite werde ich mich an eurem Projekt mal etwas mit eingeben. Bevor man über die schönste Oberfläche diskutiert sollte man vielleicht ersteinmal die Struktur und die nötige Funktionalität spezifizieren. Ich denke ähnlich wie bei Html bzw Xml, wo sich alle (unterschiedliche Hersteller) auf ein zu Grunde liegendes "Document Objekt Mdell" DOM beziehen und ihre Software entsprechend ausrichten. Vielleicht könnten wir uns hier auf ein gemeinsammes Objektmodell einigen welches das Hausnetz abbildet und damit auch den funktionalen Kern der Software darstellt. Entsprechende Visualisierungen und Bedienoberflächen sind dann relativ schnell drumherumgebaut . Ich habe dafür bei mir den Arbeitsbegriff "Home Controler Area Object Model" - HCAOM . Dieses HCA-Basis Objekt besitzt bei mir unter anderem(Events,Waves,Actions,Views,HPCSProxi....) das Kind Objekt HPCS (HomeProcessControlerServer) mit der Auflistung Conns (Verbindungen) welche mehrere Conn Objekte enthält ua mit den Eigenschaften Verbindungsart (bei mir zur Zeit nur COM oder IPsocket), Protokoll, PortNr, Settings und der Auflistung Vars (Variablenliste der einzelnen HPC) und ua den Methoden RequestVars (Variablenliste von HPC anfordern), Open, Close, ... SetVars (Variablenliste an HPC senden) auf die Variablen der einzelnen HPC's könnte ich folgendermassen zugreifen: VBCode HPCS.Conns("HPC1").open() HPCS.Conns("HPC1").RequestVars() strAuslesewert=HPCS.Conns("HPC1").Vars("TemperaturX").Value msgbox ("TemperaturX= " & strAuslesewert) Wenn man dieses Objektmodell als dll programmiert kann von jeder Sprache her einfach darauf zugegriffen werden. Und jeder der Lust hat kann somit relativ einfach seine eigene Oberfläche basteln. Format, Plattform: Angefangen hatte ich mein Projekt als AktivX (quasi als OPCServer für Haussteuerungen) das Protokoll zu den Controllern selbstgebastelt /Klartext jetzt bin ich gerade dabei es auf Net. zu portieren. Die Daten Übermittlung soll in zukunft auf XML basieren. Ich denke das xml-Sendungen auch hier das beste Format wäre. (Weil schon allgemeiner Standard, einfach zu erstellen, überprüfen und problemlos erweiterbar) Der Nachteil (nur ca 10-30% Nutzdaten und damit erhöhter Traffic) ist bei normalen privathäusern nicht relevant. was meint ihr? reinhard
Hallo Reinhard, da hast du recht. Bevor es um Applikationen auf den oberen Schichten geht (Konfig, Visualisierung, etc.) muss man sich über Datenstrukturen und Softwarekonzept insgesamt einig werden. Hast du dein Objektmodell dokumentiert? Kannst du hier etwas Ausführlicheres posten? Ich bin nämlich auch gerade dabei, mir ein Objektmodell für die Hausautomatisierung zu konzipieren. Will auch in .net programmieren. Gruß, Jan
@Reinhard: Das hört sich sehr interessant an, wie schon Jan sagte, hättest du Dokumentation dazu? Je mehr Standards man zusammenlegen könnte, desto besser wäre es natürlich für alle. Mein Wunsch ist es sowieso, die Hausautomation auf das OSI/ISO-Schichtenmodell abzubilden und die Schnittstellen so zu definieren, dass einzelne Schichten möglichst einfach gegen andere ausgetauscht werden können. Immer wird das nicht möglich sein und Kompromisse müssen sicher geschlossen werden, aber damit muss man leben. Wichtig wäre nur, das ganze Projekt so zu strukturieren, dass man die Übersicht nicht verliert. Meine Experimente in Sachen Oberflächen waren jetzt auch noch nicht spezialisiert, sondern mehr oder weniger "Studien", was man so machen könnte, da ich z.B. mit Drag&Drop noch nie gearbeitet habe...
Hallo Jan, Dokumentierte Unterlagen haben ich viele - leider aber nur handschriftlich und überwiegend in form konfuser Diagramme. Auch ist das Objektmodell ursprünglich in einen anderen Kontext entstanden daher nicht so unbedingt übertragbar. Da ich aber sowie dabei bin es auf eine andere Plattform zu portieren kann man auch einen Neubeginn ins Auge sehen. Da das HCAOM-Objektmodell ja in erste Linie das Controller Network wiederspiegelt/repräsentiert ist es unumgänglich dessen Eigenschaften sowie die erforderlichen Aktionen und Ereignisse vorher zu spezifizieren. Ich denke wir sollten zuerst ein Brainstorming veranstalten über die erforderlichen abzubildenden Eigenschaften des Systems(zbsp BusID,KnotenID,KnotenName,BusTyp,PortNr,HostIP,KnotenLokalisation) - diese dann strukturieren und den einzelnen Systemkomponenten/Objekten zuordnen um sie dann dort als Umgebungsvariablen zu spezifizieren. Weiterhin sollte hier unterschieden werden nach 1. unbedingt erforderlichen Variablen/Eigenschaften wie zbsp KnotenID,BusTyp (d.h. für die allgm. Funktion zwingend erforderlich) 2. spezifizierten optionalen Variablen/Eigenschaften wie zbsbl Taster4, Licht1, Rolladen3oben, Temperatur2(d.h. für allgemeine Funktionen von "normierten fremdgeräten" erforderlich 3. Nichtspezifizierte benutzergewählte Variable wie zbsp. xyzWert von zyx(für spezielle Funktionen) Nachdem so die Eigenschaften erfasst, strukturiert und spezifiziert sind sollte mit den erforderlichen und denkbaren Funktionen/Methoden und Ereignissen ähnlich verfahren werden. Weiterhin ist mir die Topologie des Netzes noch nicht so ganz klar. Wie soll der PC eigentlich in den CanBus integriert werden. Als "normaler" CAN Knoten mit prio1 und eigenen CANKarte oder als serielles Verbindung/Subnetz hinter einen anderen CANKnoten? Aber ich denke mal das diese auch offen gehalten sollte so das auch einfache COM/USB Verbindungen möglich sind als auch TCP/IPSockets. Allerdings bin ich noch etwas am Rätseln wie man eine "Offene" Topologie sinnvoll abbildet. Was meint Ihr dazu? Reinhard
Der PC kann ja ein ganz "normaler" Knoten sein - er dient ja nur zur Überwachung und in bestimmten Fällen zur Beeinflussung der Knoten - ansonsten handeln diese selbständig. Wie der PC auf das CAN Netz zugreift ist auch zweitrangig denke ich - ob es per USB->CAN Adapter geschieht, per seriellem Konverter oder auch über eine Modemverbindung zu einem anderen Modem, das an das CAN Netzwerk angeschlossen ist... die Software sollte alles umsetzen können, das kann man ja einfach durch zusätzliche Module bewerkstelligen... Die Art der Adressierung hab ich mir auch schon ein wenig überlegt, ich werd meine Ideen mal die nächsten Tage posten, in den anderen dafür bestimmten Thread.
Hallo Ithamar, sehe ich auch so das die Verbindung offengehalten wird. Allerdings sollte man vorher festlegen ob der PC - oder bessergesagt das Steuerprogramm einen EtraStatus erhält oder in der Kommunikation mit den anderen Knoten völliggleichberechtigt ist. Ich denke mal das dies weitreichende konsequenzen in den zugriffsverfahren nach sich zieht. Weiterhin habe ich als Anregung mal einen (MUSTER !) XML Struktur skizziert. Ich denke das dieser eine gemeinsamme Plattform bietet ein Objektmodell zu entwickeln. Da später so eine Struktur aus dem objekt jederzeit generiert werden kann ist dieser auch gleichzeitig eine universelle und offene Schnittstelle für andere Softwaremodule. Ich denke hier besonders an Visualisierungstools. In Java kenne ich mich nicht so besonders aus aber in .NET könnte aus so einer XML Structur schnell eine TreeView Ansicht gefüllt und editiert werden(auch per DragDrop) . zu der XML Struktur unten: DokumentElement <HPCS>: HomeProzessControllerServer, repräsentiert die Abbildung des Netzes, ist sozusagen das BasisObjekt Steuersoftware , Name =lokal auf rechner, denkbar das noch andere Remoteserver vorhanden sind wie Name="RemoteServer1" oder "134.456.235.768" ChildElement <Connctions> Auflistung mehrerer Childelemente vom Typ HPC- HomeProzessController(Anm. in abgrenzung zur PLC/SPS für Industriesteuerungen) ChildElement <HPC> Repräsentiert eine einzelne HPC Als Attribute werden die spezifizierten unbedingt erforderlichen Eigenschaften wie ID und ConnTyp übergeben. ConnTyp "SER" könnte hier für ser COM verbindungstehen weiterhin wäre sinnvoll noch CAN und "W"LAN weiterhin ist zu überlegen ob hier auch die Vebindungsparameter wie portnr baudrate settings stehen sollten oder ob auf ein extra objekt referenziert wird. !!Gleichzeitig könnte dieses HPC element so auch als Format für den Nachrichtenaustausch verwendet werden!!!! evtl als attribut noch Empfängeradresse einfügen cHILDeLEMENT <Var>: repräsentiert optionale Umgebungsvariablen der einzelnen Controller es können beliebig viele eingefügt werden. <?xml version="1.0" encoding="iso-8859-1"?> <HPCS Name="Local"> <Connections> <HPC ID="23" Name="xyz" ConnTyp="SER" Localisation="Heizung" NetPath="1.2.4.5"> <Var Name="s0" Value="0" Typ="Bool" /> <Var Name="s1" Value="-1" Typ="Bool" /> <Var Name="s2" Value="-1" Typ="Bool" /> <Var Name="temp1" Value="23" Typ="int" /> <Var Name="LCDOut" Value="Hallo Welt" Typ="String" /> <Var Name="s5" Value="-1" Typ="Bool" /> </HPC> <HPC ID="13" Name="otto" Localisation="Kueche" NetPath="1.1.7"> <Var Name="s0" Value="0" Typ="Bool" /> <Var Name="s1" Value="-1" Typ="Bool" /> <Var Name="s2" Value="-1" Typ="Bool" /> <Var Name="temp1" Value="23" Typ="int" /> <Var Name="LCDOut" Value="Hallo Welt" Typ="String" /> <Var Name="s5" Value="-1" Typ="Bool" /> </HPC> </Connections> </HPCS> vielleicht sollte dazu ein extra XML ObjektBaum Thread eröffnet werden. reinhard
lasst doch die daten in eine sql-db zusammenlaufen und macht noch einen event-handler rein... visualisierung am besten über webserver... config könnte man auch so machen nur eine schöne gui wirds dann nicht... wobei ein nettes bäumchen auf der seite und dann ein config "dialog" auch reichen düfte... beim visualisieren hätte ich ein tabelle gemacht wo der zellenhintergrund einfach ein bitmal vom raum ist und die werte einfach reingeschrieben... die config 2 bäume.. einen wo die hirachie haus->etage->raum->variablen ist und einen 2. baum wo eben bus->knoten->variable drinnenist.. da zwischen kannst du nette verknüpfungen machen... und passt... xml verschicken ist meinermeinung nach overkill... sql geht doch auch.. mysql hat für m$ zeugs einen odbc driver.. sonnst gehts direkt über sockets.... und da es mitlerweile auch sowas wie funktionen in mysql gibt kannst du die datenabfrage auch über eine sql-function machen.. alternativ per webserver die daten als xml holen... meinermeinung nach wär das am einfachsten... bei mir wird demnächst auch sowas anstehen.. wobei bei mir eher zimmer-automatisieren am programm steht.. also tv an/aus/um schalten.. anlage an/aus/umschalten,... alles über fernbedienung,pc oder wie auch immer :) und das wird sicher über den von mir beschriebenen weg gehen... für was hat man einen router der eh nix zu tun hat :) 73 73
Hallo Hans, >lasst doch die daten in eine sql-db zusammenlaufen und macht noch >nen event-handler rein... meinst du das kurzlebige und und von mehreren Modulen gehandelte Daten in einer SQL DAtenbank besser abgelegt sind als in einer Objektstruktur? >visualisierung am besten über webserver könnte Sinvoll sein - daher mein Vorschlag eine extra DLL "Engine" für Datenhaltung und Hausbushandling - darauf könnte dann mit der jeweils geeigneten Oberfläche zugegriffen werden - auch mit Webserver! >bitmal vom raum ist was ist das? meinst du bitmap? als Tabellenhintergrund???? >xml verschicken ist meinermeinung nach overkill... warum? eigentlich ist die empfehlung für neu Konzepte: Webservices als XML-Service - nachrichtenformat xml/Soap Auch oder gerade für Datenbanken!! >sql geht doch auch.. versteh ich jetzt nicht - xml ist ein format und sql ist ne sprache wie willst du daten als sql verschicken?? >mysql hat für m$ zeugs einen odbc driver.. ja - wie soziemlich alle datenbanken >sonnst gehts direkt über sockets.... ja - wäre eine Überlegung wenn zu einem späteren Zeitpunkt Remote verfahren angesprochen werden. Hier ging es aber erstmal um den Datenaustausch Microcontroller <> PC-Visualisierungs/Steuersoftware und der CANbus hat keine Sockets. und ich kenne auch keine Linx oder CE Versionen für kleinere µC welche für den Betrieb eines Apache oder IIS erforderlich sind. >und da es mitlerweile auch sowas wie funktionen in mysql gibt >kannst du >die datenabfrage auch über eine sql-function machen.. alternativ per >webserver die daten als xml holen... wenn dann würde ich dies lieber mit PHP oder ASP ..bewerkstelligen meine Versuche mit SQL Funktionen waren nicht so das pralle...:-( >meinermeinung nach wär das am einfachsten... hmh >also tv an/aus/um schalten.. >anlage an/aus/umschalten,... alles über fernbedienung,pc und diese Datenmengen über SQL-Server ;-) gruß reinhard
Naja Weboberfläche is sicher praktisch, aber das sehe ich eher als "Schmankerl" an - denn der Webserver braucht erst mal Zugriff auf den Bus. Klar, das is sicher praktisch, aber ich denk mal der Zugriff auf die PC-Schnittstellen vom Webserver aus is komplizierter als direkt von einem Programm... Übrigens habe ich das auch im Hinterkopf gehabt, als ich die Idee von der Java-Software hatte, denn die kann ein wenig abgewandelt als Applet im Browser laufen. PHP is dafür natürlich auch sicher ned schlecht, aber als erstes muss mal die Kommunikation stimmen - die Visualisierung kommt danach. SQL is auch praktisch, eventuell könnte man das mal nutzen, um den Webserver Daten loggen zu lassen, die man dann auswerten kann, beispielsweise wann welche Lampe wie lang an war, um Stromkosten sparen zu können oder sowas - aber das sind Zukunftsvisionen. Ob allerdings XML-Daten über den Bus verschickt werden sollen, sollte gut überdacht werden. Das könnte Overkill sein und macht auch viel mehr Arbeit und lastet die Chips mehr aus. Schön wärs natürlich wegen der Skalierbarkeit. Aber ich denke auch, bevor man das diskutiert, sollte besprochen werden, wie man die Knoten anspricht -> anderer Thread
ich glaube ich muss meine geistigen ergüsse noch ein bisserl ordnen :) also ich meinte folgendes: irgendwelche scripts/programme hold die daten und übergeben sie einer weiteren instanz die z.b temp-regelt,... diese instanz tut alle daten aufbereitet in eine nette datenbank legen. von dort aus können sie zur visualisierung abgeholt werden und fertig wenn du lustig bist dann mach eine ramdisk und nimm als "datenbank" sqlite.. dann sind alle daten im ram :) php ist übrigends wunderbar geeignet um deamonen zu schreiben.. und nebenbei kanns auch so ziemlich jede datenbank bedienen und xml libs hats auch schon dabei... also lässt man nun einen php daemon die daten holen, die events handlen (licht ein, regen fäll,...) und schreibt alles in die datenbank ein anderes script geht da zyklisch drüber und regelt z.b die temperaturen... wie der datenaustausch nun zwischen php und mysql stattfindet interessiert keinen... man lässt die scripts einfach in die rohdaten-tablelle schreiben und ein zyklisch durchlaufendes script macht daraus lesbare daten... (hierbei könnten sql-functions hilfreich sein weil sie dieses script starten könnten wenn neue daten da sind => aktuellere daten und weniger cpulast am controller :) wichtig ist eigentlich nur wie du die daten von den uCs in eine datenbank bringst.. der rest ist "einfach"... denk doch nur mal nach was dir das für vorteile bringt nicht immer den ganzen xml-baum zu durchsuchen wenn du weist am knoten 2 hängt alles von einem raum drauf => "select * from daten where busid=1 and node=2" und du hast alles was draufhängt und brauchst nicht herumiterieren... ausserdem müsstest du wenndann die software komplett multithreaded aufziehen... sonnst geht dir die performance flöten wenn du was visualisieren willst (realtime) und dir nebenbei ich weisnicht wieviele knoten was mittleilen möchten... multithreaded ist zwar nicht böse aber aufwendig.. drumm lieber mehrere prozesse die untereinander kommunizieren.. und was bietet sich besser an zum daten verwalten wie eine datenbank :) ausserdem gibts noch viele vorteile: => steuer- bzw messrechner müssen nicht der gleiche sein (prinzipiell könnte man auch ein uclinux ding für alles verwenden weil sqlite ja auch dort wunderbar geht.. nur der rest müsste halt in c dazugedingst werden) => man kann alles schön austauschbar machen... datenbank zugriff in eine php file die von den daemonen, visualisierungs-script,.. verwendet wird und du kannst die datenbank wunderbar durch eine andere tauschen... neuer physical layer? kein prob.. das datenerfassungs-script ausgetauscht und alles geht wieder... oder neue visualisierung ? auhc kein prob weil die daten eh aus der datenbank kommen... => auch das plattform prob ist damit gelöst.. mysql,sqlite,php.. das gibts für alle plattformen die in frage kommen ausserdem sinkt der code-aufwand gewaltig... ein einfacher php-daemon ist primitiv.. und ich bin mir nichtmal sicher ob es überhaupt ein daemon sein muss.. wenn nur gepollt wird reicht ein cron-job :) ist ja nur eine idee... ich würd also eine variablen-tabelle und eine node-tabelle aufbaun.. also in der node-tab: NodeId,BusNr,NodeNr,Description und in der var-tab: VarId,NodeId,VarNr,VarType,Value,Description wobei VarNr nur notwendig ist wenn eine node mehrere Variablen haben kann... dann noch daten über die verteilung der nodes in den zimmern speichern und fertig ist alles was man zum visualisieren braucht... das mit bitmap als zellenhintergrund meinte in folgedem zusammenhang: http://de.selfhtml.org/html/tabellen/anzeige/bgcolor.htm 2. tabelle und zelle rechts unten.. da ist ein bild als zellenhintergrund... da machst du dann einfach ein schönes "bild" vom raum rein wie bei dem komischen "otto" projekt/programm/was auch immer... zumindest für die etagen-übersicht.. bei der ansicht von einem einzelnen raum könnte man ja den raum als hintergrund für die ganze tabelle nehmen und somit die werte dort anzeigen wo sie hinmüssen... ganz wäre aber sicher ein java-applet :) allein schon weil es sich automatisch updaten kann.... naja das ist aber wieder ein ganz anderes problem :) 73
Äh also PHP als Daemon zu verwenden halte ich für wenig sinnvoll, um es nett auszudrücken. Besser ist schon C für sowas geeignet, da vorkompiliert und performanter. Generell ist die Frage, ob du deine Hausautomation zentral oder dezentral steuern willst. Ich find es nicht prickelnd wenn ein PC dauernd laufen muss und wenn der mal ausfällt gibts kein Licht oder die Heizung läuft nimmer... Bei CAN wäre grad der Vorteil, dass der Bus multimaster-fähig ist, also kann man schön die Intelligenz in die Knoten verlagern - der PC dient dann lediglich zum Visualisieren und umprogrammieren der Knoten - steuern kann man natürlich auch, wenn man will, muss man aber nicht. Zentrale Steuerungsaufgaben kann man natürlich auch programmieren wenn man will, aber das würde ich dann auch einen extra µC übernehmen lassen, der z.B. im Schaltschrank sitzt. Aber wie gesagt, den PC würd ich nur zum Visualisieren nehmen...
naja.. wer sagt denn, das die knoten unter einander nicht reden... lass die daemonen weg und poll nur am bus herum.. fertig.. im prinzip kann dann die gleiche hardware sowohl im zentral bzw dezentral gesteuerten netz verwendet werden.. an der software brauchst auch nicht allzuviel gedreht werden... bei mir rennt ein router 24/7 und der dürfte unter 30W "fressen" das ist in meinem fall ok weil der auch backup-fileserver spielt... der darf dann auch diese "Spielerei" von mir mitbedienen.. wie gesagt mein anwendungsfall braucht keine intelligenten nodes.. mir würden dumme tiny12 nodes genügen und ein i2c bus :) trotzdem sehe ich eine gewisse logik dahinter möglichst viele konzepte unter einen hut zu bringen.. und wenn das visualisier/config frontend gleichbleiben kann und nur das daten-hol backend anders ist glaube ich ohne probleme beides unter einen hut bringen zu können... wie wolltest du denn die daten speichern/verteilen/...? 73
Bitte 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.