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

[CHDI]

Hallo Ansgar,

danke für den Tip, das hat mich weiter gebracht. Mit verbose 5 sehe ich bei jedem Schaltvorgang NOCCA.
Und ja, hätte ich jede Seite ordentlich gelesen, dann wäre ich evtl auch selbst auf Seite 46 dieses Threats gelandet - shame on me 
Gleiches Verhalten, auch wenn CCAmode auf 0 ist.
Ich habe am CC1101 433 die mitgelieferte Antenne (Stabantenne ca. 4cm - ich gehe mal davon aus, dass hier nicht Lambda/4 geschweigedenn Lambda/2 vorliegen kann!?) und habe mir mal eine 433 Antenne bestellt. Evtl. hilft das ja auch bei mir. Weiteres hierzu dann am Montag, wenn die Antenne da ist.
Der Workaround mit der a-culfw bleibt als Möglichkeit, aber wenn es mit TSculfw funktionieren müsste dann will ich es nun wissen. Scheint ja irgendwas anderes nicht zu passen.

Bekomme ich irgendwie raus, wieso der CUL davon ausgeht, dass der Funkkanal belegt ist?
- USB Verlänferung habe ich und habe dias Modul ca. 30cm vom RASPI weg.

Wieso interessiert den CUL das mit der a-culfw nicht und er sendet?

Gruß Chris

[noansi]

Hallo Chris,

Gleiches Verhalten, auch wenn CCAmode auf 0 ist.

Weil nach Code die SlowRF CC1101 Register Einstellungen für Intertechno fest mit CCAmode 1 (mit CARRIER_SENSE_REL_THR 14dB, CARRIER_SENSE_ABS_THR MAGN_TARGET 5dB) genutzt werden.
Sollte ich wohl mal ändern.
Das würde bedeuten, dass ständig irgendwas (Störungen) empfangen wird. -> von Störquelle entfernen

Ich habe am CC1101 433 die mitgelieferte Antenne (Stabantenne ca. 4cm - ich gehe mal davon aus, dass hier nicht Lambda/4 geschweigedenn Lambda/2 vorliegen kann!?)

Wenn es nur so ein kurzer Draht ist, dann wohl nicht. Wenn es ein zu einer Spule gewickelter Draht ist, schon.

Gruß, Ansgar.

[CHDI]

Ich habe am CC1101 433 die mitgelieferte Antenne (Stabantenne ca. 4cm - ich gehe mal davon aus, dass hier nicht Lambda/4 geschweigedenn Lambda/2 vorliegen kann!?) und habe mir mal eine 433 Antenne bestellt. Evtl. hilft das ja auch bei mir. Weiteres hierzu dann am Montag, wenn die Antenne da ist.

Die neue Antenne war wohl die Lösung. Bei der a-culfw war das egal, mit der tsculfw nur mit neuer Antenne...

Besten Dank!

Gruß Chris

[noansi]

Hallo Testwillige,

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

Diese Version bietet einige Verbesserungen für SlowRF Empfang und RF-Router. Ein Peakfilter für SlowRF Empfang ist ergänzt und mit "peakfilter" einstellbar.
In dem Zusammenhang ist auch das RF-Router Ping Timing geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw.
Außerdem kann das Senden von RF-Router Daten nach deren Empfang einstellbar verzögert werden (RfRdelay).

CCAMode wirkt nun auch auf IT-Senden und SOMY-Senden, sowie auf das Senden des RF-Router Pings. Mit fRfCCAMode kann auch das CCA Verhalten für RF-Router Senden und FastRF geändert werden.

Das EEPROM Layout ist wegen der neuen Parameter geändert und daher werden nach dem Flashen alle Einstellungen auf default zurück gestellt. Also vor dem Flashen individuelle Einstellungen, z.B. Frequenzoffsets, notieren und nacher neu einstellen.

