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

Begonnen von noansi, 09 Juni 2014, 19:16:01

Vorheriges Thema - Nächstes Thema

noansi

#135
Hallo Joachim,

ZitatNur eine neuere Version von 00_CUL.pm

Die meinte ich. Und wenn Du auch noch die benutzt, dann hast Du den letzten Stand gefunden.

ZitatAndersrum gefragt: wenn ich die neueste von dir (glaube ich waren die Anpassungen!?) asksin.c in die runtergeladenen Sourcen (neueste Version der "standard cul-fw") austausche habe ich dann alles was ich für Homematic timing brauche?

Die asksin.c alleine reicht nicht, da ich sehr viel mehr in der Firmware geändert habe und es mit dem einfachen Austausch der Datei nicht getan ist.
Wenn Du aber nur HM machen willst, warum willst Du dann die Standard Firmware umbauen? Ich sehe da keinen Vorteil.
Schau nur, dass Du meine Variante mit Deinem nanoCul ans laufen bekommst. Und da nanoCUL nicht zwingend gleich nanoCUL ist, bleibt Dir die Überprüfung und ggf. Anpassung der genannten Dateien nicht erspart.
(Oder es findet sich jemand, der das mit gleicher Hardware und Pinbelegung schon gemacht hat.)

Also ist die erste Frage, was hängt an welchem Pin?
Und die zweite, welchen Prozessor hast Du auf deinem nanoCUL und mit welcher Taktfrequenz läuft der?
(Taktfrquenz ist wichtig um den CPU-Takt Vorteiler so einzustellen, dass ein effektiver Takt von 8MHz raus kommt, sonst geht das Timing trotzdem in die Hose)

Und/Oder Du vergleichst (mindestens) die genannten Dateien aus den Sourcen von der bei Dir schon laufenden Version mit denen aus meiner Variante bezüglich der Pin Nutzung und CPU Takt und passt entsprechend an, was anders ist.
Dann compilieren und flashen.

Zu der Frage "Wie passe ich CUL Firmware Sourcen an meinen nanoCUL an?" wäre es dann sinnvoller einen separaten Thread zu öffnen und die Fragen da zu diskutieren.

Außerdem musst Du die *.pm Dateien im FHEM Verzeicnnis ausstauschen. Das steht im Thread. Inklusive meiner dringenden Hinweise, vorher die Dateien zu sichern, falls FHEM Neuerungen zu Nebenwirkungen führen.

Gruß, Ansgar.

MadMax-FHEM

Hi Ansgar,

vielen Dank!

Dann passt alles.

Also die genannte cul-fw hier im Thread compilieren (gut prüfen und anpassen eh klar) und dann die letzte zu findende 00_CUL.pm.

Das wollte ich wissen.

Hab mich nur wund gesucht und wusste nie, ob ich nun wirklich die aktuellste spezielle cul-fw habe...
...oder ob es irgendwo (sourceforge, github, ...) bereits eine neuere gibt...

Gruß, Joachim

P.S.: pinbelegung etc. ist wie bei "cul-fw" beschrieben, nach der Anleitung habe ich den nanoCUL gebastelt und er läuft ja prinzipiell...
MC ist ein ATMEGA328 auf einem Arduino Nano allerdings mit 16MHz wobei sich das ja per fuse einstellen lässt, dann allerdings nur mit dem internen Takt. Ist der genau genug?? Bzw. kann ich das doch ebenso in der board.h einstellen!?
Ich denke das kriege ich hin...
Wenn nicht: neuer Thread! Danke...
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

noansi

Hallo Joachim,

ZitatMC ist ein ATMEGA328
Im Makefile ist atmega328p oben eingetragen. Wenn ohne p, dann pass es an.
F_CPU = 8000000 belassen, ist relevant für die Baudratenberechnung.

Zitat16MHz
Das ist ok.
In board.h ist das schon passend definiert, so dass in nanoCUL.c der Prescaler auf Halbierung eingestellt wird -> wunderbare 8MHz.

Zitatpinbelegung etc. ist wie bei "cul-fw"
Beim schnellen Überfliegen sieht das dann wohl gut aus.
Nur den Kommentar bei
// #define SPI_CC1101_READ_SPECIAL_PIN   6     // we missuse this unused (has to be checked!) pin as fast signaling bit for special cc1101_read_buf
musst Du in board.h entfernen, um die Zeile zu aktivieren und
#define MULTI_FREQ_DEVICE
darin auskommentieren, da Du ja vermutlich/hoffentlich ein 868MHz cc1101 Modul hast.

