Pearl Sensor für FWS-70 wird als SD_WS07_TH erkannt statt als SD_WS07_T

[plin2]

Specifications for new sensor / switch / or other device ...

• manufacturer: Pearl
• model name: FWS-70
• pictures of the device / the board (very helpful) ; https://www.pearl.de/a-NX6876-3041.shtml

Specifications

• Microcontroller: SIGNALduino mit CC1101
• Version (Firmware): V 3.4.0 SIGNALduino cc1101 (chip CC1101) - compiled at Jul 16 2020 20:52:15

• Versionmodul (FHEM Module): v3.4.4

Recherche/Analyse: siehe https://forum.fhem.de/index.php/topic,113600.0.html

Ich besitze 3 neue Funkthermometer (Funk-Außensensor für Wetterstation FWS-70, https://www.pearl.de/a-NX6876-3041.shtml) von Pearl. Diese wurden von FHEM (V 3.4.0 SIGNALduino cc1101 (chip CC1101) - compiled at Jul 16 2020 20:52:15, versionmodul v3.4.4) als SD_WS07_TH-Devices erkannt. Die Sensoren liefern korrekte Temperaturwerte. Die Humidity Nibbles werden mit nicht nachvollziehbaren Werten gefüllt. Einige davon im Bereich >100. Bei $model <> SD_WS07_T wird die Humidity auf Plausibilität geprüft. Werte über 100 führen dazu, dass sowohl Temperatur als auch Humidity verworfen werden. Folge: es werden nur hin und wieder Temperaturen in FHEM eingeliefert.

In einem Zeitraum von ca. 8 Stunden erschien die Meldung "mySIGNALduino: SD_WS07_TH_3 ERROR - Humidity out of range 0-100: (251)" 1.151 mal.

Laut Beschreibung des Produktes auf der Seite https://www.pearl.de/a-NX6876-3041.shtml scheint die Wetterstation auch die Humidity anzuzeigen, der zugehörige Sensor liefert aber nur Temperaturwerte.

Im Modul 14_SD_WS07.pm müsste die Abfrage ab Zeile 198ff. eine Möglichkeit beinhalten, die Lieferung/Validierung von Humidity explizit auszuschalten.

Als Anlage diverse Logs und ein Screenshot mit Temperaturen/Humidity der vorhandenen sowie der neuen Funkthermometer (die vorhandenen stammen aus einer ande4ren Modellreihe).

Issue_SD_WS07_TH.zip

[elektron-bbs]

Die Kanäle scheinen ja schon mal zu stimmen.
Interessant wäre noch, ob "batteryState" und "sendmode" passen.

Wenn ja, würde ich vorschlagen im Modul 14_SD_WS07.pm die Weiterbearbeitung bei ungültigen Feuchtewerten nicht abzubrechen:

	$hum += AttrVal($name, "offset-hum", 0);				# correction value for humidity (default 0 %)
	if ($model ne "SD_WS07_T" && $hum > 100 || $model ne "SD_WS07_T" && $hum < 0) {
		Log3 $name, 4, "$iohash->{NAME}: $name ERROR - Humidity out of range 0-100: ($hum)";
		# return "";
	}

und dafür ein Update des Readings "humidity" nur bei Feuchtewerten kleiner/gleich 100 durchzuführen:

    readingsBulkUpdate($hash, "humidity", $hum)  if ($models{$modelkey} eq "TH" && $hum <= 100);

[plin2]

mmh, das wird bei dem Sensor nur zu unnötigen Rückfragen/Issues führen ("Der zeigt falsche Werte an"). Als Anlage ein Vergleich der Messwerte alte/neue Sensoren. Die "moderne Kunst" unten rechts entspricht dem Ansatz "wenn's im Bereich 0-100 liegt darf es durch".

Ich würde eher den Ansatz verfolgen:
max-deviation-hum:1,2,3,4,5,6,7,8,9,10,15,20,25,30,35,40,45,50,999 offset-hum
und die Abfrage in Zeile 198 so ergänzen, dass bei 999 die Humidity auf 0 gesetzt wird (egal welcher Wert geliefert wird). Das sollte auch in der Doku stehen, damit bei diesen Sensoren keine falschen Erwartungen geweckt werden.

[elektron-bbs]

Ich denke, du hast Recht.
Kannst du mal bitte noch ein paar Daten in dieser Excel-Tabelle ergänzen. Ich möchte wissen, ob sich in den Werten der Feuchte wirklich nur Zufallszahlen befinden, oder ob es sich um irgendein Prüfverfahren handelt.

SD_WS_07.xlsx

Bitte auch gleich noch "batteryState" und "sendmode" verifizieren.

[plin2]

Ich habe einige Logs der letzten Tage ausgewertet und ab Zeile 487 ins Excel eingefügt, nach Channels getrennt.

Die Batterien sind frisch, also passt der "batteryState". Was ist der "sendmode"?
SD_WS_07_20200821.xlsx

[elektron-bbs]

Es wäre gut, wenn du auch mal probierst, den "batteryState" auf "low" zu bringen, entweder mit einem Labornetzteil soweit vorhanden, ansonsten vielleicht mit älteren Batterien oder Akkus...

Der Sensor hat eine Taste beschriftet mit "TX". Wenn du diese betätigst, sollte sich in FHEM das Reading "sendmode" in "manual" ändern. Wenn das nicht der Fall ist, bitte davon Logs hochladen,

[plin2]

batteryState kann ich bestätigen. Bei alten Battrien geht der auf low.

De sendmode macht Probleme. Ich sehe Readings "sendmode" die auf "auto" stehen, aber mindestens einen Tag alt sind. Wenn ich versuche über den TX-Button ein Update zu provizieren, ändert sich nichts. Der dekodierte Code ist P7#B7D11BF9A.

Beim Betätigen von TX scheint der Sensor den Channel zu ändern (1->5->1->5, 2->6->2->6 ...).

[elektron-bbs]

Das habe ich mir fast schon gedacht. Bei den bisher erfassten Sensoren (bis auf einen) wurde der Kanal aus 3 Bit gebildet. Hier sind es jetzt, wie beim Auriol nur 2 Bit:

  # 0   4    8     12            24    28       36
  # 00110110 1010  000100000010  1111  00111000 0000  eas8007
  # 01110010 1010  000010111100  1111  00000000 0000  other device from anfichtn
  # 11010010 0000  000000010001  1111  00101000       other device from elektron-bbs
  # 01100011 1000  000011101010  1111  00001010       other device from HomeAuto_User SD_WS07_TH_631
  # 11101011 1000  000010111000  1111  00000000       other device from HomeAuto_User SD_WS07_T_EB1
  # 11000100 1000  000100100010  1111  00000000       other device from HomeAuto_User SD_WS07_T_C41
  # 01100100 0000  000100001110  1111  00101010       hama TS36E from HomeAuto_User - Bat bit identified
  # Long-ID  BCCC  TEMPERATURE    ??   HUMIDITY       B=Battery, C=Channel

  # 10110001 1000  000100011010  1010  00101100       Auriol AFW 2 A1, IAN: 297514
  # Long-ID  BSCC  TEMPERATURE    ??   HUMIDITY       B=Battery, S=Sendmode, C=Channel
	
  # 01001010 1000  000100000000  1111  01101000       Pearl FWS-70 (Bit 28-35???)
  # Long-ID  BSCC  TEMPERATURE    ??   RANDOM??       B=Battery, S=Sendmode, C=Channel

Ich schätze, wir müssen ein zusätzliches Attribut "model FWS-70" hinzufügen, es sei denn, wir kommen noch dahinter, diesen Sensor automatisch anhand des letzten Bytes (Feuchte) zu identifizieren.

Hat sich eigentlich beim Batteriewechsel die Ident (Byte 0) geändert?

Die Daten aus der Excel-Tabelle von dir habe ich jetzt hier eingepflegt. Bitte nochmal ergänzen, aber nicht mit möglichst vielen Daten, sondern mit möglichst unterschiedlichen Daten. Du kannst die Daten auch gleich in die entsprechenden Blätter einfügen. Entscheidend ist nicht die Kanalnummer (hattest du zwischenzeitlich geändert), sondern die Ident (Byte 0).
SD_WS_07.xlsx

[plin2]

'>es sei denn, wir kommen noch dahinter, diesen Sensor automatisch anhand des letzten Bytes (Feuchte) zu identifizieren.
ich denke das wid nicht klappen. Ich habe die binäre Darstellung des Codes aus dem Log selektiert, nach den letzten 8 bits sortiert und verdichtet (siehe last_nibbles_sorted.txt). Ergbenis: Da findet sich fast jede binäre Zahl.
last_nibbles_sorted.txt

'>Hat sich eigentlich beim Batteriewechsel die Ident (Byte 0) geändert?
ja, habe ich ins beigefügte Excel bei Channel 2 eingetragen.
ch2_battery_change.txt

'>Bitte nochmal ergänzen, aber nicht mit möglichst vielen Daten, sondern mit möglichst unterschiedlichen Daten.
Wieviel Varianz bzw. an Änderung an welchen Stellen brauchst Du? Die kann ich dann gezielt raussuchen und ergänzen.
SD_WS_07_20200822.xlsx

[elektron-bbs]

Ich habe keine Idee, wie wir das vernünftig lösen können.

Problem 1 ist, das statt der Feuchte offensichtlich alle Werte von 0 bis 255 vorkommen. Bei Wert 0 würde z.B. ein Sensor
SD_WS07_T_1 angelegt und bei Werten von 1 bis 100 ein SD_WS07_TH_1. Das lässt sich noch relativ einfach prüfen, ob T oder TH bereits definiert ist.

Problem 2 ist das Bit "sendmode", das bei bisherigen Definitionen Bestandteil des Kanales ist.

Beim Betätigen von TX scheint der Sensor den Channel zu ändern (1->5->1->5, 2->6->2->6 ...).

Ich weiß nicht, ob es wirklich Sensoren mit diesem Protokoll und mehr als 4 Kanälen gibt, sonst könnte ich die Kanäle auf 2 Bit einschränken.

Ideen sind gefragt :-)

