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

Begonnen von noansi, 09 Juni 2014, 19:16:01

Vorheriges Thema - Nächstes Thema

Jasimo

Hallo,

hatte gerade die folgende Meldung im Log:
2018.07.23 14:44:52 2: TSCUL_ReceiveDelayed: CUL1  C 00=07 01=2E 02=01 03=42 04=E9 05=CA 06=31 07=0C 08=45 09=00 0A=00 0B=06 0C=F3 0D=21 0E=65 0F=6A 10=C8 11=93 12=03 13=22 14=F8 15=34 16=07 17=3C 18=18 19=16 1A=6C 1B=43 1C=67 1D=91 1E=87 1F=6B 20=F8 21=56 22=10 23=AC 24=2B 25=17 26=11 27=41 28=00 29=59 2A=7F 2B=3E 2C=81 2D=35 2E=0B 2F=00 30=00 31=14 32=F2 33=1A 34=C4 35=0D 36=00 37=00 38=2B 39=CC 3A=00 3B=41 3C=00 3D=00
2018.07.23 14:53:48 3: CUL_HM set TE_Licht on
2018.07.23 14:53:49 3: TSCUL_ParseTsHM: CUL1 HM CCA channel busy error to 5F6A36/TE_Licht:  260854 A F004 06277748 00 0E 22 A011 471147 5F6A36 0201C80000 _sfail
2018.07.23 14:53:58 3: CUL_HM set TE_Licht off

Nutze die tsculfw 0.26, hat da jemand eine Idee.
Gruß
Jan

davedeluxe

Hallo Zusammen,
da ich grade auf ne Intel NUC mit Proxmox und darauf FHEM in einem LXC - Container umgestellt habe, habe ich aktuell ein paar Probleme da ich meinen nanoCUL nicht zum Container durchschleifen kann.
Nun zur Frage, gibt es eine Möglichkeit diese Firmware auf einem WLAN- oder LAN-fähigen Gerät laufen zu lassen anstatt auf einem Arduino Nano?
Alternativ dachte ich an den originalen HM LAN-Adapter aber den gibt es leider nicht mehr.

Grüße Dave

noansi

Hallo Jan,

um 14:44:52 war wohl wenig los mit Empfang und daher wurden mal die Transceiver Register ausgelesen.

Um 14:53:49 war wohl auf 868MHz bereits ein anderes Gerät sendend bzw. der Kanal belegt und dann sendet die Firmware nicht. Kann passieren.
Wenn es mal zum Dauerzustand wird, dann hilft nur den Störer ausfindig zu machen, siehe auch dieser Thread: https://forum.fhem.de/index.php/topic,89162.0.html

Gruß, Ansgar.

noansi

Hallo Dave,

auf einem CUNO2 würde sie laufen.
Auf CUNO oder CUN vermutlich auch, aber ich habe es mit denen mangels Hardware nie testen können.
Die drei gibt es nur nicht mehr neu bei Busware.

Auf einem CC1101 868MHz PIGATOR Modul z.B. an einem CUNX würde sie laufen, jedoch nicht auf CUNX selbst.

Gruß, Ansgar.

davedeluxe

Hi Ansgar,
danke für die Antwort, das klingt doch vielversprechend.

Ich habe mir das ganze mal angesehen, meinst du es läuft auch auf einem Network PIM Connector mit:
Pigator Modul: CC1101 868MHz RP-SMA-Anschluss ?
Oder sogar dem Busser? mit dem o.g. Pigator Modul ?


Ansonsten wäre das der von dir beschriebene CUNX? :
http://shop.busware.de/product_info.php/products_id/47
Brauch ich da noch etwas oder ist das alles an HArdware?

Grüße Dave

Horti

Hi,

bevor Du Geld und Zeit investierst, um die TSCUL-Firmware übers Netz laufen zu lassen, wäre nicht ein MOD-RPI-PCB über LAN/WLAN nicht eine Alternative?

Entweder fertig gelötet hier im Forum (suche nach WLAN der LAN Homematic Gateway) oder ansonsten aber relativ einfach selber zusammenzustricken. Kostet natürlich auch Zeit und Geld, aber deutlich weniger und hat sich schon bei vielen bewährt ;)


noansi

Hallo Dave,

ZitatIch habe mir das ganze mal angesehen, meinst du es läuft auch auf einem Network PIM Connector mit:
Pigator Modul: CC1101 868MHz RP-SMA-Anschluss ?
Oder sogar dem Busser? mit dem o.g. Pigator Modul ?

Also auf dem von Dir richtig gewählten Pigator Modul läuft die tscul Firmware.
Ich habe ein 433MHz Modul damit geflashed und die Firmware läuft darauf stabil. Auf dem 868MHz Modul wird sie auch stabil laufen.

Die CUNX Firmware von Busware hat noch Schwächen. Insbesondere klappt DHCP nicht richtig und man muss die Netzwerkadresse/Netzmaske etc. händisch eintragen. Dazu gibt es einen Thread.

Das Pigatormodul zu flashen war in sofern problematisch, dass der vorinstallierte Bootloader auf dem Mpdul nicht wollte und ich erst mal den auf Stand bringen musste, was einen entsprechenden Programmer nötig machte.

Zum Network PIM Connector habe ich keine Erfahrungen. Ebenso nicht zum Busser.

Zum MOD-RPI-PCB über LAN/WLAN habe ich ebenfalls keine persönlichen Erfahrungswerte.

Gruß, Ansgar.

davedeluxe

Ich denke ich werde es mal mit dem HM-MOD-RPI-PCB und nem USR-TCP232-T2 probieren,
Das ist günstig und schnell zusammengebastelt so wie es aussieht...

Danke für eure Hilfe, dann kann mein Intel NUC/Proxmox-Vorhaben jetzt weiter gehen :)

Grüße Dave

Bastel-Frank

Hallo Ansgar,

ich bin heute von der Version 21 auf die 26 gegangen. Bis auf ein Device läuft alles unauffällig.

Beim Device "HM-RC-Dis-H-x-EU" (Fernbedienung mit Display) bleiben nun CMDs hängen und werden auch nach mehrfachen Versuchen nicht übertragen. Ein Resetten auf die Werkseinstellungen hat dazu geführt, dass das Pairing nicht mehr vollständig durchgeführt wird. Dies bedeutet wohl, dass es mit diesem Device ein Timing-Problem gibt.

Ich bin versuchsweise auf die Version 25 und 21 zurückgegangen. Dies hat leider keine Besserung gebracht. Bei früheren Versionen habe ich dieses Problem nicht gehabt.

Hast Du eine Idee?

PS: Ich habe insgesamt 4 CUL's und einen NanoCUL im Einsatz, welche mit ser2net angebunden sind

Viele Grüße
Frank

Bastel-Frank

PS:

Ich habe nun festgestellt, dass es die o.g. Probleme gibt, wenn ich mich näher als 5m zu meinen "Haupt-CUL" (CUL mit langer Antenne) aufhalte. Entferne ich mich weiter, dann werden die CMDs ausgetauscht und die Fernbedienung wird konfiguriert und funktioniert anschließend.

Gibt es hierzu eine Erklärung?

Viele Grüße
Frank

RaspiLED

Ja steht auch im Wiki Stichwort Übersprechen.
Ich höre meine Tochter auch nicht, wenn Sie in mein Ohr brüllt und mein Gehirn sagt nur Aua und nicht ACK ;-)

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

noansi

Hallo Frank,

es dürfte vermutlich eher was mit der Multi-IO Umgebung zu tun haben, wenn < als 5m nicht < als 1m bedeutet.

Ohne Log mit verbose 4 für alle CULs läßt sich dazu gar nichts sagen.

Wenn die IO-Device Zuordnung beim Anlernen wechselt, weil ein schlechter empfangender CUL zuerst empfängt, könnte das zu Problemen führen.

Außerdem natürlich Firmware aller CULs und Module auf den gleichen Stand nach jeweilgem ZIP-File bringen. Mischen bringt in der Regel nichts sinnvolles.

Gruß, Ansgar.

Bastel-Frank

Hallo Ansgar,

ich halte alle CULs auf dem gleichen Versionsstand. Ich könne die anderen CULs mal fürs anlernen mit Dummy=1 stilllegen und mit verbose 4 mitschneiden. Würde das für die Analyse helfen?

Viele Grüße
Frank

noansi

Hallo Frank,

ZitatIch könne die anderen CULs mal fürs anlernen mit Dummy=1 stilllegen und mit verbose 4 mitschneiden. Würde das für die Analyse helfen?
Nur, wenn Du vermutest, dass der eine CUL "kaputt" ist.
Außerdem müsstest Du die anderen CULs dabei auch ausschalten, da Du nicht weisst, welcher CUL die Fernbedienung noch als sein device"kennt" und damit mit automatischen Acks dazwischen funken würde. Nur dummy=1 löscht nicht die Zuordnungstabelle in den CULs und schaltet die CULs auch nicht in SlowRF. Nur dummy=1 würde mehr Probleme schaffen.

Log mit verbose 4 für alle CULs.

Gruß, Ansgar.

noansi

#734
Hallo Testwillige,

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

Diese Version enthält Korrekturen für HM und Ergänzungen für SlowRf. Außerdem wird das Attribut "dummy" nun sinnvoll unterstützt.

Für CUL-IOs mit großem SRAM Speicher (SCC,COC,CUNO2,PIGATOR,...) ist die HM-Device Tabelle vom EEPROM ins SRAM verlagert und somit der EEPROM Verschleiss bei HM für diese entfallen. In dieser Version ist de SRAM Tabelle vergrößert (je nach verfügbarem SRAM).

Kurzer Auszug für SlowRf Änderungen aus der Readme:
- SlowRF Send Frequeny to set with Xs
- Xs delivers SlowRF Send Frequeny Offset and Send Frequeny (answer Xf:ooffffff)
- Xo added to set SlowRF (default is the offset for reception)
- if delivers Send Frequeny Offset and Send Frequeny (answer if:ooffffff)
- io added to set InterTechno Send Frequeny Offset (default is 0)
- it removed, ic remains to set it_interval
- isr just sets InterTechno Repetition-count but does no more respond with ir:
- ir and ix removed
- Yx removed

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 Flashen auch von NanoCULs und MiniCULs ergänzt. 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.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

Ebenfalls möglich ist das Flashen eines PIGATOR Moduls an einem CUNX
TSCULflash <pigatordevicename>|<cunxdevicename> TSPIGATOR

AESCommReq wird unterstützt. 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 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_29_FHEM_Modules_00_40_1.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC 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 (generell 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:
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:
#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
define CUL_868 TSCUL /dev/CUL868_0@12000000 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware in der board.h 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.

Bei nicht nativen USB CULs wie z.B. nanoCUL, miniCUL oder CUNO2, beträgt die Baudrate 38400, dementsprechend muss die Definition beispielsweise so aussehen:
define CUL_868 TSCUL /dev/CUL868@38400 1234
bzw.
define CUL_433 TSCUL /dev/CUL433@38400 0000

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.

10_IT.pm                   -> vermeidet unnötiges busy waiting beim Senden. Wird ohne Schutz von FHEM update überschrieben

Außerdem:

98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert.
HMConfig.pm             -> optional, 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_HMinfo.pm           -> optional, Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.

10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

97_timerTS.pm           -> optional, Austausch-Timerroutinen. Wenn es nicht genutzt werden soll, dann löschen oder umbennen.
98_apptime.pm          -> apptime zur zwingenden 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:
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 97_timerTS.pm 98_TSCULflash.pm 97_timerTS.pm 98_apptime.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm

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

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

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). 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
attr HMdeviceName IOgrp VCCU
setzen, sondern
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.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.

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

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:

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.msg773255.html#msg773255

EDIT: Firmware .hex Dateien in zip aktualisiert
EDIT2: 00_TSCUL.pm angepasst um CC0 = xx / xxx Meldungen im SlowRf Betrieb zu filtern.