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

Hallo Christian,

das hier ist die größte Merkwürdigkeit:
2016.10.16 15:49:11.723 4: TSCUL_Parse: nanoCULHomeMatic  056992 A FFA3 00300592 00 0E 03 A011 D3AA78 4AD28C  -138
2016.10.16 15:49:17.567 4: TSCUL_send:  nanoCULHomeMatic                         As 0E 03 A011 D3AA78 4AD28C 0201C80000
2016.10.16 15:49:17.569 4: CUL_HM_Resend: BrZi_ErkerRe_Rollo nr 2
2016.10.16 15:49:19.107 4: TSCUL_Parse: nanoCULHomeMatic  064372 A FFA1 00300744 00 11 03 A002 4AD28C D3AA78 0423FCBBFBD2E102 -70
2016.10.16 15:49:19.187 4: TSCUL_Parse: nanoCULHomeMatic  064456 A FFA3 00306560 00 0E 03 A011 D3AA78 4AD28C  -138

15:49:11.723 wird der send des vorherigen Set Befehls von nanoCUL quittiert.
15:49:17.567 wird der nächste, wiederholte Versuch gesendet
15:49:19.107 wird die empfangene Antwort des vorherigen von FHEM "empfangen", also ca. 7 Sekunden verzögert
15:49:19.187 kommt die Sendequittung des wiederholten Versuchs, am Zeitstempel 00306560 (in ms mit 8ms Auflösung) ist eindeutig zu sehen, das vorher eine Verzögerung aufgetreten ist. Aber auch die kommt mehr als 1,5s später, was nicht von der Firmware auf dem nanoCUL verursacht wird.

Wenn es dumm läuft, macht der USB-Seriell Baustein auf dem nanoCUL noch Verzögerung, oder der USB Treiber, weil der Versand der Wiederholung ja noch dazwischen gelaufen ist.
Bist Du bei dem RasPi auch aktuell?
sudo aptitude und Update kann eventuell auch helfen.

Zu Pilight Nebenwirkungen kann ich nichts sagen. Was machst Du mit Pilight? Kann das längere Zeit den I/O blockieren?

Gruß, Ansgar.

weini

Hi Ansgar!

Der RasPI ist aktuell, habe das letzte Upgrade vor ca. 2 Wochen gemacht. Ich bin auf Jessie und habe keine Testing oder Experimental-Pakete drauf.

Pilight hab ich zu Beginn für die IT Komponenten verwendet. Das läuft jetzt größtenteils über einen 433er CUL. Aktuell nutze ich Pilight nur noch für ein paar exotische Themen. Nicht ist leichter, als einen Test mit deaktivierten Pilight zu machen, geht nur heute Abend nicht mehr.

Ich nutze viele Entertainment-Module, z. B. 71_DENON12_AVR.pm, 70_ENIGMA2.pm, 82_LGTV_IP12.pm. Dazu dann noch Zeug für den Raspi wie 42_SYSMON.pm, Telegram, AMAD, HTTPMOD. Da würde ich ansetzen und die Dinger selektiv deaktivieren.


Viele Grüße,
Christian

weini

Noch ein kleiner Nachtrag:
Habe mir jetzt das HM-MOD-RPI-PCB besorgt und via USB-TTL Adapter (UM 2102) an meinen RPi angeschlossen.
Damit fahren alle 8 Rollläden bei gleichzeitiger Bedienung absolut sauber. Das entsprechende FHEM Modul und die Firmware scheinen bei ansonsten gleichen Voraussetzung (habe noch keine Module deaktiviert) deutlich resistenter gegen Timing Probleme zu sein.

Ich werde trotzdem nochmal weiterforschen, ob ich das via CUL auch noch sauber hinbekomme.

noansi

Hallo Christian,

da das AES Signing un ACK wohl vom HM-MOD-RPI-PCB abgearbeitet wird, so weit ich das verstehe, wundert mich das nicht.

Die TSculfw ermöglicht ein besseres Timing, aber FHEM muss die Sendedaten, auch AES Signing und ACK, doch früh genug bereit stellen.
Der eingeschränkte Speicher auf vielen CUL Hardware Plattformen, so auch nanoCUL, sind leider nicht sonderlich geeignet, um das AES und ACK auch auf CUL abzuarbeiten.
AES Signing wohl eher, da vom vorherigen Sendebefehl die hmId des device bekannt ist. Natürlich auf Kosten anderer Funkprotokolle.

