Modellinformationen in der neuen FHEM Statistik

[betateilchen]

Hallo Entwicklerkollegen,

nachdem letztes Wochenende die neue FHEM Statistik live gegangen ist, wollte ich die Gelegenheit nutzen und kurz beschreiben, was bezüglich Eurer Module notwendig ist, damit verschiedene "Modelle" bei den angelegten devices korrekt gezählt werden können.

Für die Suche nach der Modellinformation eines devices gilt folgende (Prioritäten-)Reihenfolge:

• Internal -> 'model'
• Internal -> 'MODEL'
• Reading -> 'model'
• Attribute -> 'model'

(bitte Groß-/Kleinschreibung beachten!)

Sollte Euer Modul im device entsprechende Modellinformationen in einem der genannten Werte bereitstellen, werden diese Werte automatisch für die Zählung verwendet und es besteht kein weiterer Handlungsbedarf. Im Umkehrschluss bedeutet das aber auch, dass in diesen Werten nichts anderes stehen sollte, als eine wirklich nützliche Information.

Aktuell gibt es für die Statistik noch folgende modulspezifische Sonderbehandlungen, die ich gerne irgendwann wieder ausbauen möchte:

• BOSEST -> reading 'type' wird verwendet (dominik hat schon zugesagt, das im nächsten Update zu ändern, danke!)
• ZWAVE -> reading 'modelId' wird verwendet
• KNX -> model wird grundsätzlich ignoriert, weil da komplette hashes vorkommen, was nicht auswertbar ist
• CUL_HM -> (die Liste der Sonderlocken würde den Rahmen dieses Beitrags sprengen)

[rudolfkoenig]

Fuer ZWave sollte man mAn wieder model verwenden.

Erklaerung: modelId existiert parallel zu model, und ist die vom Geraet gemeldete Zahl. Das ZWave Modul baut daraus per Lookup in FHEM/lib/openzwave_manufacturer_specific.xml das model Reading. Ja, model kann sich theoretisch aendern, aber das kann man vernachlaessigen, und das trifft fuer die anderen Protokolle genauso zu. Als Benutzer der Statistik will man keine Nummer sehen, sondern den Text.

[krikan]

Ja, model kann sich theoretisch aendern, aber das kann man vernachlaessigen, und das trifft fuer die anderen Protokolle genauso zu.

Das aendert sich nicht nur theoretisch, sondern auch praktisch. 
Ich habe in der Vergangenheit haeufiger model-Texte geaendert. Dadurch hat das gleiche Geraet je nach Inklusionszeitpunkt bzw. letztem get-model-Abruf eine anderes model.
Außerdem gibt es erst ein Klartext-model, wenn ich eine Zuordnung in der XML vorgenommen habe, ansonsten ist es der Hexwert aus modelId.
Gebe zu, dass die Hexwerte unschön sind. Aber es ist zumindest eine saubere Datenbasis.
Aber entscheiden dürft ihr.

[betateilchen]

Die Änderung von model zu modelId habe ich erst nachträglich auf Anraten von krikan eingebaut.

Gibt es im ZWAVE Modul eine Funktion, die aus der modelId einen eindeutigen modelText zurückliefert? Dann kann ich in 98_fheminfo.pm diese Funktion verwenden um Modelle in Klartext zu zählen, unabhängig davon, wann der Anwender in seiner Installation zuletzt die model-Information aktualisiert hat.

[betateilchen]

Hab schon...

Code Auswählen Erweitern


sub zwaveModel($) {
  my ($zwave) = @_;
  my $xml = $attr{global}{modpath}.
            "/FHEM/lib/openzwave_manufacturer_specific.xml";

  my ($mf, $prod, $id) = split(/-/,$zwave);
  ($mf, $prod, $id) = (lc($mf), lc($prod), lc($id)); # Just to make it sure

  my ($err,@data) = FileRead({FileName => $xml, ForceType=>'file'});
  return $err if($err);

  my ($lastMf, $mName, $ret) = ("","");
  foreach my $l (@data) {
    if($l =~ m/<Manufacturer.*id="([^"]*)".*name="([^"]*)"/) {
      $lastMf = lc($1);
      $mName = $2;
      next;
    }
    if($l =~ m/<Product type\s*=\s*"([^"]*)".*id\s*=\s*"([^"]*)".*name\s*=\s*"([^"]*)"/) {
      if($mf eq $lastMf && $prod eq lc($1) && $id eq lc($2)) {
        $ret = "$mName $3";
        last;
      }
    }
  }
  return $ret if($ret);
  return $zwave;
}


