gelöst: Hilfe - immer noch "UNKNOWN CODE" in 10_CUL_HM.pm (Version 6223)

Begonnen von mmattern, 18 Juli 2014, 12:05:01

Vorheriges Thema - Nächstes Thema

mmattern

Hallo zusammen,

ich habe immer noch eine Menge "UNKNOWN CODE"-Einträge im Log mit der aktuellen FHEM-Version...
Geschrieben werden die Einträge letztlich aus fhem.pl heraus, ich habe es aber eingegrenzt auf 10_CUL_HM.pm - die CUL_HM_Parse-Funktion kommt offenbar nicht klar mit Messages, die vom HMLAN aus geschickt werden.

Zunächst zur besseren Zuordnung meine aktuelle Version:
$Id: 10_CUL_HM.pm 6223 2014-07-09 06:38:11Z martinp876

Mit ein paar zusätzlichen Log-Einträgen habe ich eingegrenzt, wo CUL_HM_Parse zurückspringt und dadurch die "found"-Variable in der Dispatch-Funktion innerhalb fhem.pl leer bleibt.
Es passiert in diesem Abschnitt von CUL_HM_Parse:
if(!$shash){    # Unknown source
    return "" if ($msg =~ m/998112......000001/);# HMLAN internal message, consum
   
    my $ccu =InternalVal($ioName,"owner_CCU","");
    CUL_HM_DumpProtocol("RCV",$iohash,$len,$mNo,$mFlg,$mTp,$src,$dst,$p);
    if ($defs{$ccu}){#
      push @evtEt,[$defs{$ccu},0,"unknown_$src:received"];# do not trigger
      return CUL_HM_pushEvnts();
    }
    return;
   
  }


$shash ist undefiniert - @martin: wäre es nicht eigentlich die Erwartung, dass für ein funktionierendes HMLAN ein Hash existiert, das über die Device-ID dann auch per my $shash = CUL_HM_id2Hash($src); gefunden werden sollte, wie es weiter oben in CUL_HM_Parse versucht wird?

Ich habe insgesamt zwei HM-CFG-LAN (bei mir "HMLAN1", "HMLAN2") und einen HM-CFG-USB ("HMUSB").
Ich habe mir auch den per my $ioName = $iohash->{NAME} ermittelten ioName ausgeben lassen - das Verhalten tritt sowohl auf, wenn CUL_HM_Parse mit ioName "HMLAN1" eine von HMLAN1 versandte Message prüft wie auch wenn es um welche geht, die von HMLAN2 bzw. HMUSB verschickt werden...

Ich hoffe, meine Beschreibung hilft bei der Aufklärung... meine Hauptvermutung ist, dass der "hash" für HMLAN1/-2/-USB nicht korrekt abgelegt und daher nicht mehr gefunden werden kann...

Viele Grüße
Michael
2x Raspberry Pi, 2x HM-CFG-LAN, 2x HM-CFG-USB, 2x HM-ES-PMSw1-Pl, 3x HM-LC-BL1-FM, 10x HM-LC-Bl1PBU-FM, 6x HM-LC-Sw1PBU-FM-CustomFW, 2x HM-PB-2-WM55-2, 4x HM-PB-6-WM55, 2x HM-SEC-MDIR-2, 6x HM-SEC-RHS, 2x HM-SEC-WIN, 2x HM-Sys-sRP-Pl

martinp876

Zitat$shash ist undefiniert - @martin: wäre es nicht eigentlich die Erwartung, dass für ein funktionierendes HMLAN ein Hash existiert,
eigentlich nein.
Alle HM devices werden in CUL_HM definiert. Dass einst eingeführt wurde, HMIds an IOs festzumachen ist historisch - kommentiere ich nicht. Man kann jetzt einen vccu in CUL_HM definieren - dann hat man alles sauber. Die Unsauberheit in der "alten" kodierung abzufangen ist m.E. nicht sinnvoll.
Man müsste alle IOs durchsuchen, ob nicht eines diese ID gesetzt hat.

definiere dir eine vccu je HMIds die du in IOs nutzt - dann ist alles dort, wo es hin gehört.


mmattern

Hallo Martin,

ok, vielen Dank für den Tipp... ich habe jetzt mal folgendes in fhem.cfg eingetragen:
define ccu_1 CUL_HM 26EC1A
attr ccu_1 IODev HMLAN1
attr ccu_1 model CCU-FHEM


26EC1A ist dabei die HMID meines HMLAN, für den anderen HM-CFG-LAN sowie den HM-CFG-USB habe ich es analog eingetragen.

Hattest du das so gemeint?

Auf jeden Fall kommen jetzt keine "UNKNOWN CODE"-Meldungen mehr ;-)

Viele Grüße
Michael
2x Raspberry Pi, 2x HM-CFG-LAN, 2x HM-CFG-USB, 2x HM-ES-PMSw1-Pl, 3x HM-LC-BL1-FM, 10x HM-LC-Bl1PBU-FM, 6x HM-LC-Sw1PBU-FM-CustomFW, 2x HM-PB-2-WM55-2, 4x HM-PB-6-WM55, 2x HM-SEC-MDIR-2, 6x HM-SEC-RHS, 2x HM-SEC-WIN, 2x HM-Sys-sRP-Pl

martinp876

ja.
ich muss noch eine Beschreibung der vccu machen.
Du kannst
attr ccu_1 IOList HMLAN1
machen - dann ergreift die vccu besitz vom HMLAN1. Es kontrolliert die HMId... man kann dann mehrere IOs eintragen...