Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Tom Major]

Bis auf die Tatsache das es bei kpwg vor ca. 2 Jahren funktionierte, wie im Zitat angegeben, kann ich leider nichts beitragen, betreibe kein FHEM mehr.
Das Register wo die altitude drinsteht (34/35) hat sich auch die ganze Zeit nicht geändert soweit ich das überblicke.

[frank]

scheinbar überschreibt FHEM/HMConfig_SenTHPL.pm die definition des register altitude.
dort ist adresse 36,37.

lösche mal FHEM/HMConfig_SenTHPL.pm und starte neu.

Update: sehe gerade, dass Du die Vermutung zurückgezogen hast

das war unüberlegt.   

[FFHEM]

Frank, das war ein Volltreffer:
Kann jetzt altitude setzen, steht auf 83 m!!!!

Aber was mache ich jetzt mit dem anderen Sensor?

Code Auswählen Erweitern

2021-03-07 19:39:32   CommandAccepted yes
     2021-03-07 10:13:06   D               7.3
     2021-03-07 19:39:31   D-firmware      1.3
     2021-03-07 19:39:31   D-serialNr      UNISENS001
     2021-03-07 19:39:34   PairedTo        0xFF3004
     2021-03-07 19:39:32   R-altitude      83 m
     2021-03-04 16:38:06   R-ledMode       undef lit:1
     2021-03-04 16:38:06   R-lowBatLimit   2.1 V
     2021-03-04 16:38:06   R-pairCentral   0xFF3004
     2021-03-05 16:47:45   R-sign          off
     2021-03-04 16:38:06   R-transmDevTryMax 6
     2021-03-07 09:30:06   R-updateIntervall 180 s

[frank]

am einfachsten ist wohl unterschiedliche registernamen zu nutzen. aber überall in der .pm datei ändern.
also zb altitude => altitudeUS1

eigentlich müssten neue registernamen bei asksin zentral verwaltet werden, wie auch die modelIDs. sonst ist chaos angesagt.

edit:
1. die anzeige des registers ledMode passt ja auch noch nicht.
hier sollte eigentlich die überflüssige definition entfallen, da das register bereits genau so definiert ist.
also zeile löschen.

2. das register lowBatLimit muss eigentlich auch umbenannt werden, da es bereits für sirenen existiert und dann dort nicht mehr passt.
also zb lowBatLimit => lowBatLimitUS1

3. in der model definition ist am ende der zeile das komma zu viel und erzeugt bei mir eine warnung.

$HMConfig::culHmModel{'F103'} = {name => 'HB-UNI-Sensor1', st => 'UniSensor1', cyc => '00:10', rxt => 'l:w:c:f', lst  => 'p',   chn  => '',};

[FFHEM]

Hallo Frank,
habe jetzt in der HM_ConfigSenTHPL.pm den Registernamen altitude überall geändert -> mein alter Sensor THPL funktioniert wieder!
In HM_Config_UniSensor1.pm die Definition der ledMode auskommentiert, jetzt kommt auch der richtige ledMode (on) an.
Das überflüssige Komma in der Modelldefinition ist auch entfernt.

Jetzt werde ich noch für die Temperatur und die Luftfeuchtigkeit feste Defines für Temperatur- und Luftfeuchtigkeitoffsets in die Arduino-Software reinschreiben.

Scheint jetzt alles prima zu laufen, ich bedanke mich recht herzlich!
Grüße,
Friedhelm

[frank]

noch zur info:

wenn man eigene register in der homebrew.pm definiert und in der definition "literals" bestimmt, erwartet cul_hm "neuerdings?" auch den hash {litInv}, in dem die keys/values zu {lit} getauscht sind.

beim einlesen der HMConfig.pm wird das am ende automatisch gemacht:

Code Auswählen Erweitern

