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

Bastel-Frank · 22 Dezember 2017, 14:34:03

Mal ne' andere Frage:
Wann wird deine Firmware endlich (!) offiziell übernommen? Ich finde, es wird "langsam Zeit" dafür. Deine Firmware läuft sehr, sehr stabil und behebt Fehler der offiziellen Firmware. Einige Devices laufen nur, weil deine Firmware dies (im Gegensatz zur offiziellen Firmware) kann.
Kann man sich dafür irgendwo stark machen?

noansi · 22 Dezember 2017, 15:10:17

Hallo Frank,

ich weiß nicht, wie meine ganzen Abwandlungen von Modulen ankommen würden. Auf die möchte ich selber jedoch nicht verzichten. Andere Maintainer mit einer Anpassung zu überlasten wird es wohl nicht bringen.
Bei SlowRF gibt es mittlerweile eine nette Empfangsstatistik zusammen mit den Sondermodulen, die man mit "get dispSRFStat" anzeigen lassen kann, ähnlich wir Martins HMInfo.

Beispiel:

Code Auswählen

SlowRF CUL_WS868 Receive Statistic:

freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:177.73kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s 
agcPrio:1 agcWait:32 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0 
CCAmode:1 csRelThr:10dB csAbsThr:4dB

Ints_per_sec  SI: 15.80240  TI: 0.37657  S: 0.13330  L: 0.00000  U: 0.00333  M: 0.00000

SlowRF_TmMatchStat  Mean: 55.0  Max: 464.0

TSCUL_WS
Cd   Name                 Type Active RSSILast RSSIMin RSSIAvg RSSIMax     TdLast     TdMin     TdAvg     TdMax       Count EstQual
11   CUL_WS_1                1  alive    -43.5   -43.5  -43.50   -43.5     177.02    176.87   180.170    353.96          56  98.241
13   CUL_WS_13               3  alive    -53.5   -54.0  -53.51   -53.5     169.00    168.55   174.729    338.43          59  96.721
14   CUL_WS_14               4  alive    -53.5   -53.5  -53.50   -53.5     165.00    164.98   165.000    165.02          62 100.000
17   CUL_WS_17               7  alive    -53.5   -53.5  -53.50   -53.5     152.98    152.01   152.995    153.98          66 100.000
21   CUL_WS_2                1  alive    -32.5   -33.0  -32.87   -32.5     176.51    176.39   176.507    176.63          58  99.996
31   CUL_WS_3                1  alive    -46.5   -46.5  -46.38   -45.5     176.01    175.88   179.095    352.02          57  98.272
41   CUL_WS_4                1  alive    -43.5   -43.5  -43.50   -43.5     175.55    175.46   175.508    175.56          58  99.996
51   CUL_WS_5                1  alive    -33.0   -33.0  -32.87   -32.5     175.01    174.83   178.074    350.01          57  98.274
61   CUL_WS_6                1  alive    -37.5   -38.0  -37.52   -37.5     174.51    174.40   174.506    174.61          58  99.996
71   CUL_WS_7                1  alive    -50.0   -50.5  -49.88   -49.5     174.01    173.90   174.010    174.12          58  99.995
80   CUL_WS_80               0  alive    -53.5   -53.5  -53.50   -53.5     354.99    177.32   180.614    354.99          57  98.276
81   CUL_WS_8                1  alive    -32.0   -32.0  -31.91   -31.5     173.54    173.47   176.496    347.01          58  98.303
82   CUL_WS_82               2  alive    -53.5   -53.5  -53.50   -53.5     169.48    169.15   169.500    169.85          60 100.000
83   CUL_WS_83               3  alive    -53.5   -53.5  -53.50   -53.5     165.49    165.44   165.500    165.57          62 100.000
84   CUL_WS_84               4  alive    -53.5   -53.5  -53.50   -53.5     161.50    161.10   161.500    161.90          63 100.000
85   CUL_WS_85               5  alive    -53.5   -53.5  -53.50   -53.5     157.19    157.16   160.000    315.00          63  98.438


TSKS300
Cd   Name                 Type Active RSSILast RSSIMin RSSIAvg RSSIMax     TdLast     TdMin     TdAvg     TdMax       Count EstQual
1234 CUL_WS_KS300           KS  alive    -53.5   -53.5  -53.50   -53.5     152.15    152.15   157.265    305.01          64  96.970


