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

[noansi]

Hallo Frank,

Ob es am Ende wirklich daran gelegen hat, muss die Zukunft zeigt.

Vom Code her kann ich es derzeit nicht nachvollziehen.

Dort war als fhtid (=Hauscode, aber eigentlich ist dies die HmId)

Das ist so nicht richtig.

In Single-CUL HM Konfiguration ist es ein historisch implementiertes Feature, dass "F1<housecode>" als hmId genutzt wird, sofern das Atribut hmId nicht gesetzt wird. Vermutlich um die Konfigurationsstartschwierigkeiten für Neuuser zu verringern.

In Multi-CUL VCCU HM Konfiguration geht das nicht, weil der housecode bei FHT in den ersten beiden Ziffern einzigartig für alle CULs sein muss und sich dann bei der CUL Definition entsprechende Fehlermeldungen und Probleme zeigen.
Da FHT zusammen mit  HM gar keinen Sinn macht, macht auch nur 0000 (schaltet FHT ab) wirklich Sinn für die FHTID (=housecode) bei den CULs.

Allerdings überschreibt die VCCU die hmId, die sich aus dem "default" aus "F1<housecode>" ergeben würde, durch setzen des Attributs hmId bei ihren IOs. Von daher sollte es eigentlich auch mit unterschiedlich gesetzten FHTIDs bei den CULs funktionieren.

Die VCCU Definition gehört hinter die CUL Definitionen in der config. Das könnte eventuell noch schief laufen.

Gruß, Ansgar.

[Bastel-Frank]

Die VCCU Definition gehört hinter die CUL Definitionen in der config. Das könnte eventuell noch schief laufen.

Das wäre ein Ansatz, da ich historisch zunächst einen stationären CUL angelegt habe, anschließend zur vccu gewechselt bin und jetzt nach und nach zusätzliche CULs hinzufüge.

[MarkusWEN]

Irgendwie bin ich gerade blind - wo kann ich bitte die tsculfw herunterladen?

[noansi]

Hallo Markus,

im ersten Beitrag dieses Threads ist der link zum passenden Beitrag zu finden.

Gruß, Ansgar.

[MarkusWEN]

Vielen Dank. Hatte den Link zur Datei nicht gesehen

[noansi]

Hallo Testwillige,

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

Diese Version bietet einige Verbesserungen insbesondere für CUNX und CUNO2.

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

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

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 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 repektive 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.31 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!

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

[killah78]

Hallo noansi,
habe von 0.30 auf 0.31 upgedated, da ich einen Absturz (fhem hat sich beendet) durch timerTS bekam, wenn ich ein MQTT2 Device anlegen wollte.
Hatte als letzte Meldung immer:

Code Auswählen Erweitern


Can't use an undefined value as a subroutine reference at ./FHEM/97_timerTS.pm line 75.


Mit der neuen 0.31 tritt dieser Fehler nicht mehr auf.
Danke für das Update.
Gruss
killah78

[ph573]

Mich hat das Problem hierher geführt, dass mehrere HM-Aktoren zu "MISSING ACK" in FHEM führen. An ein funktechnisches Übertragungsproblem will ich nicht so recht glauben, da 30 cm weiter sich funktionierende Aktoren befinden. Also warum nicht diese Firmware an meinem CUNX austesten - gleich vorweg jetzt lässt sich kein Aktor mehr ansprechen, jedes Kommando an jeden Aktor wird mit

Code Auswählen Erweitern


TSCUL_ParseTsHM: RFCUNX1 HM repeat failed to 698A2E/OG_WOH_Deckenspot:  245604 A F209 04807992 00 0B 93 A001 FA2CE4 698A2E 030E _sfail _noAnsw


quittiert.

Die Schritte im Einzelnen:

a) CUNX erfolgreich mit V0.31 geflasht

Code Auswählen Erweitern


Internals:
   CMDS       ABCDEFGHJKLMNRTUVWXYZefilmpqtux
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:HMS
   DEF        192.168.200.134:2323 0000
   DeviceName 192.168.200.134:2323
   FD         13
   FHTID      0000
   FUUID      5d45904c-f33f-5e09-74b0-e2c0d518e43c5c23
   NAME       RFCUNX1
   NR         44
   PARTIAL   
   RAWMSG     A0FCBA410698A2EFA2CE4060300003F00::-59.5:RFCUNX1:
   RFCUNX1_MSGCNT 4
   RFCUNX1_TIME 2019-08-04 08:29:18
   RSSI       -59.5
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.31 CUL868
   VERSION_HW CUNX_V1.0
   VERSION_TS yes AES ChTblSize:384
   XmitOpen   1
   assignUpdCntI 30
   assignedIDsCnt 15
   initString AP<
