[gelöst] Fehler 'Unknown argument displayWM' beim Homematic Display HM-Dis-WM55

[Beta-User]

@huntsman: Kannst du mir noch einfach die Code-Auszüge aus deiner CUL_HM-Version dazupacken? Bei mir ist schon wieder alles anders...

[...] nur die ganze Logik zur Steuerung habe ich manuell dazugefügt. An den Attributen der Devices habe ich eigentlich nicht manuell rumgespielt, außer z.B die Zuordnung zu Räumen...

"nur" ist relativ, und es gibt wirklich keinen Grund, direkt in der cfg rumzumalen (ich könnte das auf dem Echt-System nicht mal und vermisse es auch nicht). Geht alles (ggf. via devspec) über FHEMWEB schneller (und bei configdb gibt's dann auch noch einen direkt implementierten search-Befehl).

Neulich hatte ich die commandref in einem Modul überarbeitet. Aus irgendeinem Grund wollte FHEMWEB die aber nicht anzeigen. Der Grund war schlicht: Windows-Zeilenumbruch statt Unix-style. In beiden Editoren (Kate, notepad++) in der normalen Anzeige nicht zu erkennen... Also einfache Regel: Finger weg!

[Beta-User]

@beta-user
warum sind hier beide attribute vorhanden?

Code Auswählen Erweitern

attr Display IODev CUL_0
attr Display IOgrp vccu:CUL_0

...du kannst aber Fragen stellen... (woher soll ich das wissen ...)

Vermutlich, weil der Prüfungsmechanismus bei der Attributeingabe nicht greift, wenn man die cfg editiert (oder eben schon eine alte hat, nach der das möglich war).

Die implizite Aufforderung scheint zu sein: IODev-Attribut löschen, wenn IOgrp gesetzt ist?


Wenn wir es grade von Merkwürdigkeiten haben: Im Moment kann man bei allen virtuellen Kanälen ja "alles" setzen, weil .AttrList fehlt. "vermutlich" haben wir die Stelle ja jetzt identifiziert, an der man der Freiheit ein Ende setzen könnte. Mal sehen, erst sollte der in der angehängten Zwischenversion geänderte Ablauf getestet sein - meine virtuellen Sensoren sind überwiegend im Takt geblieben/wieder eingefangen, von daher bin ich optimistisch...

PS:  configCheck -f habe ich nur noch zwei im Log - warum auch immer (es ist aber nachvollziehbar, warum es grade diese Geräte sind die auftauchen) - positives Voodoo, oder?

[frank]

du kannst aber Fragen stellen

ich dachte, du hattest es nicht bemerkt. 

bei mir wurden alle attr IODev durch den start der ersten cul_hm version mit attrcheck (aktuelle svn version) gelôscht.
wenn du es nicht ausgebaut hast, sollte es noch existieren.
ausnahme: bei meinem device, dass IOgrp mit none besass, wurde attr IODev auch nicht gelöscht. das ist nach reparatur jetzt aber passiert.

huntsman hat auch noch einen erfolglosen restart nachgelegt. vielleicht stört die existenz von modelForce?

[Beta-User]

...das mit .AttrList war eher einer der Brücken von denen ich dachte, dass es erst Sinn macht, davon runterspringen zu wollen, wenn man draufsteht ... Bevor ich die codemäßig überhaupt in Sicht bekommen hatte, war das nur was für "merke ich mir für irgendwann" .

Jetzt hat es zumindest in meinen Vorstellungen vom Gesamtablauf einen Ort, wo ich es hinpacken kann - und schon erscheint es lösbar und nicht mehr rätselhaftes Voodoo .


Bzgl. IODev: Ich hatte das manuell gelöscht (zeitnah zu der Änderung von fhem.pl/DevIo) weil ich wissen wollte, ob es Probleme macht und von daher hatte das für mich erst mal keine praktische Relevanz mehr. _Glaube_ nicht, es ausgebaut zu haben, aber IOList bei der VCCU anzufassen nach $init_done könnte schon solche "Nebenwirkungen" (mit Absicht) verursacht haben. Wie auch immer: kommt auf meine Liste .

Da ich komplett den Überblick verloren habe: ist dann noch was offen, wenn die beiden Punkte erledigt wären?


Bestimmt übersehe ich was, aber wo ist der nachgelegte "erfolglose restart"?
Mein Verständnis von modelForce: Wenn es da ist, hilft es, "model" gradezuziehen. Sobald das in model paßt, ist es nicht mehr erforderlich, stört aber auch nicht direkt (außer man ist so ein Extremist wie meinereiner, bei dem weg muss, was man nicht unbedingt braucht und was potentiell zu Mißverstänsnissen oder Fehlern führen könnte ...)


Mein "getimerter" Umbau aus dem letzten Post hier hat auch die letzten RT's eingefangen. Von daher würde ich die bei Vorliegen einer qualifizierten Zweitmeinung wieder zur aktuellen Patchversion erklären (vermutlich aber erst morgen Abend, falls ich dazu komme, mind. einen der obigen Punkte abzuhaken). 

[frank]

Bestimmt übersehe ich was, aber wo ist der nachgelegte "erfolglose restart"?

antwort #14. da gibt es auch warnings zu sehen.
https://forum.fhem.de/index.php/topic,123257.msg1178290.html#msg1178290

[Beta-User]

Das RAW-list hätte ich als erfolgreich gewertet:

Code Auswählen Erweitern

attr Display .mId 00D3Im list sieht man die versteckten Internals etc. nicht, attr global showInternalValues dürfte nicht gesetzt sein.

Die "uninitialized" habe ich gesehen und um den passenden Code gebeten, sonst muss ich kramen, was das in welcher Fassung war; würde auf was anders tippen. Eine "unknown argument"-Warnung hätte huntsman doch ausdrücklich erwähnt, oder?

[frank]

aber attr IODev existiert weiterhin und sowohl helper/io/vccu als auch helper/io/prefio wurden nicht gefüllt.

[Beta-User]

Vorab: Die Zeilen sind identifiziert, da scheint "CUL_HM_SetList()" zu früh bzw. für ein nicht existierendes Device aufgerufen worden zu sein. Muss auf die "für später"-Liste.

aber attr IODev existiert weiterhin und sowohl helper/io/vccu als auch helper/io/prefio wurden nicht gefüllt.

Jetzt "muss" erst mal IODev weg, falls "doppelt", dann geht's ggf. weiter .

[Beta-User]

Vorab: Die Zeilen sind identifiziert, da scheint "CUL_HM_SetList()" zu früh bzw. für ein nicht existierendes Device aufgerufen worden zu sein. Muss auf die "für später"-Liste.

Zumindest ein Pflaster hat es gereicht, wobei ich unschlüssig bin, ob das eine gute Idee ist - besser wäre es, die eigentliche Ursache zu finden.

Jetzt "muss" erst mal IODev weg, falls "doppelt", dann geht's ggf. weiter .

Das ist jetzt mit der Fassung im Anhang weg, auch wenn die Frage offen bleibt, wieso das ein Problem war. Auf meinem Testsystem wurden helper/io/vccu und helper/io/prefio nämlich auch dann gefunden, wenn beides in der cfg vorhanden war. Evtl. ist an dem System von @huntsman was anders (Perl, OS, ...).

.AttrList ist jetzt auch in den virtuellen Kanälen vorhanden, cmds/cmdList fühlt sich aber jedenfalls bei den virtuellen Channels noch nicht optimal an.

Ad:

only for interest.

"none" ist wieder in der io/prefIO-Liste drin, allerdings ist mir auch unklar, wie das im weiteren Verlauf gehandhabt wird. Den vorhandenen Code würde ich deuten als: notfalls nimm irgendwas, wenn vorher nichts gefunden werden konnte... Müßte man nachfragen, ob das bewußt entfallen ist.

Betr. "restoredIO" finde ich zum einen die Abhängigkeit von einem rechtzeitigen Define des TSCUL-IO-Geräts irritierend, aber das scheint nicht anders zu gehen. Generell wundert sich der Novize, warum das alles unbedingt direkt in DefFn sein muss, aber da haben sich ein paar andere wohl schon mehr als einmal die Köpfe zerbrochen.
Die Frage, die sich m.E. in dem ganzen Zusammenhang noch stellt: Wie wäre es sei denn, man würde die initialen Inhalte wichtiger helper-(usw.-) Elemente anders wegschreiben, z.B. in ein Reading im Rahmen einer ShutdownFn?
Dann bräuchte man nicht "krampfhaft" versuchen, auch noch die Reihenfolge der Defines aufeinander abzustimmen, sondern könnte "ganz bequem" und (ganz oder teilweise) auch auf timer-Basis nach dem ersten Durchlauf dann checken, ob der letzte Zustand jeweils noch gültig wäre und ihn dann (nach und nach?) wiederherstellen (indem sich jede "Stufe" das rauspickt, was es benötigt und dann dort löscht?).

Noch unklar ist mir grade, ob z.B. das Setzen bestimmter Attribute im Rahmen von INITIALITZED dann dazu führt, dass Befehle an IO's gehen, die dazu noch nicht bereit sind. Ggf. müßte man dann ein "set_delayed"-Argument in CUL_HM_Attr() vorsehen, das das verhindert (ich denke v.a. an #255, "CUL_HM_Attr("set",$name,"IOgrp",AttrVal($name,"IOgrp","")) if ...").

Aber wie meistens: vermutlich ist das alles schon 100x überdacht und verworfen worden zugunsten besserer Ideen ...

[frank]

meine virtuellen chn haben jetzt auch .AttrList
bisher keine auffälligkeiten.

Evtl. ist an dem System von @huntsman was anders (Perl, OS, ...).

er hat kein hminfo

[Beta-User]

er hat kein hminfo

Das "fehlt" in meinem Testsystem auch . Tippe weiter auf was anderes.

meine virtuellen chn haben jetzt auch .AttrList
bisher keine auffälligkeiten.

Puh, schon mal was!

Grade versuche ich den Patch von noansi auf 24374 auszuwerten. Wie üblich verstehe ich bei einem Teil erst mal nur "Bahnhof", aber auch da läuft einiges darauf hinaus, die wesentlichen Attribute spätestens bei INITIALIZED ausgewertet zu haben - es steht nur jetzt alles woanders...
Mit etwas Glück bekommt man damit aber die "preferedIO"-Zuweisung wieder verbessert (Rückschläge sind aber leider nicht unwahrscheinlich)...

[frank]

Tippe weiter auf was anderes.

was, wenn huntsman nur reload gemacht hat?

[huntsman]

was, wenn huntsman nur reload gemacht hat?

Nee, hatte neu gebootet

[huntsman]

modelForce habe ich entfernt und da model jetzt auch in Großschrift ist läuft es weiterhin

Code Auswählen Erweitern

define Display CUL_HM 6D72EC
attr Display .mId 00D3
attr Display IODev CUL_0
attr Display IOgrp vccu:CUL_0
attr Display autoReadReg 4_reqStatus
attr Display expert defReg,rawReg
attr Display firmware 1.0
attr Display model HM-DIS-WM55
attr Display msgRepeat 3
attr Display room CUL_HM
attr Display serialNr QEQ0294715
attr Display subType display
attr Display webCmd getConfig:clear msgEvents

setstate Display CMDs_done
setstate Display 2021-10-08 19:38:53 .associatedWith Display,HM_6D72EC_Dis_01,HM_6D72EC_Dis_02,HM_6D72EC_Dis_03,HM_6D72EC_Dis_04,HM_6D72EC_Dis_05,HM_6D72EC_Dis_06,HM_6D72EC_Dis_07,HM_6D72EC_Dis_08,HM_6D72EC_Dis_09,HM_6D72EC_Dis_10,Display
setstate Display 2021-10-12 13:13:49 .protLastRcv 20211012131349
setstate Display 2021-10-12 13:13:49 CommandAccepted yes
setstate Display 2021-09-21 15:42:38 D-firmware 1.0
setstate Display 2021-09-21 15:42:38 D-serialNr QEQ0294715
setstate Display 2021-10-12 13:13:47 IODev CUL_0
setstate Display 2021-10-12 13:13:48 battery ok
setstate Display 2021-10-12 13:13:49 commState CMDs_done
setstate Display 2021-10-12 13:13:49 state CMDs_done

[huntsman]

@Beta-User

@huntsman: Kannst du mir noch einfach die Code-Auszüge aus deiner CUL_HM-Version dazupacken? Bei mir ist schon wieder alles anders..

meinst Du das, oder hat sich das schon erledigt?

Code Auswählen Erweitern

Internals:
   CMDS       BCFiAZEGMKURTVWXefmltux
   CUL_0_MSGCNT 8917
   CUL_0_TIME 2021-10-12 20:34:58
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyACM0@9600 1034
   DeviceName /dev/ttyACM0@9600
   FD         4
   FHTID      1034
   FUUID      615ca1b9-f33f-9964-05e3-3bc9d1b9d52becf6
   NAME       CUL_0
   NR         55
   NR_CMD_LAST_H 5
   PARTIAL   
   RAWMSG     A0C71A64150F153AFFE98017064E9
   RSSI       -85.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.58 CUL868
   devioNoSTATE 1
   initString X21
Ar
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2021-10-09 18:39:36   cmds             B C F i A Z E G M K U R T V W X e f m l t u x
     2021-10-12 18:42:30   raw             is00FFFFFF0FF0
     2021-10-12 20:34:58   state           Initialized
   XMIT_TIME:
     1634062023.21297
     1634063697.57771
     1634063697.67797
     1634063698.07548
     1634063698.1757
   helper:
     29CFCE:
       QUEUE:
     29CFE4:
       QUEUE:
     29CFEB:
       QUEUE:
     29CFF0:
       QUEUE:
     2D068E:
       QUEUE:
     3739E9:
       QUEUE:
     379E86:
       QUEUE:
     3BAE3B:
       QUEUE:
     50EE48:
       QUEUE:
     50F014:
       QUEUE:
     50F153:
       QUEUE:
     6D72EC:
       QUEUE:
Attributes:
   hmId       AFFE98
   rfmode     HomeMatic
   verbose    2