Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[frank]

Das könnte für den größeren Code verantortlich sein. Ich habe hier:

Code Auswählen Erweitern

avr-gcc (WinAVR 20100110) 4.3.3

nach der installation von WinAVR-20100110 von hier http://sourceforge.net/projects/winavr/ klappt es auch mit dem bauen des bootloaders.

gruss frank

[pc1246]

Juchhu geschafft!

Man oh man, 76 Seiten sind echt kein Pappenstiel! Ich willl auch solche Teile haben! Dirk schickst Du mir eine Preisliste, bitte!?

@Mr.P. und betateilchen: Das mit der steigenden Spannung wundert mich nicht! Wenn die Akkus/Batterien weniger belastet werden (Strom), dann steigt die Zellenspannung logischerweise etwas an. Aber das war Euch klar denke ich! Andererseits zeigt es, dass Dirks Stromsparansaetze greifen!

Gruss Christoph

[Mr. P]

@Mr.P. und betateilchen: Das mit der steigenden Spannung wundert mich nicht! Wenn die Akkus/Batterien weniger belastet werden (Strom), dann steigt die Zellenspannung logischerweise etwas an. Aber das war Euch klar denke ich! Andererseits zeigt es, dass Dirks Stromsparansaetze greifen!

Jo... War betateilchen und mir schon klar, dass wir nicht plötzlich ein Perpetuum mobile in unseren Händen halten.
Das Dirks Ansätze greifen, sehe ich auch bereits recht gut in meinen div. Spannungsaufzeichnungen, die ich bei mir laufen habe. Mal sehen, wie diese sich in den nächsten Tagen noch weiter entwickeln.

[maxritti]

Hallo zusammen,

mir geht's so wie pc1246.

Irgendwie habe ich wohl auf den 76 Seiten inzwischen den Überblick verloren. 
Ist schon echt klasse, was hier entwickelt wurde.

Gerne würde ich einen Sensor für Temperatur/Helligkeit für draußen haben.
Später dann ggf. auch noch den ein und anderen Sensor für innen.
Wenn ein solches noch mehr kann... umso besser.

Stellt sich mir die Frage:

Was kostet ein Sensor für außen, der mind. Temperatur und Helligkeit feststellt?
Am besten als Komplettsensor, also auspacken, einschalten, anlernen und fertig. 
Löten geht bei mir zwar, aber keine SMD Technologie.

Es wäre super, wenn ich nehme mal an Dirk mir Infos zusenden könnte.
Gerne auch als PM.

Gruß

Max

[hglaser]

Hallo maxritti

Mir ging es genau so wie Dir. Ich habe von Dirk letzte Woche einen Innensensor erhalten und der funkioniert perfekt. Das Einzige was ich selber machen musste war ein Loch in das Gehäuse über dem Helligkeitssensor zu bohren und den beiligenden durchsichtigen Stab in diesem Loch zu fixieren. An dieser Stelle vielen Dank an Dirk für die tolle Arbeit.
http://forum.fhem.de/index.php/topic,20620.msg199288.html#msg199288 Hier ist eine Preiliste von Dirk, ich hoffe sie ist noch aktuell.

lg Harald

[maxritti]

Hi Harald,

danke Dir dafür.
Ich habe auch gerade Post von Dirk bekommen.
Es geht nun per PM weiter denke ich.

Gruß

Max

[Dirk]

Ich habe mal eine neue Firmware-Version ins Git gestellt. v0.13.
Dies ist aber eine Beta-Version. Wenn sich dafür ein paar Tester finden, währe es schön.

Es gibt jetzt einstellbare Register:

• transmitTryMax: Damit kann eingestellt werden wie oft der Sensor daten an z.B. eine gepairte Zentrale sendet falls kein ACK empfangen wird (1-6)
• lowBatLimit: Damit kann die Battery-Low schwelle eingestellt werden. (1,5 V - 5,0 V)
• ledMode: Hiermit kann das Leuchten der LED im normalen Betrieb abgeschaltet werden. Die LED leuchtet dann nur noch im Config-Mode und kurz beim Starten.
• altitude: Speziell für die CCU-Only User. Damit kann die Sensorhöhe in Metern eingestellt werden. Der Sensor gibt dann dann den Luftdruck bezogen auf Meehreshöhe aus.
  FHEM-Benutzer brauchen dieses Register eigentlich nicht setzen. Da FHEM diese Berechnung selber vornimmt.

