Peering von HM-ES-PMSw1-Pl (Schaltaktor) mit HM-Sec-WDS-2 (Wassermelder)

[fast-eddy]

Hallo zusammen,

habe seit langem mal wieder ein Problem, das ich leider nicht mit Hilfe der Doku oder des Forums lösen kann.
Das spricht für die Qualität, die FHEM mittlerweile erreicht hat und vor allem für die des Forums! Danke hierfür!

Um was geht es:
Bei mir im Keller steht eine Hebeanlage, die gerne dann ausfällt , wenn gerade die Waschmaschine gerade am Abpumpen ist.
Um dies abzufangen, hatte ich folgende Idee: Platzieren eines HomeMatic Wassermelders (HM-Sec-WDS-2) an der Hebeanlage
und eines HomeMatic Schaltaktors (HM-ES-PMSw1-Pl ) an der Waschmaschine. Fällt die Hebeanlage aus (Boden = nass) schaltet
die Waschmaschine ab ist das Problem beseitigt (Boden = trocken) schaltet die Waschmaschine wieder ein.

Soweit der Plan A:
- Pairing von Schaltaktor und Wassermelder mit FHEM               -> OK
- DOIF für Ein-/Ausschalten bei Ausfall Hebeanlage über state (dry/wet) definiert    -> OK

Soweit so gut aber wie gesagt stehen Hebeanlage und WaMa im Keller mein FHEM-Pi mit HM-LAN im 1 OG, was (je nach Tageszeit)
dazu führt, dass der Empfang suboptimal ist und die Messages verzögert ankommen.

Also zu PLAN B:
DoIf wieder deaktiviert und zusätzlich zum Pairing jetzt ein "PEERING" der Devices durchgeführt, um eine direkte Kommunikation, unabhängig von FHEM,
sicherzustellen. ("set keller_WASSERMELDER peerChan 0 HM_Schaltaktor_pwr_2C0CAC_Sw single set"   -> OK ). Das Pairing benötige ich trotzdem, um via
FHEM eine PUSH-Message absetzen zu können.

ERGEBNIS:
WaMa schaltet wie gewünscht sofort ab, sobald der Wassermelder in "State:wet" übergeht. Allerdings wird beim erneuten Senden des State:wet die WaMa
wieder eingeschalten d.h. der Schaltaktor "toggelt"mit jedem event, egal welchen Wert der state hat (siehe unten...).

MEIN PROBLEM!
Vermutlich muss ich über die Register Settings in der Condition Table einen Eintrag vornehmen, um die drei Status (dry:damp:wet) auf dedizierte Aktionen zu mappen.
(D.h. wet -> off | dry -> on | damp -> ?? ) Nur welchen und wie? Kann mir hierbei jemand helfen?

-----------------------
AUSZUG EVENT MONITOR:
-----------------------

