FODY E42 für Tempus Pro E41 Thermo-/Hygrosensor Funk 868 MHz

[Noop]

Hallo,

ich möchte gerne die Temperaturen meiner Innen- und Außenräume kontinuierlich messen und speichern.
Als Neuling ohne Ahnung dachte ich mir Sender = Sender und solange die Mhz stimmen wirds schon klappen. Noch einen Jeelink dazu und fertig.
Erst nach dem Bestellen und Lesen einiger Anleitungen kam ich dann drauf, dass das nicht so einfach wird 

Nun habe ich also hier ein paar super günstigen Fody E42 Sensoren (1,52€ pro Stück + Versand [Conrad / Voelkner]) aber kann momentan nichts damit anfangen.
Im Internet habe ich leider nicht mehr gefunden, als was in der Bedienungsanleitung steht. Die Firma Fody scheint nicht mehr zu existieren.

Vielleicht findet sich aber hier jemanden, der mir helfen kann diese Dinge zu verstehen oder es gibt gar existierende / verwandte Integrationen dafür?
Dafür habe ich mal einen der Sensoren auseinander genommen (siehe Bilder).
Vielleicht kann jemand dem etwas hilfreiches abgewinnen?

Oder sollte ich jetzt erstmal einen DVBT-Stick kaufen um das Signal aufzunehmen?
Wie viel Geduld sollte man denn mitbringen um so ein Signal zu entschlüsseln?

Danke im Vorraus
Noop

P.S.: Nach weiterer Internetsuche habe ich einen Reverse-Engineering blog vom Fody Tempus Multisensor (Regen, Wind, Temp, Hygro) gefunden:
https://forum.mysensors.org/topic/6645/fody-weather-station-wind-sensor
Es scheint allerdings, dass der user ihn mit einem arduino direkt verbindet statt über Funk.

Der Thermo-/Hygrosensor ist demnach bekannt. Allerdings gibt es nichts über das Funkprotokoll.
"It was a HT-01D sensor for measuring temp/hum. It is I2C and address is 0x28.
I found code for HYT 221 that worked fine"

[KölnSolar]

Hi Noop,
willkommen bei FHEM. Du fängst ja gleich mit komplizierten Dingen an. Hast Dich aber scheinbar schon gut mit ein paar Basics

Erst nach dem Bestellen und Lesen einiger Anleitungen kam ich dann drauf, dass das nicht so einfach wird

auseinandergesetzt und verstanden.

Allerdings gibt es nichts über das Funkprotokoll.

Nicht wenigstens eine genauere Frequenzangabe und/oder das "Funkverfahren(ASK,OOK,FSK....)" ?

Ansonsten wird es schwierig für einen Einsteiger. Wäre interessant die Dinger mal in einer "868-(nano)CUL-Umgebung zu beobachten. Als nanoCUL ließe sich der vielleicht noch als S'duino flashen, wobei ich nicht weiß, ob das für einen 868 überhaupt machbar ist. Vielleicht meldet sich Ralf9 mal dazu.

Grüße Markus

[elektron-bbs]

Schätzungsweise dürfte der SIGNALduino die geeignetere Wahl sein. Ich vermute aber, das das Teil mit Frequenzmodulation sendet. Die Angabe "Update Interval: 12 Seconds" lässt mich darauf schließen, da bei OOK/ASK eher größere Intervalle üblich sind.
Der Empfang frequenzmodulierter Signale ist etwas komplizierter, da erst weitere Parameter, wie z.B. die Datenrate erforderlich sind. Der DVB-T-Stick wäre dazu schon mal ein guter Ansatz.
Ich habe mal probehalber so einen Sensor bestellt und werde berichten...

[KölnSolar]

Ich habe mal probehalber so einen Sensor bestellt und werde berichten...

priiimaaa.  Preislich ist der ja unschlagbar u. hässlich ist der auch nicht. Mich ärgern nur die Versandkosten. 

Hab auch mal gegoogeld. Nichts zu finden, außer der I2C-Protokollbeschreibung
attiny85 mit 433-Sender einbauen wäre auch ne Option. 
Grüße Markus

[Noop]

Hallo,

Vielen Dank für das herzliche Willkommen und eure Antworten.
"ich habe mal probehalber so einen Sensor bestellt und werde berichten..." - wow!

Ja, ich hatte es mir tatsächlich nicht vorgestellt gleich so tief einzusteigen.
Ich könnte auch 1-2 verschicken wenn jemand Interesse hat.
Ich habe mich von dem günstigen Einzelpreis locken lassen und zwecks Versandkostenersparnis gleich einige bestellt.

Über das Funkprotokoll / genauere Frequenz / Modulationsverfahren konnte ich leider nichts finden.
Bin also sehr gespannt, was electron-bbs damit empfangen wird.
Ich werde mir dann wohl noch so einen DVBT-Stick kaufen und mich am Wochenende damit auseinandersetzen.
Mit einem 868mhz jeelink (clone) kann man die Modulation /Datenrate nicht herausfinden, oder?

"attiny85 mit 433-Sender einbauen" hieße das pro Sensoreinheit nur den Sensor (und Stromversorgung?) zu verwenden, die 2 Komponenten kaufen, irgendwie neu zusammen stecken, einen custom sketch dort aufspielen der den Sensor liest und die daten dann mit einem bekannten Protokoll funkt?

[KölnSolar]

"attiny85 mit 433-Sender einbauen" hieße das pro Sensoreinheit nur den Sensor (und Stromversorgung?) zu verwenden, die 2 Komponenten kaufen, irgendwie neu zusammen stecken, einen custom sketch dort aufspielen der den Sensor liest und die daten dann mit einem bekannten Protokoll funkt?

Genau. Oder halt einen anderen MC+Sender. Ich mag die attinys, weil klein, stromsparend,preiswert,Arduino-IDE-kompatibel...

Ich könnte auch 1-2 verschicken wenn jemand Interesse hat.

Ich sah kürzlich ums Eck einen Conrad-Schriftzug an einer Halle. Bingo.  Wir haben wieder einen Shop in Colonia. Ich kann wohl dorthin bestellen...

[Noop]

Wir haben wieder einen Shop in Colonia. Ich kann wohl dorthin bestellen...

Habt ihr eine Ahnung welche DVB Sticks man nehmen kann? Funktioniert es mit allen? Es gibt wohl DVT-T1 und DVB-T2. Und vielleicht gibt es ja noch andere Unterschiede... Ich will nicht wieder denselben Fehler machen und erst bestellen und dann feststellen, dass es nicht geht

[KölnSolar]

Nein leider nicht. Aber wenn Elektron-bbs seine Sensoren hat, werden wir schnell wissen, ob  und wie der funktioniert. Den Stick kannst Du Dir dann sparen. Ich hab vor Jahren mal ein Protokoll über eine Soundkarte und Audacity analysiert. Ging für ASK/OOK recht gut. Musst Du mal googeln, ob das vielleicht die preiswertere Alternative ist, um die Wartezeit zu überbrücken.

Grüße Markus

[elektron-bbs]

Das Netz ist voll mit Listen von tauglichen Sticks, wie z.B.:

https://www.funk-technik.info/alles-%C3%BCber-rtl-sdr/welche-dvb-t-stick-funktionieren.html
http://thomas-messmer.com/index.php/15-free-knowledge/allerlei/technische-informationen/6-sdr-via-dvb-t-stick
https://osmocom.org/projects/rtl-sdr/wiki/Rtl-sdr

PS: Die Lieferung der Sensoren ist für Sonnabend angekündigt.

[Noop]

Danke. Dann bin ich einfach geduldig.
Ich dachte ich kann damit vielleicht etwas zur Lösung beitragen, aber vermutlich bekommt electron-bbs eh mehr dabei heraus. Schönen Abend euch!

[elektron-bbs]

Kurzer Zwischenstand:
Die Sensoren wurden heute schon geliefert. Mit dem SIGNALduino werden sie bereits empfangen und dekodiert. Das Protokoll ist gleich bzw. ähnlich dem der Wetterstation Bresser 5-in-1. Das dazugehörige Modul muss noch angepasst werden, da die Sensoren natürlich keine Messwerte für Wind und Regen liefern.

[KölnSolar]

 

[Noop]

Wow. Das klingt ja viel besser als erwartet.
Das heißt ich brauche zum empfangen dann auch einen SIGNALduino, oder geht das mit dem jeelink?
Ich hatte im Forum glaube auch gelesen man würde jetzt MiniMaple empfehlen, kann das sein? Trifft das hier zu? Tut mir leid für die vielen Fragen - es ist leider für mich nicht so einfach da durchzublicken, auch wenn ich mich bemühe es nachzulesen und zu verstehen.

[Noop]

Auf github habe ich zum SIGNALduino gefunden, dass es wohl auch einen reinen Thermo/Hygro Sensor von Bresser gibt. Vielleicht ist dessen Implementierung ja sogar noch besser geeignet:
https://github.com/RFD-FHEM/RFFHEM
Hama TS33C, Bresser Thermo/Hygro Sensor    Weather sensor

[KölnSolar]

Das heißt ich brauche zum empfangen dann auch einen SIGNALduino, oder geht das mit dem jeelink?

Ein Siganlduino muss es schon sein. Mal grob, was die USB-Sticks ausmacht/unterscheidet: MC,firmware,Funkmodul. Als MC kommt in der Regel ein Arduino zum Einsatz. Gerne wird der nano genommen. Bei den Funkmodulen ist es beim Jeelink wohl ein RF12B-Funkchip. Die firmware ist dann auf den Funkchip ausgelegt. Der Signalduino ist ein DIY-Projekt und wesentlich variabler bei der Auswahl der Hardware. So ist z.B. die Kombination eines ArduinoNano mit CC1101-Funkchip möglich. Diese Konstellation entspricht dann hardwaretechnisch einem nanoCUL, den man als Signalduino aber auch als nanoCUL einsetzen kann. Der Unterschied besteht in der firmware. Und natürlich ist beim Funkchip die Frequenz zu beachten. Zwar lässt diese sich in der Regel per Software verändern, aber die Platinchen sind so optimiert, das sie "vernünftig" nur in ihrer Auslegungsfrequenz funktionieren. Im Fody-Fall also 868 MHz.
Zu Deiner Frage kommt es jetzt darauf an, ob Du Bastler bist u. den Jeelink ggfs. selbst gebaut hast(oder bauen könntest). Wenn nicht müsstest Du Dir einen 868-Signalduino kaufen.

Vielleicht ist dessen Implementierung ja sogar noch besser geeignet

Verlass Dich mal auf das know-how von electron-bbs. 
Das von Dir gefundene Protokoll ist anders als das der Bresser 5-in-1. Wenn Du Perl kannst oder lernen möchtest, dann guck mal zu Deinem Link in das Perl-Modul. Dort siehst Du die unterschiedlichen Protokolle.
Grüße Markus

[Noop]

Vielen Dank Markus und elektron-bbs!
Ich habe mir jetzt einen 868mhz nanoCUL bestellt.

Danke für den Link zum Perl modul, das sollte ich hinbekommen zu lesen

"Verlass Dich mal auf das know-how von electron-bbs."
Ja, nach dem was ich in github sehe ist seine Erfahrung wohl keine Zufall

[Ralf9]

Hallo,

falls jemand einen FODY E42 übrig hat, ich könnte einen gebrauchen.

Beim nanocul gibts mittlerweile auch eine Variante die als new nanocul bezeichnet wird und nicht kompatibel zum nanocul ist.
Da dort der Atmega32U4 verwendet wird, ist dafür eine spezielle sduino firmware notwendig.

Gruß Ralf

[rob]

@Ralf: ich hätte einen abzugeben. Kostenlos versteht sich. Wenn Du den haben magst, sag mir nur wohin ich ihn senden soll

VG
rob

[elektron-bbs]

Ich habe das Modul 14_SD_WS.pm angepasst, so das diese Sensoren dekodiert werden. Im Anhang ist das angepasste Modul, das in FHEM ersetzt werden muss.

Erforderlich ist dafür die aktuelle Firmware Version 3.5.0-dev+20210808 (derzeit noch aus dem Entwicklerzweig) hier zu finden: https://github.com/RFD-FHEM/SIGNALDuino/releases

Dann muss bei dem SIGNALduino das Attribut "rfmode" auf "Bresser_5in1" gesetzt werden.

Damit sollte der Empfang bereits funktionieren.
Soll mehr als ein Sensor empfangen werden, muss bei dem SIGNALduino noch das Attribut "longids" auf den Wert "SD_WS_108" gesetzt werden. Dann werden die Sensoren mit einer eindeutigen Ident, wie z.B. "SD_WS_108_73" angelegt.

[rob]

