Protokoll für Bresser 5CH Temp Hygro

[mrxps]

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

• manufacturer: Bresser
• model name: Weather Center 5-in-1 (Art. 70-02510)

Specifications

• Microcontroller: V 3.3.1-rc4 SIGNALESP cc1101 868MHz - compiled at Mar 22 2018 23:45:03
• Version (Firmware): v3.3.1-rc4
• Versionmodul (FHEM Module): v3.3.3

Es wäre toll, wenn die Bresser Wetterstation implementiert wird.

Folgendes habe ich dazu auf GitHub (merbanan/rtl_433) gefunden:
https://github.com/merbanan/rtl_433/blob/master/src/devices/bresser_5in1.c
https://github.com/andreafabrizi/BresserWeatherCenter

[mrxps]

cc1101_bresser.txt

[HomeAutoUser]

Hallo, kannst du bitte noch ein paar mehr RAWMSG‘s sammeln.

Am besten wäre, du kannst Zwischenzeitlich festhalten welche Werte an dem Display der Station angezeigt werden.

Liebe Grüße

[elektron-bbs]

Wahrscheinlich wird er diesen Sensor mit einem SIGNALduino nicht empfangen können:
Auszug aus: https://github.com/merbanan/rtl_433/blob/master/src/devices/bresser_5in1.c

The device uses FSK-PCM encoding.

Laut https://github.com/andreafabrizi/BresserWeatherCenter allerdings

The sensor transmit the packet on the 868.300M frequency with AM modulation.

aaaber:

The packet is 264 bits long and the bits are ecoded with 1 for high and 0 for low.

[Ralf9]

aaaber:

The packet is 264 bits long and the bits are ecoded with 1 for high and 0 for low.

Dies ist das kleinste Problem

With the sampling rate set to 48Khz we have an average of 6 samples per bit.

evtl passt auch die Datarate nicht

[elektron-bbs]

Mit deiner Firmware dürften die 264 Bit vieleicht funktionieren...

[Ralf9]

Mit einem SIGNALESP macht es wahrscheinlich keinen Sinn es weiter zu versuchen, damit es mit den 264 Bit funktionieren kann ist ein nanoCul oder ähnliches notwendig.
Ich bin mir nicht sicher ob der ESP mit dem sehr langen Signal und dem recht niedrigen Clock von ca 100-120 überhaupt zurecht kommt.
Solange nur viel zu kurze rawmsg empfangen werden, ist die Länge sowieso kein Thema

[sidey79]

The packet is 264 bits long and the bits are ecoded with 1 for high and 0 for low.

Wo ist denn definiert was das Paket ist? Besteht das vielleicht aus mehreren Übertragungen?

[elektron-bbs]

Die Infos findest du auf den verlinkten Seiten. Wenn es keinen Sinn macht, das weiter zu verfolgen, würde ich vorschlagen, das Issue zu schließen.

[beaune33]

Hallo,

das Thema ist zwar schon etwas älter, ich würde es aber gerne nochmal aufleben lassen.

Wenn ich nochmal rekapituliere, was die Schwierigkeiten bisher zu sein schienen, ist das:

• Paketgröße 264 Bit, aber das scheint ja laut @Ralf9 kein wirkliches Problem zu sein, bzw. schränkt vielleicht die verwendbare Hardware für den Signalduino ein, richtig?
• Sampling Rate 48 KHz: Es wurde bezweifelt, dass die richtig ist, aber da das sowohl in diesem Projekt: https://github.com/brainexe/BresserWeatherStation-Go als auch hier https://github.com/andreafabrizi/BresserWeatherCenter so angegeben wurde, scheint mir das zu stimmen.
• Vielleicht ist das Problem die Modulation? Laut https://github.com/andreafabrizi/BresserWeatherCenter ist es ASK, laut https://github.com/merbanan/rtl_433/blob/master/src/devices/bresser_5in1.c aber FSK. Letzteres würde wiederum Sinn ergeben, da die Signalduino-FW 3.3.1 noch gar kein FSK unterstützt hat. Wenn das das Problem wäre, könnte man die Telegramme erst ab 3.3.4 sehen können.
• Stutzig macht mich dann aber wieder der Kommandozeilenaufruf aus den oben genannten Projekten. Demnach wär es ja doch wohl eher ASK:

