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?)
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 .
@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
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.
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/software/big/software3.jpg http://www.dsh-elektronik.de/arcrobot/fotos/software/big/software_sim.jpg 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...
@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
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.
@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.
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
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
@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 ;)
@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.
@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:
1 | /*
|
2 | Anmerkung: IM FOLGENDEN NENNE ICH AUS ZEITGRÜNDEN NUR EIN BEISPIEL und
|
3 | gehe nicht auf alle möglichen Fälle ein. 100%ig ist auch noch nichts
|
4 | festgelget, das kann alles noch variieren und da ich nicht ewig Zeit
|
5 | habe um das folgende zu schreiben können da auch noch kleine Fehler
|
6 | drin sein, die aber leicht behoben werden können.
|
7 | |
8 | Nur um das schonmal Klarzustellen:
|
9 | Mit dem Konzept wie ich es mir vorstelle, kann man natürlich auch
|
10 | Timer-Events o.ä. konfigurieren wenn man das entsprechend vorsieht...
|
11 | Aktoren zu Gruppen zusammenzufassen geht ebenfalls, indem man jedem
|
12 | Aktor bestimmte Gruppenevents zuweist auf die er reagieren soll. Das
|
13 | kann auch, damit es für den DAU (Ich setze "DAU" mal mit dem Anwender
|
14 | gleich, der null Ahnung vom Bussystem hat) übersichtlicher wird, über ne
|
15 | komfortable Eingabemaske passieren, die diese Einstellungen automatisch
|
16 | erzeugt...............
|
17 | */
|
_
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.
@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
@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...
@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
@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.
@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.
@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.
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 ;)
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.
@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
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-FH&stufe=3&SessionId=00193493650500240504 Hoffe der link läuft GRUSS JOCHEN
Sicherheit: Wie bei der bank mit TAN's dann sollte es wirklich sicher sein!!
Offtopic: Is ja lustig :) http://kdirstat.sourceforge.net/screen-shots/kdirstat-main.png http://www.methylblue.com/filelight/images/filelight_0.6.3-2.png
Thread beobachten
Seitenaufteilung abschalten
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.