HM-SEC-SC mit FS20ST

[caldir65]

Hallo,

ich habe da ein kleines Problem:

ich habe eine FS20-Steckdose zunächst einmal mit einem FS20-Schalter gepairt, zudem wurde sie in fhem angelegt - diese Konstellation funktioniert problemlos ;-)

Code Auswählen Erweitern

define kue_Dunsthaube FS20 0783 01
attr kue_Dunsthaube icon icoLuefter
attr kue_Dunsthaube model fs20st
attr kue_Dunsthaube room Kueche


Inzwischen habe ich zuätzlich einen HM-SEC-SC Fensterkontakt mit in fhem eingebunden - auch seine events kann ich schön in fhem verfolgen

Code Auswählen Erweitern

define kue_Fenster_Kueche CUL_HM 1E30CF
attr kue_Fenster_Kueche .devInfo 810101
attr kue_Fenster_Kueche .stc 80
attr kue_Fenster_Kueche actCycle 028:00
attr kue_Fenster_Kueche actStatus dead
attr kue_Fenster_Kueche devStateIcon .*:signal_Fenster_Offen.off
attr kue_Fenster_Kueche expert 2_full
attr kue_Fenster_Kueche firmware 2.0
attr kue_Fenster_Kueche model HM-SEC-SC
attr kue_Fenster_Kueche peerIDs
attr kue_Fenster_Kueche room Kueche
attr kue_Fenster_Kueche serialNr KEQ0030091
attr kue_Fenster_Kueche subType threeStateSensor
attr kue_Fenster_Kueche webCmd open close


Jetzt habe ich beide Komponenten mittels notify zusammengebracht nach dem Motto:
- wenn Fenster zu, dann FS20ST off
- wenn Fenster auf, dann FS20ST on

Code Auswählen Erweitern

define kue_fenster_auf notify kue_Fenster_Kueche:.* { if ( Value ("kue_Fenster_Kueche") eq "open") \
{fhem("set kue_Dunsthaube on")} }

define kue_fenster_zu notify kue_Fenster_Kueche:.* { if ( Value ("kue_Fenster_Kueche") eq "closed") \
{fhem("set kue_Dunsthaube off")} }


Prinzipiell funktioniert das soweit auch, bei jedem event vom Funkschalter reagiert der FS20ST wunschgemäß. Leider wird die Steckdose auch in unregelmäßigen Abständen (ich vermute, z.B. nach Änderungen und Abspeichern der fhem.cfg via Webfrontend) abgeschaltet, was natürlich nicht von mir gewollt ist. In den Logs kann ich zwar ein Schalten des FS20ST sehen, aber keinerlei event, welches vom HM-SEC-SC ausgelöst wurde.

Wie kann ich dieses Problem jetzt umgehen? Könnte man die notify-Anweisungen quasi von einer Abfrage ummanteln, die die notify-Anweisungen nur dann zur Durchführung bringt, wenn auch tatsächlich ein event (nur opn oder close) vom Fensterschalter kommt?

Danke bereits an dieser Stelle für Eure Unterstützung

Gruß

[Zrrronggg!]

Ich weiss nicht, ob ich dir helfen kann, aber will mal paar Gedanken in den Raum werfen.

(nicht wichtig, nur der Vollständigkeit halber: "pairen" heisst, das zwei Geräte so gekoppelt werden, das nur sie miteinander kommunizieren können, aber nicht dritte Teilnehmer. Dies wird meist über Serienummer oder spezielle IDs gemacht. Dieses Verhahren wird z.b. bei FHT und HM eingesetzt, bei FS20 aber nicht. D.H.  

FS20-Steckdose zunächst einmal mit einem FS20-Schalter gepairt

Nein, hast du nicht. Du hast nur in beiden Geräten den selben Hauscode eingestellt und die selbe Kanaladresse.  Das ist aber nur eine allgemeine Anmerkung, und hat mit deinem Problem zugegeben nix zu tun)


Du verwendest Folgendes:

define kue_fenster_auf notify kue_Fenster_Kueche:.* { if ( Value ("kue_Fenster_Kueche") eq "open") \
{fhem("set kue_Dunsthaube on")} }