X21
Ar
AM5
AHFA2CE4
   msgLoadCurrent 10
   owner_CCU  RFVHM
   Helper:
     DBLOG:
       Xmit-Events:
         logdb:
           TIME       1564898206.75477
           VALUE      init:1 disconnected:1 non-HM:1 ok:1
       cond:
         logdb:
           TIME       1564898206.75477
           VALUE      ok
       prot_ok:
         logdb:
           TIME       1564898206.75477
           VALUE      last
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:HMS      ^810e04......a001
   READINGS:
     2019-08-04 07:56:46   Xmit-Events     init:1 disconnected:1 non-HM:1 ok:1
     2019-08-04 07:56:10   cmds             A B C D E F G H J K L M N R T U V W X Y Z e f i l m p q t u x
     2019-08-04 07:56:46   cond            ok
     2019-08-04 07:56:10   prot_disconnected last
     2019-08-04 07:56:12   prot_init       last
     2019-08-04 07:56:11   prot_non-HM     last
     2019-08-04 07:56:46   prot_ok         last
     2019-08-04 08:14:26   scF             1.0083672737872
     2019-08-04 07:56:12   state           Initialized
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   15
     assIdRep   15
     nRec       0
     recAlive   1
     recd       1
     DEVIO:
       RXfailTO   
     HM:
       ChTblRAM   1
       ChTblSize  384
       FUP        0
       HMactive   1
       hmCrdts    1
       hmSbusy    0
       ChTbl:
         698A2E3F   01
         698B423F   01
         698B5E3F   01
         698C0F3F   01
         698C3A3F   01
         698C523F   01
         698CCD3F   01
         698CFA3F   01
         698D223F   01
         698D6E3F   01
         6B7AB33F   01
         6B7AB43F   01
         6B7AC23F   01
         6B7AC43F   01
         6B7AC93F   01
       msgCNT:
         0x01       4
         0x02       175
         0x03       343
         0x09       109
       unknwn:
     cnd:
       0          1
       250        1
       253        1
       255        1
     hmLogHist:
        110172 A F203 02328760 01 0B 28 A001 FA2CE4 698D22 010E _CCAdly:4
        110322 A F209 02329024 00 0B 28 A001 FA2CE4 698D22 010E _sfail _noAnsw
        110357 A F203 02329032 01 0B A3 A001 FA2CE4 6B7AC2 010E _CCAdly:4
        110627 A F203 02329300 01 0B A3 A001 FA2CE4 6B7AC2 010E _CCAdly:4
        110897 A F203 02329568 01 0B A3 A001 FA2CE4 6B7AC2 010E _CCAdly:4
        111136 A F209 02329832 00 0B A3 A001 FA2CE4 6B7AC2 010E _sfail _noAnsw
        114012                 As 0B 28 A001 FA2CE4 698D22 010E
        114048 A F203 02332692 02 0B 28 A001 FA2CE4 698D22 010E _CCAdly:8
        114341 A F203 02332984 06 0B 28 A001 FA2CE4 698D22 010E _CCAdly:24
        114614 A F203 02333256 01 0B 28 A001 FA2CE4 698D22 010E _CCAdly:4
        114854 A F209 02333520 00 0B 28 A001 FA2CE4 698D22 010E _sfail _noAnsw
        141235 A F202 02359676 00 01 AE _ping
        175140 A F202 02393308 00 01 AE _ping
        210661 A F102 02428540 00 01 AE _ping
     hmQ:
       000000:
       698A2E:
       698B42:
       698B5E:
       698C0F:
       698C3A:
       698C52:
       698CCD:
       698CFA:
       698D22:
       698D6E:
       6B7AB3:
       6B7AB4:
       6B7AC2:
       6B7AC4:
       6B7AC9:
     ids:
       698A2E:
         cfg        +698A2E,00,01,00
         name       OG_WOH_Deckenspot
       698B42:
         cfg        +698B42,00,01,00
         name       OG_ESS_Deckenspot
       698B5E:
         cfg        +698B5E,00,01,00
         name       OG_TRE_Deckenspot
       698C0F:
         cfg        +698C0F,00,01,00
         name       OG_BAD_Deckenspot
       698C3A:
         cfg        +698C3A,00,01,00
         name       OG_KUC_Deckenspot
       698C52:
         cfg        +698C52,00,01,00
         name       OG_SCH_Deckenspot
       698CCD:
         cfg        +698CCD,00,01,00
         name       OG_SCH_Nachtlampe_L
       698CFA:
         cfg        +698CFA,00,01,00
         name       OG_SCH_Nachtlampe_R
       698D22:
         cfg        +698D22,00,01,00
         name       OG_WOH_Tischlampe
       698D6E:
         cfg        +698D6E,00,01,00
         name       OG_WOH_Kugellampe
       6B7AB3:
         cfg        +6B7AB3,00,01,00
         name       OG_WOH_Leinwand
       6B7AB4:
         cfg        +6B7AB4,00,01,00
         name       OG_SCH_Rolladen
       6B7AC2:
         cfg        +6B7AC2,00,01,00
         name       OG_WOH_Rolladen
       6B7AC4:
         cfg        +6B7AC4,00,01,00
         name       OG_KUC_Rolladen
       6B7AC9:
         cfg        +6B7AC9,00,01,00
         name       OG_ESS_Rolladen
     loadLvl:
       bl         40
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       RQLSt      0
       RQLt       0
       XRpCnt     0
       XRpTm      1564900148.36344
       answerPend 0
       hmLanQlen  1
       apIDs:
         698A2E     0
         698B42     0
         698B5E     0
         698C0F     0
         698C3A     0
         698C52     0
         698CCD     0
         698CFA     0
         698D22     0
         698D6E     0
         6B7AB3     0
         6B7AB4     0
         6B7AC2     0
         6B7AC4     0
         6B7AC9     0
     ref:
       Sdly       28
       TmBmCnt    1
       ioBR       113943.621545667
       ioBRMax    113943.621545667
       ioBRMean   84825.765874739
       ioBRn      0
       lHMt       35865160
       lSys       458319582
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pngLm      3
       pngMax     13740
       pngMaxTot  13740
       pngMin     -5
       pngRef     -5
       pngtm      457429126
       scErr      0
       scF        1.0083672737872
       scFN       1
       scHT       33966572
       scST       456405120