Viele Grüße
Dirk

[hexenmeister]

V0.13 habe ich gerade geflasht. Neu gepairt und getConfig. Neue HMConfig_SenTHPL.pm installiert.
Grundfunktion - keine Änderung bemerkt.
Die zusätzliche Register sehe ich auch.

Ich habe versucht, die lowBatLimit auf 1.0 zu setzen. Mit dem Max sehe ich das als ein akzeptabler Wert, geht jedoch nicht:
value:1.0 out of range 1.5 to 5 for Reg "lowBatLimitTHPL"
Ist das nicht etwas zu restriktiv?

ledMode funktioniert.

Ich habe auch mit dem Burst experimentiert: burstAccess auf auto und burstRx auf on. Ich merke hier keine Änderung. getConfig wird erst beim Betätigen der Taste oder erst bei der nächsten Übertragung beantwortet. set burtsXmit bringt auch nichts. Habe ich etwas übersehen?

[Mr. P]

Hej Dirk,

habe jetzt auch auf einen meiner Sensoren die 0.13er Version drauf und bin schon gespannt, wie sie sich schlägt.
Also ledMode ist schon mal toll. Bin schon gespannt, wie sehr sich das auf den Energieverbrauch auswirkt. Und außerdem ist der WAF jetzt hoch genug, damit einer der Sensoren wieder ins Schlafzimmer zurück kann.
Habe zwar keinen Luftdruckmesser, aber bei dem Altitude-Register wäre es wohl interessant, dass dann letztendlich sowohl der gemessene Wert als auch der errechnete übertragen wird. Finde den Weg, dass FHEM sich selbst darum kümmert und die CCU das übergeben benötigt, weniger elegant. Einheitlich beide Werte immer vom Sensor kommen zu lassen wäre mE besser.

Und was mir vorhin noch aufgefallen ist (war aber auch schon bei v0.12 so)... Ich kann die Register nur setzen, wenn ich auf die Config-Taste drücke.
Wenn ich versuche, die Daten als Antwort an die Werte zu senden, beginnt zwar laut FHEM die Verarbeitung, aber der Sensor kann diese nicht verarbeiten.

Vielen Dank fürs Update!

[hexenmeister]

Mein Sensor läuft soweit

Interessante Beobachtung: die ohnehin schwache Batterie wurde beim Update endgültig geplättet. Das hat paar sonderbare Messergebnisse gebracht:

Code Auswählen Erweitern


2014-10-05_00:01:24 EG_WZ_KS01 temperature: 24.8
2014-10-05_00:01:24 EG_WZ_KS01 batVoltage: 0.65
2014-10-05_00:01:24 EG_WZ_KS01 humidity: 53
2014-10-05_00:01:24 EG_WZ_KS01 luminosity: 43.54
2014-10-05_00:01:30 EG_WZ_KS01 temperature: 24.9
2014-10-05_00:01:30 EG_WZ_KS01 batVoltage: 0.66
2014-10-05_00:01:30 EG_WZ_KS01 luminosity: 43.74
2014-10-05_00:01:34 EG_WZ_KS01 temperature: 124.1
2014-10-05_00:01:34 EG_WZ_KS01 batVoltage: 0.64
2014-10-05_00:01:34 EG_WZ_KS01 luminosity: 43.59
2014-10-05_00:01:38 EG_WZ_KS01 temperature: -37.7
2014-10-05_00:01:38 EG_WZ_KS01 batVoltage: 0.63
2014-10-05_00:01:38 EG_WZ_KS01 humidity: 37
2014-10-05_00:01:38 EG_WZ_KS01 luminosity: 43.86
2014-10-05_00:01:42 EG_WZ_KS01 temperature: -39.7
2014-10-05_00:01:42 EG_WZ_KS01 batVoltage: 0.61
2014-10-05_00:01:42 EG_WZ_KS01 humidity: 34
2014-10-05_00:01:42 EG_WZ_KS01 luminosity: 44.53


[mmatt]

