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

[Bastel-Frank]

Hallo Ansgar,

ich werde mir eine Testumgebung aufbauen und die aktuelle Version dort zunächst verproben. Sollte diese dort laufen, wovon ich ausgehe, dann werde ich nochmal in die Produktivumgebung gehen.

Du hast recht, der CUL_KG hängt direkt im System (ohne ser2net). Mit dem CUL_EG werde ich mir speziell nochmal ansehen.

Ich hatte alle Dateien aus deinem ZIP, Ordner FHEM in meine Umgebung kopiert.

Was macht das autoReadReg? Ich höre dies zum ersten Mal.

Viele Grüße
Frank

[noansi]

Hallo Frank,

Was macht das autoReadReg? Ich höre dies zum ersten Mal.

Es steht standardmäßig auf 4, was bedeutet, dass bei jedem Systemstart für alle HM devices auch ein getConfig ausgeführt wird.

Mit 5 wird nur ein getConfig ausgeführt, wenn keine gespeicherten Registerwerte vorliegen. Zusammen mit HMinfo und autoArchive zu nutzen.

Gruß, Ansgar.

[Bastel-Frank]

Mit 5 wird nur ein getConfig ausgeführt, wenn keine gespeicherten Registerwerte vorliegen. Zusammen mit HMinfo und autoArchive zu nutzen.

Ahh, Sehr gut, dann werde ich alles umstellen ...

[noansi]

Hallo Frank,

mir ist aufgefallen, dass 00_TSCUL.pm noch ein Problem bei Nutzung mehrerer TSCULs für HM hat, wenn diese auch die HM devices eines anderen empfangen der gerade gesendet hat.

Im Anhang eine Aktualisierung zum Testen.

Gruß, Ansgar.

[Bastel-Frank]

mir ist aufgefallen, dass 00_TSCUL.pm noch ein Problem bei Nutzung mehrerer TSCULs für HM hat, wenn diese auch die HM devices eines anderen empfangen der gerade gesendet hat.

... dann müßte dieses Problem nach der Version 06 dazugekommen sein, weil ich mit der 06 seit einigen Wochen produktiv bin (mit den 4 CULs).

[noansi]

Hallo Frank,

dann müßte dieses Problem nach der Version 06 dazugekommen sein

War da auch schon drin. Es fällt erst beim genaueren Hinsehen auf, z.B. getConfig dass recht lange benötigt, wenn ein langsam angebundener CUL benutzt wird. Die Sendewarteschlange des langsamen wird langsam abgearbeitet, da empfangene Antworten nicht als solche erkannt werden, weil der schnellere CUL schon die Flags ablöscht.

Gruß, Ansgar.

[Bastel-Frank]

Hallo Ansgar,

ich bin jetzt auf die Version 10 gewechselt und alles läuft wieder  . Ich nehme an, das Problem hingt tatsächlich mit dem autoReadReg der Devices zusammen. Beim Start hat das das System schlichtweg überlastet. Ich habe jetzt alle auf autoReadReg=5 stehen und es ist Ruhe eingekehrt.

Bei den ersten Versuchen mit der Versuchen 10 ist mit aufgefallen, dass die weiter entfernten Devices mit kritischem Empfang jetzt spontan reagieren. Dies kann aber auch andere Gründe haben oder es ist Zufall. Oder hast Du die Firmware dahingehend optimiert?

Viele Grüße
Frank

[noansi]

Hallo Frank,

Bei den ersten Versuchen mit der Versuchen 10 ist mit aufgefallen, dass die weiter entfernten Devices mit kritischem Empfang jetzt spontan reagieren.

Hast Du die letzte Version 00_TSCUL.pm (vom 7.9.17) jetzt im Einsatz?
Dann wir es eher an der liegen, da Du vermutlich weiter entfernte Devices über die per sernet angebundenen CULs nutzt?!?

Gruß, Ansgar.

[Bastel-Frank]

