mikrocontroller.net

Forum: Haus & Smart Home Optik einer Visualisierungssoftware


Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

frage mich gerade, ob es nicht noch bessere/geeignetere/intuitivere
Darstellungen zur Steuerung/Konfiguration des Hauses gibt, als diese
überall anzutreffende Grundrisszeichnung, in den die zu steuernden
Geräte eingemalt sind?

Beispiel: Wenn ich mich nur über den "Füllstand" meiner Festplatte
verschaffen will, dann ist der Explorer auch wenig geeignet mir schnell
einen Überblick zu verschaffen, wo und wie die Dateien verteilt sind.
Dafür gibt's spezielle Software à la "SequoiaView" oder
"Scanner".
Screenshots:
http://www.win.tue.nl/sequoiaview/Graphics/ScreenSHSq1a.jpg
http://www.steffengerlach.de/freeware/scnshot.gif
Beide verwenden zwar eine grundverschiedene, aber jeweils sehr clevere
Art der Darstellung, auf die man soo einfach nicht kommt, wenn man nur
den WindowsExplorer kennt.
Das ganze hat zwar nix mit Grundrisszeichnung o.ä. zu tun, sondern ich
überlege, ob man die Idee der unkonventionellen Darstellung nicht auch
auf die Darstellung der automatisierten Aktoren/Sensoren 'irgendwie'
anwenden könnte?

Mich stört bei der Grundrissdarstellung, daß man nicht so schön durch
die einzelnen Aktoren/Parameter/Knoten "browsen" kann...
Außerdem hätte ich gerne eine neue, intuitivere Darstellung.

Welche Ideen habt ihr zur Visualisierung und evtl. Konfiguration? Kann
man das beides überhaupt mit einer Oberfläche erschlagen?

Habt ihr evtl. schon sowas gemacht? (Screenshots?)

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht eine Listendarstellung mit mehreren Spalten der Eigenschaften
wie Ein/Aus, Typ, Standort, Leistung usw. Und im Listenkopf dann die
Möglichkeit nach Spalte auf/absteigend zu sortieren. So könnte man zB
schnell erkennen ob viel eingeschaltet ist oder viele Fenster offen
sind .

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@and_ref,

ich persönlich glaube, das die Grundrissdarstellung nicht zu überbieten
ist.
Was ich für schwieriger halte ist einen intelligenten Zoom einzubauen
der in einer Gesamtübersicht einen Teil in eine Detailansicht
überführt. So ähnlich wie eine Lupe die über eine Platine gleitet. Aber
wie dann in der Lupe mit der Maus etwas anklicken? Eine ExtraLupenMaus?
Der Hammer ist aber die Verknüpfung des Busses so zu visualisieren das
auch ein "Normalo" etwas verändern kann ohne Totalschaden anrichten
zu können.
Das Thema sollten wir ausführlich diskutieren, es ein Punkt der mal
unabhängig von dem eingesetzten Bus ist.

Koopi

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie sieht denn so eine Grundrissdarstellung aus? Gibt's davon irgendwo
vielleicht eine Demo oder Screenshots? Was kann man mit der
Grundrissdarstellung alles machen?

Ich habe so eine Grundrissdarstellung noch nie gesehen, stelle sie mir
aber nicht so mächtig vor. Vielleicht ganz nett anzusehen, aber auch
komfortabel und mächtig?

Naja, ansonsten, die Verknüpfungen so darstellen, und die Software so
machen, dass sie jeder verwenden kann, ist so eine Sache.

Eine extrem einfache Bildverarbeitung macht nicht automatisch aus jeden
ein Picasso. Eine extrem einfache Textverarbeitung macht nicht aus jedem
ein Schrifftsteller.

Aber: Natürlich könnte man die Software zweiteilen:

Also eine Ebene, in der die Sensoren wie Tastern bestimmten Eingängen
zugeordnet werden, und auch z.B. Lampen oder Rollos irgendwelchen
Ausgängen. Diese Ebene wäre auch dafür zuständig, die physikalische
Position eines Sensors oder Aktors zuzuordnen. Also das Taster Nr.
12345 der Taster im Schlafzimmer ist, und Ausgang Nr. 4567 die Lampe im
WC ist etc. Diese Ebene sollte geschützt vor der einfacheren Ebene
sein.

Naja, und in der einfacheren Ebene kann man dann bestimmte Taster auf
bestimmte Lampen zuordnen usw. Das sollte alles DAU-sicher gehen. Da
gibt's keine Probleme.

Interessant wird's eben, wenn man auch komplizierter Sachen machen
können soll. Und das kann man nicht beliebig vereinfachen. Man kann
zwar für verschiedene Standard-Situationen irgendwelche Assistenten
oder Module zur Verfügung stellen, aber wirklich flexibel wird man
damit nicht.

Es ist einfach das alte Problem: Ich kann nicht etwas kompliziertes
lösen, ohne die Grundlagen zu kennen.

Fazit: Einfache (primitive) Software kann nur einfache Probleme lösen.
Wer komplizierte Sachen machen will, kommt nicht drum herum, sich mit
der Materie auseinanderzusetzen.

