Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

Begonnen von trilu, 23 Februar 2014, 12:23:22

Vorheriges Thema - Nächstes Thema

moonsorrox

Zitat von: frank am 28 Januar 2015, 13:55:32
rausnehmen bevor sie tot sind. darum 1.5 monate. du warst 2 wochen zu spät.
mmh OK  ;)

aber ich hoffe das ändert sich mit einer neueren Firmware, denn ich wollte das Ding ja mal an seinem Platz festschrauben, sonst brauche ich jedes mal ne Leiter  :-\
Intel-NUC i5: FHEM-Server 6.1 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

Mr. P

Zitat von: frank am 28 Januar 2015, 13:55:32
rausnehmen bevor sie tot sind. darum 1.5 monate. du warst 2 wochen zu spät.
Genau. ;-)

Wenn du dich natürlich per Mail, SMS, usw. über schwache Batterien deiner Komponenten informieren lässt, kannst du auch noch reagieren und sie schnell raus und wieder hinein geben. Aber das sollte dann binnen 1-2 Stunden nach der Info geschehen, bevor die Batterien ganz leer gesaugt sind.
Greetz,
   Mr. P

frank

#1427
hier mal eine schöne batterie-selbstheilung, ohne rausnehmen der batterie. sehr schön erkennt man auch, dass sofort mit beginn des spgs-abfalls (kurz vor 8.00) temp und feuchte zu vergessen sind. die kurven machen quasi den batterie-kurvenverlauf mit. jetzt ist auch das erste mal eine bat=low meldung gekommen. der schwarze peak unten bei 1.0 volt.

der heilungsbeginn könnte mit dem ausbleiben des lichtwertes (0) zusammenhängen.

(http://forum.fhem.de/index.php?action=dlattach;topic=20620.0;attach=26813;image)

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Inputsammler

Hallo Frank
Ist ziemlich heiß bei dir :-)
Fast 1000 Grad Celsius

Gruß Gerd
Rpi's und Bpi's und Hw von Dirk und locutus
CCU2,F20,Ks300,1-Wire,Homematic usw ...
vitodens 300 & IstrkrM372 auslesen über USB und FHEM
RUHE IN FRIEDEN AHA1805 RIP Mallorca +29.08.16
I miss you and your Family H.H.L.L.

Inputsammler

Hallo Frank
Ist ziemlich heiß bei dir :-)
Fast 1000 Grad Celsius

Gruß Gerd
Rpi's und Bpi's und Hw von Dirk und locutus
CCU2,F20,Ks300,1-Wire,Homematic usw ...
vitodens 300 & IstrkrM372 auslesen über USB und FHEM
RUHE IN FRIEDEN AHA1805 RIP Mallorca +29.08.16
I miss you and your Family H.H.L.L.

knochenmuehle

Hallo,
gibt's eigentlich schon was neues bzgl Firmware ohne Batterie Bug?

Gruß
Andreas

bjoernh

Hallo,

ich habe mir jetzt auch mal einen solchen Sensor gebaut.
Dann habe ich die Firmware (Hex) geflasht. Soweit schein es zu funktionieren.

Wenn ich nun einen zweiten baue habe, dann habe ich das Problem, dass die Adresse ja schon vergeben ist.
Wie ändert man via Fhem von so einem Sensor die Adresse, so dass man mehrere betreiben kann?
Muss ich dazu den Code selbst kompilieren?

Gruß
Björn

hexenmeister

Zitat von: bjoernh am 08 Februar 2015, 19:39:23
Muss ich dazu den Code selbst kompilieren?
Nicht unbedingt. Von Dirk gibt es ein Flash-Script, wo man eine eigene Adresse angeben kann. Ist (glaube ich) im Wiki beschrieben.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

bjoernh

Zitat von: hexenmeister am 08 Februar 2015, 19:45:38
Nicht unbedingt. Von Dirk gibt es ein Flash-Script, wo man eine eigene Adresse angeben kann. Ist (glaube ich) im Wiki beschrieben.
Mhh, ok. ich finde das Flash-Skript leider nicht. Weder im github noch im Wiki ist etwas zu finden. Im Wiki steht zwar, dass es eines gibt, aber wo ist die große Frage.

vbs

Man mag mich korrigieren, aber wenn ich mich recht erinnere, ist das Flash-Skript nicht im master enthalten im Moment. Sollte aber noch in einem anderen Branch/Tag zu finden sein.

bjoernh

Zitat von: vbs am 08 Februar 2015, 20:21:16
Man mag mich korrigieren, aber wenn ich mich recht erinnere, ist das Flash-Skript nicht im master enthalten im Moment. Sollte aber noch in einem anderen Branch/Tag zu finden sein.

