Homematic Geräte machen Ärger

[kptkip]

Aloa,

ich habe einige Probleme mit meinen HM-Produkten auf einer FHEM-Instanz.
2 Fhem instanzen laufen auf 2 Raspi 3 - einer als Haupt- und einer als Slave per Fhem2Fhem

• die Garageninstanz läuft mit einem USB-CUL (ver.1.67) und einem optischen Homematik Fenster-Sensor
• die Hauptinstanz läuft mit einem Neumann-CUL (a-culfw ver.1.26.05) und 4 optischen HM Fenster-Sensoren, einem HM Rauchmelder und bisher mit einem HM Heizungsthermostat

Beim Garagen-fhem habe ich nur den Sensor einmal mit pairforSec initial gepaired ohne jede weitere Tätigkeit (kein getDeviceInfo o.Ä. oder HmInfo) - läuft seit nem Jahr ohne Murren und Ausfälle.

Bei der Hauptinstanz habe ich jede Menge Probleme mit sich abmeldenden Fensterkontakten (vor allem zusammen als Sensor in ALARM), beim Rauchmelder brauchte ich auch ne Ewigkeit, bis er lief - geht jetzt (bet!) hab nun ein Heizungsventil und ebenfalls wieder beim Anlernen die Orgie von PairforSec, GetDeviceINfo, CMD_Pendigs en masse und MISSING_ACK. Seit heute morgen geht er (nochmal drüber gepaired), allerdings ohne, dass ich ihm neue Temperaturwerte senden kann. Danach habe ich ihm den burstAccess=1_auto spendiert, nun nimmt er die Werte. Das soll aber laut FOrumseintrag keine schlaue Idee sein.

Bottom-line: bei meiner Hauptinstanz habe ich beim Anlernen der HM-Geräte allesammt immer eine Orgie von Workarounds und Rumgefummel, bis das Zeug läuft - auf dem Garagen-FHEM hats einfach - ganz naiv - super funktioniert und ich frage mich, ob die Anlernorgie bei HM einfach normal (wäre ja sehr ärgerlich) ist, oder ob der Neumann-Cul mit der FW diesbezüglich Murks macht. Habe in einigen Threads im Forum gelesen, dass das Thema Timing bei HM ein schwieriges Feld ist liegt es evtl daran?

Habe schon über die Anschaffung einer HM-LAN-Bridge nachgedacht, weiß aber nicht, ob das sinnvoll ist.

   
CUL-Device auf dem GaragenFHEM:

Code Auswählen Erweitern

defmod CUL_NUC CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@38400 0000
attr CUL_NUC alias CUL Garagen_PI
attr CUL_NUC hmId 74826a
attr CUL_NUC icon cul_868
attr CUL_NUC rfmode HomeMatic
attr CUL_NUC room Homematik

setstate CUL_NUC 2019-06-04 15:17:10 cmds A B b C e F G h i K k L l M m N R T t U u V W X x Y Z
setstate CUL_NUC 2019-09-16 14:54:35 state Initialized


CUL-Device auf dem Haupt-FHEM:

Code Auswählen Erweitern

defmod CULHat4 STACKABLE_CC CULHat3
attr CULHat4 DbLogExclude .*
attr CULHat4 alias HomematicCUL EG
attr CULHat4 group Infrastruktur
attr CULHat4 hmId 74826A
attr CULHat4 icon cul_868
attr CULHat4 rfmode HomeMatic
attr CULHat4 room Homematic,07_Serverschrank

setstate CULHat4 2019-09-15 22:48:38 cmds C A Z N E L Y V X f z
setstate CULHat4 2019-09-16 16:09:18 state Initialized

hier das VCCU-Device:

Code Auswählen Erweitern

defmod VCCU CUL_HM 74826A
attr VCCU .mId FFF0
attr VCCU DbLogExclude .*
attr VCCU IODev CULHat4
attr VCCU IOList CULHat4
attr VCCU IOgrp VCCU
attr VCCU alias Virtuelle VCCU Homematic
attr VCCU expert 2_raw
attr VCCU group Infrastruktur
attr VCCU hmKey 01:e10adc3949ba59abbe56e057f20f883e
attr VCCU icon cul_868
attr VCCU model CCU-FHEM
attr VCCU room Homematic
attr VCCU subType virtual
attr VCCU webCmd update

setstate VCCU CULHat4:ok
setstate VCCU 2019-09-16 07:04:23 IOopen 1
setstate VCCU 2019-09-16 07:04:23 state CULHat4:ok
setstate VCCU 2019-08-06 15:15:50 unknown_1C203E received
setstate VCCU 2019-09-16 15:28:34 unknown_216114 received
setstate VCCU 2019-09-10 18:22:38 unknown_296CAA received
setstate VCCU 2019-08-06 16:23:33 unknown_2FEA56 received
setstate VCCU 2019-08-06 15:49:04 unknown_38875A received
setstate VCCU 2019-08-04 12:23:43 unknown_3CDD6B received
setstate VCCU 2019-07-17 10:34:07 unknown_3FDBE2 received
setstate VCCU 2019-09-14 23:23:47 unknown_4179DD received
setstate VCCU 2019-06-18 15:05:50 unknown_589B3A received
setstate VCCU 2019-06-14 19:17:55 unknown_5ECC53 received
setstate VCCU 2019-09-16 12:17:30 unknown_6533D1 received
setstate VCCU 2019-07-28 22:26:31 unknown_663E9A received
setstate VCCU 2019-07-28 22:25:34 unknown_664214 received