Cool... innderhalb von 4 Sekunden von 124.1 auf -37.7 Grad C.
Auf welchem Planeten wohnst Du den 

Grüsse Martin

[Mr. P]

Interessante Beobachtung: die ohnehin schwache Batterie wurde beim Update endgültig geplättet.

Wenn du dir deine Logfiles so durch siehst... Bis zu welcher Spannung würdest du denn behaupten, dass der Sensor zuverlässige Daten geliefert hat?

[hexenmeister]

Der letzte sinnvolle Wert war bei 0,66V geliefert. Da der Max-Chip aber (wenn ich mich recht erinere) ab 0,8V garantiert anläuft, würde diesen Wert als noch 'zuverlässig' betrachten.

Die Dateien sehe ich aber nur dann so genau durch, wenn die Plots auffällig aussehen

[Dirk]

Ich habe versucht, die lowBatLimit auf 1.0 zu setzen. Mit dem Max sehe ich das als ein akzeptabler Wert, geht jedoch nicht:
value:1.0 out of range 1.5 to 5 for Reg "lowBatLimitTHPL"
Ist das nicht etwas zu restriktiv?

Ich hab das dann mal auf 1 gestellt. Das Update im Github kommt dann vermutlich im Laufe des Tages.

Ich habe auch mit dem Burst experimentiert: burstAccess auf auto und burstRx auf on. Ich merke hier keine Änderung. getConfig wird erst beim Betätigen der Taste oder erst bei der nächsten Übertragung beantwortet. set burtsXmit bringt auch nichts.

Burst und "Lazy Config" funktionieren noch nicht.

Also ledMode ist schon mal toll. Bin schon gespannt, wie sehr sich das auf den Energieverbrauch auswirkt.

Ich schätze das wird gesehen auf die Gesamtlaufzeit nur ca. einen Tag ausmachen.

Habe zwar keinen Luftdruckmesser, aber bei dem Altitude-Register wäre es wohl interessant, dass dann letztendlich sowohl der gemessene Wert als auch der errechnete übertragen wird. Finde den Weg, dass FHEM sich selbst darum kümmert und die CCU das übergeben benötigt, weniger elegant.

In FHEM kann man ggf. komplexere Berechnungen durchführen. Außerdem braucht man dann wieder zwei zusätzliches Bytes in der Nachricht.
Daher soll das aktuell nur eine Hilfe für CCU-Benutzer sein.

Und was mir vorhin noch aufgefallen ist (war aber auch schon bei v0.12 so)... Ich kann die Register nur setzen, wenn ich auf die Config-Taste drücke.

Siehe oben. Lazy-Config funktioniert noch nicht.

Das hat paar sonderbare Messergebnisse gebracht:

Kannst du mal messen was bei 0,6V Batteriespannung noch aus dem Max rauskommt. Das liegt gestimmt deutlich unter 2,5V. Und dann misst der SHT schon mal Mist.
Vielleicht sollte ich den AVR veranlassen unter 0,8V Batteriespannung keine Daten mehr zu senden?

[Mr. P]

Ich schätze das wird gesehen auf die Gesamtlaufzeit nur ca. einen Tag ausmachen.

Die Hauptsache war aber auch, dass sich niemand mehr an dem blinkenden LED stört... Danke dafür.

In FHEM kann man ggf. komplexere Berechnungen durchführen. Außerdem braucht man dann wieder zwei zusätzliches Bytes in der Nachricht.
Daher soll das aktuell nur eine Hilfe für CCU-Benutzer sein.

Ist zwar nur Kosmetik, aber dann würde ich den Register vielleicht auch CCUaltitude nennen oder zumindest in der Registerbeschreibung erläutern.

Siehe oben. Lazy-Config funktioniert noch nicht.

Ok, passt.

Vielleicht sollte ich den AVR veranlassen unter 0,8V Batteriespannung keine Daten mehr zu senden?

Also wenn hexenmeister die 0,8V richtig im Kopf hat, würde das Sinn machen. Und wenn ich auch nicht betroffen bin, aber wie sieht es dann bei den Max-losen Boards aus? Kann man die auch berücksichtigen bzw. den Grenzwert wieder konfigurierbar machen?