Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.43

noansi · 24 April 2020, 22:13:01

Hallo Peter,

~~einer war drin und es ist auch was eingesammelt worden (21:47:51).~~ Doch nicht...
Da drüber muss ich dann mal grübeln.

Wär nicht schlecht, wenn Du noch etwas mehr einfangen könntest.

Gruß, Ansgar.

pantau · 24 April 2020, 22:31:08

Aber was war hiermit:
2020.04.24 21:46:01 4: TSCUL_Parse: CUBe868SL H2E6F01750100E6 -87
2020.04.24 21:46:01 4: TSCUL_Parse: CUL_0 raw SlowRf:
Der Sensor wurde vom CUBe empfangen und steht 2m vom CUL_0, sagst Du der CUL_0 hat nichts empfangen?
Kann es an der letzten Firmware liegen?
Ich hatte an der Konstellation nichts geändert und es war mit sens 8.
Ich kann es gerne wiederholen, aber gib mir mal einen Tipp woran ich erkenne das der CUL_0 was für Dich hilfreiches empfängt, dann sparen wir uns das erstellen von Logs ohne hilfreichen Inhalt.
Gruß

Peter

noansi · 24 April 2020, 22:44:21

Hallo Peter,

ZitatAber was war hiermit:
2020.04.24 21:46:01 4: TSCUL_Parse: CUBe868SL H2E6F01750100E6 -87
2020.04.24 21:46:01 4: TSCUL_Parse: CUL_0 raw SlowRf:

CUL_0 hat den aber nicht empfangen.
Das ist ein weiteres Thema, bessere Einstellungen zu finden. Z.B. ist sens 12 für KS, EM und TX3 mit der Datenrate beim die beste Einstellung.
Das ist aber anscheinend nicht so für HMS.

Aber erst mal soll das, was empfangen werden kann, was mit dem zu tun bekommen, was der CUBe empfängt.

21:47:54 ist noch was. Wieder zu früh mit Timeout ausgestiegen.

Kannst Du bitte mit der Firmware im Anhang den Test mit sens 8 und set X3D wiederholen?!

Gruß, Ansgar.

pantau · 24 April 2020, 23:11:33

Weder erwärmen, noch Batterie rein raus bringt die Sensoren spontan zum senden - mühsam ...
22:54:21 EB90
22:55:32 2E6F (da sieht es so aus, als ob der CUL_0 nichts hat, komisch beide Sensoren stehen nebeneinander)

pantau · 24 April 2020, 23:15:44

Zitat von: noansi am 24 April 2020, 22:44:21

21:47:54 ist noch was. Wieder zu früh mit Timeout ausgestiegen.

Das scheint aber ein H43xx zu sein, denk dran das sind keine echten HMS, das sind welche die über eine Emulation beim 868SL reinkommen, die kann deine FW so nicht empfangen - denke ich.
Deshalb gebe ich Dir immer die CODE an.
Im CUBe steckt noch ein CUL (CUBe868N) den ich alle 5min per set raw Nr1 auf LaCrosse Empfang umschalte. Ich habe nie verstanden warum da als IO der CUBe868SL kommt, aber hat ja funktioniert ...
43xx sind die Code dieser Sensoren.

noansi · 24 April 2020, 23:22:43

Hallo Peter,

hier ist was:
2020.04.24 22:54:21 4: TSCUL_Parse: CUL_0 P80 952 1056 1008 488 19 8 4 -68 940240029080800800 984
2020.04.24 22:54:21 4: TSCUL_Parse: CUBe868SL HEB9000650100E3 -88.5

2020.04.24 22:55:32 4: TSCUL_Parse: CUL_0 P80 1000 1024 1032 512 19 8 4 -46 4421080AA280800280 1000
2020.04.24 22:55:32 4: TSCUL_Parse: CUBe868SL H2E6F01750100E5 -87.5

und noch welche mehr, die aber der CUBe nicht empfangen hat. Immerhin hat mich der Timeout nicht mehr raus gekegelt.

Setz bitte mal attr global mseclog 1
Dann gibt es auch ms bei den Uhrzeiten und man kann viel besser sehen, ob die was miteinander zu tun haben.

