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

[noansi]

Hallo Harald,

ich habe keine HM gesteuerten Rollos, daher kann ich dazu nichts selber testen.

Daher bitte ein Device List (CUL+Rollos) und ein Log (mit verbose 4 beim nanoCul) zu Deinem Problemfall.
Und zwar ein Log mit dem Steuern nur eines Rollos möglichst ohne dass was anderes noch dazwischen funkt.
Und dann ein Log mit dem Steuern mehrerer Rollos auf einmal.

Außerdem zeigt sich mit TSCUL das gleiche fehlerhafte Verhalten, dass nicht auf ein ACK gewartet wird bevor ein neuer Funkbefehl gesendet wird.

Das ist so nicht richtig. Wenn ein Befehl mit Ack-Anforderungs Flag gesendet wird, wartet die Firmware eine gewisse Zeit auf die Antwort, bevor ein weiterer Befehl gesendet wird. Aber ich kann nicht ausschließen, dass es für Deine Rollos nicht passt, also die z.B. nicht innerhalb dieser Zeit antworten.
Bezüglich Sendezeiten müssen die Sendequittungen ausgewertet werden. As schickt nur eine Sende-message an CUL.

Außerdem darfst Du für HM generell nicht FHEM mit busy waiting oder hoher Auslastung am rechtzeitigen Senden und Verarbeiten weiterer HM-Nachrichten hindern.

TSCUL_Parse: nanoCul  139750 A FF13 08120968 01 0E 3E B011 133A3C 35F481 02 _bst _CCAdly:4 -138

139750

Zeit (ms) des Starts der Verarbeitung einer HM Nachricht in 00_TSCUL.pm (also in FHEM)

A

ASKSIN message vom CUL

FF

Kennung für Timestamp ASKSIN message (eigentlich nur das erste der beiden F, das zweite kann noch Verwendung finden)

13

grober credits Stand und Typ der message (1=Empfangene Nachricht, 2=ping, 3=Sendequittung, 0 und 4 bis 7 Sendefehler)

08120968

Timestamp in ms auf CUL zu der die message erzeugt wurde

01

CCA Verzögerung in 4ms Einheiten, 1 ergibt sich schon durch das Umschalten auf Senden

0E 3E B011 133A3C 35F481 02

hier so viel von der gesendeten Nachricht, dass sie eindeutig wieder zu erkennen ist

Was bedeuten  "_bst"

Das Burst Flag ist gesetzt, d.h. es wird die lange 300ms Aufweckpräambel statt der nomalen 10ms gesendet

Was bedeutet "_CCAdly:4"

CCA bedingte Zusatzverzögerung (wenn der Kanal nicht frei ist, 4 ergibt sich bereits durch die Umschaltung auf Senden bei freiem Kanal)

- Was bedeutet: "TSCUL_XmitDlyHM:  nanoCul  id:35F481 dDly:95 toms:33"

00_TSCUL.pm interne Verzögerungszeiten für das Senden an CUL.

- Was bedeutet: "_dhmSt"

Antwortzeit bezogen auf die letzte vom device empfangene Nachricht in ms

00_TSCUL.pm kennt übrigens das Attribut hmLanQlen.

Hast Du die Firmware aus "TSCUL_fwcode_00_06_FHEM_Modules_00_06m.zip" von hier https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 geflasht? Das ist die aktuellste.

Gruß, Ansgar.

[b4rRa]

Hallo

ich habe auf meinem nanoCUL mittlerweile die TS_CUL Firmware laufen. Ich habe wie nachgefragt, direkt die fertige hex-File für den nanoCUL geflasht. Prinzipiell läuft es auch. Aber ich bekomme leider im Log ziemlich oft folgende Fehler

2017.03.16 17:42:25 1: TSCUL_ParseTsHM nanoCUL_868_HM HM repeat failed sending to 30C21A/Bastelecke: AFF600001029F000E50A011A1B2C330C21A02

es werden dann teilweise Befehle nicht ausgeführt oder der Status nicht aktualisiert. Ich bekomme dann einen NACK als state. Den Fehler bekomme ich auch immer wenn ich einen status request über das Device manuell ausführe.

[noansi]

Hallo 

ohne List vom nanoCul, Linst vom device und Log mit Verbose 4 beim nanoCul wirst Du meine Glaskugel leider nicht sehr erhellen können.

Möglicherweise kann nanoCul nicht senden, weil er z.B. nah an einer Störquelle liegt. Oder das Device antwortet nicht oder ist zu weit weg oder dicht dran. Oder Du versuchst mehrere devices gleichzeitig zu schalten und das scheitert dann an der Kanalbelegung bezüglich des rechtzeitgen Empfangs. Usw...

[b4rRa]

Hallo

Danke für Deine Antwort! Ja, das mit der Glaskugel ist immer so eine Sache.. Meist dann kaputt wenn man sie braucht

Habe mir das Wochenende frei genommen und werde noch mal einige Sachen testen.. Sollte ich weiterhin Probleme haben, werde ich mich mit diversen Logs wieder melden

VG

[Manul]

