Korrektur / Ergänzungen zum Wiki Artikel zu HM-Sec-WDS Funk-Wassermelder

[muc46]

Hallo,
nutze für die Abschaltung einer Waschmaschine den Wassermelder HM-Sec-WDS Funk-Wassermelder mit V1.4 in Verbindung mit der Funksteckdose von HM. Bei dem HM-Sec-WDS Funk-Wassermelder werden die Zustände dry, wet und water angezeigt. Dem Zustand damp konnte ich nicht finden. Das könnte ungedated werden.

Zudem wäre es hilfreich eine Kurzbeschreibung der Register des Wassermelders - soweit bekannt - in die Wiki Seite aufzunehmen. Bei Interesse kann ich meine Mithilfe beim Editieren anbieten.

Beste Grüße, MUC46

[ph1959de]

Laut 10_CUL_HM wird umgesetzt:

Code Auswählen Erweitern

"HM-SEC-WDS"      =>{"00"=>"dry"     ,"64"=>"damp"    ,"C8"=>"wet"        }
"HM-SEC-WDS-2"    =>{"00"=>"dry"     ,"64"=>"damp"    ,"C8"=>"wet"        }

Wo genau siehst Du die von Dir aufgeführten Werte dry, wet und water?

Vielleicht kannst Du mal das "List" Ergebnis von Deinem HM-SEC-WDS hier anhängen?

[muc46]

Danke für die schnelle Rückmeldung.

Model: 131778D0A HM-Sec-WDS-2
Version: 1.4

Anbei die Einträge unter regList:
##################
list:         register | range              | peer     | description
   0: cyclicInfoMsg    |     literal        |          | cyclic message options:off,on_100,on
   0: pairCentral      |   0 to 16777215    |          | pairing to central
   0: transmDevTryMax  |   1 to 10          |          | max message re-transmit
   1: eventFilterTimeB |   5 to 7620s       |          | event filter time
   1: msgWdsPosA       |     literal        |          | Message for position A options:dry,noMsg
   1: msgWdsPosB       |     literal        |          | Message for position B options:water,noMsg,wet,dry
   1: msgWdsPosC       |     literal        |          | Message for position C options:noMsg,water,wet
   1: sign             |     literal        |          | signature (AES) options:on,off
   1: transmitTryMax   |   1 to 10          |          | max message re-transmit
   4: expectAES        |     literal        | required | expect AES options:off,on
   4: peerNeedsBurst   |     literal        | required | peer expects burst options:off,on
##########################

Wie dort zusehen wird in der Message dry, wet und water  signalisiert.
Kommen Sie damit weiter?

[Pfriemler]

beim Suchen zufällig drüber gestolpert ...

Ich kann nicht erkennen, dass das Problem inzwischen gelöst wurde. Der WDS meldet wie beschrieben via 10_CUL_HM je nach Zustand "dry", "damp", "wet", die "msgWdsPosX" (A,B,C) sind bei der Registerprogrammierung mit "dry", "wet", und "water" benannt. "wet" hat also im Register die Bedeutung "feucht", im Zustand "nass".

Das ist einfach nur falsch. Blöderweise ist die Registerwertebezeichnung die korrektere im ursprünglichen Sinne des Herstellers, da der Sensor zwischen einer Bodenfeuchte/nässe (im Sinne eines mehr oder weniger geschlossenen und leitfähigen Wasserbelags) und einem echten Wasserstand (Wasser steht höher als 0,5 mm) unterscheidet. Man müsste der Funktionalität und Wahrheit zuliebe also 10_CUL_HM ändern - und damit alle Nutzer zur Anpassung ihrer Routinen zwingen.

Ich schlage stattdessen vor, die Einträge in HMConfig.pm denen des Status anzupassen ("different literals"). Bei Fenstersensoren gibt es mit open|tilted|closed ja auch Übereinstimmung.

Edith meint noch, dass ich martin876 darauf hinweisen sollte. Getan.

[martinp876]

Da ich keinen Sensor haben kann ich es nicht testen
"damp" ist im XML nicht definiert.
Der WDS ist ein 3-state sensor, welcher also 3 Zustände liefert, A, B oder C. Also eigentlich nie "damp"

Man kann über die Register einrichten, wann welche message kommen soll
A: keine message oder Dry (default)
B: keine message, Dry, Water oder Wet (default)
C: keine message, Water (default) oder Wet

Damp ist keine Option. Damp ist wohl mit wet gleichzusetzen.

Weiter ist definiert, dass dry=0, wet=100(50%) und water=200(100%) entspricht.

ok, erste inkonsistenz: entweder damp oder wet nutzen - dass sind offensichtlich synonyme

Nun ist es mit der Einstellung bei HM etwas kompliziert, so man von den defaults abweicht. Das Verhalten wie ich es kenne:
Position A = 0(0%) also physikalisch trocken. Einstellbar ist, keine Mesage oder "trocken" (00)
Position B = 100(50%)  physikalisch feucht. Einstellbar ist, keine Mesage, "trocken", feucht(64) oder nass(C8)
Position C = 200(100%)  physikalisch nass. Einstellbar ist, keine Mesage, feucht(64) oder nass(C8)

Als event wird gemeldet /gemappt
bei 00(=0=0%) "dry" => ok
bei 64(=100=50%) "damp" => könnte"wet" sein
bei C8(=200=100%) "wet" => könnte "water" sein

Ich hoffe, eq3 hat wet und water nicht verdreht.... müsste man testen, wenn man ein device besitzt

[Pfriemler]

0. Ich finde die Diskussion gehört eigentlich nach "Homematic" verschoben.

Martin, ich kann das alles nachvollziehen was Du schreibst, aber wie lösen wir das Problem jetzt - das war meine Frage.
Nochmal etwas anders formuliert:

1. Es ist kein funktionelles Problem. Derzeit werden die Zustände alle gemeldet und können ausgewertet werden. Nur wie sie (richtig) heißen, ist strittig.

2. eq3 gibt über die XML die literals "dry", "wet" und "water" vor. Das entspricht auch der technischen Funktion des Sensors: Der WDS steht auf vier Elektroden, von denen jeweils zwei ein Kontaktpaar bilden, mit dem zunächst eine leitfähige Oberflächenbenetzung erkannt werden kann - eine feucht gewordene Staubschicht, eine nasse Pappe oder ein nasser Teppich. (Auf glatten Böden dürfte die Oberflächenspannung von Wasser einen durchgängigen Feuchtebelag verhindern). Der Untergrund ist dann jedenfalls "nass", was man sowohl mit "damp" als auch "wet" übersetzen kann. Eine fünfte Elektrode hängt frei und bekommt erst Kontakt, wenn sich ein Wasserstand von 1-2mm gebildet hat. Das ist dann der 100%-Wert "water" (laut eQ3) bzw. "wet" (laut CUL_HM).
Von daher finde ich die eq3-Bezeichnungen auch technisch korrekter als die die CUL_HM verwendet.

3. CUL_HM übersetzt die Zustände seit Jahren unverändert nach "dry", "damp" (50%) und "wet" (100%), wie Du ja schriebst. "wet" bedeutet hier also etwas anderes als bei eQ3. Woher diese Bezeichnungen stammen, kann ich nicht nachvollziehen, aber sie sind nun einmal da.

4. Benutzer, die mit einem Gerät noch nicht vertraut sind, suchen nach Infos zu den möglichen Zuständen des Gerätes. Als Homematic-User hat man gelernt, dass man diese auch über die A,B,C-Positionsangaben der Register herausbekommt - das klappt bei allen Kontaktinterfaces und Fenstersensoren. Man liest sie über "regList" oder bekommt sie, wenn man die versteckten Readings sichtbar macht, sogar in der Device-Ansicht angezeigt.

Nun haben wir eben die Diskrepanz, dass man aktuell beim WDS dort "dry", "wet" und "water" angezeigt bekommt, der Sensor in FHEM aber nur "dry", "damp" und "wet" darstellen kann. Ich sehe zwei Lösungsmöglichkeiten für das Problem:

a) CUL_HM wird geändert, der Sensor hat künftig in FHEM die Zustände "dry", "wet" oder "water". Damit laufen alle Routinen ins Leere, die auf den Zustand "damp" reagieren, und alle Routinen, die auf "wet" reagieren, werden auf anderen anderen Zustand als vorher reagieren. Alle WDS-Benutzer müssten ihre Programmierungen anpassen.

b) HMConfig wird geändert und verwendet die literals "dry", "damp" und "wet". Damit wird die Einheitlichkeit wiederhergestellt, ohne dass es zu einer Funktionalitätsänderung kommt und der Benutzer eingreifen muss. Allerdings entspricht die Darstellung der Registerwerte für die Positionen A,B,C in FHEM dann nicht mehr mehr der eQ3-Vorgabe in der XML. Ich halte das für vertretbar, zumal die Namen aller Register in eQ3/CCU ohnehin bereits von denen in FHEM abweichen.

Obwohl ich es für insgesamt korrekter hielte, a) zu machen, plädiere ich aus Gründen der "Rückwärtskompatilität" für b). Du hattest ja schon früher einmal eine von mir vorgeschlagene Vereinheitlichung der Registernamen aus diesen Gründen abgelehnt (was ich rückblickend jetzt ebenso sehen würde).

Einen WDS werde ich in wenigen Tagen haben und könnte dann als "Versuchskaninchen" dienen. Aber ich erwarte keine bahnbrechenden Erkenntnisse. Warum sollte eQ3 die Werte vertauscht haben?

[Pfriemler]

So, jetzt habe ich im zweiten Anlauf endlich einen funktionierenden WDS. Er steht auf einem feuchten Tuch (mit einen Stück Folie unter dem Mittelstift) und liefert "damp" - eine Position, die es laut den Einstellmöglichkeiten gar nicht gibt.

Code Auswählen Erweitern

Internals:
   NAME       Wassermelder_1
   NOTIFYDEV  global
   NR         756908
   STATE      damp
   TYPE       CUL_HM
   chanNo     01
...
   READINGS:
...
     2020-05-09 19:28:23   .R-msgWdsPosA   dry
     2020-05-09 19:28:23   .R-msgWdsPosB   wet
     2020-05-09 19:28:23   .R-msgWdsPosC   water

Attributes:
...   .mId       0045
   model      HM-SEC-WDS


[Christoph Morrison]

Nur mal so als Anmerkung zu 2: Damp und wet sind nicht identisch und da foppt einen die kontextlose Übersetzung im Netz. Wet ist, wenn man wirklich Feuchtigkeit sehen kann, z.B. Tropfen oder Lachen, also eher nass. Damp dagegen ist, wenn etwas leicht feucht ist, also z.B. ein angefeuchtetes Stück Karton oder ein angefeuchteter Lappen. Für damp könnte man auch moist sagen und das würden die meisten Engländer auch eher tun. Außer irgendwas ist eher nicht so gelaufen oder toll wie man gedacht hatte, dann ist das ein damp squib - und daran kann man sich auch wieder damp nähern: Wörtlich genommen ist ein damp squib ein Feuerwerk, das nicht so richtig zünden wollte, weil das Schießpulver feucht wurde.

[Pfriemler]

edit: Nachfrage zu "on_100" nach neuen Erkennnissen hier gelöscht.

[Christoph Morrison]

edit: Nachfrage zu "on_100" nach neuen Erkennnissen hier gelöscht.

Schade. Fass doch bitte mal deine Erkenntnisse zu on_100 zusammen - ich hatte deinen Beitrag gelesen und war nun wirklich gespannt, um was es dabei geht.

[Pfriemler]

Fass doch bitte mal deine Erkenntnisse zu on_100 zusammen - ich hatte deinen Beitrag gelesen und war nun wirklich gespannt, um was es dabei geht.

Naja, beim gründlichen Nachsuchen habe ich bemerkt, dass es ja keineswegs nur um den WDS geht. Und den Sinn und Unsinn hat Martin schon hier ansatzweise erklärt:
https://forum.fhem.de/index.php/topic,63359.msg771086.html#msg771086