rtl_fm -M am -f 868.300M -s 48k -g 50

• Und mich wundert auch, dass ich mit meinem sduino V 3.3.4-dev200914 keine Telegramme von diesem Gerät empfange. Damit müßte FSK ja schon gehen. Das mag aber auch ne Konfigurationsfrage sein; vielleicht muß ich FSK erstmal einschalten. Ist mir nicht ganz klar, insbesondere auch nicht, ob ich dann parallel zu FSK auch noch die bisherigen ASK-Telegrame empfangen kann.

Ich werde mir jetzt mal einen SDR-Stick beschaffen, mit dem man laut https://github.com/brainexe/BresserWeatherStation-Go und https://github.com/andreafabrizi/BresserWeatherCenter ja offenbar die Telegramme empfangen und in eine Datei pipen kann. Das wäre dann ein möglicher Workaround für fhem, dass man die Wetterstationsdaten nicht mir einem Signalduino empfängt, sondern mit einem SDR-Stick, und dann die Auswertung der in eine Datei gepipten Daten in einem Dummy-Device zyklisch wiederkehrend in fhem macht. Mag gehen, wär aber nicht schön.

Was meint Ihr? Kriegen wir das für fhem vernünftig gelöst? Informationen und andere Beispielimplementierungen liegen ja eigentlich viele vor.

[elektron-bbs]

Der SDR-Stick zur Analyse ist schon mal ein guter Ansatz.
Meines Erachtens handelt es sich um eine FSK-Modulation. Vielleicht gibt es auch verschiedene Varianten der Station.
FSK funktioniert ja mittlerweile mit dem SIGNALduino.
Das Problem ist nur, die richtige Datenrate und den Frequenzhub herauszubekommen.
Hier finden sich auch noch interessante Infos:
merbanan/rtl_433#719
merbanan/rtl_433#1172
jgromes/RadioLib#168
https://groups.google.com/g/rtl_433/c/9rnXYC8Vb-U
merbanan/rtl_433#1416

[Ralf9]

Mit diesen cc1101 Registerwerten funktioniert inzwischen der Empfang
0001,012E,0246,0306,042D,05D4,06FF,0700,0802,0D21,0E65,0FE8,1088,114C,1202,1322,14F8,1551,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611

Mit dieser Routine werden die beiden checksums berechnet

sub SIGNALduino_Bresser_5in1
{
	my ($name,$dmsg,$id) = @_;
	my $d1;
	my $d2;
	my $bit;
	my $bitsumRef;
	my $bitadd = 0;
	my $sumFlag = -1;
	
	for (my $i = 0; $i < 13; $i++) {
		$d1 = hex(substr($dmsg,$i*2,2));
		$d2 = hex(substr($dmsg,($i+13)*2,2));
		if (($d1 + $d2) != 255) {
			$sumFlag = $i;
			last;
		}
		if ($i == 0) {
			$bitsumRef = $d2;
		}
		else {
			$bit = sprintf("%08b", $d2);
			for (my $j = 0; $j < 8; $j++) {
				$bitadd += substr($bit,$j,1);
			}
			#Log3 $name, 4, "$name Bresser: $bit $bitsum $d2 n=$bitadd";
		}
	}
	if ($sumFlag != -1) {
		return (-1, "Bresser 5in1: Checksum Error pos=$sumFlag");
	}
	if ($bitadd != $bitsumRef) {
		return (-1, "Bresser 5in1: Bitsum Error bitsum=$bitadd ref=$bitsumRef");
	}
	$dmsg = substr($dmsg, 28, 24);
	return (1,$dmsg);
}

Jetzt fehlt noch der Einbau ins SD_WS.pm Modul, ich hab schon mal damit angefangen und dabei die neue Protocoll Id 108 verwendet
14_SD_WS.pm.txt

@elektron-bbs, kannst Du es bitte ins SD_WS.pm Modul einbauen?

Hier sind einige Testdaten:
von beaune33:

MN;D=E6837FE11FE7EFEFFEBD89FFFF197C801EE018101001427600000001;N=7;R=213;
W108#7C801EE01810100142760000  T: 11 H: 42 wind_max_m_s:3.0  wind_avg_m_s:1.8  wind_dir_deg:315.0  rain_mm:7.6