Auszug aus der Changed:
- IT and SOMYFY use SlowRF EEPROM CCA setting now for sending
- changes in SlowRF reception for reset and sync start. IT V1 reception tested succsessfully.
- SlowRF filter and match adaption
- SlowRF spike filter improved, max. peak lenght settable with Xpxx, xx hex time in 8us units
- IR receive/transmit pause during send of SlowRF changed to not globally switching off all interrupts
- periodic RF-Router ping RSSI display as "Cuxx\r\n" with xx = RSSI Hex
- RF-Router ping timing changed for better distinguish from other protocols
- RF-Router pre silence before send settable with uRxx, xx hex time in 4ms units
- Xrrt commands bits:
   rr:
   report known protocol data                                                      Bit 0
   report repeated data                                                            Bit 1
   report received bits                                                            Bit 2
   report 'r' (rising) or 'f' (falling) edge, '.' (collect) or '?' (sync) timeout  Bit 3
   report edges, bit times and timeouts                                            Bit 4
   report S300 data with valid checksum only                                       Bit 5
   report FHT                                                                      Bit 6
   report 'l' RSSI decimal data continuosly                                        Bit 7
   t:
   report recorded SlowRF timing                                                   Bit 0
- corrections in interrupt flag clearing
- correction in delay function
- fastRF bug corrected, untested
- EEPROM layout changed for the new parameters


TSCUNX kann mit entsprechendem RS485 Modul nun auch DMX.
Auch HM485 ist für TXCUNX angepasst.
In dem Zuge ist auch die DMX Funktionalität bei CUNO2 etwas erweitert.
IR läuft nun auch richtig mit TSCONO2.
Außerdem läuft RF-Router auf der tsculfw, allerdings mit einer Änderung. Das 'U' ist durch '~' ersetzt. 'U' kollidierte mit dem Uniroll Senden.

Kurzer Auszug aus der CHANGED:
- IO optimizations CUNX, especially to/from PIM and Ethernet
- CUNX DHCP non blocking operation
- IO optimizations
- HM485 support for CUNX (like CUNO2) with RS485 PIM.
  HM485 switch off with Hx for CUNX. With CUNX after Hx RS485 PIM again accessible via PIM USB or Ethernet Interface
- CUNX support for DMX and HM485 with RS485 PIM (to be tested), a Dwxxxxyy switches to DMX via CUNX Interface, a Hsxxxxxxxxxxxxxxxxxx switches to HM485 via CUNX Interface
- DMX switch off with Dx. With CUNX after Dx RS485 PIM is again accessible via PIM USB- or Ethernet Interface
  DMX flexible channel usage. Channels are sent out upto the highest channel set (0 sent as default for unset channels). With switching off with Dx the highest channel is reset.
  DMX changed in timing and resting behaviour. Rests on IDLE if less then 24 device, only, to keep 1204µs min. BREAK to BREAK (to be tested)
  DMX Dt command to set/view timing of MarkAfterBreak and BREAK
  DMX less disturbed while sending SlowRF
- W function gives feedback after writing EEPROM
- clock timer unburdened, may impact onewire and fht (to be tested)
- corrections for IRTX
- IR base timings changed to 12500Hz or 20000Hz
- RF-Router working, but 'U' changed to '~' (definable in board.h, but 'U' disables HAS_UNIROLL)

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

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.

Ebenfalls möglich ist das Flashen eines PIGATOR Moduls an einem CUNX

Code Auswählen Erweitern

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_32_FHEM_Modules_00_43_0.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUNX, TSPIGATOR , TSCUL_V3 , TSCUL_V3_RFR, TSCUNO2, TSCOC und TSSCC. (TSCUL_V3_RFR ist ohne HM Unterstützung, also nur SlowRF)

Die tsculfw Firmware kann für TSCUL_V3, TSCUNO2, TSCOC, TSSCC, TSCUNX und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden. Bei CUNO2 und SCC muss die Bootloadertaste gedrückt werden, bis der Flashvorgang anläuft.
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 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 z.B. TSCUL_V3.
Beispiel:

Code Auswählen Erweitern

TSCULflash MeinCulV3Device 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 in der board.h festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Oder für CUNX

Code Auswählen Erweitern

define CUNX_868 TSCUL /dev/CUNX868_0@12000000 0000
oder für PIGATOR an CUNX

Code Auswählen Erweitern

