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

[RaspiLED]

Hi,
kann es sein, dass Dein FTDI unter dem Testpin Bug leidet?
https://ketturi.kapsi.fi/2014/04/how-to-fix-moody-arduino-nano/
Gruß Arnd


Gesendet von iPhone mit Tapatalk

[klausw]

kann es sein, dass Dein FTDI unter dem Testpin Bug leidet?

Danke für den Tip Arndt.
Ich ringe noch mit mir den nanoCUL auseinaner zu löten 

[Cube]

Ich lese mich gerade in die tsculfw-Thematik ein, da ich mit der Standard-Firmware in letzter Zeit auch immer häufiger Probleme habe. Dabei stelle ich mir die folgende Frage: Wieso wird diese Firmware und die FHEM-Module, die dafür benötigt werden, nicht über ein Third-Party-Repo und die update-Funktion bereitgestellt? Das würde die Einbindung und das Aktualisieren doch deutlich vereinfachen.

[noansi]

Hallo Testwillige,

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

Diese Version bietet neben einigen Verbesserungen insbesondere nun auch Support für CUNX.

Für CUL-IOs mit großem SRAM Speicher (SCC,COC,CUNO2,PIGATOR,CUNX...) 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 CHANGED:
- support for CUNX with USB and network, dfu-programmer 0.7.2 required for flashing. Flashable via USB only. TSCULflash supports it.
  dhcp works
  PIM modules are supported (tested with cc1101 PIGATOR only). PIGATOR flashing is also possible, but via USB only. TSCULflash supports it.
  Unfortunately the bootloader clears the CUNX EEPROM every time the unit is flashed.
  00_TSCUL.pm allows backup of EEPROM with get eeprom into log directory. get eerestore allows to restore the EEPROM with this file.
  For linux use take a look at devices/99-usb-serial.rules for an example to make sure to allways get the same TTY connection.

- 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

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_30_FHEM_Modules_00_41_8.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,  TSCUNX 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:

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_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             -> 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.
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.30 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

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

EDIT1: 10_IT.pm aktualisiert wegen \r im Commandref Text.
EDIT2: 97_timerTS.pm 98_apptime.pm 98_apptm.pm aktualisiert, um undefinierte PrioQueue Einträge abzufangen
            00_TSCUL.pm aktualisiert, kleinere Anpassungen für Datenratemessung
EDIT3: 97_timerTS.pm 98_apptime.pm 98_apptm.pm aktualisiert, für korrekte Funktion von PrioQueues
EDIT4: unnötige u. ggf. fehlerträchtige use vars aus Modulen entfernt
EDIT5: 00_TSCUL.pm aktualisiert, Korrektur für dummy Attribut
           98_apptime.pm 98_apptm.pm aktualisiert

[noansi]

Hallo Cube,

Wieso wird diese Firmware und die FHEM-Module, die dafür benötigt werden, nicht über ein Third-Party-Repo und die update-Funktion bereitgestellt? Das würde die Einbindung und das Aktualisieren doch deutlich vereinfachen.

Weil mein Fokus auf der Firmwareentwicklung liegt und nicht darauf einen eigentlich nicht so schwierigen Vorgang noch einfacher zu gestallten.

Zweites Hemmnis, meine Modulvarianten haben großenteils ein Pendant in der Standard FHEM Version zur Unterstützung der Standard culfw. Damit gäbe es dann zwei Möglichkeiten für Ähnliches aber nicht voll Kompatibles, was dann zu ganz anderen User Verständnisproblemen führen würde.
Und ich denke schon aus Support Gründen nicht, das Rudolf sehr glücklich über über solch eine Zweigleisigkeit in FHEM wäre.

Gruß, Ansgar.

[sash.sc]

Habe da mal so ne frage.

Besteht die Möglichkeit, die Firmware auf nen esp 8266 oder esp32 zu portieren?
Mit wlan Anbindung, oder so?

Die beiden Chips dürften ja auch mehr Speicher zur Verfügung stellen, oder?

Gruß Sascha

Gesendet von meinem E6653 mit Tapatalk

[noansi]

Hallo sash.sc,

Besteht die Möglichkeit, die Firmware auf nen esp 8266 oder esp32 zu portieren?

Mag sein.
Weder kenne, noch habe ich die Hardware.
Ein 16Bit Timer mit 8µs Takt und Interruptmöglichkeiten ist eine Vorraussetzung.
Für SlowRF muss ein I/O Pin Interrupts auslösen können.

Ist auf jeden Fall ne Menge Arbeit, sogar, wenn die Hardware, wie beim XMEGA nicht ganz so weit vom ATMEGA weg ist. Die andere Registerdefinition alleine macht es schon unangenehm.
Versuchen kannst Du es.

Gruß, Ansgar.

[sash.sc]

Danke für die Info.

Leider reichen da meine Kenntnisse in keinster Weise für aus. [emoji6]

Gesendet von meinem E6653 mit Tapatalk

[MadMax-FHEM]

Vermutlich ist es einfacher den USB-Adapterteil von einem CUL wegzulassen und stattdessen direkt an Rx/Tx einen ESP dran und da dann serialBridge drauf.

