[HMinfoTools.js] ein WebUI für das modul HMinfo

Begonnen von frank, 12 Juli 2020, 12:28:10

Vorheriges Thema - Nächstes Thema

RalfRog

Da ich in letzter Zeit etwas mehr in Perl gemacht habe (und etwas besser Perl-Code verstanden) und den "SystemCheck" aufhübschen wollte fiel mir auf, dass die Push-Nachtrichten schon seit "Jahren" verstümmelt sein müssen, da nur das "hminfo" Event gesendet wurde.
Ich wollte daher den Code anpassen aber konnte die passenden Readings/Internals nicht finden (um dann eben über "HMinfoTools.js" zu stolpern  ;D).

Zu renovieren wären die drei Internals in 99_myUtils - ERR_names, ERR__protoNames, W__unreachNames:

############
## Perlcode um für SystemCheck die Fehler zu senden #######
sub HM_Error($$)
{
  my ($hminfo, $event) = @_;
  my $text = "";

  if ($event =~ /^ERR_[^_].*/) {
    # Event caused by sumERROR
    $text = "$event:".InternalVal($hminfo, "ERR_names", "");
  }
  elsif ($event =~ /^ERR__protocol:.*/) {
    # Protocol error
    $text = "$event:".InternalVal($hminfo, "ERR__protoNames", "");
  }
  elsif ($event =~ /^ERR__unreachable:.*/) {
    # Unreachable
    $text = "$event:".InternalVal($hminfo, "W__unreachNames", "")];
  }
  else {
    $text = "Unknown event: $event";
  }
#  fhem "set teleBot message @#FHEM $text" ;
  fhem "msg push $text" ;
}
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

RalfRog

#61
Schließen wir diesen OT Exkurs mal ab. Ich werde im ersten Schritt Folgendes ersetzen (und die Pushnachrichten auf unvollständige Ausgaben überwachen).

$text = "$event:".InternalVal($hminfo, "ERR_names", "") durch if's mit
  => ...InternalVal($hminfo, "iERR_Activity_dead", "")
  => ...InternalVal($hminfo, "iERR_battery_low", "")
  => ...InternalVal($hminfo, "iERR_sabotageError_on", "")

$text = "$event:".InternalVal($hminfo, "ERR__protoNames", "") mit
  => ...InternalVal($hminfo, "iERR__protocol", "")
 
$text = "$event:".InternalVal($hminfo, "W__unreachNames", "") mit
  => ...InternalVal($hminfo, "iERR__unreachable",, "")

Gruß Ralf

P.S. ...vielleicht ergibt sich für Martin ja mal die Gelgenheit, die cref anzupassen.  Aber ich merke ja schon als User bei mir ohne Modulpflege wieviel Arbeit in FHEM drinsteckt und die Zeit damit wegläuft...  :-[
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

frank

hallo ralf,

Zitat$text = "$event:".InternalVal($hminfo, "W__unreachNames", "") mit
  => ...InternalVal($hminfo, "iERR__unreachable",, "")
=> ...InternalVal($hminfo, "iW__unreachNames", "")

ausserdem gibt es noch critical protocol:
  => ...InternalVal($hminfo, "iCRI__protocol", "")
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

RalfRog

Hallo Frank
Ja die zugehörigen Readings der Beiden habe ich auch bei mir, da aber=0 gibt es aktuell keine Internals dazu - danke für die Namen ("iW__unreachNames", "iCRI__protocol").
Ich lass mir auch bei den "unbekannten" Fehlern ne Nachricht schicken und hoffe so nach und nach die relevanten Internals (mit den konkreten Devicenamen) zu fangen.
Denke die Häufigsten sind erfasst und ich habe jetzt endlich auch die Devicenamen zu den ERRs.

Da wird mir auch "HMinfoTools.js" sicher bei helfen  ;D
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

frank

#64
moin,
update im ersten post.

hminfotools hat ein neues icon (desired-io) bekommen.
damit lässt sich schnell erkennen, ob ein gewünschtes io auch aktuell benutzt wird.

aktuell erlaubt cul_hm 3 unterschiedliche io konfigurationen, die mit hilfe der 2 attribute IODev und IOgrp einstellbar sind.
1. kein attribut gewählt => fhem sucht sich irgend ein io. => macht hoffentlich niemand => icon immer rot.
2. nur attr IODev gesetzt => io fest eingestellt => warum keine vccu nutzen! => icon grün, wenn es genutzt wird, sonst rot
3. nur attr IOgrp gesetzt => vccu übernimmt die auswahl => sollte immer genutzt werden => grün nur, wenn mindestens ein preffered io gesetzt ist und das erste prefered io genutzt wird.


überblick der farbauswahl, ich hoffe ich habe nichts vergessen:
// color attr IOgrp set                              attr IODev set                           none
// ---------------------------------------------------------------------------------------------------------------------------
// white no prefered set                                                         
// green                        1. prefered                                 reading = attr
// yellow 2. prefered
// orange no prefered
// red no prefered (opt none), missing_IODev       reading != attr, missing_IODev           only red



ich wünsche einen bunten nachmittag.


edit: im tooltip ist das aktuelle io zu sehen und in klammern dahinter ggf die einstellung des gewählten attributes.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Benni

Hallo Frank,

Ich habe es mal eben schnell bei mir installiert, aber wenn man gerade keine "Problem"-Devices in hminfo hat, sieht man halt auch nichts ;)