[plin2]

Problem 1: Ich würde ein zusätzliches Attribut SD_WS07_override_model mit den Optionen SD_WS07_TH und SD_WS07_T aufnehmen.

Problem 2: Wenn ich mir die Bedienungsanleitung anschaue, kann ich nur 3 Außensensoren anbinden


2 Bits müssten somit für die Kanäle ausreichen.
Ich würde ein zusätzliches Attribut SD_WS07_override_chanbits mit den Optionen 2 und 3 aufnehmen. Bei 2 bits kann das führende 3. wieder als sendmode herhalten.

Das hält die ganze Sache flexibel und ich kann nachträglich korrigieren.

[elektron-bbs]

Das Problem dabei ist, das erst geprüft wird, ob ein Gerät schon existiert. Nur wenn es schon angelegt ist, hat das Modul Zugriff auf die Attribute.
Angenommen, N2 (siehe Excel-Tabelle) sieht so aus: 1101
Ist das jetzt ein "normaler" WS07 auf Kanal 6 oder ein Pearl-Sensor auf Kanal 2 mit Bit sendmode 1?
Es müssten also alle Varianten vorher geprüft werden. Erschwerend kommt hinzu, das die Sensoren auch noch mit longids definiert sein könnten.

[plin2]

Wenn wir das Thema 3 oder 6 Channels mal neutral betrachten: Die FWS-70 kann nur drei Kanäle bedienen. Wir wollen die Sensoren für die Heimautomation nutzen. Wir können auch 6 Channels bedienen so wie die Sensoren es hergeben. Nur das Reading sendmode leidet darunter. Am Anfang war ich verunsichert, wieso neben Channels 1-3 noch weitere Devices auf den Kanälen 5-7 auftauchten. Das müsste man z.B. in der Doku transparent machen. Insbesondere da im Display nur die Channels 1-3 angezeigt werden.
Bedeutet aber auch: Ich kann eine Produktserie für 6 Räume nutzen und muss nicht so wie ich auf 2 verschiedene Produktserien mit je 3 Channels ausweichen. Die wilden Feuchtigkeitswerte sind störender als das Channel-Thema.

