Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Tom Major]

Hmm, normalerweise sollte für FHEM reichen was ich im readme geschrieben habe:

Die Datei FHEM/HMConfig_UniSensor1.pm nach /opt/fhem/FHEM kopieren, dann FHEM neustarten.

Falls Arnd auf der richtigen Fährte ist, dann wäre mal ein Diff zwischen der Problem HMConfig_UniSensor1.pm im FHEM Ordner und der direkt per Browser runtergeladenen Variante interessant.

[RaspiLED]

Hi,
Probiere doch mal diese Dateien:
https://forum.fhem.de/index.php?action=dlattach;topic=93045.0;attach=108470 die bei gloob funktionieren!
Als Model sollte dann HB-GEN-SENS sein.

Edit: Kann bestätigen, dass die Dateien bei mir auch laufen und ich das Model auswählen kann

Gruß Arnd


Gesendet von iPhone mit Tapatalk

[bromosky]

Moin,

ich habe Neues zu berichten.
Ich habe auf der Hauptinstanz nun es geschafft, über den Befehl im Wiki die SenTHPL.pm einzubinden (über FHEM-Konsole).
Danach habe ich über die Zip, welche ich per wget geholt habe, die UniSensor1.pm in das /opt/fhem/FHEM Verzeichnis verschoben. Per chown es möglich gemacht, FHEM zuzugreifen.
Nun ist alles so wie es soll.
Auch zeigt der FHEM-Log keine Fehler mehr an.

Dies ist die Raw-Config:

Code Auswählen Erweitern

defmod HM_444005 CUL_HM 444005
attr HM_444005 DbLogExclude .*
attr HM_444005 IODev nanoCUL
attr HM_444005 IOgrp VCCU:nanoCUL
attr HM_444005 actCycle 000:10
attr HM_444005 actStatus alive
attr HM_444005 autoReadReg 4_reqStatus
attr HM_444005 expert 2_raw
attr HM_444005 firmware 0.2
attr HM_444005 model HB-UW-Sen-THPL-O
attr HM_444005 peerIDs 00000000,
attr HM_444005 room CUL_HM
attr HM_444005 serialNr FHEM444005
attr HM_444005 subType THPLSensor

setstate HM_444005 2018-11-10 14:15:42 .D-devInfo 010000
setstate HM_444005 2018-11-10 14:15:42 .D-stc 41
setstate HM_444005 2018-11-10 14:15:42 .peerListRDate 2018-11-10 14:15:42
setstate HM_444005 2018-11-10 14:15:59 .protLastRcv 2018-11-10 14:15:59
setstate HM_444005 2018-11-10 14:18:14 Activity alive
setstate HM_444005 2018-11-10 13:42:15 CommandAccepted yes
setstate HM_444005 2018-11-10 14:15:42 D-firmware 0.2
setstate HM_444005 2018-11-10 14:15:42 D-serialNr FHEM444005
setstate HM_444005 2018-11-10 14:15:42 PairedTo 0x310597
setstate HM_444005 2018-11-10 13:42:19 R-pairCentral 0x310597
setstate HM_444005 2018-11-10 14:15:42 RegL_00. 0A:31 0B:05 0C:97 00:00



Sprich ich kann nun auch als Model: den Unisensor, den THPL-O oder I auswählen und als subtpe sowohl THPL als auch Unisensor.
Nur die richtigen Werte mag er mir wirklich nicht ausspucken.
Aber ja, ein Fehler war es, die eine .pm per wget zu holen. Danke Arnd für den Tipp.

@RaspiLED Die Zip schaue ich mir sofort an, wenn ich Gelegenheit dazu habe.

Grüße, Max

[bromosky]

Ich schon wieder,

ich habe die .pm's erfolgreich eingefügt, die aus der .zip von Arnd stammen. Danke dafür!

Alles soweit okay, er wird sogar das Model richtig gesetzt, subtype auf custom. Stimmt der subtype oder sollte der lieber auf THLP-Sensor?

Nun muckt aber nicht mehr der CUL auf, sondern es werden valueFormat's verlangt. Ein kurzer Blick ins wiki half mir jedoch nicht so recht weiter.
Ich werde noch etwas mich umschauen, falls jedoch jemand ein Tipp hat, ich wäre euch sehr dankbar.