Attributes:
   group      CUL
   hmId       FA2CE4
   rfmode     HomeMatic
   room       Heizung
   verbose    5


b) Die angegebenen Perl-Programme in das FHEM Verzeichnis kopiert

c) Die Einstellungen der VCCU kontrolliert

Code Auswählen Erweitern


Internals:
   DEF        FA2CE4
   FUUID      5d45904e-f33f-5e09-06f0-284901a43f974e4d
   IODev      RFCUNX1
   NAME       RFVHM
   NOTIFYDEV  global
   NR         49
   NTFY_ORDER 50-RFVHM
   STATE      RFCUNX1:ok,
   TYPE       CUL_HM
   assignedIOs
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1564898206.91722
           VALUE      RFCUNX1:ok,
   READINGS:
     2019-08-03 18:45:26   IOopen          2
     2019-08-04 07:56:46   state           RFCUNX1:ok,
     2019-07-27 13:57:24   unknown_18B83F  received
     2019-08-03 16:15:48   unknown_2B728B  received
     2019-08-02 08:05:48   unknown_30401E  received
     2019-08-02 20:37:43   unknown_62B794  received
     2019-07-29 14:45:25   unknown_65FACE  received
     2019-08-01 21:56:07   unknown_66F920  received
     2019-07-26 08:15:27   unknown_66F96F  received
     2019-08-03 22:58:12   unknown_670BBD  received
     2019-07-31 19:38:55   unknown_680191  received
     2019-07-27 11:53:32   unknown_698CCD  received
     2019-07-27 12:00:02   unknown_698CFA  received
     2019-07-27 12:40:11   unknown_698D22  received
     2019-07-27 11:33:15   unknown_698D6E  received
     2019-08-03 14:05:50   unknown_6A1618  received
     2019-08-01 17:27:21   unknown_6B7AB3  received
     2019-08-01 21:57:18   unknown_6B7AB4  received
     2019-08-01 21:55:49   unknown_6B7AC2  received
     2019-08-01 22:22:41   unknown_6B7AC4  received
     2019-08-03 18:42:02   unknown_6B7AC9  received
     2019-08-03 10:41:48   unknown_6CCD00  received
     2019-08-03 18:57:37   unknown_83ECC9  received
     2019-08-03 22:00:17   unknown_95F7F5  received
     2019-08-03 22:46:05   unknown_97DB2E  received
     2019-08-02 01:29:22   unknown_987BDD  received
     2019-08-03 22:56:21   unknown_A5BB34  received
     2019-08-03 13:43:56   unknown_B8CEE6  received
   helper:
     HM_CMDNR   76
     mId        FFF0
     regLst     ,0
     rxType     1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       RFVHM
       ioList:
         RFCUNX1
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
Attributes:
   IODev      RFCUNX1
   IOList     RFCUNX1
   expert     2_defReg+raw
   hmKey      01:a43f1b6a59137f3980e070cf3e8e0637
   model      CCU-FHEM
   subType    virtual
   verbose    5
   webCmd     virtual:update


