HM-ES-PMSw1-Pl Funk-Schaltaktor, Sensorkanal nutzen

Begonnen von PatrickR, 18 Januar 2014, 17:30:58

Vorheriges Thema - Nächstes Thema

PatrickR

Hallo zusammen!

Nach dem Umstieg auf Homematic möchte ich gerne meine bislang sehr gut funktionierende Nachricht bei Fertigstellung des Waschvorgangs meiner Waschmaschine von FS20 auf Homematic portieren.

Bei FS20 verwendete ich einen FS20FMS in Kombination mit einem Watchdog, der auslöste, wenn nicht 1:35 Minuten nach dem off-Signal ein on-Signal kam:
OG.BZ.WaschmaschineMS:.*off 00:01:35 OG.BZ.WaschmaschineMS:.*on trigger W_WaschmaschineFertig .
Mit entsprechend eingestellter Schwelle funktionierte das sehr zuverlässig und löste meine vorherige Lösung bestehend aus diversen Notifys und "dynamischen" Ats ab.

Mit Homematic möchte ich nun einen HM-ES-PMSw1-Pl Funk-Schaltaktor verwenden. Die nahe liegende Lösung wäre hier ein Notify auf den _Pwr-Kanal, das sämtliche power:-Meldungen parst. Ich bin jedoch auf der Suche nach einer eleganteren Lösung unter Verwendung des SenPwr-Kanals, der mit einem virtuellen Gerät gepeert wird. Falls möglich, sollte die Lösung mit dem Master-Slave nachgebildet werden. Hier komme ich aber mangels Dokumentation des PMSw1 nicht weiter:

list:         register | range              | peer     | description
   1: cndTxCycAbove    |     literal        |          | trigger if cond is above threshold options:on,off
   1: cndTxCycBelow    |     literal        |          | trigger if cond is below threshold options:on,off

   1: cndTxDecAbove    |   0 to 255         |          | trigger if decision is above
   1: cndTxDecBelow    |   0 to 255         |          | trigger if decision is below

   1: cndTxFalling     |     literal        |          | trigger if falling options:on,off
   1: cndTxRising      |     literal        |          | trigger if rising options:on,off

   1: txThrHiPwr       |   0 to 3680W       |          | threshold high power
   1: txThrLoPwr       |   0 to 3680W       |          | threshold low power


Ich verstehe die Register so:
cndTxCycAbove ist on und der (Leistungs-Messwert) ist über txThrHiPwr => Trigger
cndTxCycBelow ist on und der (Leistungs-Messwert) ist unter txThrLoPwr => Trigger
cndTxFalling ist on und der (Leistungs-Messwert) fällt von über txThrHiPwr unter txThrLoPwr => Trigger
cndTxRising ist on und der (Leistungs-Messwert) steigt von unter txThrLoPwr über txThrHiPwr => Trigger

Hierzu folgende Fragen:
1. Stimmen meine Vermutungen?
2. Was bedeutet "decision" bzw. welche Werte sind mit 0..255 einstellbar?
3. Was bedeutet "Trigger"? Tatsächlich ein triggern on <-> off, d. h. ich kann nicht verschiedene Befehle bei verschiedenen Events auslösen (z. B. Falling -> off, Rising -> on)?

Patrick
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

martinp876

Hi Patrik,

ich habe keinen zum testen - lese es so

txThrHiPwr - level legt den 100% wert high fest
cndTxDecAbove ist ein prozent-wert in 0.5% Schritten. 200 ist also 100%, 255 = 127,5%. Die Berechnung müsste also relativ zu txThrHiPwr  gelten.
cndTxCycAbove sendet zyklich einen trigger, wenn der Wert txThrHiPwr *cndTxDecAbove  überschritten ist.
cndTxRising sendet einen trigger, wenn txThrHiPwr *cndTxDecAbove überschritten wird - einmalig. Evtl auch wenn txThrLoPwr * cndTxDecBelow unterschritten wird? oder     txThrHiPwr * cndTxDecBelow? das wäre zu testen

Ein Event-trigger in HM liefert immer einen Prozent wert mit - daher muss HM dies auch Umrechnen. Mit dieser Methode ist es möglich sein device zu kalibrieren. Die Prozentwerte im Event sind wichtig für die Angeschlossenen (gepeerten) aktoren da der von denen ausgewertet wird.