2015-12-22 07:36:45 CUL_HM keller_WASSERMELDER battery: ok
2015-12-22 07:36:45 CUL_HM keller_WASSERMELDER contact: wet (to vccu)
2015-12-22 07:36:45 CUL_HM keller_WASSERMELDER wet
2015-12-22 07:36:45 CUL_HM keller_WASSERMELDER trigDst_vccu: noConfig
2015-12-22 07:36:45 CUL_HM keller_WASSERMELDER trigger_cnt: 211
2015-12-22 07:36:47 CUL_HM HM_Schaltaktor_pwr_2C0CAC CMDs_done
2015-12-22 07:36:48 CUL_HM HM_Schaltaktor_pwr_2C0CAC_Sw deviceMsg: on (to vccu)
2015-12-22 07:36:48 CUL_HM HM_Schaltaktor_pwr_2C0CAC_Sw level: 100
2015-12-22 07:36:48 CUL_HM HM_Schaltaktor_pwr_2C0CAC_Sw pct: 100
2015-12-22 07:36:48 CUL_HM HM_Schaltaktor_pwr_2C0CAC_Sw on
2015-12-22 07:36:48 CUL_HM HM_Schaltaktor_pwr_2C0CAC_Sw timedOn: off
---
2015-12-22 07:36:55 CUL_HM keller_WASSERMELDER battery: ok
2015-12-22 07:36:55 CUL_HM keller_WASSERMELDER contact: wet (to vccu)
2015-12-22 07:36:55 CUL_HM keller_WASSERMELDER wet
2015-12-22 07:36:55 CUL_HM keller_WASSERMELDER trigDst_vccu: noConfig
2015-12-22 07:36:55 CUL_HM keller_WASSERMELDER trigger_cnt: 212
2015-12-22 07:36:58 CUL_HM HM_Schaltaktor_pwr_2C0CAC CMDs_done
2015-12-22 07:36:58 CUL_HM HM_Schaltaktor_pwr_2C0CAC_Sw deviceMsg: off (to vccu)
2015-12-22 07:36:58 CUL_HM HM_Schaltaktor_pwr_2C0CAC_Sw level: 0
2015-12-22 07:36:58 CUL_HM HM_Schaltaktor_pwr_2C0CAC_Sw pct: 0
2015-12-22 07:36:58 CUL_HM HM_Schaltaktor_pwr_2C0CAC_Sw off
2015-12-22 07:36:58 CUL_HM HM_Schaltaktor_pwr_2C0CAC_Sw timedOn: off

[martinp876]

Prüfen, welche level hinter werden, dry usw steht. Sagen wir wet ist 200.
Du willst, dass bei wet eingeschaltet werden soll. Filtere also alle Zustände kleiner wet weg.
Das soll passieren, wenn aktuell off ist. Bei on musst du nicht schalten, ist jamschon.
Also setze den high CT  alue auf 199.
Setzenshctoff auf GT high.

Wenn also der Schalter aktuell off ist und der peer einen trigger bekommt mit level 200 wird die Aktion ausgeführt, welche bei short vorgegeben ist.
Wenn ein triggern kleiner 199 kommt wird der ignoriert
Dann setze lo auf 1.
Setze shcton auf leLo. Wenn also on ist und trigger 0 kommt ist der kleiner als lo und die definierte Aktion wird
ausgeführt.

[fast-eddy]

Hallo martinp876,

danke für Deine schnelle Antwort  und sorry wegen der späten Reaktion
aber KabelBW war leider der Meinung wir brauchen über die Feiertage kein Internet 

Also die Sache mit den Registern ist komplettes Neuland für mich - ich dachte, ich hätte
das wenigstens grob verstanden nach Deiner Antwort stelle ich fest, dass das wohl ein Irrtum war 

Soweit ich Dich verstanden habe, soll ich zuerst auslesen welche Werte sich hinter dry, wet und damp verstecken richtig?
Nur wo verstecken sich diese Einstellungen? "get regVal lgCtValLo" oder "get regVal lgCtValHi" auf den Schaltaktor gibt immer nur "Value not captured..." zurück?

Darauf habe ich den WDS in eine Wanne mit Wasser gestellt, um die Level-Werte beim Statuswechsel mitzulesen. Hierbei habe ich bemerkt, dass alle 10 Sekunden eine Nachricht (state:wet) gesendet wird solange der WDS im Wasser steht.

Nach Eingabe von get RegRaw List1 konnte ich sehen, dass level hierbei zwischen 0 und 100 springt und der Schaltzustand zwischen on und off toggelt.

Nimmt man den WDS aus dem Wasser heraus, sendet er state:dry und hört dann auf zu senden. Der level toggelt bei jeder message immer zwischen 0 und 100 egal ob wet oder dry gesendet wird?!

KORREKTUR / ERGÄNZUNG: Der Statuswechsel von "wet auf dry"  hat offensichtlich KEINEN Einfluss auf den "level". Der Wechsel auf "dry" löst nämlich keinerlei Reaktion beim
Schaltaktor aus d.h. weder Änderung des level noch des Schaltzustands! 