wäre das denn nicht eher was für hm.js?
Die Info ist doch direkt am Device viel interessanter.

gb#


frank

ZitatIch habe es mal eben schnell bei mir installiert, aber wenn man gerade keine "Problem"-Devices in hminfo hat, sieht man halt auch nichts
das lässt sich in der regel, jedenfalls bei mir, ganz leicht ändern.  ;)


hminfo bietet ja quasi einen "benchmarktest" an:
ZitatcmdRequestG
issues a status request to update the system and performs access check to devices
ping: for one channel per CUL_HM device
status: for all channels that suport statusRequest
Ping will generate a message to the device. If not answered the device is unaccessible. Check protState for errors in case.
ein klick auf das attention-icon, 2. icon von links, in der icon übersicht startet den cmd => "set hminfo cmdRequestG ping". das erzeugt bei mir zumindestens einige warnungen (resend).  ein umgehendes "set hminfo update" sollte zudem auch alle pending devices zunächst anzeigen.



und ja, das kommt natürlich auch noch nach hm.js. die icons sollen grundsätzlich bei beiden identisch sein.
(da bin ich aber noch am umbauen, weswegen es noch dauern wird)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

#67
tipp:
um alle hauptdevices anzuzeigen, auch wenn sie keine fehler haben, kann man auch das attribut summERROR von hminfo um den eintrag "IODev:ok" erweitern. das zeigt alle entities, die ein reading IODev haben, das nicht "ok" ist.  ;)

auf jeden fall sollte jeder das attribut um den eintrag "cfgState:ok" ergänzen, damit alle entities mit configcheck problemen auftauchen. schade, dass hminfo diesen eintrag in der default einstellung nicht anbietet.

die einträge im attribut sind durch kommas zu trennen: ","
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

tipp des jahres:  8)

seit ein paar tagen gibt es einen neuen fhem cmd (fhemdebug forceEvents {0|1}), womit man events "aktivieren" kann, die im modul code abgeschaltet sind. um dieses wunderbare feature regelmässig nutzen zu können, muss man allerdings zunächst ein mehrstufiges sicherungssystem "entsichern".
dieser cmd aktiviert zusätzliche events nur in fhem devices, bei denen ein userattr forceEvents=1 gesetzt ist. ausserdem reagieren nur readings, die im code durch die fhem standard methoden gesetzt werden.

dieser "sicherungsmechanismus" ist ein kompromiss, um befürworter und kritiker dieses features gleichermassen zufrieden zu stellen => https://forum.fhem.de/index.php/topic,123655.0.html.

vor der nutzung des neuen features sollte man zunächst unbedingt die aktuelle eventbelastung des systems prüfen und/oder verbessern. bei vielen usern sind bereits probleme zu beobachten, die schon durch die "normalen" events verursacht werden, da sie keine massnahmen zur reduzierung von events vorgenommen haben.
spätestens jetzt, vor dem aktivieren zusätzlicher events, bitte entsprechende massnahmen durchführen. jeder user ist für seine "event hygiene" selbst verantwortlich.
als standard massnahme sollte also grundsätzlich in jedem fhem device, nicht nur homematic, mindestens folgendes attribut zur reduzierung von events existieren:
attr <device> event-on-change-reading .*
ausserdem ist für jedes homematic hauptdevice das setzen des attributes commStInCh=off mehr als sinnvoll, da es bereits viele probleme löst.
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=DEF!=000000 commStInCh off