Zunächst weiterer kleiner Hinweis:

notify kue_Fenster_Kueche:.*

ist das selbe wie

notify kue_Fenster_Kueche

da
notify xy:.* = Beliebiges Zeichen an beliebiger Stelle beliebig oft wiederholt = alle Events
und
"notify xy" ohne weitern zusatz = alle Events

Trotzdem sollte das gehen.

Leider bist du im Weiterten zu ungenau um zu erkennen, was Problem und Fragestellung sind:

Leider wird die Steckdose auch in unregelmäßigen Abständen (ich vermute, z.B. nach Änderungen und Abspeichern der fhem.cfg via Webfrontend) abgeschaltet, was natürlich nicht von mir gewollt ist.

Was meint das GENAU?
Meinst du:
a) Ich schalte die Dunsabzugshaube bei geschlossenem Fenster über Fhem oder Fernbedienung an und dann geht die irgendwann aus obwohl das Fenster  vorher zu war und kein "schliessen" Event kommen dürfte?
Oder meinst du
b) Ich schalte die Dunsabzugshaube bei offenem Fenster über Fhem oder Fernbedienung an und dann geht die irgendwann aus obwohl das Fenster noch offen ist?

Wenn du a) meinst, könnte das daran liegen, dass das der Fensterkontakt andere Meldungen sendet, (Batteriestatus oder so, ich hab nicht mehr im Kopf, was der TRISTATE Sensor alles sendet) und dann wird dein notify getriggert und dann wird der Value überprüft und der ist closed und ... peng.

Dann sollten die Abstände aber nicht wirklich unregelmäßig sein, die Meldungen kommen in einem Intervall, welcher weiss ich aber nicht.

Das kann man sicher berücksichtigen, aber WIE am Besten, Bedarf von dir noch einer Präzision von

Jetzt habe ich beide Komponenten mittels notify zusammengebracht nach dem Motto:
- wenn Fenster zu, dann FS20ST off
- wenn Fenster auf, dann FS20ST on

Meint das:
a) Wenn das Fenster zugemacht wird, soll ein einmaliges FS20 off Event gesendet werden?
oder
b) solange das Fenster zu ist, soll die FS20 immer dann auf off geschaltet werden, wenn sie auf ON geschaltet wurde oder on ist?
(und jewils anlaog bei "on")

Also kurzum: was genau soll passieren und was genau passiert tatsächlich?

[caldir65]

[quote title=Zrrronggg! schrieb am Mi, 29 Mai 2013 23:44]
Du verwendest Folgendes:

define kue_fenster_auf notify kue_Fenster_Kueche:.* { if ( Value ("kue_Fenster_Kueche") eq "open") \
{fhem("set kue_Dunsthaube on")} }

Ich habe mir die Notify-Konstruktion aus dem Howto-PDF entlehnt und angepaßt - soweit funktioniert es ja auch

Leider bist du im Weiterten zu ungenau um zu erkennen, was Problem und Fragestellung sind:

Leider wird die Steckdose auch in unregelmäßigen Abständen (ich vermute, z.B. nach Änderungen und Abspeichern der fhem.cfg via Webfrontend) abgeschaltet, was natürlich nicht von mir gewollt ist.

Was meint das GENAU?
Meinst du:
a) Ich schalte die Dunsabzugshaube bei geschlossenem Fenster über Fhem oder Fernbedienung an und dann geht die irgendwann aus obwohl das Fenster  vorher zu war und kein "schliessen" Event kommen dürfte?
Oder meinst du
b) Ich schalte die Dunsabzugshaube bei offenem Fenster über Fhem oder Fernbedienung an und dann geht die irgendwann aus obwohl das Fenster noch offen ist?

Wenn du a) meinst, könnte das daran liegen, dass das der Fensterkontakt andere Meldungen sendet, (Batteriestatus oder so, ich hab nicht mehr im Kopf, was der TRISTATE Sensor alles sendet) und dann wird dein notify getriggert und dann wird der Value überprüft und der ist closed und ... peng.

