[gelöst] Probleme mit nanoCUL und Homematic Rolladen Aktor nach Stromausfall

[frank]

vermutlich ist das attr IODev vom aktor die ursache.

hier steht nämlich nanoCUL2 zum senden drin. diesen hast du aber disconnected und ausserdem hat dieser keinen empfang wegen der reichweite, wie du sagtest. also setze mal beim aktor zusätzlich manuell folgendes attribut:

Code Auswählen Erweitern

attr HM_4E0C99 IOgrp VCCU:nanoCUL

danach nochmal drüber pairen. eventuell musst du öfter pairen, denn auch mit diesem cul scheint der funk nicht besonders gut zu sein.

[Puschel74]

Zitat aus dem Wiki zum HM-Lan-Adapter:

Wichtig ist es, die hmId zu vergeben. Diese ist ein 3-Byte hexadezimal-Wert, somit eine 6-stellige Zeichenfolge in Großbuchstaben. 000000 und FFFFFF sind ungültig. Wenn HM-Geräte mit der Zentrale gepairt werden, wird ihnen diese hmId eingetragen

https://wiki.fhem.de/wiki/HM-CFG-LAN_LAN_Konfigurations-Adapter
Den relevanten Teil hab ich mal hervorgehoben.

Edith: Auch im Bereich https://wiki.fhem.de/wiki/CUL_HM
findet sich ein Verweis:

Voraussetzungen

HomeMatic Interface: CUL im HomeMatic Modus oder HMLAN Konfigurator.

Wobei der HMLAN Konfigurator als Link ausgeführt ist.

[thgorjup]

Ja, dass dachte ich auch aber in Verbingung mit der VCCU hatte ich Probleme mit unterschiedlicher FTHID.
Deswegen habe ich beide auf 0000 gesetzt und dann klappt auch das anlernen meiner Devices im DG.
Ich denke ohne VCCU müssen die unterschiedlich sein.

Ich schick den Aktor zurück zu ELV.
Hab schon angerufen. Die schicken einen neuen Bausatz.
Muss ich wieder löten.... 

[Puschel74]

FHTID und HMID sind 2 unterschiedliche Paar Schuhe die miteinander nichts zu tun haben.

FHTID wird im DEF definiert und dient der Kommunikation mit FS20/FHT-Geräten und DARF 0000 sein wenn man seine FHT nicht steuern will sondern nur lauschen.
HMID wird als Attribut angelegt und DARF NICHT 0000 oder FFFF sein - daran ändert weder eine vCCU noch ein nanoCUL etwas.

Das sich mit einer HMID = 0000 auch nur irgendein HM-Device korrekt pairen hat lassen glaube ich dir nicht.

[thgorjup]

Naja, die HMID ist ja auch F1 + FHTID also in meinem Fall F10000

[Puschel74]

Das mag sein aber in deinen bisherigen List der Devices habe ich nirgend ein korrektes Pairing gesehen.
In jedem der gezeigten Devices (NICHT vCCU und auch NICHT die nanoCUL) fehlt mir die Zeile:

2016-11-29 21:48:36   PairedTo        0x123ABC

Und solange diese Zeile mit der korrekten HMID NICHT im Device steht ist dieses nicht gepairt.

Zeig bitte nochmal ein list deines vermeintlichen gepairten Devices aus dem DG.

[Otto123]

In praktisch jeder Anleitung zum CUL steht bla bla bla 0000. Damit wird die FHTID -> 0000
Aus der FHTID macht die "CUL DEF" oder wer auch immer dann noch automatisch eine HMID -> F10000
Es sei denn ich lege eine extra Attribute HMID an - aber warum denn es geht doch auch so!?!

Damit haben 95 % der CUL User auf dieser Welt eine HMID F10000 und wenn man sie fragt wissen sie von nix. Die steht ja auch nirgendwo! 
Die wird intern automatisch verwendet und nicht sichtbar als Attribute angelegt.

Das ist leider so.

Das mit der unterschiedlichen FHTID bei zwei CULs und der angeblichen Gleichheit der FHTID bei einer VCCU erscheint mir völlig unlogisch.
Ich kann es aber nicht nachvollziehen, ich habe keinen CUL. Und ich kann ihn für Homematic auch nicht unbedingt empfehlen.
Und mindestens die TimeStamp Firmware wäre Pflicht.

Gruß Otto

[Puschel74]