MN;D=E8837FF76FEFEF9CFF8F89FFFF177C80089010106300707600000002;N=7;R=215; 
W108#7C8008901010630070760000  T: 6.3  H: 70  rain_mm: 7.6

MN;D=E5837FEB1FEFEFD8FEB989FFFF1A7C8014E010102701467600000002;N=7;R=215; 
W108#7C8014E01010270146760000  T: 12.7 H: 46

und in diese habe zum Testen "low Bat", eine negative Temperatur und rain eingebaut und die checksum angepasst

MN;D=E4837FEB1FEFEFD8FEB989FF7F1B7C8014E010102701467600800002;N=7;R=215;  W108#7C8014E01010270146760080  T: 12.7 H: 46  low bat
MN;D=E4837FEB1FEFEFD8FEB989FFF71B7C8014E010102701467600080002;N=7;R=215;  W108#7C8014E01010270146760008  T: -12.7 H: 46
MN;D=E9837FF76FEFEF9CFF8FEDFCFF167C80089010106300701203000002;N=7;R=215;  W108#7C8008901010630070120300  T: 6.3  H: 70  rain_mm: 31.2

[elektron-bbs]

Ich sehe es mir an.
Einige Testdaten mehr mit allen Readings wären nicht schlecht.

[janusjanusjanus]

Ich habe obige 14_SD_WS.pm.txt heruntergeladen, umbenannt und in fhem einen reload des Modules gemacht. Mein Signalduino ist "V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:13:56". Die Bresser 5-in-1 sendet, aber fhem empfängt nichts. Woran könnte das noch liegen?

[elektron-bbs]

Diese veraltete Firmware-Version unterstützt noch keine FSK-Modulation und stammt nicht aus unserer Entwicklung.

Ich bin gerade dabei, dieses Protokoll bei uns zu integrieren. Hier bei mir funktioniert es jetzt schon sehr gut und wird dann bald veröffentlicht.

[janusjanusjanus]

Danke für die Rückmeldung.
Dann sollte es mit Version 3.5.0-dev+20201207 doch funktionieren?

Leider funktioniert es damit und dem 3.5.0er-Modul auch nicht:

`version	V 3.5.0-dev+20201207 SIGNALduino cc1101 (chip CC1101) - compiled at Dec 18 2020 22:34:07
versionProtocols	1.21
versionmodul	3.5.0
`
Woran könnte es noch liegen?

[elektron-bbs]

Zu der Firmware gehören auch noch die Protokolldefinitionen und ein dazu passendes Modul. Beides ist bei uns noch nicht veröffentlicht. Bitte hab noch ein paar Tage Geduld.

[janusjanusjanus]

Dann bitte ich um Nachsicht für meine Ungeduld. Ich habe die Bresser-Wetterstation bei Aldi-Nord online erworben und würde sie gerne rechtzeitig zurückgeben, falls ich sie nicht in fhem einbinden kann.
Aber dafür warte ich gerne auch noch ein paar Tage.

[Ralf9]

Ich habe inzwischen in das SD_WS.pm Modul für das BRESSER 5-in-1 alles eingebaut,
die aktuelle Version ist im fhem Forum unter "FSK mit dem SIGNALDuino"
https://forum.fhem.de/index.php/topic,106594.msg1004463.html#msg1004463

@janusjanusjanus
meine Firmware und meine Variante des 00_SIGNALduino.pm Moduls ist hier off Topic. Support gibts dafür im fhem Forum.

Damit das BRESSER 5-in-1 empfangen werden kann, ist eine Firmware die FSK unterstützt notwendig.
Es sollte auch ein 868 MHz cc1101 Modul verwendet werden, es gibt 433 MHz cc1101 Module die bei 868 MHz unbrauchbar sind.

Bei neuen Protokollen ist in der Regel im 00_SIGNALduino.pm Modul auch eine neue Protokoll ID notwendig

[elektron-bbs]

Ich habe jetzt in einem neuen Branch https://github.com/RFD-FHEM/RFFHEM/tree/master_bresser5in1 das Protokoll für BRESSER 5-in-1 Weather Center und Professional Rain Gauge veröffentlicht.

Für den Empfang mit dem SIGNALduino ist Firmware-Version 3.5.0-dev+20201207 erforderlich.

Das Update von FHEM erfolgt mit folgendem Befehl:

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master_bresser5in1/controls_signalduino.txt

