10_CUL_HM müllt mir das Logfile zu

[betateilchen]

permanent auftretender Hinweis in meinem Logfile seit neuestem (gestern):

Code Auswählen Erweitern


Use of uninitialized value in regexp compilation at ./FHEM/10_CUL_HM.pm line 871.
Use of uninitialized value in regexp compilation at ./FHEM/10_CUL_HM.pm line 871.


[martinp876]

sollte mit 6054 erledigt sein.
Bekommst du viele messages von unbekannten Devices?

[betateilchen]

was sind denn unbekannte devices nach Deinem Verständnis?

Edit:

Ich habe gerade das Logfile genauer angeschaut. Aufgrund der Einträge mit Timestamps kann ich sagen, dass im Zeitraum zwischen zwei echten Logeinträgen diese Warnmeldung (die ja keine Timestamps hat) ungefähr alle zwei Minuten aufgetreten sein muss.

Mit der aktuell bereitgestellten Version treten die Meldungen nicht mehr auf.

Kann ich an der Stelle, die die Meldung geworfen hat, ein sinnvolles Debug einbauen, um dahinterzukommen, was die Meldung verursacht?

[martinp876]

Der Fehler ist aufgetreten, wenn ein nicht bekanntes device eine message gesendet hat und ich dessen Namen genutzt habe - geht natürlich nicht.

Unbekannt bedeuted, dass die SRC-Id keiner Entity zugeordnet werden konnte. Könnte sein, dass es deine CUL war, die mit der ID des HMLAN sendet.
Ich werden einmal testen -
a) die messages als unknown zurückzugeben
b) das ganze mit der vccu abfangen - wenn es von einem eigenen IO gekommen ist

[martinp876]

Das Problem tritt bei mehreren IOs auf (oder externen/parallelen CCUs)

Die saubere Lösung wäre messages deren ID man nicht kennt abzuweisen. Hat man mehrere IOs wird zu UNKNOWNCODE führen.
Abhilfe wäre, eine vccu zu definieren.
das ganze an den HMIds der IOs festzumachen ist nicht clever - da müsste man ständig suchen - die sind nicht unter der Kontrolle von CUL_HM.

Einen Alarm (Reading-event) für CUL_HM kann ich nicht werfen, da es diese Instanz nur implizit gibt (leider)

Passt das so auch für dich? Eine vccu müsstest du dann einrichten - eigentich jeder mit mehr als einem IO. Sollte nicht wirklich weh tun, hoffe ich.

[betateilchen]

Die saubere Lösung wäre messages deren ID man nicht kennt abzuweisen.

Das mit den "ID die man nicht kennt" hab ich noch nicht verstanden.

Bei mir gibt es zwei HMUSB die beide mit der gleichen ID laufen - fhem müsste die also eigentlich kennen? Auch meine CCU2 die hier noch völlig unabhängig von fhem in Betrieb ist, benutzt die gleiche ID.

[martinp876]

kennen - schon. aber eigentlich nicht in CUL_HM. Das ist eigentlich ein design-Loch.

(fast) Alle HMIds sind in CUL_HM mit der Definition ein-eindeutig vergeben. Alle? nein da ist eine kleine Gruppe von IDs die den IO devices zugeordnet werden. Diese und deren Änderungen werden in den IOs verwaltet - leider.
Ja, technisch kann man diese suchen gehen.

Besser ist, alle HMIds in CUL_HM zu verwalten. Das macht technisch einiges einfacher. Das ist ein Grund für die virtuelle CCU. Baut man diese ein wird deren ID auch in CUL_HM verwaltet - mit schnellen Zugriff und ohne wirkliche Suche. Es löst einege weitere Problem wie die Suche nach dem Namen des IO - wenn doch 2 IOs unterschiedliche Namen aber die selbe ID nutzen. Der "Name der ID" ist dann der Namen der CCU. Der Name des IO wird dann noch verwendet, wenn man das IO meint  - nicht die ID.

Um dahin upzugraden muss man eine CCU definieren und die Liste der IOs eingeben (oder update machen... um aufzuräumen).  Damit ist das Namen vergeben schon einmal erledigt.

Eigentlich sollten die vccu automatisch angelegt werden, wenn sie nicht existiert und ein HM-device ein IO mit einer entsprechenden ID nutzt....