Vielen Dank für die Anpassung + Info.
Aktuell verwende ich den Sduino für meine Wetterstation (WH1080; Protokoll-ID#9) und habe noch Version "V 3.3.2.1-rc9 SIGNALduino cc1101 - compiled at Jun 16 2019 20:18:01" aktiv. Werde dann wohl wechseln müssen 

Bevor ich ändere, hätte ich zwei Fragen:
Verträgt sich das Attribut "rfmode" auf "Bresser_5in1" gesetzt mit anderen Protokollen, oder kann ich den Sduino dann nur exklusiv für die Fody's nutzen?
Welche Frequenz usw. sollte via cc1101_config gesetzt sein? Für meine Wetterstation hab ich sie aktuell so:

Code Auswählen Erweitern

ccconf: Freq: 868.400 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 4 dB, DataRate: 5603.79 Baud, Modulation: ASK/OOK, Syncmod: No preamble/sync

Vielen Dank und beste Grüße
rob

[Ralf9]

Für FODY E42 benötigst Du einen weiteren 868MHz sduino.

WH1080 (Protokoll-ID#9) hat die Modulation: ASK/OOK (SlowRF)

FODY E42 hat die Modulation FSK, das cc1101 Modul wird da in einem anderen Modus betrieben.

Gruß Ralf

[KölnSolar]

Hi Ralf,
ich blick ja nie so ganz zwischen Euren Versionen der firmware durch.  Ist die 3.5.0-dev+20210808 dann grob vergleichbar Deiner 3.3.4.0-dev200126 und lässt sich der CC1101-Signalduino zwischen den verschiedenen Modulationsverfahren umschalten(ccmode ?) ?

Dann muss bei dem SIGNALduino das Attribut "rfmode" auf "Bresser_5in1" gesetzt werden.

Also wird man die PCA301 nicht gleichzeitig empfangen können, oder ?

Grüße Markus

[Ralf9]

Ja beide firmware können FSK, sind aber bei FSK nicht kompatibel. Ich verwende eine konfigurationsvariable N, die an die raw Nachrichten angehängt wird. Die benötige ich für maximale Flexibilität und die Firmware für den Maple und ESP32 wo mehrere cc1101 Module möglich sind.

Nein, das ist kein einfaches umschalten, da müssen einige cc1101 Register geändert und der cc1101 kurz in den idle Modus geschaltet werden. Dies wird mit dem rfmode alles gemacht. Bei meiner firmware ist dies auch der ccmode.
Mir ist aufgefallen, daß es danach ca 1 Min dauert bis der Frequenzgenerator die eingestellte Frequenz ereicht hat.

Also wird man die PCA301 nicht gleichzeitig empfangen können, oder ?

Nein, der PCA301 hat eine andere Frequenz und Datarate. Die Datarate muß recht genau passen.

Gruß Ralf

[Noop]

Ich habe das Modul 14_SD_WS.pm angepasst, so das diese Sensoren dekodiert werden...

Klasse. Vielen Dank elektron-bbs für deine Arbeit!!!
Dann werde ich das jetzt mal ausprobieren

[Noop]

Dann muss bei dem SIGNALduino das Attribut "rfmode" auf "Bresser_5in1" gesetzt werden.

Bei mir funktioniert "set sduino rfmode Bresser_5in1" nicht: "Unknown argument rfmode, choose one of supported commands", ich sehe es auch nicht in den dropdowns.
Ich nehme mal stark an, dass mir etwas fehlt (z.b. ein update).

Ich habe gemacht (unter Windows, ich weiß das löst bei manchem Schmerzen aus ):
- SignalDuino flashen mit SIGNALDuino_nanocc1101_3.5.0-dev+20210808.hex
  (mittels XLoader, denn mit fhem* / bzw. der avrdude version ging es nicht, da bekam ich immer "ser_recv(): programmer is not responding")
- "update"
- "update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt" schmeißt folgenden Fehler*:
2021.11.27 00:54:41 1 : Downloading https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt
2021.11.27 00:54:41 1 : https://raw.githubusercontent.com:443: Attempt to reload IO/Socket/SSL.pm aborted. Compilation failed in require at (eval 162) line 1. BEGIN failed--compilation aborted at (eval 162) line 1.
- das 14_SD_WS.pm von elektron-bbs reinkopiert

Aktuell werden wohl zumindest mal 2 Sensoren von Nachbarn gelesen

Update: holen von Firmware via fhem geht jetzt wohl (vielleicht lags am portable perl zum path hinzufügen). Die Ausgabe schafft es zwar nicht bis ins UI, aber immerhin ins logfile. Da gibt es dann einen Fehler*
2021.11.27 00:50:40 1: sduino: found availableFirmware for ESP8266,ESP8266cc1101,ESP32,nano328,nanoCC1101,miniculCC1101,promini,radinoCC1101
2021.11.27 00:50:40 3: sduino: githubParseHttpResponse, error while requesting https://api.github.com/repos/RFD-FHEM/SIGNALDuino/releases - https://api.github.com:443: Attempt to reload IO/Socket/SSL.pm aborted.
Compilation failed in require at (eval 151) line 1.
BEGIN failed--compilation aborted at (eval 151) line 1.
(command: queryReleases

*Liegt vermutlich alles an demselben:
E:\FHEM\fhem-6.1>perl\bin\perl.exe -e "use IO::Socket::SSL"
Can't load 'E:/FHEM/fhem-6.1/perl/vendor/lib/auto/Net/SSLeay/SSLeay.xs.dll' for module Net::SSLeay: load_file:The specified module could not be found at E:/FHEM/fhem-6.1/perl/lib/DynaLoader.pm line 193.
  at E:/FHEM/fhem-6.1/perl/vendor/lib/IO/Socket/SSL.pm line 19.
Compilation failed in require at E:/FHEM/fhem-6.1/perl/vendor/lib/IO/Socket/SSL.pm line 19.
BEGIN failed--compilation aborted at E:/FHEM/fhem-6.1/perl/vendor/lib/IO/Socket/SSL.pm line 19.
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

Ich habe aber wie gesagt "E:\FHEM\fhem-6.1\perl\bin" auf dem pfad (davor hatte ich es schon mit "E:\FHEM\fhem-6.1\perl" und "E:\FHEM\fhem-6.1" probiert)
Mit den beiden folgenden hatte ich daher keinen Erfolg:
- https://forum.fhem.de/index.php?topic=85855.0 (zum path hinzufügen)
- https://forum.fhem.de/index.php?topic=74497.0 (ssl neu installieren? zumindest nicht mit apt-get...)

Vielleicht hat ja jemand einen Gedanken dazu (außer: nimm doch einfach deinen RaspberryPI - ja, den muss ich noch abstauben wollte idealerweise dass es mit beidem funktioniert)

[KölnSolar]

Dann fehlt Dir wohl IO/Socket/SSL.pm.
Für Ubuntu gibt's hier die Lösung.

[Ralf9]

Dann muss bei dem SIGNALduino das Attribut "rfmode" auf "Bresser_5in1" gesetzt werden.

Bei mir funktioniert "set sduino rfmode Bresser_5in1" nicht:

Ich finde das etwas verwirrend, zum Setzen von cc1101 Registern oder einer firmware config wird normalerweise ein set Befehl verwendet.
Beim offiziellen Signalduino Modul von Sidey wird dafür das Attribut rfmode verwendet obwohl dies das gleiche macht wie "set cc1101_reg".
Beim cul wird dies zwar auch über das Attribut rfmode gemacht, aber dies ist nicht vergleichbar, dort wird im cul Modul und in der firmware der Modus geändert.

Gruß Ralf

[Noop]

Dann fehlt Dir wohl IO/Socket/SSL.pm.
Für Ubuntu gibt's hier die Lösung.

Leider nein, die Datei ist da.

[Noop]

Bei mir funktioniert "set sduino rfmode Bresser_5in1" nicht: "Unknown argument rfmode, choose one of supported commands", ich sehe es auch nicht in den dropdowns.

Ist das überhaupt (wie ich vermutete) ein problem mit dem fehlenden update für die SIGNALduino fhem modul, oder etwas anderes?

"SIGNALduino Modul aktualisieren: update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt Durch das Update von FHEM wird sichergestellt, dass das Modul mit FHEM arbeitet."
https://wiki.fhem.de/wiki/SIGNALduino#FHEM-Modul_laden

Und wenn ja: gibt es alternative Wege den update zu machen?

Vielen Dank

[elektron-bbs]

Es müsste auch funktionieren, wenn du auf https://github.com/RFD-FHEM/RFFHEM auf den Button "Code" gehst und dort "Download ZIP" wählst. Die Dateien im Ordner "FHEM" und dessen Unterverzeichnis "lib" aus dem Archiv musst du dann in deine FHEM-Installation kopieren.

[Noop]

Vielen Dank. Das manuelle Downloaden und Replacen hatte leider nicht funktioniert:

"2021.11.28 11:31:16 1: reload: Error:Modul 00_SIGNALduino deactivated:
Can't locate Digest/CRC.pm in @INC (you may need to install the Digest::CRC module) (@INC contains: ./lib ./FHEM . E:/FHEM/fhem-6.1/perl/site/lib E:/FHEM/fhem-6.1/perl/vendor/lib E:/FHEM/fhem-6.1/perl/lib) at ./FHEM/00_SIGNALduino.pm line 27, <$fh> line 29.
BEGIN failed--compilation aborted at ./FHEM/00_SIGNALduino.pm line 27, <$fh> line 29."

Vermutlich hatte ich dabei irgend etwas falsch gemacht oder es hing auch wieder mit dem folgenden zusammen:

Ich habe nun die Lösung für das IO/Socket/SSL Problem gefunden:
Ich musste E:\FHEM\fhem-6.1\c\bin zum path hinzufügen (ich hatte davor nur E:\FHEM\fhem-6.1\perl\bin).

Jetzt konnte ich endlich via fhem das SIGNALduino Modul aktualisieren:
"New entries in the CHANGED file:
2021-11-28 - new protocol 109 for rojaflex remote controls (#1030)"

Allerdings liefert set sduino rfmode Bresser_5in1 immer noch "Unknown argument rfmode, choose one of supported commands"
Egal ob mit dem aktualisierten 14_SD_WS.pm von github, oder mit dem von elektron-bbs

Ich habe mal angehängt, was ich über den sduino in fhem sehe.

[Ralf9]

Allerdings liefert set sduino rfmode Bresser_5in1 immer noch "Unknown argument rfmode, choose one of supported commands"

Bei dem Signalduino Modul das Du verwendest, funktioniert das nicht mit "set".
Der rfmode wird durch das Attribut rfmode geändert.

Code Auswählen Erweitern

attr sduino rfmode Bresser_5in1
Durch das Setzen des Attributs rfmode werden die für "Bresser_5in1" notwendigen cc1101 Register geändert.

Daß die cc1101 Register geändert wurden, kannst Du mit "get sduino ccconf" erkennen.
Die Frequenz ist dann 868.35, die Datarate ca 8.207 und die Modulation 2-FSK

[Noop]

Hallo, vielen Dank euch allen. Es funktionert 

[Ralf9]

Ich hab den FODY E42 in meine Variante des 14_SD_WS Moduls ergänzt
https://github.com/Ralf9/14_SD_WS/blob/main/FHEM/14_SD_WS.pm

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/Ralf9/14_SD_WS/main/controls_ralf9_sd_ws.txt
version 14_SD_WS.pm
"2021-11-30 21:00:00Z Ralf9"

Ich hab gegenüber der Version von elektron-bbs ein paar Sachen abgeändert:

Bei der DEF habe ich TH ergänzt: SD_WS_108_TH

batteryChanged hab ich invertiert. Beim Batteriewechsel oder Reset wird dann das "batteryChanged" 1 und nach 60 Minuten gehts wieder zurück nach 0.

Bei Bedarf müsste eigentlich auch, wie bei Lacrosse, das "set replaceBatteryForSec" eingebaut werden können:

Code Auswählen Erweitern

replaceBatteryForSec <sec> [ignore_battery]
sets the device for <sec> seconds into replace battery mode. the first unknown address that is received will replace the current device address.
this can be partly automated with a readings group configured to show the battery state of all LaCrosse devices and a link/command to set replaceBatteryForSec on klick.

Gruß Ralf

[rob]

Gemäß der Infos wäre ein Signalduino ja exklusiv wg. FSK usw. einzusetzen. Läuft für mich also auf einen Mapleduino hinaus (reizt mich eh schon lange wg. LAN, aber Zeit fehlt). Bisher hatte ich nur einen "one headed" (1x cc1101) in fliegender Verdrahtung erfolgreich aufgebaut.

Zwei Fragen hätte ich:
Wenn ich den Maple nun "multiheaded" aufbaue, würde ich 2x FSK benötigen (LaCrosse + Fody) oder würde ein FSK head reichen, um LaCrosse UND Fody zu empfangen/ dekodieren?
Wäre eine neue Firmware-Version auch für den Mapleduino nötig?

Vielen Dank und beste Grüße
rob

[Ralf9]

Hallo rob,

da LaCrosse und Fody (Bresser 5in1 oder 6in1) eine andere Datarate haben, reicht ein cc1101 nicht.
Bei meiner Firmware gibts die Möglichkeit die cc1101 Registerkonfig von LaCrosse und Fody auf verschiedene EEPROM Speicherbänke zulegen und dann mit einem DOIF oder notify z.B. alle 5 Min die cc1101 konfig zu wechseln. Da das hier etwas offtopic ist, rest per pm.

Gruß Ralf

[rob]

Ja, müssen wir nicht vertiefen, die Info reicht mir schon   Vielen Dank.

VG
rob

[KölnSolar]

Meine sind nun auch eingetroffen, aber sie wollen irgendwie nicht.

Ich hab 2 ausprobiert. Dabei festgestellt, dass es eine weiße LED gibt. Wann blinkt die denn ? 5-mal bei Reset und Batteriewechsel hab ich gesehen. Auch im Betrieb bei Funkübertragung ?

Hier mal das list mit Ralfs firmware

Code Auswählen Erweitern

Internals:
   CFGFN     
   Clients    :CUL_EM:CUL_FHTTK:CUL_TCM97001:CUL_TX:CUL_WS:Dooya:FHT:FLAMINGO:FS10:FS20: :Fernotron:Hideki:IT:KOPP_FC:LaCrosse:OREGON:PCA301:RFXX10REC:Revolt:SD_AS: :SD_BELL:SD_GT:SD_Keeloq:SD_RSL:SD_UT:SD_WS07:SD_WS09:SD_WS:SD_WS_Maverick:SOMFY: :Siro:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_001PQQCF-if00-port0
   DMSG       nothing
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_001PQQCF-if00-port0@57600
   FD         27
   FUUID      61ab8925-f33f-5874-f9d1-1959cfbaca323db6
   LASTDMSG   nothing
   LASTDMSGID nothing
   NAME       Sduino868
   NR         564
   PARTIAL   
   STATE      opened
   TIME       1638631717
   TYPE       SIGNALduino
   cc1101_available 1
   sendworking 0
   version    V 3.4.0 SIGNALduino cc1101 (chip CC1101) - compiled at Jul 16 2020 20:52:15
   versionProtocols 1.38
   versionmodul 3.5.2+20211120
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|20|24|26|29|30|34|46|56|68|69|76|78|81|83|86|90|91|91.1|92|93|95|97|99|104|105|114)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79|96|98|112)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     29:SD_GT   ^P49#[A-Fa-f0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     30:LaCrosse ^(\S+\s+9 |OK\sWS\s)
     31:KOPP_FC ^kr\w{18,}
     32:PCA301  ^\S+\s+24
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2021-12-04 16:55:49   cc1101_config   Freq: 868.350 MHz, Bandwidth: 464 kHz, rAmpl: 33 dB, sens: 8 dB, DataRate: 8.23 kBaud
     2021-12-04 16:55:49   cc1101_config_ext Modulation: 2-FSK, Syncmod: 16/16 sync word bits detected, Deviation: 57.13 kHz
     2021-12-04 16:28:41   cc1101_patable  C3E = 00 84 00 00 00 00 00 00 => 5_dBm
     2021-12-04 17:23:40   ping            OK
     2021-12-04 16:28:39   state           opened
   additionalSets:
   keepalive:
     ok         1
     retry      0
   mcIdList:
   mnIdList:
     108
   msIdList:
   muIdList:
Attributes:
   hardware   nanoCC1101
   room       System
   whitelist_IDs 108
Sieht doch eigentlich alles gut aus oder fällt jemand was auf(ausser dass nichts empfangen wurde) ? Die Hardware ist auch OK. Empfang von ASK/OOK problemlos.

Grüße Markus

[Ralf9]

Ich hab 2 ausprobiert. Dabei festgestellt, dass es eine weiße LED gibt. Wann blinkt die denn ? 5-mal bei Reset und Batteriewechsel hab ich gesehen. Auch im Betrieb bei Funkübertragung ?

Im Betrieb bei Funkübertragung hab ich sie noch nicht blinken sehen

Das List zeigt die firmware und das 00_Signalduino Modul von Sidey.

Meine firmware lässt sich nicht ohne weiteres bei FSK mit dem 00_Signalduino Modul von Sidey verwenden.

Gruß Ralf

[KölnSolar]

Hi Ralf,
Danke.

Das List zeigt die firmware und das 00_Signalduino Modul von Sidey.

Aber dann hätte es doch auch rennen müssen ? 

Ich sagte ja

ich blick ja nie so ganz zwischen Euren Versionen der firmware durch.

Aber nun bin ich wieder auf Deinen Versionen und sie rennen. 

Aufgefallen ist mir, dass sie permanent um +/- 0.1 T schwanken weshalb sich ein

Code Auswählen Erweitern

attr SD_WS_108_TH_4A event-on-change-reading .*:0.1empfiehlt. Die Temperaturen liegen 1,5-2 % höher als bei meinen Oregons. Bei einem die RLF um 25% niedriger  Muss ich mal weiter analysieren.

Grüße Markus

Edit: Ralf, wenn Du bei Gelegenheit beschreiben könntest, wie man das mit den Banken definieren müsste, um z.B. zwischen Bresser-5-in-1 u. PCA301 switchen zu können. Denn dann haben wir beim Wechsel keine verschleißenden Schreibzyklen, oder ?

[elektron-bbs]

Mhmm, das list zeigt eine Firmware von Sidey:

Code Auswählen Erweitern

version    V 3.4.0 SIGNALduino cc1101 (chip CC1101) - compiled at Jul 16 2020 20:52:15

Aber mit dieser Version ist noch kein FSK-Empfang möglich. Das funktioniert erst mit der aktuellen Entwicklerversion:

Code Auswählen Erweitern

version    V 3.5.0-dev+20210808 SIGNALduino cc1101 (chip CC1101) - compiled at Aug  7 2021 22:44:01

Im Übrigen scheint der Sensor eine "Macke" zu haben. Es gibt Sprünge bei der Temperatur in Stufen von 0,5 °C. Ist das bei ech auch so?

[KölnSolar]

wir schrieben wohl gleichzeitig

Aufgefallen ist mir, dass sie permanent um +/- 0.1 T schwanken weshalb sich ein...

[elektron-bbs]

Mag sein, das wir parallel schrieben, aber wir meinten verschiedenes. Du schreibst von +/- 0.1 ich aber von Stufen in +-0,5 °C Schritten

[KölnSolar]

Ist das bei ech auch so?

Nein, ich beobachte

dass sie permanent um +/- 0.1 T schwanken

Besser ? 

Aber es scheint bei mir auch die großen Sprünge zu geben, denn nun ist nicht mehr

Temperaturen liegen 1,5-2 % höher als bei meinen Oregons

, sondern 1-2% niedriger, was dann auf 0,5-Sprung deutet.

[Ralf9]

Ich hab mal von 21:24 bis 23:32 Uhr die vom FODY E42 alle 12 Sek empfangenen Werte in ein filelog geschrieben.
Die Schwankungen sind +/- 0.1 T und dreimal +/- 0.2 T

Wegen dem Umschalten der aktiven Bank schreibe ich noch was. Beim Wechsel der aktiven Bank wird nichts in das EEPROM geschrieben, ich bin gerade dabei es noch etwas zu optimieren.

[KölnSolar]

Einen halben Tag später mit 2 "harten" Wechseln der Umgebungsbedingungen(Sensor auf die Terrasse) lassen sich die Charakteristiken so zusammenfassen

- nettes Design, relativ schwer, kein Display
- Funkübertragung alle 12s --> event-on-change-reading empfohlen
- gute Reichweite, stabile Funktelegramme
- durch 1byte random-id(Reset/Batteriewechsel) problemlos viele devices einsetzbar --> attr  longids am Transceiver setzen
- weiße LED blinkt 5-mal bei Reset und Batteriewechsel, nicht im Normalbetrieb(evtl. bei LowBat ?)
- "Zittern" von Messwerten: Schwankungen von +/- 0.1/0.2 T --> threshold für event-on-change-reading empfohlen
- Sprünge von +/- 0,5 T --> für Steuerungsaufgaben z.B. Lüftungserkennung unbrauchbar
- RLF sehr ungenau(mind. 10% zu niedrig) --> für Steuerungsaufgaben z.B. Lüftungssteuerung unbrauchbar
- sehr träge bei starken Schwankungen durch große Masse u. Bauweise(90' Verzug bei deltaT 15°  )

Könnten die Sprünge an falsch interpretiertem Datenprotokoll liegen ? 

Beim Wechsel der aktiven Bank wird nichts in das EEPROM geschrieben

Prima, dann ließen sich ja doch devices unterschiedlichster Funkprotokolle problemlos mit einem 868-nanoCUL-Sduino betreiben. 

Grüße Markus

[elektron-bbs]

Könnten die Sprünge an falsch interpretiertem Datenprotokoll liegen ? 

Kann ich mir nicht vorstellen. Ich habe mal die Daten über 24 h in eine Excel-Tabelle gepackt. Da gibt es kein Bit, was sich zusätzlich oder anders auswerten ließe.
In dem Zeitraum gab es folgende Wertänderungen der Temperatur:

Code Auswählen Erweitern


Diff.   Anzahl
--------------
0,0       553
0,1       280
0,2        75
0,5        37
-------------
Summe:    945


[KölnSolar]

sehr schöne Excel-Arbeit.

Auf den ersten Blick fällt mir auch nichts anderes ein.

Die Bedeutung von Byte 13 versteh ich nicht. Was soll mir bit count sagen ?
Irgendwie ändern die nibbles sich ja mit den T-Nibbles. Gefühlt stecken da die Sprünge drin. Mal anders dargestellt ohne redundante Werte

Code Auswählen Erweitern

u u T T T H H t
Temperatur Feuchte
1 3 8 6 1 3 9 0 0,0 39
1 4 8 7 1 3 9 0 18,7 39
1 2 8 8 1 3 9 0 18,8 39
1 3 9 2 1 3 9 0 19,2 39
1 3 9 4 1 3 9 0 19,4 39
1 4 9 9 1 3 9 0 19,9 39
1 0 0 0 2 3 9 0 20,0 39
1 2 0 5 2 3 9 0 20,5 39
1 1 0 6 2 3 8 0 20,6 38
1 2 0 6 2 3 9 0 20,6 39
1 0 0 7 2 4 0 0 20,7 40
1 2 0 7 2 3 8 0 20,7 38
1 3 0 7 2 3 9 0 20,7 39
0 F 1 2 2 4 0 0 21,2 40
1 0 1 2 2 4 1 0 21,2 41
1 1 1 2 2 3 8 0 21,2 38
1 2 1 2 2 3 9 0 21,2 39
1 0 1 3 2 4 0 0 21,3 40
1 1 1 3 2 4 1 0 21,3 41
1 2 1 3 2 3 8 0 21,3 38
1 3 1 3 2 3 9 0 21,3 39
1 1 1 8 2 3 8 0 21,8 38
1 2 1 8 2 3 6 0 21,8 36
1 3 1 8 2 3 7 0 21,8 37
1 2 1 9 2 3 8 0 21,9 38
1 3 1 9 2 3 6 0 21,9 36
1 4 1 9 2 3 7 0 21,9 37
1 0 2 0 2 3 8 0 22,0 38
1 1 2 0 2 3 6 0 22,0 36
1 2 2 0 2 3 7 0 22,0 37
1 2 2 5 2 3 8 0 22,5 38
1 3 2 5 2 3 9 0 22,5 39
1 4 2 5 2 3 7 0 22,5 37
1 2 2 6 2 3 8 0 22,6 38
1 3 2 6 2 3 9 0 22,6 39
Aber eine Formel erkenne ich auch nicht. 

Grüße Markus

Edit: u. wir liegen ja mal über u. mal unter der T. von meinem Oregon.

[elektron-bbs]

Das ist eine Quersumme aller Bits:

Code Auswählen Erweitern

checksum (number/count of set bits within bytes 14-25)

[Noop]

- "Zittern" von Messwerten: Schwankungen von +/- 0.1/0.2 T
- sehr träge bei starken Schwankungen

Diese Punkte sind mir auch schon aufgefallen. Die Werte hüpfen oft in dem Bereich.
Zur Genauigkeit kann ich wenig sagen, weil mir ein zuverlässiger Vergleich fehlt
Bedeutet wohl, dass die Teile eigentlich keinen guten Dienst für ihre Aufgabe tun, oder? Also letztlich schlechte Qualität.
Woran erkennt man denn das Gegenteil, z. B. @KölnSolar von "deinem Oregon"? Bzw was wäre denn eine übliche Trägheit?
By the way: was ist RFL?

[KölnSolar]

OK. passt.
Dann doch nur die 3 nibbles. 
Das sind die "Lücken" durch die Sprünge

Code Auswählen Erweitern

20,1-20,4
20,8-21,1
21,4-21,7
22,1-22,4Auch nicht so richtig systematisch.

Ich mag nicht glauben, dass das ein Hardwarefehler ist. 

Edit:

Also letztlich schlechte Qualität

Das würd ich so nicht sagen. Im Augenblick sieht das nach einem systematischen Problem aus.

By the way: was ist RFL?

RLF=Relative LuftFeuchte

Bzw was wäre denn eine übliche Trägheit?

Z.B. könnte ein Sensor benutzt werden, um plötzlichen Temperaturabfall durch Fensteröffnung zu erkennen. Dafür ist der FODY zu träge. Die meisten Sensoren sind da flinker(weniger Masse, Luftschlitze f. Sensor).

[Ralf9]

Das sind die "Lücken" durch die Sprünge

Da sind vermutlich noch mehr Lücken.
Die Lücke zwischen 20.1 und 20.4 hab ich mal getestet.
Bei einer Raumtemperatur von ca 20 Grad wurden bei meinem FODY E42 keine Temperaturen zwischen 20.1 und 20.4 Grad angezeigt.

Sind diese Lücken evtl der Grund warum es diese Sensoren z.Zt. so günstig gibt?

[KölnSolar]

Sind diese Lücken evtl der Grund warum es diese Sensoren z.Zt. so günstig gibt?

Klar, den Gedanken hatte ich auch schon. Aber für uns 3 Entwickler ist doch nicht nachzuvollziehen, dass die Daten eines per I2C angebundenen Sensors nicht mit einem Bröckchen Software richtig in ein Datenprotokoll umzusetzen wären. Da ist das Funkprotokoll doch 1.000-mal komplizierter.
Ich guck mir mal den Sensor näher an...

Edit:
Noop: die Bilder im 1. Post hast Du gemacht ? Der HT-01D ist hier näher beschrieben und hier das technische Datenblatt. Temp/Hum werden mit jeweils 14bit übertragen. Die Formel für die Temp ist etwas komplex

Code Auswählen Erweitern

Temp output [C] = (Temp_High[7:0] × 64 + Temp_Low[7:2]/4])/214 × 165 - 40. Ob da ein Fehler gemacht wurde ? Hilft alles aber auch nicht weiter. 

[Noop]

Noop: die Bilder im 1. Post hast Du gemacht ?

Ja, die habe ich gemacht. Habe auch vorhin mal versucht den auseinander genommenen Fody in Betrieb zu nehmen um zu sehen, ob er sich anders verhält, aber da habe ich wohl etwas kaputt gemacht.
Ich habe aktuell 9 dieser Sensoren in Betrieb (aktuell ohne event-on-change-reading + der Signalduino / fhem läuft bisher nicht durchgehend).
Bei allen sieht man das 0,1°C "flackern", teilweise aber nicht durchgängig, sondern zwischendurch auch mal stabil.
0,5°C Sprünge habe ich jetzt beim Anschauen dieses kurzen Zeitabschnitts nicht gesehen.
Ich kann mal logs hochladen. Wie soll ich das am Besten machen (also irgend ein format / command)?

[KölnSolar]

Ja, die habe ich gemacht

Danke, dann können wir also sicher sein, dass der HT-01D drin steckt.

Von mir mal der Vergleich der Sensoren als Grafik. Leider nur eine schmale Bandbreite wg. FBH. Aber man sieht schön, wie die Werte mal drüber mal drunter liegen, mal 0,1°, mal 0,2° "Zittern" und den 0,5° "Sprung". Wenn man das weiter analysiert, könnte man vielleicht wenigstens eine Korrektur einbauen.

[KölnSolar]

Und damit das hier nicht einschläft: Mittlerweile kristallisiert sich heraus, dass die 0,5-Sprünge tatsächlich immer bei derselben Temperatur stattfinden(was für einen Fehler in unserer Dateninterpretation oder einem firmwarefehler im Fody spricht). Außerdem, dass die T wenig(max. 0,2°) unter dem Vergleichssensor liegt, aber deutlich über(max. 0,5°) nach(vor) einem Sprung nach oben(unten). Das sieht man auch schon an meiner gestrigen Grafik. Ich hab nun einen 2. Vergleich in einem anderen Raum gestartet. Und dann werde ich die beiden Sensoren tauschen, da unterschiedlichste Temperaturverhältnisse vorhanden sind.

Eine Wertekorrektur könnte ich mir per userReadings vorstellen. 3 St. müssten genügen(TempSprung,TempDiffSprung,TempKorrigiert). Oder die Sprungtemperaturen definieren und immer auf dieser Basis korrigieren ? Was meint Ihr ?

Grüße Markus

[elektron-bbs]

Und damit das hier nicht einschläft: Mittlerweile kristallisiert sich heraus, dass die 0,5-Sprünge tatsächlich immer bei derselben Temperatur stattfinden(was für einen Fehler in unserer Dateninterpretation oder einem firmwarefehler im Fody spricht). Außerdem, dass die T wenig(max. 0,2°)

Was meinst du mit "die 0,5-Sprünge tatsächlich immer bei derselben Temperatur stattfinden"?
In meiner Excel-Tabelle sehe ich die Sprünge bei verschiedenen Temperaturen:

Code Auswählen Erweitern


19,3   19,9   20,5   21,2   21,8   22,5   |   18,8   21,3   22,0
18,8   19,4   20,0   20,7   21,3   22,0   |   19,3   21,8   22,5


Was auffällt, ist die stark schwankende Anzahl der jeweiligen Nachkommastellen:

Code Auswählen Erweitern


Anz.   Nachkomma
----------------
122      0,0
   0      0,1
101      0,2
178      0,3
  21      0,4
  44      0,5
  42      0,6
  33      0,7
116      0,8
290      0,9


Diese müssten ja eigentlich relativ gleich verteilt sein.

Ich habe keine Vorstellung, wie man das nachträglich korrigieren will. Ich habe es schon versucht mit einer Mittelwertbildung über die letzten 10, 20 o.ä. Messwerte. Aber da werden halt auch nur aus den "Stufen" dann "Schrägen" über einen bestimmten Zeitraum.

Im Anhang mal noch ein Diagramm von zwei Sensoren im Vergleich.

[KölnSolar]

Was meinst du mit "die 0,5-Sprünge tatsächlich immer bei derselben Temperatur stattfinden"?

In meinem obigen Bsp. findet ein Sprung immer von 18,8 auf 19,3 statt. Werte 18,9-19,2 gibt es nie.

Nun bin ich wieder ein Stückchen weiter. Denn was ich zuvor geschrieben habe stimmt nicht ganz. Nach dem 0,5-Sprung "zittert" das Teil zwischen 19,2 u. 19,4 bis zum nächsten 0,5-Sprung.

D.h. aber, dass eine Korrektur nicht möglich ist bzw. wir tatsächlich nur mit einer Genauigkeit von 0,5° messen.    Lediglich die Scheingenauigkeit des Zitterns(bisher ohne dass ich dort ein System erkenne)müsste man ausfiltern, damit man nicht dem Trugschluss unterliegt, es würden tatsächlich T-Veränderungen stattfinden.

Bis Morgen habe ich wieder mehr Daten und dann von 2 Sensoren. Dann stell ich wieder Grafiken ein, so dass mein Gesülze besser nachvollziehbar ist.
Und vielleicht erkennen wir ja doch noch etwas, um den Sensor wenigstens auf 1/4° Genauigkeit zu kriegen. 

Diese müssten ja eigentlich relativ gleich verteilt sein.

Eben nicht, weil es sich nicht um einen Messfehler, sondern um einen Systemfehler handelt. Die Häufigkeit ist dann abhängig vom Temperaturbereich und dem Verhältnis der Dauer der unterschiedlichen 0,5°-Bereiche.

Edit: Deine Vergleichsgrafik ist auch interessant. Man erkennt durch den Versatz der Kurven recht gut die von mir beschriebene Trägheit. Und dadurch wird ein "Berg" zu einem "Plateau".

[KölnSolar]

Hölle, ist das Ding träge. Ich habs nur in den ca. 3° wärmeren Referenzraum gebracht(grüne Linie). Eine Stunde bis die neue Umgebungstemp. richtig angezeigt wird. 

Ansonsten sieht man ganz gut, was ich vorhin versuchte in Worte zu fassen. 

[KölnSolar]

Und nun ein Chart mit 2 Fody's über ca. 12h im Vergleich. Man sieht, dass sie sich fast identisch verhalten. Ein Muster beim "Zittern", welches man für eine Korrektur nutzen könnte, sehe ich nicht.
Folglich nur die Bestätigung für meinen obigen Ansatz, den Sensor mit 0,5° Genauigkeit zu betreiben und das "Zittern" auszufiltern. So z.B.

Code Auswählen Erweitern

attr SD_WS_108_TH_4A userReadings corrtemperature:temperature.* {if(ReadingsVal($name,"temperature",0) > ReadingsVal($name,"corrtemperature",0) + 0.3 ||  ReadingsVal($name,"temperature",0) < ReadingsVal($name,"corrtemperature",0) - 0.3)  { ReadingsVal($name,"temperature",0) } else {ReadingsVal($name,"corrtemperature",0)}}

sah im Log dann simpel und unspektakulär so aus

Code Auswählen Erweitern

2021-12-08_08:28:23 SD_WS_108_TH_4A corrtemperature: 18.6
2021-12-08_09:53:59 SD_WS_108_TH_4A corrtemperature: 19.3
2021-12-08_09:54:23 SD_WS_108_TH_4A corrtemperature: 18.8
2021-12-08_09:54:35 SD_WS_108_TH_4A corrtemperature: 19.3
Man könnte vielleicht noch überlegen, ob man nicht gezielt auf jeweils xy.0 u. xy.5 korrigiert.

[rob]

Das Zittern/Springen allein ist schon doof. Die Trägheit macht das Teil schwer benutzbar. Ließe sich zumindest dafür mit kleinen Bohrungen an geeigneter Stelle Abhilfe schaffen?

[KölnSolar]

Ganz vergessen, dass noch ein 5. Mitstreiter unterwegs ist. 

Die Trägheit macht das Teil schwer benutzbar.

Will man "nur aufzeichnen", ist es sicherlich OK. Wenn es ums Steuern geht, dann muss man das individuell sehen. Bei mir mit geringen u. laaaaangsamen Veränderungen unproblematisch. Wie man bei electron-bbs sehen konnte, in anderen Umgebungen schon sehr problematisch.

Ließe sich zumindest dafür mit kleinen Bohrungen an geeigneter Stelle Abhilfe schaffen?

Da gehe ich von aus. Ich hab aber noch kein Teil auseinandergenommen und aus den Bildern im 1.Post lässt sich auf die Lage des Sensors auch nicht schließen.

@Noop: Kannst Du grob beschreiben, wo sich der Sensor befindet ? Dürfte ja aufgrund des Batteriefachs irgendwo in der Spitze sein. In der Nähe der LED ?

Grüße Markus

[Ralf9]

Stellt Ihr den FODY hin oder hängt er an der Wand? An der Wand müsste eigentlich die Trägheit etwas geringer sein.

Das Zittern ist schon recht heftig.

Gruß Ralf

[Noop]

Ich hab die Fodys normalerweise aufgestellt. Jezt mal probeweise einen hingelegt.
Der Sensor befindet sich ziemlich weit unten. Im Anhang ein Foto.
Der Pfeil zeigt auf den Sensor.
Das "abgeknabberte" Plastik im Vordergrund ist normalerweise zu, wenn man ihn nicht (wie ich) sinnloserweise gewaltsam öffnet. Zum gewaltärmeren öffnen genügt es eigentlich die zwei Plastikstifte (rechts und links unter der Batterieabdeckung - quasi unter den beiden Standfüßen) heraus zu ziehen und dann mit einem seeehr langen dünnen Schraubenzieher aufzuschrauben (so einen hatte ich aber leider nicht, bzw. wusste es auch am Anfang nicht).

Bei Bedarf gerne weitere Bilder oder Abmessungen oder ...

[Noop]

Hier nochmal die Ansicht der Rückseite mit abgebrochener Rückplatte.
Markiert sind rechts die Stellen, wo man mit sanfter Gewalt die Plastikstifte herausziehen muss.
Auch ohne das Rausziehen sind da schon 2 Löcher. Möglicherweise kommt man mit einem noch dünneren Schraubenzieher bereits so an die Schrauben.
Links dann die Schrauben, die man mit einem entsprechend langem und dünnen Schraubenzieher lösen müsste.

Als Ergebnis hat man dann einen Sensor ohne die schicke Außenhülle, der dafür aber dann direkt Kontakt mit der Luft hat.

[Ralf9]

Edit: Ralf, wenn Du bei Gelegenheit beschreiben könntest, wie man das mit den Banken definieren müsste, um z.B. zwischen Bresser-5-in-1 u. PCA301 switchen zu können. Denn dann haben wir beim Wechsel keine verschleißenden Schreibzyklen, oder ?

Ich habe es hier
https://forum.fhem.de/index.php/topic,82379.msg1192584.html#msg1192584
ein wenig beschrieben

[rob]

Das Teil hab ich jetzt auch zerlegt gehabt. Dank der guten Hinweise ging das recht leicht. So einen langen Schraubendreher hatte ich auch nicht, aber eine lange schmale Vierkantfeile tat es auch 

Tatsächlich hat der Sensor bereits seine Öffnungen, nur eben im Boden. Scheint nicht zu reichen. Die Hauptplatine gibt wenig preis, weil zwei schwarze Kleckse wie so oft alles verdecken.
Die Rückseite hat einige Kontaktpads - nur leider ohne Beschriftung. Flashen wird man wohl trotzdem vergessen können, weil die Chips unklar sind. Wenig erhellend das Teil 

[KölnSolar]

Ich habe es hier
https://forum.fhem.de/index.php/topic,82379.msg1192584.html#msg1192584
ein wenig beschrieben

Aber nur ein wenig.  Ich hatte gar nicht mitbekommen, dass das Verfahren zum Beschreiben der EEPROM-Banken so einfach geworden ist. 

Der permanente Wechsel zwischen PCA301 u. Bresser-5-in-1 über ein periodisches at funktioniert hervorragend. 

Grüße Markus

[Noop]

Das Teil hab ich jetzt auch zerlegt gehabt. Dank der guten Hinweise ging das recht leicht

Freut mich. Hast du mal geschaut, ob sich mit offenem Gehäuse die Wert jetzt anders verhalten (also z.b weniger Zittern, weniger träge, weniger Abweichung bei Feuchte)?

[KölnSolar]

Ich beantworte mal für Rob die Frage mit einem Bild von 4 Sensoren im Wochenchart.

Wie man erkennen kann, befinden sich die 4 Sensoren in unterschiedlichen Räumen. In allen 4 Räumen ist die Temperatur im Tagesverlauf relativ stabil.

Man erkennt nach wie vor deutlich bei allen Sensoren das Zittern und die Sprünge. Wenn man genau hinsieht erkennt man jeweils je Sensor eine dünne Linie in gleicher Farbe. Das ist das Ergebnis meiner oben beschriebenen "Korrektur" über userReadings. Das kommt dann der Wahrheit mit den gegebenen Möglichkeiten der Sensoren recht nah. Halt eine Anzeige mit 0,4-0,5°C Anzeigegenauigkeit.

Daran ändert dann auch ein offenes Gehäuse nichts. Lediglich bei der Trägheit könnte es Auswirkungen haben.

Grüße Markus

[Ralf9]

Aber nur ein wenig.  Ich hatte gar nicht mitbekommen, dass das Verfahren zum Beschreiben der EEPROM-Banken so einfach geworden ist. 

Ich habe hier die Beschreibung zu FSK noch ein wenig ergänzt. Ist es so besser? Fehlt noch was?
https://forum.fhem.de/index.php/topic,111653.msg1058902.html#msg1058902

Der permanente Wechsel zwischen PCA301 u. Bresser-5-in-1 über ein periodisches at funktioniert hervorragend.

Das schalten des PCA301 dürfte dann aber nicht mehr so richtig funktionieren. Du müsstest vor jedem schalten erstmal auf die entsprechende Bank wechseln.

[KölnSolar]

Das schalten des PCA301 dürfte dann aber nicht mehr so richtig funktionieren. Du müsstest vor jedem schalten erstmal auf die entsprechende Bank wechseln.

Klar. Mir geht es mehr ums Messen.

Ist es so besser? Fehlt noch was?

Passt schon. Mir fehlt immer wieder der eine Post, wo alles beschrieben ist und man dann im gegebenen Fall erkennt, dass man die Bank nicht mehr wie im Ursprung mit set raw..., sondern einfacher per set rfmode ... beschreiben kann.
Frohes Fest
Markus

[Noop]

Danke Markus, von mir auch frohe Weihnachten an alle 

https://www.youtube.com/watch?v=wFBGKW5ORaQ&t=45

[Ralf9]

Mir fehlt immer wieder der eine Post, wo alles beschrieben ist

Da müsste alles zu finden sein. Da gibts in der 2.Nachricht eine Linkliste und in der dritten ist das mit dem rfmode beschrieben
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900


Wünsche Euch allen frohe Weihnachten

[epaul]

Hello & Happy New Year!

I also bought some E42 sensors and took off the sensor on a breadboard with a SI7021 close and run readings for 24H.
I only got one 0.5 jump, but in comparison to the SI7021 temperature readings I got 6 with plus 1.3-1.4 difference.

I used code for HYT 221/271 which seem to have same protocol as HT-01D https://www.conrad.com/p/ist-ag-hyt-271-digital-humidity-and-temperature-sensor-digital-humiditytemperature-sensor-505675.

Does anybody own a HYT 221/271 and Fody E42 to test?

Best Regards,
Paul

[epaul]

Update: