CUL-Probleme - andere FW nutzen?

Begonnen von errazzor, 07 Juni 2019, 08:23:37

Vorheriges Thema - Nächstes Thema

errazzor

Hallo,

ich betreibe seit längerem einen CUL mit Firmware culfw 1.67 per Ser2Net an einem zweiten Raspi.
Der Raspi mit dem CUL befindet sich im Erdgeschoss und alle Devices im Erdgeschoss haben den CUL als bevorzugtes Device im Attribut IOGrp eingetragen (VCCU:CUL_SER)

Ich habe folgende Probleme:

- Manche Devices weisen immer mal wieder eine gestörte Kommunikation auf (MISSING_ACK, Register Timeout, AESComm2Dev failed). Allerdings nicht immer und nicht alle Devices!
Beispielsweise habe ich im Wohnzimmer 3 Rolladenaktoren direkt untereinander. Zwei davon kommunizieren völlig problemlos, der dritte hat immer wieder die oben beschriebenen Probleme.

- Fenstersensoren melden Status nicht zuverlässig (LED leuchtet rot, MISSING_ACK bzw. AESComm2Dev failed) - aber auch nicht alle und nicht immer!

- Anlernen/Pairen von Devices geht überhaupt nicht mehr über den CUL, nur über meine anderen Gateways wie den HMLAN oder HMUART

Jetzt habe ich etwas von der angepassten Firmware mit der Timestamp Funktion gelesen, allerdings verstehe ich da nur Bahnhof.

Kann mir bitte jemand helfen und mir sagen:

- ob diese Firmware besser geeignet und mein Problem beheben könnte
- wenn ja, wie ich diese FW auf den CUL bringe und was ich sonst noch machen muss

Das wäre prima.

Danke vorab!


MadMax-FHEM

Zitat von: errazzor am 07 Juni 2019, 08:23:37
Hallo,

ich betreibe seit längerem einen CUL mit Firmware culfw 1.67 per Ser2Net an einem zweiten Raspi.
Der Raspi mit dem CUL befindet sich im Erdgeschoss und alle Devices im Erdgeschoss haben den CUL als bevorzugtes Device im Attribut IOGrp eingetragen (VCCU:CUL_SER)

Ich habe folgende Probleme:

- Manche Devices weisen immer mal wieder eine gestörte Kommunikation auf (MISSING_ACK, Register Timeout, AESComm2Dev failed). Allerdings nicht immer und nicht alle Devices!
Beispielsweise habe ich im Wohnzimmer 3 Rolladenaktoren direkt untereinander. Zwei davon kommunizieren völlig problemlos, der dritte hat immer wieder die oben beschriebenen Probleme.

- Fenstersensoren melden Status nicht zuverlässig (LED leuchtet rot, MISSING_ACK bzw. AESComm2Dev failed) - aber auch nicht alle und nicht immer!


CUL und Homematic: Forum suchen und du wirst einiges finden (wenn du missing ack / timeout register read mit dazu nimmst), gleiches im Internet. Auch im Wiki (zu Homematic) steht, dass ein CUL nicht optimal ist.

Durch ser2net wird es verm. nicht besser, da die Telegrammbearbeitung nicht im CUL stattfindet (wie bei einem richtigen HM-IO, das sendet zumindest die ACKs selbständig) sondern in fhem und zurück zum CUL bevor er das Telegramm sendet... Tja...


Zitat von: errazzor am 07 Juni 2019, 08:23:37
Jetzt habe ich etwas von der angepassten Firmware mit der Timestamp Funktion gelesen, allerdings verstehe ich da nur Bahnhof.

Kann mir bitte jemand helfen und mir sagen:

- ob diese Firmware besser geeignet und mein Problem beheben könnte

Ob die FW das Problem behen kann: musst du testen.
Bei mir (und vielen anderen) hat es geholfen...
...allerdings kommt bei dir noch die ser2net-Problematik (roundtrip-Zeit) dazu...

Wenn du wirklich Ruhe haben willst, dann evtl. gleich ein richtiges HM-IO.
Z.B. HMOD-PCB, geht auch per USB, WLAN, LAN, ... https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi



Zitat von: errazzor am 07 Juni 2019, 08:23:37
Jetzt habe ich etwas von der angepassten Firmware mit der Timestamp Funktion gelesen, allerdings verstehe ich da nur Bahnhof.

Kann mir bitte jemand helfen und mir sagen:

- wenn ja, wie ich diese FW auf den CUL bringe und was ich sonst noch machen muss


Was, wo, wie: https://forum.fhem.de/index.php/topic,24436.msg175466.html#msg175466


Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

errazzor

#2
Danke für deine Antwort.

Den von Dir verlinkten Beitrag zur TS-FW habe ich ja gefunden, allerdings wie geschrieben, ich verstehe da nur Bahnhof.
Deswegen hatte ich auf eine einfache (verständliche) Erklärung gehofft (falls es die gibt...)

Dann werde ich mich wohl eher mit dem Austausch des CULs durch ein anderes GW beschäftigen müssen. Allerdings kann ich an der Stelle wo das GW steht nur per USB oder WLAN anschliessen, da die GPIO des zweiten Raspi anderweitig belegt sind.

MadMax-FHEM

#3
Sollte im ersten Beitrag eigentlich alles stehen...

Im Prinzip (ist aber bei mir schon etwas her):

- runterladen der FW (passend für den CUL, wenn bereits was vorcompiliertes da ist / sonst: selber bauen, ist halt etwas mehr zu lesen/machen)

- runterladen der angepassten fhem-Module (evtl. ist es auch nur ein Paket wo alles drin ist)

- FW auf den CUL flashen

- fhem-Module nach /opt/fhem/FHEM kopieren (bei Standard-Installation / dann: sudo chown -r fhem:dialout /opt/fhem/FHEM  ebenfalls bei Standardinstallation)

- die ausgetauschten fhem-Module (nicht die zusätzlichen, da ist es egal ;)  ) in exclude-from-update (damit sie bei einem fhem update nicht wieder mit den "originalen" überschrieben werden / und damit ist es dann schon nicht mehr so einfach wie mit einem echten HM-IO / weil du ab und an schauen musst, dass du evtl. nachgezogene fhem-Module einpflegen kannst/musst  / und das musst du wie oben beschrieben manuell tun...)

- aus CUL TSCUL (glaube ich) in der fhem.cfg machen: auf die "DEF" klicken und anpassen...

- fhem neu starten und das sollte es gewesen sein...

Sollte aber alles im ersten Thread beschrieben sein und im Zweifel lieber das machen was dort steht als das was ich geschrieben habe ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)