Hast Du die letzte Version 00_TSCUL.pm (vom 7.9.17) jetzt im Einsatz?

Ja, klar, die habe ich genommen.

[noansi]

Hallo Testwillige,

hier eine neue Version 0.15 der Timestamp Firmware und der dazu benötigten FHEM Module.

Geändert ist diesmal eine Verbesserung bezüglich der Wiederholung von AESCommReq Nachrichten seitens des devices, wenn der erste Versuch nur am Empfang der abschließenden Quittung seitens des devices gescheitert ist. In der Version 0.14 wurde dann eine erneute Challenge gesendet, was mein Testdevice jedoch wenig interessiert hat. Nun wird diese Challenge durch TSCUL mit der schon bekannten Abschlussquittung ersetzt. Dies funktioniert und damit wird diese Kommunikation noch stabiler.

Außerdem ist mir noch sicherheitskritisch aufgefallen, dass bei low Battery Warnung wegen des zusätzlich gesetzten Bits im Channel Byte keine Signierung von der Version 0.14 angefordert wurde. Dies ist in dieser neuen Version behoben.

Diese Version bietet AESCommReq Unterstützung durch die tsculfw. Dazu wird im EEPROM des CULs eine Liste mit AESCommReq Kanälen und deren zu nutzende KeyNummer verwaltet. In einem CUL V3 ist die Liste auf 81 Einträge begrenzt. Ein SCC oder COC kann bis zu 209 Einträge verwalten.
Trifft nun eine Triggernachricht ein, so sendet tsculfw eine Challenge und prüft die Antwort auf gültige Authentifizierung, so (ähnlich) wie es der AES-Code von Michael Gernoth in 10_CUL_HM.pm für CULs macht. Nur bei gültiger Authentifizierung wird die auslösende Empfangsnachricht mit AUTH-Bytes durch die tsculfw an FHEM weiter gereicht. 10_CUL_HM.pm muss abschließend einen ACK mit den AUTH-Bytes senden. Dazu ist eine entsprechend modifizierte 10_CUL_HM.pm beigefügt (Ich hoffe, Martin übernimmt das wieder in den Standard).
Damit läuft der Authentifizierungsprozess in der Firmware mit dem Vorteil des stabilen Timings ab. FHEM muss also nur die ACKs zeitgerecht liefern, wie es bisher auch ohne AES der Fall ist.

Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 5 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei der ungetesteten nanoCUL und miniCUL Version habe ich nur 3 Empfangspuffer vorgesehen, um den Restpeicher für den Stack zu erhalten. Vielleicht hat jemand die Möglichkeit, die max. Stacknutzung mal ausgiebig zu testen, damit der verbleibende Speicher optimal "ausgequetscht" werden kann???

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_15_FHEM_Modules_00_16.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC, TSCUNO2 und TSSCC. Jedoch nur mit einem AESCommReq tauglichen Bewegungsmelder.

Die tsculfw Firmware kann für TSCUL_V3 und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:

Code Auswählen Erweitern

TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:

Code Auswählen Erweitern

#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034

Ergänzender Hinweis zu USB CULs: 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_08\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

Code Auswählen Erweitern

define CUL_868 TSCUL /dev/CUL868_0@12000000 1234
bzw.

Code Auswählen Erweitern

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 Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 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 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  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.

Außerdem:

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Derzeit ist die Nutzung dieses Moduls zwingend erforderlich!!!
98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

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:

Code Auswählen Erweitern

attr global exclude_from_update 10_CUL_HM.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 98_TSCULflash.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.

Code Auswählen Erweitern

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

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.15 ab. Eine ältere Version wird also nicht unterstützt, da sich diesmal auch das Timestamp Protokoll (inkompatibel zum vorherigen Stand) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