Dann noch alle 433MHz Protokolle, z.B.
#define HAS_TX3_SEND                  //
#define HAS_INTERTECHNO
#define HAS_IT       // define to enable IT support
...
nach Bedarf auskommentieren.

Viel Erfolg,

Ansgar.

MadMax-FHEM

Hallo Ansgar,

vielen Dank für die Hinweise!!

Dann kann ich ja loslegen...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MadMax-FHEM

Hallo,

also bauen und flashen war (fast) unproblematisch.

Allerdings scheint der 'HM-Sen-Db-Pcb' (Klingelsensor) eine hartnäckige Nuss zu sein.

Habe schon einiges hier gelesen und immer wieder wurde das Timing als Ursache genannt...
...drum habe ich mich auf die Suche nach dieser speziellen cul-fw gemacht.

Aber leider immer noch: ich bekomme die Nachrichten (also dass "gedrückt" wurde), allerdings bleibt 'R-pairCentral' auf 'set_0xAFFE02' stehen...

Werde mal testen, ob der Klingelsensor an einem HM-CFG-USB-2 auch so zickt...
Bei den (optischen) Fenstersensoren hatte ich das auch nur an meinem CUL, sobald ich ihn dann ins "scharfe" System mit HM-CFG-USB-2 integriert habe gings...

Gut, da es mein Testsystem ist, ist es erst mal nicht so schlimm aber komisch ist es schon...

Trotzdem vielen Dank noch mal!!

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

noansi

Hallo Joachim.

dann stell bitte in FHEM den CUL auf verbose 4 und logge damit mal das pairing von dem device und poste es.

Dann kommen wir vielleicht dahinter, was da klemmt.

Gruß, Ansgar

PS: Du hast auch die .pm Dateien im FHEM Verzeichnis ausgetauscht und das nicht vor lauter Firmwarefreude verdrängt?!

MadMax-FHEM

Hallo Ansgar,

ja habe ich.
Eben noch mal geprüft...

Hier mal zur Sicherheit ein list des CUL:


Internals:
   CMDS       ABCEFGJKMRTUVWXYZeflmtx
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400 1111
   DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400
   FD         8
   FHTID      1111
   NAME       nanoCUL_HM
   NR         43
   PARTIAL
   RAWMSG     AFF01001B9F4C000FB586102B8E860000000A98DE0C000004
   RSSI       -72
   STATE      Initialized
   TYPE       CUL
   VERSION    V 99.78 nanoCUL868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes
   initString X21
Ar
At1
   nanoCUL_HM_MSGCNT 2249
   nanoCUL_HM_TIME Initialized
   owner_CCU  vccu
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2016-05-17 03:22:53   ccconf          freq:868.300MHz bWidth:101kHz rAmpl:33dB sens:8dB drate:9.993kBit/s agcprio:1 agcwait:16 agchyst:2 dcBlockingoff:0 IF:152.34kHz agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0 freq_offs:-22.217kHz
     2016-05-18 21:27:51   cmds             A B C E F G J K M R T U V W X Y Z e f l m t x
     2016-05-06 00:05:19   credit10ms      900
     2016-05-18 20:22:31   hmSioDly        20
     2016-05-06 00:12:28   raw             V 1.66 nanoCUL868
     2016-05-19 01:47:38   scF             1.00016741512861
     2016-05-19 01:49:52   state           Initialized
     2016-05-17 03:23:10   version         V 99.78 nanoCUL868
   Helper:
     398b7d:
       QUEUE:
     Hm:
       FUP        0
       hmCrdts    0
       hmSbusy    0
     Q:
       Cap:
         sum        45000
     Ref:
       ApCUPend   0
       AsPend     0
       Lhmt       14453088
       Lsys       105257899
       Sdly       7
       dwoCCAAa   104
       nusew      31
       pTTu       1024
       pingMax    4
       pingMin    3
       pingRef    4
       pingdly    4
       pinglm     11
       pingtm     105152473
       scErr      15.4089839153457
       scF        1.00016741512861
       scFN       1
       scHT       14347688
       scHTL      14347688
       scST       105152477
       scSTL      105152477
       tgtdly     104
