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

[pte]

Noch ein paar Antworten zu Deinen Fragen:
über den Hardwaretaster ist es mir nicht gelungen, dies zu provozieren. Ist aber unsichher, da auch über Funk durchaus mehrere (20-30) Befehle fehlerfrei hintereinander ausgeführt werden.

Firmewarestand ist 2.5.

Ich bin mir inzwischen relativ sicher, dass es stets nach dem Schalten während der ACK Phase zum Absturz kommt. Ich hatte dann heute früh noch beobachtet, dass nach einem Funkbefehl die Dose schaltete ohne Rückmeldung an FHEM, dann die LED 3x gelb blinkte und danach FHEM die Quittung bekam. Darauffolgende Befehle wurden wieder normal ausgeführt und quittiert.

Ein paar Doppelzuweisung "assignIDs" habe ich gefunden (betreffen aber nicht die Dose). Wie krieg ich die wieder weg? Sollten die nach einem Neustart mit Deiner aktuellen Version verschwinden?

Bezüglich Deiner Aussage, dass immer nur über ein IO kommuniziert wird habe ich in Erinnerung im Log schon betreffend einer Kommunikation mehrere beteiligte IO's gesehen zu haben. Das können aber auch nur Empfangsnachrichten gewesen sein. Die leiten doch wohl alle IO's an FHEM weiter und erst dort werden die Duplikate gefiltert, richtig?

Ich werde das noch mal genauer prüfen und Dir dann mal einen Logmitschnitt schicken.

Hab erst mal einen angenehmen Tag.

[noansi]

Hallo pte,

dann die LED 3x gelb blinkte

Leider kann ich nicht sagen, was das Gerät damit sagen will?

Wie sieht der RSSI aus?

Mit TSCUL auf verbose 4 könntest Du aber Schaltvortgänge inklusive Timing Information schön mit loggen.

Sollten die nach einem Neustart mit Deiner aktuellen Version verschwinden?

Ja, wenn ich alles richtig gemacht habe. 
Allerdings kann ich das nur von 10_TSCUL.pm in Verbindung mit der modifzierten 10_CUL_HM.pm behaupten.
Bitte TSCUL Firmware und Module auf aktuellen Stand, siehe oben, bringen.

Die im CUL EEPROM gespeicherten Zuweisungen lassen sich grundsätzlich auch einzeln oder komplett löschen. Aber damit wäre die Änderung FHEM nocht nicht bekannt gegeben. Und wenn es bisher schon dazu gekommen ist, wird es mit dem alten Stand wohl auch wieder passieren können.

Das können aber auch nur Empfangsnachrichten gewesen sein.

Das sehr wahrscheinlich, da alle IOs im Empfangsbreich die Nachricht auch empfangen.
Du mußt bei der Interpretation schon darauf achten, ob es Sendenachrichten von IOs sind, die doppelt kommen.
Außerdem empfangen die IOs ja auch die Sendenachrichten der anderen IOs, sofern im Empfangsbereich. Da kann man sich auch schon mal vergucken.

Wenn Du Doppelzuweisungen bei IOs hast, dann würden auch alle diese IOs versuchen ihre automatische Antwort los zu werden.

Die leiten doch wohl alle IO's an FHEM weiter und erst dort werden die Duplikate gefiltert, richtig?

So ist es.
Und sollte es mal nicht so sein, ist es zumindest in 10_CUL_HM.pm so gedacht. 

Gruß, Ansgar.

[pte]

RSSI liegen bei -72, ich würde sagen grün/gelber Bereich
hatte heute Testschleife (1min an, 1min aus) laufen ohne Last (also ohne Pumpe). Lief 3h ohne Probleme.
Dann mit Pumpe -> keine 5 min.

Du hattest wohl den Finger drauf bezüglich Spannungsspitzen durch induktive Last.

Test läuft jetzt mit einem zusätzlichen Motorschutzkondensator in der Leitung zwischen Dose und Pumpe.

Werde berichten.

Firmeware und Module update ich dann nach dem Test.

[noansi]

Hallo pte,

Du hattest wohl den Finger drauf bezüglich Spannungsspitzen durch induktive Last.

Noch ergänzend zur Vermutung, hier https://homematic-forum.de/forum/viewtopic.php?f=19&t=29975&start=10 sind die Datenblätter zu HM-ES-PMSw1-Pl-DN-R1 und HM-ES-PMSw1-Pl im Vergleich zu sehen.

Beim HM-ES-PMSw1-Pl-DN-R1 ist ohmsche Last als Lastart angegeben.

Beim HM-ES-PMSw1-Pl gibt es keine Angabe dazu.

Gruß, Ansgar.

[pte]

Mit dem Datenblatt hast Du natürlich recht. Ich habe da bisher eher die Probleme Abbrand durch Funkenerosion (induktive Last) bzw. Verkleben durch Einschaltstrom (kapazitive Last wie LED Lampen). Das die Dinger auf EMV so empfindlich reagieren hätte ich nicht vermutet. Die Pumpe hat ja auch ca. 10Watt (ich weiß, auf die Höhe der Spannungsspitzen hat das nur bedingt Einfluss, wohl aber auf deren Energiegehalt).
Da ist das Design der Dose in dieser Hinsicht wohl doch etwas schwach.

Der Kondensator scheint übrigens zu wirken.


Gesendet von iPhone mit Tapatalk

[noansi]

Hallo Testwillige,

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

Diese Version verbessert das K Kommando und macht es nutzbarer.

Außerdem Verbesserungen bei der HM-Devicezuordnung mit mehreren HM IOs, insbesondere nach einem Neustart von FHEM.

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

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 6 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 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_21_FHEM_Modules_00_33.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC, TSCUNO2 und TSSCC.

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
97_timerTS.pm        -> Austausch Timerroutinen (inkompatibel zu 30_MilightBridge.pm vgl. https://forum.fhem.de/index.php/topic,81365.msg734828.html#msg734828). Wenn es nicht genutzt werden soll, dann löschen oder umbennen.

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!!!
HMConfig.pm             -> Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware
98_apptime.pm          -> apptime zur Nutzung mit 97_timerTS.pm

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.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

Code Auswählen Erweitern


define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:

Code Auswählen Erweitern


define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}


Gruß, Ansgar.

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

EDIT: aktualisiert auf TSCUL_fwcode_00_21_FHEM_Modules_00_27, Martins letzte Änderungen eingepflegt daher ist auch 98_HMtemplate.pm in Martins aktueller Version dabei, da erforderlich. Modifiziertes apptime vgl. https://forum.fhem.de/index.php/topic,81365.msg734513.html#msg734513, um auch Timeraufrufe mit Code Referenz sinnvoll anzuzeigen und geänderte Timerwarteschlangenabarbeitung zu berücksichigen.

EDIT2: aktualisiert auf TSCUL_fwcode_00_21_FHEM_Modules_00_28, in 10_CUL_HM.pm das attribut "rssiSwichHyst" in "rssiSwitchHyst" korrigiert. Außerdem hat mich AssignIO in den jeweiligen Modulen mit Verzögerungen gestört.

EDIT3: aktualisiert auf TSCUL_fwcode_00_21_FHEM_Modules_00_29, kleinere Modul Korrekturen und 10_CUL_HM.pm entspr. Martins Änderung aktualisiert.

EDIT4: aktualisiert auf TSCUL_fwcode_00_21_FHEM_Modules_00_30, kleinere Modul Korrekturen, Verbesserungen und 10_CUL_HM.pm entspr. Martins Änderung aktualisiert. Bitte Martins aktuelles 98_HMtemplate.pm nutzen!

EDIT5: aktualisiert auf TSCUL_fwcode_00_21_FHEM_Modules_00_31, kleinere Modul Korrekturen, Bug in DevIoTS.pm behoben, 10_CUL_HM.pm entspr. Martins Änderung aktualisiert. Bitte Martins aktuelles 98_HMtemplate.pm nutzen!

EDIT6: aktualisiert auf TSCUL_fwcode_00_21_FHEM_Modules_00_32, 10_CUL_HM.pm entspr. Martins Änderung aktualisiert. Bitte Martins aktuelles 98_HMtemplate.pm nutzen! In TSCUL erfolgt message Dispatch nun in einem Timer.

EDIT7: aktualisiert auf TSCUL_fwcode_00_21_FHEM_Modules_00_33, 10_CUL_HM.pm entspr. Martins Änderung aktualisiert. Bitte Martins aktuelles 98_HMtemplate.pm nutzen! 97_timerTS.pm ergänzt.

[Bastel-Frank]

Hallo Ansgar,

wieder mal ein fettes Danke von mir für deine unermüdliche und super Arbeit 

Viele Grüße
Frank

[klausw]

Version 0.21 funktioniert seit gestern Abend stabil bei mir.
Ebenso wie TSCULflash mit dem nanocul
Daumen hoch 

[noansi]

Hallo Testwillige,

ich habe hier https://forum.fhem.de/index.php/topic,24436.msg732585.html#msg732585 nochmal eine Aktualisierung der Module angehangen. Bitte diesen letzten Stand nutzen.

@Klaus und @Frank: Danke für die positive Rückmeldung.
Normalerweise kann ich nur annehmen, dass keine Probleme auftreten , bis ich selbst mal drüber stolpere. 

Gruß, Ansgar.

[Bastel-Frank]

Ich habe die neuen Versionen noch nicht in Produktion. Daher kann ich auch kein Feedback geben. Da ich mir keine Ausfälle leisten kann und inzwischen 5 CULs im Einsatz habe, ist der Aufwand für ein Update und ein evtl. zurückgehen auf eine vorherige Version leider ziemlich aufwendig. Ich warte daher immer erst etwas ab 

[noansi]

Hallo Frank,

Ich habe die neuen Versionen noch nicht in Produktion.

Bei welchem Stand bist Du denn jetzt?

Da ich mir keine Ausfälle leisten kann und inzwischen 5 CULs im Einsatz habe

Redundanzfunktionen können nie schaden.
Gerade dann wäre es interessant, ob die MultiIO Zuordnung stets sauber funktioniert. Genau genommen hat Deine Problematik meine Neugier geweckt, mich dem anzunehmen.
Ich teste selber mit maximal 2 CULs, es läuft bei mir aber prima mit einem.

Gruß, Ansgar.

[Bastel-Frank]

Ich hatte bis vor kurzem zu 0.10 im Einsatz, jetzt ist es die 0.15. Beide Versionen laufen TipTop in meiner Umgebung.

Zwischen den Feiertagen werde ich deine 0.21 testen.

[noansi]

Hallo Frank,

Zwischen den Feiertagen werde ich deine 0.21 testen.

Dann beherzige dabei bitte auch die Hinweise zur IO Zuordnung der HM devices Stichwort "VorzugsIOs" und Haltbarkeit EEPROM.

Gruß, Ansgar.

[Bastel-Frank]

Hallo Frank,
Dann beherzige dabei bitte auch die Hinweise zur IO Zuordnung der HM devices Stichwort "VorzugsIOs" und Haltbarkeit EEPROM.
Gruß, Ansgar.

Ja, ich das werde ich machen  . Vielen Dank nochmal für deinen Hinweis.

[noansi]

Halllo Testwillige,

ich habe hier https://forum.fhem.de/index.php/topic,24436.msg732585.html#msg732585 nochmal die Module nach neuesten Erkenntnissen auf TSCUL_fwcode_00_21_FHEM_Modules_00_28.zip aktualisiert.

Gruß, Ansgar.