Autor: D. H. (slyd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wärs wenn wir da nen gemeinsames OpenSource Projekt raus machen?

Also eine Verwaltungssoftware für den Bus könnte ja eigentlich jeder
gebrauchen. Nur hat nicht jeder die Zeit, alles selbst zu entwickeln.
Damit also alle was davon haben und jeder nicht unnötig viel Zeit
investieren muss, könnten wir ein gemeinsames Projekt draus machen, das
jeder ständig erweitern kann wie er mag.
(am besten mit Plugin Schnittstelle)

Das Protokoll des jeweiligen Hausbussystems, sollte beliebig
veränderbar sein - genau wie die Ansteuerung der Hardware über die auf
den Bus zugegriffen wird. So bleibts flexibel/kompatibel und jeder kann
weiter sein eigenes Süppchen beim Bussystem kochen.
(Wir können da natürlich auch da nen Standard definieren - aber da muss
sich ja niemand dran halten wenn er nicht will...)

Welche Art von Bus (CAN, RS485, etc.) verwendet wird, ist auch erstmal
egal. Da kann man dann ja einen passenden "Treiber" für schreiben.

--> Oberfläche von der Hardwareschicht komplett trennen und nur
abstrakt ansteuern.  Am besten ne kleine Serveranwendung schreiben, auf
die man mit der Bedienoberfläche übers Netzwerk zugreifen kann.

__________________

Als Programmiersprache würde ich Java vorschlagen.
Für alle die jetzt denken "Java = Applett" - hier mal Screenshots ner
Applikation die ich vor einiger Zeit zum Steuern meines Bots geschrieben
hab:

http://www.dsh-elektronik.de/arcrobot/fotos/softwa...

http://www.dsh-elektronik.de/arcrobot/fotos/softwa...


Damit wäre es Plattformunabhängig sowohl für Linux als auch Windows zu
gebrauchen. (und sieht auch gut aus - sofern ich die Zeit finde, kann
ich dem Projekt dann nen cooles GUI beisteuern.

Naja und die OOP von Java ist schon was feines - sehr leicht da was mit
mehreren Entwicklern aufzuziehen.)



Hausgrundriss ist gut - kann ich gleich als Karte für meinen Bot
benutzen und den über die Software steuern g
(So in der Art: "Busknoten 22 meldet: Einbruchalarm an Fenster 4" -->
Roboter bewegt sich zu Fenster 4 und haut dem Einbrecher eins auf die
Mütze ;) )

Ausserdem ist so ein Hausgrundriss sehr einfach in der Software
darzustellen - und reinzoomen sollte auch relativ problemlos möglich
sein...

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Unbekannter

deine beiden letzten Sätze sind Gesetz. Kann man nicht zerreden. Aber
wenn ich eine gute Textverabeitung habe, kann wenig geübter Mensch
schnell einen relativ fehlerfreien Text erstellen. Mit Edit ist das
schwierieger. Auf dem Bus übertragen bedeutet das z.B. das ich eine
Verknüpfung einer Lampe mit einem Taster realisiere indem der Anwender
eines der beiden Elemente mit der Maus auf das andere Element schieb.
Dadurch öffnet sich ein Formular das ausgefüllt wird und die
Verknüpfung steht. Das ist intuitiv bedienbar. Ich kann niemanden
zumuten eine Tabelle mit Hex-Zahlen zu füttern. Das können wir, sogar
manchmal fehlerfrei, aber hol einmal Heinz Normalo. Der wird dich
wahrscheinlich auslachen. Das Verständnis fehlt einfach. Ich habe
meinen Hausbus auf meinem Geburstag einmal vorgeführt. Natürlich am
Notebook wireless konnte ich ganz stolz über meine Grundrisszeichnung
Rollos und Licht schalten. Sinngemäße Antwort der meisten: Wir haben
dafür normale Schalter an der Wand.

Koopi

Autor: D. H. (slyd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eben weil ne einfach zu bedienende Software so komplex zu programmieren
ist, sollte man dit janze als OpenSource Projekt machen. Zunächst hat
man dann nur nen einfaches Framework (eben mit HexZahlen per Hand
eingeben).
Später kann das aber sehr gut weiterentwickelt werden und wird dann
vielleicht irgendwann auch mal für jeden bedienbar...

Wenn viele Leute dran mitarbeiten, könnte das durchaus was werden.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Koopi:

> Sinngemäße Antwort der meisten: Wir haben
> dafür normale Schalter an der Wand.

Oh ja, diese Art von Antworten kenne ich genügend...

Naja, ich denke, das ist "typisch deutsch". Was neu ist, kann ja
nichts sein. Vielleicht ist's auch Neid, oder nicht so sehr Neid, aber
die Unfähigkeit, anderen mal etwas zuzugestehen dass sie etwas tolle
gebaut haben. Anderen Anerkennung schenken kann der "typische
Deutsche" meiner Erfahrung nach nicht. Das muss genetisch bedingt
sein.

Ansonsten, wegen der Software, stimme ich Dir zu. Genau das meinte ich
ja. Man kann eine Oberfläche bauen, damit man wirklich nicht mit
Hex-Dumps und Busadressen und Ausgangsnummern hantieren muss. Diese
Software kann dann auch Standardanwendungen wie z.B. eine
"Eltaco-Schaltung", oder auch ein Treppenhauslichtautomatik
(Zeitsteuerung) zur Verfügung stellen.


@Dominik:

Hmm, da sehe ich etwas schwarz. Ich denke, die Unterschiede in den
verschiedenen Bus-Systemen sind zu groß. Der einzige gemeinsame Nenner
dürfte eine irgendwie geartete Grundrissdarstellung sein, auf der man
rumklicken kann (wobei ich mir meine Software ziemlich anders
vorstelle).

Naja, gleich mal am Anfang eine Programiersprache in den Ring werfen,
obwohl noch nicht mal ein Hauch von Anforderungsanalyse gemacht wurde,
ist auch nicht so das Wahre. Die Auswahl der Programiersprache kommt
ganz am Schluss.

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
unsere beiden Postings haben sich vorhin überschnitten.
Ich gebe dir zum Großteil recht. Wobei wir als Schritt 1 erst einmal
die Eckpunkte diskutieren sollten.
Was mir am meisten Probleme bereitet, ist die Vorgehensweise. Ich fange
bei einer Software immer mit dem Datenmodell an. Darauf setze ich
Funktionen usw. Wirst Du wahrscheinlich ähnlich machen. Nur stellt sich
nun die Frage wie allgemein kann man die Datenstrukturen aufbauen um
allen gerecht zu werden. Ich habe so eine Software für meinen Bus schon
in den Grundzügen aufgebaut und dabei festgestellt, dass die
Datenstruktur für Aktoren und Sensoren sich schon sehr stark
unterscheiden. Wie wollen wir ereignis- und befehlsorientierte
Strukturen unter einen Hut bekommen.
Gedanke: eventuell nur Oberflächen und Händling realisieren /
diskutieren?

Koopi

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eine Software auf einem Webserver, wäre das nicht die richtige
Plattform? Dann gibt es kein Linux, XP, Mac. Softwareupdate auf dem
eigenen Server. Man ist weltweit "zu Hause". Ja, ja nicht ganz, aber
ich kann im Arbeitszimmer Licht einschalten. Der PDA wäre auch gleich
eine Fernbedienung.

Ich habe einen Versuch an meinem Bus laufen.
Kannst ja mal schauen unter www.khbus.de
die grafische Darstellung ist mit user0 / pass0 geschützt. Macht euch
keine Hoffnung, ihr könnt nur schauen, schalten habe ich gesperrt. :-)

