[HM-Wired] Version 0.8.00 - Tester gesucht

[Thorsten Pferdekaemper]

Oh, das ist jetzt wirklich etwas blöd. Komisch, dass ich das Problem nie hatte, obwohl ich das ganze auch mal auf einer frischen Installation getestet habe.
Eigentlich wollte ich die v0800 heute nach master schieben, aber das lasse ich jetzt erstmal bleiben. Ansonsten könnte das bei jemandem, der einfach ein normales update macht auf die Bretter gehen.

EDIT: Ich habe dazu mal einen Thread im Developer-Bereich aufgemacht: https://forum.fhem.de/index.php?topic=71399.msg629002#msg629002.

Danke&Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Offenbar war mein System noch zu neu: Ich musst noch XML::SAX und XML::Simple nachinstallieren.

Ich habe jetzt noch ein bisschen geforscht und gefunden, dass anscheinend das Debian-Paket für FHEM von libxml-simple-perl abhängt, was genau XML::Simple enthält und wiederum XML::SAX oder ähnlich voraussetzt. Wie hast Du denn FHEM installiert, dass Du diese Pakete nicht hattest?
Gruß,
    Thorsten

[cjung]

Hi Thorsten,

Mein FHEM System ist schon etwas alt und gem. dem Erstellungsdatum der Verzeichnisse am 24.09.2015 installiert worden.
Seit dem wurde es durch normale Updates aktuell gehalten.

Installiert habe ich es natürlich auch über das Debian Paket.
Kein Ahnung ob es damals schon notwendig war. Irgendwie hat es noch nie gefehlt.

Gruß
Christoph

[Thorsten Pferdekaemper]

Hi,

ich habe jetzt doch nochmal was überarbeitet.
Wenn jetzt XML::Simple fehlt (oder ähnlich), dann stürzt FHEM nicht mehr ab, sondern startet fast normal. Die HM485-Devices können auch betrachtet werden, funktionieren aber nicht wirklich in FHEM. Es wird da, wo ansonsten "Device configuration" usw. angezeigt wird, ein roter Fehlertext angezeigt, der sagt, was los ist. Außerdem steht etwas im Logfile.
Außerdem werden die nicht mehr vorhandenen Attribute jetzt etwas "freundlicher" gelöscht, so dass es nicht mehr zu den ganzen Fehlermeldungen kommt.

Könnte nochmal jemand die neuste Version aus v0800 holen und ausprobieren, ob noch alles geht? Den update-Prozess nochmal auszuprobieren wäre wahrscheinlich etwas zu viel verlangt...

Danke&Gruß,
   Thorsten

[Lonie]

Hi Thorsten,

das hat jetzt zwar nicht wirklich etwas mit deinem Update zu tun aber ich habe ein merkwürdiges Verhalten. Ich habe noch nicht herausgefunden wodurch es ausgelöst wird. Manchmal verschwindet der Tab "Peering Configuration". Die Peerings sind noch vorhanden und funktionieren, im Log finden sich keine Auffälligkeiten. Ein getConfig bringt keine Besserung. Nur ein Neustart von fhem sorgt dafür dass im Frontend alles wieder richtig angezeigt wird. Eventuell kannst du dir so schon einen Reim darauf machen, ansonsten versuche ich das Nachstellbar zu machen.


Liebe Grüße
Marcel

