[gelöst] Problem mit 10_CUL_HM

[m.a.d]

Servus

Habe in letzer Zeit einige Probleme mit meinen Homematic Devices in fhem.
Verwendet werden 2 HM-LGW und HMUARTLGW mit einer VCCU.

Begonnen hat es als ich einen 6-fach Taster zu einem VCCU Btn peeren wolte um bei Tastendruck grüne LED zu bekommen :

Mit der Version 10_CUL_HM.pm 21055 2020-01-26 09:02:21 bekam ich

set remote.01 peerChan 0 VCCU_Btn1 single set
peerChan requires parameter: -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
set remote.01 peerChan 0 VCCU_Btn1 single unset
peerChan requires parameter: -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]

Nach einem Update auf 10_CUL_HM.pm 22700 2020-08-30 18:00:33 funktionierte zwar das peering aber schon beim Restart fiel mir auf das CUL_HM keine statusRequest am Ende des Restarts sendet :
2020.09.16 13:43:43 2: AttrTemplates: got 175 entries
2020.09.16 13:43:43 1: PERL WARNING: Use of uninitialized value $chType in concatenation (.) or string at FHEM/lib/HM485/Device.pm line 250.

Nach dem manujellen Restore von 10_CUL_HM aus dem Backup waren sie wieder da, leider auch meine Probleme mit peering
2020.09.16 13:51:15 2: AttrTemplates: got 175 entries
2020.09.16 13:51:16 3: CUL_HM set kueche.licht statusRequest

Also zurück zur Version 10_CUL_HM.pm 22700 2020-08-30 18:00:33

Neben den Problemen mit dem statusRequest zeigt diese Version bei mir auch ein echt seltsames Verhalten während Pairing oder getConfig.
Es werden dabei wahllos Kommandos an die HM Deives gesendet wobei meine Eingangstür und die Garagentore aufgingen.
Aus dem Debug Log (verbose 5) während hmPaitForSec oder set HM_Device  getConfig
2020.09.16 14:28:53 5: Cmd: >set HM_Device on-for-timer 1<
2020.09.16 14:28:53 5: Cmd: >set HM_Device on<

Nach dem heutigen Update auf Version 10_CUL_HM.pm 22785 2020-09-18 15:36:28Z hat sich an dem Verhalten bei pairing bzw getConfig nichts verändert, nur beim Status Request während des Starts kommt jetzt

2020.09.19 12:23:30 2: AttrTemplates: got 183 entries
2020.09.19 12:23:33 3: CUL_HM set deckenfluter.licht statusRequest noArg

In der Zwischenzeit habe ich fhem komplett mit neuen Linux und fhem Installation neu installiert und nur die fhem.cfg übernommen, keine Änderung des Verhaltens.

ConfigCheck ist auch unauffällig, die HM-LGW habe ich auch schon einzeln deaktiviert keine Änderung.
Ob man Pairing von der VCCU aus oder dem HM-LGW durchführt ist eben falls egal.

Leider habe ich keine weiter Idee dazu.

mit der Bitte um Hilfe
Alfred

[frank]

1. nur 10_cul_hm.pm zu tauschen, kann nicht funktionieren.
mache also zunächst ein fhem update.
2. dann berichte, was aktuell nicht funktioniert.
3. poste je ein aktuelles list vom device, vccu und beiden ios.

[m.a.d]

Hello
Danke für die schnelle Antwort:

zu 1.) Gerade das ist das einzige das einwandfrei (bis aufs peering) funktioniert.
zu 2.) Habe noch mal ein  update gemacht :
a.) setzt man die VCCU auf hmPaitForSec und drückt auf einen neuen HM-Device kurz auf den Anlernknopf werden diverse Aktoren geschaltet.
b.) setzt man ein HM Device auf getConfig drückt kurz den Anlernknopf eines gepairten devices werden diverse Aktoren geschaltet.
c.) Verwendet man die CUL_HM Version 21055 2020-01-26 geschieht nicht von alledem und alle Funktionen (ausgenommen set peerChan) funktionieren. Läuft so schon ein paar Tage ohne Problem.
zu 3.) Im Anhang

Danke & lg
Alfred

[frank]

das einzige problem ist also ein "ungewolltes" schalten einiger aktoren.

das liegt sicherlich am reading cfgState, das anfang sommer in jeder entity neu dazugekommen ist.
deine notify,doif,... , die die aktoren auslösen, sind also schlecht "konfiguriert" und reagieren auf die events des readings cfgState.

dazu gibt es bereits einige threads.

[m.a.d]

Herzlichen Dank frank

Gibt es vieleicht nähere Informationen zu dem neuen reading ?
Ich muß echt sagen so auf dem Schlauch bin ich in meinen 7 Jahren mit fhem noch nie gestanden. Ich habe keine Ahnung wo ich anfassen soll, ich habe einige Beiträge gefunden die mit Wildcard in notify,doif arbeiten und damit Probleme hatten aber ich habe keine Wildcards (grep auf fhem.cfg/Doif nach * zeigt keine Ergebnisse) in meinen doif, notify habe ich keine mehr habe ich alle auf doif migriert.

Vieleicht kann mir jemand helfen was so in einem doif noch "schlecht konfiguriert" wäre, ein kleiner Schubs wäre hier echt gut (Habe über 50 DOIF)?
Was bedeutet "cfgState updating" eigentlich ?

Sorry da sich mich hier so blöd anstellen aber ich kann mir unter dem cfgState auch nichts vorstellen.

EDIT : Habe einige DOIF die solche Abfragen "=~/" haben z.B.:

