Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Tom Major]

Dirk hatte damals bei seinem Sensor, von denen ich hier einige laufen habe, mit der Asksin-FW 0.15 eine stabile Synchronisation erreicht. Ich habe aber keine Ahnung, was er da gegenüber der 0.14 geändert hat.

habe mir das gerade mal bei Dirk angeschaut, du meinst eventuell diese issue?
"Pairing with thermostat goes often lost"
https://github.com/kc-GitHub/Wettersensor/issues/16

Hat er am 9.8.2015 markiert als gefixt und geschlossen.

Jetzt kommt das merkwürdige, er hat am 9.8. zwar 11x das readme geändert aber kein Stück Code wenn ich das richtig sehe.
Auch in dem Zeitraum vorher/nachher sehe ich keine Codeänderung die zur Issue passt.
https://github.com/kc-GitHub/Wettersensor/commits/master

[papa]

Ich habe im Master mal die Reihenfolge zwischen Messen/Senden und Reaktivieren des Alarms getauscht. Probier mal bitte aus, ob das jetzt besser ist.

[plombe]

Hallo,
in der Version 0.15 in der AskSinMain.cpp steht im Kommentar

// AES will be ignored at the moment, but burst needed will be translated into the message flag - bit 0 in regLstByte, translated to bit 4 = burst transmission in msgFlag

das heisst ja, dass immer mit Burst gesendet wird. Das funktioniert dann auch mit den Thermostaten. Das ist zwar nicht die eigendlich gewünschte Funktion mit exakter Zeitmessung und erhöht den Stromverbrauch bei allen auf Burst reagierenden Empfängern - aber es funktioniert.

[Tom Major]

Hallo,
in der Version 0.15 in der AskSinMain.cpp steht im Kommentardas heisst ja, dass immer mit Burst gesendet wird. Das funktioniert dann auch mit den Thermostaten. Das ist zwar nicht die eigendlich gewünschte Funktion mit exakter Zeitmessung und erhöht den Stromverbrauch bei allen auf Burst reagierenden Empfängern - aber es funktioniert.

eventuell wird bei Dirk nicht immer Burst gesendet, sondern es ist konfigurierbar, siehe dieses hier 2 Zeilen vor deinem Zitat:

// now we need the respective list4 to know if we have to send a burst message

Und in seinem FHEM und CCU config file gibt es ein burstRx register true/false zum Konfigurieren in List0.
Eventuell war das sein Fix für die "Pairing with thermostat goes often lost" issue.
imho nicht erstrebenswert weil es den DC ziemlich erhöhen wird...

[plombe]

@Tom Major
Leider war Burst fest eingestellt und nicht konfigurierbar. Ich habe mal gekramt und so sah mein Sensor 2016 aus:

Code Auswählen Erweitern


Starting sketch...
freeMem: 1246 byte
Device type from PROGMEM: F1 01
Serial from PROGMEM: 55 57 53 37 34 37 35 31 33 34
Address from PROGMEM: EA D5 C7
powerMode: 3
Config changed. Data:  (L:0)
lowBatLimit: 16
ledMode: 0
burstRx: 0
transmDevTryMax: 3

content of dDef for 2 elements
cnl:0, lst:0, pMax:0
idx:0, len:9, addr:0
regs: 01 05 0A 0B 0C 12 14 24 25
data: 00 24 F1 00 11 10 03 00 00

cnl:1, lst:4, pMax:6
idx:5, len:1, addr:5
regs: 12
data: 10 03 00 00 00 00
45 12 19 01   00 00 00 00   00 00 00 00   00 00 00 00   00 00 00 00   00 00 00 00   


