Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[plombe]

Hallo papa,

du weisst hoffentlich, dass die alte Version 0.15 nur aufgrund eines Fehlers funktioniert. In der Register.h waren gegenüber der vorherigen Versionen 4 Register hinzugefügt worden. Aber die Adressen wurden nicht angepasst, so dass beim Auslesen des Wertes für peerNeedsBurst stattdessen der Wert für lowBatLimit genommen und daher immer mit Burst gesendet wird. Daher funktioniert diese Version. Korrigiert man dies, funktioniert nichts mehr.

Code Auswählen Erweitern


-89 { 1,   4,   6,        0x05, 1,    0x0005, 0x0000, (void*)&regs.ch1.l4}, // List 4
+89 { 1,   4,   6,        0x00, 1,    0x0009, 0x0000, (void*)&regs.ch1.l4}, // List 4

-103 {   0x0000, 0x0002, 0x001a, 0x0025, }, // start address
-104 {   0x0002, 0x0030, 0x000b, 0x0000, }, // length

+103 {   0x0000, 0x0002, 0x0020, 0x0032, }, // start address
+104 {   0x0002, 0x001e, 0x0012, 0x0000, }, // length



H.G.

[papa]

Nein - das wusste ich nicht. Aber ich würde es gern mit der AskSin++ hinkriegen. Die originalen Sensoren können es ja auch.

[Tom Major]

In diesem Zusammenhang frage ich mich wo die Formel herstammt - empirisch ermittelt oder eine originale Firmware reversed?

