Closed LineF closed 1 year ago
TomMajor
commented
1 year ago Liegt evtl. an der Ungenauigkeit der Watchdog Frequenz, der WD ist beim Sleep für das Timing zuständig, nicht der 8 MHz Quartz. Ausnahme: Sleeps timing mit 32kHz Uhrenquarz anstatt WD (RTC mode in AskSinPP) WD Ungenauigkeits Test siehe auch https://github.com/TomMajor/SmartHome/tree/master/Info/WDT_Frequenz
LineF
commented
1 year ago Ja, ich glaube, das war die Lösung. Die Korrektur hatte ich damals für den WDT in der damaligen AskSin-Lib auch eingebaut. Nach 6 Jahren war das jetzt leider nicht mehr im Kopf parat...
Vielen Dank! Martin
pa-pa
commented
1 year ago Wäre es hier nicht gut, einen Factor einstellen zu können, der dann entsprechend die Sleep-Zeiten anpasst ?
jp112sdl
commented
1 year ago Ich mache es seit jeher direkt im Sketch: https://github.com/jp112sdl/HB-UNI-Sen-LEV-US/blob/master/HB-UNI-Sen-LEV-US.ino#L50-L51 https://github.com/jp112sdl/HB-UNI-Sen-PRESS/blob/master/HB-UNI-Sen-PRESS/HB-UNI-Sen-PRESS.ino#L45-L46 https://github.com/jp112sdl/HB-UNI-Sen-TEMP-MAX6675/blob/master/HB-UNI-Sen-TEMP-MAX6675/HB-UNI-Sen-TEMP-MAX6675.ino#L35 ...
LineF
commented
1 year ago Ich habe jetzt auch den Korrekturfaktor per define eingefügt - kann ich damit über den Compiler-Befehl mit angeben (für verschiedene Sensoren). Damals hatte ich den Code so erweitert, daß der Faktor nach einer initialen 250ms-Messung automatisch bestimmt wird. Natürlich nur im Rahmen der internen Oszillator-Genauigkeit. Die hatte ich aber per OSCCAL recht gut hinbekommen. Und war jahrelang ausreichend für einen Connect mit HM-CC-RT-DN Thermostaten. Da das ein Homebrew-Device war, konnte ich den Faktor zur Laufzeit einstellen, eine Meßfrequenz auf dem LED-Port ausgeben und so recht komfortabel das Device einstellen. Jetzt bleibe ich lieber beim AskSinPP-Standard - solche Erweiterungen sind recht zeitintensiv zu pflegen...
Hallo, vor 6 Jahren hatte ich mir Temperatursensoren gebaut und damals mit der Software von Trilu (AskSin) versehen. Die hatte ich mit ihm auch etwas fehlerbereinigt. Sie liefen bislang mit fhem sehr gut, allerdings steige ich derzeit auf die CCU um und nun gibt es teilweise Probleme im Protokoll. Deshalb wechsle ich jetzt bei der Sensor-Firmware auf AskSinPP.
Prinzipiell läuft der Sensor (Vorlage HM-WDS40-TH-I, der aktuelle Sensor ohne RTC, DHT22 und DS18B20 Sensoren drauf). Die Erweiterung, zwei Sensoren auszulesen und diese auch Powerseitig ein-/auszuschalten funktioniert.
Nun habe ich aber das Problem, daß die Timings ca. 10% zu lange laufen. D.h. die Schleife, die in der Klasse WeatherChannel mit trigger und reactivate gebildet wird, läuft 10% zu lange. Ich habe die beiden Prozeduren mal auf eine Debug-Ausgabe und ein CLOCKTYPE::instance().add(*this,15000); reduziert - läuft ca. 16,5 Sek.
Woran könnte das liegen? Der Atmega328p läuft ziemlich exakt mit 8 MHz - extra per OSCCAL-Register nachjustiert und Frequenz nachgemessen. Beim Debugging der ganzen Alarmklassen tue ich mir noch recht schwer...
Viele Grüße, Martin