Code Auswählen Erweitern

2018.11.10 20:05:01 1: Missing attribute valuesformat at HM_444005_Values
2018.11.10 20:05:46 2: CUL_HM Unknown device HM_444003 is now defined
2018.11.10 20:05:46 2: autocreate: define HM_444003 CUL_HM 444003
2018.11.10 20:05:46 2: autocreate: define FileLog_HM_444003 FileLog ./log/HM_444003-%Y.log HM_444003
2018.11.10 20:06:22 1: Missing attribute valuesformat at HM_444003_Values
2018.11.10 20:06:22 0: CUL_HM_assignIO HM_444003 AssignIoPort used
2018.11.10 20:08:15 1: Missing attribute valuesformat at HM_444005_Values
2018.11.10 20:11:29 1: Missing attribute valuesformat at HM_444005_Values

Die HM_444003 spuckte keinen Fehler aus, da der subtype zum testen auf THLP-Sensor gesetzt war. Jedoch gab es hierbei keine Readings, die auf Lufttfeuchtigkeit/temperatur oder Druck hinweisen würden.

Grüße, Max.

[RaspiLED]

Hi,
Hilft das:

Code Auswählen Erweitern


attr HM_xxxxxx_Values userattr valuesformat
attr HM_xxxxxx_Values valuesformat 2s:temperature:10 1:humidity 1:batVoltage:10

Quelle:
https://forum.fhem.de/index.php/topic,90300.msg827464.html#msg827464
Gruß Arnd


Gesendet von iPhone mit Tapatalk

[PeMue]

Hallo zusammen,

Mein Changelog für Ver 2.01
- MAX44009 hinzugefügt
- BMP180 entfernt (Ersatz durch BME280)
- TSL2561 entfernt (Ersatz durch MAX44009) warum? https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/SensorTest_Lux
- zweite I2C Stiftleiste für zusätzliche Sensoren auf Breakout-Boards
- meine Schaltung für echte Batteriespannungsmessung unter Last hinzugefügt
- 10k pull-up Widerstand am ChipSelect des CC1101 für sicheres ISP-Flashen (Bootloader) mit verbautem CC1101
- Miniatur-Quarz 8MHz optional bestückbar (anstatt int. RC-Osc.)
- alle Abstände der Leiterbahnen gegeneinander auf min. 0,25mm vergrößert
- Layout entflochten und verbessert
- Lötpads für BME280 und MAX44009 nach außen verlängert falls man versuchen will diese ohne Reflow oder Heisßluft zu löten

und so sieht das Ganze dann mit verlöteten Bauteilen aus (BME280 per Schablone und Reflow, MAX44009 auf der oberen Platine unter dem Mikroskop per Hand, da die Schablone nicht gepasst hat  ). Das Löten des MAX44009 ist eine ziemliche Fummelei, geht aber schlußendlich dann doch einigermaßen.

Tests folgen, aber Durchmessen mittels Ohmmeter zeigt, dass alle Pins angeschlossen sein sollten und die Sensoren funktionieren sollten.

Gruß PeMue

[Tom Major]

Gute Arbeit  , bin gespannt ob beide aufgelötete Sensoren funktionieren.

[Kai-Alfonso]

Gute Arbeit  , bin gespannt ob beide aufgelötete Sensoren funktionieren.

Ich hab die Sachen auch noch auf meiner Todo Liste, warte derzeit noch auf die Atmegas und schlechteres Wetter

[PeMue]

Gute Arbeit  , bin gespannt ob beide aufgelötete Sensoren funktionieren.

Und hier kommt die Auflösung:
Sie funktionieren (siehe Bilder im Anhang).
Leider gibt es keine vorcompilierte ESPEasy Version, die den MAX44009 bedient, aber ich denke, wenn der Baustein unter der Adresse 0x4A gefunden wird, dann sollte der Rest auch funktionieren.

Gruß PeMue

[Tom Major]

Das klingt gut, denke auch dass wenn Du die I2C Adresse 4A auf dem Bus siehst alles mit dem Löten geklappt hat 