[elektron-bbs]

Du kannst auch jetzt schon mehr als 3 Sensoren einer Serie nutzen. Dafür gibt es das Attribut "longids". Damit können prinzipiell bis zu 256 Sensoren unterschieden werden.
Ich habe jetzt mal das Modul SD_WS07 um ein Attribut "type" erweitert. Wenn du dieses auf "FWS-70" setzt, wird die Feuchte nicht mehr ausgewertet.
14_SD_WS07.zip

Es hat aber den Nachteil, das z.B. beim Betätigen der Sendetaste neue Sensoren angelegt werden:

2020.08.27 13:13:19 4: sduino_dummy: SD_WS07_Parse SD_WS07 (P7#60D106F59) length: 9
2020.08.27 13:13:19 4: sduino_dummy: SD_WS07_Parse SD_WS07 converted to bits 01100000 1101 000100000110 1111 01011001
2020.08.27 13:13:19 1: sduino_dummy: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_6

oder auch beim Empfang vom Feuchtewerten gleich 0:

2020.08.27 13:20:42 4: sduino_dummy: SD_WS07_Parse SD_WS07 (P7#609106F00) length: 9
2020.08.27 13:20:42 4: sduino_dummy: SD_WS07_Parse SD_WS07 converted to bits 01100000 1001 000100000110 1111 00000000
2020.08.27 13:20:42 1: sduino_dummy: UNDEFINED Sensor SD_WS07_T detected, code SD_WS07_T_2

@sidey79 , @Ralf9 oder andere, die Sensoren dieses Typs verwenden...
In der Dokumentation zum Modul steht:

#  flags are 4 bits B 0 C C, where B is the battery status: 1=OK, 0=LOW 
#  and CC is the channel: 0=CH1, 1=CH2, 2=CH3 

Ausgewertet werden dann aber 3 Bit:

my $channel = oct("0b" . substr($bitData,9,3)) + 1;

Was ist richtig?

[Ralf9]

Die Dokumentation ist von hier:
https://initrd.net/stuff/rtl_433/src/devices/nexus.c

[elektron-bbs]

Dort werden dann auch nur 2 Bit verwendet:

channel = ((b[1] & 0x30) >> 4) + 1;