Gruß, Ansgar.

noansi


MadMax-FHEM

Hi Ansgar,

klar gerne, kann aber etwas dauern...

Gibt es was besonderes zu testen/beachten?

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

#261
Hallo Joachim,

bezüglich AES Hängern habe ich eine Änderung in 10_CUL_HM.pm eingebaut.
Daher diese bitte mit testen.
Christian hatte zusätzlich Timing Probleme mit FHEM, so dass der IO zu seinem nanoCUL verzögert erschien, was beim gleichzeitigen Schalten seiner Rollos aufgefallen ist. Wäre interessant zu sehen, ob Du die Probleme auch hast. Es könnte ja auch eine Einschränkung in Verbindung mit dem nanoCUL USB-Seriell Schnittstellenbaustein sein, wenn der z.B. mit FIFO Threshold Pufferung arbeitet und daher Datenpakete erst dann komplett ankommen, wenn Sendeschwellen erreicht werden (auch wenn ich doch eher an FHEM Module mit langer Rechenzeit denke).

Die TS Firmware ist unverändert.

Ansonsten habe ich 00_TSCUL.pm/16_TSSTACKED.pm um einige nicht HM Protokolle erleichtert, so dass die Module, die ich zusätzlich beigepackt habe, unterstützt werden, ansonsten jedoch 00_CUL.pm und 16_STACKABLE_CC.pm genutzt werden müssen.
Es werden also die Module CUL_HM, TSKS300, TSCUL_WS, TSCUL_TX, TSIT, UNIRoll_TS, CUL_IR und HMS unterstützt.

Mit Rudolfs Tip https://forum.fhem.de/index.php/topic,24436.msg501057.html#msg501057 kannst Du nach dem Kopieren/Austausch der Dateien auch das Commandref aktualisieren und damit dann auch Doku lesen.

Gruß, Ansgar.

MadMax-FHEM

Zitat von: noansi am 19 Oktober 2016, 21:42:56
bezüglich AES Hängern habe ich eine Änderung in 10_CUL_HM.pm eingebaut.
Daher diese bitte mit testen.

Hmmm habe bislang noch nichts mit AES gemacht...
Mal sehen was ich noch an HM-Geräten am Testsystem hängen habe und dann mal nachlesen was/wie AES...
Kann aber bissi dauern.


Zitat von: noansi am 19 Oktober 2016, 21:42:56
Christian hatte zusätzlich Timing Probleme mit FHEM, so dass der IO zu seinem nanoCUL verzögert erschien, was beim gleichzeitigen Schalten seiner Rollos aufgefallen ist. Wäre interessant zu sehen, ob Du die Probleme auch hast. Es könnte ja auch eine Einschränkung in Verbindung mit dem nanoCUL USB-Seriell Schnittstellenbaustein sein, wenn der z.B. mit FIFO Threshold Pufferung arbeitet und daher Datenpakete erst dann komplett ankommen, wenn Sendeschwellen erreicht werden (auch wenn ich doch eher an FHEM Module mit langer Rechenzeit denke).

Hmmm, Rolloaktoren habe ich leider gar keine.
Wie bzw. mit welchen Aktoren könnte ich das "simulieren"??
Wobei ich eh nur einen Schaltaktor im Einsatz habe den ich verwenden könnte...
...mit mehrere gleichzeitig könnte also schwierig werden...


Zitat von: noansi am 19 Oktober 2016, 21:42:56
Die TS Firmware ist unverändert.

Ansonsten habe ich 00_TSCUL.pm/16_TSSTACKED.pm um einige nicht HM Protokolle erleichtert, so dass die Module, die ich zusätzlich beigepackt habe, unterstützt werden, ansonsten jedoch 00_CUL.pm und 16_STACKABLE_CC.pm genutzt werden müssen.
Es werden also die Module CUL_HM, TSKS300, TSCUL_WS, TSCUL_TX, TSIT, UNIRoll_TS, CUL_IR und HMS unterstützt.