EDIT: Da ich für gewöhnlich nur einen CUL für HM nutze ist mir erst bei einem Test mit 2 CULs im HM Modus aufgefallen, dass die Mehr-CUL Nutzung noch erhebliche Probleme mit der IODev Zuordnung machte. Daher ein Update der Module 00_TSCUL.pm und 10_CUL_HM.pm mit der TSCUL_fwcode_00_15_FHEM_Modules_00_16.zip.
Damit verbunden noch ein Tip zur Haltbarkeit des CULs. Jedesmal, wenn einem HM-Device mit gesetzem aesCommReq=1 das IODev neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf

Code Auswählen Erweitern

attr HMdeviceName IOgrp VCCU
setzen, sondern

Code Auswählen Erweitern

attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.

Gruß, Ansgar.

Vorherige Version ohne AESCommReq: https://forum.fhem.de/index.php/topic,24436.msg640892.html#msg640892

[noansi]

Hallo Testwillige,

die Firmware (und Module) im vorherigen Beitrag ist aktualisiert auf Version 0.15.

Mir noch sicherheitskritisch aufgefallen, dass bei low Battery Warnung wegen des zusätzlich gesetzten Bits im Channel Byte entsprechender Nachrichten keine Signierung von der Version 0.14 angefordert wurde. Dies ist in der neuen Version behoben.

Gruß, Ansgar.

[noansi]

Hallo Testwillige,

ich habe den vorvorherigen Beitrag nochmal geändert, da mir Probleme bei MehrCUL Nutzung im HM Modus aufgefallen sind. Siehe auch EDIT.
00_TSCUL.pm und 10_CUL_HM.pm zur Firmware VTS 0.15 sind aktualisiert, wie auch hier angehangen.

Gruß, Ansgar.

[noansi]

Hallo Testwillige,

hier eine neue Version 0.17 der Timestamp Firmware und der dazu benötigten FHEM Module.

Ergänzt ist diesmal ein Auto ACK für default Quittungen zusätzlich zur AESCommReq Unterstützung. D.h. tsculfw sendet diese für bekannte HM-Devices/-Kanäle, für die eine Liste im EEPROM geführt wird. Ein CUL kann bis zu 210 Eintrage verwalten, ein COC oder SCC bis zu 254.

Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 5 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei der ungetesteten nanoCUL und miniCUL Version habe ich nur 3 Empfangspuffer vorgesehen, um den Restpeicher für den Stack zu erhalten. Vielleicht hat jemand die Möglichkeit, die max. Stacknutzung mal ausgiebig zu testen, damit der verbleibende Speicher optimal "ausgequetscht" werden kann???

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_17_FHEM_Modules_00_18.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC, TSCUNO2 und TSSCC. Jedoch nur mit einem AESCommReq tauglichen Bewegungsmelder für AES.