[PeMue]

Hallo zusammen,

hier mal eine laienhafte Frage eines Hardwerkers zur Software (wenn es hier nicht passt, verschiebe ich das gerne in die AskSin Ecke):

Ich beziehe mich auf diese Darstellung:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1 Option 2 und 3.

Warum ist eine gesonderte Programmierung in der Software notwendig? Die Ansteuerung ist doch identisch.

Ich vermute, das hängt mit der Zeit zwischen den Messungen (immer zusammen mit dem Messwert bei Option 2, nur 2x am Tag bei Option 3 wegen Messung unter Last) zusammen.

Gibt es irgendwo ein Beispiel, wo alle drei Optionen per #include parametrierbar sind?

Zwei habe ich schon gefunden:

Code Auswählen Erweitern

#ifdef INTERNAL_VOLTAGE_MEASUREMENT
  typedef BatterySensor           BatteryType;
#else
  typedef BatterySensorUni<5, 6>  BatteryType;
#endif
oder auch entsprechend mit der Definition der beiden Pins BAT_SENS_PIN bzw. BAT_EN_PIN.
Als dritten Parameter hätte ich dann noch LOAD_VOLTAGE_MEASUREMENT als false/true genommen.

Danke + Gruß

Peter

[Tom Major]

Ich beziehe mich auf diese Darstellung:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1 Option 2 und 3.

Warum ist eine gesonderte Programmierung in der Software notwendig? Die Ansteuerung ist doch identisch.

Gibt es irgendwo ein Beispiel, wo alle drei Optionen per #include parametrierbar sind?

Danke + Gruß

Peter

Hallo Peter,
nein, die Ansteuerung ist bei Option 2) und 3) nicht identisch. Bei 2) wird mit Low an D9 die Messung aktiviert, bei 3) mit High um den N-Kanal Mosfet durchzuschalten. (R4 dort ist ein Safety (Angst-Widerstand) falls durch Fehler irgendeiner Art der Port auf input bleibt, wir wollen dann keinen Laststrom  )
Weiterhin möchte ich bei 3) z.B. für 200ms warten bevor ich messe wegen der Belastung, dass ist bei 2) nicht nötig.

Ich kann gerne bei Gelegenheit alle 3 Optionen per #include parametrierbar machen. Vorher stehen noch ein paar Langzeittests mit Option 3) an, danach mache ich das.

[papa]

Ich kann gerne bei Gelegenheit alle 3 Optionen per #include parametrierbar machen. Vorher stehen noch ein paar Langzeittests mit Option 3) an, danach mache ich das.

Wir können das dann als extra Klasse in die Lib einbauen.

[PeMue]

Hallo Tom,

nein, die Ansteuerung ist bei Option 2) und 3) nicht identisch. Bei 2) wird mit Low an D9 die Messung aktiviert, bei 3) mit High um den N-Kanal Mosfet durchzuschalten. (R4 dort ist ein Safety (Angst-Widerstand) falls durch Fehler irgendeiner Art der Port auf input bleibt, wir wollen dann keinen Laststrom  )
Weiterhin möchte ich bei 3) z.B. für 200ms warten bevor ich messe wegen der Belastung, dass ist bei 2) nicht nötig.

ups, Denkfehler meinerseits. Der Transistor invertiert die Logik ja. Danke für die Klarstellung.

Ich kann gerne bei Gelegenheit alle 3 Optionen per #include parametrierbar machen. Vorher stehen noch ein paar Langzeittests mit Option 3) an, danach mache ich das.

Das wäre echt klasse. Auf jeden Fall habe ich schon mal Option 1 und 2 in der Software drin und sie wird auch fehlerfrei kompiliert.

Wir können das dann als extra Klasse in die Lib einbauen.

Wenn das dann auch ein Hardwerker versteht, wäre das klasse.

Danke + Gruß

Peter

[Tom Major]

Wir können das dann als extra Klasse in die Lib einbauen.

ich kann gern einen PR der Batt. Klasse für Option 3 machen, brauche aber noch ein paar Tage bis ich dazu komme und für Tests.