Nach einem Neustart von FHEM muss bei dem SIGNALduino (868 MHz, CC110x) unter dem Menupunkt "Display protocollist" das Protokoll 108 aktiviert werden. Anschließend muss noch das Attribut "rfmode" auf den Wert "Bresser_5in1" gesetzt werden. Nachdem der CC1101 konfiguriert ist (das dauert einige Sekunden) aktualisieren sich die Readings auf folgende Werte:

cc1101_config       Freq: 868.300 MHz, Bandwidth: 203 KHz, rAmpl: 33 dB, sens: 8 dB, DataRate: 8207.32 Baud 
cc1101_config_ext   Modulation: 2-FSK, Syncmod: 16/16 sync word bits detected 
cc1101_patable      C3E = 00 84 00 00 00 00 00 00 => 5_dBm 

Nach dem Empfang von 5 gültigen Nachrichten sollte ein neuer Sensor "SD_WS_108" angelegt werden.

[elektron-bbs]

@janusjanusjanus
Kann ich das Emoji so deuten, das der Empfang der Wetterstation damit funktioniert?

[janusjanusjanus]

Ja, bei mir funktioniert es einwandfrei. Herzlichen Dank!

[elektron-bbs]

@janusjanusjanus
Ich habe noch einige Veränderungen in den Settings des CC1101 vorgenommen.
Machst du bitte nochmal ein Update auf diesen Branch und startest anschließend FHEM neu.
Anschließend den rfmode kurz auf SlowRF stellen und danach wieder auf Bresser_5in1. Dadurch wird der CC1101 neu initialisiert. Der Empfang sollte dann weiterhin funktionieren.

[janusjanusjanus]

Funktioniert unverändert weiter. Sollte ich Veränderungen bemerken?

[elektron-bbs]

Nein, wenn der Empfang weiterhin funktioniert, ist alles gut.

[elektron-bbs]

Ich musste nochmal etwas ändern. Bei dem Reading "rain" erfolgte bisher ein Überlauf bei 99,9. Der Zähler ist aber offensichtlich 4-stellig, wie ich gerade festgestellt habe.

[gitpower2017]

Danke elektron-bbs gute Arbeit funktioniert unter FHEM der Empfang meiner 5in1 Wetterstation.
Da ich dies aber gerne direkt als MQTT (per Python) auswerten möchte benötige ich noch ein paar Infos zur Parametrierung

• wie muss man die Parametrierung vornehmen das der Empfang funktioniert?
  Leider ist der Quellcode sehr komplex und ich finde die Passende Register im Code nicht.

[elektron-bbs]

FHEM kann die Daten auch via MQTT weitergeben.
Die Registereinstellungen findest du z.B. in einer Excel-Liste, die ich hier veröffentlich habe: #955 (comment)
oder in der Datei SD_ProtocolData.pm, Protokoll 108.

[gitpower2017]

Danke für die Infos. Werde mir das alles man ansehen. Vielleicht gibts ein "RPI mit MQTT + FHEM"
Schön wäre ein ESP das direkt die Werte per MQTT verarbeitet, aber ich bin kein Entwickler

[Alex-S1981]

Ok scheint zu passen. Die Temp weicht in 50% der Fälle um 1/10 ab wie das was die Anzeige am original Display sagt.

Bresser_5in1_v2 Alex.xlsx
Ich hab am Ende mal ein paar überschrieben und blau markiert.

[Ralf9]

In dem log von Alex habe ich 4 verschiedene Nachrichten gefunden:

E00520B00C1618FFFFFF2028FFFFDBFF01D7 00000000000000000021
C56620B00C1618FFFFFF2028247265FFF0C6 0000000000000000007C
6D1B20B00C1618FFFFFF2028248264FFF0B7 00000000000000000008
5A2B20B00C1618FFFFFF2028248265FFF0B6 0000000000000000001D

mit den Infos in
https://github.com/merbanan/rtl_433/blob/master/src/devices/bresser_6in1.c
bekomme ich

E005 20B00C16 18 FFFFFF 2028 FFFF DBFF01    D7 00000000000000000021
C566 20B00C16 18 FFFFFF 2028 24.7 2 65 FFF0 C6 0000000000000000007C
6D1B 20B00C16 18 FFFFFF 2028 24.8 2 64 FFF0 B7 00000000000000000008
5A2B 20B00C16 18 FFFFFF 2028 24.8 2 65 FFF0 B6 0000000000000000001D
cccc iiiiiiii Tb wwwwww dddd tt t   hh uuuu ss