Koopi

Autor: D. H. (slyd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Unbekannter:
Natürlich sind die Bussysteme sehr verschieden. Und bestimmte
Vorraussetzungen muss das Bussystem schon erfüllen um mit einer
universellen Konfigurations Software kompatibel zu sein. (z.B. muss
alles notwendige frei parametrierbar sein)
Aber soooo schwierig wie Du es sagst ist es nicht. Läuft ja alles
darauf hinaus ein Hexfile für ein EEPROM mit der Parametrierung zu
generieren und auf den jeweiligen Busknoten zu übertragen.
Und jedes Bussystem basiert ja meistens auf irgendwelchen Sensoren die
Events erzeugen, sowie darauf reagierenden Aktoren. Und das sind nur
wenige einfache Bytesequenzen die da erzeugt werden müssen.


Warum ich gleich Java in den Raum werfe? Weil mir die Anforderungen an
die Software schon weitestgehend klar sind.
Und alles was mir an Anforderungen eingefallen ist, kann ich mit Java
Problemlos realisieren. (die Sprache ist für sowas eigentlich ziemlich
egal, da braucht man nicht viel zu analysieren. Nur mit Java kann ich
eben sehr gut umgehen und ne ganze Menge Komponenten fürs GUI und
Netzwerk sind bei mir schon vorhanden.)

Aber selbstverständlich war Java nur ein Vorschlag. Wir müssen nicht
unbedingt Java verwenden - mir wäre es allerdings sehr recht, da ich
von GUIs in C/C++ absolut kein Plan hab.

Ist aber kombinierbar. Serverapplikation in C/C++ und GUI in Java -
sollte normalerweise kein Thema sein.

__________________________


@Koopi:
Klar kommt erstmal ne etwas konkretere Definition - wir müssen ja alle
wissen was für Daten wir bearbeiten wollen.



Das ganze sieht für mich momentan wie folgt aus:

Die Software hat zwei größere Aufgaben:
1. Die Parametrierung des Bussystems generieren.
Und das möglichst einfach und abstrakt für den Anwender. (am besten
also visuell - sprich: Klick auf nen Busknoten
und die Einstellungen erscheinen - Klick auf nen Aktor und die für den
Aktor relevanten Einstellungen erscheinen, usw.
Diese Darstellung kann man für die Visualisierung in Punkt 2 natürlich
gleich weiterverwenden)

2. Den aktuellen Zustand des Bussystems visualisieren und die Busknoten
steuern.


Punkt 1 ist für mich quasi eine art "Hochsprachencompiler", nur eben
visuell... Zunächst wird aus einem abstrakten Modell des Bussystems und
des Hauses mit allen Busknoten, Events, Aktoren, Sensoren etc. ein
Zwischencode erzeugt. Kann z.B. einfach ne XML Datei sein - und die aus
dem Modell zu generieren ist einfach.

Aus dieser - ich bleibe jetzt mal bei der XML Datei - werden in einem
zweiten Schritt dann die Hexfiles generiert die direkt ins
"Parametrier-EEPROM" der Busknoten geladen werden können. (oder auch
Befehlssequenzen die auf dem Bussystem übertragen werden müssen um die
Knoten entsprechend zu konfigurieren sofern das erforderlich ist)

Das mit dem Zwischencode könnte man auch weglassen und alles direkt aus
dem Modell generieren, nur so ist es flexibler. Denn so kann man den
Teil der das Modell generiert besser vom Busspezifischen Teil trennen
(ausserdem braucht man ja auch sowieso was zum Abspeichern des Modells
und da bietet sich XML an).


Der zweite Teil kann ähnlich sein wie bei der Weboberfläche von Koopi.
Die sieht übrigens schonmal gar nicht schlecht aus. (OK - grafisch
könnte man da noch nen bisschen dran feilen ;) )
Da man aber sowieso TCP/IP als Kommunikationsmittel zwischen Client und
Server verwenden sollte - isses egal was man dafür nimmt - hauptsache es
ist Netzwerkfähig.



Das ist erstmal so die Grundlage wie ich mir sowas vorstellen könnte.
Ums nochmal zusammenzufassen: Es gibt eine Client Applikation zum
Erstellen der Parametrierung und
zur Visualisierung/Steuerung.
Dazu eine Serverapplikation, die zur Kommunikation an das jeweilige
Bussystem angepasst wird und auf irgendeinem Rechner
installiert werden kann, der eh den ganzen Tag läuft. (muss natürlich
nicht wenn man so nen Rechner nicht hat.
Bei mir wird aber nen embedded PC, der noch einige andere Sachen
übernimmt, sowieso den ganzen Tag an sein (u.a. damit man das Haus gut
übers Internet fernsteuern kann))
Kommunikation zwischen beiden Applikationen erfolgt komplett über
TCP/IP - ist also egal auf welchem Rechner die Client
Software läuft. (und man kann das auch mit ner Applikation in nem
Webserver ansteuern. Gleichzeitig natürlich! Multiuserfähig sollte es
schon sein)

Also das fänd ich schon gut sowas =)



> Macht euch keine Hoffnung, ihr könnt nur schauen,
> schalten habe ich gesperrt

Na also wenn gleich um 3:00 Uhr bei Dir im Schlafzimmer das Licht
angeht, hats doch wer geknackt ;)

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dominik:

Naja, da geht es ja schon los. Meine Vorstellung der Software sieht
ganz  anders aus:

Beim parametrieren will ich nichts von den Busknoten wissen. Ist mir ja
als Anwender in diesem Falle auch egal, an welchen Busknoten welche
Taster hängen und welche Busknoten welche Lampen und Rollos etc.
bedienen. Es spielt aus Anwendersicht keine Rolle, ob in einem Zimmer
die Taster, Lampen und Rollos alle an einem einzigen Busknoten
angeschlossen sind, oder jeder Sensor und Aktor sein eigenen Busknoten
hat.

Als Anwender möchte ich Taster und Lampen zu Gruppen zusammenfassen,
Zeitfunktionen hinzufügen, abhängigkeiten von Tageszeiten, Wochentagen
oder Umweltparamteren (Sonne, Regen, Tag, Nacht) definieren etc.


@Koopi:

Hmm, ja, so eine Web-basierende Lösung hat schon irgendwas. Mir stellt
sich nur eine grundsätzliche Frage:

Will man per Web-Oberfläche das Haus nur bedienen, oder soll man es
auch konfigurieren (parametrieren) können?

Der zweite Themenkomplex ist Sicherheit. Daher würde ich soweit gehen,
zum einem zwei getrennte Web-Server aufbauen, einer für die Bedienung
aus dem Haus heraus, z.B. per WLAN und PDA, der darf praktisches alles,
und ein Web-Server für das Internet, der dürfte hauptsächlich nur
anzeigen und einige Dinge wie Heizung an/aus oder so. Weiter würde ich
mir sogar eine Art Hardware-Firewall vorstellen. Also dass der
Buskoppler an dem der PC mit dem Internet-Server hängt, nur exakt
vordefinierte CAN-Nachrichten durchlässt. Es muss auf jeden Fall
verhindert werden, dass es mit einem gehacktem Webserver möglich ist,
die Kontrolle über das Haus zu übernehmen. Bei diesem Thema bin ich
sehr sensibel. Von daher würde ich evtl. doch nur ein Telefon-Interface
für die Fernbedienung vorsehen.

