Originally posted by: <email address deleted>
Damit es nicht langweilig wird, hier schon die nächste Idee. Ich habe in
meinem Haus einen VDR-Server im Keller und 2 yaVDR-Clients (Version 0,4),
was ja Ubuntu-Installationen mit speziellen VDR-Paketen sind, außerdem ist
dort standardmäßig XBMC installiert, sowie von mir selbst ein MPD Server,
weiterhin nutze ich die Kisten als Pulseaudio-RTP-Receiver für das
synchrone Multiroom-Audio (wenn mal ne Party ist...)
Was will ich erreichen
- in FHEM jederzeit Informationen über den Zustand der Clients (server
lassen wir erstmal weg)
- Events bei ZUstandsänderungen
- Möglichkeit, per "set" jeden gewünschten Zustand herbeizuführen
Ein Zustand kann hierbei z.B. sein, dass das gesamte System AUS ist. Es
kann aber auch sein, "XBMC läuft und es wird der Film
abgespielt bei der aktuellen Position 00:40:52". Oder "VDR läuft und schaut
Fernsehen auf Kanal 10".
Ich habe mal überlegt, was es genau für Zustände geben kann und anbei mal
die Liste. Was haltet ihr von dieser "projekt"-Idee? Ich habe die Clients
an FS20-Zwischensteckern, kann die also wirklich auch hart abschalten.
Bei dem Setzen der Zustände dauert es ja teilweise eine WEile, bis der
gewünschte Zielzustand erreicht ist (wenn die Kiste erstmal hochfahren muss
z.B.) Daher sollte ein Zielzustand von einem Istzustand unterschieden
werden und das entsprechende "Device" dann auf die Erreichung des
Zielzustandes nach einer vernünftigen Zeit überwachen um ggf. Maßnahmen
einleiten zu können (z.B. nochmal verrsuchen alles runterzufahren,
Steckdose aus, nach kurzer Zeit wieder an, usw)
Folgendes ist mir eingefallen:
off (keine Ping-Antwort)
dormant (Ping ja, kein ssh check, kein connect auf VDR, auf MPD oder auf
XBMC)
idle (Ping ok, ssh check ok, kein Service an)
VDR an (SVDRP Port offen)
XBMC an (XBMC Port offen)
MPD an (MPD Port offen)
pulseaudio-rtp-client (PA-Port offen)
----
wenn VDR an, folgende Infos:
Fernsehmodus
- Kanal
Video-Wiedergabemodus
- Videoname / Nummer
- Play oder Pause
wenn XBMC an
- Idle
- Abspielen
- Musik
- Video
- jeweils Pfad/Dateiname
- jeweils Play/Pause
- TV-Modus
- TV -> Kanal (vom XVDR-Server)
- Wiedergabe -> Nummer (vom XVDR-Server)
- Plugin, z.B. youtube
.....
wenn MPD an
- Play/Pause/Song etc.
etc. etc.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Klingt gut - aber sollte man dann nicht etwas allgemeiner herangehen ?
Für FHEM wäre ein Modul wünschenswert, das von beliebigen anderen Systemen
per Ethernet irgendeinen Zustand abfragen kann (wird zurückgeliefert als
XML-Datei). In einer anderen Datei (nenn sie *.cfg) ist ein Modell des
anderen Systems abgelegt, zusammen mit den erwünschten Zustandsänderungen.
FHEM bietet dann (grafisch ?) eine Darstellung dieser Zustände, und erlaubt
das Auslösen der Übergänge.
Damit könnte man dann die internetfähige Waschmaschine genauso steuern, wie
den VDR-Server.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Die Idee, dies per XML-Konfiguration und somit weitgehend parametrisch und
nicht algoritmisch zu machen ist an sich ja sehr gut und sicher auch
erstrebenswert. Ich fürchte nur, wenn ich überhaupt ein Ergebnis will, muss
ich jetzt das spezielle lösen und mit der Erfahrung die ich dabei gewinne
ggf. eine allgemeine Lösung bauen.
Es ist eben in meiner Vorstellung weit mehr als die Abfrage eines Zustandes
per Ethernet. Für die verschiedenen Anwendungen müssten unterschiedlichste
Dinge gemacht werden. Die Grundzustände lassen sich noch per Check auf
offenen Port prüfen jedoch muss man für die Ermittlung des internen
Zustandes von XBMC z.B. schon einige JSON-RPC Abfragen an die API schicken
und die Antworten auswerten, MPD hat ein ganz eigenes Protokoll, ebenso der
VDR mit der SVDRP-Schnittstelle.
Was ich versuchen sollte zu berücksichtigen ist vll zumindest eine
Baumstruktur
1. Ethernet-Gerät
1.1. hat ein Linux-OS
1.1.2 hat einen installierten VDR (per config beschrieben)
1.1.3 hat ein installiertes XBMC (...)
1.1.4 hat ein installiertes MPD
1.1.5 hat eine installierte Webcam nutzbar als Bewegungsmelder...
1.1.6 usw.
1.2 lässt sich über FS20-Dose abc vom Strom trennen
usw...
Am Mittwoch, 28. März 2012 15:48:26 UTC+2 schrieb Prof. Dr. Peter A.
Henning:
>
> Klingt gut - aber sollte man dann nicht etwas allgemeiner herangehen ?
>
> Für FHEM wäre ein Modul wünschenswert, das von beliebigen anderen Systemen
> per Ethernet irgendeinen Zustand abfragen kann (wird zurückgeliefert als
> XML-Datei). In einer anderen Datei (nenn sie *.cfg) ist ein Modell des
> anderen Systems abgelegt, zusammen mit den erwünschten Zustandsänderungen.
>
> FHEM bietet dann (grafisch ?) eine Darstellung dieser Zustände, und
> erlaubt das Auslösen der Übergänge.
>
> Damit könnte man dann die internetfähige Waschmaschine genauso steuern,
> wie den VDR-Server.
>
> LG
>
> pah
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Salve,
On 03/28/2012 02:29 PM, unimatrix wrote:
> Damit es nicht langweilig wird, hier schon die nächste Idee. Ich habe in meinem
> Haus einen VDR-Server im Keller und 2 yaVDR-Clients (Version 0,4), was ja Ubuntu-
> Installationen mit speziellen VDR-Paketen sind, außerdem ist dort standardmäßig
> XBMC installiert, sowie von mir selbst ein MPD Server, weiterhin nutze ich die
> Kisten als Pulseaudio-RTP-Receiver für das synchrone Multiroom-Audio (wenn mal ne
> Party ist...)
Für letzteres bin ich ja Squeezebox-Fan geworden, sodaß bei mir da der entsprechende
squeezeplay[er]-Prozeß zu überwachen wäre (oder gleich alles über Squeezecenter, was
auf der yaVDR (0.3) im Wohnzimmer mitläuft).
> Was will ich erreichen
> - in FHEM jederzeit Informationen über den Zustand der Clients (server lassen wir erstmal weg)
> - Events bei ZUstandsänderungen
> - Möglichkeit, per "set" jeden gewünschten Zustand herbeizuführen
>
> [...] Was haltet ihr von dieser "projekt"-Idee? Ich habe die Clients an FS20-Zwischensteckern, kann die also wirklich auch hart abschalten.
Ernsthafte Frage? Ernsthafte Antwort: wozu das Ganze? Was nützt Dir die Information,
daß der VDR-Server "Kanal 10" "schaut"?
Sinnvoll wäre ein "VDR ping", wo beim Ausbleiben den "pong" dann FS20 zündet -- wobei
meine Probleme mit VDR mehr a) am Frontend liegen (das friert bei yaVDR 0.3 gerne mal
ein und scheint auch ein Speicherleck zu haben) und b) beim Dockstar als VDR-Server im
Keller in den per USB angebundenen DVB-S2-Receivern zu suchen sind.
FTR, ich habe zwei VDR-Server im Keller, einen im RZ, einen im Appartment in Berlin
(DVB-T). Der VDR im Wohnzimmer hat Zugriff auf einen eigenen USB-DVB-S-Empfänger und
eben die besagten Server, wobei Berlin mangels Upstrem natürlich nicht wirklich
funktioniert -- das ist eher zum hin- und herkopieren der Aufzeichnungen.
Bedarf in FHEM sehe ich nur an einem allgemeinen "VDR is/is not running", "8h+ Kapazität
sind noch frei" oder so; alle anderen Infos gehören doch mehr auf den Zusatzbildschirm
zum jeweiligen Server (Stichwort LC-Display-Plugin).
MfG,
-kai
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> F�r letzteres bin ich ja Squeezebox-Fan geworden, soda� bei mir da der
> entsprechende
> squeezeplay[er]-Proze� zu �berwachen w�re (oder gleich alles �ber
> Squeezecenter, was
> auf der yaVDR (0.3) im Wohnzimmer mitl�uft).
>
K.a. von dem Ding, aber das wäre ein weiteres Sub-Modul so wie oben
überlegt.
> Ernsthafte Frage? Ernsthafte Antwort: wozu das Ganze? Was n�tzt Dir die
> Information,
> da� der VDR-Server "Kanal 10" "schaut"?
>
Ganz einfach: Ich kann einen Status-Transfer vom Wohnzimmer aufs
Schlafzimmer machen damit nach Duschen / Zähneputen das Programm an der
gleichen Stelle an anderem Client weiterläuft :) ... also nich was der
Server schaut sondern was jemand am Client schaut meinte ich.
> Sinnvoll w�re ein "VDR ping", wo beim Ausbleiben den "pong" dann FS20
> z�ndet
>
richtig, das ist Grundfunktion
> -- wobei
> meine Probleme mit VDR mehr a) am Frontend liegen (das friert bei yaVDR
> 0.3 gerne mal
> ein und scheint auch ein Speicherleck zu haben) und b) beim Dockstar als
> VDR-Server im
> Keller in den per USB angebundenen DVB-S2-Receivern zu suchen sind.
>
Aus genau dem grund hab ich mir irgendwann einen "richtigen" Server mit PCI
Karten hingestellt...hatte auch nur Ärger und das geht gar nicht wenn die
Frau was wichtiges schaut :)
Was ich da beschrieben habe, hat natürlich eine gewisse
Watchdog-Komponente, war jedoch gar nicht mein primärer Gedanke.
> Bedarf in FHEM sehe ich nur an einem allgemeinen "VDR is/is not running",
> "8h+ Kapazit�t
>
> sind noch frei" oder so; alle anderen Infos geh�ren doch mehr auf den
> Zusatzbildschirm
> zum jeweiligen Server (Stichwort LC-Display-Plugin).
>
Um Visualisierung geht es mir gar nicht. Ich will nix visualisieren. Mein
Haus soll so aussehen wie ein stinknormales. Die ganze Intelligenz ist
versteckt und für den Anwender nur am Rande wahrnehmbar. Daher betreffen
mich auch diese aktuellen Entwicklungen wie Floorplan überhaupt nicht. Für
den Anwendungszweck "User will bewusst ein bestimmtes Licht schalten" gibt
es aus meiner Sicht nur eine gute Lösung und die heisst Lichtschalter. Was
im Hintergrund dabei passiert, braucht er nicht zu wissen. Und wenn man
gerade um 19:50 vom Einkaufen nach Hause kommt und den Lichtschalter am
Eingang drückt, kann das eben auch dazu führen, dass der VDR schonmal
angeht auf Kanal 1 ...
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Die Idee mit dem allgemeinen Herangehen habe ich nochmal genauer überdacht
und bin inzwischen soweit, wohl doch eher allgemen herangehen zu wollen :)
Ein Problem was ich aber berücksichtigen muss ist eine gewisse
Klassenhierarchie und hier bin ich noch nicht sicher, wie ein Mapping in
FHEM sinnvoll sein könnte.
Eine recht allgemeine "Klasse" in diesem Modell wäre also z.B. ein
Linux-Rechner, wobei dies sowohl ein embedded-Device (Router, Fritzbox,
Dockstar) als auch ein normaler PC sein kann. Diese Klasse hätte einige
Pflichtattribute (z.B. einen Hostnamen) und auch optinale Attribute (z.B.
ein FS20-Device, welches die Steckdose ist, an dem der Rechner hängt). Ein
anderes Pflichtattribut könnte sein "Shutdown-Kommando" - hier ist ein
Kommando hinterlegt , mit dem der Rechner runtergefahren werden kann. Also
z.B. das Ausführen eines "shutdown" Befehls über eine Remote Shell und dann
nach einem Timeout das Ausschalten der FS20-Dose. Auch ein
Einschalt-Command müsste konfiguriert sein. Z.B. Einschalten der FS20-Dose
oder anders: Wake on LAN. Dann ggf. nach Timeout Prüfung, ob Einschalten
erfolgreich war (Ping-Test, Selbsttest über Remote-Shell).
Nun müsste man basieren auf dieser sehr allgemeinen Klasse möglicherweise
speziellere Klassen (welche die Eigenschaften der allgemeinen Klasse erben)
deklarieren. Z.B. eine Klasse Fritzbox, die nochmal speziellere
Pflichtattribute hat
Nun sind diese Linux-Kiste kein Selbstzweck sondern sie dienen als
Container für Applikationen, wobei auf einer Kiste eine oder mehrere
Applikationen laufen könne, wobei es solche gibt, die parallel laufen
können und andere, dessen Betrieb sich gegenseitig ausschliesst. So kann
z.B. ein VDR-Server (ohne Monitor) gleichzeitig mit einem MPD-Server
laufen, der Musik via RTP ins Netzwerk streamt. Auf einem Client kann aber
nicht (oder nicht sinnvoll) gleichzeitig dieser RTP-Stream abgespielt
werden "Musik-Modus" und parallel per VDR-Client TV geschaut werden
und/oder parallel per XBMC ein Film geschaut werden
Diese Applikationsklassen müssten also eigens definiert werden, auch sie
hätten Pflichtattribute und optionale Attribute. Ein Pflichtattribut für
alle diese Klassen ist z.B. eine Referenz auf das Host-Objekt (den
Linux-PC)
Nehmen wir nun mal den Grundzustand eines Hauses (mein Master-Objekt (nur
im Kopf)) - alles ist ausgeschaltet. Nun kommt der Anwender plötzlich auf
die Idee, dass er im Wohnzimmer ein bestimmtes Album hören möchte und ind
er Küche am besten auch, weil er da ab und zu ja hingeht. Das Kommando an
das System wäre also "1. Spiele Album XY ab; 2. Höre diesem Abspielen in WZ
und 3. Küche zu"
Das 1. Kommando geht an die Applikation MPD-Server (z.B. im Keller). Dessen
Existenz ist dem Anwender bekannt. Das 2. Komande geht an die Applikation
"Musik-Abspieler im WZ" und das 3. Kommando an die Applikation
"Musik-Abspieler in Küche"
Nun muss das System die gewünschten Zustände der Applikationen setzen, hier
mal sinngemäß in Pseudo-FHEM-"Code":
set mpdserver1 play playlist radio1
set wz_musik listento mpdserver1
set kueche_musik listento mpdserver1
Jetzt sind ja sowieso alle Rechner noch komplett aus. Der mpdserver1 muss
also nun erstmal irgendwie seinen Host dazu bewegen, sich einzuschalten und
ihm dann irgendwann ein "Ready" zu quittieren, damit dann die Applikation
ihrerseits sich hochfährt und entsprechend des Befehls konfiguriert (also
die Playlist laden, abspielen, den Output zum Pulseaudio-Server aktivieren,
usw.)
Gleichzeitig muss dass in der Küche und WZ entsprechend ablaufen. Dabei
muss immer der Ausgangszustand der Geräte egal sein. Hat man im WZ vorher
fernseh geschaut, wird diese Applikation einfach beendet, der Host geht in
eine Art "ich bin bereit für alles"-Zustand und dann geht das los, was der
Anwender wollte.
Uff jetzt hab ich Kopfschmerzen. Ist irgendwem noch klar, wie ich das alles
meine ???
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Uff jetzt hab ich Kopfschmerzen. Ist irgendwem noch klar, wie ich das alles
> meine ???
Fuer den Fall, dass die Kopfschmerzen nicht ausreichend sind :)
Mich erinnert das unweigerlich an das angedachte Bier-brauen-mit-fhem Projekt
von Remo: in beiden Faellen muessen je nach Zustand bestimmte Aktionen
getriggert werden, die Aktionen ueberwacht, und falls nach einem Timeout nicht
das gewuenschte eintrifft, dann muss errorhandling ausgeloest werden.
Also eine Tabelle wie
Zustand: Z3
Voraussetzung: Z1,Z2
Befehl B3
PruefungObErreicht P3
PruefIntervall I3
Timeout T3
ErrorHandling E3
Zustand2 -> Zustand3
Befehl X2
...
Und ein Framework, der ausrechnet, was man alles fuer einen bestimmten Zustaend
benoetigt, und alles noetige startet, ueberwacht, und die Zustandsuebergaenge
ausloest.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Du hast recht...diese Tabelle ist ganz genau das was man tun
muss....arghhh..
Und das dann für jeden Zustand bzw. Zustandsübergang.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Da ich gerne iterativ arbeite implementiere ich gerade ein relativ
statisches Testmodul.
So oder so kommt man aber zu dem Punkt, wo man "warten" muss. Da FHEM ja in
einem einzigen Prozess läuft, ist mir nicht klar, wie man das geschickt
löst.
Beispiel:
FS20 off
30 sekunden warten
FS20 wieder an
Ist die Lösung ein fork() oder hat das negative Effekte? (Speicher, etc.)
VG
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> So oder so kommt man aber zu dem Punkt, wo man "warten" muss. Da FHEM ja in
> einem einzigen Prozess läuft, ist mir nicht klar, wie man das geschickt
> löst.
Ich wuerde z.Zt InternalTimer() empfehlen. Am besten packt man die Aufgaben-
Teile in eine Datenstruktur (Array?), damit man nicht so viele Funktionen bauen
muss.
> FS20 off
> 30 sekunden warten
> FS20 wieder an
set FS20 off;; sleep 30;; set FS20 on
Sleep (und damit meine ich das fhem Kommando) traegt sich neuerdings via
InternalTimer in die WarteListe ein, und blockiert fhem nicht mehr. Wenn die
Zeit abgelaufen ist, dann ruft sie alle Befehle hinter dem sleep auf.
> Ist die Lösung ein fork() oder hat das negative Effekte? (Speicher, etc.)
Speicher wuerde ich erstmal vernachlaessigen, aber Du musst mit dem
Haupt-Server kommunizieren, und evtl. mit anderen Prozessen synchronisieren.
Dafuer kann man auch in perl dann gefahrlos "sleep 30" verwenden.
Die Alternative ist ein thread-faehiges perl, was wiederum nicht ueberall
standard ist, und noch aufwendiger bzgl. synchronization ist.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
> Hi,
>
>
wenn es nur um den VDR geht habt ihr doch mit FHEM fertige Arbeit.
ECMD und SVDRP lösen das Steuern der einzelnen VDRs.
SVDRP sollte ja allen VDR Usern bekannt sein.
http://www.vdr-wiki.de/wiki/index.php/SVDRP
Das Hoch- und Runterfahren kann hierdurch erfolgen:
http://www.wehavemorefun.de/fritzbox/index.php/Ether-wake
Wenn es um ux'e generell gehen soll ist es vielleicht möglich über
SNMP nachzudenken. Hierfür kann man sich dann für alle möglichen
Funktionen SNMP MIBs basteln. SNMP Dämonen gibt es fertig ;)
Mit einer SNMP Integration in FHEM könnte ich mir dann auch vorstellen,
in kleinen Netzen Router, Servertemperaturen und Switche mit FHEM zu
monitoren
und dann, z.B. über FS20 Aktionen wie Neustart von ISDN Routern oder
ähnlichem
auszulösen. Vollautomatisiert und mit Benachrichtigung z.B. über E-Mail.
Ideen, Ideen, Ideen.....
Gruß Andreas
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
das sind nette Ideen, auch mit SNMP mit dem ich mich leider so gut wie gar
nicht auskenne.
Der Zugriff auf die ganzen Funktionen ist kein Problem. Sowohl für VDR mit
SVDRP als auch auf XBMC (etwas aufwändiger mit JSON RPC, zumal es hier auch
Callbacks gibt).
Das abstrakte Denken über ein generisches parametrisches Modell zur
Umsetzung in FHEM ist eher das, was anstrengend ist und dann eben auch die
Abhängigkeiten der Zustände (siehe Bier Brauen). und dann noch vernetzte
Abhängigkeiten die über einen einzelnen Host hinausgehen (Beispiel: Zum
Fernsehschauen am Client muss auch der Server hochgefahren werden) UND die
Fehlerbehandlung bzw. die Überwachung darüber, ob die angestrebten
Sollzustände auch erreicht werden, das Erstellen von einer Art
Command-Stack wenn mehrere Vorbedingungen zu erfüllen sind, usw....
VG :)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
> Hi,
>
>
dan schwebt dir also soetwas vor? ;)
http://sourceforge.net/apps/mediawiki/perl-workflow/index.php?title=Main_Page#Perl_Workflow
Gruß Andreas
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
ich hätte das mal eher lesen sollen....das sieht ja phantastisch aus.
nachdem ich mich nun seit gestern abend mit der Implementierung eines
generischen Modells mit Graphen beschäftigt habe, in denen alle möglichen
Systemzustände in Knoten und dann die auszuführenden Funktionen in den
Kanten abgelegt sind um von einem Zustand in einen benachbarten zu kommen
bzw. dann über Pathfinding zum letzlich gewünschten...
Am Donnerstag, 12. April 2012 20:47:06 UTC+2 schrieb Sturi2011:
>
> Hi,
>>
>>
> dan schwebt dir also soetwas vor? ;)
>
>
> http://sourceforge.net/apps/mediawiki/perl-workflow/index.php?title=Main_Page#Perl_Workflow
>
> Gruß Andreas
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich hab den Ansatz mit dem Workflow jetzt mal weiter verfolgt und mir ein
Testsetup gebaut, welches nix anderes kann als einen Linux-Rechner an oder
auszuschalten bzw. runterzufahren oder neu zu starten. Das ganze nach
folgendem Modell. Sieht bisher ganz vielversprechend aus.
Parallell zu Workflow baue ich mir noch mit CPAN Graph die Graphenstruktur
so auf, dass ich einen Pfad finden kann. Wenn ich also in unknown bin und
will jetzt zu on dann sagt mit das Ding automatisch, ich muss jetzt den
Pfad unknown->off->boot->on gehen. Dies dispatche ich dann in einer
schleife an den Workflow
Also nur mal so als Zwichenmeldung...ich bastle weiter
mit FHEM hat das im Moment zwar nix mehr zu tun. Soweit ich das sehe
brauche ich für jeden solchen Workflow eigene Prozesse die immer laufen die
dann aber ein Interface zu FHEM haben um dort events zu generieren und auf
Wunschzustände zu reagieren und damit ich alles mit den anderen FHEM-Sachen
in Beziehung setzen kann.
VG
+---------+
+- | INITIAL |
| +---------+
| |
| |
| v
| +-------------------+ +------+
| | on | --> | halt |
| +-------------------+ +------+
| | | ^ |
| | | | |
| v | | |
| +---------+ | | |
+----+> | boot | -+----+ |
| | +---------+ | |
| | | | |
| | | | |
| | v | |
| | +---------+ | |
| +> | unknown | <+ |
| +---------+ |
| | |
| | |
| v |
| +---------+ |
+------ | off | <---------------+
+---------+
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Nachdem ich nun eckige Augen habe und die Tricks des Debuggers
kennengelernt habe, ist mir eine Implementierung gelungen, die ich in Kürze
zur Verfügung stellen werde.
Ich habe ein Workflow-Modul geschrieben mit dem man Workflow-Devices in
fhem definieren kann
- Ein Workflow-Device muss einen Typ haben, der Typ muss im Folder
vorhanden sein
- Ein typ besteht aus einem Perl-Modul und XML-Dateien zur Konfiguration
- Bisher habe ich den Typ "HostController" erstellt mit dem ich meine
Linux-Kisten im Netzwerk steuern kann
- Dem Modul liegt das cpan workflow Modul zu Grunde, welches ich aber stark
verändert / erweitert habe
- Der Workflow und die Statusübergangsbedingungen und -Aktionen sind im XML
konfiguriert und übersichtlich in den Modulen einkodiert (in perl!)
- Die Workflows/Typen sind parametrierbar (im Beispiel HostController:
Hostname und "Socket" (bei mir FS20 Dosen an denen die hängen)
- Die Workflows können sowohl den Status überwachen als auch einen
"desired"-Status ansteuern (wie ein Regler)
- Beim Überwachen reagieren Sie auf das System selbst und spiegeln den
Systemzustand in einem Reading in FHEM wieder
- Beim Steuern versucht der Workflow eigenständig einen gewünschten
("desired") Zustand durch Verkettung von Aktionen und Überwachung der
Auswirkungen / Bedingungen zu erreichen. So lange in meinem Beispiel-Typen
z.B. der desired-Zustand auf "on" steht, führt ein manuelles runterfahren
oder ausschalten der Steckdose dann wieder zum einschalten. Das Modul ist
hier hartnäckig. Das Desired-Setting kann über "set ..." gesetzt und
auch wieder entfernt werden, um das Gerät dann wieder "frei" laufen zu
lassen
- Die Implementierung nutzt viele CPAN Module und wird so z.B. niemals auf
einer Fritzbox lauffähig sein.
- Es wird pro Workflow ein eigener Thread gestartet (!!!) ... eine
thread-lose-Lösung habe ich bisher nicht.
- Die Kommunikation mit dem Subthread erfolgt über 2 shared-Variablen und
über ein Signal mit dem der Thread beim "delete " beendet wird.
Ich werde den Code noch bereinigen und dann falls gewünscht für
experimentierfreudige Personen bereitstellen. Bei einem Einsatz muss davon
ausgehen, dass ein laufendes FHEM-System instabil wird und ggf. abstürzt.
Viele Grüße!
Am Sonntag, 15. April 2012 11:27:45 UTC+2 schrieb unimatrix:
>
> Ich hab den Ansatz mit dem Workflow jetzt mal weiter verfolgt und mir ein
> Testsetup gebaut, welches nix anderes kann als einen Linux-Rechner an oder
> auszuschalten bzw. runterzufahren oder neu zu starten. Das ganze nach
> folgendem Modell. Sieht bisher ganz vielversprechend aus.
>
> Parallell zu Workflow baue ich mir noch mit CPAN Graph die Graphenstruktur
> so auf, dass ich einen Pfad finden kann. Wenn ich also in unknown bin und
> will jetzt zu on dann sagt mit das Ding automatisch, ich muss jetzt den
> Pfad unknown->off->boot->on gehen. Dies dispatche ich dann in einer
> schleife an den Workflow
>
> Also nur mal so als Zwichenmeldung...ich bastle weiter
>
> mit FHEM hat das im Moment zwar nix mehr zu tun. Soweit ich das sehe
> brauche ich für jeden solchen Workflow eigene Prozesse die immer laufen die
> dann aber ein Interface zu FHEM haben um dort events zu generieren und auf
> Wunschzustände zu reagieren und damit ich alles mit den anderen FHEM-Sachen
> in Beziehung setzen kann.
>
> VG
>
> +---------+
> +- | INITIAL |
> | +---------+
> | |
> | |
> | v
> | +-------------------+ +------+
> | | on | --> | halt |
> | +-------------------+ +------+
> | | | ^ |
> | | | | |
> | v | | |
> | +---------+ | | |
> +----+> | boot | -+----+ |
> | | +---------+ | |
> | | | | |
> | | | | |
> | | v | |
> | | +---------+ | |
> | +> | unknown | <+ |
> | +---------+ |
> | | |
> | | |
> | v |
> | +---------+ |
> +------ | off | <---------------+
> +---------+
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com