TSCUL_TX
Cd   Name                 Type Active RSSILast RSSIMin RSSIAvg RSSIMax     TdLast     TdMin     TdAvg     TdMax       Count EstQual
23   CUL_TX_23              TH  alive    -53.5   -53.5  -53.41   -52.5     230.00     53.46   215.319    231.01          47  26.705

Die Firmware kann nur mit den abgewandelten Modulen vernünftig laufen.

Eine Sonderform von 10_CUL_HM.pm möchte ich eigentlich nicht noch aufmachen. Aber der letzte Versuch, die IO Zuordnungsänderungen bei Martin komplett durch zu bekommen war nicht so erfolgreich. Ich habe aber noch einiges geändert, was das erleichtern könnte und Martins sonstige Änderungen derweil immer nachgezogen. Das ist für mich noch ein Knackpunkt.

Ein weiterer Knackpunkt für mich ist, dass nicht alle Funktionalitäten der Firmware getestet sind, da ich selber keine Testhardware dafür habe. Was an möglichen Befehlen in {CMD} gemeldet wird, soll auch funktionieren, nicht nur 'A'.

Das Feedback hier ist recht gering, respektive der Mut zur Lücke die man ausmerzen könnte nicht sehr groß. Gut könnte mal ein bischen frisch werden, derzeit.

Gruß, Ansgar.

Bastel-Frank · 28 Dezember 2017, 10:49:17

Hallo Ansgar,

ich habe damit begonnen, die aktuelle Firmware zu installieren. Nach dem Update des ersten CUL's und den neuen Modulen in FHEM bekomme ich von dem umgestellten CUL sehr viele Log-Einträge in der Art:

Code Auswählen

2017.12.28 10:44:21 3: LogHist CUL_OG:  133272 A F603 00778052 01 0E B7 A011 738396 370AA2 0201000000 _CCAdly:4
2017.12.28 10:44:21 3: LogHist CUL_OG:  133544 A F603 00778328 01 0E B7 A011 738396 370AA2 0201000000 _CCAdly:4
2017.12.28 10:44:21 3: LogHist CUL_OG:  133817 A F603 00778600 01 0E B7 A011 738396 370AA2 0201000000 _CCAdly:4
2017.12.28 10:44:21 3: LogHist CUL_OG:  134056 A F609 00778868 00 0E B7 A011 738396 370AA2 0201000000 _sfail _noAnsw
2017.12.28 10:44:21 3: LogHist CUL_OG:  134114 A F602 00778924 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2017.12.28 10:44:21 3: LogHist CUL_OG:  134340 A F601 00779152 00 0D 84 A410 2A327B 738396 0601C840 -98dB
2017.12.28 10:44:21 3: LogHist CUL_OG:  134470 A F603 00779256 01 0A 84 8002 738396 2A327B 00 _CCAdly:4 _dhmSt:104
2017.12.28 10:44:21 3: LogHist CUL_OG:  135007 A F601 00779816 00 14 A2 845E 34264B 000000 80024D000000000008EFFE -103dB
2017.12.28 10:44:21 3: LogHist CUL_OG:  136192 A F601 00781004 00 0C B2 865A 27128B 000000 B0DC31 -79dB
2017.12.28 10:44:21 3: LogHist CUL_OG:  138005 A F602 00782816 00 01 CC _ping
2017.12.28 10:44:21 3: LogHist CUL_OG:  138300 A F601 00783112 00 0D 84 A410 2A327B 738396 0601C840 -100dB
2017.12.28 10:44:21 3: LogHist CUL_OG:  138424                 As 0E B7 A011 738396 370AA2 0201000000
2017.12.28 10:44:21 3: LogHist CUL_OG:  138429 A F603 00783216 01 0A 84 8002 738396 2A327B 00 _CCAdly:4 _dhmSt:104
2017.12.28 10:44:21 3: LogHist CUL_OG:  138537 A F603 00783320 01 0E B7 A011 738396 370AA2 0201000000 _CCAdly:4
2017.12.28 10:44:21 3: LogHist CUL_OG:  138809 A F603 00783592 01 0E B7 A011 738396 370AA2 0201000000 _CCAdly:4
2017.12.28 10:44:21 3: LogHist CUL_OG:  139080 A F603 00783864 01 0E B7 A011 738396 370AA2 0201000000 _CCAdly:4

Kann man die Anzahl der Log-Einträge eindämmen?

Viele Grüße
Frank

noansi · 28 Dezember 2017, 11:11:31

Hallo Frank,