Attributes:
   hmId       AFFE02
   rfmode     HomeMatic
   verbose    4


und hier das Pairing mit verbose 4 (gestartet um 01:55):


2016.05.19 01:54:05 4: CUL_send:  nanoCUL_HM                            Ap AE     
2016.05.19 01:54:05 4: CUL_Parse: nanoCUL_HM  157819 A FF02 14734848 00 01 AE -138
2016.05.19 01:54:35 4: CUL_Parse: nanoCUL_HM  187178 A FF01 14764200 00 0C 6C 8670 2BBF72 000000 009B2F -76
2016.05.19 01:55:03 4: CUL_Parse: nanoCUL_HM  215540 A FF01 14792560 00 0C 00 865A 31D1FE 000000 90F328 -47.5
2016.05.19 01:55:04 4: CUL_Parse: nanoCUL_HM  216237 A FF01 14793248 00 1A 01 8400 398B7D 000000 1000DC4D45513036353638393240010101 -66
2016.05.19 01:55:04 2: CUL_HM Unknown device HM_398B7D is now defined
2016.05.19 01:55:04 2: autocreate: define HM_398B7D CUL_HM 398B7D
2016.05.19 01:55:04 2: autocreate: define FileLog_HM_398B7D FileLog ./log/HM_398B7D-%Y.log HM_398B7D
2016.05.19 01:55:04 3: CUL_HM pair: HM_398B7D pushButton, model HM-Sen-DB-PCB serialNr
2016.05.19 01:55:04 4: CUL_send:  nanoCUL_HM                         Aw 07 10 02 A001 AFFE02 398B7D 00050000000000
2016.05.19 01:55:04 3: CUL_send:  nanoCUL_HM  id:398B7D dDly:76
2016.05.19 01:55:04 4: CUL_Parse: nanoCUL_HM  216420 A FF13 14793408 00 10 02 A001 AFFE02 398B7D 00050000000000 -138
2016.05.19 01:55:04 4: CUL_Parse: nanoCUL_HM  216559 A FF11 14793568 00 1A 02 8400 398B7D 000000 1000DC4D45513036353638393240010101 -58.5
2016.05.19 01:55:04 3: CUL_HM set HM_398B7D getConfig
2016.05.19 01:55:04 4: CUL_send:  nanoCUL_HM                         Aw 08 13 03 A001 AFFE02 398B7D 000802010AAF0BFE0C02
2016.05.19 01:55:04 3: CUL_send:  nanoCUL_HM  id:398B7D dDly:83
2016.05.19 01:55:04 3: CUL_ParseTsHM: nanoCUL_HM  id:398B7D dhmSt:112 hmSioDly:22
2016.05.19 01:55:04 4: CUL_Parse: nanoCUL_HM  216696 A FF13 14793680 00 13 03 A001 AFFE02 398B7D 000802010AAF0BFE0C02 -138
2016.05.19 01:55:04 4: CUL_Parse: nanoCUL_HM  216810 A FF11 14793824 00 0A 03 8002 398B7D AFFE02 80 -62
2016.05.19 01:55:05 4: CUL_send:  nanoCUL_HM                            Ap AE     
2016.05.19 01:55:05 4: CUL_Parse: nanoCUL_HM  217931 A FF12 14794952 00 01 AE -138
2016.05.19 01:55:07 4: CUL_Parse: nanoCUL_HM  219618 A FF11 14796632 00 0C A9 865A 3227F4 000000 90E329 -86.5
2016.05.19 01:55:10 4: CUL_Parse: nanoCUL_HM  222453 A FF01 14799464 00 0F B7 8610 2B8E86 000000 0A98DF0C0000 -71.5


und noch das list vom Device nach dem Pairing(versuch):