Beispielhaftes Gerät(Heizungsthermostat):

Code Auswählen Erweitern

defmod HM_4179DD CUL_HM 4179DD
attr HM_4179DD .mId 0095
attr HM_4179DD DbLogExclude .*
attr HM_4179DD IODev CULHat4
attr HM_4179DD IOgrp VCCU:CULHat4
attr HM_4179DD actCycle 000:10
attr HM_4179DD actStatus alive
attr HM_4179DD autoReadReg 4_reqStatus
attr HM_4179DD burstAccess 1_auto
attr HM_4179DD expert 2_raw
attr HM_4179DD firmware 1.4
attr HM_4179DD model HM-CC-RT-DN
attr HM_4179DD room Homematic
attr HM_4179DD serialNr MEQ1553647
attr HM_4179DD subType thermostat
attr HM_4179DD webCmd getConfig:clear msgEvents:burstXmit

setstate HM_4179DD CMDs_done
setstate HM_4179DD 2019-09-16 06:34:33 .D-devInfo 00FFFF
setstate HM_4179DD 2019-09-16 06:34:33 .D-stc 59
setstate HM_4179DD 2019-09-16 16:11:27 .protLastRcv 2019-09-16 16:11:27
setstate HM_4179DD 2019-09-16 09:36:33 Activity alive
setstate HM_4179DD 2019-09-16 10:30:41 CommandAccepted yes
setstate HM_4179DD 2019-09-16 06:34:33 D-firmware 1.4
setstate HM_4179DD 2019-09-16 06:34:33 D-serialNr MEQ1553647
setstate HM_4179DD 2019-09-15 23:34:40 R-backOnTime 10 s
setstate HM_4179DD 2019-09-15 23:34:40 R-burstRx on
setstate HM_4179DD 2019-09-15 23:34:40 R-cyclicInfoMsg on
setstate HM_4179DD 2019-09-15 23:34:40 R-cyclicInfoMsgDis 0
setstate HM_4179DD 2019-09-15 23:34:40 R-pairCentral 0x74826A
setstate HM_4179DD 2019-09-16 16:11:27 actuator 0
setstate HM_4179DD 2019-09-16 16:11:27 battery ok


Ich hoffe, ich konnte den Sachverhalt einigermaßen klar beschreiben.

Links:
Neumann-CUL: 3x868MHz 1x433MHz als PI-Hat
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=2ahUKEwiZ-IeustXkAhVBCewKHTomBe4QFjACegQIARAB&url=https%3A%2F%2Foskar.pw%2FmapleHat&usg=AOvVaw3DTx6yDzmA69tIoQipcHyX

[gloob]

Ich sag ja noch es liegt daran, dass beide die gleich HMID haben.

[kptkip]

hm, räusper..

Bei dem vielen RAW-Data Kopieren ist mir das Detail garnicht aufgefallen.

Was ist Deine Empfehlung: Physikalisches Device mit ner neuen HMID versorgen oder dort löschen und dann dann in der VCCU eine neue vergeben.?

Muss ich dann die Geräte neu anlernen - danke ja, oder?

Gruß KptKip

[gloob]

Jede FHEM Instanz sollte eine eigene VCCU mit eindeutiger HMID haben und dort werden die IO Devices hinzugefügt. Um die Weiterleitung der HMID an die IO Devices kümmert sich dann die VCCU.
Da du bereits eine VCCU hast mit HMID würde ich die FHEM Instanz so lassen.

Die 2. FHEM Instanz (Garageninstanz) würde ich auch mit einer VCCU "ausrüsten" und dort eine neue HMID vergeben. Da du dort nur einen Fensterkontakt hast, würde ich den ablernen und nach dem umstellen der HMID neu anlernen.

[kptkip]

Danke für den Hinweis und die Ausführung.

Das Vorgehen scheint mir auch das mit dem geringsten Aufwand zu sein.

Eine Frage hättw ich aber noch:
Bei der Haupt-FHEM-instanz hat nicht VCCU die HMID sondern das physikalische CUL-Device.
Ist das ein Problem? Sollte man das auch drehen und wenn ja, geht das auch ohne das Neu-Pairen der HM-Devices?

Gruß
Kptkip

[gloob]

Danke für den Hinweis und die Ausführung.

Das Vorgehen scheint mir auch das mit dem geringsten Aufwand zu sein.

Eine Frage hättw ich aber noch:
Bei der Haupt-FHEM-instanz hat nicht VCCU die HMID sondern das physikalische CUL-Device.
Ist das ein Problem? Sollte man das auch drehen und wenn ja, geht das auch ohne das Neu-Pairen der HM-Devices?

Gruß
Kptkip

Wenn du in der VCCU einfach die selbe HMID setzt wie im CUL Device brauchst du nix anpassen. Wenn ich es richtig gesehen habe, hast du es ja bisher auch so schon gemacht, dann passt es ja.