Slot=647 (161), dst=163205, nTime=162169(419), cnt=0 (1038)
counter=1, mills=1132, startMillis=0, timer=0
burst
<- 14 00 B2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1521)
-> 0A 00 80 02 45 12 19 EA D5 C7 00 (1640)
Slot=590 (147), dst=311265, nTime=147919(419), cnt=1 (163350)
counter=1, mills=163443, startMillis=1132, timer=0
<- 14 01 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (163451)
-> 0A 01 80 02 45 12 19 EA D5 C7 00 (163594)
Slot=532 (133), dst=444687, nTime=133409(409), cnt=2 (311281)
counter=1, mills=311375, startMillis=163443, timer=0
<- 14 02 A2 70 EA D5 C7 45 12 19 00 F5 35 00 00 00 00 00 00 0D 48 (311383)
-> 0A 02 80 02 45 12 19 EA D5 C7 00 (311526)
Slot=730 (182), dst=627601, nTime=182909(409), cnt=3 (444696)
counter=1, mills=444789, startMillis=311375, timer=0
<- 14 03 A2 70 EA D5 C7 45 12 19 00 F5 35 00 00 00 00 00 00 0D 48 (444799)
-> 0A 03 80 02 45 12 19 EA D5 C7 00 (444940)
Slot=673 (168), dst=796300, nTime=168669(419), cnt=4 (627633)
counter=1, mills=627727, startMillis=444789, timer=0
<- 14 04 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (627735)
-> 0A 04 80 02 45 12 19 EA D5 C7 00 (627878)
Slot=615 (153), dst=950470, nTime=154169(419), cnt=5 (796305)
counter=1, mills=796397, startMillis=627727, timer=0
<- 14 05 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (796408)
-> 0A 05 80 02 45 12 19 EA D5 C7 00 (796549)
Slot=557 (139), dst=1090384, nTime=139669(419), cnt=6 (950717)
counter=1, mills=950811, startMillis=796397, timer=0
<- 14 06 A2 70 EA D5 C7 45 12 19 00 F4 37 00 00 00 00 00 00 0D 48 (950819)
-> 0A 06 80 02 45 12 19 EA D5 C7 00 (950962)
Slot=500 (125), dst=1216029, nTime=125419(419), cnt=7 (1090614)
counter=1, mills=1090706, startMillis=950811, timer=0
<- 14 07 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1090716)
-> 0A 07 80 02 45 12 19 EA D5 C7 00 (1090857)
Slot=698 (174), dst=1391166, nTime=174919(419), cnt=8 (1216249)
counter=1, mills=1216344, startMillis=1090706, timer=0
<- 14 08 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1216354)
-> 0A 08 80 02 45 12 19 EA D5 C7 00 (1216495)
Slot=640 (160), dst=1551820, nTime=160419(419), cnt=9 (1391405)
counter=1, mills=1391497, startMillis=1216344, timer=0
<- 14 09 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1391508)
-> 0A 09 80 02 45 12 19 EA D5 C7 00 (1391649)



Wenn man die berechneten Zeiten(dst) mit den Sendezeiten sieht, läuft das auseinander. Ohne Burst würde das so nicht gehen.

[Gernott]

Ich habe im Master mal die Reihenfolge zwischen Messen/Senden und Reaktivieren des Alarms getauscht. Probier mal bitte aus, ob das jetzt besser ist.

Muss dann die msgcnt-Zeile auch mit hoch?

Code Auswählen Erweitern

