Wiki-Eintrag bzgl. Firmware zu CUL und Co. mit Timestamp

[MadMax-FHEM]

Hallo,

ich selbst hatte iauch rgendwann Probleme mit meinem selbstbau nanoCUL in Verbindung mit HomeMatic.
Es ging eigentlich gut und dann ein neues Gerät (Klingelsensor) und damit nur Probleme...

Nach längerem Suchen bin ich dann auf die spezielle Timestamp-FW von Ansgar gestossen. Vielen Dank!

Allerdings war zu der Zeit noch der Austausch vieler/einiger Module notwendig und ich noch Anfänger und traute mich nicht recht das "einfach mal zu versuchen"...

Habe mir dann aber ein Testsystem aufgesetzt und dort einfach mal probiert: hat super geholfen!

Seither gebe ich dann doch häufig den Hinweis auf diese Spezial-FW, wenn in Threads von Problemen bzgl. CUL und HomeMatic die Rede ist, gerade wenn sie evtl. mit Timing zu tun haben.

Anfangs war es auch noch schwer die aktuelle Version der FW und fhem-Module zu finden, selbst ich als "Tester" fand es nicht immer einfach

Das ist jetzt deutlich besser!
Auch dafür danke Ansgar!

In einem Thread:
https://forum.fhem.de/index.php/topic,68145.msg735532.html#msg735532

habe ich mich dann (freiwillig) "breit schlagen lassen" etwas bzgl. der "Sichtbarkeit" dieser Spezial-FW zu tun.

Wiki-Zugnag habe ich mittlerweile, allerdings tue ich mich etwas schwer bzgl. des WIE.

Aktuell wird von CUL-Wiki direkt auf den Thread bzgl. "Spezial-FW" verlinkt und dort (jetzt neu) im ersten Beitrag auf die jeweils aktuellste Version.
Würde ja (im gegensatz zu früher) eigentlich passen, oder?

Zu viel in den CUL-Wiki zu schreiben ist nicht gut/hilfreich...
...denke ich.

Folgender Vorschlag/Idee (ich hoffe ich habe Zeit dafür und kriege raus wie das geht   ):

statt dem direkten Link auf den Thread einen Link auf einen neuen Wiki-Eintrag (CUL-FW mit Timestamp für HomeMatic / oder so ähnlich)...
...dort dann ein wenig erläutern warum, wieso, weshalb und was so grob getan werden muss:

- umflashen
- Module "tauschen"/einspielen
- evtl. bereits vorhandenen CUL "umdefinieren" oder eben neu als TS_CUL etc. definieren

Die Details und aktuellen "Tätigkeiten" dann in dem Thread bzgl. "Spezial-FW"!?

Was haltet ihr davon?
Andere Meinung/Vorgehensweise?

EDIT: achja, der Thread bzgl. "Spezial-FW" ist der hier: https://forum.fhem.de/index.php/topic,24436.0.html

Gruß und danke, Joachim

[Beta-User]

Habe es mir eben auch nochmal angesehen.

An sich gebe ich dir recht, dass es grundlegend in Ordnung ist, dass  zumindest an den beiden wesentlichen Stellen (CUL und Homematic) schon mal ein Hinweis auf die TS_CUL zu finden ist.

Beide Hinweise sind zwar eher etwas "verdruckst", und insbesondere der Hinweis bei Homematic ist nicht unbedingt einladend, das könnte man ggf. auch etwas "neutralisieren".

Den Vorschlag, einen (kleinen) TS_CUL-Artikel zu machen, in dem die wichtigsten Infos zusammengefaßt sind, finde ich gut. Bei der Verlinkung auf den Thread würde ich direkt auf den ersten Beitrag verlinken (mit {{Link2Forum|Area= |Topic= |Message= |LinkText= }}), dann hat man nicht das Problem, sich erst zum ersten Beitrag durchklicken zu müssen, wenn man (wie ich) die aktuellen Beiträge nach oben sortiert.

Zum Wiki-Artikel selbst würde ich neben den genannten Themen noch den Mischbetrieb mit weiteren IO's interessant finden (LAN-GW oä.+TS_CUL - geht das? Kann man eine VCCU betreiben??)

(Sorry, ich habe mir die interne Funktionalität der Module nicht angesehen, wenn ich es richtig verstanden habe, ist der Code nah an CUL_HM, sowas sollte also eigentlich gehen).

[MadMax-FHEM]

Danke für die Rückmeldung und das mit dem Verlinken!

Habe es mir eben auch nochmal angesehen.

An sich gebe ich dir recht, dass es grundlegend in Ordnung ist, dass  zumindest an den beiden wesentlichen Stellen (CUL und Homematic) schon mal ein Hinweis auf die TS_CUL zu finden ist.

