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

[Manul]

Hallo Ansgar,

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

Schon klar. Ich meinte lediglich in Bezug auf AES.

[noansi]

Hallo Zusammen,

ein Hinweis im Bezug auf OTA Firmware Updates via FHEM.
Mit der aktuellen TSCUL und tsculfw klappt es leider nicht, da der Hochschaltbefehl auf 100kbits für CUL den Hochschaltfunkbefehl an das Device "überholt", so dass dieser fälschlicherweise mit 100kbits an das noch auf 10kbits lauschende device gesendet wird.

Das wird mit der nächsten TSCUL Version mit einer Wartezeit in TSCUL behoben.

Michael Gernoth aktuelles flash-ota Tool 0.03 aus hmcfgusb-0.103 kann alternativ ohne fhem genutzt werden, da es Anpassungen an tsculfw enthält und funktioniert.

Übergangsweise kann aber auch in 10_CUL_HM.pm die Wartezeit vor dem Hochschalten erhöht werden also:

Code Auswählen Erweitern

sub CUL_HM_FWupdateSteps($){#steps for FW update
  my $mIn = shift;

...

    CUL_HM_SndCmd($hash,"${mNoA}00CB$id${dst}105B11F81547");
#    CUL_HM_SndCmd($hash,"${mNoA}20CB$id${dst}105B11F815470B081A1C191D1BC71C001DB221B623EA");
    select(undef, undef, undef, (0.04));
    CUL_HM_FWupdateSpeed($name,100);


ändern in

Code Auswählen Erweitern

sub CUL_HM_FWupdateSteps($){#steps for FW update
  my $mIn = shift;

...

    CUL_HM_SndCmd($hash,"${mNoA}00CB$id${dst}105B11F81547");
#    CUL_HM_SndCmd($hash,"${mNoA}20CB$id${dst}105B11F815470B081A1C191D1BC71C001DB221B623EA");
    select(undef, undef, undef, (0.2)); # longer wait for tsculfw
    CUL_HM_FWupdateSpeed($name,100);


Dann sollte es klappen (wenn dann nicht zufälligerweise kurz zuvor noch Sendebefehle an andere devices in den tsculfw HM-Puffer geschoben wurden und noch abgearbeitet werden).

Außerdem wichtig, es müssen vor einem OTA Updateversuch die verfügbaren credits10ms abgefragt werden. Nur wenn die nahezu auf 1800 "aufgeladen" sind, steht genug Sendezeit für ein OTA Update zur Verfügung.
In 10_CUL_HM wird das derzeit nicht abgefragt, wohl aber von Michaels flash-ota Tool 0.03.

Gruß, Ansgar.

[noansi]

Hallo Testwillige,

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

Im Anhang ist in TSCUL_fwcode_00_08_FHEM_Modules_00_08.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 tsculfw Firmware kann nicht mit FHEM geflashed werden, sondern muss 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.

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
attr SCC_HM868 hmLanQlen 3_normal
attr SCC_HM868 rfmode HomeMatic
attr SCC_HM868 room Receiver
attr SCC_HM868 sendpool CUL_HM868,SCC_WS868
attr SCC_HM868 verbose 1


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
CUL_Util.pm            -> Hilfsfunktionen, um CUL Typen abzufragen, für "Mischbetrieb"
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.


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 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm CUL_Util.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.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.

Code Auswählen Erweitern

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

Der letzte Hinweis zum Problem beim OTA Firmware Update ist damit auch weitgehend entschärft, wie angekündigt.

Das Sendetiming zu devices ist in der Firmware etwas geändert, ich hoffe zum Besseren.

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.08 ab. Eine ältere Version wird also nicht unterstützt, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist.

Gruß, Ansgar.

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

EDIT: update auf 0.08, Firmware Bug bei MsgCnt Reihenfolge behoben, Timing für FUP (OTA-Update) verbessert

[noansi]

Hallo Testwillige,

im letzten Eintrag habe ich ein Update auf Version 0.08 eingepflegt, weil mir ein älterer Bug bezüglich Messagecounter in der Firmware aufgefallen ist. Insbesondere beim OTA-Firmwareupdate bei HM Devices konnte das zu unnötigen Übertragungswiederholungen führen.
Außerdem eine Timinganpassung für das OTA-Update.

Gruß, Ansgar.

[noansi]

Hallo Testwillige,

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

Im Anhang ist in TSCUL_fwcode_00_09_FHEM_Modules_00_09.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 tsculfw Firmware kann für TSCUL_V3 mit FHEM mit dem modifizierten CULflash 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 CULflash verwendet.

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

Code Auswählen Erweitern

CULflash 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
CUL_Util.pm            -> Hilfsfunktionen, um CUL Typen abzufragen, für "Mischbetrieb"
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         -> verlängertes Wiederholtiming als Anpassung für TSCUL/tsculfw. Ich bitte auch um Feedback, wie es mit HMLAN läuft.
98_CULflash.pm         -> Ergänzt um Flash von TSCUL_V3 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 98_CULflash.pm 10_CUL_HM.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm CUL_Util.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.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.

Code Auswählen Erweitern

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

Das Sendetiming zu devices ist in der Firmware etwas geändert, ich hoffe zum Besseren.

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

Gruß, Ansgar.

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

EDIT: auf TSCUL_fwcode_00_09_FHEM_Modules_00_09c.zip aktualisiert. Darin 00_TSCUL.pm und DevIoTS.pm aktualisiert. Besseres Hochlaufverhalten durch ping-verzögerte HM Sendefreigabe.

[noansi]

Hallo Testwillige,

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

Neu ist diesmal ein Throttle Mechanismus für von TSCUL für CUL_HM bei hoher Systemlast und damit einhergehender langer Sendeverzögerung an CUL. Diese lange Sendeverzögerung macht Probleme in der HM Kommunikation, so z.B. beim Systemstart, mit vielen vergeblichen Sendeversuchen, wenn CUL_HM nicht gebremst wird.
In Anlehnung an HMLAN ist das Attribut "respTime" hinzu gekommen. Allerdings ist es die Zeit, die maximal vergehen darf, bis ein "Echo" für ASKSIN Sendenachrichten ankommt, sonst setzt das Throtteling über XmitOpen ein und wird beendet, wenn die Antwortzeit von Test Pings wieder unter die Hälfte von "respTime" gefallen ist. 0,5 Sekunden sind im Code hinterlegt. Weniger als 0,1 Sekunden und mehr als 1 Sekunde macht sicherlich keinen Sinn einzustellen.

Im Anhang ist in TSCUL_fwcode_00_10_FHEM_Modules_00_11.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 tsculfw Firmware kann für TSCUL_V3 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
CUL_Util.pm            -> Hilfsfunktionen, um CUL Typen abzufragen, für "Mischbetrieb"
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         -> verlängertes Wiederholtiming als Anpassung für TSCUL/tsculfw. Ich bitte auch um Feedback, wie es mit HMLAN läuft.
98_TSCULflash.pm         -> Zum Flash von TSCUL_V3 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 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

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.10 ab. Eine ältere Version wird also nicht unterstützt, da sich diesmal auch das Timestamp Protokoll etwas (aber inkompatibel zum vorherigen Stand) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Gruß, Ansgar.

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

EDIT: 10_CUL_HM.pm muss nicht mehr ausgetauscht werden, da Martin meine wesentliche Änderung übernommen hat. Ich lasse es aber noch drin, falls er das nochmal Rückgängig macht, wenn es damit mit anderen HM-IOs zu Problemen kommen sollte.

EDIT: TSCULflash ersetzt CULflash zum Flashen der tsculfw auf USB CULs. CUL_Util.pm ist entfallen, da es nicht seinem eigentlichen Zweck dienen konnte. Module sind nun wieder unabhängig von anderen Modulen von FHEM.

[MadMax-FHEM]

Hallo Ansgar,

du schläfst wohl auch nie

Ich hab zwar schon länger keine Probleme mehr: Danke!!

Aber ich werd bei Gelegenheit mal die neue FW (bauen und) flashen und die neuen Module einspielen.

Leider werde ich wohl keine deiner erwarteten Feedbacks liefern können...
...höchstens, dass es immer noch ohne Probleme läuft...

Gruß, Joachim

[noansi]

Hallo Joachim,

danke für das Feedback, wenn auch zum alten Stand.

Ich hab zwar schon länger keine Probleme mehr

Wenn Du noch auf einem historischen Stand bist, dann kennst Du sie eventuell nur noch nicht.   
Z.B. OTA-Firmware Update von HM Devices klappt vor 0.08 nicht über FHEM.

Gruß, Ansgar.

[MadMax-FHEM]

Hallo Joachim,

danke für das Feedback, wenn auch zum alten Stand.
Wenn Du noch auf einem historischen Stand bist, dann kennst Du sie eventuell nur noch nicht.   
Z.B. OTA-Firmware Update von HM Devices klappt vor 0.08 nicht über FHEM.

Gruß, Ansgar.

Hallo Ansgar,

bitte gerne!

Hmm, das kann sein.
Es ist ja auch immer noch "nur" mein Testsystem

Aber ich kann ja "spasseshalber" mal das mit dem FW-Update probieren (mal sehen, ob ich noch ein HM-Gerät am Testsystem hab was noch ein Update vertragen kann oder wo ich 2 FW-Stände zum hin und her spielen hab)...

Gruß, Joachim

[noansi]

Hallo Joachim,

oder wo ich 2 FW-Stände zum hin und her spielen hab)...

Mußt Du nicht, Du kannst auch den gleichen Stand nochmal Senden. Bei Kommunikationsfehlern meckert FHEM...

Gruß, Ansgar.

[MadMax-FHEM]

Hallo Ansgar,

so endlich! Sorry!!

Hatte viel zu tun und noch so einige andere "Baustellen"

Aber jetzt habe ich die neue FW eingespielt (habe sie mal mit meiner bestehenden board.h selber compiliert, hat ja immer gut funktioniert / evtl. spiele ich die vorcompilierte FW auch mal ein...) und auch die Module kopiert.

FW-Update klappt prima!

Bin nur beim Hin-und-her-einspielen in die "1%-Falle" getappt...

Wenn ich was testen kann oder du irgendwelche Infos brauchst einfach Bescheid sagen...

Ansonsten läuft auch diese Version prima!

EDIT: zu früh gefreut... Nein kein Problem mit der FW etc. aber ich hab "natürlich" TSCUL_fwcode_00_09_FHEM_Modules_00_10 ausprobiert. Du hast aber mittlerweile TSCUL_fwcode_00_10_FHEM_Modules_00_11 hier eingestellt... Da werde ich wohl dann demnächst noch mal dran gehen...

EDIT2: so, doch schon mal compiliert und eingespielt Läuft immer noch prima! Also einen FW-Update habe ich jetzt noch nicht noch mal gemacht Wenn ich was testen kann etc. einfach Bescheid geben...

Gruß, Joachim

[kaihs]

Hallo Ansgar,

ich habe jetzt endlich auch mal deine TSculfw auf dem rpiAddOn-Board zum Einsatz gebracht.
Lässt sich ohne Änderungen compilieren und flashen und funktioniert auch.

Ein Problem gibt es aber noch mit dem TSCUL Modul:

Code Auswählen Erweitern


2017.07.25 20:20:58 1: CUL_0 is VERSION_TS, VTS 0.10 RPIAddOn_CSM
2017.07.25 20:20:59 1: define IR_Dev CUL_IR CUL_0: Wrong IODev specified or IODev doesn't support CUL_IR


Das Board hat auch einen IR-Empfänger und -Sender, unterstützt durch das CUL_IR Modul.
Das original CUL Modul unterstützt das auch, bei deinem ist das wohl nicht (mehr) enthalten.
Kannst du das noch mit geringem Aufwand einbauen?
Wenn nicht, muss ich es mal selbst versuchen.

Unabhängig von deiner Firmware habe ich mit einem meiner Boards noch ein spezielles Problem.
Das sendet nicht mehr, mit der original culfw stürzt es beim Senden einfach ab.
Bei deiner zwar nicht, aber es wird wohl nicht gesendet. Das andere Board empfängt nichts, Aktoren reagieren nicht. Der Empfang funktioniert dagegen problemlos.
Hast du eine Idee woran das liegen könnte oder was man da noch debuggen könnte?

Gruß,

Kai

[noansi]

Hallo Kai,

Das Board hat auch einen IR-Empfänger und -Sender, unterstützt durch das CUL_IR Modul.
Das original CUL Modul unterstützt das auch, bei deinem ist das wohl nicht (mehr) enthalten.
Kannst du das noch mit geringem Aufwand einbauen?

Das Problem liegt Modulseits eher in 10_CUL_IR.pm Zeile 64

Code Auswählen Erweitern

    if((defined($cl) && $cl =~ m/:CUL_IR:/) &&


Mit TSCUL passt der match nur für SlowRF. Homematic ist CUL_IR bei den clients in $clientsHomeMatic (und ggf. $clientsMAX und $clientsWMBus) am Ende ohne abschließenden ':' in TSCUL, was mAn sonst unnötig Rechenzeit kostet.

Du kannst entweder in TSCUL noch einen ':' am Ende ergänzen oder obigen match in CUL_IR vom zweiten : befreien respektive besser auch auf CUL_IR ohne : aber Ende testen lassen.

IR (und rpiAddOn) habe ich aber bisher nicht testen können und von daher kann ich nicht versprechen, dass die Firmware dazu nicht noch Unschärfen enthält.

Hast du eine Idee woran das liegen könnte oder was man da noch debuggen könnte?

Wie Rudi schon im anderen Thread von Dir meinte, kann es an CCA scheitern, wenn das Board zu viel Störsignale/-rauschen empfängt. Meine SCCs und COC nutze ich mit abgesetzter Antenne, um Störungen durch den Pi zu vermeiden. Andere Geräte in der Nähe können auch stören. Und ein Dauerstörsender auf dem Kanal kann auch zu CCA Problen führen (hatte ich mal mit einem S200 Sensor, dessen Batterien zu Ende gingen und der mit aktivem Sender bis zum Batterieende den Kanal belegte).
Was steht denn im log, wenn Du für das board verbose 4 aktivierst und einen Sendeversuch startest? In den Timestamps wird ein CCA Sendefehler gemeldet. Also AFFx4... statt AFFx3... bei "erfolgreichem" Versand.

Natürlich könnte auch der cc1101 gelitten haben, sprich der Sendetreiber defekt sein, das wäre schade.

Gruß, Ansgar.

[kaihs]

Hallo Kai,

Das Problem liegt Modulseits eher in 10_CUL_IR.pm Zeile 64

Code Auswählen Erweitern

    if((defined($cl) && $cl =~ m/:CUL_IR:/) &&


Mit TSCUL passt der match nur für SlowRF. Homematic ist CUL_IR bei den clients in $clientsHomeMatic (und ggf. $clientsMAX und $clientsWMBus) am Ende ohne abschließenden ':' in TSCUL, was mAn sonst unnötig Rechenzeit kostet.

Du kannst entweder in TSCUL noch einen ':' am Ende ergänzen oder obigen match in CUL_IR vom zweiten : befreien respektive besser auch auf CUL_IR ohne : aber Ende testen lassen.

Danke für die Analyse.
Ich habe 10_CUL_IR.pm etwas anders geändert:

Code Auswählen Erweitern


     if (defined($cl)) {
        my @clients = split /:/, $cl;
       
    if(grep(/^CUL_IR$/, @clients) &&
       $defs{$p}{NAME} eq $a[2]) {   
          $hash->{IODev} = $defs{$p};
          last; 
        }
    }

Das ist m. E. noch etwas robuster, so kann CUL_IR an beliebiger Stelle in der Clientliste stehen.
Werde ich mal als Patch mit der Bitte um Übernahme ins passende Forums stellen.

Was steht denn im log, wenn Du für das board verbose 4 aktivierst und einen Sendeversuch startest? In den Timestamps wird ein CCA Sendefehler gemeldet. Also AFFx4... statt AFFx3... bei "erfolgreichem" Versand.

Code Auswählen Erweitern


2017.07.27 19:58:42 4: TSCUL_send:  CUL_0                         As 0C 7C A011 F11034 52B558 0201C8
2017.07.27 19:58:42 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90 rtoms:1761
2017.07.27 19:58:43 1: TSCUL_ParseTsHM: CUL_0 CCA channel busy error to 52B558/az_Rollo:  221509 A F004 07189076 00 0C 7C A011 F11034 52B558 02 _sfail
2017.07.27 19:58:44 4: TSCUL_XmitAwaitTo CUL_0: timeout - 52B558
2017.07.27 19:58:44 1: TSCUL_ParseTsHM: CUL_0 CCA channel busy error to 52B558/az_Rollo:  222745 A F004 07190332 00 0C 7C A011 F11034 52B558 02 _sfail
2017.07.27 19:58:45 1: TSCUL_ParseTsHM: CUL_0 CCA channel busy error to 52B558/az_Rollo:  223981 A F004 07191588 00 0C 7C A011 F11034 52B558 02 _sfail
2017.07.27 19:58:45 1: TSCUL_ParseTsHM: CUL_0 HM repeat failed to 52B558/az_Rollo:  224212 A F009 07192844 00 0C 7C A011 F11034 52B558 02 _sfail


Tatsächlich CCA.
Fragt sich nur warum. Ich werde das Board jetzt mal auf einem anderen Hostrechner testen. Mglw. strahl der BananaPi jetzt mehr Störungen aus.

Vielen Dank nochmal für deine Unterstützung!

[kaihs]

Ich habe die Boards jetzt getauscht.
Auf dem Bananapi läuft das bisher funktionierende Board, auf dem RPi läuft das 'kaputte' auch weiterhin nicht.
Sieht tatsächlich nach einem Hardwaredefekt aus

Allerdings kommen von dem kaputten Board auf dem RPi andere Fehler:

Code Auswählen Erweitern


2017.07.27 20:57:10 4: TSCUL_send:  CUL_rpi                         As 0A F4 8002 F11034 52B558 00
2017.07.27 20:57:10 4: TSCUL_XmitDlyHM:  CUL_rpi  id:52B558 toms:96
2017.07.27 20:57:10 4: TSCUL_Parse: CUL_rpi  058513 A F103 02343000 01 0A F4 8002 F11034 52B558 00 _CCAdly:4 -138
2017.07.27 20:57:12 4: TSCUL_send:  CUL_rpi                         As 10 F4 A001 F11034 52B558 010452B5580103
2017.07.27 20:57:12 4: TSCUL_XmitDlyHM:  CUL_rpi  id:52B558 toms:101 rtoms:1746
2017.07.27 20:57:12 4: TSCUL_Parse: CUL_rpi  061188 A F103 02345700 01 10 F4 A001 F11034 52B558 01 _CCAdly:4 -138
2017.07.27 20:57:13 4: TSCUL_Parse: CUL_rpi  061324 A F101 02345868 00 1A F4 A010 52B558 F11034 0301000000326400FF00FF014454630000 -42
2017.07.27 20:57:13 4: TSCUL_Parse: CUL_rpi  061620 A F101 02346168 00 1A F4 A010 52B558 F11034 0301000000326400FF00FF014454630000 -41.5
2017.07.27 20:57:13 4: TSCUL_Parse: CUL_rpi  062018 A F101 02346572 00 1A F4 A010 52B558 F11034 0301000000326400FF00FF014454630000 -41.5
2017.07.27 20:57:14 4: TSCUL_XmitAwaitTo CUL_rpi: timeout - 52B558
2017.07.27 20:57:14 4: TSCUL_send:  CUL_rpi                         As 0A F4 8002 F11034 52B558 00
2017.07.27 20:57:14 4: TSCUL_XmitDlyHM:  CUL_rpi  id:52B558 toms:96
2017.07.27 20:57:14 4: TSCUL_Parse: CUL_rpi  063137 A F103 02347692 01 0A F4 8002 F11034 52B558 00 _CCAdly:4 -138
2017.07.27 20:57:25 4: TSCUL_Parse: CUL_rpi  073875 A F102 02358612 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.07.27 20:57:47 4: TSCUL_Parse: CUL_rpi  095650 A F102 02380688 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.07.27 20:58:13 4: TSCUL_Parse: CUL_rpi  122099 A F102 02407528 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.07.27 20:58:47 4: TSCUL_Parse: CUL_rpi  155901 A F002 02441832 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138


Das Device CUL_rpi ist per ser2net an FHEM angebunden. Am Schluss geht der State des angesprochnen Homematic Devices dann auf IOErr.
Kannst du mir diese Meldungen noch erläutern?