Autor: D. H. (slyd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Unbekannter:

Sicher - das kann man auch so machen wie Du es beschreibst - das der
Anwender die Busknoten gar nicht mehr sieht.
Ist eigentlich ne gute Idee. Darum sollte sich wirklich die Software
kümmern.

Also lässt man die Darstellung der Busknoten ganz einfach weg und
stellt nur die Sensoren und Aktoren dar.

Umd das ganze vorgehen beim Anlegen eines neuen Hauses in der Software
mal etwas zu präzisieren:
/*
Anmerkung: IM FOLGENDEN NENNE ICH AUS ZEITGRÜNDEN NUR EIN BEISPIEL und
gehe nicht auf alle möglichen Fälle ein. 100%ig ist auch noch nichts
festgelget, das kann alles noch variieren und da ich nicht ewig Zeit
habe um das folgende zu schreiben können da auch noch kleine Fehler
drin sein, die aber leicht behoben werden können. 

Nur um das schonmal Klarzustellen:
Mit dem Konzept wie ich es mir vorstelle, kann man natürlich auch
Timer-Events o.ä. konfigurieren wenn man das entsprechend vorsieht...
Aktoren zu Gruppen zusammenzufassen geht ebenfalls, indem man jedem
Aktor bestimmte Gruppenevents zuweist auf die er reagieren soll. Das
kann auch, damit es für den DAU (Ich setze "DAU" mal mit dem Anwender
gleich, der null Ahnung vom Bussystem hat) übersichtlicher wird, über ne
komfortable Eingabemaske passieren, die diese Einstellungen automatisch
erzeugt...............
*/

_

Das Anlegen des neuen virtuellen Hauses muss natürlich der Spezialist
machen, der das Bussystem entwickelt hat.
Der DAU der später mal was ändern möchte das mit Taster X ne andere
Lampe angeschaltet wird oder ein Temperaturschalter zwischen 18 und
22°C anstatt zwischen 20 und 24°C schaltet, bekommt davon aber nix
mit.


##### 1. Schritt:
Zunächst legt man eine Liste mit allen Busknoten an. Hierzu sollte man
vorher verschiedene Klassen von Busknoten definieren. Jede Klasse von
Busknoten hat verschiedene Hardware Module wie Digitale Ein- und
Ausgänge, ADCs, PWMs, Timer, RC5 Empfänger o. ä.
Ist aus Softwaresicht aber alles sehr ähnlich, denn letzlich kommen
immer nur bestimmte Werte rein oder raus. Ob's nun 2 Bytes für nen 12
Bit ADC, oder nur ein Bit für nen Eingang sind - das ist erstmal egal.

Man spezifiziert nur die entsprechende Art der Hardware und legt nen
Namen dafür fest, anhanddessen man diese später gut identifizieren
kann, z.B. für nen Digitaleingang des Busknoten an Port 1: "P1.1"

Wenn man nur eine Art von Busknoten hat - braucht man das natürlich nur
einmal machen und kann dann beliebig viele Instanzen dieser
Busknotenklasse anlegen.

##### 2. Schritt:
Dann definiert man welche Sensoren und Aktoren an welchen Busknoten
hängen. Kann man z.B. ganz einfach in ner Baumansicht darstellen.
Klickt man auf einen Busknoten, kann man neue Sensoren und Aktoren
hinzufügen/löschen/verschieben/kopieren usw.

Auch hier muss man erstmal die "Sensor"- und "Aktor"-Klassen
definieren. Jeder Sensor ist ja eigentlich nur eine Ansammlung von
Messwerten und Zuständen. Welche Einheit oder Aussage die Messwerte
oder Zustände haben, kann der Software dabei egal sein. Ist einfach nur
ein bestimmter Wert. Die Busknoten stellen ja auch bereits Routinen zur
überprüfung dieser Werte bereit - z.B. ob der Wert eines ADCs innerhalb
eines bestimmten Bereichs liegt.
Einheit und Bedeutung (also obs nun ne Temperatur, nen Füllstand oder
sonstwas ist) kann der Anwender festlegen.


Einfaches kleines Beispiel:
Bei nem Taster gibt es ja z.B. die Zustände "Taster gedrückt"  und
"Taster losgelassen". Diese Zustände nimmt der Taster an, wenn der
zugeordnete Port jeweils logisch 1 oder 0 ist. Jeder dieser Zustände
hat nen Zahlenwert, der bei einer Zustandsänderung als Event auf den
Bus gelegt wird.
Also definiert man ne neue Sensorklasse "Taster" mit diesen beiden
Zuständen.
Dann fügt man alle Taster die man hat, den jeweiligen Busknoten hinzu.
Für jedem Taster muss festgelegt werden an welchem der verfügbaren
Eingänge des Busknotens er hängt - also z.B. "P1.1" und welche ID er
hat, z.B. "Taster 1 Flur UG" (damit man später die Aktoren auf diese
ID konfigurieren kann).


##### 3. Schritt:
Dann definiert man z.B. eine Aktorklasse "Lampe", mit den Zuständen
"An" und "Aus". ("An" ordnet man die Zahl 1 und "Aus" die Zahl
0 zu, dieser Wert wird beim Wechsel in einen der beiden Zustände direkt
auf den Ausgang des Busknotens gelegt)
Jetzt fügt man alle Lampen den jeweiligen Busknoten hinzu, wieder mit
IDs, Ausgangsnummern etc.

(nun kann man das ganze entweder so wie es ist als Liste lassen, oder
die Sensoren und Aktoren auf nem Grundriss des Hauses verteilen - nur
wenn man das möchte natürlich - diese Funktion kann man auch später
noch dazuprogrammieren und ist erstmal gar nicht soooo wichtig. .)


##### 4. Ende:
Wenn man das alles gemacht hat, sollte man den DAU an den Rechner
lassen können. Der schnappt sich nun z.B. den Aktor "Lampe Flur UG"
und fügt diesem das Event ["Taster 1 Flur"."Taster gedrückt"]
hinzu. Dann legt er die Aktion fest - z.B. "Schalte zum nächsten
Zustand".
Die Lampe würde dann bei jedem Tastendruck zwischen den beiden
Zuständen getoggelt.


Jetzt muss man natürlich noch einige weitere Fälle behandeln -
Beispielsweise sollte es auch Aktionen geben wie "Schalte in den
Zustand X" oder "Addiere zum Wert Y, den Wert Z hinzu" ...
Oder Events die erzeugt werden sobald ein Wert einen bestimmten Bereich
verlassen hat.
Das kann man dann beliebig um alles erweitern was man will.

Gut, das ist nicht ganz einfach zu programmieren - aber möglich ist es,
da bin ich sicher.

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Unbekannter,

du liegst schon gut in der Spur.
Ich halte es zwar für wichtig den Bus auch übers WWW komplett
erreichbar zu machen, aber natürlich über verschiedene User-Level bis
hin zum Admin der dann alles darf. Schlagwort: Fernwartung
Da der CGI-Server selber geschrieben werden muß, ist es ein leichtes
bestimmten Usern entsprechende Rechte zu geben oder auch zu nehmen.
Wenn man dann nicht den PC sondern einen Embedded Server benutzt, gibt
es auch keine Viren oder ähnliche Schikanen. Ich nutze einen Server von
Beck ( www.beck-ipc.com ), dabei habe ich mir auch die Möglichkeit
geschaffen, durch zwei Jumper, den Bus physikalisch vom Server zu
trennen.

Koopi

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Koopi:

Über Fernwartung habe ich auch nachgedacht. Ist sehr verlockend.

Nur denke ich, das "einfache Model mit Userlevel" etc., ist nicht
ausreichend bei dieser Geschichte. Ich sehe da ein viel höheres
Gefährdungspotential.

Konkret: Angenommen, mit dem Hausbus werden Rollos und auch mindestens
ein elektrisches Fenster gesteuert. Dann kann ein Angreifer per
Fernwartung das Fenster öffnen um seine Diebestour zu erleichtern.
Gleichzeitig kann er verhindern dass Infrarot-Detektoren etc. das
Aussenlicht angehen lassen usw. Auch nur die einfache Funktion, ein
Rollo auffahren zu lassen um anschliessend durch das Fenster
einzusteigen sind ausreichend.
Ein Angreifer könnte auch aus der Ferne das Haus observieren, und so
Informationen sammeln, wann das Haus leer ist etc.

D.h. mächtige Möglichkeiten, die ich um alles in der Welt verhindern
möchte.

Das konzeptionelle Problem an der Geschichte ist, sobald ich von
Unterwegs auf das Haus zugreifen kann, ist mit einer
Man-In-The-Middle-Attack das alles einfach möglich.

D.h. der Zugriff dürfte nur durch einen sicheren VPN-Client erfolgen.
Da ich aber einem fremden System, z.B. in einem Internet-Cafe nicht
trauen kann, müsste ich einen eigenen Notebook mitschleppen, mit
entsprechend installierter VPN-Software. Nur so wäre ich vor Angriffen
einigermassen geschützt.

Die Frage ist eben: Will ich das? Wenn ich einen dedizierten Notebook
mitschleppen muss, ist der Komfort doch schon eingeschränkt.

Ok, das ist die eine Sache.

Die andere, konkrete Sache: Zwei Jumper um den Bus vom Internet zu
trennen, wäre mir zu wenig.

In entsprechenden Rechenzentren etc. ist es üblich, eine rote Dose mit
einem roten Kabel an exponierter Stelle zu montieren, mit dicken
Warnschild darüber. So dass man jeden Laien zu der Dose schicken kann
um das Netzwerkkabel zu ziehen damit der betreffende Teil sofort vom
Internet physikalisch getrennt wird. Es gibt inzwischen dafür glaub'
sogar entsprechende Schalter mit Veriegelung, die nur durch einen
Schlüssel entriegelt werden können. Meine so etwas mal flüchtig in
einem Rechenzentrum gesehen zu haben.

Mal ganz nebenher: Wie sieht es eigentlich Versicherungstechnisch bei
einer Home-Automaton aus? Gerade bei Rollo oder sogar Fenstersteuerung?
Hat sich da schon mal jemand informiert?


@Dominik:

Nur ganz kurz (muss weg) zu Punkt #1:

Die Busknoten sollten der Software selbst melden, welche
"Fähigkeiten" sie haben, also ob Digitale oder Analoge Ein- und
Ausgänge vorhanden sind, wieviel von denen vorhanden sind.

Auch sollte die Software den Bus "scannen" können, also automatisch
alle Busknoten finden können. Das würde mein Protokoll auf jeden Fall
vorsehen.

Ausserdem sollte jeder Busknoten ausser einer eindeutigen Seriennummer
auch eine Möglichkeit besitzen, selbst einen beliebigen, eigenen Namen
zu im EEPROM zu speichern.

Weiter sollten die Buskoppler evtl. in einen Zustand versetzt werden
können, in dem sie angeschlossene Taster automatisch finden können. Das
müsste die Hardware allerdings irgendwie unterstützen. Bin ich mir noch
nicht schlüssig.

Es sollte so sein, das die Gefahr von Dateninkostenz minimiert wird.
D.h. wenn ich von Hand eintragen muss, welcher Buskoppler was kann,
besteht die Gefahr dass das nicht mit der Realität übereinstimmt. Also
soll das das System gefeligst selbst machen.

Ansonsten, noch einen "politischen" Hinweis: Ich denke, Du solltest
lieber von "Anwendern" anstatt von DAUs sprechen. Software wird für
Anwender geschrieben, Software ist ein Werkzeug das zu dienen hat.
Software ist kein Selbstzweck oder ein Mittel um Personengruppen zu
klassifizieren... Das wollen wir lieber mal dem Stoiber überlassen...

Ich finde, es ist wichtig, wie man über die Anwender denkt, wie man sie
sieht. Nur so kann man Problem zufriedenstellend lösen.

So, ist nun doch etwas länger geworden. Nun muss ich aber weg...

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Unbekannter,

ja ja alles richtig, nur meine Jumper sind die Bus2Web-Verbinder.
Sollte jemand den Jumper unerlaubt stecken, war er schon bei mir und
hat ja schon gewonnen. Aber eine Idee wäre ein Anruf der das Relais (
dann nicht mehr Jumper ) setzt.

Username und Passwort nutzt z.B. die Fa. Siemens um die HICOM -
Telefonanlagen großer Kunden ( ganzer Call-Center ) zu konfigurieren.
Da geht es nicht nur um einen Einbruch, dort wäre es möglich innerhalb
von 60 Sekunden eine Firma lahm zu legen. Ich glaube das dort schon auf
Sicherheit geachtet wird.

Ein Restrisiko besteht immer.

Koopi

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Unbekannter:
> Wie sieht denn so eine Grundrissdarstellung aus?
Ich habe ca. 10min nach einem Link für mein Eingangsposting gesucht,
aber nix gefunden, deshalb hier: So oder so ähnliches ist gemeint:
http://www.canathome.de/Bilder/BCB_Betrieb.jpg

@Koopi:
> Sinngemäße Antwort der meisten: Wir haben dafür normale Schalter an
> der Wand.
Und Recht haben die! Das liegt daran, daß eine Haussteuerung noch viel
zu teuer im Gegensatz zum möglichen Nutzen/Energieersparnis ist, als
daß sich schon der Allgemeinheit bekannt wäre. Hinzu kommen noch die
hohen Preise und vielen Standards... Gäbe es einen gescheiten,
genormten, evtl. sogar schnittstellenoffenen Bus, dann müßten wir uns
nicht hier mit Bedienkonzepten rumschlagen, sondern könnten
standardisierte Software einsetzen :-)