d) exemplarisch den Dimm-Aktor OG_WOH_Deckenspot überprüft

Code Auswählen Erweitern


Internals:
   DEF        698A2E
   FUUID      5d45904e-f33f-5e09-7ed2-7b6c303719ff5e8a
   IODev      RFCUNX1
   LASTInputDev RFCUNX1
   MSGCNT     3
   NAME       OG_WOH_Deckenspot
   NOTIFYDEV  global
   NR         85
   NTFY_ORDER 50-OG_WOH_Deckenspot
   RFCUNX1_MSGCNT 3
   RFCUNX1_RAWMSG A0FCBA410698A2EFA2CE4060300003F00::-59.5:RFCUNX1:
   RFCUNX1_RSSI -59.5
   RFCUNX1_TIME 2019-08-04 08:29:18
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 OG_WOH_Deckenspot_Dim
   channel_02 OG_WOH_Deckenspot_Dim_V_01
   channel_03 OG_WOH_Deckenspot_Dim_V_02
   lastMsg    No:CB - t:10 s:698A2E d:FA2CE4 060300003F00
   protCmdDel 3
   protLastRcv 2019-08-04 08:29:18
   protRcv    3 last_at:2019-08-04 08:29:18
   protResnd  9 last_at:2019-08-04 08:29:16
   protResndFail 1 last_at:2019-08-04 07:58:39
   protSnd    7 last_at:2019-08-04 08:29:18
   protState  CMDs_done
   rssi_RFCUNX1 cnt:3 min:-63 max:-62 avg:-62.66 lst:-63
   rssi_at_RFCUNX1 cnt:3 min:-60 max:-59 avg:-59.5 lst:-59.5
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1564900158.5733
           VALUE      CMDs_done
   READINGS:
     2019-07-22 08:09:23   D-firmware      1.1
     2019-07-22 08:09:23   D-serialNr      PEQ0826054
     2019-08-03 18:23:52   PairedTo        0xFA2CE4
     2019-07-27 13:53:21   R-pairCentral   0xFA2CE4
     2019-08-03 22:35:17   RegL_00.       
     2019-07-27 14:40:20   powerOn         2019-07-27 14:40:20
     2019-08-04 08:29:18   state           CMDs_done
   helper:
     HM_CMDNR   203
     cSnd       01FA2CE4698A2E020E,01FA2CE4698A2E030E
     mId       
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       lstRecType 10
       newChn     +698A2E,00,01,00
       nextSend   1564900158.61736
       nxtSndMcnt CB
       rxt        0
       tgtDly     88
       vccu       RFVHM
       lRcTm:
         RFCUNX1    35866528
         tnms       458320964
       p:
         698A2E
         00
         01
         00
       prefIO:
         RFCUNX1
     mRssi:
       mNo        CB
       io:
         RFCUNX1:
           -49.5
           -49.5
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rpt:
       IO         RFCUNX1
       flg        A
       ts         1564900158.54183
       ack:
         HASH(0x24a2168)
         CB8002FA2CE4698A2E00
     rssi:
       RFCUNX1:
         avg        -62.6666666666667
         cnt        3
         lst        -63
         max        -62
         min        -63
       at_RFCUNX1:
         avg        -59.5
         cnt        3
         lst        -59.5
         max        -59
         min        -60
     tmpl:
Attributes:
   IODev      RFCUNX1
   IOgrp      RFVHM:RFCUNX1
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.1
   model      HM-LC-DIM1T-DR
   room       CUL_HM
   serialNr   PEQ0826054
   subType    dimmer
   webCmd     getConfig:clear msgEvents

e) Wie schon eingangs erwähnt endet jedes Kommando in einem timeout gleichwohl welcher Aktor angesprochen wird und bestehende bzw. neue Aktoren lassen sich nicht anlernen (als wenn der Aktor im Anlernmodus keinen Funk aussendet).

Code Auswählen Erweitern

2019.08.04 08:48:08 4: TSCUL_XmitAwaitHMTo RFCUNX1: timeout - 698A2E
2019.08.04 08:48:09 4: CUL_HM_Resend: OG_WOH_Deckenspot nr 2
2019.08.04 08:48:09 5: TSCUL_Write: RFCUNX1 sending As0ECFA011FA2CE4698A2E0201C80000
2019.08.04 08:48:09 4: TSCUL_send:  RFCUNX1  175797                 As 0E CF A011 FA2CE4 698A2E 0201C80000
2019.08.04 08:48:09 4: TSCUL_XmitDlyHM:  RFCUNX1  id:698A2E rtoms:2328
2019.08.04 08:48:09 5: TSCUL_Read RFCUNX1: /A

2019.08.04 08:48:09 5: TSCUL_Read RFCUNX1: /AF103008D196D010ECFA011FA2CE4698A2E0201C8000080

2019.08.04 08:48:09 4: TSCUL_Parse: RFCUNX1  175834 A F103 03433908 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:09 5: TSCUL_Read RFCUNX1: /AF103008D19B1010ECFA011FA2CE4698A2E0201C8000080

2019.08.04 08:48:09 4: TSCUL_Parse: RFCUNX1  176106 A F103 03434180 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 5: TSCUL_Read RFCUNX1: /AF103008D19F5010ECFA011FA2CE4698A2E0201C8000080

2019.08.04 08:48:10 4: TSCUL_Parse: RFCUNX1  176380 A F103 03434452 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 5: TSCUL_Read RFCUNX1: /AF109008D1A38000ECFA011FA2CE4698A2E0201C8000080

2019.08.04 08:48:10 3: LogHist RFCUNX1:  143114 A F103 03401444 05 0E D5 A011 FA2CE4 698C0F 0201C80000 _CCAdly:20
2019.08.04 08:48:10 3: LogHist RFCUNX1:  144600 A F103 03401716 01 0E D5 A011 FA2CE4 698C0F 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: LogHist RFCUNX1:  144600 A F103 03401988 01 0E D5 A011 FA2CE4 698C0F 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: LogHist RFCUNX1:  144600 A F109 03402256 00 0E D5 A011 FA2CE4 698C0F 0201C80000 _sfail _noAnsw
2019.08.04 08:48:10 3: LogHist RFCUNX1:  165618 A F002 03423804 00 01 AE _ping
2019.08.04 08:48:10 3: LogHist RFCUNX1:  172574                 As 0E CF A011 FA2CE4 698A2E 0201C80000
2019.08.04 08:48:10 3: LogHist RFCUNX1:  172609 A F103 03430712 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: LogHist RFCUNX1:  172883 A F103 03430984 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: LogHist RFCUNX1:  173158 A F103 03431256 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: LogHist RFCUNX1:  173399 A F109 03431524 00 0E CF A011 FA2CE4 698A2E 0201C80000 _sfail _noAnsw
2019.08.04 08:48:10 3: LogHist RFCUNX1:  175797                 As 0E CF A011 FA2CE4 698A2E 0201C80000
2019.08.04 08:48:10 3: LogHist RFCUNX1:  175834 A F103 03433908 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: LogHist RFCUNX1:  176106 A F103 03434180 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: LogHist RFCUNX1:  176380 A F103 03434452 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: TSCUL_ParseTsHM: RFCUNX1 HM repeat failed to 698A2E/OG_WOH_Deckenspot:  176621 A F109 03434720 00 0E CF A011 FA2CE4 698A2E 0201C80000 _sfail _noAnsw
2019.08.04 08:48:11 4: TSCUL_XmitAwaitHMTo RFCUNX1: timeout - 698A2E


