Seite 21 von 36

Re: HB-UNI-Sensor1-THPD-BME280

Verfasst: 05.06.2021, 08:17
von deimos
Hi,
Hackertomm hat geschrieben:
05.06.2021, 00:51
Und Smartkram kann da nix für, da sie die Platine von Alexander Reinert verwenden.
Dieser müsste da eine 2.Version, nur für den Ebyte-E07-868MS10 entwerfen.
Warum sollte ich? Smartkram macht das in eigenem Namen und auf eigene Rechnung mit einer alten Revision der Platine, welche leider noch nicht unter der aktuellen Lizenz steht, so dass ich ihnen das leider nicht untersagen kann. Ansonsten gäbe es die Platinen dort nicht mehr.
Aber jeder, der sich nur minimal in das Thema einließt, bevor er dort kauft, wirdmerken, dass man deutlich günstiger an die Platinen kommt, entweder direkt bei mir zum Selbstkostenpreis oder bei größeren Mengen über JLCPCB.

Viele Grüße
Alex

Re: HB-UNI-Sensor1-THPD-BME280

Verfasst: 29.06.2021, 20:42
von Shortie
Ist es möglich den HB-UNI-Sensor1-THPD-BME280 per Direktverknüpfung mit einem HM-CC-RT-DN zu verbinden wenn ein 32khz Oszillator verwendet wird?
Aktuell nutze ich dazu HM-WDS40-TH-I-RTC-BME280 und würde gerne wegen der weiteren Features umsteigen.

Re: HB-UNI-Sensor1-THPD-BME280

Verfasst: 30.06.2021, 08:26
von FUEL4EP
Hi Shortie,

es spricht zuerst mal nichts dagegen, dass ein Pairing mit dem Thermostaten HM-CC-RT-DN möglich ist, wenn wie beim HM-WDS40-TH-I-RTC-BME280 ein 32kHz Quarz verwandt wird. HM-WDS40-TH-I-RTC-BME280 verwendet als Sketch HM-WDS40-TH-I. HB-UNI-Sensor1-THPD-BME280 ist austauschkompatibel zu HM-WDS40-TH-I. Da ich keinen meiner Sensoren umlöten will (bin ja nur ein grobmotoriger Löter :D ), kann ich das leider nicht testen.

Also: Bitte versuche es bei Dir und berichte hier darüber.

Re: HB-UNI-Sensor1-THPD-BME280

Verfasst: 30.06.2021, 19:40
von Shortie
Hi,

danke, das klingt ja schon mal sehr vielversprechend. Dann werde ich mal einen umflashen und berichten.

Ich hab mir vorhin schon zum testen den Sketch auf ein Testboard geflasht (aktuell ist da auch noch kein BME280 dran und auf der Platine ist auch kein 32kHz Oszillator). Dabei habe ich festgestellt, das ich für die Einbindung in fhem noch etwas mehr tun muss. Ich sitze daher die letzten Stunden daran zu verstehen wie ich das in der HMConfig_AskSinPPCustom.pm eintragen muss. Bisher wollte sich der Erfolg noch nicht einstellen.

Re: HB-UNI-Sensor1-THPD-BME280

Verfasst: 02.07.2021, 10:47
von Hackertomm
Ich habe ja den Sensor damals am 06.04.21 ebenfalls nach gebaut, mehr zum Spaß, weil ich gerade eine wegen "Stromfressen" aussortierte Platine eines HM-WDS40-TH-I-BME280 HM-WDS40-TH-I-BME280hatte.
Diese Platine verbrauchte innerhalb von etwas über 2 Wochen einen Satz Batterien und wurde dann nach dem schon mehrere Sätze Batterien durch waren, aussortiert.

Es wurden dann die 2 Batteriehalter ausgelötet, denn die brauchte ich bei der Neuen HM-WDS40-TH-I-BME280 Platine, die die Alte Platine ersetzen sollte.
Den BME280 wollte ich ebenfalls übernehmen, aber der ist beim Auslöten drauf gegangen , da musste ich einen Neuen Einlöten, den letzten aus meinem Vorrat.
Deshalb ist ist auf dem HB-UNI-Sensor1-THPD-BME280 ein umgelöteter 5V BME280 drauf.
Aber was ich eigentlich schreiben wollte, der HB-UNI-Sensor1-THPD-BME280 läuft ja jetzt seit 06.04.21, immer noch mit dem selben Satz Batterien.
Die Batteriespannung ist momentan 2,94V!
Soll heißen er wird noch lange Dauern bis "Batterie Leer" Gemeldet wird.