@Unbekannter:
[Wir haben dafür normale Schalter an der Wand]
> Naja, ich denke, das ist "typisch deutsch [...] Neid...".
Nein, das ist fehlende Technikbegeisterung/-verliebtheit - das hat
gewiss nix mit "typisch deutsch" oder gar Neid zu tun!

@Dominik:
> Aber soooo schwierig wie Du es sagst ist es nicht. Läuft ja alles
> darauf hinaus ein Hexfile für ein EEPROM mit der Parametrierung zu
> generieren
Nein! Ich träume nicht im entferntesten davon ein Hexfile für ein
Eeprom zu generieren ;-)
Das wird (bei mir) alles durch diskrete Konfigurationstelegramme
gelöst. Sodaß auch andere CAN-Teilnehmer (nicht nur der PC) auch
prinzipiell in der Lage wären eine Konfiguration durchzuführen. Muß ja
nicht gleich eine Taster-Lampenumbelegung sein...

> Weil mir die Anforderungen an die Software schon weitestgehend klar
> sind.
Hm, da bist du scheinbar der einzige hier - so wie ich die Äußerungen
der anderen interpretiere... für mich sind da noch sehr viele Punkte
offen...

Ich leg mal los:
1.) Soll die Grundrissansicht mit den darüber einblendbaren Lampen usw.
bereits zur Programmerstellungszeit fest in den Code reincodiert werden,
oder soll das Einzeichnen zur Laufzeit möglich sein (wie z.B. in einem
CAD-Programm). Ersteres ist natürlich deutlich einfacher zu lösen...
vielleicht so eine Mischform, d.h. Grundriss als Bitmap fest verankert,
aber Lampen z.B. noch nachträglich hinzufügbar oder verschiebbar?!?
2.) Aus welcher Sicht präsentiere ich die "Zustände/Parameter"? D.h.
soll bei einem Klick auf ein Wandtastersymbol ein Fenster aufgehen, das
mir die damit verbundenen Lampen grafisch/sonstwie anzeigt, oder
interessieren die Taster primär weniger und ich baue das aus Sicht der
Lampen auf (bei Klick sieht man die Taster, die mit den Lampen
verbunden sind - evtl. auch irgendwie grafisch), oder ganz anders?
3.) Sollte die Oberfläche von einem normalen PC-Programm dargestellt
werden, oder gibt es inzw. einfache Möglichkeiten das über einen
Webserver zu regeln? Wie sähe die Anbindung der HW (sprich
PC-CAN-Interface) an einen Webserver aus? (kenne mich da überhaupt
nicht aus).