Bin aktuell etwas ratlos was ich noch ausprobieren bzw. anpassen kann, außer die gemachten Änderungen wieder rückgängig zu machen. Vielleicht übersehe ich auch etwas Essentielles und jemand hat einen guten Tipp für mich.

Herzliche Grüße,
Peter

[frank]

hallo peter,

seltsam finde ich das reading IOopen=2 bei deiner vccu, da es ja nur ein io gibt. dem entsprechend gibt es beim state reading wahrscheinlich am ende auch ein komma für ein weiteren state eines 2. ios.

bei der vccu fehlt noch das attr IOgrp.

nutzt du 10_cul_hm.pm, hmconfig.pm, 98_hminfo.pm aus der zip datei, oder die aktuellen "normalen" dateien?

fhem restart hast du sicherlich gemacht.

[noansi]

Hallo Peter,

was sagt ccconf beim CUNX?

Vermutlich liegt es am hmFreqOffset.
Versuch mal ein set hmFreqOffset 0 beim CUNX. Damit wärest Du beim Stand vor dem Flashen der Firmware, was den hmFreqOffset angeht.

Wenn dann was geht, dann kannst Du mit hmFreqOffset vermutlich noch weiter ins + gehen.
Mein CUNX, der auf  HM läuft, hat z.B. mit 17.456kHz Offset sein Optimum zu meinen HM devices.

Gruß, Ansgar.

[ph573]

Hallo Frank,
hallo Ansgar,

danke für Eure Rückmeldungen und Beobachtungen:

seltsam finde ich das reading IOopen=2 bei deiner vccu, da es ja nur ein io gibt. dem entsprechend gibt es beim state reading wahrscheinlich am ende auch ein komma für ein weiteren state eines 2. ios.

In der Tat hat es bis vor ein paar Tagen eine zweite stackable CUL gegeben die in der VCCU konfiguriert war. Ich hatte sie rausgenommen, da ich nicht sofort alle mit der TSCUL Firmware flashen wollte. Dabei übersehen, dass FHEM ein Gedächtnis in Form der SAVE- und EVENTS-Dateien hat. Inzwischen gelöscht, IOopen ist nun 1, aber das Komma im state bleibt. Habe daher auch eine weitere VCCU erzeugt um zu sehen, ob dort das Komma bei nur einer CUL weggeht: dem ist nicht so, Komma bleibt.

Dann irrtümlich die "produktive" VCCU gelöscht, und siehe da die CUNX kann mit allen Aktoren perfekt kommunizieren. Jetzt habe ich direkt alle Aktoren an der CUNX angelernt.

bei der vccu fehlt noch das attr IOgrp.

nutzt du 10_cul_hm.pm, hmconfig.pm, 98_hminfo.pm aus der zip datei, oder die aktuellen "normalen" dateien?

fhem restart hast du sicherlich gemacht.

IOgrp hatte ich ergänzt, hat keine Verbesserung gebracht. Dateien aus dem TS-Zip wurden kopiert, und die ganze Box wurde neu gestartet.

Vermutlich liegt es am hmFreqOffset.
Versuch mal ein set hmFreqOffset 0 beim CUNX. Damit wärest Du beim Stand vor dem Flashen der Firmware, was den hmFreqOffset angeht.

Ich habe ich vorm Löschen der VCCU mit verschiedensten Frequenzoffsets gespielt, keine Verbesserung erzielt.

Vielleicht schaffe ich es die Tage noch den zweiten CUL zu flashen, dabei auch eine neue VCCU anlegen, einfach nur um zu sehen ob es an der "nur mit einer Sendestation verbundenen VCCU" liegt.

[handy80]

Hallo,
wie kann ich meine TSCUL updaten? Bin noch auf FW 0.18 (VERSION VTS 0.18 CUL868) und (VERSION_HW ist CUL_V3.4)
hab mich hier im Thread zurück-gewurschtelt, aber dann bin ich bei den Preconditions irgendwie verwirrt.
Kann jemand kurz für mich als Dummie skizzieren, welche Schritte ich auf meinem Raspi in welcher Reihenfolge machen muss um den USB-Stick von busware inkl. FHEM upzudaten. Wichtig sind vermutlich die richtigen Versionen und wo ich die Dateien runterladen kann.