define PIGATOR_433 TSCUL /dev/CUNXPIM_0@38400 0000
die Seriennummer wird aus der Seriennummer des XMEGA Chips des CUNX gebildet. Unter Linux lsusb nutzen!

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:

Code Auswählen Erweitern

define CUL_868 TSCUL /dev/CUL868@38400 1234
bzw.

Code Auswählen Erweitern

define CUL_433 TSCUL /dev/CUL433@38400 0000

Und noch ein Beispiel für eine Definition eines Netzwerk CUNX:

Code Auswählen Erweitern

define CUL_868 TSCUL 192.168.178.111:2323 0000
oder für PIGATOR an CUNX

Code Auswählen Erweitern

define PIGATOR_433 TSCUL 192.168.178.111:2324 0000
beim PIGATOR sollten zuvor mit Anschluss an USB und öffnen der Schnittstelle mit gewünschten Kommunikationsparametern mit ps oder unter TSCUL mit set PIMstoreBaud die seriellen Kommunikationsparameter zum PIGATOR Modul gespeichert werden, falls sie vom default abweichen.

Oder Netzwerk CUNO2:

Code Auswählen Erweitern

define CUNO2_868 TSCUL 192.168.178.110:2323 0000

Die aktuell eingestellte oder per DHCP erhaltene Netzwerkadresse kann mit Lc repektive in TSCUL mit get NetAdresses abgefragt werden. Mit Lp respektive in TSCUL mit get NetPHYlink kann der Linkzustand des Netzwerkanschlusses angezeigt werden.


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_TSCUL_RFR.pm -> der 16_CUL_RFR.pm, aus CUL_RFR devices werden damit TSCUL_RFR devices in der fhem.cfg (händisch anzupassen)
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). Obsolet, da 14_TSCUL_WS.pm nun KS300 unterstützt.
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
ReadingUtil.pm          -> Hilfsroutinen für Readings

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             -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. 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           -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.
Die 3 Dateien entsprechen einem Stand von Mitte 12/2019. Seither gab es viele Änderungen, so dass entweder diese 3 verwendet werden müssen oder die 3 aus aktuellem Update (meinerseits nicht getestet und der EEPROM-Verschleißhinweis unten ist zu beachten).

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.
98_apptm.pm            -> apptime zur zwingenden Nutzung mit 97_timerTS.pm, mit geringerem Speicherverbrauch bei weniger Details

98_autocreate.pm       -> autocreate mit TSCUL Unterstützung

98_Cumulate               -> Kumulieren von Zählwerten, wie Strom, Regenmenge etc.
98_SAverage.pm         -> Mittelwertbildung von z.B. Temperaturen. Stunde, Tag, Monat und Jahr, sowie ein gleitender Mittelwert der letzten Stunde sind damit möglich.


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 97_timerTS.pm 98_TSCULflash.pm 97_timerTS.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.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.32 ab. Eine ältere Version wird also nicht unterstützt!

Frequenzoffset: Für HM ist ein Frequenzoffset von -20.6kHz im EEPROM als default in der tsculfw hinterlegt (das ist ein individuelles Optimum für meinen COC). Dieser Frequenzoffset kann mit set hmFreqOffs umgestellt werden. 0 ist default in der Standard-culfw.
Wenn also keine Antwort von angesprochenen HM devices kommt, dann hmFreqOffs von 0 ausgehend verstellen. CUNX z.B. geht eher in Richtung + mit dem Offset.
Wer das Frequenzspektrum sichtbar machen kann, kann sich die optimale Mitte aller devices ermitteln und mit dem Offset sein CUL dazu passend einstellen.

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

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.
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:

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

[1wire]

Hallo Ansgar,

ich hatte Timing-Probleme mit culfw 1.67. Konnte nie alle CMD abarbeiten und R_tempList_Stare incomplete.
Habe heute per FLIP meine CUL auf tsculfw upgedatet und die entsprechenden Module in FHEM eingespielt.

Sofort wurden alle CMDs abgearbeitet und es funktioniert jetzt mit meinen HM Modulen alles prima.