Einziges Problem konnte für tests sein, dass man die HMId des IO nur ändern kann, wenn sie keiner vccu zugeordnet ist. Man muss also erst das IO von der vccu entfernen und dann kann man ändern... ein Problem bei voller automatik.

[betateilchen]

Deine vccu ist mir genauso suspekt wie HMinfo 

[martinp876]

lass es sein - war alles nur ein Versuch, deine Interfaces zu stören. Ist alles teufelswerk ... uuuhhh

"ist mit suspekt" beendet jeden sinnvollen Austausch und klärt rein garnichts - noch nicht einmal eine Antwort. Dann "haben wir fertig" - und ich werde selbst überlegen, wie ich mit diesen Messages umgehe.

[betateilchen]

nun sei doch nicht schon wieder beleidigt.

"suspekt" bedeutet einfach nur, dass ich immer noch nicht verstanden habe, wie das ganze funktionieren soll. Das war in keinster Weise negativ gemeint - ich verstehe einfach tatsächlich nicht, welche Funktion eine vccu da spielen würde.

[martinp876]

schon klar, was suspekt bedeutet, habe ich genau verstanden.

HMInfo ist ein support Modul. Es sammelt einige Daten, erlaubt Übersicht über alle Protokoll -ereignisse usw. Auch ein paar Einstellungen mittels template sind machbar. Du hast sicher eigene Auswertungen und Funktionen am Laufen - die scheinen dir gute Dienste zu leisten.
Das hat nicht Jeder, und nicht Jeder möchte es neu erfinden. Mit HMInfo bekommt er eine Sammlung von Funktionen aus dem System -was den Vorteil hat, dass sie getestet sind und gewartet werden.

Was dir an der vccu nicht klar ist, ist mir nicht klar. Ich habe es erklärt - und kann, wenn es noch Fragen gibt diese gerne beantworten. Fakt ist, dass das Handling der HMId in den IOs eine Krücke ist. Da gehört es nicht hin, sowohl aus System, SW und auch User sicht. Auch eQ3 kam nicht auf die Idee, eine ID am IO zu verankern. In FHEM  wurde es gemacht, weil es erst einmal schneller hin zu basteln war. Fakt ist, dass die vccu Pflicht sein müsste - eQ3 hat nie etwas anderes gebaut, aus guten Grund. Das ich mich so lange ohne abkämpfe war ein Fehler.

Neben dem Handling der HMIds passiert nach dem Einrichten einer vccu erst einmal gar nichts, außer dass sich die SW leichter tut. Optional kann man (bisher)
- peers mit der vccu erstellen (das peeren mit einem IO device war eine Krücke, nicht wasserdicht und nicht prüfbar für den User)
- IO Ersatzschaltungen vornehmen und Zustand sowie HMId der IOs verwalten (wenn sie einer vccu zugeordnet werden)

Falls du
- Fragen hast, frage
- sowieso kein Interesse hast, lass es
- es dir zu gefährlich ist - hm, verstehe ich nicht, was gefährlich sein sollte. Klären wir es
- es dir weiterhin einfach nur "suspekt" ist - lass es klären oder vergiss es.

[marvin78]

Zu dem Punkt

IO Ersatzschaltungen vornehmen und Zustand sowie HMId der IOs verwalten (wenn sie einer vccu zugeordnet werden)

habe ich eine Frage:

Wenn ich einem Device die IOgrp zuweise, ist dann das IOdev Attribut überflüssig? Gibt es eine Rangordnung oder muss ich das IOdev Attribut entfernen?

Pairing passiert weiterhin über das IO-Device?

[martinp876]

wenn eine IOgrp zugewiesen ist, ist IODev nicht mehr relevant.
Ich hatte es als default verwendet - aber IODev wird von kernal-funktionen mit genutzt und ggf. manipoliert. Das wäre beim Setzen eines defaults kontraproduktiv.

Wenn du IOgrp gesetzt hast werden zum Senden nur IOs der CCU genutzt. Mit IOgrp ccu:defIO kannst du dein leiblings-IO für dieses Device festlegen.
IODev solltest du ignorieren.

Pairing passiert weiterhin über das IO-Device?

nein - wieso auch? Welches Scenario?
ach - jetzt: Ja, das Kommando hmPairForSec wird am IO ausgelöst. Das konnte man auch ändern, da hast du recht. Man könnte es der ccu zuweisen und dann IOgrp entsprechend setzen.  Gute Idee