Ich habe gerade versucht, die Firmware zu flashen, bin aber nicht sicher, ob's erfolgreich war, da die udev-Regeln nicht greifen und der vorher definierte CUL weiter zu funktionieren scheint. Mein CUL meldet sich mit Version "V 1.66 CUL868" - welchen Versionsstring würde denn die aktuelle TS-Firmware ausgeben?

[noansi]

Hallo Manul,

die Versionsinfo der TS Firmware fängt mit "VTS" statt "V" an.
Du warst offenbar nicht erfolgreich.

Gruß, Ansgar.

[Manul]

Danke. Ich bin wie folgt vorgegangen:

• Zip-Archiv aus diesem Post runtergeladen und entpackt
• alle Module aus FHEM nach /opt/fhem/FHEM kopiert, fhem neu gestartet
• Firmware/TSCUL_V3.hex nach /opt/fhem/FHEM/firmware/CUL_V3.hex kopiert

[li]CULflash <CUL> CUL_V3 in fhem eingegeben
[/li][/list]

Allerdings scheine ich jetzt in /opt/fhem/FHEM/firmware/CUL_V3.hex eine neuere und größere Datei zu haben. Wo liegt mein Fehler?

Nebenbei: Wäre es nicht an der Zeit, der TSCUL-Firmware mal eine Seite im Wiki zu spendieren? Und die Firmware selbst vielleicht irgendwo außerhalb dieses Threads zu hosten? Es ist schon etwas mühsam, sich hier durch den Thread wühlen zu müssen. Bei einer Wiki-Seite helfe ich auch gerne mit.

[noansi]

Hallo Manul,

Du hast anscheinend einen CUL V3!?!

CULflash geht nicht, da es aus dem Internet die aktuelle Standard Firmware runter lädt und diese dann flashed (wie es auch das Commandref beschreibt).

Die folgende Beschreibung gilt für einen Rapsberry Pi, also Linux.

Um den CUL V3 also mit der tsculfw zu flashen musst Du erst mal dfu-programmer installiert haben.

Dann muss der CUL V3 mittels dem Befehl "B01" in den Bootloader gestartet werden (mach ich in FHEM mit set raw beim CUL und FHEM kann normalerweise weiter laufen). Alternativ geht es auch mit Taste am CUL drücken und mit gedrückter Taste CUL in den USB Port stecken.

Dann in einem Terminal zum Verzeichnis der hex Datei wechseln und dann:

Code Auswählen Erweitern

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

Dann sollte der CUL V3 mit TSCUL_V3.hex geflashed werden und neu booten.
Und diese Beschreibung gilt nur für CUL V3. Andere Typen benötigen einen anderen Programmer und ein anderes Vorgehen.

Wäre es nicht an der Zeit, der TSCUL-Firmware mal eine Seite im Wiki zu spendieren?

Wenn Du Zeit dafür hast, gerne.

Gruß, Ansgar.

[Manul]

Danke, ich hab in der Tat einen CUL_V3 an einem Raspi. Über die derzeit installierte culfw kann ich den doch auch in den Bootloader starten, oder?

Was soll hier:

Code Auswählen Erweitern

sudo dfu-programmer atmega32u4 erase || true

das "|| true" bewirken?

Wenn Du Zeit dafür hast, gerne.

So nach und nach werde ich die schon finden. Muß ja nicht alles sofort sein. Wo kann ich denn nachlesen, welche Probleme TSCUL behebt bzw. was die Motivation für deren Entwicklung war. Ich habe hier im Thread den Eindruck, daß das vorherige Problem als bekannt vorausgesetzt wird.

Und gibt es eigentlich einen Grund, warum die TS-features nicht in die "offizielle" culfw aufgenommen wurden?

[rudolfkoenig]

Und gibt es eigentlich einen Grund, warum die TS-features nicht in die "offizielle" culfw aufgenommen wurden?

Die Aenderungen waren/sind so umfangreich, dass ich das nicht alles verstanden habe bzw. testen konnte.
Weiterhin haben wir (Ansgar und ich) unterschiedliche Philosophien, wie man mit seltenen bzw. schwer reproduzierbaren Problemen umgeht.

Zusaetzlich habe ich die Motivation verloren culfw fuer HM zu optimieren, da ich das FHEM Modul nicht mehr betreue, und auch keine Geraete mehr im Betrieb habe.

[noansi]

Hallo Manul,

Über die derzeit installierte culfw kann ich den doch auch in den Bootloader starten, oder?

Ja, ebenfalls B01.

das "|| true" bewirken?

Habe ich so stumpf aus dem makefile übernommen, da ich normalerweise über make auch flashe.
Vermutlich soll es bei einer Fehlermeldung diese bezüglich Rückgabe unterdrücken? Der Ersteller des ursprünglichen makefiles wird es wohl wissen. 
Vermutlich kannst Du das || true wohl auch weglassen.

Die Aenderungen waren/sind so umfangreich, dass ich das nicht alles verstanden habe bzw. testen konnte.

War und ist eine tolle Ausgangsbasis für die Änderungen und Anpassungen.