Ok, dann kann ich den CUL ja mal lassen...
...und ansonsten kopiere ich einfach die neuen Module, oder!?
(Backup ja klar wobei nicht so entscheidend, da "nur" Testsystem/"Spielwiese"  ;-)   )


Zitat von: noansi am 19 Oktober 2016, 21:42:56
Mit Rudolfs Tip https://forum.fhem.de/index.php/topic,24436.msg501057.html#msg501057 kannst Du nach dem Kopieren/Austausch der Dateien auch das Commandref aktualisieren und damit dann auch Doku lesen.

Mache ich 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)

weini

ZitatHmmm, Rolloaktoren habe ich leider gar keine.

Das Problem kommt IMHO nicht von den Rollladenaktoren an sich sondern aus der Situation, wenn mehrere Aktoren gleichzeitig geschaltet werden sollen.
Bei mir sind das die Rollläden, für einen Test tun es aus meiner Sicht aber genauso Lichtschalter, Dimmer etc.

VG,
Christian

MadMax-FHEM

Zitat von: weini am 19 Oktober 2016, 23:05:13
Das Problem kommt IMHO nicht von den Rollladenaktoren an sich sondern aus der Situation, wenn mehrere Aktoren gleichzeitig geschaltet werden sollen.
Bei mir sind das die Rollläden, für einen Test tun es aus meiner Sicht aber genauso Lichtschalter, Dimmer etc.

VG,
Christian

Hi Christian,

jaja dachte ich mir schon...
...trotzdem: bei nur einem Aktor schwierig mehrere gleichzeitig ;-)

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 Testwillige,

es gibt hier https://forum.fhem.de/index.php/topic,24436.msg489979.html#msg489979 wieder eine Aktualisierung.
Ich habe in 10_CUL_HM.pm bei meinen Änderung zum AES Signing noch eine "Unschönheit" übersehen.

Gruß, Ansgar.

noansi

#266
Hallo Testwillige,

hier https://forum.fhem.de/index.php/topic,24436.msg635101.html#msg635101 geht's zur neuen Version!

---------------------------------------------------------------------------------------------------

ich habe nun einiges vom Timing und auch das AES Signing für HM mit in die Firmware aufgenommen.
Die AES Keys (3 Stück) können genau wie bei HMLAN gesetzt werden (von TSCUL Seite ist dafür der Befehl Ak ergänzt um 3 Keys zu setzen und die hmKey Attribute).

TSCUL versucht nun Befehle an ein device 3 mal abzusetzen, bis eine Antwort kommt.
Wenn ein device ein AES Signing anfordert, so führt dies TSCUL mit den verfügbaren Keys aus. Der Default Key ist natürlich auch in der Firmware hinterlegt.
Dies ist im Gegensatz zu HMLAN etc. auch das einzige automatische ACK seitens TSCUL, d.h. 10_CUL_HM.pm muss die sonstigen ACKS/NACKS weiterhin senden (rechtzeitig an TSCUL schicken).

Damit sind die Timing Probleme weiter entschärft, da Kommunikation von TSCUL zum device bezüglich Timing im Wesentlichen behandelt wirdt.
Bei Kommunikation eines devices zu TSCUL muss weiterhin FHEM via 10_CUL_HM.pm schnell genug eine Antwort liefern.

Je nach CUL Hardware werden bis zu 8 Sendepuffer verwaltet (einer wird stets für AES Signing genutzt). Mittels eines Flags wird stets eine "Unterhaltung"ssequenz zu einem device abgeschlossen, bevor Puffer mit Daten für andere Devices abgearbeitet werden. Aus diesen Sendedaten wird auch die eigene HMID "gelernt".
Bei Empfang eines unaufgefordeten Datenpakets von einem device an diese gelernte HMID mit Antwortanforderung wird von TSCUL ebenfalls eine "Unterhaltung" für ca. 400ms gesetzt, so dass eine Antwort von 10_CUL_HM.pm direkt entsprechend Antworttiming gesendet wird und so lange nichts an ein anderes device gesendet wird.

Im Anhang ist in TSCUL_fwcode_00_06_FHEM_Modules_00_06m.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC, TSCUNO2 und TSSCC.
Alle vorcompilierten .HEX Firmware Files haben 8 (+1) Sendepuffer konfiguriert.
Die .HEX files haben ein TS im Filenamen vorangestellt bekommen.