Eigentlich gehört sowas ja in das ZWAVE Modul, aber ich baue das jetzt erstmal in fheminfo ein.

[betateilchen]

Kann mal bitte jemand, der ZWAVE im Einsatz hat, folgendes tun:

• 98_fheminfo.pm aus SVN auschecken und installieren
• "fheminfo send debug" ausführen
• die Ausgabe hier posten

Danke.

[rudolfkoenig]

Von der etwas angepassten Kopie meines Produktivsystems:

Code Auswählen Erweitern

{"CUL":{"noModel":"1"},"CUL_EM":{"noModel":"1"},"CUL_HOERMANN":{"noModel":"2"},"CUL_RFR":{"noModel":"1"},"CUL_TX":{"noModel":"1"},"CUL_WS":{"noModel":"5"},"FBAHAHTTP":{"noModel":"1"},"FBDECT":{"noModel":"5"},"FHEMWEB":{"noModel":"4"},"FHT":{"noModel":"2"},"FS20":{"dummySimple":"1","fs20as4":"10","fs20fms":"1","fs20ms":"5","fs20ms2":"1","fs20pira":"1","fs20piri":"5","fs20sa":"1","fs20st":"8","fs20st2":"1","noModel":"8"},"FileLog":{"noModel":"19"},"HMS":{"noModel":"1"},"KM271":{"noModel":"1"},"KS300":{"noModel":"1"},"SVG":{"noModel":"33"},"ZWDongle":{"noModel":"1"},"ZWave":{"":"14","Chromagic Technologies Corporation HSM02 Mini Door/Window Detector":"1","Everspring AN158 Plug-in Meter Appliance Module":"2","FIBARO System FGS221 Double Relay Switch 2x1.5kW":"1","Homeseer HSM100 Wireless Multi-Sensor":"1","Z-Wave.Me ZME_RC2 Remote Control":"1"},"allowed":{"noModel":"1"},"at":{"noModel":"8"},"autocreate":{"noModel":"1"},"dewpoint":{"noModel":"1"},"eventTypes":{"noModel":"1"},"holiday":{"noModel":"1"},"notify":{"noModel":"20"},"readingsGroup":{"noModel":"3"},"system":{"configType":"configFile","feature":"5.8","os":"darwin","perl":"5.16.2","release":"5.8","revision":"14652","uniqueID":"9924e40c53e3acbe572413980c89c296"},"telnet":{"noModel":"1"},"watchdog":{"noModel":"1"},"weblink":{"noModel":"1"}}
Btw.

Und parallel dazu gibts im Log:

2017.07.07 07:49:55.227 1: PERL WARNING: Use of uninitialized value $mf in lc at ./FHEM/98_fheminfo.pm line 259.
2017.07.07 07:49:55.227 1: PERL WARNING: Use of uninitialized value $prod in lc at ./FHEM/98_fheminfo.pm line 259.
2017.07.07 07:49:55.227 1: PERL WARNING: Use of uninitialized value $id in lc at ./FHEM/98_fheminfo.pm line 259.

[betateilchen]

Danke. Sieht prinzipiell nicht schlecht aus. Was mich irritiert sind die 14 Einträge ohne Modell. Gibt es ZWAVE devices, die keine modelId haben? Das würde auch die perl warnings erklären.

Code Auswählen Erweitern



"ZWave":{
"":"14",
"Chromagic Technologies Corporation HSM02 Mini Door/Window Detector":"1",
"Everspring AN158 Plug-in Meter Appliance Module":"2",
"FIBARO System FGS221 Double Relay Switch 2x1.5kW":"1",
"Homeseer HSM100 Wireless Multi-Sensor":"1",
"Z-Wave.Me ZME_RC2 Remote Control":"1"
}



[rudolfkoenig]

Gibt es ZWAVE devices, die keine modelId haben?

Ja:

1. wenn etwas nicht nach Plan laeuft. Modellabfrage ist ein extra "get model" an das Geraet bei der Inklusion (aka peering). Wenn die Antwort ausbleibt, wird das Geraet von FHEM trotzdem nicht entfernt, sondern existiert ohne model und modelId. Das stoert in manchen Faellen die Benutzer auch, weil sie die config Befehle vom Beipackzettel ablesen und numerisch eingeben muessen, es gibt kein dropdown mit Klartext und Hilfe im Frontend dazu. Ich gehe davon aus, dass sie das kurz oder lang fixen, indem sie die Abfrage manuell wiederholen.