Du kannst die Logeinträge abschalten, indem Du das Attribut "hmLogLev" größer einstellst, als das Attribut "verbose" für Deinen CUL.
Also z.B. hmLogLev auf 2 und verbose auf 1.

Und hmLogLev = verbose, wenn Du die Ausgabe aktivieren möchtest, da damit bei Fehler recht gut eine kurze zeitliche Vorgeschichte sichtbar wird, was bei der Fehlersuche hilfreich sein kann.

So scheint das device mit der ID 370AA2 von Deinem CUL_OG aus anscheinend entweder nicht erreichbar zu sein oder es antwortet nicht, z.B. weil es sich nicht angesprochen fühlt, mangels Pairing.

Gruß, Ansgar.

Bastel-Frank · 28 Dezember 2017, 13:22:00

Hallo Ansgar,

ich habe alle CULs umgestellt. Das System war zunächst eine Weile recht träge, nach einer Stunde läuft jetzt aber wieder alles. Das Log ist jetzt auch ruhig, es gibt keine größeren Einträge mehr.

Soweit so gut, ich behalte alles im Auge und werde berichten. Gibt es irgendwas besonderes, worauf ich achten soll?

Viele Grüße
Frank

noansi · 28 Dezember 2017, 14:04:41

Hallo Frank,

schau mal mit get assignIDs bei den einzelnen IOs, ob es so bei Deinen IOs passt, wie Du es eingestellt hast, respektive ganz wichtig, ob es keine Doppelzuordnung zu zwei IOs gleichzeitig gibt.

Und natürlich, ob es irgendwelche Schaltprobleme gibt.

ZitatDas System war zunächst eine Weile recht träge

War das, als die LogHist Einträge noch geschrieben wurden?

Die kannst Du auch mal durchgehen. Da wo _sfail und/oder _noAnsw steht, ist was schief gegangen, was auf eine ungünstige IO Zuweisung für die jeweilige ID hindeuten könnte.
Normal ist nur, dass es gelegentlich mal schief geht, weil z.B. ein anderes Device dazwischen quaselt. In kurzer Abfolge aber zeigt es eher ein Einstellungs- oder Erreichbarkeitsproblem.

Gruß, Ansgar.

Bastel-Frank · 28 Dezember 2017, 15:54:14

Zitat von: noansi am 28 Dezember 2017, 14:04:41
War das, als die LogHist Einträge noch geschrieben wurden?

Nein, es wurde nach und nach besser. Ich habe den Eindruck, dass es mit den Änderungen der IOgrp's von "vccu" auf "vccu:CUL_XX" zusammen hing. Irgendwie hatte ich den Eindruck, dass fhem in dieser Zeit mit sich selbst beschäftigt war und Prozesse im Hintergrund liefen, die ich nicht einschätzen kann. Aktionen in der Oberfläche musste ich sehr oft doppelt anklicken bis etwas passierte.

Torsten_MG · 30 Dezember 2017, 08:48:12

Mal hier hin verschoben:

Zitat von: Torsten_MG am 29 Dezember 2017, 14:41:09
OK, dann werde ich jetzt mal alles auf 0 setzen und von vorne Anfangen!

Kann mir dann bitte jemand eine Schritt-für-Schritt-Anleitung zur Verfügung stellen, wie ich die Alternative fw für den CUL drauf bekomme und was ich mit den ganzen Dateien im Firmware-Ordner machen muss.

VIELEN DANK! schonmal

Zitat von: noansi am 29 Dezember 2017, 23:49:22
Hallo Thorsten,

...
Dort kann dann ggf. auch jemand anderes Deine Installationsfragestellungen und Antworten zur tsculfw und TSCUL nachlesen.

Und im Firmware Ordner gibt es mehrere .hex Dateien. Du musst die zu Deinem CUL Modell passende auf Deinen CUL flashen. Und das genauso, als würdest Du die "Standard" Firmware flashen, jedoch natürlich mit der richtigen .hex Datei. der tsculfw.

Das wäre Step 1.

Step 2 wäre, Dein fhem zu stoppen und in der fhem.cfg aus "CUL" "TSCUL" bei der Definition Deines CUL1 zu machen und FHEM wieder zu starten.
Welche hmID Du verwendest, ist im Prinzip wurscht, aber in dichter Besiedlung mit anderen Homatic Nachbarn halt sehr sinnvoll, was eher indivduelles zu wählen. Und das ganze mit 6 hex Ziffern groß geschrieben.

