Originally posted by: <email address deleted>
Hallo an alle,
ich hatte vor ein paar Tagen hierein neues FHEM-Modul namens
*Things* vorgestellt, das sich aber in der Diskussion als vollkommen
unnötig erwies, da seine Funktionalität entgegen meiner Kenntnis bereits
von *dummy* abgedeckt war.
Mittlerweile scheint es mir aber, dass für den beabsichtigten Einsatzzweck
eine erweiterte Funktionalität nützlich wäre, die von *dummy* definitiv
nicht mehr abgedeckt wird, nämlich, auch den aktuellen Status der
gesteuerten Geräte in FHEM zu erfassen.
Diese Überlegungen will ich, statt einfach erneut selbst ein Modul zu
fabrizieren, im Folgenden zur Diskussion stellen, da
1. ich ja möglicherweise wieder etwas übersehe und die Funktionalität
bereits durch FHEM abgedeckt ist (wenn auch nicht durch *dummy*)
2. Ihr mehrheitlich der Meinung seit, dass die jetzigen Möglichkeiten,
so etwas mit FHEM zu realisieren, hinreichend sind und nichts Neues
benötigt wird
3. für eine möglichst umfassende Funktionalität die Ideen und
Bedürfnisse möglichst vieler potentieller Nutzer von Interesse sind
4. ich selbst wohl erst in etlichen Monaten die Zeit finden würde, so
was zu implementieren.
Ich darf noch anmerken *;–)* , dass ich das Modul wieder *Things* genannt
habe, weil ich mir eben keinen besseren Namen ausdenken kann. *Things* kann
aber ggf. gerne umbenannt werden (auch wenn ich mir wünschen würde, dass
kein kryptischer Techniker-Name aus irgendwelchen Buchstaben und Zahlen
dabei herauskommt ...)
*Ausgangsüberlegungen*
Was die Steuerung von Geräten betrifft, so hat eine Hausautomation wie FHEM
zwei Funktionen, einmal eben das Steuern der Geräte, aber zum zweiten auch
die Rückmeldung der augenblicklichen Status auf der Bedienoberfläche.
Bei Geräten wie etwa Lampen, deren Stromversorgung einfach über FS20 oder
ein ähnliches System geschaltet bzw. geregelt wird, ist das auf
verlässliche Weise einfach dadurch zu erreichen, dass die Sender (Schalter
etc.) nur *indirekt* über FHEM mit den Schaltaktoren gekoppelt werden, die
Sender ihre Befehle also lediglich an FHEM senden, das daraufhin
entsprechende Befehle an die Schaltaktoren absetzt. Solange sichergestellt
ist, dass die Schaltaktoren nicht auch direkt angesprochen werden können,
ist FHEM der aktuelle Status also stets verlässlich bekannt (von so etwas
wie Stromausfällen einmal abgesehen).
Anders ist das bei Geräten wie Computern oder audiovisuellen Anlagen, für
die ich *Things* gedacht hatte. Solche Geräte werden in der Regel von FHEM
aus über Netzwerk- oder Infrarot-Befehle zwischen aktivem und
Standby-Zustand umgeschaltet; vor allem aber ist FHEM hier regelmäßig nicht
die einzige Steuerungsmöglichkeit: Der Computer kann genauso gut durch
einen Tastendruck aufgeweckt werden, und die Stereoanlage über die
IR-Fernbedienung.
Daher ist FHEM der Status (Ein/Standby) solcher, über *dummy* gesteuerter
Geräte zunächst mal nicht bekannt. Ich fände das aber aus zwei Gründen sehr
hilfreich:
1. Um eben über den Status der Geräte informiert zu sein
2. Bei Geräten mit IR-Fernbedienung ist ausgerechnet Einschalten und
Ausschalten oftmals über *eine* Toggle-Taste auf der Fernbedienung
realisiert. Soll solch ein Gerät via IR von FHEM z.B. eingeschaltet werden,
so muss FHEM der aktuelle Status des Geräts bekannt sein, da FHEM den
Befehl nur senden darf, wenn das Gerät noch aus ist, aber nicht, wenn es
bereits läuft (dann würde es ja wieder ausgeschaltet).
*Augenblickliche Lösung mit FHEM*
Um diese Funktionalität im Augenblick mit FHEM zu implementieren, müsste
man in etwa Folgendes tun:
1. Das Ein- und Ausschalten wird wie gehabtmit
*dummy* realisiert. Über *notify* sind mit *on* und *off* entweder
Skripte gekoppelt, die entsprechende Befehle übers Netzwerk senden, oder
ein IR-Sender (CUNO2, ELV FS20 IRF, ...) wird angesteuert. Bei Letzterem muss
(im üblichen Fall, dass Ein/Aus getoggelt wird) aber noch via Perl-Code
eine Überprüfung des aktuellen Gerätestatus vorgenommen werden (s.o.) und
das Senden des IR-Befehls davon abhängig gemacht werden. (*Vorbehalt:*Eine explizite Statusabfrage wäre natürlich unnötig, wenn FHEM-Module eine
*Notification* nur dann tatsächlich triggern würden, wenn der dadurch zu
setzende Status sich von dem aktuellen Status unterscheidet, aber meiner
Kenntnis nach ist das *nicht* der Fall, sondern die *Notification* wird
immer getriggert.)
2. Der Status von Netzwerkgeräten wird über Anpingen im Sekundentakt
überprüft, wozu es eines eigenen, ständig laufenden Hintergrundprozesses
bedarf. Dieser Prozess benötigt Informationen über die IP-Nummern der zu
überwachenden Geräte und die zugeordneten *dummy*-Instanzen in FHEM.
Stellt der Hintergrundprozess eine Statusänderung fest (*Ping
erfolgreich > Ping nicht erfolgreich* oder umgekehrt), sendet er einen
entsprechenden *setstate*-Befehl an die entsprechende *dummy*-Instanz.
3. Der Status von allen anderen Geräten (IR-gesteuert, ... – *gibt es
nochwas?*) kann über den Stromverbrauch mit einem ELV FS20 FMS
Funk-Master-Slave-Schalter erfasst werden (*gibt es weitere
Möglichkeiten?*); via *notify* in der entsprechenden FS20-Instanz in
FHEM würde dann wiederum *setstate* in der entsprechenden *dummy*-Instanz
angesprochen.
*Lösung mit Things?*
Meine Befürchtung wäre, dass, wenn man nicht nur eines, sondern etliche
solcher Geräte hätte, das Ganze schnell zu einem schwer zu entwirrenden
Konfigurations-Tohuwabohu führen würde. Die Frage wäre also, ob sich ein *
Things*-Modul lohnen würde, das dieselbe Funktionalität unter einer
einfacheren Oberfläche verbirgt:
1. Über die *dummy*-Funktionalität hinaus würde *Things* eine *
Notification* stets nur triggern, wenn deren zugeordneter Status *
ungleich* dem aktuellen Status ist.
2. Über das Attribut *IP* kann für Netzwerkgeräte deren IP gesetzt
werden. Die Ping-Abfragen im Hintergrund werden in die Hauptschleife vom
FHEM-Server integriert; die *Things*-Instanz registriert dann die
IP-Nummer ,,ihres" Gerätes beim FHEM-Server und erhält von diesem die
entsprechenden Status-Infos zurück.
3. Wird *IP* nicht definiert, so geht *Things* davon aus, dass es
Statusinformationen von einem Funk-Master-Slave-Schalter über *setstate*erhält.
4. Unsicher wäre ich mir bei der Frage, ob *Things*, da es ja nur mit *
Notifications* sinnvoll funktioniert, für die *Notifications* eine
vereinfachte Oberfläche anbieten sollte, also etwa zwei Attribute *
onCommand* und *offCommand*, die äquivalent wären zu den beiden
Definitionen
define *someOnName* notify *things*:on "/usr/local/bin/*
some_on_command*"
define *someOffName* notify *things*:off "/usr/local/bin/*
some_off_command*"
Das wäre einerseits eleganter und kürzer, andererseits inkonsistent zum
Rest von FHEM. Und ich weiß auch gar nicht, ob das technisch zu realisieren
wäre, ohne am Ende doch (automatisiert) *notify*-Definitionen in die
Konfigurationsdatei zu schreiben.
Was meint Ihr? Wäre sowas sinnvoll? Zumindest die Integration der
Ping-Abfragen würde ja einen direkten Eingriff in den FHEM-Server-Code
bedeuten.
Im Moment ist das nur eine spontane Idee von mir aufgrund meiner
augenblicklichen Erfahrungen mit FHEM.
Uli
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Was meint Ihr? Wäre sowas sinnvoll?
Vielleicht, wenn es weiter strukturiert wird, und nicht vieles ( LAN-ping /
Strommessung / Toggle-Verfolgung) miteinander vermischt wird. Sonst ist es kein
Modul, sondern eine Loesung fuer ein konkretes Problem.
Ich glaube die Abgrenzung ist erreicht, wenn es einem aus dem Namen des Moduls
oder hoechstens einem kurzen Satz der Sinn erschliesst. Das ist bei mir noch
nicht der Fall.
Weiterhin bitte beachten:
- Boris hat angefangen eine Infrastruktur fuer gemeinsame Behandlung von Events
anzubieten (readingsBeginUpdate usw), diese Infrastruktur bietet es an events
Geraeteabhaengig nur bei Zustandsaenderung auszuloesen. Z.Zt wird diese
Infrastruktur in vielen weit verbreiteten Modulen (FS20/FHT/HM) noch nicht
eingesetzt.
- Aus externe/per Funk empfangene toggle Events (die leicht verloren gehen
koennen) auf dem Zustand zu schliessen kann leicht den fhem Zustand
durcheinanderbringen. Wem sowas wichtig ist, der sollte ueberlegen von FS20
auf HomeMatic oder vergleichbares umzusteigen.
> Zumindest die Integration der Ping-Abfragen würde ja einen direkten Eingriff
> in den FHEM-Server-Code bedeuten.
??? Das kann ich nicht nachvollziehen.
So eine Diskussion sollte lieber in der fhem-devel Gruppe stattfinden.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Mittwoch, 23. Mai 2012 09:07:17 UTC+2 schrieb Rudolf Koenig:
>
> > Was meint Ihr? Wäre sowas sinnvoll?
>
> Vielleicht, wenn es weiter strukturiert wird, und nicht vieles ( LAN-ping
> /
> Strommessung / Toggle-Verfolgung) miteinander vermischt wird. Sonst ist es
> kein
> Modul, sondern eine Loesung fuer ein konkretes Problem.
>
Je nach ,,Granularität" des Blicks ist natürlich jedes Modul eine Lösung für
ein konkretes Problem; für eine sinnvolle Untergliederung innerhalb von
FHEM habe ich noch nicht so das ,,Gefühl".
Aber die Grundidee für das Modul war natürlich schon eine ,,Vermischung"
mehrerer Eigenschaften, die zusammengenommen eben den Einsatz für eine
generische Klasse von Geräten erlauben (letztlich viel generischer als FS20
etc.). Mit einzelnen Bausteinen ließe sich das Problem ja jetzt schon in
FHEM lösen, wie skizziert, nur eben mit sehr vielen/unübersichtlichen
Einträgen in der *fhem.cfg*, und mit dem Problem, dass der Ping-Loop
unabhängig vom FHEM-Server läuft und also auch unabhängig crashen könnte,
was eine zusätzliche Inkonsistenz ermöglichen würde.
Technisch gesprochen hätte so ein Modul gegenüber *dummy* ja nur zwei
zusätzliche Eigenschaften:
1. LAN-ping
2. Befehle werden nur gesendet, wenn deren Ziel-*state* nicht mit dem
aktuellen *state* übereinstimmt (u.U. beschränkt auf eine sinnvolle
Untergruppe von states wie *on/off/dimn%*)
Dabei könnte man sich noch überlegen, ob 2.) vielleicht ein optionales
Verhalten für alle FHEM-Module sein könnte, das über ein Attribut gesetzt
wird, dann bliebe wirklich nur noch das LAN-Ping als Spezifikum übrig.
Ich glaube die Abgrenzung ist erreicht, wenn es einem aus dem Namen des
> Moduls
> oder hoechstens einem kurzen Satz der Sinn erschliesst. Das ist bei mir
> noch
> nicht der Fall.
>
,,LAN_IR"? ,,Generisches Modul für nur über LAN oder IR zu steuernde Geräte"?
- Boris hat angefangen eine Infrastruktur fuer gemeinsame Behandlung von
> Events
> anzubieten (readingsBeginUpdate usw), diese Infrastruktur bietet es an
> events
> Geraeteabhaengig nur bei Zustandsaenderung auszuloesen. Z.Zt wird diese
> Infrastruktur in vielen weit verbreiteten Modulen (FS20/FHT/HM) noch
> nicht
> eingesetzt.
>
Das heißt, Punkt 2 oben wäre bei einem Einsatz dieser Infrastruktur in dem
neuen Modul bereits abgedeckt?
Dann bliebe als Spezifikum wirklich nur der LAN-Ping übrig.
- Aus externe/per Funk empfangene toggle Events (die leicht verloren gehen
> koennen) auf dem Zustand zu schliessen kann leicht den fhem Zustand
> durcheinanderbringen.
Mir ist klar, dass das theoretisch passieren kann, aber bei indirekter
Kopplung wie im Wikivon mir beschrieben läuft das bei mir jetzt seit ein paar Monaten bei
lebhaftester Benutzung 100% zuverlässig.
Wem sowas wichtig ist, der sollte ueberlegen von FS20
> auf HomeMatic oder vergleichbares umzusteigen.
>
HomeMatic ist halt längst nicht so universell und auch nichts Halbes und
nichts Ganzes, da immer noch nicht wirklich verschlüsselt. Ich habe auf der
*Light & Building* lange mit jemandem von RWE darüber gesprochen, dass eine
Öffnung von deren ja auch von eQ-3 produziertem System für sie sehr
fruchtbar sein könnte, und vielleicht tut sich da was.
> > Zumindest die Integration der Ping-Abfragen würde ja einen direkten
> Eingriff
> > in den FHEM-Server-Code bedeuten.
>
> ??? Das kann ich nicht nachvollziehen.
>
Mein Vorschlag war ja, die Ping-Abfragen nicht in einem eigenen Prozess
laufen zu lassen, sondern im Main Loop von FHEM, einfach, um die
Inkonsistenz zu verhindern, dass FHEM zwar noch läuft, der Ping-Loop aber
gecrasht ist und daher die Status-Angaben nicht mehr stimmen. Alternativ
müsste der Main-Loop permanent überwachen, ob der Ping-Loop noch läuft.
So eine Diskussion sollte lieber in der fhem-devel Gruppe stattfinden.
>
Ooops, von der wusste ich noch gar nichts. Weißt Du, ob man Threads in
google groups ,,umziehen" kann, soll ich den Vorschlag dort nochmal posten,
oder was wäre am besten?
Uli
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Abgesehen von meiner Kritik an der Benennung "Things" - die ich hiermit in
vollem Umfang aufrecht erhalte ! - erzeugt in meiner Auffassung diese
Vielzahl von Skripten, externen Programmen und Rückmeldewegen genau das
Wirrwarr, das sie angeblich vermeiden soll.
Für die Zustandsüberwachung gibt es bereits jetzt mehrere Wege
- Homematic
- FS20 mit separatem Rückkanal (setze ich wunderbar bei der Überwachung
meiner Gartenbewässerung ein)
- bei beliebigen Aktoren: sie einmal täglich in einen definierten Zustand
zu versetzen
Es fehlt also der Use Case.
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Mittwoch, 23. Mai 2012 16:29:28 UTC+2 schrieb Prof. Dr. Peter A. Henning:
>
> Abgesehen von meiner Kritik an der Benennung "Things" - die ich hiermit in
> vollem Umfang aufrecht erhalte ! - erzeugt in meiner Auffassung diese
> Vielzahl von Skripten, externen Programmen und Rückmeldewegen genau das
> Wirrwarr, das sie angeblich vermeiden soll.
??? Ohne das vorgeschlagene Modul wären es mehr externe Programme/Skripte,
das ist doch einer der Punkte hinter dem Vorschlag.
Für die Zustandsüberwachung gibt es bereits jetzt mehrere Wege
> - Homematic
> - FS20 mit separatem Rückkanal (setze ich wunderbar bei der Überwachung
> meiner Gartenbewässerung ein)
>
Das ist hier völlig irrelevant, da es ja definitionsgemäß gerade
ausschließlich um Geräte geht, die *nicht* via FS20, Homematic etc. in der
Stromversorgung *geschaltet* werden können, sondern nur via LAN/IR auf
sleep/wake gesetzt werden können.
- bei beliebigen Aktoren: sie einmal täglich in einen definierten Zustand
> zu versetzen
>
Das hilft für eine sekundengenaue Statusüberwachung unheimlich viel ...
Abgesehen davon ist es ja gerade eines der zu lösenden Probleme, wie man
Geräte, die nur via IR zwischen Ein und Aus getogglet werden können,
überhaupt in einen definierten Zustand versetzen kann.
> Es fehlt also der Use Case.
>
Nicht ,,Es", ,,Mir"! Ist ja schön für Dich, wenn Du's nicht brauchst; ich
brauche es, und andere vielleicht auch – deswegen das Meinungsbild hier.
Uli
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Wie wäre es denn damit: Machen, nicht reden. Vielleicht wird es ja der
Knaller, den jeder unbedingt installieren möchte.
Abgesehen vom hybrischen Namen gibt es ja noch nicht viel.
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Mittwoch, 23. Mai 2012 17:26:48 UTC+2 schrieb Prof. Dr. Peter A. Henning:
>
> Wie wäre es denn damit: Machen, nicht reden.
Genau das habe ich bei meinem ersten Anlauf ja getan, mit dem Ergebnis,
dass sich das Ganze als unnötig herausstellte.
Daraus klug geworden, wollte ich beim zweiten Anlauf zuvor ein Meinungsbild
einholen, auch, weil es sich hier um ein komplexeres Unterfangen handelt,
wo es vielleicht mehr Nutzerwünsche gibt und bei dem es vielleicht nicht so
sinnvoll ist, als Neuling alleine vor sich hinzuwurschteln.
Wenn das als sinnvoll erachtet wird, werde ich gerne daran arbeiten, habe
dafür selbst die Zeit aber halt erst in einigen Monaten.
Das hatte ich aber alles schon eingangs geschrieben ...
Abgesehen vom hybrischen Namen gibt es ja noch nicht viel.
>
Das haben Konzepte so an sich ...
Und was den Namen betrifft, würden Dich LAN_IR oder SLEEP_WAKE glücklicher
machen?
Uli
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Persönliches Glück suche ich sicher nicht in FHEM...
Ja, der letztere schon. Denn er drückt etwas über die Funktion aus. Und das
sogar doppelt. Weil "sleep" eine perl-Funktion ist, wäre es sinnvoll, den
zweiten Teil des zweiten Vorschlags mit dem ersten zu kombinieren - etwa so
ähnlich wie "remoteWake". Das soll aber kein konkreter Vorschlag sein.
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Das heißt, Punkt 2 oben wäre bei einem Einsatz dieser Infrastruktur in dem
> neuen Modul bereits abgedeckt?
Ja.
> Dann bliebe als Spezifikum wirklich nur der LAN-Ping übrig.
Damit waere der Name des Moduls festgelegt: 91_ping.pm :)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
On 05/23/2012 01:54 AM, Uli Zappe wrote:
> *Ausgangsüberlegungen*
>
> Was die Steuerung von Geräten betrifft, so hat eine Hausautomation wie FHEM zwei Funktionen, einmal eben das Steuern der Geräte, aber zum zweiten auch die Rückmeldung der augenblicklichen Status auf der Bedienoberfläche.
>
> Bei Geräten wie etwa Lampen, deren Stromversorgung einfach über FS20 oder ein ähnliches System geschaltet bzw. geregelt wird, ist das auf verlässliche Weise einfach dadurch zu erreichen, dass die Sender (Schalter etc.) nur /indirekt/ über FHEM mit den Schaltaktoren gekoppelt werden, die Sender ihre Befehle also lediglich an FHEM senden, das daraufhin entsprechende Befehle an die Schaltaktoren absetzt. Solange sichergestellt ist, dass die Schaltaktoren nicht auch direkt angesprochen werden können, ist FHEM der aktuelle Status also stets verlässlich bekannt (von so etwas wie Stromausfällen einmal abgesehen).
Nein. Das ist *definitiv* *nicht* der Fall für FS20 (oder InterTechno). Der *Regelfall* mag sein, daß das Signal durchkommt und der Aktor wie instruiert schaltet; *verläßlich* ist dies bei FS20 nicht, weder in der Theorie noch, leider, in der Praxis.
[...]
> 3. Der Status von allen anderen Geräten (IR-gesteuert, ... – /gibt es nochwas?/) kann über den Stromverbrauch mit einem ELV FS20 FMS Funk-Master-Slave-Schalter erfasst werden (/gibt es weitere Möglichkeiten?/); via /notify/ in der entsprechenden FS20-Instanz in FHEM würde dann wiederum *setstate* in der entsprechenden /dummy/-Instanz angesprochen.
Klar; Plugwise, EM1000, Energiesparampel, Flukso ... Der FMS ist imho etwas träge, und insbesondere, FS20 eben, wieder nur Einbahnstraße; er sendet seinen Status bei Statuswechsel. Verlierste den Status, z. B. durch FHEM-Restart, fehlt wieder ein Stück vom Glück.
Was Du eigentlich willst, sind bidirektionale Systeme, die Du befragen kannst über ihren Status. Just my 0,02 €,
-kai
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Donnerstag, 24. Mai 2012 12:01:50 UTC+2 schrieb Rudolf Koenig:
>
> > Das heißt, Punkt 2 oben wäre bei einem Einsatz dieser Infrastruktur in
> dem
> > neuen Modul bereits abgedeckt?
>
> Ja.
>
Ah,klasse! Dann ist die Aufgabenstellung ja wirklich sehr überschaubar. *:–)
*
> > Dann bliebe als Spezifikum wirklich nur der LAN-Ping übrig.
>
> Damit waere der Name des Moduls festgelegt: 91_ping.pm :)
>
Und damit wäre die größte Hürde auf dem Weg zur Erstellung des Moduls auch
schon genommen! *;–)*
Wie gesagt, ich könnte mich selbst dessen annehmen, aber leider erst im
Herbst/Winter ... *:–(*
*
*
*
Uli
*
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Donnerstag, 24. Mai 2012 12:33:17 UTC+2 schrieb Kai Siering:
>
> Nein. Das ist *definitiv* *nicht* der Fall für FS20 (oder InterTechno).
> Der *Regelfall* mag sein, daß das Signal durchkommt und der Aktor wie
> instruiert schaltet; *verlässlich* ist dies bei FS20 nicht, weder in der
> Theorie noch, leider, in der Praxis.
>
Hm, in der Theorie vielleicht nicht, in der Praxis bei mir aber schon.
(Schon klar dass nix Kritisches davon abhängen darf.)
> Was Du eigentlich willst, sind bidirektionale Systeme, die Du befragen
> kannst über ihren Status.
>
Schon klar. Aber selbst wenn es sowas in richtig gut schon gäbe, würde es
mein hier vorgeschlagenes Modul nicht überflüssig machen, weil das ja
gerade *externe* Geräte wie Audio-/Videoanlagen oder Computer so in FHEM
integrieren soll, dass FHEM auch *deren* Status kennt.
Uli
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Uli Zappe wrote:
> Am Donnerstag, 24. Mai 2012 12:33:17 UTC+2 schrieb Kai Siering:
>
> Nein. Das ist *definitiv* *nicht* der Fall für FS20 (oder
> InterTechno). Der *Regelfall* mag sein, daß das Signal durchkommt
> und der Aktor wie instruiert schaltet; *verlässlich* ist dies bei
> FS20 nicht, weder in der Theorie noch, leider, in der Praxis.
>
>
> Hm, in der Theorie vielleicht nicht, in der Praxis bei mir aber schon.
> (Schon klar dass nix Kritisches davon abhängen darf.)
Du Glücklicher. Vielleicht ist meine Umgebung auf 868 MHz zu verstrahlt,
aber es kommt nicht selten vor, daß ich FS20ST und FS20LED mehrfach ein
Signal senden muß, damit sie auch Schalten.
>
>
> Was Du eigentlich willst, sind bidirektionale Systeme, die Du
> befragen kannst über ihren Status.
>
>
> Schon klar. Aber selbst wenn es sowas in richtig gut schon gäbe, würde es
Da ein Rechner, der auf "ping" reagiert nicht zwingend funktional
lauffähig sein muß, lehne ich halbe Sachen wie eine auf DHCP-Auswertung
oder ping basierende "Statuserkennung" ab.
MfG,
-kai
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Montag, 28. Mai 2012 01:47:03 UTC+2 schrieb Kai 'wusel' Siering:
>
> Du Glücklicher. Vielleicht ist meine Umgebung auf 868 MHz zu verstrahlt,
> aber es kommt nicht selten vor, daß ich FS20ST und FS20LED mehrfach ein
> Signal senden muß, damit sie auch Schalten.
>
Meine Güte ... Nö, sowas kommt bei mir vielleicht alle 2 Jahre einmal vor. Da
ich die z.B. Backup-Festplatten meiner Computer über FS20 zum automatischen
Backup ein- und ausschalte, wüsste ich das, wenn es anders wäre ... Das mache
ich seit 2005, und bin in dieser Zeit auch einmal umgezogen, ohne dass sich
da was verändert hätte. Da musst Du schon ausgesprochen Pech haben.
Da ein Rechner, der auf "ping" reagiert nicht zwingend funktional lauffähig
> sein muß,
>
Wichtiger ist mir aber vielleicht die umgekehrte Variante: Ohne ping ist
das Gerät ganz sicher nicht normal am Laufen. Es geht mir im übrigen auch
nicht nur um Rechner, sondern um diverse netzwerkfähige Geräte, einen
Videoprojektor zum Beispiel. Und es geht mir auch nicht um 100% Sicherheit.
Es ist einfach ein hilfreicher Statushinweis.
> lehne ich halbe Sachen wie eine auf DHCP-Auswertung oder ping basierende
> "Statuserkennung" ab.
>
Meine Güte, warum sind hier denn immer alle gleich so "ultimativ"? Du musst
es ja selbst nicht so machen, aber warum "ablehnen"? Für mich wäre sowas
äußerst nützlich, für manch andere vielleicht auch.
Weißt Du eine bessere Lösung? Was wäre denn eine "ganze Sache", um etwa
herauszufinden, ob mein Projektor im Schlafmodus ist oder nicht? (Aufgrund
der Deckeninstallation könnte ich da z.B. einen FS20 FMS nur sehr schwer
installieren; außerdem ist Dir ja FS20 auch nicht sicher genug ... (ping
dürfte sicherer sein ...))
Uli
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Uli Zappe wrote:
>
> lehne ich halbe Sachen wie eine auf DHCP-Auswertung oder ping
> basierende "Statuserkennung" ab.
>
>
> Meine Güte, warum sind hier denn immer alle gleich so "ultimativ"? Du
> musst es ja selbst nicht so machen, aber warum "ablehnen"? Für mich
> wäre sowas äußerst nützlich, für manch andere vielleicht auch.
Wieder kann ich nicht für "alle" sprechen; aus meiner Sicht, weil es
einen falschen Status recht leichtfertig ermöglicht. Ein sicheres
Zeichen für einen "Ein"-Zustand ist sicherlich die elektrische
Leistungsaufnahme. Aber FS20ST in FS20MS/EM1000EM sieht schon so
verboten aus, daß dies schon aus WAF-Gründen ausscheidet (außer, man hat
entspr. Aussparungen in Wand/Möbel gefräst. Besser geeignet wäre da ein
Plugwise Stealth in der Zuleitung, was aber wegen a) nicht frei
verkäuflich und b) proprietärem Protokoll ausfällt. Zielführend wäre
digitalStrom, so jedes Gerät im Stromkreis über diesen gesteuert werden
können soll. Mit ein bißchen Hardware, die in handelsübliche
Sicherungskästen gar nicht mehr reinpaßt (zumindest weder in meiner
Eigentums- noch Mietwohnung) ...
Den Zustand von Netzwerkdevices überwacht Nagios, dafür wurde es
geschaffen. HiFi-Geräte mit Fernwirk-/Netzwerkanschluß benötigen ein
passendes Modul (welches man ggf. mal als generisches erstellen sollte,
sprich mit variablen Kommandos, die man z. B. per attr setzen kann), um
sie in FHEM sinnvoll anzubringen.
Seit ich freudig feststellte, daß mein LG-Flatscreen eine serielle
Schnittstelle hat, über die er gesteuert werden kann (ja, auch schon
wieder 4 Jahre alt) und dies in ein FHEM-Modul umsetzte, würde ich keine
Unterhaltungselektronik mehr neu anschaffen, was nicht außer von der
Couch per Fernbedienung auch (heute: über (Wireless) IP) von der
Hausautomation steuerbar (inkl. abfragbar) ist. Das ist keine Lösung für
Althardware oder für den kleinen Geldbeutel (leider); aber bevor ich mit
Ratespielen wie "ping" anfinge, würde ich eher 'nen Nebenerwerb suchen
und damit auf ein sauber integrierbares Gerät sparen ;)
Allerdings, und vielleicht ist das Teil des Miß-/Unverständnisses:
welchen Nutzen bringt Dir das wissen, ob Dein Projektor im Standby ist
oder nicht? Wenn Du ihn brauchst: einschalten. Nach Benutzung/nachts:
abschalten ...
Ich schalte nachts VCR/DVD, Wii, PS3 und sonstiges A/V-Zeuch (per FS20)
ab, bei Wahl des entsprechenden A/V-Einganges am LG wird per FHEM das
entsprechende Gerät eingeschaltet (was dank FS20 bei schlechtem Wetter
immer wieder zu Notrufen auf Papas Handy führt(e): "kannst Du bitte mal
die Wii einschalten"; mittlerweile haben wir ein Familien-Netbook und
dort dank pgm2, bzw. neuerdings FHEM-Android-App auf den Handies, ist
dies Problem mittlerweile fast gelöst. Zuverlässig funktionierende
Funk-Schalter wären echt hipp ...) -- ungefähre Rückschlüsse auf
Ein-/Aus-Status läßt die Messung dieser Geräte über einen EM1000EM zu,
aber ohne Wert pro Verbraucher ist das Kaffeesatzleserei :(
Ciao,
-kai
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Montag, 28. Mai 2012 14:40:07 UTC+2 schrieb Kai 'wusel' Siering:
>
> Uli Zappe wrote:
>
Meine Güte, warum sind hier denn immer alle gleich so "ultimativ"? Du musst
> es ja selbst nicht so machen, aber warum "ablehnen"? Für mich wäre sowas
> äußerst nützlich, für manch andere vielleicht auch.
>
> Wieder kann ich nicht für "alle" sprechen; aus meiner Sicht, weil es einen
> falschen Status recht leichtfertig ermöglicht.
>
Hmm, ich wüsste um keine besonderen Probleme mit Ping.
Ich glaube, das kommt einfach auf den Einsatzzweck an, und Du bist da
offenkundig weit professioneller ausgerichtet als ich. Ein Firmennetzwerk
würde ich auch nicht mit Ping überwachen wollen. Aber wenn ich abends im
Bett liege und mich frage, ob ich vergessen habe, den Projektor und
Medienserver im Wohnzimmer schlafenzulegen, aber lieber auf meinem iPad
nachgucke, als nochmal aufzustehen, dann würden mir auch 95%
Zuverlässigkeit locker reichen, und Ping ist sicherlich zuverlässiger.
Ein sicheres Zeichen für einen "Ein"-Zustand ist sicherlich die elektrische
> Leistungsaufnahme.
>
Ist es nicht immer. Ob ein Laptop schläft oder nicht, ist daran zum
Beispiel nicht zu erkennen, weil er entweder gar nicht am Stromnetz hängt
oder aber möglicherweise der Akku gerade geladen wird, obwohl das Gerät
schläft. Zuverlässig sind nach meiner Erfahrung hier nur Ping oder
USB-Status. ELV hatten auf meine Anregung hin mal einen USB-Master-Slave
gebaut, der sehr zuverlässig ist und den ich hier noch mehrfach im Einssatz
habe; leider gibt es das Gerät aber nicht mehr (Produktkontinuität ist ja
leider nicht gerade eine Stärke von ELV ...), und es war auch nie in FS20
integriert.
Und bei Geräten, wo das mit der Stromaufnahme funktioniert, brauchst Du
eben trotzdem pro Gerät nochmal neue Hardware, und FS20 ist doch nach
Deiner Aussage auch nicht zuverlässig.
> Aber FS20ST in FS20MS/EM1000EM sieht schon so verboten aus,
>
Das ich kein FS20 für solche Geräte benötigen würde (sie sollen ja eben
nicht ausgeschaltet, sondern nur in Standby versetzt werden), wäre das bei
mir jetzt gar nicht das Problem ...
Zielführend wäre digitalStrom, so jedes Gerät im Stromkreis über diesen
> gesteuert werden können soll. Mit ein bißchen Hardware, die in
> handelsübliche Sicherungskästen gar nicht mehr reinpaßt (zumindest weder in
> meiner Eigentums- noch Mietwohnung) ...
>
> Den Zustand von Netzwerkdevices überwacht Nagios, dafür wurde es
> geschaffen.
>
Nagios wäre für meine Bedürfnisse mit Kanonen auf Spatzen geschossen, und
mir wegen der Zusatzsoftware auf den Netzwerkgeräten auch nicht so
sympathisch (je mehr Komponenten, desto mehr kann Probleme machen ...).
Meine Grundeinstellung zu diesen ganzen Automationssachen ist eher, dass
wir uns (immer noch) in einer technologischen Frühphase befinden und
ohnehin nichts, was wir jetzt tun, auf Dauer Bestand haben wird. Deswegen
bin ich (entgegen meiner sonstigen Mentalität) hier eher sehr pragmatisch,
so nach dem Motto, Hauptsache, es funktioniert hier und heute einigermaßen.
Und gemessen daran haben alle meine "Provisorien" in diesem Bereich bislang
erstaunlich gut funktioniert.
Seit ich freudig feststellte, daß mein LG-Flatscreen eine serielle
> Schnittstelle hat, über die er gesteuert werden kann (ja, auch schon wieder
> 4 Jahre alt) und dies in ein FHEM-Modul umsetzte, würde ich keine
> Unterhaltungselektronik mehr neu anschaffen, was nicht außer von der Couch
> per Fernbedienung auch (heute: über (Wireless) IP) von der Hausautomation
> steuerbar (inkl. abfragbar) ist.
>
Ja, da sind wir uns einig.
Das ist keine Lösung für Althardware oder für den kleinen Geldbeutel
> (leider); aber bevor ich mit Ratespielen wie "ping" anfinge, würde ich eher
> 'nen Nebenerwerb suchen und damit auf ein sauber integrierbares Gerät
> sparen ;)
>
Könnte es sein, dass Du irgendeine Art von Allergie gegen Ping hast? *;–))*
Ich müsste eher meinen Haupterwerb zurückfahren, um Zeit für die
Anschaffung eines Neugerätes zu haben. Die ist nämlich aus meiner Sicht das
viel größere Problem als Geld; bei der Vielzahl technischer Geräte in
meinem Haushalt bin ich da eher auf einem ,,never change a running system,
only integrate it into FHEM"-Trip ... *;–)* Dazu kommt noch die Frage nach
dem Geräte-Design ...
Allerdings, und vielleicht ist das Teil des Miß-/Unverständnisses: welchen
> Nutzen bringt Dir das wissen, ob Dein Projektor im Standby ist oder nicht?
> Wenn Du ihn brauchst: einschalten. Nach Benutzung/nachts: abschalten ...
>
Ja, nur quält mich eben nachts oft genug im Bett die Frage ,,Hab ich nun
oder nicht?"* ;–)*
Ein zweiter Nutzen ist wie schon beschrieben der, dass Geräte, die nur über
Toggle-Befehle zwischen Ein und Standby umzuschalten sind, nur dann von
FHEM sicher in einen bestimmten Zustand versetzt werden können, wenn der
aktuelle Zustand bekannt ist.
Uli
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com