Gruß, Ansgar.

pantau · 25 April 2020, 00:09:20

23:59:44
00:02:18
00:05:06
habe ich was gesehen von beiden Sensoren

noansi · 25 April 2020, 12:00:59

Hallo Peter,

kannst Du bitte mit der Firmware im Anhang den Test mit sens 8 und set X3D wiederholen?!

Außerdem dabei bitte den CUBe mit set X25 und auch auf verbose 4. (anschließend wieder zurück auf X21).

Gruß, Ansgar.

pantau · 25 April 2020, 12:41:45

Sieht gut aus!

Code Auswählen

Internals:
   CFGFN      ./sensor.cfg
   CODE       2e6f
   CUBe868SL_MSGCNT 162
   CUBe868SL_RAWMSG 810e04xx0511a0012e6f000001740100
   CUBe868SL_RSSI -89
   CUBe868SL_TIME 2020-04-25 12:39:28
   CUL_0_MSGCNT 1
   CUL_0_RAWMSG 810e04xx0511a0012e6f000001740100
   CUL_0_RSSI -46.5
   CUL_0_TIME 2020-04-25 12:39:28
   DEF        2e6f
   FUUID      5c48e3f6-f33f-d5a5-db97-e66b5ddfc9750ef4
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     162
   NAME       hms100t
   NR         887
   STATE      T: 17.4  Bat: ok
   TYPE       HMS
   READINGS:
     2020-04-22 18:29:36   ExactId         2e6f
     2020-04-25 12:39:28   battery         ok
     2020-04-25 12:39:28   batteryState    ok
     2020-04-25 12:39:28   state           T: 17.4  Bat: ok
     2020-04-25 12:39:28   temperature     17.4
     2020-04-25 12:39:28   type            HMS100T
Attributes:
   IODev      CUL_0
   alias      Vorratskeller
   comment    Keller_Vorrat
   model      hms100-t
   room       Keller
   timeout    0

LOG folgt ...

pantau · 25 April 2020, 13:16:54

Hallo Ansgar,

wie schon erwähnt hat der CUL_0 nun HMS empfangen. Jetzt sieht man auch das die Sensoren öfters senden, nur der Empfang vom CUBe868SL schlechter ist. Liegt überwiegend an der Anordnung. Ich hatte dann am CUBe868SL mal mit sens und datarate gespielt. Sollte im Log sein. Auch gleichzeitiger Empfang ist im Log, wenn auch weniger. EB90 steht etwas günstiger zw. beiden CUL.
Wenn Du denkst es macht Sinn, kann ich dann auch noch den CUNX und Pigator testen, die habe ich auch noch im Einsatz, vermute aber das Problem ist/war nicht HW abhängig?
Ich hatte auch gesehen das Du im CUL_V3.hex FHT disabled hattest, deshalb wäre ich auch an der Source interessiert, dann kann ich meine Protokolle selber einschalten.
Hat aber keine Eile. Vielen Dank!
Gruß

Peter

noansi · 25 April 2020, 16:36:29

Hallo Peter,

Zitatvermute aber das Problem ist/war nicht HW abhängig?

Richtig, das Problem saß (vor langer Zeit) vor der Tastatur.

Leider hat die Behebung das Kompilat etwas vergrößert, so dass ich bei CUL_V3 HAS_HOERMANN aus dem Standardkompilat entfernen musste, um Platz zu bekommen. Flash- und Speichergröße sind leider hardwareabhängig.

ZitatCUL_V3.hex FHT disabled hattest, deshalb wäre ich auch an der Source interessiert

Funktioniert denn FHT bei Dir? Das ist auch noch ein mangles Testobjekt ungetesteter Bereich. Im CULV3~~RFR~~ ist es aus eben Flashmangel nicht drin. Dafür muss man auf andere Protokolle verzichten.
Sourcen kommen, wenn der nächste Test auch noch erfolgreich ist. Negatives, wie positives Feedback sind erwünscht.

Kannst Du bitte mit der Firmware im Anhang den Test mit sens 8 und set X3D wiederholen?!
Und dabei bitte den CUBe mit set X25 und auch auf verbose 4.