Beide Hinweise sind zwar eher etwas "verdruckst", und insbesondere der Hinweis bei Homematic ist nicht unbedingt einladend, das könnte man ggf. auch etwas "neutralisieren".

Meinst du das hier:

Timestamp Firmware mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT REGISTER READ" u.ä. Meldungen kommen.

Äh da hab ich schon ein wenig "gefummelt"

bzw. eher das hier:

Vom Einsatz von nicht originalen Homematic IOs ist eigentlich abzuraten. Es kommt bei allen CUL-Derivaten immer wieder zu Schwierigkeiten bei der Kommunikation mit komplexeren Geräten. Wenn überhaupt ist dringend der Einsatz der TimeStamp Firmware zu empfehlen! Zusätzlich sind unbedingt die Hinweise im Artikel AES_Encryption zu beachten!

Hmmm, mal sehen "neutralisieren" lässt sich (vielleicht) machen...
...aber prinzipiell ist ein Original-IO gerade bei HomeMatic schon (deutlich) problemloser...
...bzw. "spart" man sich zumindest den (mitlerweile deutlich geringeren) Aufwand etwas am "Standrad-fhem" anpassen zu müssen...

Zum Wiki-Artikel selbst würde ich neben den genannten Themen noch den Mischbetrieb mit weiteren IO's interessant finden (LAN-GW oä.+TS_CUL - geht das? Kann man eine VCCU betreiben??)

(Sorry, ich habe mir die interne Funktionalität der Module nicht angesehen, wenn ich es richtig verstanden habe, ist der Code nah an CUL_HM, sowas sollte also eigentlich gehen).

Ja sollte eigentlich gehen.
Es gibt wohl einige die das in der Mischung auch betreiben, zumindest beim immer wieder mit drüber fliegen des Spezial-FW-Threads habe ich denke ich sowas gelesen...

Ansonsten "muss" ich vielleicht den CUL doch wieder zusammenbasteln und ans Testsystem stecken.
Da werkelt mitlerweile halt ein HM-PI-MOD-PCB...

Gruß, Joachim

[Beta-User]

Das war gemeint... Vorschlag der Synthese:

Code Auswählen Erweitern


Erfahrungsgemäß ist der Einsatz originaler Homematic IOs empfehlenswert, da es bei allen CUL-Derivaten immer wieder zu Schwierigkeiten kommen kann, vor allem in größeren Installationen und bei der Kommunikation mit komplexeren Geräten. Wer einen CUL für Homematic verwenden will, sollte eine speziell für den Betrieb mit Homematic optimierte CUL-firmware (TimeStamp Firmware) verwenden. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT REGISTER READ" u.ä. Meldungen kommen!

Zusätzlich sind unbedingt die Hinweise im Artikel AES_Encryption zu beachten!

Zu mehreren IO's: Ist Kür, keine Pflicht...

[noansi]

Hallo Joachim,

danke für den Anfang!

- umflashen
- Module "tauschen"/einspielen
- evtl. bereits vorhandenen CUL "umdefinieren" oder eben neu als TS_CUL etc. definieren

Im Prinzip ja.
Zuallererst natürlich der Hinweis auf ein vorheriges BACKUP der Dateien und alte HEX Datei bereit halten, um bei Problemen den Rückweg offen zu halten!

Insbesondere braucht der Anfänger wohl konkrete Befehls- und Konfigurationsbeispiele, denke ich.

Das Umflashen wird wohl eine der größten Hürden sein.
Wenn das System bezüglich flash-Programm und Rechteeinstellung um Flashen aus FHEM mal richtig eingestellt ist, dann sollte es auch mit TSCULflash gehen.
Da aber nur die passende HEX Datei auf den jeweiligen CUL-Typ zu flashen ist, ist wohl der Verweis auf die jeweilige Flash Anleitung mit Befehlsbeispiel in jedem Fall nötig, um sich nicht erst an der Vielfalt der Rechteprobleme die Zähne ausbeißen zu müssen.

Ansonsten halte ich es für besser, von meiner Seite aus nur Korrektur zu lesen, und den Wiki Artikel eher aus Deiner Sicht und Anfängersicht entstehen zu lassen, da ich selber wohl Probleme an anderer Stelle sehe, als Anfänger. 

statt dem direkten Link auf den Thread einen Link auf einen neuen Wiki-Eintrag (CUL-FW mit Timestamp für HomeMatic / oder so ähnlich)...
...dort dann ein wenig erläutern warum, wieso, weshalb und was so grob getan werden muss:

Ich kann in dem ersten Thread Beitrag zusätzlich zu dem Link auf die aktuelle Version auch einen Link auf den Wiki Eintrag erstellen. Ist zumindest eine einfache Übergangslösung.

Ja sollte eigentlich gehen.
Es gibt wohl einige die das in der Mischung auch betreiben, zumindest beim immer wieder mit drüber fliegen des Spezial-FW-Threads habe ich denke ich sowas gelesen...