Anmerkungen:
attr IODev sollte gesetzt werden, wenn IOgrp nicht gesetzt ist. Es ist irrelevant, wenn IOgrp genutzt wird
Internal IODev ist immer das IO, welches als letztes zum Senden genutzt wurde
Das Empfangen von Messages wird durch keines der Attribute eingeschränkt, es kommt immer über alle.
attr IOgrp ermöglicht Ersatzschaltung/dynamische IO zuweisung, rssi-auswertung und festlegen eines prefered-IOs

Gruss Martin

[marvin78]

Danke für die Antwort. Alles drin, was ich wissen wollte.

[betateilchen]

Falls du
- Fragen hast, frage

Was genau soll ich nun genau tun, um bei der Lösung der aufgetretenen Schwachstelle innerhalb meines Szenario zu helfen?

[martinp876]

aktuell ist mir nicht bekannt, dass Schwachstellen aufgetreten sind. Und dein Szenario kenne ich nicht.
Wenn du mir da einen Tip gibst, werde ich versuchen es zu Lösen und oder deine Szenarien berücksichtigen.

Falls du Fragen hast, ich also einen Teil nicht hinreichend erklärt habe, sag mir, was nicht verständlich war oder komplett gefehlt hat.

[stromer-12]

Im Logfile habe ich keinen Fehler aber bei einen FHEM Start erscheint auf der Console:

Code Auswählen Erweitern

substr outside of string at ./FHEM/10_CUL_HM.pm line 6408.
Use of uninitialized value $btnS in hex at ./FHEM/10_CUL_HM.pm line 6409.
sh: 1: Syntax error: word unexpected (expecting ")")
^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE $/ at fhem.pl line 1800.
substr outside of string at ./FHEM/10_CUL_HM.pm line 6408.
Use of uninitialized value $btnS in hex at ./FHEM/10_CUL_HM.pm line 6409.


# $Id: 10_CUL_HM.pm 6054 2014-06-04 07:43:35Z martinp876 $

Gruß
Gerd

[martinp876]

werde ich abfangen.
Allerdings hast du wohl eine entity mit seltsamen Attribut peerIDs.
was sagt
get hm param peerIDs
? Es sollten nur einträge mit 8 stellen drin stehen.

[stromer-12]

Ergibt:

Code Auswählen Erweitern

param done:
param list
    entity              : peerIDs              |
    CUL_HM_HM_LC_BL1_FM_1C7B62 : 00000000,
    CUL_HM_HM_LC_BL1_FM_221510 : 00000000,
    CUL_HM_HM_LC_SW4_DR_2060DE :  -
    CUL_HM_HM_LC_SW4_DR_2060DE_Sw_01 : 00000000,
    CUL_HM_HM_LC_SW4_DR_2060DE_Sw_02 : 00000000,
    CUL_HM_HM_LC_SW4_DR_2060DE_Sw_03 : 00000000,
    CUL_HM_HM_LC_SW4_DR_2060DE_Sw_04 : 00000000,
    CUL_HM_HM_PB_6_WM55_24BD20 :  -
    CUL_HM_HM_PB_6_WM55_24BD20_Btn_01 : 00000000,
    CUL_HM_HM_PB_6_WM55_24BD20_Btn_02 : 00000000,
    CUL_HM_HM_PB_6_WM55_24BD20_Btn_03 : 00000000,
    CUL_HM_HM_PB_6_WM55_24BD20_Btn_04 : 00000000,
    CUL_HM_HM_PB_6_WM55_24BD20_Btn_05 : 00000000,
    CUL_HM_HM_PB_6_WM55_24BD20_Btn_06 : 00000000,
    CUL_HM_HM_SCI_3_FM_244762 :  -
    CUL_HM_HM_SCI_3_FM_244762_Sw_01 : 00000000,
    CUL_HM_HM_SCI_3_FM_244762_Sw_02 : 00000000,
    CUL_HM_HM_SCI_3_FM_244762_Sw_03 : 00000000,
    CUL_HM_HM_SEC_SC_2_26B578 : 00000000,
    CUL_HM_KFM100_Sensor_1D9A46 :  -
    hmlan_ccu            :  -

[martinp876]

hm - kein Fehler zu sehen. Dann kann es nur an der ID der CCU liegen - auch seltsam.
Jedenfalls sollte es morgen nicht mehr auftreten.