10_HM485.pm   800 2017-04-13 21:19:00Z ThorstenPferdekaemper

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        000141C3
   FailedConfigReads 0
   IODev      HM485LAN
   NAME       HMW_IO_12_Sw7_DR_MEQ1534890
   NR         13
   RawDeviceType 18
   RawFwVersion 774
   STATE      ACK
   TYPE       HM485
   channel_01 WZ.Taster.RO
   channel_02 WZ.Taster.LO
   channel_03 WZ.Taster.LM
   channel_04 WZ.Taster.RM
   channel_05 WZ.Taster.LU
   channel_06 WZ.Taster.RU
   channel_07 GA.Klingel
   channel_08 WZ.BW.Treppe
   channel_09 HMW_IO_12_Sw7_DR_MEQ1534890_09
   channel_10 HMW_IO_12_Sw7_DR_MEQ1534890_10
   channel_11 HMW_IO_12_Sw7_DR_MEQ1534890_11
   channel_12 HMW_IO_12_Sw7_DR_MEQ1534890_12
   channel_13 KU.Tischlicht
   channel_14 WZ.Deckenlicht
   channel_15 FL.Deckenlicht
   channel_16 KU.Deckenlicht
   channel_17 BK.Wandlicht
   channel_18 WZ.Sofalicht
   channel_19 WZ.Esstischlicht
   peer_act_0 channel_02 → KU.Deckenlicht
   peer_act_1 channel_03 → KU.Tischlicht
   peer_act_2 channel_04 → WZ.Deckenlicht
   peer_act_3 channel_05 → WZ.Sofalicht
   peer_act_4 channel_06 → WZ.Esstischlicht
   peer_act_5 channel_05 → WZ.TV
   peer_act_6 channel_06 → WZ.TV
   peer_sen_0 channel_16 ← WZ.Taster.LO
   peer_sen_1 channel_13 ← WZ.Taster.LM
   peer_sen_2 channel_14 ← WZ.Taster.RM
   peer_sen_3 channel_18 ← WZ.Taster.LU
   peer_sen_4 channel_19 ← WZ.Taster.RU
   peer_sen_5 channel_15 ← FL.Taster.Deckenlicht
   Readings:
     2017-05-07 21:35:03   D-deviceKey     HMW_IO12_SW7_DR
     2017-05-07 21:35:03   D-fwVersion     3.06
     2017-05-07 21:35:03   D-serialNr      MEQ1534890
     2017-05-07 21:35:07   R-central_address 00000001
     2017-05-07 21:35:07   R-logging_time  2.00
     2017-05-07 21:35:08   configStatus    OK
     2017-05-07 21:35:08   state           ACK
   Cache:
     01:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
     02:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
     03:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
     04:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
     07:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
     08:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
     09:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
     10:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
     11:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
     12:
       allowedSets press_short:noArg press_long:noArg
       peeredChannels:
     13:
       allowedSets on:noArg off:noArg toggle:noArg on-for-timer:textField inhibit:noArg install_test
       peeredChannels:
     14:
       allowedSets on:noArg off:noArg toggle:noArg on-for-timer:textField inhibit:noArg install_test
       peeredChannels:
     15:
       allowedSets on:noArg off:noArg toggle:noArg on-for-timer:textField inhibit:noArg install_test
       peeredChannels:
     16:
       allowedSets on:noArg off:noArg toggle:noArg on-for-timer:textField inhibit:noArg install_test
       peeredChannels:
     17:
       allowedSets on:noArg off:noArg toggle:noArg on-for-timer:textField inhibit:noArg install_test
       peeredChannels:
     18:
       allowedSets on:noArg off:noArg toggle:noArg on-for-timer:textField inhibit:noArg install_test
       peeredChannels:
     19:
       allowedSets on:noArg off:noArg toggle:noArg on-for-timer:textField inhibit:noArg install_test
       peeredChannels:
     Linkparams:
       Actuator:
         address_start 857
         address_step 6
         channel_param channel
         channels   01 02 03 04 05 06 07 08 09 10 11 12
         count      27
         peer_param actuator
         type       link
         parameter:
           HASH(0x3c7ea18)
           HASH(0x3c7ed18)
       Sensor:
         address_start 45
         address_step 28
         channel_param channel
         channels   13 14 15 16 17 18 19
         count      29
         peer_param sensor
         type       link
         parameter:
           HASH(0x3ce5130)
           HASH(0x3ce5400)
           HASH(0x3ce6038)
           HASH(0x3ce6320)
           HASH(0x3ce65d8)
           HASH(0x3ce6b78)
           HASH(0x3ce6e48)
           HASH(0x3ce8cd0)
           HASH(0x3ce9120)
           HASH(0x3ce94f8)
           HASH(0x3ce9948)
           HASH(0x3ceb7d0)
           HASH(0x3cebbd8)
           HASH(0x3cebfe0)
           HASH(0x3cec3e8)
           HASH(0x3ceef98)
           HASH(0x3cef250)
           HASH(0x3cef7f0)
           HASH(0x3cef9b8)
           HASH(0x3cefc70)
           HASH(0x3cf0b48)
           HASH(0x3cf0f98)
           HASH(0x3cf1370)
           HASH(0x3cf17c0)
           HASH(0x3cf3658)
           HASH(0x3cf3a60)
           HASH(0x3cf3e68)
           HASH(0x3cf6d78)
     Peered_act:
       0:
         channel    02
         name       000141C3_16
       1:
         channel    03
         name       000141C3_13
       2:
         channel    04
         name       000141C3_14
       3:
         channel    05
         name       000141C3_18
       4:
         channel    06
         name       000141C3_19
       5:
         channel    05
         name       0000D1F4_13
       6:
         channel    06
         name       0000D1F4_13
     Peers:
       Actuators:
         0:
           actuator   000141C3_16
           channel    02
         1:
           actuator   000141C3_13
           channel    03
         2:
           actuator   000141C3_14
           channel    04
         3:
           actuator   000141C3_18
           channel    05
         4:
           actuator   000141C3_19
           channel    06
         5:
           actuator   0000D1F4_13
           channel    05
         6:
           actuator   0000D1F4_13
           channel    06
       Sensors:
         0:
           channel    16
           sensor     000141C3_02
         1:
           channel    13
           sensor     000141C3_03
         2:
           channel    14
           sensor     000141C3_04
         3:
           channel    18
           sensor     000141C3_05
         4:
           channel    19
           sensor     000141C3_06
         5:
           channel    15
           sensor     0000D1F4_05