Ergänzender Hinweis: Nach dem flashen von TSCUL kann es sein, dass das Betriebssystem TSCUL eine neue Schnittstelle zuweist und ggf. auch anderen USB devices. Auf Linux mit "dmesg" heraus zu lesen.
Auch beim Neustart des Systems kann sich die Reihenfolge ändern. Bei meinem Raspi sogar abhängig von der Startart Reboot oder Einschalten.
Für CULs mit nativer USB Schnittstelle (z.B. CUL V3.x oder CUN) kann die \Firmware\tsculfw-code-459-trunk_lufa_00_04\culfw\Devices\99-usb-serial.rules nach /etc/udev/rules.d/99-usb-serial.rules kopiert werden. Dann wird CUL stets der Schnittstelle /dev/CUL868_0 (oder /dev/CUL433_0 bei 433.9MHz Version) zugewiesen und er kann mit
define CUL_868 TSCUL /dev/CUL868_0@12000000 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Das geht leider nicht bei nicht nativen USB CULs wie z.B. nanoCUL oder CUNO2. Hier muss eine 99-usb-serial.rules nach den Daten in der dmesg Ausgabe erstellt oder modifiziert werden, um den gleichen Effekt zu erzielen, sofern der USB-Seriell Interfacebaustein eine eindeutige Seriennummer liefert.
Ansonsten kann es noch mit der USB-Schnittstelle probiert werden, an der CUL eingesteckt ist ("lsusb" Ausgabe), was an meinem RasPi aber nicht funktioniert hat, da dieser abhängig von Warmstart oder Kaltstart andere USB-Portnummern vergibt.

In der TSCUL_fwcode_00_06_FHEM_Modules_00_06m.zip sind die neuen und geänderten Module zu finden.

00_TSCUL.pm         -> statt der 00_CUL.pm, aus CUL devices werden damit TSCUL devices in der fhem.cfg (händisch anzupassen)
DevIoTS.pm            -> verbesserte Version von DevIo.pm für die TS Module
CUL_Util.pm            -> Hilfsfunktionen, um CUL Typen abzufragen, für "Mischbetrieb"
16_TSSTACKED.pm -> statt der 16_STACKABLE_CC.pm, aus STACKABLE_CC werden damit TSSTACKED devices in der fhem.cfg (händisch anzupassen)

10_TSIT.pm            -> optional statt der 10_IT.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus IT wird dann TSIT in der fhem.cfg (händisch anzupassen), das normale IT sollte nun auch nutzbar sein
10_TSIT.pm ist entfallen. Bitte ggf. die fhem.cfg wieder auf IT umstellen und 10_IT.pm verwenden.
10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus UNIRoll wird dann UNIRoll_TS  in der fhem.cfg (händisch anzupassen)
13_TSKS300.pm     -> statt der 13_KS300.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen)
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus CUL_TX wird dann TSCUL_TX  in der fhem.cfg (händisch anzupassen)
14_TSCUL_WS.pm   -> statt der 14_CUL_WS.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

10_CUL_HM.pm muss ausgetauscht werden, bis @Martin die notwendigen Änderung in den Standard übernommen hat. Hier wird auf CUL_Util.pm zurück gegriffen, um den CUL Typ abzufragen.
10_CUL_HM.pm muss nicht mehr ausgetauscht werden, da Martin die notwendigen Änderung in den Standard übernommen hat. Bitte ggf. attr global exclude_from_update entsprechend anpassen, um den automatischen update für 10_CUL_HM.pm wieder zuzulassen.

Mischbetrieb mit 00_CUL.pm und 16_STACKABLE_CC.pm ist nicht möglich ohne Anpassungen im Code dieser Module. Das ist nur relevant für einen Stapel aus SSC + COC/CCD Modulen.
Wer also mit einem weiteren CUL z.B. die a-culfw nutzen möchte, kann dies nicht ohne weiteres mit einem SCC Modul tun, wenn im SCC/COC Stapel auch TSCUL für z.B. HM genutzt werden soll.