Wenn Du mit der Installation Firmware und Umstellung auf TSCUL dann mal durch bist, kannst Du in Deinem Ausgangsthread ggf. zum Anlernen Deines HM-Sen-MDIR-WM55 weiter fragen, falls es immer noch Probleme gibt.
Grundsätzlich ist es aber immer guter Stil, erst mal verfügbare Anleitungen zu lesen. Also z.B. wie setze ich meinen
HM-Sen-MDIR-WM55 in den Auslieferungszustand zurück, wenn ich bei 0 anfangen möchte.. Das solltest in Papierform haben.

Gruß, Ansgar.

Ich tue mich schon mit Step 1 schwer. Als ich den CUL (CC1101 CULV3-OEM) das erste mal geflasht habe, habe ich es wie in diesem https://haus-automatisierung.com/hardware/fhem/2016/05/08/fhem-tutorial-reihe-part-4-cul-flashen-und-erste-geraete-anlernen.html Tutorial gemacht. Muß ich jetzt nur deine *.hex in den Ordner von dem damals heuntergeladenen Ordner austauschen, diesen Ordner auf meinen Raspi schieben und wie im Tutorial neu flashen? Und was muß ich mit den Dateien im tsculfw-code-459-trunk_lufa_00_21-Ordner machen?

Bytechanger · 30 Dezember 2017, 09:42:01

Guten Morgen,

wurden die Änderungen zwischenzeitlich in die 10_CUL_HM.pm übernommen, oder muss ich sie weiterhin vom Update ausschließen?

Greets

Byte

noansi · 30 Dezember 2017, 12:18:36

Hallo Byte,

Zitatwurden die Änderungen zwischenzeitlich in die 10_CUL_HM.pm übernommen, oder muss ich sie weiterhin vom Update ausschließen?

Leider noch nicht übernommen, daher bleibt es vorerst noch beim Update Ausschluss.

Gruß, Ansgar.

noansi · 30 Dezember 2017, 12:52:36

Hallo Torsten,

dfu-programmer, der für das Flashen eines CUL V3 benötigt wird, hast Du also demnach schon installiert.

Zum Flashen findest Du unter http://busware.de/tiki-index.php?page=CUL:

CUL Stick in den Bootloader bringen, z.B. mit set CUL1 raw B01
oder mit gedrücktem Bootloadertaster in den USB-Port einstecken.
Dann müßte für die Standard Firmware die Du jetzt nicht flashen möchtest, in einem Shell Fenster:

Code Auswählen

dfu-programmer atmega32u4 erase
dfu-programmer atmega32u4 flash CUL_V3.hex
dfu-programmer atmega32u4 reset

und somit also für die tsculfw:

Code Auswählen

sudo dfu-programmer atmega32u4 erase
sudo dfu-programmer atmega32u4 flash TSCUL_V3.hex
sudo dfu-programmer atmega32u4 reset

nachdem Du zuvor mit "cd" in das Verzeichnis gewechselt hast, in das Du die TSCUL_V3.hex hinein kopiert hast, z.B. Dein Home Verzeichnis auf dem RasPi. Das zusätzliche sudo wirst Du sehr wahrscheinlich benötigen, damit Du nicht an den Zugriffsrechten auf die Schnittstelle scheiterst.

Prinzipiell geht es auch mit TSCULflash unter fhem, wenn Du die TSCUL_V3.hex in das FHEM/Firmware Verzeichnis kopiert hast. Aber nur, wenn Du zuvor auch die Zugriffsrechte für FHEM dazu ausreichend eingestellt hast. Wie das geht ist per Hinweisen aus der CommandRef und Suche herraus zu finden. Daher versuchs besser erst mal mit dem obigen Weg, statt eine neue Baustelle aufzumachen.
EDIT: z.B. so https://forum.fhem.de/index.php/topic,81823.msg738963.html#msg738963
Nachdem Du die .pm Dateien in den FHEM Ordner kopiert hast, kannst Du noch das FHEM CommandRef aktualisieren, wie in dem Beitrag mit der Firmwaredatei angegeben.

In Deinem link Artikel wird noch nicht das Attribut "hmId" genannt.
Das Attribut "hmId" musst Du für Deinen CUL1 auch noch auf Deine gewünschte Homematic-ID einstellen.

Besser wäre es wohl direkt auf eine VCCU zu gehen, wenn Du vor hast FHEM längerfristig zu nutzen, siehe auch https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU.

Gruß, Ansgar.

Torsten_MG · 30 Dezember 2017, 16:16:00