tatsächlich steht für fragliche Zeiten einfach nur ein "2013.05.27 16:21:53 3: FS20 set kue_Dunsthaube off" im fhem.log, und im Log zum Fensterkontakt sind nur Aktivitätsmeldungen

2013-05-26_12:51:49 kue_Fenster_Kueche Activity:: alive
2013-05-27_16:21:53 kue_Fenster_Kueche Activity:: dead
2013-05-28_18:35:51 kue_Fenster_Kueche Activity:: dead
2013-05-28_18:36:15 kue_Fenster_Kueche Activity:: dead
2013-05-28_19:25:01 kue_Fenster_Kueche Activity:: dead
2013-05-28_20:16:19 kue_Fenster_Kueche Activity:: dead
2013-05-28_22:18:05 kue_Fenster_Kueche Activity:: unknown
2013-05-28_22:18:38 kue_Fenster_Kueche Activity:: unknown
2013-05-29_22:57:27 kue_Fenster_Kueche Activity:: unknown

Meint das:
a) Wenn das Fenster zugemacht wird, soll ein einmaliges FS20 off Event gesendet werden?

Genau, es soll ausschließlich bei echten Aktionen (also echtem Fenster wird geschlossen) ein set off kommen, analog natürlich beim Öffnen ein Einmaliges set on. Alle anderen Sendungen wie alive, dead, cyclicMsg etc sollen kein Schaltevent auslösen.

Ich hoffe, ich konnte mein Anliegen jetzt etwas besser verdeutlichen
Im Anhang einmal die fhem.log sowie das Log des Fensterschalters ...

Gruß

PS: um 9:47 ist für heute wieder ein solches Ereignis aufgetreten,

2013-05-30_09:38:19 kue_Fenster_Kueche open
2013-05-30_09:38:19 kue_Fenster_Kueche contact: open (to HMLAN1)
2013-05-30_09:38:22 kue_Fenster_Kueche closed
2013-05-30_09:38:22 kue_Fenster_Kueche contact: closed (to HMLAN1)
2013-05-30_09:47:29 kue_Fenster_Kueche Activity:: alive

im fhemlog steht da nur

2013.05.30 09:38:20 3: FS20 set kue_Dunsthaube on
2013.05.30 09:38:20 3: FS20 set kue_Dunsthaube on
2013.05.30 09:38:22 3: FS20 set kue_Dunsthaube off
2013.05.30 09:38:22 3: FS20 set kue_Dunsthaube off
2013.05.30 09:47:30 3: FS20 set kue_Dunsthaube off

(die Einträge vorher habe ich mittels Fenster Auf und Zu provoziert ...)

[MisterEltako]

Vielleicht interner Timer? Oder eine anderes Gerät hat den gleichen Hauscode/Adresse?

Code Auswählen Erweitern


ELV FS20 ST-4 Funk-Schaltsteckdose:
 
Zum Schaltkomfort dieses zentralen Aktors des FS20-Systems gehört auch eine integrierte Timer-Funktion (Abschalttimer).

Damit ist eine automatische Abschaltung des aktivierten Schaltausgangs nach 1 Sek. bis 4,25 Stunden möglich.
Diese Zeitbegrenzung ist sowohl fest in der Schaltdose programmierbar (d.h. sie wirkt bei Steuerung per Handfernbedienung und EZcontrol XS1), als auch einmalig per speziellem XS1 Befehl für den nächsten Schaltvorgang festzulegen.

MFG, MisterEltako

[caldir65]

Vielleicht interner Timer? Oder eine anderes Gerät hat den gleichen Hauscode/Adresse?

Hallo,

dann müßte der Timer aber bereits ab Werk programmiert sein - ich habe außer Pairing mit dem Taster nichts unternommen (Hauscode kommt vom Taster, ist auch keine Dublette vorhanden), alles andere wird über fhem gemacht

Könnte das FS20-Off evtl. im Zusammenhang mit der Alive-Meldung vom Türkontakt stehen? Lt. Logs ist da zeitlich nur etwa eine Sec zwischen beidem

Gruß

[Zrrronggg!]

Sieht für mich doch genau so aus, wie ich es schon hinschrieb:

könnte das daran liegen, dass das der Fensterkontakt andere Meldungen sendet, (Batteriestatus oder so, ich hab nicht mehr im Kopf, was der TRISTATE Sensor alles sendet) und dann wird dein notify getriggert und dann wird der Value überprüft und der ist closed und ... peng.

Dein Notify fängt ja alle Ereignisse ab und wird also auch durch ein alive getriggert.

D.H. das HM-SEC-SC sendet:
2013-05-30_09:47:29 kue_Fenster_Kueche Activity:: alive
(das steht wegen zu geringen verboselevel nicht im normalen Log. Kannst ja mal versuchsweise verbose auf 5 setzen:
Anstatt
attr global verbose 3
attr global verbose 5
in der FHEM.cfg)

Das triggert sowohl dein:

Code Auswählen Erweitern

define kue_fenster_auf notify kue_Fenster_Kueche:.*

als auch

Code Auswählen Erweitern

define kue_fenster_zu notify kue_Fenster_Kueche:.*

Und da das Fenster noch zu ist ergibt der Test von

Code Auswählen Erweitern

{ if ( Value ("kue_Fenster_Kueche") eq "closed")
ein true
und löst dann

Code Auswählen Erweitern

{fhem("set kue_Dunsthaube off")} }
aus. Und das sieht du dann auch im Log:

2013.05.30 09:47:30 3: FS20 set kue_Dunsthaube off


Ein ähnliches Problem gäbe es z.b. mit den FHT TFKs die alle 2 Minuten ihren Status melden.

Das kann man auf mehre Arten umgehen:
1. Vorfiltern des notivys:

Code Auswählen Erweitern


define kue_fenster_auf notify kue_Fenster_Kueche:open
Theorie ist, das nur OPEN Meldungen das notify auslösen und die anderen ignoriert werden.
Leider weiss ich bei dem HM TriStateSensor nicht genau wie die Formulierung da sein muss, da der ja nicht "open" und "closed" sendet, sondern sowas wie
"Window: open"
Naheliegend wäre:
define kue_fenster_auf notify kue_Fenster_Kueche:.*open
aber das klappte irgendwie nicht, wenn ich mich recht erinnere.Da gabs hier im Forum neulich mal eine Diskussion, ich kann mich an das Ergebniss nicht mehr erinnern.
Such mal hier im Forum.

2. Testen auf den vorherigen Wert ("old Value") und nur wenn der anders ist auslösen.

Müsste (aus dem Kopf )in etwa so gehen:

Code Auswählen Erweitern

define kue_fenster_zu notify kue_Fenster_Kueche: { if ( Value ("kue_Fenster_Kueche") eq "closed" && OldValue ("kue_Fenster_Kueche") eq "open" ) {fhem("set kue_Dunsthaube off")} }

Ob das hier hilft habe ich nicht voll durchdacht, man müsste sich alle Werte die derHM-SEC-Dings sendet ansehen. Einen Versuch ist's Wert.


3. Einen Abstraktionslauer einbauen.

Du erzeugst dir einen Dummy, der sagen wir mal "Kuechenfesnterdummy" heisst.

Denn lässt du durch deine Notifys befüllen:

Code Auswählen Erweitern

define kue_fenster_auf notify kue_Fenster_Kueche { if ( Value ("kue_Fenster_Kueche") eq "open") \
{fhem("set Kuechenfesnterdummy offen")} }

define kue_fenster_zu notify kue_Fenster_Kueche { if ( Value ("kue_Fenster_Kueche") eq "closed") \
{fhem("set Kuechenfesnterdummy zu")} }

Die ganzen anderen Meldungen erzeugen jetzt eine immer wieder neues Befüllen von Kuechenfesnterdummy  mit "zu" oder "offen", das ist aber egal, weil das nix direkt schaltet.

Und dann baust dir eine Auswertung von Kuechenfesnterdummy, die den Abzug schaltet:

Code Auswählen Erweitern

define Kuechenfesnterdummy_offen notify Kuechenfesnterdummy:offen set kue_Dunsthaube on

define Kuechenfesnterdummy_zu notify Kuechenfesnterdummy:zu set kue_Dunsthaube off