So wie es aussieht, benötige ich für meine Baustelle weiteres coaching...   
Hiefür danke im Voraus!   
   

[martinp876]

Die Werte habe ich einmal gemapped und jetzt vergessen. Defacto sendet der Sensor einen wert zwischen 0 und 200, was max 100% entspricht. 3state senden typisch 0, 50 und 200. es sollte im Sensor einstellbar sein, wenn welcher wert kommt.
Kommt da nicht ein level mit in den readings des Sensor?
Ich tippe auf 0, dry.  50 damp und 200 wet.

Damit ist der Sensor geklärt. Der gepeerte aktor hat einen Satz regs für den peer. Dort gibt es die CT, conditiontable table. Das ist ein filter. Trigger des peers welche der CT nicht entsprechen werden verworfen.
Mache ein get regTable, das ist m.e. der beste Überblick.
Du kannst unter Nutzung der high und low Werte filtern, abhängig vom zustand des aktors.
Also wenn er on ist und der trigger größere low,...... Usw.

Die weitere Aktion ist dann unabhängig vom trigger wert. Jetzt kommt die jt, jumptabel zum tragen.

[fast-eddy]

ZUM SENSOR:

Kommt da nicht ein level mit in den readings des Sensor?

Leider nicht! Über den Eventmonitor sehe ich nurfolgende Werte des Sensors:

2015-12-29 16:55:37 CUL_HM keller_WASSERMELDER battery: ok
2015-12-29 16:55:37 CUL_HM keller_WASSERMELDER contact: wet (to vccu)
2015-12-29 16:55:37 CUL_HM keller_WASSERMELDER wet
2015-12-29 16:55:37 CUL_HM keller_WASSERMELDER trigDst_vccu: noConfig
2015-12-29 16:55:37 CUL_HM keller_WASSERMELDER trigger_cnt: 24
2015-12-29 16:55:47 CUL_HM keller_WASSERMELDER battery: ok
...
2015-12-29 16:55:47 CUL_HM keller_WASSERMELDER contact: dry (to vccu)
2015-12-29 16:55:47 CUL_HM keller_WASSERMELDER dry
2015-12-29 16:55:47 CUL_HM keller_WASSERMELDER trigDst_vccu: noConfig
2015-12-29 16:55:47 CUL_HM keller_WASSERMELDER trigger_cnt: 25

Und auch über "regVal msgWdsPosA/B/C" ehalte ich nur ein "Value not captured:keller_WASSERMELDER - msgWdsPosA"
"getRegRaw" liefert mir im Gegensatz zum Schaltaktor leider auch keine Info über irgendwelche Level die auf dry|damp|wet gemapped werden...       

ZUM AKTOR:

Mache ein get regTable, das ist m.e. der beste Überblick.

Meintest Du "get regList"? Das argument "regTable" kenne ich nicht (wird auch nicht angeboten) und liefert  "Unknown argument regTable" zurück.
Im Forum oder der commadref kann ich hierzu leider auch keine Syntax finden ..

Danke für Deine Geduld - dachte nicht, dass das ne größere Baustelle wird! 

[martinp876]

Regtable ist noch nicht wirklich alt. Es liefert eine, wie ich meine uebersichtliche Darstellung der aktuellen Werte.
RegList zeigt die Register, deren Wertebereich und eine Zeile Beschreibung.
Evtl ist ein update fällig.

Msgabc solltest du in regList finden

[fast-eddy]

Guten Morgen,

Evtl ist ein update fällig.

... so, Update durchgeführt - leider sehe ich noch immer kein regTable 

Unknown argument regTable, choose one of cmdList param reg regList regVal saveConfig

Msgabc solltest du in regList finden

Ja, in der RegList habe ich den Eintrag auch gefunden, nur kann ich den aktuell gesetzten Wert über get regVal nicht abfragen. Erhalte für alle Register A/B/C die Meldung:

Value not captured:keller_WASSERMELDER - msgWdsPosC

irgendwie steh ich auf dem Schlauch...