Alle meine Bugs habe ich mangels Testhardware sicherlich auch noch nicht gefunden. So ist mir jüngst aufgefallen, dass SlowRF EM in der aktuellen Version noch nicht funktioniert. Wird in der nächsten Firmwareversion funktionieren.

Wo kann ich denn nachlesen, welche Probleme TSCUL behebt bzw. was die Motivation für deren Entwicklung war.

In diversen Threads, hauptsächlich hier und bezüglich HM im Homematic Forum.

Ich habe mit HM, wie so viele, das Problem mit culfw gehabt, dass die Geräte bezüglich Empfangstiming von Antworten empfindlich sind. Das gesamte Protokoll wird nur mit einer einfachen CUL Warteschlange und FHEM Timer bezüglich Sendezeitpunkt abgearbeitet.
Daher habe ich zunächst versucht in 00_CUL.pm Verbesserungen zu erzielen. Das geht aber nur bis zu einem gewissen Grad, da FHEM strukturbedingt Timer nicht genau einhalten kann.

Daher bin ich auf den Gedanken gekommen, culfw mit Timing arbeiten zu lassen. Dazu habe ich die ASKSIN Befehle Aw und Aa ergänzt, mit denen auf CUL vor dem Senden gewartet werden kann (Aw) oder zu einem bestimmten Zeitpunkt gesendet werden kann (Aa).
Damit FHEM auch Sendezeitpunkte liefern kann habe ich das Schnitstellenprotokoll um zusätzliche Informationen ergänzt, insbesondere einen Zeitstempel (Timestamp) für Empfangsdaten und Sendequittungen. Damit läßt sich schon sehr viel bezüglich Timing erreichen, wenn FHEM nicht ab und zu mal so "richtig lang trödeln" würde.
Das stört dann doch insbesondere bei aktivem AES, da dabei Stellbefehle auch noch im passenden Timing signiert werden müssen.
Da Rudolf meine Änderungen nicht übernommen hat und damit auch der Grund für Flashspeicherschonende Programmierung entfallen ist (CUL_V2 muss es nicht mehr tun), habe ich im nächsten Schritt AES Signierungen ebenfalls auf CUL gebracht, was dann eine Nachrichtenwarteschlange auf dem CUL nötigt machte und somit auch noch mehr Sendetimingoptimierung durch CUL ermöglicht hat. Die befehle Aa und Aw sind damit eigentlich hinfällig und fliegen wohl auch mal wieder raus.
Damit gibt es nur noch den Schwachpunkt beim Antworttiming durch Antworten, die nur durch 10_CUL_HM.pm erfolgen können.

Zusätzlich hatte ich mit CUL_V3 das Problem des gelegentlichen "Verschwindens" von CUL_V3 als USB Device.
Dazu habe ich einige Änderungen an der USB Kommunikation in tsculfw eingebaut, die bei mir auch die Stabilität verbessert haben nebst Änderungen an DeviceIo.pm, um ein kurzzeitig abgemeldetet device wieder an die gleiche Schnittstelle zu bekommen.
Um CUL V3 immer an die gleiche Schnittstelle zu bekommen, was beim RasPi je nach Startart unterschiedlich sein kann, habe ich eine USB Seriennummer eingebaut.
Diese kann in der board.h vor dem compilieren angepasst werden. Für 868er CULs lautet sie
"868000" und für 433er CULs "433000".

Bei CUNO2 habe ich Stabilitätsverbesserungen an der Netzwerkschnittstelle einfließen lassen, was im Wesentlichen am Netzwerktreiber lag.

Bei SCC habe ich insbesondere die Stackingschnitstelle zu höheren devices im Stapel optimiert. Im "Original" wurden Nachrichten für das nächste device immer erst komplett empfangen und dann nach oben weiter gereicht. Das ist in tsculfw geändert in Weiterreichen ab dem ersten Zeichen, so dass die Sendezeit zum richtigen Stackmitglied drastisch verkürzt ist.
Da ich einen COC auf einem SCC betreibe und dieser COC HM macht dient das auch der HM Optimierung.

Zusätzlich gibt es Änderungen an SlowRF, da ich mit der Auswertung der Empfangsdaten nicht glücklich war. Das ist nur getestet, so weit ich auch Testhardware greifbar habe.
...

Gruß, Ansgar.

[Manul]

Noch eine Verständnisfrage zu AES: Wie interagieren die auf dem CUL gespeicherten Schlüssel mit denen in FHEM?

[noansi]

Hallo Manul,

Wie interagieren die auf dem CUL gespeicherten Schlüssel mit denen in FHEM?

Das Verhalten ist analog zu HMLAN.
Du setzt den/die Schlüssel bei TSCUL (oder VCCU) via Attribut und dann werden sie von FHEM in TSCUL gesetzt.

Gruß, Ansgar.

[Manul]

Danke! Das heißt also, der Umstieg von CUL auf TSCUL ist quasi vollständig transparent, sofern man eine VCCU nutzt? Ich muß mich nur um den Schlüssel der VCCU kümmern, den Rest erledigt FHEM?

[noansi]

Hallo Manul,

den Rest erledigt FHEM?

Die fhem.cfg musst Du schon noch anpacken, damit die TS Module genutzt werden.

Gruß, Ansgar.