Ähnlich wie: HMOD-PCB per WLAN...

...evtl. gibt es das schon im Forum aber halt mit aculfw oder so...
Wäre aber egal, weil man ja auf den Atmega (o.ä.) Teil ja "jede FW" flashen kann...

Gruß, Joachim

[Cube]

Ich habe heute meine Installation umgestellt und alle meine HomeMatic-Probleme sind verschwunden. Vielen Dank für diese Firmware. 

Weil mein Fokus auf der Firmwareentwicklung liegt und nicht darauf einen eigentlich nicht so schwierigen Vorgang noch einfacher zu gestallten.

Zweites Hemmnis, meine Modulvarianten haben großenteils ein Pendant in der Standard FHEM Version zur Unterstützung der Standard culfw. Damit gäbe es dann zwei Möglichkeiten für Ähnliches aber nicht voll Kompatibles, was dann zu ganz anderen User Verständnisproblemen führen würde.
Und ich denke schon aus Support Gründen nicht, das Rudolf sehr glücklich über über solch eine Zweigleisigkeit in FHEM wäre.

Wäre es aber nicht sinnvoll deine Arbeit einem größeren Publikum zugänglich zu machen? Hier im Forum kriegt ja kaum jemand mit, dass es diese Firmware gibt - sieht man auch an den geringen Downloadzahlen der neusten Version. Ein weiterer Punkt der mich zunächst vom Umstieg abgehalten hat ist weniger der initiale Aufwand (der ist wirklich minimal), sondern die Tatsache, dass ich meine Installation jetzt nicht mehr einfach aktuell halten kann. Wenn bei mir alles stabil läuft, dann halte ich sie einfach über die interne Update-Funktion aktuell und treibe mich nicht im Forum rum. Und es werden dann ja nicht nur die exklusiven Module dieser Firmware nicht aktualisiert, sondern auch diverse offiziellen Module.

Noch besser wäre natürlich, wenn diese Firmware offizieller Teil von FHEM werden würde. Die Standard-culfw wird doch schon seit Jahren nicht mehr wirklich weiterentwickelt. Gibt es überhaupt noch vom CUL V2 abgesehen irgendetwas wofür man diese bräuchte? Ich habe beim Überfliegen des Threads gesehen, dass Rudolf das eher skeptisch sieht. Aber das ist letztendlich das allgemeine Problem von FHEM, dass man sich mit größeren Modernisierungen und dem Abschneiden alter Zöpfe schwer tut.

[Cube]

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