foreach my $rN   (keys %culHmRegDefine) {#create literal inverse for fast search
if ($culHmRegDefine{$rN}{lit}){# literal assigned => create inverse
foreach my $lit (keys %{$culHmRegDefine{$rN}{lit}}){
$culHmRegDefine{$rN}{litInv}{$culHmRegDefine{$rN}{lit}{$lit}}=$lit;
}
}
}


für einzelne neue register kann man das ja direkt definieren.
für das (schlechte, weil überflüssige) beispiel mit ledMode dann so:

Code Auswählen Erweitern

$HMConfig::culHmRegDefine{'ledMode'}         = {a=> 5.6,s=>0.2,l=>0,min=>0   ,max=>1     ,p=>'n',c=>'lit',f=>'',u=>''  ,d=>0,t=>'LED mode',lit=>{off=>0,on=>1}, litInv=>{0=>'off', 1=>'on'}};

[FFHEM]

Danke!

[vbs]

Mal eine Frage bzgl. Temperatursensoren:
Ich hab bisher nur den BME280 verwendet. Hatte jetzt aber schon bei zwei Exemplaren das Problem, dass nach einigen Monaten die Luftfeuchtigkeit zu hoch (teilweise über längere Zeit 100%) angezeigt wird.

Nun hab ich gesehen, dass der SHT-30 unterstützt wird. Laut Datenblatt hat er eine Genauigkeit von +/- 0,3°C (wenn ich es richtig verstehe). Auf der Projektseite, wird ja empfohlen den DS18B20 anstelle des BME280 zu verwenden. Der DS18B20 ist jedoch nur mit +/- 0,5°C angegeben.

Laut Code hat ja wohl der DS Priorität ggü. dem BME und der SHT-30 wiederum Prio ggü. dem DS?

Code Auswählen Erweitern

#ifdef SENSOR_BME280
        uint16_t altitude = this->device().getList0().altitude();
        bme280.measure(altitude);
        temperature10 = bme280.temperature();
        airPressure10 = bme280.pressureNN();
        humidity      = bme280.humidity();
#elif defined SENSOR_BMP180
        uint16_t altitude = this->device().getList0().altitude();
        bmp180.measure(altitude);
        temperature10 = bmp180.temperature();
        airPressure10 = bmp180.pressureNN();
#endif

// Falls DS18X20 vorhanden, dessen Temp der BME280/BMP180 Temp vorziehen
#ifdef SENSOR_DS18X20
        Sens_DS18X20::measure(ds18x20, ds18x20Count);
        temperature10 = ds18x20[0].temperature();
        // Beispiel: Hier sind alle DS18B20 Temperaturen im Array falls mehrere DS18B20 an einem Pin/Bus verwendet werden
        // Dafür muss DS18X20_COUNT in der Konfigurationsdatei angepasst werden!
        // for (uint8_t i = 0; i < DS18X20_COUNT; i++) {
        //    temp10Array18x20[i] = ds18x20[i].temperature();
        //}
#endif

// Feuchte/Temp vom SHT31/21/10 falls kein BME280 vorhanden
#ifndef SENSOR_BME280
#ifdef SENSOR_SHT31
        sht31.measure();
        temperature10 = sht31.temperature();
        humidity      = sht31.humidity();
#elif defined SENSOR_SHT21
        sht21.measure();
        temperature10 = sht21.temperature();
        humidity      = sht21.humidity();
#elif defined SENSOR_SHT10
        sht10.measure();
        temperature10 = sht10.temperature();
        humidity      = sht10.humidity();
#endif
#endif

Also die Frage ist: wenn ich einen SHT-30 verwende, dann macht es keinen Sinn, parallel einen DS18B20 anzuschließen. Erstens, weil der SHT ja höhere Priorität hat und zweitens, weil er eine höhere Genauigkeit hat? Wohl mit dem kleinen Haken, dass er mit einem Breakout-Board etwas träger reagiert als ein freifliegender DS?

[Gernott]

