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?
Thema: Korrektur / Ergänzungen zum Wiki Artikel zu HM-Sec-WDS Funk-Wassermelder (Gelesen 8595 mal)