Code Auswählen Erweitern


  // here we calc when to send next value
  uint32_t delay (const HMID& id,uint8_t msgcnt) {
    uint32_t value = ((uint32_t)id) << 8 | msgcnt;
    value = (value * 1103515245 + 12345) >> 16;
    value = (value & 0xFF) + 480;
    value *= 250;


[Tom Major]

Der erste Teil ist ein Pseudo-Zufallsgenerator (Parameter 1103515245 und 12345)
http://pubs.opengroup.org/onlinepubs/009695399/functions/rand.html

[frank]

In diesem Zusammenhang frage ich mich wo die Formel herstammt - empirisch ermittelt oder eine originale Firmware reversed?

Code Auswählen Erweitern


  // here we calc when to send next value
  uint32_t delay (const HMID& id,uint8_t msgcnt) {
    uint32_t value = ((uint32_t)id) << 8 | msgcnt;
    value = (value * 1103515245 + 12345) >> 16;
    value = (value & 0xFF) + 480;
    value *= 250;


der ursprung müsste hier liegen:
https://forum.fhem.de/index.php/topic,18193.msg120907.html#msg120907

[Tom Major]

der ursprung müsste hier liegen:
https://forum.fhem.de/index.php/topic,18193.msg120907.html#msg120907

Sehr interessante Info in dem Link, Danke.
250ms Zeitfenster ist nicht viel.
RTC/Uhrenquarz ist sicher ein Muss bei dieser Art Anwendung.

[frank]

250ms-fenster gilt wohl nur beim vd. tc und vd können sich auch synchronisieren.

bei gepeerten tempfühlern gibt es noch unterschiede mit dem fenster. siehe zb hier:
https://forum.fhem.de/index.php/topic,45735.msg568831.html#msg568831

[plombe]

Damals hatte ich meine Sensoren erstmal ohne Schlafzustand mit dem HM-CC-RT-DN gepeert und ein Ack bei jedem Telegramm angefordert (A2). An einem Kontrollpin habe ich die echten Sendezeiten gemessen. Dadurch sah ich, wo korrigiert werden mußte.
Ich hatte in die Sensoren 8 MHz Quarze eingesetzt, aber jetzt in der Versuchsschaltung gesehen, daß die Resonatoren hinreichend genau sind. Es geht ja nur um 2,5 bis 3 Minuten.
Unter Berücksichtigung eines Korrekturwertes (errechneter Wert:gemessener Wert 0.9963) bei der Sendezeitberechnung ist die Übertragung der Versuchsschaltung hinreichend stabil, auch wenn manchmal kein Ack kommt. Der HM-CC-RT-DN vergrößert ja dann sein Empfangsfenster und empfängt bei der nächsten Übertragung wieder.
Das ist dann also mehr ein Ausprobieren gewesen.
Überraschenderweise passte der Korrekturwert bei allen Sensoren.
Eine genaue Zeit mit dem Watchdog zu erreichen, hatte ich mal beschrieben. Das funktioniert auch, wenn ich den Sensor in den Tiefkühler lege.
Da ich ja kein Programmierer bin, kann ich das leider bei der AskSin++ nicht umsetzen.

H.G.

[papa]

250ms-fenster gilt wohl nur beim vd. tc und vd können sich auch synchronisieren.

bei gepeerten tempfühlern gibt es noch unterschiede mit dem fenster. siehe zb hier:
https://forum.fhem.de/index.php/topic,45735.msg568831.html#msg568831

Ich habe jetzt auch einfach mal eine Sekunde extra Wartezeit eingebaut. Das sieht mit meinen Testthermostat jetzt ganz gut aus. Seit gut einer Stunde keine Aussetzer mehr. Wer es selber ausprobieren möchte - das ganze ist im asynch-Branch eingecheckt.

[papa]

Leider hatte ich heute nach 3 Aussetzer. Habe jetzt mal auf 1,5 Sekunden erhöht.

[Gernott]

Leider hatte ich heute nach 3 Aussetzer. Habe jetzt mal auf 1,5 Sekunden erhöht.

Habe mutig auf 2 s erhöht, setzt aber auch aus. 1 s ging auch nicht, 1.5 s hatte ich übersprungen.

[papa]

1,5 war auch Mist. Bin jetzt auf 750ms. Mal sehen wie es üner Nacht aussieht. Hoffentlich gibt es da nicht noch ein anderes Problem.

[Gernott]

1,5 war auch Mist. Bin jetzt auf 750ms. Mal sehen wie es üner Nacht aussieht. Hoffentlich gibt es da nicht noch ein anderes Problem.

Ich probiere gerade mal 500 ms. In der Peerlist stehen jetzt jedesmal (unpeering, neue FW, peering) zwei unbekannte IDs, die sich nur mittels peerBulk entfernen lassen. Ist das normal?

[papa]

Nein, sollte nicht sein. Aber Du kannst einfach die neue FW draufmachen ohne die Peering zu löschen.

[Spezialtrick]

Ich habe mich nach langer Zeit auch mal wieder an einen Asksinpp Eigenbausensor begeben und komme leider an einer Stelle in der Arduino IDE nicht weiter. Ich versuche den aktuellen HB-UNI-Sensor1 von TomMajor zu kompilieren und erhalte die nachfolgende Fehlermeldung, wenn ich

Code Auswählen Erweitern

#define NDEBUG

auskommentieren:

Code Auswählen Erweitern

C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.21.0_x86__mdqgnx93n4wtt\hardware\arduino\avr\cores\arduino\Print.h: In function 'write.constprop':

C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.21.0_x86__mdqgnx93n4wtt\hardware\arduino\avr\cores\arduino\Print.h:55:5: internal compiler error: Segmentation fault

     }

     ^

Please submit a full bug report,

with preprocessed source if appropriate.

See <http://gcc.gnu.org/bugs.html> for instructions.

lto-wrapper.exe: fatal error: C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.21.0_x86__mdqgnx93n4wtt\hardware\tools\avr/bin/avr-gcc returned 1 exit status

compilation terminated.

c:/program files/windowsapps/arduinollc.arduinoide_1.8.21.0_x86__mdqgnx93n4wtt/hardware/tools/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld.exe: error: lto-wrapper failed

collect2.exe: error: ld returned 1 exit status

exit status 1
Fehler beim Kompilieren für das Board Arduino Pro or Pro Mini.


Wenn ich

Code Auswählen Erweitern

#define NDEBUG

einkommentiere, läuft das Kompilieren ohne Probleme durch und der Sketch wird übertragen. Allerdings kann ich dem Sensor keine Ausgabe über den Serial Monitor entlocken, obwohl das Debugging ja offensichtlich eingeschaltet ist. Pairing mit Fhem und Übertragung von Werten läuft hingegen ohne Auffälligkeiten.

Mit demFreqTest Sketch werden ohne Probleme Meldungen auf den Serial Monitor ausgegeben. An dem Sensor selbst und an dem verwendeten Ftdi Adapter liegt es also offenbar nicht.

Hat jemand eine Idee wo mein Fehler liegt?