Also die Frage ist: wenn ich einen SHT-30 verwende, dann macht es keinen Sinn, parallel einen DS18B20 anzuschließen. Erstens, weil der SHT ja höhere Priorität hat und zweitens, weil er eine höhere Genauigkeit hat? Wohl mit dem kleinen Haken, dass er mit einem Breakout-Board etwas träger reagiert als ein freifliegender DS?

Das ist wohl so. Bei mir habe ich im Unisensor-Sketch die Temperaturmessung vom SHT stets auskommentiert, weil ich die Temperatur vom DS18B20 bevorzuge. Bei Tom im Github gibt es einige Kurven zur Trägheit der auf die Breakouts aufgelöteten Temperatursensoren. Kann jeder also selbst entscheiden, welche Temperatur er nutzen will.

[Tom Major]

Laut Code hat ja wohl der DS Priorität ggü. dem BME und der SHT-30 wiederum Prio ggü. dem DS?

Also die Frage ist: wenn ich einen SHT-30 verwende, dann macht es keinen Sinn, parallel einen DS18B20 anzuschließen. Erstens, weil der SHT ja höhere Priorität hat und zweitens, weil er eine höhere Genauigkeit hat? Wohl mit dem kleinen Haken, dass er mit einem Breakout-Board etwas träger reagiert als ein freifliegender DS?

ja, soll aber nur ein Beispiel mit den ganzen #if/else sein. Du kannst ja jederzeit nicht genutzte Zuweisungen auskommentieren oder verschieben wegen den Prioritäten.

Der SHT-30 auf einem Breakout Board wird prinzipiell ähnliche Trägheitsprobleme wie der BME haben. Allerdings sehe ich beim Amazon Bild eine Art Folie zwischen SHT und Board. Eventuell ist die zur thermischen Isolierung?
Genau wissen wirst du es erst mit eigenen Messreihen. Würde vermuten ein DS18 der frei in der Luft hängt wird kaum zu schlagen sein bzgl. Dynamik, aber wer weiß.

Wenn du 2 Temps gleichzeitig beim UniSensor brauchst könntest du den HB-UNI-Sensor3 nehmen.
https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#benutzerspezifische-sensordaten
Allerdings müsste dafür dann auch das Perl Skript angepasst werden.

[kadettilac89]

Laut Code hat ja wohl der DS Priorität ggü. dem BME und der SHT-30 wiederum Prio ggü. dem DS?


Also die Frage ist: wenn ich einen SHT-30 verwende, dann macht es keinen Sinn, parallel einen DS18B20 anzuschließen. Erstens, weil der SHT ja höhere Priorität hat und zweitens, weil er eine höhere Genauigkeit hat? Wohl mit dem kleinen Haken, dass er mit einem Breakout-Board etwas träger reagiert als ein freifliegender DS?

ich habe alle 3 Sensoren im Einsatz. Die Steuerung welcher aktiv ist habe ich, wie schon von Gernot und Tom Major schrieb, per Änderung im Sourcecode gemacht.

Kombination BME280 mit DS18B20. Der BME280 war langsam und zeigte zu hohe Temperaturen an. Die SHT30 und DS18B20 waren immer identisch. Der SHT30 nur etwas langsamer. Im Neuzustand kein Problem.

Das Problem mit der Luftfeuchte habe ich nicht, habe 2 Sensoren außen und die hängen da seit 3 oder 4 Jahren. Bildet sich vielleicht Kondenswasser in deinem Gehäuse das nicht ablaufen kann?

[vbs]

Ok, danke euch. Ich werde da mal rumprobieren.

Die Trägheit beim BME280-Breakout ist ja doch beachtlich. Der braucht ja 2 Stunden...

Die schnelle Reaktionszeit beim DS18 bezieht sich sicherlich auf die Variante mit dem kleinen Bauteil hier rechts auf dem Bild oder? Ich hab noch einen mit Kabel und diesem "Kolben" wie links auf dem Bild. Der Kolben wird wohl auch eine ziemlich Trägheit mitbringen, oder?

