HM-SCI-3-FM und HM-LC-Sw1PBU-FM peeren für Wechselschaltung

Begonnen von angel_65, 15 August 2013, 22:34:52

Vorheriges Thema - Nächstes Thema

angel_65

Hallo,

ich versuche eben, einen Kanal eines HM-SCI-3-FM mit einem HM-LC-Sw1PBU-FM über FHEM für eine Wechselschaltung zu peeren.

set OG.FL.Licht.TreppenhausUnten peerChan 0 EG.FL.Licht.TreppenhausOben single set

Hat bisher auch geklappt, nur bekomme ich im Moment nicht raus, welche Register ich im HM-LC-Sw1PBU-FM wie setzen muß, damit ich mit dem SCI-3 das Licht ein- und ausschalten kann.

Die Kommandos

   set EG.FL.Licht.TreppenhausOben shSwJtOn  off OG.FL.Licht.TreppenhausUnten
   set EG.FL.Licht.TreppenhausOben shSwJtOff on OG.FL.Licht.TreppenhausUnten

führen dazu, dass das Licht bei einem Wechsel von closed->open toggled und nicht wie gewünscht bei closed->on und bei open->off.

Irgendwas scheine ich da etwas falsch verstanden zu haben.

Kann mir vielleicht jemand auf die Sprünge helfen ?

Danke !
angel_65




martinp876

Hi Angel_65,

hm, ja, das ist falsch verstanden. wird auch aufwendiger. Du musst in 2 Ebenen denken.

erst einmal die Statemachine und dann die Filterebene.

- der SCI3 hat 2 positionen und sendet einen Wert (z.B. 0) bei Position 1 und einen bei Position 2 (z.B.200) 200 entspricht 100%.

Du solltest programmieren, dass bei jedem Trigger des SCI der SW1 'toggelt'. Das sollte der Fall sein, wenn du NICHTS an der jumptable aenderst (...Jt...) und mit 'single' peerst. Also statemachine in ruhe lassen.

Nun der Filter:
Du willst nur ausschalten bei Pos 1 und einschalten bei Pos 2 (oder umgekehrt). Nutze die ...CT... register.
Wenn "on" ist werden trigger "Pos1" zugelassen und auf "off" toggeln, "Pos2" wird gefiltert.
Unser Vergleichswert ist "shCtValLo". Der steht per default auf 25 - lassen wir so.

shCtDlyOn  = ltLo
shCtOn =    ltLo

=> wenn pos1 kommt und wir in "on" oder auf dem Weg dahin "dlyOn" sind schalten wir (entsprechend JT) Richtung off.

und die Gegenrichtung:
shCtDlyOff = geLo
shCtOff =  geLo

=> wenn pos2 kommt (200) und wir in "off" oder auf dem Weg dahin "dlyOff" sind schalten wir (entsprechend JT) Richtung on.

Ich hoffe man kann das  Prinzip erkennen.
Übrigens kann man im SCI3 festlegen an welcher position welche Message kommt.

Gruss Martin





Pawers


angel_65

Hallo Martin,

danke ! Klappt !

Gibt es eigentlich eine Beschreibung der Homatic Statemachines ? Oder habt ihr das alles durch Trial & Error rausgefunden ?

Viele Grüße
angel_65

martinp876

Hi Angel_65

ich habe es mir zusammengereimt. Für die CT habe ich sehr lange gebraucht.
Die JT habe ich im Einsteigerdoc beschrieben (oder es versucht). Die Statemachines sind alle gleich/fast identisch. Bei einigen fehlen ein paar states (ramp gibt es bei Lichtschaltern nicht, ref ist eine Wartezeit der Umschaltung von Motoren bei Blinds).

Unklar ist, ob HM immer alle states implementiert aber nicht alle zugänglich macht. Ist für den User aber egal.
Zur CT muss man nur verstehen, dass einige Sensoren Werte mitsenden, die man mit 2 Werten vergleichen kann. Der RHS hat 2 Werte, ein tristate-sensor kann 3 liefern und andere Sensoren "analoge" werte - also ein MotionDetektor die Helligkeit in  von 0-100% in 0.5% schritten - nicht ganz analog...

Gruss Martin

angel_65

Hallo Martin,

ok. D.h. ein bisschen spielen.

Bzgl. des ursprünglichen Problems:
Habe es eben mal im Zusammenspiel mit dem SW1 versucht. So ganz klappt es doch noch nicht. Habe ich evtl. durch meine ersten Versuche mit den Registern wetwas "kaputt" gemacht ? Bzw. wie spielen die da noch mit rein.

Problem ist jetzt. dass ich zwar mit dem SCI3 ein- und auschlaten kann, aber sobald ich am SW1 den Zustand ändere, muß ich den SCI3 erst einmal aus und wieder einschalten, damit der wieder im "Rythmus" ist.

Grüße
angel_65


martinp876

Hi,

du kannst einmal die Register schicken, dann kann ich reinsehen.
Du kannst einfach noch einmal peeren, dann überschreibt das device die register mit den default (auch im Einsteigerdoc erwähnt).Dann solltest du wieder ein "sauberes" toggel haben.

SCI3 und SW1 synchronisieren sich nicht. Das ganze ist, wie alles, ein event gesteuertes system, kein state gesteuertes. Will sagen der SCI meldet einen trigger und der SW reagiert ggf. der SCI prüft NIE den Zustand und gleicht den auch nicht ab. Was du erreichen kannst ist

SCI3 wechselt nach "on" => wenn SW1 "on" toggle. Wenn SW1 "off" tue nichts
SCI3 wechselt nach "off" => wenn SW1 "on" tue nichts. Wenn SW1 "off" toggle

jedenfalls in der Form.