Die tsculfw Firmware kann für TSCUL_V3 und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen noch nicht getestet (nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:

Code Auswählen Erweitern

TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:

Code Auswählen Erweitern

#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034

Ergänzender Hinweis zu USB CULs: 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_08\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

Code Auswählen Erweitern

define CUL_868 TSCUL /dev/CUL868_0@12000000 1234
bzw.

Code Auswählen Erweitern

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 Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 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 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  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.

Außerdem:

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Derzeit ist die Nutzung dieses Moduls zwingend erforderlich!!!
98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

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:

Code Auswählen Erweitern

attr global exclude_from_update 10_CUL_HM.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 98_TSCULflash.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.

Code Auswählen Erweitern

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

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.17 ab. Eine ältere Version wird also nicht unterstützt, da sich diesmal auch wieder das Timestamp Protokoll (inkompatibel zum vorherigen Stand) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Noch ein Tip zur Haltbarkeit des CULs. Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf

Code Auswählen Erweitern

attr HMdeviceName IOgrp VCCU
setzen, sondern

Code Auswählen Erweitern

attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.

Gruß, Ansgar.

Vorherige Version ohne Auto Ack: https://forum.fhem.de/index.php/topic,24436.msg699202.html#msg699202

EDIT: Aktualisiert auf TSCUL_fwcode_00_17_FHEM_Modules_00_18 wegen Matchkorrekturen und -optimierungen in Modulen. Firmware unverändert.

[noansi]

Hallo Testwillige,

hier eine neue Version 0.18 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diesmal sind die Module nochmal bezüglich Matches überarbeitet.
In der Firmware ist das Timing noch etwas verkürzt. In meiner Testumgebung verbessert das die AES Kommunikation inbesondere zu Batteriebetriebenen devices.
Außerdem ist noch etwas mehr Flash Speicher durch komplett optionale Verwendung von FastRF für die Verwaltung von HM-Devices/-Kanälen frei geworden, so dass nun auf einem CUL V3 220 Kanäle möglich sind.
Die EEPROM Versionsnummer hat sich danit auch geändert, was zur Folge hat, dass das EEPROM nach dem Flashen auf Defaultwerte zurück gesetzt wird. (also ggf. vor dem Flashen individuelle Einstellung notieren)

In TSCULflash ist der Versuch des Flashens auch von NanoCULs und MiniCULs ergänzt. Da ich es aber mangels Hardware nicht testen kann, bitte ich um Feedback, ob es funktioniert. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen. Wäre nett, wenn das mal jemand testen und Feedback geben könnte.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit

Code Auswählen Erweitern

TSCULflash <nanodevicename> TSnanoCUL
bzw.

Code Auswählen Erweitern

TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

AESCommReq wird. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 5 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei der ungetesteten nanoCUL und miniCUL Version habe ich nur 3 Empfangspuffer vorgesehen, um den Restpeicher für den Stack zu erhalten. Vielleicht hat jemand die Möglichkeit, die max. Stacknutzung mal ausgiebig zu testen, damit der verbleibende Speicher optimal "ausgequetscht" werden kann???

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_18_FHEM_Modules_00_19.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC, TSCUNO2 und TSSCC. Jedoch nur mit einem AESCommReq tauglichen Bewegungsmelder für AES.

Die tsculfw Firmware kann für TSCUL_V3 und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen noch nicht getestet (nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:

Code Auswählen Erweitern

TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:

Code Auswählen Erweitern

#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034

Ergänzender Hinweis zu USB CULs: 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_08\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

Code Auswählen Erweitern

define CUL_868 TSCUL /dev/CUL868_0@12000000 1234
bzw.

Code Auswählen Erweitern

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 Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 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 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  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.

Außerdem:

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Derzeit ist die Nutzung dieses Moduls zwingend erforderlich!!!
98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

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:

Code Auswählen Erweitern

attr global exclude_from_update 10_CUL_HM.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 98_TSCULflash.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.

Code Auswählen Erweitern

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

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.16 ab. Eine ältere Version wird also nicht unterstützt, da sich diesmal auch wieder das Timestamp Protokoll (inkompatibel zum vorherigen Stand) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Noch ein Tip zur Haltbarkeit des CULs. Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf

Code Auswählen Erweitern

attr HMdeviceName IOgrp VCCU
setzen, sondern

Code Auswählen Erweitern

attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.

Gruß, Ansgar.

Vorherige Version: https://forum.fhem.de/index.php/topic,24436.msg708709.html#msg708709

[klausw]

Hallo noansi,

habe die 0.18 mit TSCULflash auf einen NanoCUL  geflashed

Code Auswählen Erweitern

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e952b
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "./FHEM/firmware/TSnanoCUL.hex"
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex auto detected as Intel Hex
avrdude: writing flash (28372 bytes):

Writing | ################################################## | 100% 12.13s

avrdude: 28372 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/TSnanoCUL.hex:
avrdude: load data flash data from input file ./FHEM/firmware/TSnanoCUL.hex:
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex contains 28372 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 12.05s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x133d
         0x94 != 0xe0
avrdude: verification error; content mismatch

avrdude done.  Thank you.

Gab zwar verification Fehler, aber das liegt evtl. an der Hardware.
Es scheint trotzdem alles zu funktionieren.
Super Arbeit

Wie kann ich denn die max. Stacknutzung testen?

Grüße
Klaus