https://github.com/TomMajor/SmartHome/raw/master/HB-UNI-Sensor1/Images/DS18B20_Pin_Assignment.jpg

Das Problem mit der Luftfeuchte habe ich nicht, habe 2 Sensoren außen und die hängen da seit 3 oder 4 Jahren. Bildet sich vielleicht Kondenswasser in deinem Gehäuse das nicht ablaufen kann?

Ja, hab ich schon versucht. Hab den Sensor reingeholt und komplett durchgelüftet. Wurde zwar besser, aber zeigt systematisch z.B. innen ~40% an während mehrere anderen Sensor 32% zeigen. Dann hab ich ihn wieder auf den Balkon gehängt und da war er sofort wieder bei 95-100%...
Hab ihn dann gegen ein anderes Exemplar getauscht und dann war es sofort i.O. Ist mir nicht klar, was das los ist... Werde jetzt auf einen SHT-35 umsteigen probeweise bzw. DS18.

[Gernott]

Die Trägheit beim BME280-Breakout ist ja doch beachtlich. Der braucht ja 2 Stunden...

Die schnelle Reaktionszeit beim DS18 bezieht sich sicherlich auf die Variante mit dem kleinen Bauteil hier rechts auf dem Bild oder? Ich hab noch einen mit Kabel und diesem "Kolben" wie links auf dem Bild. Der Kolben wird wohl auch eine ziemlich Trägheit mitbringen, oder?

https://github.com/TomMajor/SmartHome/raw/master/HB-UNI-Sensor1/Images/DS18B20_Pin_Assignment.jpg
Ja, hab ich schon versucht. Hab den Sensor reingeholt und komplett durchgelüftet. Wurde zwar besser, aber zeigt systematisch z.B. innen ~40% an während mehrere anderen Sensor 32% zeigen. Dann hab ich ihn wieder auf den Balkon gehängt und da war er sofort wieder bei 95-100%...
Hab ihn dann gegen ein anderes Exemplar getauscht und dann war es sofort i.O. Ist mir nicht klar, was das los ist... Werde jetzt auf einen SHT-35 umsteigen probeweise bzw. DS18.

Ja, der DS18B20 steht beim Unisensor zumeist frei an seinen 3 Beinchen auf der Platine und zeigt damit die geringste Trägheit. Diese Teile im Kolben sind m.E. nur für Messungen in Flüssigkeitssonden sinnvoll. Ich verwende ansonsten SHT31/35 auf Breakouts, aber nur für die Feuchtigkeit. Einen BME280 hatte ich auf dem Balkon, wo er nach einigen Monaten ebenfalls gelegentlich auf 100 % ging und letztendlich dort blieb. Zum Schluß zeigte er auch einen positiven Temperaturoffset und Ausfälle auch beim Druck. Vor einiger Zeit habe ich ihn im Backofen bei 120 °C getrocknet, was ihn wohl leidlich "repariert" hat. Er zeigt aber danach immer noch  im Innenbereich einen um 5..10 %-Punkte höheren Wert an als die SHT35. Ich bin inzwischen der Meinung daß die BME für den Freilufteinsatz nur bedingt geeignet sind, und wenn, dann an einem sehr gut geschützten Platz bzw. mit einer Goretex-Schutzkappe o.ä. Selbst wenn es draußen Nebel gibt und er in Kontakt mit dem Sensor kommt, übersättigt er und das war es dann.

Die Sensorträgheit kann man mit einer guten Durchströmung des Sensorgehäuses zwar reduzieren, aber am Ende hat man eben immer die Masse des Boards unter dem Sensor, angekoppelt über die Lötpads. Durch entsprechendes Freifräsen kann man die Kopplung reduzieren, oder durch Kontaktierung mit Drähtchen. Beim SHT10 auf der Mikroplatine ging das noch, die SHT35 habe ich bisher nur auf großen Platinen gesehen. Andererseits muß man sich auch fragen, mit welcher Trägheit man in seinem Anwendungsfall leben kann...