Mischbetrieb mit 00_CUL.pm und 16_STACKABLE_CC.pm ist ab # $Id: 00_CUL.pm 12983 2017-01-06 13:53:27Z StefanStrobel $  und # $Id: 16_STACKABLE_CC.pm 12973 2017-01-06 10:01:25Z StefanStrobel $ möglich da Rudolf die Änderungen eingebaut hat. Danke!

Wie immer, vor Austausch und Veränderungen der module und fhem.cfg, erst Backup dann Ändern!

Mit folgendem Eintrag (oder Ergänzung des attributs) in der fhem.cfg kann man das fhem Update am ungewollten Austausch der angepassten Module hindern:

attr global exclude_from_update 00_TSCUL.pm 16_TSSTACKED.pm DevIoTS.pm CUL_Util.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm CalcUtil.pm


Hier https://forum.fhem.de/index.php/topic,24436.msg501057.html#msg501057 noch Rudolfs Tip zur Aktualisierung des Commandref  nach dem Kopieren/Austausch der Dateien so dass dann auch Doku zur Nutzung zu lesen ist.

fhem> { `perl contrib/commandref_join.pl` }


Gruß, Ansgar.

EDIT: Commandref um hmKey ergänzt.
EDIT: Update VTS 0.04 CCA geändert
EDIT: Update VTS 0.05 Bug in Sendewarteschlange behoben und Code für richtige Sendereihenfolge zum gleichen device bei gleicher Message Nummer und FHTID wird nicht mehr von TSCUL gesetzt, wenn 'T' nicht unterstützt wird (z.B. nanoCUL), 10_CUL_HM mit TSCUL auf Stand 12707 gebracht
EDIT: 10_CUL_HM.pm muss nicht mehr ausgetauscht werden ab Stand # $Id: 10_CUL_HM.pm 12943 2017-01-03 08:35:18Z martinp876 $
EDIT: CCA Einstellung für IT und SlowRF Default unempfindlicher gewählt
EDIT: TSCUL um set ITClock ergänzt -> IT sollte statt TSIT nutzbar sein
EDIT: Update VTS 0.06 CCA Korrekturen, ASKSIN Wiederholtiming verkürzt und HEX Files um TS im Namen ergänzt. TSIT entfällt -> IT verwenden
EDIT: TSCUL_fwcode_00_06_FHEM_Modules_00_06m.zip enthält nun source für miniCUL (ungetestet)

klausw

Hi Ansgar,

Zum Glück bin ich auf diesen Thread gestoßen.
Endlich funktionieren meine HM-SEC-SCo anstandslos.


Es tauchen allerdings noch Perlwarnungen im Log auf:

2016.11.29 00:07:17 1: PERL WARNING: keys on reference is experimental at ./FHEM/00_TSCUL.pm line 1008, <$fh> line 37.
2016.11.29 00:07:17 1: PERL WARNING: keys on reference is experimental at ./FHEM/00_TSCUL.pm line 1017, <$fh> line 37.
2016.11.29 00:07:17 1: PERL WARNING: keys on reference is experimental at ./FHEM/00_TSCUL.pm line 1180, <$fh> line 37.
2016.11.29 00:07:17 1: PERL WARNING: keys on reference is experimental at ./FHEM/00_TSCUL.pm line 1866, <$fh> line 37.
2016.11.29 00:07:17 1: PERL WARNING: keys on reference is experimental at ./FHEM/00_TSCUL.pm line 1875, <$fh> line 37.


Am Beispiel von Zeile 1008:
foreach (keys $unkndst){
zu
foreach (keys %{$unkndst}){

behebt die Warnungen.

Grüße
Klaus
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

christian.asd

Zitat von: klausw am 29 November 2016, 00:45:28
Zum Glück bin ich auf diesen Thread gestoßen.
Endlich funktionieren meine HM-SEC-SCo anstandslos.

Bei mir das Gleiche. Danke für die Arbeit!!

Bastel-Frank

Ich möchte sehr gerne die neue Firmware testen, da ich mit mehreren Devices Kommunikationsprobleme habe.

Ich benötige aber etwas Nachhilfe: Die Firmware ist geflasht, die neuen Module in fhem kopiert. In der fhem.cfg habe ich folgende Änderung eingetragen:
define CUL_01 TSCUL /dev/ttyACM0@9600 1034

Nur leider wird dann der CUL nicht initialisiert. Was mache ich falsch?