else {
      // reactivate for next measure
      uint8_t msgcnt = device().nextcount();
      HMID id;
      device().getDeviceID(id);
      uint32_t nextsend = delay(id,msgcnt);
      tick = nextsend / 1000; // seconds to wait
      millis = nextsend % 1000; // millis to wait
      rtc.add(*this);


Sonst meckert der  Compiler.

[papa]

Da hast Du natürlich Recht

[Tom Major]

@Tom Major
Leider war Burst fest eingestellt und nicht konfigurierbar. Ich habe mal gekramt und so sah mein Sensor 2016 aus:

Code Auswählen Erweitern


Starting sketch...
freeMem: 1246 byte
Device type from PROGMEM: F1 01
Serial from PROGMEM: 55 57 53 37 34 37 35 31 33 34
Address from PROGMEM: EA D5 C7
powerMode: 3
Config changed. Data:  (L:0)
lowBatLimit: 16
ledMode: 0
burstRx: 0
transmDevTryMax: 3

content of dDef for 2 elements
cnl:0, lst:0, pMax:0
idx:0, len:9, addr:0
regs: 01 05 0A 0B 0C 12 14 24 25
data: 00 24 F1 00 11 10 03 00 00

cnl:1, lst:4, pMax:6
idx:5, len:1, addr:5
regs: 12
data: 10 03 00 00 00 00
45 12 19 01   00 00 00 00   00 00 00 00   00 00 00 00   00 00 00 00   00 00 00 00   


Slot=647 (161), dst=163205, nTime=162169(419), cnt=0 (1038)
counter=1, mills=1132, startMillis=0, timer=0
burst
<- 14 00 B2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1521)
-> 0A 00 80 02 45 12 19 EA D5 C7 00 (1640)
Slot=590 (147), dst=311265, nTime=147919(419), cnt=1 (163350)
counter=1, mills=163443, startMillis=1132, timer=0
<- 14 01 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (163451)
-> 0A 01 80 02 45 12 19 EA D5 C7 00 (163594)
Slot=532 (133), dst=444687, nTime=133409(409), cnt=2 (311281)
counter=1, mills=311375, startMillis=163443, timer=0
<- 14 02 A2 70 EA D5 C7 45 12 19 00 F5 35 00 00 00 00 00 00 0D 48 (311383)
-> 0A 02 80 02 45 12 19 EA D5 C7 00 (311526)
Slot=730 (182), dst=627601, nTime=182909(409), cnt=3 (444696)
counter=1, mills=444789, startMillis=311375, timer=0
<- 14 03 A2 70 EA D5 C7 45 12 19 00 F5 35 00 00 00 00 00 00 0D 48 (444799)
-> 0A 03 80 02 45 12 19 EA D5 C7 00 (444940)
Slot=673 (168), dst=796300, nTime=168669(419), cnt=4 (627633)
counter=1, mills=627727, startMillis=444789, timer=0
<- 14 04 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (627735)
-> 0A 04 80 02 45 12 19 EA D5 C7 00 (627878)
Slot=615 (153), dst=950470, nTime=154169(419), cnt=5 (796305)
counter=1, mills=796397, startMillis=627727, timer=0
<- 14 05 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (796408)
-> 0A 05 80 02 45 12 19 EA D5 C7 00 (796549)
Slot=557 (139), dst=1090384, nTime=139669(419), cnt=6 (950717)
counter=1, mills=950811, startMillis=796397, timer=0
<- 14 06 A2 70 EA D5 C7 45 12 19 00 F4 37 00 00 00 00 00 00 0D 48 (950819)
-> 0A 06 80 02 45 12 19 EA D5 C7 00 (950962)
Slot=500 (125), dst=1216029, nTime=125419(419), cnt=7 (1090614)
counter=1, mills=1090706, startMillis=950811, timer=0
<- 14 07 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1090716)
-> 0A 07 80 02 45 12 19 EA D5 C7 00 (1090857)
Slot=698 (174), dst=1391166, nTime=174919(419), cnt=8 (1216249)
counter=1, mills=1216344, startMillis=1090706, timer=0
<- 14 08 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1216354)
-> 0A 08 80 02 45 12 19 EA D5 C7 00 (1216495)
Slot=640 (160), dst=1551820, nTime=160419(419), cnt=9 (1391405)
counter=1, mills=1391497, startMillis=1216344, timer=0
<- 14 09 A2 70 EA D5 C7 45 12 19 00 F4 35 00 00 00 00 00 00 0D 48 (1391508)
-> 0A 09 80 02 45 12 19 EA D5 C7 00 (1391649)



Wenn man die berechneten Zeiten(dst) mit den Sendezeiten sieht, läuft das auseinander. Ohne Burst würde das so nicht gehen.

Bin jetzt nicht in allen Details drin, aber wäre es nicht so dass man 'burstRx' auf 0/1 konfigurieren kann?
Wenn die Zeiten auseinanderlaufen wäre es interessant wie sich ein originaler HM-WDS10-TH-O oder das Wandthermostat diesbezüglich verhalten, dass sie stabile Verbindung zum HK-Teil hinbekommen - auch immer Burst oder stabilere Zeitbasis oder stimmt die Formel für die Sendezeit bei den Homebrew Geräten noch nicht exakt?

[plombe]

@Tom Major
Nach dem Verändern der Software sieht seitdem mein Sensor so aus

Code Auswählen Erweitern