Die Triggern nur, wenn der Wert von Kuechenfesnterdummy sich tatsächlich ändert. Et Voila.

(letztere Methode setze ich bei mir ein, allerdings aus leicht anderen Gründen. Daher weiss ich aber, dass die geht, und mit den ersten beiden Methoden habe ich mich noch im Zusammenhang mit dem HM-SEC-SC noch nicht befasst, obwohl die für deinen Anwendungsfall eleganter wären.)

[caldir65]

Hallo,

ich habe jetzt einmal etwas experimentiert (nachdem ich ein paar andere "Baustellen" beseitigt habe ;-)) und mich mit Deinem Vorschlag 2 beschäftigt:

zunächst einmal die Einträge im Log zum Schalter bei verbose 5:

2013.06.07 14:58:31 5: HMLAN_Parse: HMLAN1 R:E1E30CF   stat:0000 t:08FA50F6 d:FF r:FFAE     m:5B A041 1E30CF 13D2D1 0152C8
2013.06.07 14:58:31 5: HMLAN1 dispatch A0C5BA0411E30CF13D2D10152C8::-82:HMLAN1
2013.06.07 14:58:31 5: HMLAN_Send:  HMLAN1 I:+1E30CF,00,00,
2013.06.07 14:58:31 5: HMLAN_Send:  HMLAN1 S:S1EB786EF stat:  00 t:00000000 d:01 r:1EB786EF m:5B 8002 13D2D1 1E30CF 0101C800
2013.06.07 14:58:31 5: Triggering kue_Fenster_Kueche (2 changes)
2013.06.07 14:58:31 5: Notify loop for kue_Fenster_Kueche open
2013.06.07 14:58:31 5: HMLAN_Parse: HMLAN1 R:R1EB786EF stat:0002 t:00000000 d:FF r:7FFF     m:5B 8002 13D2D1 1E30CF 0101C800
2013.06.07 14:58:31 5: HMLAN_Parse: HMLAN1 discard
2013.06.07 14:58:33 5: HMLAN_Parse: HMLAN1 R:E1E30CF   stat:0000 t:08FA58B4 d:FF r:FFAE     m:5C A441 1E30CF 13D2D1 015300
2013.06.07 14:58:33 5: HMLAN1 dispatch A0C5CA4411E30CF13D2D1015300::-82:HMLAN1
2013.06.07 14:58:33 5: HMLAN_Send:  HMLAN1 S:S1EB78EA7 stat:  00 t:00000000 d:01 r:1EB78EA7 m:5C 8002 13D2D1 1E30CF 0101C800
2013.06.07 14:58:33 5: Triggering kue_Fenster_Kueche (2 changes)
2013.06.07 14:58:33 5: Notify loop for kue_Fenster_Kueche closed

Mit diesem fhem.cfg-Code habe ich mich versucht:

Code Auswählen Erweitern

define kue_fenster_zu notify kue_Fenster_Kueche: { if ( Value ("kue_Fenster_Kueche") eq "closed" && OldValue ("kue_Fenster_Kueche") eq "open" ) {fhem("set kue_Dunsthaube off")} }
define kue_fenster_auf notify kue_Fenster_Kueche: { if ( Value ("kue_Fenster_Kueche") eq "open" && OldValue ("kue_Fenster_Kueche") eq "closed" ) {fhem("set kue_Dunsthaube on")} }

Leider ohne den gewünschten Erfolg.

Mit Vorschlag 3 habe ich mich noch nicht beschäftigt, steht aber (zumindest testweise) noch auf meinem Plan - ich würde allerdings gerne die elegantere Lösung benutzen (wenn sie denn läuft ;-))

Gruß

[caldir65]

Hallo,

ich habe mich jetzt mal mit Vorschlag3 beschäftigt - grundsätzlich scheint es erst einmal zu funktionieren. Ob das Eingangs beschriebene Problem damit beseitigt ist, muß die Zeit zeigen.

Gruß

[edit] So wie es bisher aussieht, funktioniert es offenbar. Einzig bei einem Neustart von fhem geht der Schalter auf Aus.