Mit der Sicherheit über Webinterface mache ich mir auch keine so großen
Sorgen - bevor mir jemand per Internet die Fenster auffährt und
einbricht, klaut der mir mir Auto, kopiert sich meine Kreditkarte oder
läßt sich sonst was einfallen.

Autor: D. H. (slyd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Unbekannter:

<Stoiber-Voice>
Ja gutt - äähh - das mit dem DAUhh - äähh - des hob ich nua
geschrieb'n - äähhh - um mir Tipp-äähh-arbeit zu erspoaren...
</Stoiber-Voice>
(ich hab den Stoiber Thread auch gehen  und gerade die Stoiber-Rede im
TV gesehen ;)
Zitat: "wir haben nunmal nicht überall so kluge Leute wie in
Bayern"...)

Vielleicht hätt ich das umgekehrt machen sollen und den Super-Anwender
als Admin bezeichnen sollen und den normalo-Anwender nur als Anwender.
Also das war gegenüber einem normalo-Anwender nicht herablassend
gemeint - ich denk über solche Nebensächlichkeiten meist nicht
sonderlich viel nach.
Als Politiker wär ich wohl auch nicht zu gebrauchen, aber das stört
mich eher weniger ;)

Na lassen wir das.




_________________________________________________________
Back to topic:

Das sich die Software Ihre komplette Konfiguration direkt "vom Bus"
holt hatte ich bisher nicht geplant, aber es spricht nix dagegen das
mit einzubauen.

An einen automatischen Scanner der zumindest auflistet welche Knoten
angeschlossen sind, hatte ich sowieso gedacht. Aber das was ich maximal
einbauen wollte war eine Klassen-ID im Busknoten, so das allen Busknoten
auch automatisch die passende Klasse zugewiesen wird.

Wenn ich es recht überlege - man kann die komplette Konfiguration aber
auch einfach als nen paar Strings im Flash-ROM ablegen - dann würde das
wiederum gehen, dann bräuchte man ja nur ne Funktion die die Strings
über das Busystem überträgt...
Aber das kostet natürlich einiges an Speicherplatz...


So wie ich es oben beschrieben habe funktioniert es allerdings auch mit
Bussystemen die sowas nicht bieten. Deswegen sollte man schon eine
Funktion vorsehen die Busknoten per Hand einzustellen.

Und die automatische Konfiguration funktioniert nur für die Busknoten.

Alles mit den Sensoren und Aktoren muss meiner Meinung nach per Hand
eingestellt werden.


> Weiter sollten die Buskoppler evtl. in einen Zustand
> versetzt werden können, in dem sie angeschlossene
> Taster automatisch finden können.

Ich hatte eigentlich vor, universelle digitale Eingänge an jedem
Busknoten zu realisieren - was da dranhängt ist dem Busknoten natürlich
unbekannt.
Wie willst Du denn Hardwareseitig feststellen ob da nun ein Schalter
dran ist, oder nicht doch irgendein Sensor der logisch 1 oder 0
liefert? (also ohne großen Hardwareaufwand natürlich)


_________________________________

@Koopi:
Sowas mit Siemens kann ich bestätigen, da ich mal inner
Technikabteilung in nem Krankenhaus gearbeitet hab (Zivildienst...).
Dort gibt es nen Rechner der z.B. das BHKW, die Klimatechnik und alles
mögliche andere steuern kann. Und ein Siemens-Techniker kann sich über
eine Modem Verbindung einwählen und alles fernbedienen.
Und in nem Krankenhaus ist das sehr Sicherheitskritisch... wenn da
irgendwer von ausserhalb an der Klimaanlage/Heizung vom OP rumpfuschen
könnte...


__

Na also wegen der Sicherheit würde ich eine eventuelle
Konfigurationssoftware im Internet auch nicht unbedingt direkt auf die
Startseite meiner Homepage stellen ;)
Allerhöchstens ne Subdomain ...


Das mit dem Anruf/SMS ist ne gute Idee.

Und wenn man die Weboberfläche als Java Applett laufen lassen würde,
könnte man die Sicherheit was fremde Rechner angeht auch noch etwas
erhöhen - so kann man die Verbindung besser verschlüsseln und
verhindern das der Webbrowser/Proxy irgendwelche sicherheitsrelevanten
Daten zwischenspeichert.
Gegen Tastaturlogger o.ä. im Internetcafe hilft das aber natürlich auch
nichts...
Das Problem dabei ist nur, das nicht in jedem Internet Cafe Java
Appletts erlaubt sind bzw. ne JVM installiert ist...
So gut wie jeder aktuelle PDA kann aber mit ner Java VM ausgestattet
werden. Auf vielen Handys läuft ne stark abgespeckte Version davon
ebenfalls. Also bleiben noch genug Möglichkeiten übrig.

Autor: D. H. (slyd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@and_ref:

> Nein! Ich träume nicht im entferntesten davon ein Hexfile für ein
> Eeprom zu generieren ;-)

Hab ich gesagt das man es so machen MUSS ? ;)
Ich zitiere mich mal selbst:

Aus dieser - ich bleibe jetzt mal bei der XML Datei - werden in einem
zweiten Schritt dann die Hexfiles generiert die direkt ins
"Parametrier-EEPROM" der Busknoten geladen werden können.
*(oder auch Befehlssequenzen die auf dem Bussystem übertragen werden
müssen um die Knoten entsprechend zu konfigurieren sofern das
erforderlich ist)*


Das war nur ein Beispiel wie man es machen könnte.