Starting sketch...
freeMem: 1229 byte
Device type from PROGMEM: F1 01
Serial from PROGMEM: 55 57 53 37 34 37 35 31 33 37
Address from PROGMEM: ED D8 CA
MAID: F1 00 11
PEER: 45 12 19
powerMode: 3
Config changed. Data:  (L:0)
lowBatLimit: 16
ledMode: 0
burstRx: 0
peerNeedsBurst: 0
expectAES: 0
transmDevTryMax: 3
Slot=698 (174), dst=175538, nTime=174400(-100), cnt=0 (1140)
<- 14 00 86 70 ED D8 CA 00 00 00 01 0C 2F 00 00 00 00 00 00 0A 8C (1155)
Slot=640 (160), dst=335538, nTime=159900(-100), cnt=1 (175640)
<- 14 01 86 70 ED D8 CA 00 00 00 01 08 2F 00 00 00 00 00 00 0A F0 (175656)
Slot=582 (145), dst=481039, nTime=145400(-100), cnt=2 (335641)
<- 14 02 86 70 ED D8 CA 00 00 00 01 06 30 00 00 00 00 00 00 0A F0 (335658)
Slot=525 (131), dst=612290, nTime=131150(-100), cnt=3 (481142)
<- 14 03 86 70 ED D8 CA 00 00 00 01 06 30 00 00 00 00 00 00 0A F0 (481158)
Slot=723 (180), dst=793360, nTime=180650(-100), cnt=4 (612712)
<- 14 04 86 70 ED D8 CA 00 00 00 01 06 31 00 00 00 00 00 00 0A F0 (612728)
Slot=665 (166), dst=959930, nTime=166150(-100), cnt=5 (793782)
<- 14 05 86 70 ED D8 CA 00 00 00 01 06 31 00 00 00 00 00 00 0A F0 (793798)
Slot=608 (152), dst=1112249, nTime=151900(-100), cnt=6 (960351)
<- 14 06 86 70 ED D8 CA 00 00 00 01 07 30 00 00 00 00 00 00 0A F0 (960368)
Slot=550 (137), dst=1250069, nTime=137400(-100), cnt=7 (1112671)
<- 14 07 86 70 ED D8 CA 00 00 00 01 07 30 00 00 00 00 00 00 0A F0 (1112688)

Gesendet wird an 00 00 00(Broadcast), es wird kein Ack angefordert.
So laufen 6 Sensoren seit Ende 2016 und haben nie die Verbindung zu den HM-CC-RT-DN verloren.

[Gernott]

Ich habe im Master mal die Reihenfolge zwischen Messen/Senden und Reaktivieren des Alarms getauscht. Probier mal bitte aus, ob das jetzt besser ist.

Nein leider nicht, siehe Plot. Zum Test habe ich noch einen originalen Homematic-Aussensensor mit dem Heizkörperregler gepeert. Der Aussensensor ist ziemlich zickig und meldete sich nach dem peerChan erstmal nicht mehr. Leiter, Batterie raus und rein, dann  mochte er wieder. Zuerst kam keine Übertragung zustande, dann habe ich den Aktor neu gestartet und es lief ab da ohne Aussetzer.

Ich habe mal nach dem Start für einige Minuten aus dem seriellen Log die Anzahl bis zum ACK:01 und die vorhergehenden Pausenzeiten als Trend für beide Varianten aufgetragen. Interpretieren kann ich es nicht. Zumindest war in dem beobachteten Zeitraum bei Deiner modifizierten Variante sogar mehr Sendeversuche bis zum ACK nötig als vorher. Es kam aber nicht zur Unterbrechung der Übertragung beim Aktor.

@plombe:
Was hast Du denn an der Firmware für den Dirk-Sensor modifiziert? Würdest Du die Firmware zur Verfügung stellen?

[papa]

Mist - habe ich wieder zurück gebaut. Verwende nun eine andere Methode zum Senden. Diese erwaret keine Antwort des Peers. Kannst Du das mal bitte probieren ?
Welchen Sensor nimmst Du zum Testen ? Vielleicht dauert der measure() Aufruf auch zu lange.

[Gernott]

Mist - habe ich wieder zurück gebaut. Verwende nun eine andere Methode zum Senden. Diese erwaret keine Antwort des Peers. Kannst Du das mal bitte probieren ?
Welchen Sensor nimmst Du zum Testen ? Vielleicht dauert der measure() Aufruf auch zu lange.

Ich verwende einen SHT31. Habe mal mit micros() die Zeit für measure() ermittelt, waren etwas über 40 ms.
Ich werde die Tage mal Deine neue Version testen.

[Gernott]

Die letzte Version arbeitet leider auch nicht stabil.

[papa]

Das sieht ja noch schlechter aus als vorher. Es gibt noch eine Ungenauigkeit - die RTC zählt ja immer nur in ganzen Sekunden. Dadurch kann eine Ungenauigkeit von fast einer ganzen Sekunde in die Berechnung des nächsten Sendeslot auftreten - nämlich genau dann, wenn direkt nach dem Aktivieren des nächsten Alarm die Sekunde bei der RTC vorbei ist. Das muss ich die Tage mal noch fixen. Sonst fällt mir dann auch langsam nichts mehr ein.

[papa]

@Gernott Kannst Du bitte mal die Version aus dem asynch Branch testen. Dazu musst Du aber auch die Lib aus diesem Branch nehmen.