[HM-Wired] Probleme mit STATE bei key-Events

[Thorsten Pferdekaemper]

Hi,
dieser Thread ist aus diesem Beitrag entstanden: http://forum.fhem.de/index.php/topic,22952.msg315654.html#msg315654.
Da das dort etwas off-Topic ist habe ich es in einen neuen Thread verlagert.
Gruß,
    Thorsten

Ich habe jetzt auch mal die 10_HM485.pm von Thorsten mit einem Homebrew Modul mit Tastereingängen getestet.
Dabei ist mir aufgefallen, das in der Kanalübersicht im subType key beim drücken einer Taste der state nicht angezeigt wird. Ist dies bei euch auch so?
Wenn ich in der "10_HM485.pm" in der "sub HM485_ChannelDoUpdate" die folgende Zeile auskommentiere, funktioniert es.

Code Auswählen Erweitern


# if ( defined( $chHash->{STATE}) && $chHash->{STATE}) {


Ich habe auch mal die aktuelle Version von honk getestet, dort funktioniert es. Mir ist aufgefallen das dort
"press_short 33" anstatt "press_short_press_short 33" angezeigt wird.

@honk wo hast Du das geändert, ich finde das so schöner.

Gruß Ralf

[Thorsten Pferdekaemper]

Ich habe jetzt auch mal die 10_HM485.pm von Thorsten mit einem Homebrew Modul mit Tastereingängen getestet.
Dabei ist mir aufgefallen, das in der Kanalübersicht im subType key beim drücken einer Taste der state nicht angezeigt wird. Ist dies bei euch auch so?
Wenn ich in der "10_HM485.pm" in der "sub HM485_ChannelDoUpdate" die folgende Zeile auskommentiere, funktioniert es.

Code Auswählen Erweitern


# if ( defined( $chHash->{STATE}) && $chHash->{STATE}) {


Ich nehme mal an, dass das ansonsten die einzige Stelle ist, wo ein Channel sein STATE bekommt. In einer älteren Version war das vielleicht anders, da früher die Kanäle ein paar Sachen vom Device übernommen haben. Das ist jetzt nicht mehr so.

Ich habe auch mal die aktuelle Version von honk getestet, dort funktioniert es. Mir ist aufgefallen das dort
"press_short 33" anstatt "press_short_press_short 33" angezeigt wird.

Wenn ich mir das Coding anschaue, dann würde ich auch erwarten, dass es ein Reading mit Namen "press_short" gibt, das "press_short_33" anzeigt. Das wäre meiner Meinung nach auch nicht ganz richtig. Es sollte eigentlich nur "33" anzeigen.
Ich kann das gerade selbst nicht testen, da ich gerade nichts mit einer Taste dranhängen habe. Kann das mal jemand tun?

Ich sehe im Coding auch eine Sonderbehandlung von press_long. Ich blicke nicht ganz durch, aber es sieht so aus, als ob ein press_long keine FHEM-Events produzieren soll, wenn es durch wirklich langes Drücken der taste wiederholt wird. Da das ganze aber sowieso auf der event-on-change-reading-Liste steht, wenn das System da hin kommt, dann hat sich an der Stelle der Wert doch schon geändert. ...oder?
Ich habe den Eindruck, dass hier auch etwas nicht stimmt.

@honk wo hast Du das geändert, ich finde das so schöner.

Das würde mich auch interessieren. Ich würde das Coding dann ggf. auch in "meine" Version übernehmen. (...in der Hoffnung, dass wir am Ende wieder nur eine Version haben.)

Gruß,
   Thorsten

[Ralf9]

Ich habe bei mir noch zusätzlich in der 10_HM485.pm die folgenden Zeilen entfernt, da ich die press_short und press_long events gerne in den readings hätte.

Code Auswählen Erweitern