Dies als kleine Rückmeldung das die V0.32 bei mir funktioniert. und ein Super-Danke an die beteiligten.

Meine Hardware: FHEM auf Win10 in Qnap-Virtualization, 2x CUL (1x Draht, 1x Antenne, 3 Homematic-Heizkörperthermostate V1.3 und V1.4, 3 threeStateSensor)

[Crania]

Kurze Statusmeldung

Auf der Suche nach einer CUNX Firmware bin ich auf diesen Thread gestoßen und habe daraufhin
die tsculfw 0.32 geflashed(TSCUNX.hex) und die zugehörigen Module installiert.
Ein paar HomeMatic Teile angelernt und getestet. Bis jetzt läuft alles super.

Gruß Crania

[riker1]

Hallo,

habe nun auch den tscul angelegt und 2 devices definiert.

Trotzdem habe ich CMD_Pending Probleme.

was mache ich da denn falsch?

Muss ich noch besondere Parameter setzen?


habe alle Fhem module kopiert, und nanoCul geflashed.


list tscul:

Code Auswählen Erweitern


Save config
CUL_HM
Plots
Unsorted
nanocul
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
Internals:
   CMDS       ABCEFGJKMRUVWXYZeilmtux
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:HMS
   DEF        /dev/ttyUSB0@38400 2934
   DeviceName /dev/ttyUSB0@38400
   FD         11
   FHTID      2934
   FUUID      5de94123-f33f-4d6e-52ea-e245585317d4d74e
   NAME       cul_TSCULF_LAPTOP
   NR         73
   PARTIAL   
   RAWMSG     A0F428610610C0B0000000A50B40C0040::-68.5:cul_TSCULF_LAPTOP:
   RSSI       -68.5
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.32 CSM868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes AES ChTblSize:209
   XmitOpen   1
   assignUpdCntI 7
   assignedIDsCnt 2
   cul_TSCULF_LAPTOP_MSGCNT 9
   cul_TSCULF_LAPTOP_TIME 2019-12-05 20:03:50
   initString AP<