Ich habe noch bei ESA die Sync Prüfung etwas verschärft und HMS über HAS_HMS ebenfalls für's kompilieren konfigurierbar gemacht.

Gruß, Ansgar.

pantau · 25 April 2020, 17:47:00

Zitat von: noansi am 25 April 2020, 16:36:29
Funktioniert denn FHT bei Dir? Das ist auch noch ein mangles Testobjekt ungetesteter Bereich. Im CULV3RFR ist es aus eben Flashmangel nicht drin. Dafür muss man auf andere Protokolle verzichten.

Das verstehe ich nicht. Laut der board.h vom CUL aus der FW 0.34 ist FHT in V3 nicht drin, in V3_RFR aber sehr wohl. Deshalb hatte ich neulich gefragt, ob die Sourcen zu den HEX passen... Der nakte CUL hat ja mehr Platz als der RFR und wenn FHT in RFR passt, war meine Frage, warum Du es im normalen disabled hast .
Bei FHT ist mir nichts negatives aufgefallen:

Code Auswählen

Internals:
   CFGFN      ./fht.cfg
   CODE       1e08
   CUBe868SL_MSGCNT 805
   CUBe868SL_RAWMSG 810c04xx0909a0011e080000b000
   CUBe868SL_RSSI -77
   CUBe868SL_TIME 2020-04-25 17:31:54
   CUL_0_MSGCNT 957
   CUL_0_RAWMSG 810c04xx0909a0011e080000b000
   CUL_0_RSSI -80
   CUL_0_TIME 2020-04-25 17:31:54
   DEF        1e08
   FUUID      5c48e3f7-f33f-d5a5-164e-ea42b7f65b280413
   IODev      CUBe868SL
   LASTInputDev rcul
   MSGCNT     1083
   MyRFR_MSGCNT 876
   MyRFR_RAWMSG 810c04xx0909a0011e080000b000
   MyRFR_RSSI -50.5
   MyRFR_TIME 2020-04-25 17:31:55
   NAME       wz
   NR         960
   STATE      measured-temp: 21.1
   TYPE       FHT
   rcul_MSGCNT 951
   rcul_RAWMSG 810c04xx0909a0011e080000b000
   rcul_RSSI  -76
   rcul_TIME  2020-04-25 17:31:54
   Helper:
     DBLOG:
       actuator:
         logdb:
           TIME       1587828714.05239
           VALUE      0
   READINGS:
     2020-04-25 17:31:54   actuator        0%
     2020-02-17 09:02:56   battery         ok
     2020-02-17 09:02:56   batteryState    ok
     2020-04-19 20:14:32   desired-temp    off
     2020-02-17 09:02:56   lowtemp         ok
     2020-02-17 12:43:26   measured-temp   21.1
     2019-12-20 15:14:50   mode            manual
     2020-02-17 12:43:26   state           measured-temp: 21.1
     2020-02-17 12:43:26   temperature     21.1
     2020-02-17 09:02:56   warnings        none
     2020-02-17 09:02:56   window          closed
     2020-02-17 09:02:56   windowsensor    ok
Attributes:
   DbLogInclude .*
   IODev      CUBe868SL
   fp_Erdgeschoss 350,630,2,
   minfhtbuffer 5
   retrycount 3
   room       WohnZ
   timeout    0

CUBe868SL a-culfw, CUL_0: V3_RFR (0.35), MyRFR: V3_RFR (V0.34), rcul: CUNX (tscul V0.34)
Also für mich sieht das ok aus. FHTTK gehen auch.

Hast recht ESA ging bisher noch nicht mit TSCUL, hatte ich übersehen:

Code Auswählen