c LFSR-16 gen 0x8810 key 0x5412
i ID
T s_type - 1: weather station, 2: indoor?, 4: soil probe
b Bat + channel
w wind
d wind_dir
t temperature
h humidity
u UV
s chksum

anscheinend entspricht LFSR-16 dem CRC-16/XMODEM
ich habe es getested mit
https://crccalc.com/

[Alex-S1981]

Würde es was bringen wenn ich mal auf einen Datensatz warte wenn auch Regen und Wind mit dabei sind ?

[elektron-bbs]

Das wäre nicht schlecht. Bitte aber auch die Werte, die die Wetterstation anzeigt mit notieren.

[Alex-S1981]

Die letzen 5 Werte für Windgeschwindigkeit und Richtung, leider nicht ganz genau in welcher Zeile.
Die Werte für wind und richtung ändern sich alle 12 Sekunden mit jeder msg.

Wobei die Geschwindigkeit in "avarge" im Display ausgegeben wird. Gust kann noch den max. Wert anzeigen

average in km/h
8,6 SSW
8,3 SSW
9,0 SW
7,2 SW
6,1 SSW

2021.07.31 07:50:56 4: signalduino: Read, msg: �MN;D=FE6220B00C1618FF77FF1588185261FFF02900000000000000000000;R=234;
2021.07.31 07:51:08 4: signalduino: Read, msg: �MN;D=7C2E20B00C1618FEBDFE2028FFFFC9FF012D00000000000000000000;R=209;
2021.07.31 07:51:32 4: signalduino: Read, msg: �MN;D=FDD420B00C1618FECCFE1588FFFFC9FF01C900000000000000000038;R=215;
2021.07.31 07:51:56 4: signalduino: Read, msg: �MN;D=494B20B00C1618FD9CFD2028FFFFC9FF015000000000000000000120;R=220;
2021.07.31 07:52:08 4: signalduino: Read, msg: �MN;D=2D6020B00C1618FD9CFD2028185261FFF05D00000000000000000009;R=233;
2021.07.31 07:52:20 4: signalduino: Read, msg: �MN;D=18E920B00C1618FDAAFD1808FFFFC9FF016A00000000000000000009;R=226;
2021.07.31 07:52:32 4: signalduino: Read, msg: �MN;D=B59720B00C1618FDBFFD2258185260FFF00900000000000000000020;R=233;
2021.07.31 07:52:44 4: signalduino: Read, msg: �MN;D=E68C20B00C1618FDBFFD2258FFFFC9FF01FB0000000000000000002E;R=233;
2021.07.31 07:52:56 4: signalduino: Read, msg: �MN;D=DC5C20B00C1618FE68FE2028185261FFF08F00000000000000000034;R=208;
2021.07.31 07:53:08 4: signalduino: Read, msg: �MN;D=8A7020B00C1618FEABFE1808FFFFC9FF016700000000000000000004;R=223;

Hier habe ich die letzten 5 Nachrichten genau notiert mit dem Gust Wert (also max Windgeschw)
alles in km/h
4,0 SSE
6,8 SSE
5,4 SSE
5,4 SSW
7,9 SSE

2021.07.31 07:57:56 4: signalduino: Read, msg: �MN;D=9C4F20B00C1618FEEEFE1588FFFFC9FF01A700000000000000000000;R=225;�
2021.07.31 07:58:08 4: signalduino: Read, msg: �MN;D=068720B00C1618FE68FE1588186260FFF02B00000000000000000002;R=234;�
2021.07.31 07:58:20 4: signalduino: Read, msg: �MN;D=C4F320B00C1618FEACFE2028FFFFC9FF013E0000000000000000006C;R=235;�
2021.07.31 07:58:32 4: signalduino: Read, msg: �MN;D=BB0120B00C1618FEACFE2028186260FFF03C00000000000000000051;R=233;�
2021.07.31 07:58:44 4: signalduino: Read, msg: �MN;D=F07D20B00C1618FDD6FE1588FFFFC9FF01C000000000000000000200;R=230;�

Und hier noch ein größerer Auszug aus dem log mit Werten für Wind, aber leider noch ohne Regen.

Verbose 4 mit versch Werten für wind.txt

[elektron-bbs]

Ich habe einen neuen Branch erstellt: master_Bresser6in1
Du müsstest ein Update darauf mit folgendem Befehl durchführen:

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master_Bresser6in1/controls_signalduino.txt

Danach ist ein Neustart von FHEM erforderlich. Protokoll 115 muss dann aktiviert werden. Das Attribut "rfmode" vom SIGNALduino ist auf "Bresser_6in1" zu setzen. Nicht wundern, dieses neue Protokoll unterstützt sowohl 5-in-1 als auch 6-in-1.
Dann sollte es dir, wenn alles passt nach wenigen Minuten einen neuen Sensor "SD_WS_115_0" anlegen.
Der Sensor sendet die Windgeschwindigkeiten in m/s. Falls du km/h bevorzugst, kannst du dir ein Userreading mit diesem Befehl einrichten:

attr SD_WS_115_0 userReadings windGust_kmh {ReadingsVal($name,"windGust",0) * 3.6}, windSpeed_kmh {ReadingsVal($name,"windSpeed",0) * 3.6}

Bitte testen und berichten :-)

[Ralf9]

Du überspringst das Protokoll 114, ist das schon für was anderes reserviert?

In der Anleitung vom 5-in-1 konnte ich nichts über Bat und Kanal finden, evtl gibts dies nicht bei jedem Model

[elektron-bbs]

Du überspringst das Protokoll 114, ist das schon für was anderes reserviert?

Ja, da ist Well-Light_TR401 vorgesehen.

In der Anleitung vom 5-in-1 konnte ich nichts über Bat und Kanal finden, evtl gibts dies nicht bei jedem Model

Ich habe mich erst mal nur an der bresser_6in1.c orientiert.

[Alex-S1981]

So guten Morgen!

Ihr seid ja super, vielen Dank !👍

Das funktioniert alles bestens jetzt. Anbei ein allgemeines log und ein log des Protokoll.

Einzig der Wert für regen wird als "Wochenwert" angezeigt.
Ich hätte eigentlich eher vermutet dass die Empfängerstation das zusammen und umrechnet aber wie es scheint sendet der Sensor bereits mehrere werte für die Regenmenge ?

Kann man das noch herausfinden ?

Alex Verbose 4 1 Aug 21.txt
SD_WS_115_0-2021 log.txt

[Ralf9]

Hast Du die gleiche Bresser5in1 wie in der Anlage?

Interessant ist auch noch ob sich die ID oder was anderes nach einem Batteriewechsel ändert.

Die Regenmenge ist ein fortlaufender Zähler der vermutlich bis 999.9 zählt und dann wieder bei 0 anfängt.
Bei einem Batteriewechsel wird die Regenmenge normalerweise auch auf 0 gesetzt.

Mit den Statistic Modul müsstest Du auch Tages- und weitere Werte bekommen.

[Alex-S1981]

Hast Du die gleiche Bresser5in1 wie in der Anlage?

Ja genau identisch!

Interessant ist auch noch ob sich die ID oder was anderes nach einem Batteriewechsel ändert.

Das Teil hängt jetzt am Giebel der Garage, ich wollte demnächst aber hochwertige Batterien tauschen, dann kann ich berichten.

Die Regenmenge ist ein fortlaufender Zähler der vermutlich bis 999.9 zählt und dann wieder bei 0 anfängt.
Bei einem Batteriewechsel wird die Regenmenge normalerweise auch auf 0 gesetzt.

Mit den Statistic Modul müsstest Du auch Tages- und weitere Werte bekommen.

Das schau ich mir mal an

[elektron-bbs]

Ich habe noch etwas korrigiert und das Reading "windDirectionText" hinzugefügt. Bitte nochmal ein Update durchführen.

[Alex-S1981]

Nach einiger Zeit hab ich nun ärger mit dieser Meldung:

2021.08.04 17:58:43 3: signalduino: SD_WS_115_0 ERROR - Temp diff too large (old 17.2, new 20.9, diff 3.7)
Die Aufzeichnung im Plot stoppt dann bei der ersten Meldung dieser Art.

Wind und Regen, je seperater Plot zeichnet weiter auf.

[Ralf9]