X21
Ar
AM5
AH121212
   msgLoadCurrent 70
   owner_CCU  VCCU_LT
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:HMS      ^810e04......a001
   READINGS:
     2019-12-05 19:59:47   Xmit-Events     disconnected:1 init:1 ok:1 non-HM:1
     2019-12-05 19:59:45   cmds             A B C E F G J K M R U V W X Y Z e i l m t u x
     2019-12-05 19:59:47   cond            ok
     2019-12-05 19:59:40   prot_disconnected last
     2019-12-05 19:59:46   prot_init       last
     2019-12-05 19:59:46   prot_non-HM     last
     2019-12-05 19:59:47   prot_ok         last
     2019-12-05 19:42:45   scF             0.999948700920772
     2019-12-05 19:59:46   state           Initialized
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   2
     assIdRep   2
     nRec       0
     recAlive   1
     recd       1
     DEVIO:
       RXfailTO   
     HM:
       ChTblSize  209
       FUP        0
       HMactive   1
       hmCrdts    7
       hmSbusy    0
       ChTbl:
         29553A3F   00
         3567393F   00
       msgCNT:
         0x01       9
         0x02       12
         0x03       25
         0x09       8
       unknwn:
         3567CF:
           lstRecType 10
           nextSend   1575572591.91019
           nxtSndMcnt 63
           tgtDly     88
           lRcTm:
             cul_TSCULF_LAPTOP 209968
             tnms       393336023
         3571F1:
           lstRecType 10
           nextSend   1575572600.56534
           nxtSndMcnt BF
           tgtDly     88
           lRcTm:
             cul_TSCULF_LAPTOP 218624
             tnms       393344671
         610BA6:
           lstRecType 10
           nextSend   1575572589.35021
           nxtSndMcnt 6A
           tgtDly     88
           lRcTm:
             cul_TSCULF_LAPTOP 207408
             tnms       393333454
         610C0B:
           lstRecType 10
           nextSend   1575572630.63298
           nxtSndMcnt 42
           tgtDly     88
           lRcTm:
             cul_TSCULF_LAPTOP 248696
             tnms       393374737
         610CF8:
           lstRecType 10
           nextSend   1575572533.08623
           nxtSndMcnt 9A
           tgtDly     88
           lRcTm:
             cul_TSCULF_LAPTOP 151136
             tnms       393277190
     cnd:
       0          1
       250        1
       253        1
       255        1
     hmLogHist:
        117454 A F701 00207408 00 0F 6A 8610 610BA6 000000 0A4CCD0C0000 -56.5dB
        120023 A F701 00209968 00 0F 63 8610 3567CF 000000 0A5CCC0A0040 -81dB
        121216 A F702 00211172 00 34 AA00112200000098AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        127822 A F702 00217772 00 34 AA00112200000097AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        128671 A F701 00218624 00 0F BF 8610 3571F1 000000 0A98C80B0240 -84.5dB
        140574 A F702 00230520 00 34 AA00112200000096AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        153420 A F702 00243372 00 34 AA00112200000095AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        155192                 As 0F 01 943F 121212 000000 0202257C1112
        155577 A F703 00245168 01 0F 01 943F 121212 000000 0202257C1112 _bst _CCAdly:4
        158737 A F701 00248696 00 0F 42 8610 610C0B 000000 0A50B40C0040 -68.5dB
        167241 A F702 00257200 00 34 AA00112200000094AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        180596 A F702 00270556 00 34 AA00112200000093AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        185652 A F702 00275608 00 01 CC _ping
        188226 A F702 00278180 00 34 AA00112200000092AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
     hmQ:
       000000:
       29553A:
     ids:
       29553A:
         cfg        +29553A,00,00,00
         name       HM_29553A_Switch
       356739:
         cfg        +356739,02,00,00
         name       HM_356739_Kueche
     loadLvl:
       bl         40
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       RQLSt      0
       RQLt       0
       XRpCnt     0
       XRpTm      1575572387.23254
       answerPend 0
       hmLanQlen  1
       apIDs:
         29553A     0
     ref:
       Sdly       4
       TmBmCnt    1
       ioBR       3840
       ioBRMax    3744.89987338411
       ioBRMean   3351.40756691468
       ioBRMeas   3100.35852928057
       ioBRn      92
       ioBRnC     8
       ioBRptm    1575572659.99143
       ioBRs      26811.2605353174
       lHMt       248696
       lSys       393374737
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pngLm      23
       pngMax     15
       pngMaxTot  15
       pngMin     12
       pngRef     15
       pngtm      393135934
       scF        0.999948700920772
       scFN       0
       scHT       9868
       scST       393135949
Attributes:
   comment    set cul_update_hm hmPairSerial OEQ1248979

https://forum.fhem.de/index.php?topic=65222.0


wz rechts set cul_TSCULF_LAPTOP hmPairSerial OEQ1248681
kueche set cul_TSCULF_LAPTOP hmPairSerial LTK0135825
LTK0135825
   hmId       121212
   model      nanoCUL
   rfmode     HomeMatic
   room       nanocul,CUL_HM
   verbose    5




und ein device:

Code Auswählen Erweitern

Internals:
   DEF        356739
   FUUID      5de942be-f33f-4d6e-a4c6-4390b5617083f4d1
   IODev      cul_TSCULF_LAPTOP
   NAME       HM_356739_Kueche
   NOTIFYDEV  global
   NR         74
   NTFY_ORDER 50-HM_356739_Kueche
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 HM_356739_Weather
   channel_02 HM_356739_Climate
   channel_03 HM_356739_WindowRec
   channel_04 HM_356739_Clima_Kueche
   channel_05 HM_356739_ClimaTeam
   channel_06 HM_356739_remote
   protCmdPend 5 CMDs_pending
   protState  CMDs_pending
   READINGS:
     2019-12-05 19:59:47   Activity        unknown
     2019-12-05 18:47:42   D-firmware      1.4
     2019-12-05 18:47:42   D-serialNr      LTK0135825
     2019-12-05 18:47:42   R-pairCentral   set_0x121212
     2019-12-05 20:02:46   state           CMDs_pending
   cmdStack:
     ++A011121212356739860414
     ++A011121212356739860414
     ++803F1212123567390204257C02C1
     ++A01112121235673986041F
     ++A01112121235673986041F
   helper:
     HM_CMDNR   39
     mId        0095
     regLst     ,0
     rxType     140
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +356739,02,00,00
       restoredIO cul_TSCULF_LAPTOP
       rxt        2
       vccu       VCCU_LT
       p:
         356739
         00
         00
         00
       prefIO:
         cul_TSCULF_LAPTOP
     mRssi:
       mNo       
       io:
         cul_TSCULF_LAPTOP:
           100
           100
     prt:
       bErr       0
       sProc      2
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     shRegW:
       07         04
     tmpl:
Attributes:
   IODev      cul_TSCULF_LAPTOP
   IOgrp      VCCU_LT:cul_TSCULF_LAPTOP
   actCycle   000:10
   actStatus  unknown
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.4
   model      HM-CC-RT-DN
   room       CUL_HM
   serialNr   LTK0135825
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit




danke für die Hilfe.

VG T

[OiledAmoeba]

Lass dem CUL ein bisschen Zeit. Das Sendeprotokoll sieht nur recht wenig Sendezeit pro Stunde vor. Pending bedeutet im allgemeinen, dass er entweder wartet, bis sich das Device wieder meldet, damit er sein Kommando als Antwort senden kann, oder dass die Sendezeit knapp ist.
Gerade wenn man bei einer Neueinrichtung viel zu senden hat (oft schickt man ja ein getConfig ab, das frisst unglaublich viel Sendezeit!).
Mit get <iodevice> credit10ms bekommst du heraus, wie voll der Puffer ist.
Im Wiki gibt es dazu einen guten Artikel, wie das mit dem Sendepuffer und der Sendezeit aussieht.
Die meisten Probleme mit Pending lösen sich nach ner Zeit von selbst.
Hellhörig solltest du erst werden, wenn da ein MISSING_ACK auftaucht.

Gesendet von meinem VOG-L29 mit Tapatalk

Edit: mit list <iodevice> bekommst du angezeigt, was da noch auf Übertragung wartet.

[noansi]

Hallo riker1.

zu Deinem device ist das pairing nicht durchgelaufen.

2019-12-05 18:47:42   R-pairCentral   set_0x121212

Einen Empfangs-RSSI kann ich am device nicht sehen. Eventuell hast Du Empfangsprobleme, falls die Lists nicht gerade nach einem Neustart entstanden sind.
Mit set hmFreqOffs kannst Du die Sende-/Empfangsfrequenz des CUL für HM ggf. noch etwas nachtunen (kam hier schon vor, dass nanos zu sehr daneben lagen).
Mit get ccconf kannst Du den aktuell genutzten Frequenzoffset anzeigen.

Gruß, Ansgar.

[riker1]

Hallo riker1.

zu Deinem device ist das pairing nicht durchgelaufen.

Einen Empfangs-RSSI kann ich am device nicht sehen. Eventuell hast Du Empfangsprobleme, falls die Lists nicht gerade nach einem Neustart entstanden sind.
Mit set hmFreqOffs kannst Du die Sende-/Empfangsfrequenz des CUL für HM ggf. noch etwas nachtunen (kam hier schon vor, dass nanos zu sehr daneben lagen).
Mit get ccconf kannst Du den aktuell genutzten Frequenzoffset anzeigen.

Gruß, Ansgar.

Danke Ansgar,

merkwürdig Fehlermeldung beim Anpassen der FreqOffset:

Code Auswählen Erweitern

This command is not valid in the current rfmode

RFMode ist Homematic.

Mache ich was falsch ? Danke thomas

[riker1]

Hallo riker1.

zu Deinem device ist das pairing nicht durchgelaufen.

Einen Empfangs-RSSI kann ich am device nicht sehen. Eventuell hast Du Empfangsprobleme, falls die Lists nicht gerade nach einem Neustart entstanden sind.
Mit set hmFreqOffs kannst Du die Sende-/Empfangsfrequenz des CUL für HM ggf. noch etwas nachtunen (kam hier schon vor, dass nanos zu sehr daneben lagen).
Mit get ccconf kannst Du den aktuell genutzten Frequenzoffset anzeigen.