Das lässt aber den Verdacht zu, dass bei Stromfressenden Bausätzen, die Fuses der Arduinos Schuld sein könnten!
Denn dass war eine der Änderung, die auf der ehemaligen Stromfressenden Platine gemacht wurde, das die Fuses umgeflasht wurden.
Die 2. Änderung war das Einlöten der I2C Abschluss Widerstände, aber das dürfte aber nicht die Ursache gewesen sein.
Ich vermute, das da von Haus aus am Arduino die Fuses irgendwie auf Standard gesetzt waren, aber scheinbar nicht richtig wirkten, so dass es zu dem erhöhten Ruhestrom von ca. 2mA kam.
Nach dem Umändern der Fuses, für den HB-UNI-Sensor1-THPD-BME280, war dann der Ruhestrom nur noch 5,1µA, also so wie er sein soll.

Wer also so eine Stromfressende Platine hat, könnte, sofern ein entspr. ISP Programmer vorhanden ist, einfach mal die Fuses auf dem Arduino umflashen.
Vielleicht bringt das was, wie bei mir die Wende und aus einer ehemals Stromfressenden Platine, wird wieder eine Stromsparende!
Wenn ich da jetzt wieder die Batteriehalter einlöte und den HM-WDS40-TH-I-BME280 Sketch aufspiele, dann bin ich ziemlich sicher, dass es wieder ein Stromsparender Sensor wird.
Nur leider brauche ich keinen HM-WDS40-TH-I-BME280, mein Kontingent dafür ist komplett.
Mit dem HB-UNI-Sensor1-THPD-BME280 sind es 5 Stück, wobei der Unisensor.... nur zum Test noch mitläuft.
Sind also vier Sensoren im Live Einsatz, wovon einer ein HB-WDS40-THP-O JPTHPO0001, also ein Außensensor, der auch den Luftdruck bringt.
Ist aber die selbe Platine, nur der Sketch und das Gehäuse ist anders.

Re: HB-UNI-Sensor1-THPD-BME280

Verfasst: 03.07.2021, 17:21
von Shortie
Das Pairing mit einem HM-CC-RT-DN scheint zu klappen.

Die Einbindung in fhem hat mittlerweile auch geklappt, ich hoffe es ist alles korrekt so. Falls es noch jemand benötigt, das ist mein aktueller Stand.

Code: Alles auswählen

# HB-UNI-Sensor-THPD-BME280
# a="index", s="size", l="list", min="min", max="max", t="id", c="conversion function", f="factor", u="unit", d="show register in readings", t="description"
# possible conversions from 10_CUL_HM: fltCvT, fltCvT60, min2time, m10s3, hex, lit
$HMConfig::culHmRegDefine{"deviceLedMode"} = {a=>5.6,s=>0.2,l=>0,min=>0,max=>1,c=>'',p=>'n',f=>'',u=>'',d=>1,t=>"LED mode"};
$HMConfig::culHmRegDefine{"lowBatLimit"} = {a=>18,s=>1,l=>0,min=>0.9,max=>5.0,c=>'',p=>'n',f=>10,u=>'V',d=>1,t=>"low battery limit"};
$HMConfig::culHmRegDefine{"transmitDevTryMax"} = {a=>20,s=>1,l=>0,min=>1,max=>10,c=>'',p=>'n',f=>'',u=>'',d=>1,t=>"transmitDevTryMax"};
$HMConfig::culHmRegDefine{"transmitTimeInterval"} = {a=>32,s=>2,l=>0,min=>60,max=>43200,c=>'',p=>'n',f=>'',u=>'s',d=>1,t=>"transmiti time interval"};
$HMConfig::culHmRegDefine{"altitudeAboveSeaLevel"} = {a=>34,s=>2,l=>0,min=>0,max=>10000,c=>'',p=>'n',f=>'',u=>'m',d=>1,t=>"altitude above sea level"};
$HMConfig::culHmRegDefine{"temperatureOffset"} = {a=>1,s=>1,l=>1,min=>-5,max=>5,c=>'',p=>'n',f=>'10',u=>'K',d=>1,t=>"temperature offset"};
$HMConfig::culHmRegDefine{"humidityOffset"} = {a=>2,s=>1,l=>1,min=>-5,max=>5,c=>'',p=>'n',f=>'10',u=>'%',d=>1,t=>"humidity offset"};
$HMConfig::culHmRegDefine{"pressureOffset"} = {a=>3,s=>1,l=>1,min=>-10,max=>10,c=>'',p=>'n',f=>'10',u=>'hPa',d=>1,t=>"pressure offset"};