Diese Angabe ist nicht vollständig, da fehlen mehrere Dateien. Hier die vollständige Version:

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  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` }

Das funktioniert für die angepasst 10_IT.pm nicht.

Code Auswählen Erweitern


*** EN FHEM/10_IT.pm: ignoring text due to DOS encoding
*** DE FHEM/10_IT.pm: ignoring text due to DOS encoding


[noansi]

Hallo Cube,

Das funktioniert für die angepasst 10_IT.pm nicht.

Danke für den Hinweis, ich habe es korrigiert und oben aktualisiert. Und nebenbei noch eine Änderung von Björn mit rein genommen.

Diese Angabe ist nicht vollständig, da fehlen mehrere Dateien.

Bei ergänzten Dateien ist das auch erst dann wirklich notwendig, wenn die Dateinamen im "regulären" Fhem mal verwendet werden.
Ich habs aber ergänzt. Offensichtlich hast Du aber verstanden, was es bewirken soll. 
10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm sind aber u.U. zu viel, denn die sollten auch grundsätzlich in Martins aktueller Form laufen. Es ist User Entscheidung, was genutzt werden soll.

Wäre es aber nicht sinnvoll deine Arbeit einem größeren Publikum zugänglich zu machen?

Martin weist bei nahezu jeder Frage in CUL Zusammehang auf die TS Firmware hin.
Dieser Thread hier ist öffentlich, jeder kann ihn nutzen.
Wenn Du im Forum selbst auf Fragen Hilfesuchender antwortest, kannst Du direkt hierhin verweisen.

dann halte ich sie einfach über die interne Update-Funktion aktuell und treibe mich nicht im Forum rum.

Dann bist Du mitunter auch schon mal unfreiwillig Alpha oder Beta Tester. Lies mal im Forum.
Es mach schon Sinn, vor einem Update sein Backup auf Stand zu bringen respektive auch Platz dafür zu haben, um bei einem Bug in einem der aktualisierten Module schnell zurück zu kommen. Und auch vorher mal im Forum zu schauen, ob da nicht gerade entsprechende Threads zu u.U. gravierenden Problemen veröffentlicht werden.

Noch besser wäre natürlich, wenn diese Firmware offizieller Teil von FHEM werden würde.

In wieweit alle Funktionen der Firmware funktionieren, kann ich nur mit vorhandener eigener Hardware testen und die umfasst längst nicht alle Funktionen oder Hardwareplatformen.
Von daher von meiner Seite her derzeit keine gute Idee.
User Feedback, um auch diese Funktionen ggf. zu korrigieren ist spärlich, weil die Hauptnutzung wohl auf HM läuft. (Spärlich aber auch, weil eben HM auch schon mit älteren Versionen gut läuft.)

Außerdem gibt es noch die a-culfw mit ihren Ergänzungen insbesondere für SlowRF.

Der User entscheidet, was er braucht und was er will, so sehe ich es.

Aber das ist letztendlich das allgemeine Problem von FHEM, dass man sich mit größeren Modernisierungen und dem Abschneiden alter Zöpfe schwer tut.

Oder aber auch positiv, denn was würdest Du sagen, wenn es Deine mühsam aufgebaute Haussteuerung wegen einer FHEM Modernisierung plötzlich nicht mehr tut?

Und es werden dann ja nicht nur die exklusiven Module dieser Firmware nicht aktualisiert, sondern auch diverse offiziellen Module.

Was bei Verwendung der tsculfw dann auch durchaus Sinn macht. 
Wenn Du 10_IT.pm nicht benutzt, dann ist es egal. Wenn Du es benutzt, dann ginge es sicher schief. Wobei bei einem 868MHz CUL die Nutzung auf 433MHz ohnehin sehr anzuzweifeln ist.
Auf die Änderungen in 98_autocreate.pm kannst Du auch gut verzichten, wenn Du FHEM devices händisch anlegst.

Gruß, Ansgar.

[Mr.Floppy]

Hallo

Da mein Homematic netzwerk nicht optimal läuft wollte ich meinen zweiten nanoCUL mal mit dieser firmware flashen und schauen ob es verbesserungen bringt.
Das Flashen hat soweit funktioniert aber ich verstehe die sache mit den zu ersetzenden .pm dateien nicht richtig.
Werden die Dateien nur hinzugefügt und ggf. überschrieben oder ersetzen sie komplett die angegebenen Dateien?
Die Beschreibung verstehe ich so das die Dateien die alten komplett ersetzen was mich dann zu einer weiteren frage kommen lässt.
Wie sage ich FHEM in der .cfg (wie in der Beschreibung angegeben) das es die neuen dateien benutzen soll?

Gruß

[MadMax-FHEM]

Werden die Dateien nur hinzugefügt und ggf. überschrieben oder ersetzen sie komplett die angegebenen Dateien?

Neue Dateien (also welche die Standard-fhem nicht hat) kommen dazu...
...Dateien die bereits da sind werden natürlich überschrieben...

Rechte/"Eigentumsverhältnisse" anpassen nicht vergessen: sudo chown fhem: /opt/fhem/FHEM/KopierteDatei.pm

(KopierteDatei.pm natürlich jeweils entsprechend / oder "global" über das Verzeichnis: sudo chown -R fhem: /opt/fhem/FHEM   das alles bei Standard-fhem-Installation! Und auf eigenes Risiko!   )

Die Beschreibung verstehe ich so das die Dateien die alten komplett ersetzen was mich dann zu einer weiteren frage kommen lässt.
Wie sage ich FHEM in der .cfg (wie in der Beschreibung angegeben) das es die neuen dateien benutzen soll?

Wie nach einem Update auch: shutdown restart (in Fhem-Web)

EDIT: natürlich das Define des CUL anpassen nicht vergessen!

Dann eine Frage die nicht gestellt wurde...
...trotzdem die Antwort:

wie sage ich fhem, dass die überschriebenen pm-Dateien (von TS-CUL-FW) bei einem Update NICHT wieder durch die "originalen"/Standard-fhem-Dateien ersetzt werden: Attribut exclude_from_update bei global

Gruß, Joachim

[noansi]

Hallo Mr. Floppy,

Werden die Dateien nur hinzugefügt und ggf. überschrieben oder ersetzen sie komplett die angegebenen Dateien?

Die, die es gibt, ersetzt Du und die, die es nicht gibt ergänzt Du durch Kopieren in das FHEM Verzeichnis.

Wie sage ich FHEM in der .cfg (wie in der Beschreibung angegeben) das es die neuen dateien benutzen soll?

In der fhem.cfg Datei hast Du für Deinen nanoCUL einen Eintrag in der Art:

Code Auswählen Erweitern

define nanoCUL CUL /dev/ttyUSB0@38400 0000
Das CUL sorgt dafür dass das Modul 00_CUL.pm verwendet wird.
Folglich musst Du es durch TSCUL ersetzen, damit 00_TSCUL.pm verwendet wird:

Code Auswählen Erweitern

define nanoCUL TSCUL /dev/ttyUSB0@38400 0000

Anschließend ein restart von FHEM und die geänderte Konfiguration wird verwendet.
Wenn Du den nanoCUL nur für HM verwendest und die Attribute passen, bist Du damit für einen Test schon fertig.

Das globale Attribut exclude_from_update kannst Du noch setzen, um die fhem Update Funktion an einer Ersetzung der Dateien zu hindern.

Und die Commandref Aktualisierung geht über Rudolfs Hinweis, wie beschrieben.

Gruß, Ansgar.