anleitung zur nutzung von longpoll für das icon desired-io-check:

mit diesem feature kann man nun longpoll für das neue icon desired-io-check aktivieren.
das icon reagiert auf events des readings IODev, das in allen homematic hauptdevices existiert und normal keine events erzeugt. mit erfolgter aktivierung ist ggf live ein wechsel des aktuellen io zu sehen.

0. fhem updaten, um die neue version von 98_fhemdebug zu bekommen.

1. ein userattribut "forceEvents" installieren:
zb über das globale attribut "userattr", indem wir "userattr" erweitern mit =>
forceEvents:0,1

2. das neue attribut "forceEvents=1" setzen:
wir brauchen es nur in allen homematic devices, die das reading IODev besitzen. das sind alle hauptdevices (DEF=6-stellig) ausser dem actiondetector (DEF=000000).
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=DEF!=000000 forceEvents 1

3. die zusätzlichen events einschalten:
mit folgendem fhem cmd im befehlseingabefeld werden zusätzliche events eingeschaltet =>
fhemdebug forceEvents 1
folgender befehl schaltet die zusätzlichen events wieder aus. jeder fhem restart schaltet die zusätzlichen events auch automatisch wieder aus =>
fhemdebug forceEvents 0

4. automatisches einschalten bei jedem fhem restart:
wer schon einen automatismus in seinem fhem installiert hat, der bei fhem restart einige aktionen automatisch ausführt, baut dort den befehl ein. alle anderen können zb folgendes notify definieren =>
define n_forceEvents notify global:INITIALIZED fhemdebug forceEvents 1

5. alle definitionen und einstellungen sichern



in meinem fhem läuft das feature bereits ein paar tage unauffällig.
wenn jemand das feature nutzt und probleme beobachtet, bitte melden.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

eisman

#69
Hi,

hoffe mal das es hier richtig ist, ein kleiner Schönheitsfehler.

register configuration ( ST_0101_SenF:general )
  [HM-ES-PMSW1-PL]
     _SenF
        siehe Bild: 2x transmitTryMax und txThrHiFrq mit txThrLoFrq vertauscht


mfg
1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian, Homematic,ZigBee         / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian,MQTT                               / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S

frank

gut aufgepasst,
die fehler liefert "get regList" in allen 4 sensor channels.

zusätzlich sollten statusInfoMinDly und statusInfoRandom wohl nur im switch channel auftauchen.

list:         register | range              | peer     | description
   1: cndTxCycAbove    |     literal        |          | cyclic trigger if level is above cndTxDecAbove options:on,off
   1: cndTxCycBelow    |     literal        |          | cyclic trigger if level is below cndTxCycBelow options:off,on
   1: cndTxDecAbove    |   0 to 255         |          | decission level for cndTxCycAbove
   1: cndTxDecBelow    |   0 to 255         |          | decission level for cndTxCycBelow
   1: cndTxFalling     |     literal        |          | trigger if falling options:on,off
   1: cndTxRising      |     literal        |          | trigger if rising options:on,off
   1: ledOnTime        | 0.00 to 1.275s      |          | LED ontime
   1: sign             |     literal        |          | signature (AES) options:on,off
   1: statusInfoMinDly | 0.0 to 15.5s       |          | status message min delay special:unused
   1: statusInfoRandom |   0 to 7s          |          | status message random delay
   1: transmitTryMax   |   1 to 10          |          | max message re-transmit
   1: transmitTryMax   |   1 to 10          |          | max message re-transmit
   1: txThrHiFrq       | 48.72 to 51.27Hz     |          | threshold low frequency
   1: txThrLoFrq       | 48.72 to 51.27Hz     |          | threshold high frequency
   4: expectAES        |     literal        | required | expect AES options:off,on
   4: peerNeedsBurst   |     literal        | required | peer expects burst options:on,off