# HB-UNI-Sensor-THPD-BME280
# details in HMConfig.pm, F604 = id, st = type for custom message handling set it to custom, cyc = cycle
$HMConfig::culHmModel{"F604"} = {name=>"HB-UNI-Sensor-THPD-BME280",st=>'custom',cyc=>'00:10',rxt=>'l:c:w',lst=>'1',chn=>""};
$HMConfig::culHmChanSets{"HB-UNI-Sensor-THPD-BME280"}{fwUpdate} = "<filename>";
$HMConfig::culHmChanSets{"HB-UNI-Sensor-THPD-BME280"} = $HMConfig::culHmSubTypeSets{"THSensor"};
# list of available register
$HMConfig::culHmRegModel{"HB-UNI-Sensor-THPD-BME280"} = { deviceLedMode => 1, lowBatLimit => 1, transmitDevTryMax => 1, transmitTimeInterval => 1, altitudeAboveSeaLevel => 1, temperatureOffset => 1, humidityOffset => 1, pressureOffset => 1 };

# process custom message
$customMsg{"HB-UNI-Sensor-THPD-BME280"} = sub {
  my ($msg,$target) = @_;
  my $device = main::CUL_HM_id2Hash($msg->from);
  my @evtEt=();
      if( $msg->isWeather ) {
      my $temp = $msg->payloadWord(0) & 0x7fff;
      my $battery = "ok";
      $battery = "low" if (($msg->payloadByte(0) & 0x80)==0x80);
      my $humidity = $msg->payloadWord(2);
      my $pressure = $msg->payloadWord(4);
      my $dewpoint = $msg->payloadWord(6);
      my $vapor = $msg->payloadWord(8);
      my $voltage = $msg->payloadWord(10);
      push @evtEt,[$device,1,"temperature:".$temp/10];
      push @evtEt,[$device,1,"battery:".$battery];
      push @evtEt,[$device,1,"humidity:".$humidity/10];
      push @evtEt,[$device,1,"pressure:".$pressure/10];
      push @evtEt,[$device,1,"dewpoint:".$dewpoint/10];
      push @evtEt,[$device,1,"vapor:".$vapor/100];
      push @evtEt,[$device,1,"voltage:".$voltage/1000];
      push @evtEt,[$device,1,"state:T: ".($temp/10)." P: ".($pressure/10)." H: ".($humidity/10)];
   return @evtEt;
    }
    return ();
};

Re: HB-UNI-Sensor1-THPD-BME280

Verfasst: 03.07.2021, 17:37
von FUEL4EP
👍

Ausgezeichnet!

Danke für die schnelle Rückmeldung.

Re: HB-UNI-Sensor1-THPD-BME280

Verfasst: 03.07.2021, 17:39
von jp112sdl
Shortie hat geschrieben:
03.07.2021, 17:21
Das Pairing mit einem HM-CC-RT-DN scheint zu klappen.
Behalte mal im Auge, ob das Timing klappt.
Ich erinnere mich dunkel an das aufwendige Feintuning...
https://github.com/pa-pa/AskSinPP/blob/ ... -I.ino#L10

Re: HB-UNI-Sensor1-THPD-BME280

Verfasst: 03.07.2021, 22:31
von papa
Shortie hat geschrieben:
03.07.2021, 17:21
Das Pairing mit einem HM-CC-RT-DN scheint zu klappen.

Die Einbindung in fhem hat mittlerweile auch geklappt, ich hoffe es ist alles korrekt so. Falls es noch jemand benötigt, das ist mein aktueller Stand.
Machst Du daraus bitte noch nen Pull-Request. Dann können es auch andere FHEM-User nutzen.

Danke

Re: HB-UNI-Sensor1-THPD-BME280

Verfasst: 04.07.2021, 11:28
von Shortie
Ich hab mir ein Chart gebaut um zu sehen ob Sensor und Weather Channel gleich bleiben, ich werde es weiter beobachten und berichten.

Einen Pull Request kann ich gerne noch erstellen.

Aktuell habe ich noch etwas Probleme mit der Batteriemessung. Ich nutze als Platine HMSensor mit StepUp und 1xAA. HMSensor ist mit 470k und 100k bestückt. Konfiguriert im Sensor habe ich:

Code: Alles auswählen

#define BAT_SENSOR tmBatteryResDiv<17, 7, 5700>
Im Sketch habe ich aktuell im loop auskommentiert das er ins sleepForever() geht zum weiteren testen.
Ich bekomme aktuell gemeldet das die Batterie nur noch 0.477V hat, mein Multimeter zeigt 1,33V an. Mit einer neuen Batterie frisch aus der Verpackung zeigt er mir 0.575V an.