Zitat von: noansi am 30 Dezember 2017, 12:52:36
...
Code Auswählen Erweitern
dfu-programmer atmega32u4 erase --force dfu-programmer atmega32u4 flash CUL_V3.hex dfu-programmer atmega32u4 reset

...

Gruß, Ansgar.

Anscheinend bin ich selbst dafür zu doof

Ich verbinde mich mit putty

und wenn ich dfu-programmer atmega32u4 erase --force und anschließend dfu-programmer atmega32u4 flash CUL_V3.hex eingebe kommt folgendes:

Code Auswählen

pi@raspberrypi:~ $ dfu-programmer atmega32u4 erase --force
Usage: dfu-programmer target[:usb-bus,usb-addr] command [options] [global-options] [file|data]

global-options:
        --quiet
        --debug level    (level is an integer specifying level of detail)
        Global options can be used with any command and must come
        after the command and before any file or data value

commands:
        configure {BSB|SBV|SSB|EB|HSB} [--suppress-validation] data
        dump
        dump-eeprom
        dump-user
        erase [--suppress-validation]
        flash [--suppress-validation] [--suppress-bootloader-mem]
                     [--serial=hexdigits:offset] {file|STDIN}
        flash-eeprom [--suppress-validation]
                     [--serial=hexdigits:offset] {file|STDIN}
        flash-user   [--suppress-validation]
                     [--serial=hexdigits:offset] {file|STDIN}
        get     {bootloader-version|ID1|ID2|BSB|SBV|SSB|EB|
                 manufacturer|family|product-name|
                 product-revision|HSB}
        getfuse {LOCK|EPFL|BOOTPROT|BODLEVEL|BODHYST|
                 BODEN|ISP_BOD_EN|ISP_IO_COND_EN|
                 ISP_FORCE}
        setfuse {LOCK|EPFL|BOOTPROT|BODLEVEL|BODHYST|
                 BODEN|ISP_BOD_EN|ISP_IO_COND_EN|
                 ISP_FORCE} data
        setsecure
        reset
        start
pi@raspberrypi:~ $ dfu-programmer atmega32u4 flash CUL_V3.hex
dfu-programmer: no device present.
pi@raspberrypi:~ $

PS: Woran erkenne ich, ob der CUL wirklich im Bootloader-Modus ist?

noansi · 30 Dezember 2017, 16:27:03

Hallo Torsten,

dann versuch's mal mit

Code Auswählen

sudo dfu-programmer atmega32u4 erase
sudo dfu-programmer atmega32u4 flash TSCUL_V3.hex
sudo dfu-programmer atmega32u4 reset

"--force" mag er wohl nicht.
Außerdem möchtest Du doch wohl TSCUL_V3.hex flashen und nicht die CUL_V3.hex, denke ich.

Code Auswählen

dmesg
verrät Dir, was gerade am System geändert wurde, also auch, als was der CUL erkannt wurde.

Gruß, Ansgar.

Torsten_MG · 30 Dezember 2017, 16:32:17

ok, war wohl irritiert mit deiner beschreibung. Dachte ich müsse das obere auch durchführen. Sollte wohl das Gehirn besser nutzen. Das flashen scheint jetzt funktioniert zu haben

Code Auswählen

pi@raspberrypi:~/test $ sudo dfu-programmer atmega32u4 erase
pi@raspberrypi:~/test $ sudo dfu-programmer atmega32u4 flash TSCUL_V3.hex
Validating...
28632 bytes used (99.86%)
pi@raspberrypi:~/test $ sudo dfu-programmer atmega32u4 reset
pi@raspberrypi:~/test $

Melde mich dann später nochmal, falls ich mit dem Rest probleme bekomme.

Vielen Dank erstmal!

PS: Da der Cul wieder blinkt, scheint das zu funktionieren

dora71 · 31 Dezember 2017, 14:33:23

Hallo zusammen,

habe seit gestern auch die Firmware 0.21 auf meinem CUL V3.4 geflasht. Alles ohne Probleme, alle Homematic Komponenten werden korrekt erkannt und Konflikte sind nirgendwo zu erkennen. Vielen Dank an Ansgar für die tolle Arbeit.

Eine Frage habe ich noch: Kann ich darüber auch Firmware-Updates der Homematic Komponenten durchführen oder muss ich dann noch etwas spezielles beachten?

Nochmals vielen Dank und schon allen Lesern ein guten Rutsch ins neue Jahr.

Gruß Rainer