# Bei Channels vom Typ KEY das Reading PRESS_SHORT oder PRESS_LONG loeschen
my $chNr = sprintf ('%02d' , hex( substr( $msgData, 2, 2)) + 1);
my $chTyp = HM485::Device::getChannelType( $deviceKey, $chNr);
if ( $chTyp eq 'key') {
my $chHash = HM485_GetHashByHmwid( $hmwId . '_' . $chNr);
my $chName = $chHash->{NAME};
if ( defined( ReadingsVal( $chName, 'press_short', undef))) {
fhem( "deletereading $chName press_short");
} elsif ( defined( ReadingsVal( $chName, 'press_long', undef))) {
fhem( "deletereading $chName press_long");
} else {
# kein reading zu loeschen
}
}

Gruß Ralf

[hglaser]

hallo

@honk wo hast Du das geändert, ich finde das so schöner.

Ach unterm schreiben hat es Ralf schon gefunden
lg harald

[Ralf9]

ich habe mal in der letzten Version von Thorsten ein paar Ergänzungen gemacht. Ich habe ein paar Versionsinformationen in den Anfang der 10_HM485.pm geschrieben. Wenn es ok ist würde ich gerne als Unterversionsnr einen Buchstaben hochzählen, dann wäre dies jetzt  die Testversion d

Ich habe ein paar Zeilen gelöscht, damit die  press_short und press_long wieder im reading angezeigt werden.
Ich habe auch in  der "sub HM485_ChannelDoUpdate" ein paar Änderungen gemacht damit die press_short und press_long im state angezeigt werden.
Sie werden nun verkürzt "press_long 18" im state angezeigt.
Diese Änderungen haben aber den Nachteil, daß beim länger drücken das  press_long nicht mehr wiederholt wird. Dazu müssten in der  "sub HM485_ChannelDoUpdate" noch einige anpassungen vorgenommen werden.

Ich habe bei dem set Button noch "deletereading" und "statusrequest" zugefügt. Mit dem "set statusrequest" kann auch per webcmd der status abgefragt werden.

Weiß zufällig jemand zu was der "set install_test" gut ist?

Gruß Ralf

[Thorsten Pferdekaemper]

Hi,
jetzt wird's so langsam etwas unübersichtlich. Na wenigstens kommt etwas Leben in die Entwicklung.

Ich habe bei mir noch zusätzlich in der 10_HM485.pm die folgenden Zeilen entfernt, da ich die press_short und press_long events gerne in den readings hätte.

Soweit ich das Coding verstanden hatte, wird das eigentliche Update der Readings per InternalTimer gestartet. D.h. es müsste tatsächlich nach dem Löschen des Readings passieren. Daher dachte ich, dass das Löschen nichts macht. Naja, aber besonders wichtig kann es andererseits auch nicht sein.

Wenn es ok ist würde ich gerne als Unterversionsnr einen Buchstaben hochzählen, dann wäre dies jetzt  die Testversion d

Mir ist das im Prinzip egal. Ich werde aber in Zukunft darauf achten, auch die Versionsnummer irgendwie hochzuzählen, wenn ich etwas "veröffentliche". Spätestens wenn's ins Git kommt hätte ich das sowieso getan.

Sie werden nun verkürzt "press_long 18" im state angezeigt.

Ja, so hatte ich das auch gemeint.

Diese Änderungen haben aber den Nachteil, daß beim länger drücken das  press_long nicht mehr wiederholt wird. Dazu müssten in der  "sub HM485_ChannelDoUpdate" noch einige anpassungen vorgenommen werden.

Im Prinzip muss es dann aber momentan so sein, dass diese Events explizit irgendwo unterdrückt werden.

Ich habe bei dem set Button noch "deletereading"

Wozu ist das gut? Ich denke, dass man ein Reading nur im absoluten Ausnahmefall löschen will. ...und dafür gibt's ja sowieso schon was.

und "statusrequest" zugefügt. Mit dem "set statusrequest" kann auch per webcmd der status abgefragt werden.