Wäre schön, wenn du dies klären konntest - reicht ja eine Glühlampe zum testen. Auch die cycle-time ist interessant.

möchtest du die Waschmaschine irgendwann ausschalten oder nur eine email schicken? Du könntest auch peeren und abhängig vom level andere Aktoren (auch den internen ) schalten.

Gruss Martin

PatrickR

Zwischenbericht:

1.) Es werden exakt zwei verschiedene Werte an den gepeerten Aktor gesendet: cndTxDecAbove, cndTxDecBelow:

CUL_HM martin_Btn1 trig_OG.BZ.Waschmaschine_SenPwr: 24
CUL_HM martin_Btn1 trigLast: OG.BZ.Waschmaschine_SenPwr :24
CUL_HM martin_Btn1 virtActTrigger: OG.BZ.Waschmaschine_SenPwr

CUL_HM martin_Btn1 trig_OG.BZ.Waschmaschine_SenPwr: 42
CUL_HM martin_Btn1 trigLast: OG.BZ.Waschmaschine_SenPwr :42
CUL_HM martin_Btn1 virtActTrigger: OG.BZ.Waschmaschine_SenPwr

Im Beispiel: cndTxDecAbove=42, cndTxDecBelow=24 (Habe ich auch mit anderen Werten probiert).

2.) cndTxCycAbove, cndTxCycBelow melden sich alle 3 Minuten unabhängig davon ob und wann ein Ereignis eintritt.

3.) Die Flankenfunktionen habe ich mal kurz getestet. Auch sie senden nur die zwei o. g. Werte aber sofort nach Eintritt des Ereignisses.

4.) Ob cndTxDecAbove und cndTxDecBelow Auswirkungen auf das "Auslöseverhalten" haben, kann ich noch nicht sagen. Hier bin ich mir noch nicht 100% klar, wie ich meine Beobachtungen in ein schlüssiges Bild überführen kann. Interessanterweise habe ich es nicht hinbekommen, die Werte für txThrHiPwr, txThrLoPwr, cndTxDecAbove, cndTxDecBelow so zu wählen, dass der PMSw1 mal eine Runde aussetzt und nichts sendet.

Werde das mal kommende Woche weiter verfolgen und ggf. mal skripten.

Grüße
Patrick
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

martinp876

Hi Patrick

wie wäre es mit einem Glühlampentest - oder einem Heizgerät bekannter leistung (wasserkocher?)
wenn dein Verbraucher 2kW hat:
setze 
txThrHiPwr 2000
txThrLoPwr 1000

cndTxFalling    off
cndTxRising     off
cndTxCycBelow off
cndTxCycAbove on
cndTxDecAbove 100
cndTxDecBelow  10

Jetzt erwarte ich eine zyklische message wenn der Verbraucher eingeschaltet ist - wir haben mit '100' die schwelle auf 50% gesetzt.
Es sollten keine messages bei below kommen.

cndTxFalling    off
cndTxRising     on
cndTxCycBelow off
cndTxCycAbove off
jetzt sollte eine bein Einschalten kommen

cndTxFalling    on
cndTxRising     off
cndTxCycBelow off
cndTxCycAbove off
und nun beim Ausschalten.

Gruss Martin

PatrickR

#4
Mahlzeit!

Nach mehrfachem Umbau meines Testaufbaus:











cndTxCycBelowcndTxCycAboveBedingungResultat
onoffP < txThrHiPwrcndTxDecBelow
onoffP >= txThrHiPwr%
offonP > txThrLoPwrcndTxDecAbove
offonP <= txThrLoPwr%

Anmerkungen:

  • cndTxDecBelow, cndTxDecAbove haben keinen Einfluss darauf, ob ein Ereignis gesendet wird lediglich welches.
  • Sind sowohl cndTxCycBelow als auch cndTxCycAbove gesetzt und treten beide o. g. Ereignisse ein, so ist das Ereignis cndTxDecAbove
  • Da ich nicht davon ausgehe, dass meine Last (60W-Glühlampe) eine konstante Leistungsaufnahme hat, habe ich txThrLoPwr und txThrHiPwr im Bereich 40W,50W,70W,80W

Bei Interesse die Messwerte:
https://dl.dropboxusercontent.com/u/10384346/fhem/fhem-pmsw1-tester2.sqlite

Evtl. schaue ich mir bei Gelegenheit nochmal die Flankenfunktionen an.

Patrick
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook