Geräte ohne CCU ablernen...

Begonnen von DominikG87, 20 Dezember 2017, 10:35:57

Vorheriges Thema - Nächstes Thema

DominikG87

Hallo zusammen,


bin noch ganz neu bei FHEM bzw. der Hausautomation und entweder sind meine "Such-Skills" wirklich schlecht, oder es geht einfach nicht...
Mein Problem:
Ich habe diverse Homematic Heizungs- und Wandthermostate welche an einer CCU angelernt sind. Diese CCU existiert allerdings nicht mehr.
Nun bekomme ich beim anlernen an FHEM immer ein F4 auf dem Display der Thermostate angezeigt.
Meine Frage:
Kann ich die Geräte auch ohne CCU "ablernen", so das ich keine F4 "Fehlermeldung" (ist ja wohl ein Anlernfehler) mehr bekomme?


Grüße
Dominik

marvin78

Ich bin nicht sicher, ob man das wissen kann, wenn man bisher nur eine CCU verwendet hat, aber wenn du die HMID kennst, mit der die Geräte angelernt wurden, dann kannst du das Pairing auch mit dieser HMID wieder entfernen bzw. sollte dann sogar eine Funktion in FHEM gegeben sein, wenn du deinem IODEV/der VCCU diese HMID verpasst.

Beta-User

Hier gabs erst eine ähnliche Diskussion.

Da findest du evtl. Lösungsansätze, v.a. auch um rauszufinden, ob AES aktiviert war (dann müssen die Geräte von eQ3 resettet werden).

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

DominikG87

Also eine CCU habe ich vorher auch nicht wirklich verwendet.
Ich habe mal eine auf dem Raspberry installiert und einige Geräte angelernt.
Eigentlich nur um zu schauen, ob auch alles funktioniert.
Tja, hab die CCU dann gelöscht und Raspbian inkl. FHEM installiert ohne vorher die Geräte abzulernen, da ich es nicht besser wusste.


Beta-User

Kennst du die HmID, die die Pi-CCU hatte (sollte sich auch aus dem Funkverkehr erraten lassen)?
Dann solltest du (erst mal) die auch für FHEM verwenden.

Ob es da einen Default gibt, oder einfach die "Original-ID" des Funkmoduls (hast du doch?) verwendet wird: keine Ahnung. Im Zweifel würde ich die vom Modul mal testen. Wenn ja, sollte damit ein getConfig klappen und das jeweilige Gerät vollständig eingebunden werden (pairedTo sollte genau diese ID zeigen ohne set_).

Ansonsten: bitte erst mal den anderen Thread lesen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

DominikG87

Nein, ID's habe ich mir nicht notiert, kann aber mal im Funkverkehr nachschauen ob ich was rausfinden kann.
Im Log meldeten sich, so meine ich jedenfalls, einige unbekannte Geräte. Das werden wohl die aktiven Homematic Geräte sein.

Ich verwende das HM Funkmodul, jawohl.

Wäre es eine Alternative, wieder eine Pi-CCU zu erstellen? Oder ist die HmID dann eh wieder ein andere?

Beta-User

Versuch's erst mal - wie bereits geschrieben - mit der ID des Moduls. Das geht schnell, und vielleicht klappt's ja... (eQ-3 muß für jede Pi-CCU ja auch irgendwo eine HmID generieren, das wird kaum überall dieselbe sein).
Also entweder du hast eine eingegeben (dann müssen wir sniffen, das log "as is" hilft da nicht weiter, eher die RAW-Messages von einem CUL), oder sie kommt woanders her, aber tendenziell hilft eine Neuinstallation m.E. nur sehr vielleicht. Wenn nix anderes geht, wäre das aber auch einen Versuch wert (ablernen wenn möglich, dann neu anlernen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

martinp876

Ein kommando auslösen am rt. Der informiert die zentrale, schickt also eine Nachricht an dessen hmid.
Willst du fhem mit der id des verstorbenen ccu nutzen dann setze diese id i  den ios oder und der vccu
Willst du die rts umlernen setze im fhem ebenfalls die id. Dann setze das register pair auf die neue id. Wenn alle rts geändert sind noch die fhem id zurücksetzen.
Oder resette die rts. Das pairing sollte gelöscht werden. Neu pairen, alles gut.

DominikG87

So, nun habe ich mal Zeit das ganze zu testen...

Wie genau bekomme ich nun die ID raus?
Im Log des FHEM finde ich folgendes (noch keine Geräte angelernt):
2017-12-22 15:37:20 HMUARTLGW HmUART UNKNOWNCODE A0C96865A6185F800000088AA38::-72:HmUART
2017-12-22 15:37:20 HMUARTLGW HmUART UNKNOWNCODE A096FA03F6185F6584330::-62:HmUART
2017-12-22 15:37:24 HMUARTLGW HmUART UNKNOWNCODE A096EA03F618611584330::-68:HmUART
2017-12-22 15:37:27 HMUARTLGW HmUART UNKNOWNCODE A0EE884106186125843300B90B10D40::-22:HmUART
2017-12-22 15:37:28 HMUARTLGW HmUART UNKNOWNCODE A099FB4126186125F91C3::-23:HmUART
2017-12-22 15:37:28 HMUARTLGW HmUART UNKNOWNCODE A0AA0A4596186125F91C391::-23:HmUART
2017-12-22 15:37:28 HMUARTLGW HmUART UNKNOWNCODE A096FA03F618612584330::-24:HmUART
2017-12-22 15:37:35 HMUARTLGW HmUART UNKNOWNCODE A0CF584706185E100000000B138::-56:HmUART
2017-12-22 15:37:35 HMUARTLGW HmUART UNKNOWNCODE A0970A03F6185F6584330::-61:HmUART
2017-12-22 15:37:39 HMUARTLGW HmUART UNKNOWNCODE A096FA03F618611584330::-66:HmUART
2017.12.22 15:37:39 3 : HmUART: Unknown code A096FA03F618611584330::-66:HmUART, help me!2017-12-22 15:37:40 HMUARTLGW HmUART UNKNOWNCODE A0C9684706185F800000000AA38::-74:HmUART
2017.12.22 15:37:40 3 : HmUART: Unknown code A0C9684706185F800000000AA38::-74:HmUART, help me!2017-12-22 15:37:43 HMUARTLGW HmUART UNKNOWNCODE A0C0C865A6185F600000090BB34::-62:HmUART
2017.12.22 15:37:43 3 : HmUART: Unknown code A0C0C865A6185F600000090BB34::-62:HmUART, help me!2017-12-22 15:37:43 HMUARTLGW HmUART UNKNOWNCODE A0970A03F618612584330::-23:HmUART
2017.12.22 15:37:43 3 : HmUART: Unknown code A0970A03F618612584330::-23:HmUART, help me!2017-12-22 15:37:50 HMUARTLGW HmUART UNKNOWNCODE A0971A03F6185F6584330::-62:HmUART
2017.12.22 15:37:50 3 : HmUART: Unknown code A0971A03F6185F6584330::-62:HmUART, help me!


Bringt mich aber noch nicht wirklich weiter, oder?

Beta-User

Wäre noch gut, wenn man sehen könnte, welcher Tastendruck zu welchem log-Event gehört, aber so würde ich auf
Zitat03F618
tippen (die raw-Messages scheinen beim CUL etwas anders dargestellt zu werden, dort sind es die Stellen 10-15, was hier auch als "618611" interpretiert werden könnte).

Mehrerer der Geräte liegen ziemlich dicht am HMUART (erkennbar an den sehr großen RSSI-Werten), das kann zu Fehlern führen, eigentlich müßte nämlich überall dieser Teil drinstehen.

Eventuell kannst du autcreate auch die Devices anlegen lassen und dann sehen, welche RAW-Messages zugeordnet werden.

Und ein "list" vom IO wäre auch nicht schlecht, wenn es nicht klappt.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

DominikG87

#10
Ein Wandthermostat liegt quasi direkt neben dem Raspberry, jop. Ist eher zum testen, soll dort nicht liegen bleiben.

Also autocreate ist aktiviert, es wird aber kein Gerät erstellt.

Ein "list" vom IO...
Ich bin ja auch ein Freund von Abkürzungen bei Themen von denen ich Ahnung habe.
Das ist leider bisher weder bei FHEM noch Homematic der Fall. :-D
Was genau ist der IO? Ich steh auf dem Schlauch...

Edit: Ich tippe mal auf "Input/Output" Modul, quasi der Homematic Empfänger/Sender.

Hier die Ergebnisse vom list:

Internals:
   DEF        5F91C3
   HmUART_MSGCNT 2229
   HmUART_RAWMSG 0500002BB686105F91C30000000A90B20F2D40
   HmUART_RSSI -43
   HmUART_TIME 2017-12-22 17:12:23
   IODev      HmUART
   LASTInputDev HmUART
   MSGCNT     2229
   NAME       HM_5F91C3
   NOTIFYDEV  global
   NR         33
   NTFY_ORDER 50-HM_5F91C3
   STATE      CMDs_pending
   TYPE       CUL_HM
   lastMsg    No:B6 - t:10 s:5F91C3 d:000000 0A90B20F2D40
   protLastRcv 2017-12-22 17:12:23
   rssi_at_HmUART lst:-43 cnt:2229 max:-36 avg:-42.91 min:-75
   READINGS:
     2017-12-12 22:41:27   Activity        alive
     2017-12-22 15:37:28   CommandAccepted yes
     2017-12-12 22:41:22   D-firmware      1.4
     2017-12-12 22:41:22   D-serialNr      OEQ1699399
     2017-12-12 22:41:22   R-pairCentral   set_0xFA3B12
     2017-12-12 22:42:47   actuator        15
     2017-12-12 22:42:47   batteryLevel    3
     2017-12-12 22:42:47   desired-temp    17.0
     2017-12-12 22:42:47   measured-temp   18.8
     2017-12-12 22:42:47   motorErr        communicationERR
     2017-12-12 22:42:49   state           CMDs_pending
   helper:
     HM_CMDNR   182
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5F91C3,00,00,00
       nextSend   1513959143.16427
       prefIO     
       rxt        0
       vccu       
       p:
         5F91C3
         00
         00
         00
     mRssi:
       mNo        B6
       io:
         HmUART     -41
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_HmUART:
         avg        -42.9111709286674
         cnt        2229
         lst        -43
         max        -36
         min        -75
Attributes:
   IODev      HmUART
   autoReadReg 4_reqStatus
   expert     2_raw
   room       CUL_HM

Beta-User

Sorry für die Abkürzung, aber richtig geraten ;) . Nur leider paßt das list nicht zu einem IO ;) ...

Was ich nicht verstehe ist die Aussage, es würde nichts via autocreate erstellt - das gepostete list gehört nämlich zu einem RT ??? .

Bevor du weitermachst, sollten die cmds-pending Hinweise weg sein, ich würde das hier radikal machen und clear all verwenden. Dann mal den Wiki-Artikel zu pairing bei Homematic in Ruhe lesen und den bereits verlinkten Thread. 
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

DominikG87

Dann nochmal (vielleicht) das richtige Device:
Internals:
   AssignedPeerCnt 2
   CNT        11
   DEF        /dev/ttyS0
   DEVCNT     32
   DevState   99
   DevType    UART
   DeviceName /dev/ttyS0@115200
   FD         11
   LastOpen   1513618033.11665
   NAME       HmUART
   NR         24
   PARTIAL   
   RAWMSG     050000320CA03F618612584330
   RSSI       -50
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      HM-MOD-UART
   msgLoadCurrent 0
   msgLoadHistory 0/0/0/0/0/0/0/0/0/0/0/0
   msgLoadHistoryAbs 0/0/0/0/0/0/0/0/0/0/0/0/0
   owner      FA3B12
   Helper:
     CreditTimer 26863
     FW         66561
     Initialized 1
     SendCnt    1
     AckPending:
     LastSendLen:
       3
       3
     Log:
       IDs:
     PeerQueue:
     PendingCMD:
     RoundTrip:
       Delay      0.00247716903686523
     loadLvl:
       lastHistory 1514020941.38024
   Peers:
     5F91C3     +5F91C3,00,00,00
     618612     +618612,00,00,00
   READINGS:
     2017-12-18 18:27:21   D-HMIdAssigned  FA3B12
     2017-12-18 18:27:21   D-HMIdOriginal  584330
     2017-12-18 18:27:21   D-firmware      1.4.1
     2017-12-18 18:27:21   D-serialNr      OEQ0306627
     2017-12-18 18:27:13   D-type          HM-MOD-UART
     2017-12-18 18:27:21   cond            ok
     2017-12-23 06:57:46   load            0
     2017-12-18 18:27:21   loadLvl         low
     2017-12-18 18:27:13   state           opened
   helper:
Attributes:
   hmId       FA3B12


Den RT (Wandthermostat) habe ich "versucht" anzulernen und habe dabei die Meldung F4 (also wohl ein Anlernfehler) bekommen. Das war der Grund für den Thread hier.
Ich dachte zwar, dass ich das Ding wieder rausgelöscht habe, aber offenbar nicht korrekt.



Beta-User

Hmm, also noch mal der Reihe nach:

Das list aus dem Post von gestern nachmittag stammt nicht von einem Wandthermostat, sondern von einem RT-DN (Heizkörperthermostat) - jedenfalls wenn ich unterstelle, dass es dieselben Geräte sind wie meine. Das Reading actuator gibt es jedenfalls bei einem WT nicht ::) .

Die F4 sagt: an anderer Zentrale angelernt (so steht es jedenfalls in dem anderen Thread).

Vorschlag: Du konzentrierst dich jetzt erst mal auf ein Gerät - am besten das mit F4 - und versuchst über das Auslösen von Messages die ID rauszufinden, die du dem IO zuweisen mußt. Dazu mußt du die raw Messages auswerten, bei den HMUARTs scheint das in den Stellen 21-26 drin zu sein. Allerdings: sind die Geräte mit anderen gepeert, gehen auch messages an die gepeerten Geräte, diese messages helfen dann natürlich nicht weiter, sondern nur das, was an die Zentrale geht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

frank

beim auslösen der anlernmessage (countdown) müsste eigentlich eine gepairte zentrale zu sehen sein.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html