Internals:
   CFGFN
   DEF        398B7D
   IODev      nanoCUL_HM
   LASTInputDev nanoCUL_HM
   MSGCNT     3
   NAME       HM_398B7D
   NR         360
   STATE      Nack
   TYPE       CUL_HM
   lastMsg    No:03 - t:02 s:398B7D d:AFFE02 80
   nanoCUL_HM_MSGCNT 3
   nanoCUL_HM_RAWMSG A0A038002398B7DAFFE0280::-62:nanoCUL_HM
   nanoCUL_HM_RSSI -62
   nanoCUL_HM_TIME 2016-05-19 01:55:04
   protCmdDel 5
   protLastRcv 2016-05-19 01:55:04
   protNack   1 last_at:2016-05-19 01:55:04
   protSnd    2 last_at:2016-05-19 01:55:04
   protState  CMDs_done_Errors:1
   rssi_at_nanoCUL_HM avg:-62.16 min:-66 max:-58.5 lst:-62 cnt:3
   Readings:
     2016-05-19 01:55:04   CommandAccepted no
     2016-05-19 01:55:04   D-firmware      1.0
     2016-05-19 01:55:04   D-serialNr      MEQ0656892
     2016-05-19 01:55:04   R-pairCentral   set_0xAFFE02
     2016-05-19 01:55:04   state           Nack
   Helper:
     HM_CMDNR   3
     cSnd       01AFFE02398B7D00050000000000,01AFFE02398B7D000802010AAF0BFE0C02
     getCfgList all
     getCfgListNo ,4
     mId        00DC
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       LRcTm      14793824
       LRcTmCnt   1
       LSndDlya
       LSndDlyb
       newChn     +398B7D,00,00,00
       nextSend   1463615704.90757
       nextSendLRmsg A0A038002398B7DAFFE0280
       prefIO
       rxt        0
       vccu
       p:
         398B7D
         00
         00
         00
     Mrssi:
       mNo        03
       Io:
         nanoCUL_HM -60
     Prt:
       bErr       0
       mmcS       2
       sProc      0
       mmcA:
         ++A001AFFE02398B7D00050000000000
         ++A001AFFE02398B7D000802010AAF0BFE0C02
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul_hm:
         avg        -62.1666666666667
         cnt        3
         lst        -62
         max        -58.5
         min        -66
     Shadowreg:
       RegL_00.    02:01 0A:AF 0B:FE 0C:02
     Tmpl:
Attributes:
   IODev      nanoCUL_HM
   IOgrp      vccu:nanoCUL_HM
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-Sen-DB-PCB
   room       CUL_HM
   serialNr   MEQ0656892
   subType    pushButton


Vielen Dank (schon mal/noch mal)!!

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

noansi

Hallo Joachim,

an dieser Stelle wäre jetzt Martin gefragt bezüglich der Protokoll Interpretation.

Ich sehe da ein "Nack" vom Device. Und interpretiere es so, dass es nicht mitspielen will.

Hast Du es mal auf Werkseinstellungen zurück gesetzt?


Ansonsten sehe ich noch, dass Du eine hmId AFFE02 gewählt hast. Normalerweise wird F1nnnn gewählt wobei nnnn der FHTID entspricht. Ob das ein Problem macht, kann wohl Martin sagen.

Generell solltest Du nicht relativ kurz nach einem FHEM Neustart ein Pairing versuchen, da ich erst versuche die Laufzeitunterschiede der Uhren zu ermitteln. Lass dem Vorgang mal mind. 1 Stunde Zeit.

Gruß,

Ansgar.

MadMax-FHEM

Hallo Ansgar,

danke.

Ja, habe beides getestet, also mit und ohne zurücksetzen...
Die Aufzeichnung war nach dem Zurücksetzen...

Letzter fhem Start müßte aber (deutlich) mehr als eine Stunde zurück gelegen sein (soweit ich mich erinnere, kann grad nicht nachschauen).

Aber ich probiere noch mal...

Hmmm, AFFE02 auf meinen "scharfen" System habe ich AFFE01 und keine Probleme.
Allerdings einen HM-CFG-USB...

Ich werde auch dort einfach mal testen und schauen, ob sich der Klingelsensor ähnlich wie die optischen Fensterkontakte verhält, also etwas zickig mit dem CUL (noch keine Spezialversion) und dann problemlos mit dem "scharfen" System...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

noansi

#144
Hallo Joachim, hallo Martin, hallo Testwillige,

angehängt eine neue Testversion der .pm Dateien zur Zusammenarbeit mit der Timestamp Firmware.