Ist so gedacht, dass es im Mischbetrieb mit HMLAN und HMUARTGW geht, aber nur in der Sonder 10_CUL_HM.pm. Es fehlt aber aktuell Feedback dazu, ob es mit der letzten Version geht (oder anders gesagt, es gibt kein Feedback, dass es nicht geht und selber kann ich es nich testen).
Mit der bisherigen Standard 10_CUL_HM.pm erwarte ich jedenfalls noch Probleme.
Wichtig für Multi-IO Betrieb auch den Hinweis auf die Vermeidung unnötiger IO-Umschaltungen einzubauen mit Beispielen, wie das einzustellen ist (Attribut IOgrp und rssiSwitchHyst).

Kann man eine VCCU betreiben??

Ja, und sollte man auch, da bei etwas Spieltrieb der Wunsch danach ohnehin aufkommt. 

Gruß, Ansgar.

[Bozan]

Hallo!

Zunächst einmal: Ich bin blutiger Anfänger mit FHEM, etc. und bgeinne gerade mein System mit Homematic aufzubauen.
Schnell bin ich nun auf die TS_CULFW gestossen und bin neugierig genug, diese einzusetzen. Ich scheue auch keine Risiken experimentiere gerne mit alternativen FW.
Was mir hier allerdings tatsächlich fehlt, ist eine etwas detaillierte Anleitung, wie ich die ts_fw auf den CUL bekomme. Quasi eine Art Schritt-für Schritt Anleitung.
Gibt es das irgendwo?
Besten Dank für Eure Hilfe!

[MadMax-FHEM]

Hallo,

bislang nur im verlinkten (aus 2 Wiki: HomeMatic und CUL) Forum-Thread...

Bin leider noch nicht dazu gekommen...

Was dort evtl. fehlt bzw. nich so ausführlich sein soll (muss gestehen, hab länger nicht mehr so genau geschaut) ist die Beschreibung bzgl. Flashvorgang.
Aber da kann man sich bei anderen CUL Wikis was abschauen...

Wenn etwas fehlt oder hakt wäre es gut hier zu schreiben...

Evtl. auch ein Weg wie es bei dir ging...

Wäre ein Start für den Wiki-Eintrag...

Gruß, Joachim

[Bozan]

So, ich habe es dann heute zum Laufen gebracht, war dann doch nicht so schwer mit ein wenig rumprobieren. Ob alles funzt kann ich natürlich nicht sagen, da mein system ja erst aufgebaut wird. Ist quasi "virgin". Das ersten zwei Geräte kommunizieren jedenfalls schon einmal mit dem CUL.
Kurz zur Hardware:
- Raspberry Pi 3
- CUL v3
- Homematic (Heizungsthermostat, Dimmer)

Fhem war bereits installiert und der CUL war fabrikneu.

TSCUL_fwcode_00_21_FHEM_Modules_00_32.zip herunterladen und entpacken
Ordner Firmware in /opt/fhem/FHEM Ordner kopieren (den ursprünglichen/originalen habe ich lediglich vorher umbenannt)

Da fhem bei mir schon lief und der CUL steckte im fhem folgendes eingeben

Code Auswählen Erweitern

set CUL1 raw B01

Folgendes in der Console des RPI

Code Auswählen Erweitern

cd /opt/fhem/FHEM/firmware
sudo dfu-programmer atmega32u4 erase
sudo dfu-programmer atmega32u4 flash TSCUL_V3.hex
sudo dfu-programmer atmega32u4 start
cd /opt/fhem/FHEM/firmware/tsculfw-code-459-trunk_lufa_00_08\culfw\Devices
sudo cp 99-usb-serial.rules /etc/udev/rules.d/99-usb-serial.rules

Wie im Forum schon beschrieben die neuen Module einfügen/austauschen.
Falls schon auf den CUL in der fhem.cfg Bezug genommen wird, dieses händisch in TSCUL abändern
in fhem.cfg ergänzen

Code Auswählen Erweitern

attr global exclude_from_update 10_CUL_HM.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 98_TSCULflash.pm


Mein CUL war schon einmal bei FHEM mit Standard geflasht daher noch denEintrag in fhem.cfg ändern

Code Auswählen Erweitern

define CUL1 TSCUL /dev/CUL868_0@12000000 1234


Im RPI Terminal

Code Auswählen Erweitern

sudo reboot

Dieses Attribut musste ich dann noch in fhem ändern, damit ich meine devices auch pairen konnte

Code Auswählen Erweitern

attr CUL1 rfmode HomeMatic

Save


Anmerkungen, falls ich mir etwas nicht richtig gemerkt/notiert hatte, oder falls noch etwas grundsätzlich falsch ist.