Internals:
   CFGFN      ./em.cfg
   CODE       0178
   CUBe868SL_MSGCNT 756
   CUBe868SL_RAWMSG S800178011E0029D7D1000057B56803E9
   CUBe868SL_RSSI -80
   CUBe868SL_TIME 2020-04-25 17:42:08
   DEF        0178
   FUUID      5c48e3f6-f33f-d5a5-718f-c32e2955db410456
   IODev      CUL_0
   LASTInputDev CUBe868SL
   MSGCNT     756
   NAME       EM_Total
   NR         738
   STATE      CNT: 0+ CUM: 867.228 CUR: 0.000 TICKS: 1000 LR
   TYPE       ESA2000
   Helper:
     DBLOG:
       actual:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       actual_ticks:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       battery:
         logdb:
           TIME       1587829328.95649
           VALUE      ok
       day:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       day_hr:
         logdb:
           TIME       1587751019.46024
           VALUE      0
       day_last:
         logdb:
           TIME       1587765746.28486
           VALUE      0
       day_lr:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       diff:
         logdb:
           TIME       1587829328.95649
           VALUE      0.0000
       diff_sec:
         logdb:
           TIME       1587829328.95649
           VALUE      156.460736989975
       diff_ticks:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       hour:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       hour_last:
         logdb:
           TIME       1587826887.20166
           VALUE      0
       last_sec:
         logdb:
           TIME       1587829328.95649
           VALUE      1587829328.91685
       month:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       month_hr:
         logdb:
           TIME       1587751019.46024
           VALUE      0
       month_lr:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       rate:
         logdb:
           TIME       1587829328.95649
           VALUE      LR
       raw:
         logdb:
           TIME       1587829328.95649
           VALUE      CNT: 0+ CUM: 2742225 CUR: 0  TICKS: 1000 LR
       raw_total:
         logdb:
           TIME       1587829328.95649
           VALUE      2742.225
       repeat:
         logdb:
           TIME       1587829328.95649
           VALUE      +
       sequence:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       state:
         logdb:
           TIME       1587829328.95649
           VALUE      CNT: 0+ CUM: 867.228 CUR: 0.000 TICKS: 1000 LR
       ticks:
         logdb:
           TIME       1587829328.95649
           VALUE      1000
       total:
         logdb:
           TIME       1587829328.95649
           VALUE      867.22799999998
       total_ticks:
         logdb:
           TIME       1587829328.95649
           VALUE      2742225
       type:
         logdb:
           TIME       1587829328.95649
           VALUE      ESAx000WZ
       year:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       year_hr:
         logdb:
           TIME       1587751019.46024
           VALUE      0
       year_lr:
         logdb:
           TIME       1587829328.95649
           VALUE      0
   READINGS:
     2020-04-25 17:42:08   actual          0
     2020-04-25 17:42:08   actual_ticks    0
     2020-04-25 17:42:08   battery         ok
     2020-04-25 17:42:08   day             0
     2020-04-24 19:56:59   day_hr          0
     2020-04-25 00:02:26   day_last        0
     2020-04-25 17:42:08   day_lr          0
     2020-04-25 17:42:08   diff            0.0000
     2020-04-25 17:42:08   diff_sec        156.460736989975
     2020-04-25 17:42:08   diff_ticks      0
     2020-04-25 17:42:08   hour            0
     2020-04-25 17:01:27   hour_last       0
     2020-04-25 17:42:08   last_sec        1587829328.91685
     2019-01-24 19:37:19   max             13.7806930802237
     2020-04-25 17:42:08   month           0
     2020-04-24 19:56:59   month_hr        0
     2020-04-01 01:35:24   month_last      0
     2020-04-25 17:42:08   month_lr        0
     2020-04-25 17:42:08   rate            LR
     2020-04-25 17:42:08   raw             CNT: 0+ CUM: 2742225 CUR: 0  TICKS: 1000 LR
     2020-04-25 17:42:08   raw_total       2742.225
     2020-04-25 17:42:08   repeat          +
     2020-04-25 17:42:08   sequence        0
     2020-04-25 17:42:08   state           CNT: 0+ CUM: 867.228 CUR: 0.000 TICKS: 1000 LR
     2020-04-25 17:42:08   ticks           1000
     2020-04-25 17:42:08   total           867.22799999998
     2020-04-25 17:42:08   total_ticks     2742225
     2020-04-25 17:42:08   type            ESAx000WZ
     2020-04-25 17:42:08   year            0
     2020-04-24 19:56:59   year_hr         0
     2020-01-01 00:02:21   year_last       377.947999999991
     2020-04-25 17:42:08   year_lr         0