Es gibt darin bei CUL und CUL_HM ein neues Attribut "hmDstDly". Mittles Slider kann es von 96ms bis 128ms in 8ms Schritten verändert werden.
Wird es nicht gesetzt, dann wird auf 120ms Antwortzeit optimiert. Wird es nur bei CUL gesetzt, dann wird diese Zielantwortzeit für alle damit verknüpften HM Devices eingestellt.
Wird das Attribut für ein HM Device gesetzt, dann wird nur die Zielantwortzeit für dieses eine Gerät verändert. Damit kann man auch unterschiedliche Firmwarestände optimieren.

In der fhem.cfg lassen sich auch Werte jenseits dieser Grenzen einstellen, wenn exotischer getestet werden möchte.

Weiterhin gibt es bei HM devices ein neues Atrribut "UseRepeater" für die Nutzung eines HM Repeaters (HM-Sys-sRP-Pl). Per default ist es auf 0, was gedacht ist für Devices, die nicht selektiv von einem Repeater wiedeholt werden.
Wird es auf 1 gesetzt, dann werden nur noch die Repeater Nachrichten des Devices ausgewertet und mit einer um 88ms verkürzten Antwortzeit beantwortet. Die direkt empfangenen Nachrichten werden unterdrückt. Anwendung für die Kommunikationsoptimierung zu Aktoren.
Wird es auf 2 gesetzt, dann werden beide Nahrichten durchgelassen und von/über CUL_HM beantwortet. Empfangene CUL sende Nachrichten vom Repeater werden unterdrückt (Rechenzeit Optimierung). Anwendung für die Empfangsoptimierung von Sensoren.
Wird es auf 3 gesetzt, dann erscheinen diese Nachichten zumindest im Log, werden aber für CUL_HM unterdrückt. Anwendung zu Debuggingzwecken, um das Timing vollständig sichtbar zu machen.

Meine Tests im Nahbereich und einer CUL_V3 und UseRepeater=1 laufen damit ganz gut mit Repeateten Devices (beide Nachrichten werden jeweils empfangen).
Fernbeich konnte ich bisher nicht testen, also den Fall, dass nur noch der Repeater das Device erreicht bzw. dessen Nachrichten empfängt.

Da echt serielle Devices in der Kommunikation über die serielle Schnittstelle zwangsläufig größere Verzögerungen haben, sind diese mit Repeater kritisch bis unbrauchbar. Insbesondere mit Stacking.
Die Rechenpower des FHEM Hosts muss hier lindern, sofern es überhaupt geht.

@Joachim: versuch mal mit unterschiedlicher "hmDstDly" Einstellung ein pairing mit HM-Sen-DB-PCB. Da es zumindest angelegt wird, kann es mit anderem Timing hoffentlich besser mit dem Pairing klappen.
EDIT: "FHEM module changed 2.ZIP" ausgetauscht gegen "FHEM module changed 3.ZIP".

Gruß, Ansgar.

PS: Wie immer der Hinweis, erst Dateien sichern, dann gegen die aus der Zip Datei tauschen...

Edit: Anhang gelöscht, da update siehe unten.

MadMax-FHEM

Hallo Ansgar,

vielen Dank schon mal!

Komme aber erst heute Abend (oder morgen) zum Testen...

Bin schon sehr gespannt!

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MadMax-FHEM

Hallo Ansgar,

habe mal die pms eingespielt.

Zunächst dachte ich "nur", leider kein Unterschied, bis mir dann eingefallen ist: shutdown restart bzw. Module neu laden...

Leider kommt mein fhem nun nicht mehr auf die Beine:


2016.05.23 00:58:02 3: Opening nanoCUL_HM device /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0
2016.05.23 00:58:02 3: Setting nanoCUL_HM serial parameters to 38400,8,N,1
2016.05.23 00:58:02 3: nanoCUL_HM device opened
2016.05.23 00:58:02 1: nanoCUL_HM is VERSION_TS, V 99.78 nanoCUL868, nanoCUL_V1.x
2016.05.23 00:58:03 3: nanoCUL_HM: Possible commands: ABCEFGJKMRTUVWXYZeflmtx
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 3111, <$fh> line 75.
Illegal division by zero at ./FHEM/00_CUL.pm line 3111, <$fh> line 75.


Weil ich grad dabei bin (schon mal vorfühlen für den nächsten Test):

in welche Richtung ist denn besser bzw. was bedeutet "hmDstDly" (HM -> Destination Delay!?).
Leider kann ich das HM-Protokoll (noch ;-)  ) nicht "lesen" bzw. auch nicht genau verstehen was in den Logs (vom letzten Mal) zu sehen ist.
Also wer auf wen wartet bzw. wer wo einen Timeout hat.