Kann mich leider erst am Sonntag wieder melden, da ich gleich für ein paar Tage in die Berge fahre...

Bis dahin schon mal danke für die Hilfe und einen "Guten Rutsch"

[martinp876]

Regtable gibt es unter get. Wenn es nicht da ist hat der update nicht geklappt. Evtl ein force update.
Die Werte kannst du sehen, wenn sie gelesen sind. Ein regval greift auf die Kopien in fhem zu. Dazu muss es eine Kopie geben.
Ein getconfig hast du schon gemacht? Erfolgreich?
Du kannst auch mit attr expert alles sichtbar machen. Ist zum ueben gut, auf Dauer empfehle ich dann templates.
Oder in hminfo mit get Register.

[fast-eddy]

Hallo martinp876,

dank Deiner "Denkanstöße" bin ich ein großes Stück weitergekommen und habe meine "Baustelle" fast abgeschlossen.

Einige Register waren nicht korrekt gesetzt bzw. so, dass mein Peering mit dem Default Setting nicht funktionieren konnte.
Nach einigen Versuchen habe ich mir dann mal angeschaut, wie die Register gesetzt sind, wenn ich die Devices direkt, d.h. ohne Zentrale
oder FHEM peere. Also beide Devices zurückgesetzt und die Rgister per HM-USB Stick ausgelesen. Und tatsächlich werden hier ganz merkwürdige
Schwellwerte für die Level in der Condition Table verwendet. Diese und und die Actions habe ich dann mal nach FHEM übersetzt - und siehe da,
kaum macht man es richtig schon funktioniert es.

Hier mal die Register Settings, die ich angepasst habe, vielleicht hilft es ja anderen mit ähnlichen Problemen:

set WASCHMASCHINE regSet lgActionType off WASSERMELDER
set WASCHMASCHINE regSet lgMultiExec off WASSERMELDER
set WASCHMASCHINE regSet shCtDlyOff ltLo WASSERMELDER
set WASCHMASCHINE regSet shCtOff ltLo WASSERMELDER
set WASCHMASCHINE regSet shCtValHi 180 WASSERMELDER
set WASCHMASCHINE regSet shSwJtDlyOff on WASSERMELDER
set WASCHMASCHINE regSet shSwJtDlyOn dlyOff WASSERMELDER

Mit dem abschließenden Setting sorge ich noch dafür, dass sich der Schaltaktor nach einem Stromausfall auch wieder von alleine einschaltet

set WASCHMASCHINE regSet powerUpAction on

Allerdings habe ich jetzt zwei neue kleine Probleme in diesem Zusammenhang:

1.) Der Schaltaktor "verliert" die neuen Register Settings und setzt von alleine wieder die Originalwerte ein (Habs jetzt noch mal geändert bisher hält´s!)
2.) Nach dem Zurücksetzen und erneutem pairen/peeren taucht der Wassermelder zwar in der Peering Liste des Aktors auf aber nicht umgekehrt? (dort wird gar keine Peering Liste angezeigt...)
     Könnte das damit zusammenhängen, dass ich eine ganze Reihe Änderungen kurz hintereinander gemacht habe und evtl. einige Befehle nicht bei den Aktoren angekommen sind ? (Duty Ciycle?) Erstaunlicherweise funktionioert alles ?

[martinp876]

Beim peeren werden vom device selbst defaultmwerde gesetzt. Das passiert auch, ich meine identisch, wenn man mit fhem peert.
Wenn man Register setzt und dann noch einmal einen schon gepeerten peer peert werden die Register wieder auf default gesetzt.
Einen unterschied macht es, wenn man single oder dual peert.

Aber das ist mir relativ egal. Register verliert ein device nicht, so lange es nicht kaputt ist. Es gibt aber Aktionen, peeren, die Register beeinflussen.
Also braucht man etwas, um es zu kontrollieren. Das Zauberwort heißt templates.
Ich würde also die registersettings in einem template zusammenfassen. Es gibt ein paar, vielleicht kannst du wep he nutzen. Oder du definierst es selbst.  Was bringt? Du kannst es wieder verwenden. Du kannst prüfen, dass die Register noch stimmen.
Das peeren sollte dennoch beidseitig sein. Das kannst du nachholen