2. Die Kanaele eines Geraetes (wie Fernbedienung) sind auch ZWave-Instanzen, sind erkennbar an dem Internal endpointParent oder ZWaveSubDevice=yes und haben keine eigene modelId.

-> Man kann sich bei TYPE=ZWave nicht darauf verlassen, dass model oder modelId gibt.

[betateilchen]

Das ist ja genau so ein Krampf wie bei Homematic *grummel*

[Markus Bloch]

Hallo zusammen,

mir ist noch aufgefallen, dass das Modul "dummy" neuerdings auch Models in der Statistik besitzt o.O

Ich nehme an, das Attribut "model" ist global in allen Definitionen verfügbar. Offenbar missbrauchen manche Nutzer dieses Attribut.

Gruß
Markus

[betateilchen]

Das ist mir auch noch bei ein paar anderen Modulen aufgefallen, wo "model" auch keinen Sinn macht. Aber ich glaube, wir werden das bei über 400 Modulen nicht zu 100% abfangen können.

Was mir im Moment den größten Kummer macht, ist KNX. Da ist die Zahl der Modelle plötzlich von 291 auf 454 explodiert. Und das, obwohl ich für KNX in der aktuellen Version von fheminfo gar keine Modelle mehr auswerte. Ich hoffe, dass diese Zahl sich irgendwann automatisch korrigiert.

Ausserdem habe ich das Modul "archetype" in Verdacht, das Attribut "model" völlig sinnfrei zu vererben. Dort stehen nämlich ähnliche Modelle drin, wie sie sich aktuell auch in "dummy" wiederfinden.

[betateilchen]

mir ist noch aufgefallen, dass das Modul "dummy" neuerdings auch Models in der Statistik besitzt o.O
Ich nehme an, das Attribut "model" ist global in allen Definitionen verfügbar.

Nein, ist es nicht.

ein "attr d1 model xyz" im Frontend wird mit der Fehlermeldung abgewiesen

Code Auswählen Erweitern

d1: unknown attribute model. Type 'attr d1 ?' for a detailed list.

In einem dummy kann also nur ein model auftreten, wenn es (von einem anderen Modul?) direkt in den %attr hash geschrieben wird.

[Markus Bloch]

umso schlimmer...

[igami]

Die model Attribute kommen tatsächlich davon dass ich die für archetype verwende. Die Dummys sind dabei Steuereinheit in denen die Werte für Automation stehen. UZSU Widget, Solltemperatur, Grenzwert.

Ist ja nicht verboten das Attribut model zum userattr von global hinzuzufügen

[betateilchen]

Ist ja nicht verboten das Attribut model zum userattr von global hinzuzufügen

Dann bin ich dafür, diesen Unfug ab sofort zu verbieten.

[rudolfkoenig]

Oder netter formuliert: bitte fuer diesen Zweck einen anderen Namen nutzen.

[betateilchen]

Nett kann ich auch, bringt aber meistens nix...

[igami]

Seit Jahren stört das keinen, dass ich dem dummy die Attribute subType und model gebe...
Ich werde mir aber was anderes überlegen

[betateilchen]

-> Man kann sich bei TYPE=ZWave nicht darauf verlassen, dass model oder modelId gibt.

• ZWAVE devices ohne modelId werden ab sofort für die Statistik ignoriert
• wird eine modelId gefunden, wird versucht, aus dem XML die Modellbezeichnung zu finden
• wird eine Bezeichnung gefunden, wird diese zum Zählen verwendet, ansonsten wird die Hex-ID verwendet

Dadurch sollte die Statistik für ZWAVE aussagekräftiger werden, ausserdem erkennt man an den Hex-IDs in der Statistik künftig die Modelle, die noch nicht im XML definiert sind. (wobei das natürlich abhängig ist vom Versionsstand der FHEM-Installation beim Anwender, denn es wird im XML auf Anwenderseite gesucht, nicht serverseitig)

[rudolfkoenig]

Danke, klingt nach perfekten Service.

[betateilchen]

Das Problem ist, dass ich sowas nicht testen kann, da ich keine ZWAVE Komponenten im Einsatz habe. Aber "theoretisch" müsste es nun so funktionieren wie beschrieben.

@Rudi: Du könntest nochmal die aktuelle Version testen und die Ausgabe von "fheminfo send debug" hier posten. Dann kann ich zumindest prüfen, ob die devices ohne Modellinfo verschwunden sind.

[rudolfkoenig]

Code Auswählen Erweitern

{"CUL":{"noModel":"1"},"CUL_EM":{"noModel":"1"},"CUL_HOERMANN":{"noModel":"2"},"CUL_RFR":{"noModel":"1"},"CUL_TX":{"noModel":"1"},"CUL_WS":{"noModel":"5"},"FBAHAHTTP":{"noModel":"1"},"FBDECT":{"noModel":"5"},"FHEMWEB":{"noModel":"4"},"FHT":{"noModel":"2"},"FS20":{"dummySimple":"1","fs20as4":"10","fs20fms":"1","fs20ms":"5","fs20ms2":"1","fs20pira":"1","fs20piri":"5","fs20sa":"1","fs20st":"8","fs20st2":"1","noModel":"8"},"FileLog":{"noModel":"19"},"HMS":{"noModel":"1"},"KM271":{"noModel":"1"},"KS300":{"noModel":"1"},"SVG":{"noModel":"33"},"ZWDongle":{"noModel":"1"},"ZWave":{"Chromagic Technologies Corporation HSM02 Mini Door/Window Detector":"1","Everspring AN158 Plug-in Meter Appliance Module":"2","FIBARO System FGS221 Double Relay Switch 2x1.5kW":"1","Homeseer HSM100 Wireless Multi-Sensor":"1","Z-Wave.Me ZME_RC2 Remote Control":"1"},"allowed":{"noModel":"1"},"at":{"noModel":"8"},"autocreate":{"noModel":"1"},"dewpoint":{"noModel":"1"},"eventTypes":{"noModel":"1"},"holiday":{"noModel":"1"},"notify":{"noModel":"20"},"readingsGroup":{"noModel":"3"},"system":{"configType":"configFile","feature":"5.8","os":"darwin","perl":"5.16.2","release":"5.8","revision":"14672","uniqueID":"9924e40c53e3acbe572413980c89c296"},"telnet":{"noModel":"1"},"watchdog":{"noModel":"1"},"weblink":{"noModel":"1"}}

Und keine Meldungen im Log

[betateilchen]

Danke, sieht gut aus. Und in der aktuellen Statistik hat sich auch die Anzahl der Hex-Werte bereits deutlich reduziert.

[PatrickR]

Mahlzeit!

In diesem Zusammenhang: Spricht eigentlich etwas dagegen, model etwas weiter auszulegen?

Um es konkret zu machen:
Dank Markus' freundlicher Hilfe kann ich von lepresenced Readings an das PRESENCE-Modul zurückgeben, also bspw. auch ein Reading "model". Ich hätte so die Möglichkeit, einen Einblick in die Zahl der Nutzer zu bekommen.

@Markus:
Da Du hier mitliest: Spricht aus Deiner Sicht etwas dagegen?

Patrick

[betateilchen]

Grundsätzlich spräche nichts dagegen, die Art der Erkennung bei presence als model zu führen.

Aber: Das würde voraussetzen, dass jedes PRESENCE device künftig eine Modellinformation liefert, sonst sind die gelieferten Zahlen in der Statistik nicht schlüssig interpretierbar.

Das Ganze wäre vergleichbar mit der Auswertung des verwendeten Datenbanksystems bei configDB und DbLog.

[Markus Bloch]

@Markus:
Da Du hier mitliest: Spricht aus Deiner Sicht etwas dagegen?

Nein, kannst Du gerne so implementieren. Bitte dazu ein Reading "model" generieren.

Aber: Das würde voraussetzen, dass jedes PRESENCE device künftig eine Modellinformation liefert, sonst sind die gelieferten Zahlen in der Statistik nicht schlüssig interpretierbar.

Dazu habe ich soeben eine Generierung des Reading "model" in PRESENCE eingebaut, welches den entsprechenden Modus (bluetooth/ping/etc.) beinhaltet. Dieses Reading wird einmalig beim Define gesetzt und kann durch presenced/lepresenced/collectord entsprechend übersteuert werden.

Viele Grüße

Markus

[PatrickR]

Großartig! Werde ich nach meinem Urlaub mal einbauen.


Von unterwegs gesendet.

[betateilchen]

Wen es interessiert:

Seit die Statistikdaten auch bei updateInBackground korrekt übertragen werden (danke, Markus für die Problemanalyse), hat sich die Zahl der täglich übertragenen Datensätze bei ca. 240 eingependelt.

Code Auswählen Erweitern


2017-07-23 : 241
2017-07-24 : 240
2017-07-25 : 236
2017-07-26 : 238