Was für einen Status denn? Ein "get state" gibt's eigentlich schon. Oder meinst Du was anderes?

Weiß zufällig jemand zu was der "set install_test" gut ist?

In Dirks Doku zum Protokoll steht was von "install test" beim Befehl 0x78. Ich weiß aber auch nicht, was das soll. Da müsste mal jemand ran, der eine CCU hat.

Gruß,
   Thorsten

[Ralf9]

Hallo Thorsten

Ein "set deletereading" ist praktisch, wenn man z.B. von einer alten Version mit Großschreibung auf eine aktuelle Version wechselt. Oder wenn man verschiedene Versionen testet. Wenn Du z.B. die Version von honk testet hast Du hinterher im reading auch einen "state" eintrag

Ein "set statusrequest" ist z.B. bei Eingängen (z.B. Frequenz oder Anlalog) die nicht automatisch aktualisiert werden oder das logging abgeschaltet ist, sinnvoll. Da kann dann in der Kanalübersicht ein webcmd status eingefügt werden.

Code Auswählen Erweitern


attr  eventMap  /statusrequest:status/
attr  webCmd  status


Gruß Ralf

[Thorsten Pferdekaemper]

Hi,
so, im Dev-Branch gibt es jetzt Version 0.6.1 (https://github.com/kc-GitHub/FHEM-HM485/tree/dev).
Das Folgende habe ich geändert:

1. Log levels für ein paar Log-Einträge erhöht. Dadurch kommt im Log hoffentlich nur noch wichtiges an.

2. press_short und press_long readings werden jetzt angezeigt. Als Wert sieht man nur die "Tastendruck-Nummer". Ich denke, dass das so "richtiger" ist.

3. HM485_ProcessChannelState aufgeräumt. (Es gab Perl-Warnungen, da
versucht wurde Announce-Messages zu interpretieren.)

4. event-min-interval und event-change-reading werden jetzt dem "FHEM
core" überlassen Dadurch werden auch press_long ordentlich wiederholt. Man kann sieht das im Event Monitor und daran, dass sich die Zeit in den Readings ändert. Ich habe event-min-interval und event-change-reading getestet und es funktioniert noch.

5. STATE erhält in den Kanälen den letzten Tastendruck (z.B.
press_short_42) Man sieht STATE allerdings erst, nachdem das erste Mal (seit shutdown restart oder so) eine Taste gedrückt wurde.

Für die Darstellung der Readings habe ich nicht Ralf9s Coding übernommen, sondern das ganze in Device.pm erledigt. Ich denke, dass der Fehler war, das der Key und der Wert des Readings dort verkettet wurde.

Ich hatte einmal einen Fall, dass sich ein Reading ins Device selbst verirrt hatte. Ich konnte das aber nicht mehr nachvollziehen. Falls es jemand schafft, her damit...

Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Ein "set deletereading" ist praktisch, wenn man z.B. von einer alten Version mit Großschreibung auf eine aktuelle Version wechselt. Oder wenn man verschiedene Versionen testet. Wenn Du z.B. die Version von honk testet hast Du hinterher im reading auch einen "state" eintrag

Das rechtfertigt meiner Meinung nach nicht, das als "set" im Device zu machen. Ein "deletereading <channel> <reading>" direkt als Befehl abzusetzen ist ja nicht so die Arbeit und es sollte wirklich nicht oft vorkommen.

Ein "set statusrequest" ist z.B. bei Eingängen (z.B. Frequenz oder Anlalog) die nicht automatisch aktualisiert werden oder das logging abgeschaltet ist, sinnvoll. Da kann dann in der Kanalübersicht ein webcmd status eingefügt werden.

Das habe ich auch nicht übernommen, weil es genau dasselbe macht wie "get <channel> state". Das gibt's schon auf der Oberfläche, direkt unter dem "set"-Button. Ich habe im Coding nachgeschaut, es schickt denselben Befehl, den Du auch reinprogrammiert hast.

Gruß,
   Thorsten