Attributes:
   DbLogInclude .*
   IODev      CUL_0
   room       ESA2000,Strom

Test folgt heute Abend.
Gruß

Peter

noansi · 25 April 2020, 18:21:38

Hallo Peter,

ZitatDer nakte CUL hat ja mehr Platz als der RFR

Leider falsch gedacht.
Der RFR kann kein ASKSIN und kein Moritz und kein RWE. Die machen wenig Sinn, denn RFR benötigt SlowRF. Somit hat die Variante RFR mehr Platz.

ZitatBei FHT ist mir nichts negatives aufgefallen:

Sehr schön.

ZitatHast recht ESA ging bisher noch nicht mit TSCUL, hatte ich übersehen:

Was hast Du eigentlich nicht im Zoo?

Schön.

Mir ist im Log 5 nur was aufgefallen, was der CUL_0 mit ESA verwechselt hat. Aber dann ist da mit ESA wohl noch eine offene Baustelle.
Kann der CUL_0 von seiner Position her einen ESA überhaupt empfangen?

Gruß, Ansgar.

noansi · 25 April 2020, 19:35:34

Hallo Peter,

noch eine neue Version im Anhang zum Test.
Ich bin optimistisch, dass mit der nun auch ESA klappt. Im Protokoll habe ich ESA Beispiele gefunden.
Wenn man ESA nicht braucht, ist es aber besser, es nicht rein zu komplieren, weil die Trennschärfe beim SlowRF Sync damit doch deutlich mehr gefordert wird, somit andere Protokolle eventuell schlechter empfangen werden, insbesondere, wenn die Sender ohnehin kein sauberes Timing haben oder der CC1101 wackelig empfängt.

Kannst Du bitte mit der Firmware im Anhang den Test mit sens 8 und set X3D wiederholen?!
Und dabei bitte den CUBe mit set X25 und auch auf verbose 4.

Gruß, Ansgar.

pantau · 25 April 2020, 22:08:55

Hallo Ansgar,

Zitat von: noansi am 25 April 2020, 19:35:34
Was hast Du eigentlich nicht im Zoo? Schön.

Mein Zoo ist einfach über 15 Jahre gewachsen und umfasst alle ELV Generationen. Die haben leider alle 3-5 Jahre was Neues erfunden... Die alten Sache laufen meist ganz gut, also kein Grund es wegzuschmeißen.

Zitat von: noansi am 25 April 2020, 19:35:34
Mir ist im Log 5 nur was aufgefallen, was der CUL_0 mit ESA verwechselt hat. Aber dann ist da mit ESA wohl noch eine offene Baustelle.
Kann der CUL_0 von seiner Position her einen ESA überhaupt empfangen?

Kann er, siehe auch Log, das sind ca. 2m zum CUL_0, 2 Stockwerke zum CUBe868SL.

Zitat von: noansi am 25 April 2020, 19:35:34
noch eine neue Version im Anhang zum Test.
Ich bin optimistisch, dass mit der nun auch ESA klappt. Im Protokoll habe ich ESA Beispiele gefunden.
Wenn man ESA nicht braucht, ist es aber besser, es nicht rein zu komplieren, weil die Trennschärfe beim SlowRF Sync damit doch deutlich mehr gefordert wird, somit andere Protokolle eventuell schlechter empfangen werden, insbesondere, wenn die Sender ohnehin kein sauberes Timing haben oder der CC1101 wackelig empfängt.

ESA geht. Der CUBe868SL hatte vor allem mit dem ESA nie Probleme, mit den HMS schon. Danke für die Erklärung.
Log im Anhang, jetzt ist mir aufgefallen, das tatsächlich der CUL_0 die HMS nicht immer empfing wenn es der CUBe868SL tat. ESA war bei beiden immer gleich. Zumindest auf den ersten Blick.
Ich hab ja ein paar CUL im Einsatz, da werde ich dann mal besser planen, welcher was empfangen soll.

Gruß

Peter