Entweder bekomme ich "timeout Register Read" oder einfach nur ein simples "NACK"...

Vielen Dank noch mal/wieder für deine Mühe!

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

noansi

Hallo Joachim,

Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 3111, <$fh> line 75.
Illegal division by zero at ./FHEM/00_CUL.pm line 3111, <$fh> line 75.

ich habe die ZIP in meinem letzten Beitrag ausgetauscht.
Ein Problem bei der Variableninitalisierung bei fehlendem Scewfactor. Ich hoffe, jetzt klappt es.

ZitatHM -> Destination Delay!?
Richtig. Und 100 bis 120ms sollen es wohl normalerweise sein.
Den Einstellbereich habe ich mal zum Spielen vergrößert und auch auf 4ms Schrittweite geändert, was bezüglich Gangunterschied bei den Uhren sinnoll sein kann. 8ms ist aber weiterhin die CUL Timer Auflösung.

ZitatLeider kann ich das HM-Protokoll (noch ;-)  ) nicht "lesen" bzw. auch nicht genau verstehen was in den Logs (vom letzten Mal) zu sehen ist.
Leider fehlt auch mir die Zeit, um das mal intensiv zu studieren. Martin ist da der Eperte. Bzw. in dem von Dir genannten Thread hat Oliver das wohl schon mal auseinander genommen https://forum.fhem.de/index.php/topic,30275.msg247045.html#msg247045

Gruß, Ansgar.

MadMax-FHEM

Hallo Ansgar,

neue pms eingespielt, laufen soweit aber leider klappt es mit dem HM-Sen-Db-Pcb immer noch nicht.

Habe diverse Werte getestet, immer wieder gelöscht und angelernt usw.

Das Gerät zeigt zwar "grün", also eigentlich alles ok...
...aber fhem zeigt beim Gerät "NACK" und R-pairCentral bleibt auf set_0xAFFE02.
(also nicht ganz so wie in der Analyse von Oliver, zumindest soweit ich das verstanden hab)

Scheint wirklich ein hartnäckiges Bürschchen zu sein...

Habe es dann mal mit meinem "scharfen" System mit HM-CFG-USB-2/hmlan gepairt, dort klappt es sofort.

Achja, dort ist die HMID AFFE11 nicht wie ich dachte AFFE01, kann das etwas ausmachen??

Allerdings laufen auf meinem Testsystem auch andere HM-Komponenten (z.B. Wandthermostat und Schalteraktor) problemlos.

Einzig mit dem Klingelsensor und den optischen Fenstersensoren hatte ich bislang Probleme damit, dass R-pairCentral nicht klappt und auf set_ stehen bleibt.

Die magnetischen Fenstersensoren habe ich gleich mit dem "scharfen" System betrieben (da hatte ich noch kein Testsystem).

Da der Klingelsensor am "scharfen" System arbeitet werde ich hier mal aufgeben, sorry...
Allerdings für den Fall, dass was getestet werden soll (für andere Betroffene bzw. um das System besser zu machen) steht das Testsystem nat. "zur Verfügung"... ;-)

Ich werde noch im Thread mit dem Klingelsensor nach hier verlinken, vielleicht passiert noch etwas...
...ansonsten werde ich wie gesagt erst mal so weiter leben...

Vielen, vielen Dank Ansgar!

Und wie gesagt, falls es etwas zu testen gibt, bin ich nat. dabei!

FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

noansi

#149
Hallo Testwillige, hallo Martin,

im Anhang eine neue Version zum Testen.

Bezüglich Firmware ist die Timestamp Rückmeldung eines ASKSIN Sendebefehls (As, Aa, Aw) geändert. Bisher wurde die Timestamp und das komplette Sendepaket nach dem Senden zurück gemeldet. Nun wird nicht mehr das komplette Sendepaket mit zurück gemeldet, sondern nur noch bis zur Destination Id. Das ist nach derzeitigem Stand ausreichend und spart etwas Rückmeldezeit insbesondere für serielle devices.

RFR-Router und FastRF Änderungen in der Firmware sind noch Baustelle und ungetestet, also dessen Nutzungsversuche nicht zu empfehlen, was für ASKSIN/HM aber nicht relevant ist.