Hab's gefunden, danke. Es ist im Tag v0.10 enthalten.

hglaser

Hallo

Zitatrausnehmen bevor sie tot sind. darum 1.5 monate. du warst 2 wochen zu spät.
Mist. Jetzt hab ich's auch übersehn und tot ist er seit zwei Tagen.
Könnte es sein, daß es ein Pufferüberlauf von den millis() Aufrufen in Sensor_SHT10_BMP085_TSL2561.cpp ist? Dieser Timer läuft ja ca 50 Tage und fängt dann wieder bei 0 an. 50 Tage würden ja passen.
http://www.forward.com.au/pfod/ArduinoProgramming/TimingDelaysInArduino.html

Grüße Harald

Dirk

Hallo Zusammen.

ich will mal wieder ein kleines "Lebenszeichen" senden.

Zitat von: knochenmuehle am 08 Februar 2015, 19:38:42
Hallo,
gibt's eigentlich schon was neues bzgl Firmware ohne Batterie Bug?
Da bin ich dran.
Wird aber noch etwas dauern.

Zitat von: bjoernh am 08 Februar 2015, 20:05:41
Mhh, ok. ich finde das Flash-Skript leider nicht. Weder im github noch im Wiki ist etwas zu finden. Im Wiki steht zwar, dass es eines gibt, aber wo ist die große Frage.
Der Bootloader ist inzwischen ein eigenes Projekt.
Das Flashtool dafür ist hier:
https://github.com/jabdoa2/Asksin_OTA_Bootloader/tree/master/Tools/Flash-Tool-Windows

Viele Grüße
Dirk

MarcelK

Zitat von: honk am 10 Februar 2015, 23:34:01
Könnte es sein, daß es ein Pufferüberlauf von den millis() Aufrufen in Sensor_SHT10_BMP085_TSL2561.cpp ist? Dieser Timer läuft ja ca 50 Tage und fängt dann wieder bei 0 an. 50 Tage würden ja passen.

Ich hab mir eben mal den AskSin Code angeschaut und da haben leider so ziemlich alle Zeit-Vergleiche ein Problem. Einen Timer wie millis() darf man nur mit Differenzen benutzen, dann heben sich die Fehler bei einem Überlauf auf. Wilkürliches Beispiel aus AskSinMain.cpp:

if((send.counter <= send.retries) && (send.timer <= mils)) { // not all sends done and timing is OK
[...]
    send.timer = mils + dParm.timeOut;
}


Angenommen
Mils = 0xffffff00
dParm.timeOut = 0x200

Dann ist send.timer beim nächsten Durchlauf 0x00000100 und damit jetzt schon kleiner Mils obwohl das erst in 200ms sein sollte! Man müsste den Vergleich jetzt z.B. so umschreiben:

if ((send.counter <= send.retries) && ((long)(mils - send.timer) >= 0) {
[...]
    send.timer = mils + dParm.timeOut;
}


Mit obigen Werten rechnet sich dass dann so:
mils         send.timer   Ergebnis
0xffffff00 - 0x00000100 = 0xFFFFFE00  Korrekt < 0
0x00000000 - 0x00000100 = 0xFFFFFF00  Korrekt < 0
0x00000100 - 0x00000100 = 0x00000000  Korrekt == 0
0x00000101 - 0x00000100 = 0x00000001  Korrekt > 0


Aber ganz ehrlich, da krieg teilweise selbst ich ein Knoten im Hirn und ich bin seit 20 Jahren hauptberuflich Bit-Schupser. Und so genau müsste man jede einzelne Stelle dann betrachten. Sollte es keine akute Platz-Probleme im Flash geben (weiß ich gerade nicht) würde ich eher einfach auf 64-bit Arithmetik gehen, die Umstellung lässt sich recht trivial machen und ist dann für 200 Billionen Jahre oder so sicher ;-)

Dirk

Zitat von: MarcelK am 11 Februar 2015, 23:01:37
Ich hab mir eben mal den AskSin Code angeschaut und da haben leider so ziemlich alle Zeit-Vergleiche ein Problem. Einen Timer wie millis() darf man nur mit Differenzen benutzen, dann heben sich die Fehler bei einem Überlauf auf. Wilkürliches Beispiel aus AskSinMain.cpp:
Ja, das hat Trillu in der neuen Lib auch korrigiert.
Und daher mirgiere ich die FW grade auch auf die neue Lib.

Wobei als schnellen Workaround hatte ich schon überlegt den Sensor nach x Tagen einfach einfach per Watchdog zu resetten.
Nicht schön. Aber würde erst mal helfen.

Nein. war nur so eine Idee.

Gruß
Dirk