die vertauschung betrifft nach eq3-xml-file die beschreibung. die müsste dann in HMConfig.pm (zeilen 667-674) getauscht werden:

        <parameter id="COND_TX_THRESHOLD_HI_FREQUENCY" operations="read,write">
          <logical type="float" min="48.72" max="51.27" unit="Hz" default="50.20" />
          <physical type="integer" interface="config" list="1" index="135" size="4" />
          <conversion type="float_integer_scale" factor="100" />
        </parameter>
        <parameter id="COND_TX_THRESHOLD_LO_FREQUENCY" operations="read,write">
          <logical type="float" min="48.72" max="51.27" unit="Hz" default="49.80" />
          <physical type="integer" interface="config" list="1" index="139" size="4" />
          <conversion type="float_integer_scale" factor="100" />
        </parameter>


  txThrHiPwr      =>{a=>135.0,s=>4  ,l=>1,min=>"0.00" ,max=>3680   ,c=>''        ,p=>'n',f=>'100'   ,u=>'W'   ,d=>1,t=>"threshold low power"},
  txThrLoPwr      =>{a=>139.0,s=>4  ,l=>1,min=>"0.00" ,max=>3680   ,c=>''        ,p=>'n',f=>'100'   ,u=>'W'   ,d=>1,t=>"threshold high power"},
  txThrHiCur      =>{a=>135.0,s=>4  ,l=>1,min=>0      ,max=>16000  ,c=>''        ,p=>'n',f=>''      ,u=>'mA'  ,d=>1,t=>"threshold low current"},
  txThrLoCur      =>{a=>139.0,s=>4  ,l=>1,min=>0      ,max=>16000  ,c=>''        ,p=>'n',f=>''      ,u=>'mA'  ,d=>1,t=>"threshold high current"},
  txThrHiVlt      =>{a=>135.0,s=>4  ,l=>1,min=>"115.0",max=>255   ,c=>''        ,p=>'n',f=>'10'    ,u=>'V'   ,d=>1,t=>"threshold low voltage"},
  txThrLoVlt      =>{a=>139.0,s=>4  ,l=>1,min=>"115.0",max=>255   ,c=>''        ,p=>'n',f=>'10'    ,u=>'V'   ,d=>1,t=>"threshold high voltage"},
  txThrHiFrq      =>{a=>135.0,s=>4  ,l=>1,min=>48.72  ,max=>51.27  ,c=>''        ,p=>'n',f=>'100'   ,u=>'Hz'  ,d=>1,t=>"threshold low frequency"},
  txThrLoFrq      =>{a=>139.0,s=>4  ,l=>1,min=>48.72  ,max=>51.27  ,c=>''        ,p=>'n',f=>'100'   ,u=>'Hz'  ,d=>1,t=>"threshold high frequency"},
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

update im ersten post.

ein rssi-icon macht jetzt auch longpoll, wenn im entsprechenden hauptdevice das attribut rssiLog eingeschaltet ist.
sobald ein passendes rssi-event eintrifft, färbt sich der mast der antenne weiss und der rest wie bisher. im tooltip ist dann auch nur der aktuelle rssi ohne statistik zu sehen. bei jedem neuauufbau der tabelle zeigen die rssi-icons zunächst wieder den statistischen rssi-min-wert, bis zum nächsten eintreffen eines rssi events.

ein event des readings IODev, das einen io-wechsel ankündigt, ändert nun auch das rssi-icon entsprechend.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

#72
update im ersten post.


neu:

mit einem userattr im modul hminfo können nun zusätzlich auch alle devices angezeigt werden, die keine fehler melden. folgendes userattr erzeugen und anschliessend auf "all" setzen. default ist "err".
attr hminfo userattr HMinfoTools_deviceMode:all,err

ab dieser version erzeugt HMinfoTools.js die icons für HMdeviceTools.js (neuer name und neue version von hm.js).
dadurch identische icons mit identischem verhalten auf jeder detailsseite aller cul_hm entities.
hier gibt es HMdeviceTools.js: https://forum.fhem.de/index.php/topic,106959.msg1008033.html#msg1008033

ein paar optimierungen einiger icons (battery mit veränderlichem icon, activity nur noch bei realen entities, ...)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

update im ersten post.
fix für fehlenden templatecheck in HMdeviceTools integriert.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

#74
update v2002 seit heute mittag. 
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html