> > Weil mir die Anforderungen an die Software
> > schon weitestgehend klar sind.
>
> Hm, da bist du scheinbar der einzige hier - so wie
> ich die Äußerungen
> der anderen interpretiere... für mich sind da
> noch sehr viele Punkte offen...

Da haste mich falsch verstanden - ich meinte damit nicht wie die
Bedienoberfläche aussehen soll, sondern ob man alles nötige mit der
Programmiersprache realisieren kann. Und das ist mit Java eben kein
Problem. Darüber hatte ich mit unserem Unbekannten ja geredet. Da ging
es nicht um die Oberfläche, sondern ob es prinzipiell mit der
Programmiersprache und dafür verfügbaren Bibliotheken möglich ist.


Zu 1)
Ob man den Hausgrundriss in der Software selbst zeichnet oder in nem
externen CAD Programm ist eine interessante Frage.
Die Lampen und alles andere werden aber selbstverständlich zur Laufzeit
eingefügt! Die Frage stellt sich mir nicht ;)

Also wenn man ein Bitmap des Hausgrundrisses importiert kann man es
natürlich vorher noch nen bisschen verschönern ;)
Und der Grundriss des Hauses ändert sich ja hoffentlich auch nicht so
häufig - macht also sogar Sinn das nur einmal als Grafik zu importieren
und gut iss.

Zu 2)
Wenn man wie ich es Beschrieben habe eine Liste aller Sensoren und
Aktoren hat, kann man beides kombinieren wie man lustig ist.
Ich stell mir das so vor:
Links in der Software hat man ne Liste mit allen Objekten die man im
Haus so am Bus hängen hat. Also Lampen, Schalter, Temperatursensoren
usw.
Die kann man nun per Draq&Drop direkt auf dem Grundriss, der rechts in
Software eingeblendet wird platzieren.
Jedem Objekt kann man dabei auch nen Icon zuweisen wenn man das möchte,
andernfalls wirds einfach als farbiger Kreis mit Namen daneben oder so
dargestellt.

Zu 3)
Einfache Lösung:
Man schreibt sich selbst ne kleine Serveranwendung die TCP/IP spricht,
auf der sich jede x-beliebige andere Anwendung einloggen kann. Ob das
nun ein Webserver, ein C++ Programm oder ne Java Anwendung ist, ist
dieser Serveranwendung die den Zugriff auf das Bussystem bereitstellt
egal solange sich alle an die Standards halten.

Und nicht falsch verstehen: Das die Anwendung über TCP/IP kommuniziert
heisst nicht, das man übers Netzwerk drauf zugreifen MUSS. Das geht
auch auf dem gleichen Rechner auf dem die Serveranwendung läuft.

Autor: D. H. (slyd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das

*(oder auch Befehlssequenzen die auf dem Bussystem übertragen werden
müssen um die Knoten entsprechend zu konfigurieren sofern das
erforderlich ist)*


sollte eigentlich fettgedruckt
erscheinen - vielleicht baut unser Foren admin ja demnächst noch sowas
wie BBCODE hier ein wo wir doch schon Code Tags haben ;)

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur noch mal kurtz wegen Sicherheit:

Es ist ein himmelweiter Unterschied, ob Du Fernwartung über
Telefon/Modem machst, mit einer dedizierten Telefonnummer für die
Anlage, oder über Internet.

Bei der Telefon/Modem-Variante ist prinzipiell Man-In-The-Middle-Attack
extrem schwerer, wenn nicht sogar für 99,999% der Angreifer unmöglich
(Wer kann schon das digitale Vermittlungssystem der Telefon-Konzerne
manipulieren)?

Zweitens, selbst das Abhören einer Telefonverbindung ist für die
meisten Angreifer faktisch unmöglich.

Drittens kann der Anschluss der fernzuwartenden Anlage so konfiguriert
sein, dass er ausschliesslich Anrufe von bestimmen Nummern annimmt
(Caller-ID), z.B. ausschliesslich das Handy vom Hauseigentümer.

Und erst jetzt kommt bei der Fernwartung per Telefon/Modem der
Benutzername und das Passwort.

Java-Applets, Sub-Domains usw. nützen da überhaupt nichts. Es ist
mathematisch, praktisch und theoretisch unmöglich, ein nicht
kontrollierbares, unsicheres System durch Software sicher zu machen.

Die Sicherheit kommt bei mir bei einer Web-Anwendung, speziell im
Internet, an erster Stelle. Die Sicherheit ist nämlich die
entscheidende Archillesferse.

Alles andere ist purer Leichtsinn oder grenzenlose Naivität.

Und wenn einer Firma XYZ die Sicherheit einer Fernwartung ziemlich egal
ist, und sie ausschliesslich auf Name/Passwort vertrauen, so sollen sie
das ruhig tun. Nur ist das kein Grund dass das Stand der Technik ist
oder sogar ein Beweis dafür, dass es doch gut geht.

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Unbekannter,
ich habe nun endlich verstanden, dass es kein unendlich sicheres System
gibt.
Der Firma XYZ ist die Sicherheit nicht egal. Ich kenne all die Leute
die mit dem richtigen Tool in 5 Minuten jeden Rechner im Internet
hochnehmen. Nur zeigt es mir keiner. Vielleicht ja Du. Mein Netzwerk
mit einigen Rechnern findest man spätestens über meine email-Adresse.
Außer meinen embedded-Webserver hat noch keiner einen Rechner besucht.
Und den habe ich explizit nicht geschützt.

Koopi

Autor: ELEKTROJOCHEN (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus kennt ihr die Technik des FS20 Funkschaltsystem von ELV???
So was in der Art wäre genial das ganze AVR und Funkgesteuert
(Umbauarbeiten vermeiden) Und bei Bedarf die möglichkeit das ganze mit
Pc zu visualisiern und zu verwalten.


http://www.elv.de/Main.asp?Menue=Shop&Gruppe=HT-HA...

Hoffe der link läuft

GRUSS JOCHEN

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sicherheit:

Wie bei der bank mit TAN's dann sollte es wirklich sicher sein!!

Autor: Thomas Kropf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Matthias Beitz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.