Code Auswählen Erweitern

([tor.kontakt:contact] =~/closed/) (setstate tor.status Zumachen)
Könnte das der Auslöser sein?

Danke & lg
Alfred

[frank]

ich bin eigentlich kein doif freak.

dein beispiel matcht vermutlich auf das reading contact in einem device => also eher nicht.

such mal nach code, der auf kein explizites reading matcht, sondern auf den STATE eines devices oder channels.

da du den 6-fach schalter erwähnt hast, der durch getconfig auslöst, würde ich den mal untersuchen, auch die channels.
auf der jeweiligen detailseite gibt es dann eventuell ganz unten unter "Probably associated with" das "faule" doif.

[m.a.d]

Hallo

Erstmal herzlichen Dank frank für deine Geduld mit mir, dachte immer ich kenne mich in fhem halbwegs gut aus, leider muß ich jetzt feststellen das mich diese Sache aber ein wenig überfordert.

Eines der Devices die immer im Fehlerfall angesprochen werden ist die Haustür (eingang.tuer.schalter).

Ich habe nun das dementsprechende DOIF und die dazugehörenden Devices rausgesucht :

Code Auswählen Erweitern

DOIF ([eingang.tuer.oeffner] eq "Aufmachen") (set eingang.tuer.schalter on-for-timer 1)
DOELSEIF ([eingang.kontakt] eq "geschlossen" and [eingang.tuer.oeffner] eq "Aufmachen") (set eingang.tuer.oeffner off)

eingang.tuer.oeffner (dummy)
eventMap on:Aufmachen off:off
webCmd Aufmachen

eingang.tuer.schalter (HMW_IO_12_Sw14_DR_KEQ0048320)
subType digital_analog_output
webCmd  statusRequest

eingang.kontakt (HM-SEC-SC)
cfgState updating

IODev HMLAN04
IOgrp VCCU
actCycle 099:00
actStatus alive
eventMap closed:geschlossen / open:offen
model HM-SEC-SC
peerIDs 00000000
subType threeStateSensor


Mit dem Sensor eingang.kontakt ist noch einen weiteres DOIF verbunden :

Code Auswählen Erweitern

DIOF ([tageslicht] ne "on" and [eingang.kontakt] ne "geschlossen" and [tuer.rolladen] ne "Ab") (set eingang.strasse.licht on-for-timer 60)

tageslicht (dummy)

tuer.rolladen (HM-LC-BL1-FM)
cfgState ok

IODev HMLAN02
IOgrp VCCU
autoReadReg  4_reqStatus
eventMap  on:Auf off:Ab stop:Stop
model  HM-LC-BL1-FM
peerIDs 00000000
subType blindActuator
webCmd Auf:Ab:Stop

eingang.strasse.licht (HM-LC-SW4-DR)
cfgState ok

eventMap on:Einschalten / off:Ausschalten
model  HM-LC-SW4-DR
peerIDs 00000000
webCmd Einschalten:Ausschalten



Ausser des der cfgState beim  HM-SEC-SC auf updating verbleibt sehe ich leider keine falschen Einträge.

Vielleicht jemand von euch ?

Danke & lg
Alfred

[amenomade]

Code Auswählen Erweitern

[tuer.rolladen] ne "Ab" könnte die Ursache sein, da es auf jedem Event von tuer.rolladen triggert, und nutzt dazu eine negierte Bedingung.

[frank]

ebenso beim sec-sc-2:

Code Auswählen Erweitern

[eingang.kontakt] ne "geschlossen"

zum testen kannst du ja mal ein event erzeugen:

Code Auswählen Erweitern

trigger eingang.kontakt cfgState: ok

wenn ich mich nicht irre, geht dann eingang.strasse.licht für 60 sek  an.

[m.a.d]

Super
Danke amenomade und frank

Das mit dem Trigger werde ich morgen gleich probieren.

Wäre das dann so zu lösen ?

Code Auswählen Erweitern


[tuer.rolladen:state] ne "off"   
bzw
[eingang.kontakt:state] ne "closed"


Danke & lg
Alfred

[amenomade]

Lieber "eq etwas" als "ne etwas". Das Problem von "ne", ist dass es auch auf "error" oder "set_on", oder was auchimmer reagiert.

[frank]

ich würde auch immer ein "richtiges" reading nehmen.
beim sc zb das reading contact.

[m.a.d]

Danke euch vielmals, ich denke jetzt habe ichs kapiert.

Berichte wenn hoffentlich alles wieder läuft.

Danke & lg
Alfred

[m.a.d]

Konnte das Problem nun durch eure Hilfe lösen.

Vorgangsweise :
Habe alle relevanten DOIF's für die Haustür deaktiviert  -> Fehler weg
Habe dann ein DOIF nach dem anderen wieder aktiviert bis Fehler wiederkam.

Und hier nun die Lösung die half:
Bei allen Taster erfolgte die Abfrage folgendermasen :

Code Auswählen Erweitern

([vorraum.taster.1] =~/Short/)

Dies löste den Aktor aus, nun geändert auf :

Code Auswählen Erweitern

([vorraum.taster.1:state] =~ "Short")

Damit funktioniert alles wieder. Ein "eq" ist bei den Homematic Tastern im state Reading nicht möglich da hier mehr drinnen steht als Short/Long.
Werde aber noch die anderen DOIF's nach euren Rat mit direkten Readings und nur "eq" umschreiben um auf der sicheren Seite zu sein.

Nochmal herzlichen Dank an frank und amenomade für eure Hilfe.

Alfred