das Problem sind die Attribute max-deviation-hum und max-deviation-temp, da ist in einigen Fällen der Defaultwert 1 zu wenig.
Wenn Du sie auf 50 erhöhst dürfte es damit zukünftig keine Probleme mehr geben.
Siehe auch in der Device specific help

[janusjanusjanus]

Ich habe heute ein Update von fhem gemacht und anschließend
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt
ausgeführt.

Seitdem erhalte ich im log die Meldung
sduino868: SD_WS_Parse UNDEFINED sensor SD_WS_108 detected, code SD_WS_108

Experimentell habe ich auch die 6-in-1-Variante ausprobiert (jeweils das rfmode-Attribut entsprechend gesetzt). Da erscheint aber weder ein Device noch ein Log-Eintrag.

[elektron-bbs]

Wenn autocreate aktiv ist, sollte es dir das Gerät dann auch nach 5 fehlerfrei empfangenen Nachrichten innerhalb von zwei Minuten anlegen.

[janusjanusjanus]

ok, Kommando zurück. Das Device erscheint nun, ohne daß ich etwas geändert hätte.
Merkwürdig, zuvor hatte sich auch nach 10 min nichts getan.

[elektron-bbs]

Vielleicht ist der Empfang zu schlecht, so das die 5 Nachrichten innerhalb 2 Minuten nicht empfangen wurden.
Wie sind die RSSI-Werte?

[elektron-bbs]

Wenn es von euch keine Einwände mehr gibt, würde ich das Protokoll 115 gern in den Master-Branch überführen.

[Alex-S1981]

Ich bin leider noch nicht zum Batteriewechsel gekommen um zu schauen ob die ID wechselt.
Ansonsten hab ich bisher keinerlei Schwierigkeiten feststellen können.

[elektron-bbs]

Die ID wird sich wahrscheinlich nicht ändern, da diese 4 Byte groß ist.
Interessant wäre aber die Anzeige Batterie ok/low.

[janusjanusjanus]

RSSI ist -84.
Funktioniert nun einwandfrei.

[beaune33]

Zur Info: Bei der älteren Variante der 5-in-1 ändert sich die ID bei JEDEM Reset! Also sowohl beim Batteriewechsel, als auch wenn man einfach den Reset-Knopf drückt.

Aus fhem-Sicht heißt das:

• Verwendet man das sduino Attribut "longids", dann wird die Id an den Devicenamen angehängt (z.B.: "SD_WS_108_7C"). Damit können dann mehrere Wetterstationen empfangen werden, der Devicename ändert sich dann aber beim Batteriewechsel, so dass man an die fhem-Konfiguration ran muß.
• Möchte man vermeiden, dass sich der Devicename durch den Batteriewechsel ändert, darf man longids nicht verwenden, dann merkt fhem gar nicht, dass sie sich geändert hat. In der Folge kann man dann nur auf eine Wetterstation gleichen Typs zugreifen, aber in der Regel hat man ja auch nur eine, so dass das keine relevante Einschränkung ist.
• Damit man trotzdem feststellen kann, dass sich die ID geändert hat, oder dass mehrere Wetterstationen gleichzeitig empfangen werden, hat Ralf9 das Reading sensorId vorgesehen. Dann liegt zumindest die Info in fhem vor und der Anwender kann selbst entscheiden, ob ihn die ID interessiert oder nicht.

Ich würde mal davon ausgehen, dass sich die 6-in-1 beim Reset genauso verhält und würde daher denselben Umgang mit der ID anregen.

[elektron-bbs]

Bei Protokoll 108 umfasst die ID nur ein Byte, während bei Protokoll 115 vier Byte für die ID verwendet werden.
Deshalb gehe ich davon aus, das diese eindeutig ist und sich nicht ändert. Vier Byte sollten ja mal bei der Internet-Adresse für die ganze Welt reichen :-) Vielleicht testet es ja mal jemand.

Sollten mehrere Sensoren mit einer Definition empfangen werden, so bemerkt man das ziemlich schnell an ungewöhnlichen "Zacken" in den Diagrammen, wie es hier schön zu erkennen ist:

oder auch an Logeinträgen wie z.B. diesem:

2021.08.04 17:58:43 3: signalduino: SD_WS_115_0 ERROR - Temp diff too large (old 17.2, new 20.9, diff 3.7)