Forum: Haus & Smart Home [OS-HB] PC-Steuersoftware


von Ithamar Garbe (Gast)


Lesenswert?

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?

von Guido B. (buschi)


Lesenswert?

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 ;-)

von Hardy (Gast)


Lesenswert?

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!

von Ithamar Garbe (Gast)


Lesenswert?

@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.

von reloni (Gast)


Lesenswert?

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

von Jan K. (jeangonzales)


Lesenswert?

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

von Ithamar G. (antimon)


Lesenswert?

@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...

von reloni (Gast)


Lesenswert?

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

von Ithamar G. (antimon)


Lesenswert?

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.

von reloni (Gast)


Lesenswert?

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

von Hans (Gast)


Lesenswert?

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

von reloni (Gast)


Lesenswert?

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

von Ithamar G. (antimon)


Lesenswert?

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

von Hans (Gast)


Lesenswert?

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

von Ithamar G. (antimon)


Lesenswert?

Ä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...

von Hans (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.