nach etlichen Versuche über fhem habe ich mich für den manuelle Weg (DFU Bootloader) entschieden. Eine Anleitung habe ich bei busware http://busware.de/tiki-index.php?page=DFU+Bootloader gefunden. Prozessor-Name noch auf der Produkt-Seite bei busware gefunden (atmega32u4 in meinem Fall für einen CUL V3)

Dann den Rest von Ansgars Anleitung befolgt und ich bin auf dem neusten Stand.

Gruß Holger

[CHDI]

Hallo zusammen,

ich werde nicht wirklich fündig, bin aber die 57 Seiten auch "nur" überflogen.

Ich habe folgende Konstellation:

Raspi
- nanoCul_433 IT
- nanoCul_868 HM

wegen Homematic möchte ich gerne die TS Variante nutzen:
- nanoCul_868 geflashed
- FHEM Files eingespielt (vor Update geschützt)
- TSCUL defined
- soweit alles gut

Ich war davon ausgegangen, dass ich meinen 433er wegen dem Austausch der FHEM Dateien nun auch flashen muss. IT ist ja auch in der FW mit drin. Also:
- 433er hex erstellt (bis auf 443 nichts in der board.h verändert IT ist ja eingeschaltet) und geflashed.
- CUL als TSCUL defined.

list CUL443:

Code Auswählen Erweitern


Internals:
   CMDS       ABCEFGJKMRUVWXYZeilmtux
   Clients    STACKABLETS:STACKABLE:TSCUL_WS:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_RFR:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:HMS:FS20V:CUL_TCM97001:CUL_REDIRECT
   DEF        /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 1334
   DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400
   FD         13
   FHTID      1334
   FUUID      5d925f33-f33f-ee52-e6e2-02eea5efc750bddf
   NAME       VH.CUL433
   NR         91
   PARTIAL   
   RAWMSG     
   STATE      Initialized
   SlowRF_BitBufferOvrfl 0
   SlowRF_BucketOvrfl 0
   SlowRF_IntCalcStat Last: 25.0  Min: 25.0  Mean: 25.0  Max: 40.0
   TYPE       TSCUL
   VERSION    VTS 0.31 CSM433
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes AES ChTblSize:209
   XmitOpen   0
   initString AP<
X21
AM5
AHF11334
   msgLoadCurrent 30
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:TSCUL_WS ^K.....
     B:IT       ^i.(?::.|.....)
     C:CUL_FHTTK ^T[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F]
     D:CUL_HOERMANN ^R..........
     E:TSCUL_TX ^TXA.........
     F:CUL_IR   ^I............
     G:SOMFY    ^Y[r|t|s]:?[\dA-F]+
     H:Revolt   ^r......................$
     I:ESA2000  ^S................................$
     J:TSCUL_RFR ^[\dA-F][\dA-F][\dA-F][\dA-F]~.
     K:TSCUL_EM ^E0.0[\dA-F]..............
     L:FS20V    ^81..(?:04|0c)..0101a001......00[89a-f]...
     M:BS       ^81..(?:04|0c)..0101a001a5cf
     N:USF1000  ^81..(?:04|0c)..0101a001a5ceaa00....
     O:FS20     ^81..(?:04|0c)..0101a001
     P:FHT      ^81..(?:04|09|0d)..(?:0909a001|83098301|c409c401)..
     Q:TSKS300  ^810d04..4027a001
     R:HMS      ^810e04......a001
     S:CUL_TCM97001 ^s[\dA-F]+
     T:CUL_REDIRECT ^o
   READINGS:
     2019-10-04 17:21:05   Ints_per_sec    SI: 2.31664  TI: 0.50999  S: 0.38000  L: 0.00000  U: 0.03333  M: 0.00333
     2019-10-04 18:10:53   Xmit-Events     disconnected:1 non-HM:2
     2019-10-04 17:56:04   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:12dB
     2019-10-04 18:07:40   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-10-04 18:10:53   cond            non-HM
     2019-10-04 18:07:39   prot_disconnected last
     2019-10-04 18:10:53   prot_non-HM     last
     2019-10-04 18:07:42   state           Initialized
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     nRec       0
     recAlive   1
     recd       0
     DEVIO:
       RXfailTO   
     HM:
       ChTblSize  209
       FUP        0
       hmCrdts    3
       ChTbl:
       msgCNT:
         0x02       18
     SRf:
       lastIntC   1203
       lastIntCTime 1570205562.30631
       lastIntTOC 191
       lastSyncC  242
       lastloFltC 0
       lastmtchErrC 0
       lastupFltC 24
       IntStat:
         Max        40
         Mean       25
         Min        2
         N          1
     cnd:
       250        2
       253        1
     ids:
     q:
       HMcndN     250
       hmLanQlen  1
     ref:
       ioBR       3840
       ioBRMax    3684.94040572729
       ioBRMean   3652.98752223861
       ioBRMeas   3657.40622498186
       ioBRn      82
       ioBRnC     18
       ioBRptm    1570205627.25507
       ioBRs      65753.775400295
       lHMt       4294967295
       lSys       1656605259.95772
       scF        1