Das mit der unterschiedlichen FHTID bei zwei CULs und der angeblichen Gleichheit der FHTID bei einer VCCU erscheint mir völlig unlogisch.

Die FHT-ID muss in einem System einmalig sein und kann NICHT zweimal vergeben werden.
Eine vCCU hat mit der FHTID nichts am Hut da die vCCU für Homematic gedacht ist und die FHT-ID aber für FS20/FHT-Geräte.

Warum nicht einfach die FHT-ID löschen und eine gültige HMID vergeben und nochmal versuchen das System richtig aufziehen?

Im 8. Beitrag haben wir es ja schon:

2017-01-11 08:33:40   R-pairCentral   set_0x000000

Wenn zu diesem Zeitpunkt die FHT-ID wirklich 0000 war hat das System eben nicht F10000 draus gemacht sonst würde dort stehen

2017-01-11 08:33:40   R-pairCentral   set_0xF10000

Edith:

Die wird intern automatisch verwendet und nicht sichtbar als Attribute angelegt.

Doch - beim pairen mit einem Device in diesem Device als Reading 

[Otto123]

Nein Du verstehst mich falsch: Im CUL Device wird die HMID nicht angezeigt, im gepairten Device schon.


Das hier

2017-01-11 08:33:40   R-pairCentral   set_0x000000

kenne ich. Das kommt nicht von einer falschen HMID sondern, das senden manche (alle) Homematic Device irgendwie als "ZwischenInfo". Zumindest wenn ein Hm Gerät schon mal angelernt war, ein Reset über die Zentrale erfahren hat, wird diese Reading nach dem reset angezeigt.
In dem Moment wo man ein pairing gestartet hat und das Device noch nicht reagiert hat, wird dort set_HMID eingetragen. Das ist immer noch ein Zwischenzustand.

Die FHT-ID muss in einem System einmalig sein und kann NICHT zweimal vergeben werden.

Das sehe ich genauso!

Das mit der HMID hat er ja gemacht, da er eine VCCU gemacht hat, die übernimmt den Job.

[thgorjup]

Jungs, der Rolladen Aktor funktioniert wieder. Warum kann ich nicht sagen.

Ich habe folgendes getan:

- Auf meinem zweiten Raspberry FHEM installiert (habe also jetzt ein Testsystem)
- Produktiv-System runtergefahren und nanoCUL an das Testsystem angeschlossen und auch mit VCCU und gleicher HMID F10000 konfiguriert
- Der Aktor wurde auf Anhieb per set VCCU hmPairForSec 60 und Config Button am Aktor angelernt
- Hoch/Runter getestet - alles gut.
- nanoCUL wieder an Produktiv-System angesteckt und hochgefahren
- Aktor reagierte wieder nicht 
- Alle USB Komponenten (eBus, JeeLink, nanoCUL2) entfernt so dass nur noch nanoCUL angeschlossen ist
- Reboot, Aktor reagiert immer noch nicht und neu anlernen nach Aktor Reset geht auch nicht
- fhem.cfg gesichert
- nanoCUL2 in der Config gelöscht
- Reboot, Aktor resettet, neu angelernt, klappt  hoch/runter - alles gut
- Shutdown, USB Komponeneten wieder angeschlosssen, reboot
- fhem.cfg mit Sicherung überschrieben, sodaß die nanoCUL2 Config wieder am Start ist
- FHEM gestartet
- Rolladen-Aktor funktioniert weiterhin und alle Devices im DG über nanoCUL2 funktionieren ebenfalls

Ich kann es mir nicht erklären....

Allerdings habe ich nun die DriveUP/DriveDown Zeit nachtragen wollen und sehe in den Readings:

Code Auswählen Erweitern


R-driveDown set_22 s
R-driveUp set_24 s


Also wurde das nicht fertig geschrieben. Ich bin echt ratlos. Aber zumindest geht der Rolladen wieder.


EDIT: Ich hatte gestern aus Verzweiflung einen neuen Rolladen-Aktor bestellt der heute geliefert wurde. Den konnte ich eben auf Anhieb anlernen mit allen USB-Komponenten angesteckt. Also muss der Problem-Aktor wirklich ein Problem haben und meine Config ist OK 

[thgorjup]

Hmm, mittlerweile hat es der Aktor akzeptiert   

Code Auswählen Erweitern


R-driveDown 22 s
R-driveTurn 0.5 s
R-driveUp 24 s