Zur Nutzung der Timestamp Funktionalität müssen die .pm Module aus der angehängten 20160612_fhem.zip verwendet werden.

Bitte, wie immer, unbedingt erst ein Backup der vorhandenen Dateiein im FHEM Ordner anlegen und dann die Dateien aus der 20160612_fhem.zip hinein kopieren.

Was hat sich geändert:

- das Attribut "UseRepeater" ist entfallen

- mit dem Attribut "hmDstDly" kann sowohl bei CUL als globale Einstellung, als auch bei HM devices die Zielverzögerung für HM Antworten etwas vom Default 120 variiert werden

- es gibt ein neues Attribut "RepBstAddDly" für HM devices. Das ist für die experimentelle HM-Repeater Nutzung von Burst devices speziell in Verbnindung mit STACKABLE_CC relevant. Da eine Antwort auf die erste Nachricht nach einem Burst zum device offenbar timingkritisch nicht erfolgreich verläuft (Kollision?), wird damit eine Zusatzzeit eingestellt, um passend zur nächsten wiederholten Nachricht vom device zu antworten. Für HM-LC-SW1-BA-PCB habe ich 552 als guten Wert ermittelt und als default gewählt, was aber bei anderen devices auch nicht passen kann. Somit kann man hier nach Logging und Timingbetrachtung per Burst device anpassen.

- Es wird automatisch versucht, die Repeaternutzung festzustellen, was insbesondere für die Senderichtung zum device relevant ist. Mit dem neuen Attribut "SndThrRep" kann die Automatik "überschrieben" werden, sprich die Erwartung über einen HM-Repeater zu device zu senden an und abgeschaltet werden. Die Automatik basiert auf empfangenen HM-Repeater Nachrichten von CUL zum Device und auf der per getConfig beim HM-Repeater ermittelten Konfiguration. Nach einem Neustart von FHEM ist die Info verloren und muss neu "eingesammelt" werden. Der erste "getConfig" nach einem Neustart von FHEM kann daher schief gehen.

- mit dem neuen Atrribut "hmLogRptSnd" kann das logging von empfangenen Repeaternachrichten, die CUL abgesetzt hat, aktiviert werden. Per default werden sie im Log unterdrückt, um etwas Rechenzeit zu sparen.
CUL empfängt diese Nachrichten auch nicht immer, was wohl mit dem Umschaltzeit auf Empfang nach dem Senden zusammenhängt.

- Das Sendetiming wurde weiter optimiert und erweitert. Nun werden nicht nur Antworten passend um 120ms verzögert, sondern auch das jeweils erste neue Kommando an das device nachdem eine Antwort gesendet wurde. 96ms hat sich bei mir als brauchbar erwiesen.

- Die Verzögerungsberechnung berücksichtigt nun die Übertragungsrate zum device. Bei CUL und seriellen devices wird die "@baudrate" Information der Definition genutzt.
Damit muss bei CUL "Schnittstelle@12000000" entsprechend der USB Datenrate eingestellt werden (Atmel mit USB Schnittstelle).
Bei SCC/COC ist es "Schnittstelle@38400" für das direkt auf dem RaspPi sitzende device. Stacked devices nutzen auch diese Einstellung des ersten SCC.
Bei CUNO/CUNO2 bei Nutzung der USB Schnittstelle "Schnittstelle@38400" (Atmel mit serieller Schnittstelle).
Bei CUNO/CUNO2 bei Nutzung der Ethernet Schnittstelle muss nichts geändert werden, da die Datenrate des Netzwerks genutzt wird.
Für die Datenrate ist die langsamste Teilstrecke auf der Verbindungsstrecke relevant!

Noch ein Hinweis: Es ist derzeit nur die Nutzung eines CUL device zum Empfangen von ASKSIN/HM möglich/sinnvoll. Die Uhren laufen unterschiedlich auf den verschiedenen CULs. Timestamps werden damit ggf. unbrauchbar, wenn 2 oder mehr CULs die gleiche Nachricht vom device empfangen.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

PS: Notifies bzw. events können je nach Umfang des Systems erheblich zu Timingproblemen führen. Also bei der Konfiguration des FHEM Systems konsequent Events abschalten, sie nicht benötigt werden (attribut event-on-change-reading reduzierend nutzen!).