[Tom Major]

Diese Folie hier im Bild meinte ich beim SHT30 Breakout, eventuell ist die zur thermischen Isolierung?
https://www.amazon.de/SHT30-D-Temperature-Humidity-Breakout-Temperatur-Luftfeuchtigkeitssensor/dp/B07S1FLHTC

Stimme Gernott zu bzgl. BME280 außen. Meine Erfahrungen nach ca. 2,5 Jahren HB-UNI-Sensor1 außen sind bzgl. BME auch nicht so doll, sowohl Werte für Luftdruck und bes. Feuchtigkeit.

Hauptproblem war bei mir aber immer mal wieder das Nicht mehr Melden des Sensors bei der Zentrale vor allem bei Minusgraden. Spannung war dabei immer ok, brauchte nur einen Reset.
Habe deswegen im Winter einen Prototyp mit extra ATtiny als "Message Watchdog" gebaut, seitdem gibt es keine Probleme mehr.
Deshalb werde wohl ich in den nächsten Monaten noch mal eine neue Revision der HB-UNI-Sensor1 machen, mit Watchdog und dann vlt. gleich ein SHT3x Breakout mit vorsehen.

Bis auf das Winterproblem lief der Sensor aber ziemlich stabil, auch die Batterien musste ich erst nach 2 Jahren wechseln. 

[Gernott]

Diese Folie hier im Bild meinte ich beim SHT30 Breakout, eventuell ist die zur thermischen Isolierung?
https://www.amazon.de/SHT30-D-Temperature-Humidity-Breakout-Temperatur-Luftfeuchtigkeitssensor/dp/B07S1FLHTC

Stimme Gernott zu bzgl. BME280 außen. Meine Erfahrungen nach ca. 2,5 Jahren HB-UNI-Sensor1 außen sind bzgl. BME auch nicht so doll, sowohl Werte für Luftdruck und bes. Feuchtigkeit.

Hauptproblem war bei mir aber immer mal wieder das Nicht mehr Melden des Sensors bei der Zentrale vor allem bei Minusgraden. Spannung war dabei immer ok, brauchte nur einen Reset.
Habe deswegen im Winter einen Prototyp mit extra ATtiny als "Message Watchdog" gebaut, seitdem gibt es keine Probleme mehr.
Deshalb werde wohl ich in den nächsten Monaten noch mal eine neue Revision der HB-UNI-Sensor1 machen, mit Watchdog und dann vlt. gleich ein SHT3x Breakout mit vorsehen.

Bis auf das Winterproblem lief der Sensor aber ziemlich stabil, auch die Batterien musste ich erst nach 2 Jahren wechseln. 

Das in Deinem Link sieht tatsächlich wie eine Art Spacer aus, um den Sensor etwas vom Brett zu separieren. Habe ich bei meinen China-Teilen noch nie gesehen. Ich kann mir aber nicht vorstellen, daß es viel bringt, weil ich ja noch die metallischen Wärmebrücken der Lötstellen habe. Aber, vielleicht ist der Chip ja davon intern durch Bondingdrähte entkoppelt.

Meinen BME hatte ich als Zusatzsensor an einem Feinstaubsensor mit ESP, der immer am Strom hing. Da das Teil aber nicht wirklich gut geschützt war und bei stärkerem Wind eben doch direkt nasse Luft abbekam,  habe ich den BME nun wieder entfernt. Den Luftdruck kann man auch im Innenraum messen und fürs Außenklima habe ich noch einen originalen HM-Aussensensor unterm Dachvorsprung hängen, der zuverlässig arbeitet und sich nur nach dem Batteriewechsel etwas zickig anstellt, bis er wieder Daten liefert.