Gruß, Ansgar.

Hallo,

stimmt, es war auch kein Sende-Icon im Thermostat.

wahrscheinlich waren die credts leer....viel probiert.

Mal ne Frage wegen dem Timing.

Wie lange dauert das senden an ein Thermostat? es dauert schon lange bei mir .
Der HM switch schaltet sofort.


Danke Thomas

[riker1]

Hallo

hätte ne Frage zur Umstellung.

Habe im aktuellem Fhem eine VCCU mit 3 nanoCul normal.

Nun am Testsystem mal eine VCCU mit TSCUL.


In welcher Reihenfolge stelle ich am Besten um?

Muss ja alles devices neu anlernen und die entsprechenden TSCULS erstellen?


Ich dachte.
- anlegen neuer TSCUL
- Anlegen neue VCCU_TS
- Zuordnen TSCUL zu VCCU_TS
- dann alles Geräte neu anlernen
- dann andere CULS umflashen, neu anlegen und zu VCCU_TS zuordnen


Macht das so Sinn?

Danke für die Hilfe


Danke Thomas



PS. ganz vergessen:
Wenn ich die neuen erforderlichen fhem Module einspiele, kann ich dann das alte CUL noch betreiben?
Dies müsste ja die erste Aktion sein, oder?


Gibt es eine Möglichkeit die alten Devices, paired mit den VCCU CUL wieder zu verwenden mit den neu angelernten Devices am TSCUL?  Dort werden dann doch sicher neue Devices erkannt.....

Ist mir irgendwie nicht ganz klar.

Danke

[MadMax-FHEM]

Mal ne Frage wegen dem Timing.

Wie lange dauert das senden an ein Thermostat? es dauert schon lange bei mir .
Der HM switch schaltet sofort.


Danke Thomas

Das Senden selbst dauert gleich lang

Allerdings ist der HM-Switch (vermutlich) am Strom und daher "dauerwach"...
...das HM-Thermostat ist ein Batteriegerät und daher nur "manchmal wach"...

D.h. das Senden wird erst dann ausgeführt, wenn das Gerät mal wieder wach ist (so ca. alle 3min).

Außer du aktivierst "burst", dann reagiert auch der sofort.
Geht aber auf die Batterielebensdauer...

Beim Übertragen von nicht nur "Schaltkommandos" sondern z.B. Temp-Profilen (oder Registern etc.) können auch schon mal mehrere 3min-Zyklen nötig sein...

EDIT: daher heißt es oft (und mache ich auch so) ab und an mal das "Knöpfchen drücken", dadurch wird er aufgeweckt und man muss beim Übertragen von mehreren Daten (Temp-Profil oder beim Anlernen: Register etc.) nicht so lange warten...

Gruß, Joachim

[riker1]

Danke Joachim,
werde ich dann mal beobachten
vg Thomas

[noansi]

Hallo Thomas,

This command is not valid in the current rfmode

set hmFreqOffs
und nicht set FreqOffs

hätte ne Frage zur Umstellung.

Was willst Du denn umstellen? Willst Du alle Geräte am Testsystem anlernen? Oder willst Du Dein Hauptsystem umstellen?


Wenn Du Dein Hauptsystem umstellen möchtest, dann hast Du es prinzipiell mit der schon bestehenden VCCU einfach, da nur die IOs, sprich CULs umgestellt werden müssen.
Backup vom Hauptsystem erstellen.
Die CULs alle auf tsculfw flashen und am Hauptsystem anschließen, wie gehabt.
Die FHEM Dateien austauschen.
In der fhem.cfg alle CUL Definitionen in TSCUL Definitionen umändern (CUL Device Namen beibehalten!). Wichtig, die TSCULs müssen alle vor der VCCU definiert sein.
FHEM mit der geänderten Konfiguration neu starten.
Es muss nicht neu angelernt werden, da die HM-Devices bereits angemeldet sein sollten (sofern das natürlich mal in der Vergangenheit erfolgreich erfolgt ist).

Gruß, Ansgar.