Attributes:
   DbLogExclude .*
   IODev      HM485LAN
   autoReadConfig atstartup
   room       9.11_HM485
   verbose    3


[Thorsten Pferdekaemper]

Hi Marcel,

ich habe mir mal mein Coding betrachtet und habe einen Verdacht.
Ich kann das nachstellen, wenn ich während das "getConfig" noch läuft auf die Detailseite eines Kanals wechsle und dort ggf. ein paar Mal einen Browser-Refresh mache. Dann verschwindet die Taste.
Allerdings erscheint sie wieder, wenn ich das nächste Mal ein getConfig auslöse und dann brav warte bis configStatus wieder auf OK steht.
Kannst Du vielleicht nochmal damit rumspielen? Kannst Du es auch anders nachvollziehen?

Wenn es nochmal vorkommt, könntest Du dann mal das ins Kommandofeld eingeben:

Code Auswählen Erweitern


{delete($defs{HMW_IO_12_Sw7_DR_MEQ1534890}{cache})}

Erscheint dann die Taste wieder?

EDIT: Ich kann es auch nachvollziehen, wenn ich in die Geräteübersicht (also einen Raum mit dem Gerät) gehe während getConfig noch läuft. Letzteres schließt den FHEM-Start mit ein. Aber auch hier repariert ein neues getConfig das Ganze wieder.

Danke&Gruß,
    Thorsten

[Lonie]

Guten Morgen Thorsten,

getConfig hatte ich gestern bereits getestet und das brachte keine Besserung. Das hatte ich durchgeführt als keine weiteren Seiten offen waren. Das leeren des Caches allerdings bringt den Tab wieder zum Vorschein.

Momentan habe ich ein 12/7er der das Verhalten zeigt, den anderen konnte ich mit dem Cache leeren "reparieren"

Grüße
Marcel

[Thorsten Pferdekaemper]

getConfig hatte ich gestern bereits getestet und das brachte keine Besserung. Das hatte ich durchgeführt als keine weiteren Seiten offen waren. Das leeren des Caches allerdings bringt den Tab wieder zum Vorschein.

Das ist jetzt etwas seltsam, da getConfig den Cache auch leert, außer das Gerät antwortet nicht. Dann dürfte aber configStatus nicht auf OK gehen. Außerdem müsste bei state RESPONSE_TIMEOUT stehen.

Momentan habe ich ein 12/7er der das Verhalten zeigt, den anderen konnte ich mit dem Cache leeren "reparieren"

...und der 12/7er lässt sich nicht per Leeren des Cache reparieren?

Gruß,
   Thorsten

[Lonie]

Das ist jetzt etwas seltsam, da getConfig den Cache auch leert, außer das Gerät antwortet nicht. Dann dürfte aber configStatus nicht auf OK gehen. Außerdem müsste bei state RESPONSE_TIMEOUT stehen.