Du kannst auch einmal die Events mitschreiben und schicken. Dann kann ich versuchen zu verstehen was passiert oder nicht passiert

Gruss Martin

DerTom

Hallo Martin,

ich habe zu dem Thema mal eine Frage. Ich habe das Thema mal mit einem HM-LC-SW1-FM und einem SCI3 getestet. Funktioniert wunderbar. Nun möchte ich das ganze auf die Produktive Welt anwenden. Da habe ich aber auch einen HM-LC-SW2-FM mit dem sich das Register für den Channel nicht schreiben lässt. Unten stehende Meldung erscheint, wenn ich eingebe:

set SZU_HM_ACT_LED_CH1 regSet shCtDlyOn ltLo SZU_HM_SEND_TUER_Sw_01

cannot calculate value. Please issue set SZU_HM_ACT_LED_CH1 getConfig first - invalid

Wie kann ich das Register im Channel setzen? Ein GetConfig kann ich doch am Channel gar nicht machen, sondern nur am Grät. Gepeert ist der Channel schon... Hast Du eine Idee?

Gruß
Tom

martinp876

du kannst ein getConfig auf jeden Channel machen.
wenn du es am device machst werden die für alle Channels auch ausgeführt (um es komfortabel zu machen)

DerTom

Hallo,

dass ich ein GetConfig am Channel oder am Gerät mache, ändert nichts an der Tatsache, daß dieser Fehler immer wieder kommt. Leider ...

martinp876

wenn die daten gelesen wurden und du immer noch nicht setzen kannst gibt es diese Datenfeld nicht.
setze
attr SZU_HM_ACT_LED_CH1 expert 2
und mache ein list des SZU_HM_ACT_LED_CH1

DerTom

Gemacht...
List siehe hier:

Internals:
   CFGFN      ./FHEM/fhem_Schlafzimmer.cfg
   DEF        1CA5E101
   NAME       SZU_HM_ACT_LED_CH1
   NR         571
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   device     SZU_HM_ACT
   Readings:
     2015-01-23 19:06:05   CommandAccepted yes
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgActionType jmpToTarget
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgCtDlyOff geLo
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgCtDlyOn geLo
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgCtOff geLo
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgCtOn geLo
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgCtValHi 100
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgCtValLo 50
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgMultiExec on
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgOffDly 0 s
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgOffTime unused
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgOffTimeMode absolut
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgOnDly 0 s
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgOnTime unused
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgOnTimeMode absolut
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgSwJtDlyOff off
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgSwJtDlyOn on
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgSwJtOff dlyOn
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-lgSwJtOn dlyOff
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shActionType jmpToTarget
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shCtDlyOff geLo
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shCtDlyOn geLo
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shCtOff geLo
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shCtOn geLo
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shCtValHi 100
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shCtValLo 50
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shOffDly 0 s
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shOffTime unused
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shOffTimeMode absolut
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shOnDly 0 s
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shOnTime unused
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shOnTimeMode absolut
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shSwJtDlyOff off
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shSwJtDlyOn on
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shSwJtOff dlyOn
     2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shSwJtOn dlyOff
     2015-01-01 16:45:55   R-sign          off
     2015-01-24 16:32:21   RegL_01:         08:00 00:00
     2015-01-24 16:24:17   deviceMsg       off (to VCCU)
     2015-01-24 16:24:17   level           0
     2015-01-24 16:24:17   pct             0
     2015-01-24 16:24:17   recentStateType info
     2015-01-24 16:24:17   state           off
     2015-01-24 16:24:17   timedOn         off
   Helper:
     dlvlCmd    ++A011F112341CA5E10201000000
     peerIDsRaw ,00000000
     Role:
       chn        1
       prs        1
     Shadowreg:
Attributes:
   expert     2_full
   fp_Erdgeschoss 148,239,0,Balken_Bett
   group      Schalter
   model      HM-LC-SW2-FM
   peerIDs    00000000,
   room       Schlafzimmer
   webCmd     statusRequest:toggle:on:off


Offensichtlich gibt es das Register...

martinp876

ZitatpeerIDs    00000000,
es gibt keine peers, also auch kein register dazu.

2015-01-10 15:37:59   R-SZU_HM_SEND_TUER_Sw_01-shSwJtOn dlyOff
das ist schon alt. du hast die peers gelöscht oder das Device resetet.

Zitat
Offensichtlich gibt es das Register...
leider nicht. die register-Readings werden nicht gelöscht.
mache ein
set SZU_HM_ACT_LED_CH1 clear register
dann lese noch einmal, dann ist alle frisch - und sicher auch leer

DerTom

...so ist es. Habe alles nocheinmal frisch gepeert und schick ist die Sache.

Besten Dank für die Denkanstöße!

DerTom

Aber eine Frage habe ich doch noch...

Denken wir mal ein wenig komplizierter: Ich habe in meinem Flur einen Aktor (einen Channel eines HM-LC-SW2-FM) Namens FLU_FS_6_C2 und 4 Geräte HM-SCI-3-FM Namens

FLU_HM_SEND_TUER_1_Sw_01
FLU_HM_SEND_TUER_2_Sw_01
FLU_HM_SEND_TUER_3_Sw_01
FLU_HM_SEND_TUER_4_Sw_01

Jeder dieser Sensorkanäle schaltet den Kanal des FLU_FS_6_C1 mit einem toggle um, so daß ich im Endeffekt eine "virtuelle" Kreuzschaltung habe. Kann ich das irgendwie mit den CT des Aktors abbilden, so daß er ebenfalls ohne ein notify über FHEM zu schalten wäre? Jede Zustandänderung der Sensoren (open|closed) sollte also eine Zustandsänderung des Aktors (on|off) zur Folge haben.

Meinst Du, das wäre machbar?