[fast-eddy]

Beim peeren werden vom device selbst defaultmwerde gesetzt.

logisch! Darauf hätte ich auch von selbst kommen können 
Da ich Probleme mit dem bidirektionalen Peering hatte, habe ich das Peeren wiederholt und dabei wohl die zuvor gesetzten Register platt gemacht.
Daher hört sich die Sache mit den Templates sehr spannend an. Doch dafür mache ich wohl besser einen eigenen Thread auf um das Thema nicht zu
verwässern  .

Bleibt das letzte kleine Problem: Wie bekomme ich es hin, dass das Peering sowohl im Sensor als auch im Aktor sauber eingetragen wird?
Gemäß commandref  habe ich das Peering - wie sonst auch - auf der Seite des Sensors vorgenommen:

Code Auswählen Erweitern

set <sensChan> peerChan 0 <actChan> [singlel] [set] Das hat bisher auch immer sauber funktioniert. Nur diesmal wird das Peer nur auf einer Seite - beim Aktor - eingetragen.

AUSZUG INTERNALS AKTOR:

NAME      keller_WASCHMASCHINE_Sw
NR          390
STATE     on
TYPE       CUL_HM
chanNo   01
device     keller_WASCHMASCHINE
peerList  keller_WASSERMELDER

Beim Sensor ist aber keine PeerList zu finden. Allerings stehen in den Readings Artefakte davon:

AUSZUG INTERNALS SENSOR:

R-HM_2C0CAC_Sw-expectAES             set_off   2016-01-05 18:42:49
R-HM_2C0CAC_Sw-peerNeedsBurst    set_off   2016-01-05 18:42:49

Hast Du einen Tipp für mich, wie ich das saubere Peering auch beim Sensor erzwingen kann?
Macht die simple Wiederholung des o.g. Peering befehls Sinn? Notfalls müsste ich dann halt die Register nochmals neu setzen...

[martinp876]

Einige Sender sind config oder wakeup devices. Es ist in hm Grundlagen erklärt wie man damit umgeht.
Wenn du also peerst werden die Kommandos immer in die Kommando Liste eingetragen und warten auf das versenden.
Bei normalen devices erfolgt es quasi sofort. Ist es ein config device muss fhem warten, bis config am device gedrückt ist. Sonst schläft das device.
Das Kommando hängt also in der queue.
Get hm protoevents zeigt unter anderem den zustand der q aller devices an. Wenn etwas pending ist, wartetmes noch. Wenn du einen reboot machst ist es vergessen. Wenn ein Fehler aufgetreten ist, kannst du es sehen.
Auch der status in hminfo zeigt an, wenn etwas pending ist. Schalte einen automatischen update ein.

[fast-eddy]

Das Kommando hängt also in der queue.

Jep. Mir ist über hminfo auch aufgefallen, dass noch einige Commads in der Queue hängen:

get hm protoevents:

keller_WASSERMELDER   : pending        | 60 pending| 481:     |  -       #  -       |  -       |  -     

Nur wie wecke ich den  HM-Sec-WDS-2 (Wassermelder) auf?
Sowohl kurzes Drücken (Anlernen) als auch langes Drücken (der Konfigtaste führte leider nicht zum Erfolg?
Noch ne andere Idee?

Korrektur: Da ich ja alles ausprobiere was, Du vorschlägts  hab ich es noch mal versucht und es klappt 
Hast Du Telephatische Fähigkeiten !? Gestern hat´s definitiv NICHT funktioniert!!! Vielleicht war ich aber durch das viele Testen auch im Duty Cycle.

Damit habe ich die erste Hürde genommen und mein Projekt soweit erstmal am Start.
Martin -  herzlichen Dank für Deine Geduld und Deine Hilfe zur Selbsthilfe, habe viel gelernt!