Ich habe jetzt mal den Cache bei meinen beiden 12/7er gelöscht (die peerings wurden angezeigt) und anschließend bei jedem ein getConfig durchgeführt. Ergebnis war dass danach im jeweiligen Device der Tab nicht mehr vorhanden ist. Ich mache mir langsam Gedanken dass auf meinem System irgendwo ein Fehler ist, anscheinend hat das Problem ja sonst keiner.

...und der 12/7er lässt sich nicht per Leeren des Cache reparieren?

doch, doch. Ich hatte ihn nur noch gelassen um ein Device zu haben aus dem man eventuell zusätzliche Informationen rausziehen kann.

Grüße
Marcel

[Thorsten Pferdekaemper]

Ich habe jetzt mal den Cache bei meinen beiden 12/7er gelöscht (die peerings wurden angezeigt) und anschließend bei jedem ein getConfig durchgeführt. Ergebnis war dass danach im jeweiligen Device der Tab nicht mehr vorhanden ist.

Das ist wirklich seltsam. D.h. Du kannst das mit dem Vorgehen sicher nachvollziehen, oder es passiert nur manchmal?

Ich mache mir langsam Gedanken dass auf meinem System irgendwo ein Fehler ist, anscheinend hat das Problem ja sonst keiner.

...oder Du machst etwas ein ganz klein bisschen anders. ...oder es kommt auf eine ganz bestimmte Kombination von Parametern an. Das ist alles schon vorgekommen.

Vielleicht machen wir das mal so: Ich werde heute Abend oder so eine Änderung einbauen, die zumindest den Fehler laut meiner Vermutung repariert. Danach kannst Du nochmal probieren, ob Du das Problem nachvollziehen kannst.

Gruß,
   Thorsten

[Lonie]

Ich kann das Verhalten sicher reproduzieren. Natürlich kann es auch an irgendetwas anderem liegen allerdings ist der peering tab zuverlässig nach einem getConfig weg. Merkwürdigerweise wird er trotzdem noch angezeigt wenn der Sensor/Aktor 2 peerings besitzt. Das nutze ich wenn ein Sensor abhängig von langem/kurzen Tastendruck verschiedene Aktoren schalten soll. Eventuell könnte man hier auch ansetzen. Leider bin ich da grad erst drauf gekommen.

Grüße
Marcel

[Thorsten Pferdekaemper]

Hi Lonie,
ich habe jetzt mal das korrigiert, was ich nachvollziehen konnte. Könntest Du Dir nochmal die neuste Version holen und testen?
Gruß,
   Thorsten

[Lonie]

Hi Thorsten,

mittels getConfig kann ich es nicht mehr nachstellen Ich würde das mal so laufen lassen und im Auge behalten. Danke für deinen flotten Fix


PS: Ich hätte noch einen HMW_SEN_SC_12_DR der eigentlich ein FM ist welcher Probleme bereitet. bei einem Notify auf einen Ausgang eines 12/7er sorgt er in ~50% der Fälle ein Response Timeout desselben. Dummys schaltet er jedoch problemlos. Eigentlich sollte an der Stelle ein HMW-IO-12-FM aber die gibts leider nicht mehr. Eventuell ersetz ich ihn auch einfach durch ein HBW Gerät zwecks peerings.
Wär dafür ein eigener Thread angebracht oder soll ich eine Fehlerbeschreibung hier verewigen?


Grüße
Marcel

[Thorsten Pferdekaemper]

PS: Ich hätte noch einen HMW_SEN_SC_12_DR der eigentlich ein FM ist welcher Probleme bereitet. bei einem Notify auf einen Ausgang eines 12/7er sorgt er in ~50% der Fälle ein Response Timeout desselben. Dummys schaltet er jedoch problemlos. Eigentlich sollte an der Stelle ein HMW-IO-12-FM aber die gibts leider nicht mehr. Eventuell ersetz ich ihn auch einfach durch ein HBW Gerät zwecks peerings.
Wär dafür ein eigener Thread angebracht oder soll ich eine Fehlerbeschreibung hier verewigen?

Ein neuer Thread wäre besser, dann gleich mit einer etwas ausführlicheren Beschreibung, d.h. welches Gateway sowie list des notify und der beteiligten Devices und Kanäle.
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,
ich habe gerade die neue HM485-Version zur master-Version gemacht.
Den v0800-Branch gibt es nicht mehr, als auf jeden Fall "update list" ändern.
Gruß,
   Thorsten