Attributes:
   room       CUL


Leider funkt er nun nicht mehr an die IT Steckdosen. Mir ist aufgefallen, dass RAWMSG leer ist, das ist bei der a-culfw anders
- a-culfw wieder drauf gespielt: Steckdosen schalten funktioniert wieder...

Mit der a-culfw bekomme ich im EventMonitor raw: is10..... angezeigt, das tut es mit der TSCUL_FW nicht.

Was wäre denn das richtige Vorgehen?
Muss ich den 443er mit TSCULFW betreiben? (wegen Austausch der FHEM Dateien)
    Wenn ja: muss ich ihn auch als TSCUL definieren
    Wenn nein: definiere ich ihn als CUL nicht als TSCUL und der Austausch der FHEM Dateien ist egal?

Ich fürchte es fehlt im Moment noch eher grundlegende Verständnis für das parallele Betreiben mit unterschiedlicher FW. Als die Konfig. Bisher hatte ich die immer analog.
Gruß Chris

[noansi]

Hallo Chris,

ich werde nicht wirklich fündig, bin aber die 57 Seiten auch "nur" überflogen.

Wie jetzt...?   

Wenn Du die tsculfw nutzen willst, dann musst Du die fhem Module aus der zip benutzen.
Für IT insbesondere auch die 10_IT.pm aus der zip.

Was eventuell ein Problem sein könnte, ist die Anzahl der Wiederholungen beim IT device.
Die a-culfw wiederholt 6 mal per default. Die tsculfw 3 mal per default.
Versuch mal beim IT device das Attribut "ITrepetition" auf 6 zu setzen. Eventuell will Dein device mehr Wiederholungen, um zu verstehen.
Ein list vom IT device hast Du leider nicht beigepackt.

Mit der a-culfw bekomme ich im EventMonitor raw: is10..... angezeigt, das tut es mit der TSCUL_FW nicht.

Auch die tsculfw schickt ein "is..." zurück, wenn sie hat senden können. Es kann aber passieren, dass sie nicht senden kann. Bei mangelnden credits käme ein "LOVF" und wenn der Sendekanal als belegt erkannt wird käme ein "NOCCA", statt zu senden. Mit einem verbose 5 beim 433er nano würdest Du das auch im Log sehen können.


Da Du nur zwei nanoCuls verwendest solltest Du problemlos auch den 433er mit a-culfw flashen können und diesen auch, als CUL definiert (nicht TSCUL), wie zuvor gewohnt nutzen können. Allerdings musst Du dann das standard 10_IT.pm verwenden und nicht das aus der zip.
Den 868er würdest Du mit tsculfw flashen und als TSCUL definieren und damit Homematic machen. Das 10_IT.pm ist dafür irrerelvant.

Nur wenn Du gestackte CULs, also bspw. SCC oder COC verwenden würdest, dann könnte ich mir Unverträglichkeiten im Mischbetrieb vorstellen.

Gruß, Ansgar.

[noansi]

Hallo Holger,

die Nutzung con TSCULflash setzt, ebenso, wie CULflash, für einen CUL V3 den installierten dfu-programmer vorraus.

Andere CULs mit serieller Schnittstelle erforden den installierten avrdude.

Wenn das CommandRef nach Kopieren der FHEM Module aktualisiert ist, ist die Nutzung von TSCULflash dort zu lesen.

Gruß, Ansgar.