1: Error: >HM_TC_Mansarde_chn-05< has no TYPE, but following keys: ><

[Tommi ratlos]

Hallo zusammen,

bei meinem neuen HM-TC-IT-WM-W-EU kommt beim Absetzen von

Code Auswählen Erweitern

set HM_TC_Mansarde_Climate controlMode manual
die Meldung

Code Auswählen Erweitern

Error: >HM_TC_Mansarde_chn-05< has no TYPE, but following keys: ><
Es scheint aber alles zu funktionieren.
Stutzig macht mich chn-05 bezieht sich das auf channel_05? Den gibt es bei einem HM-TC-IT-WM-W-EU aber nicht.

Gruß
Thomas

[MadMax-FHEM]

Ist wohl mit den Änderungen vom 16.01. passiert...

Hätte ich mal gesucht, wäre ich schon vor dem Schreiben hierauf gestoßen, Schande... 

Soll heißen: mir ist ähnliches aufgefallen https://forum.fhem.de/index.php?topic=118087.msg1125159#msg1125159

Mal sehen, Joachim

[betateilchen]

Die Meldung steht bei mir auch im Log, mich verwundert sie nur deshalb, weil es in dem zugehörigen TC nur die Channels 1-3 und 6-7 gibt.

Davon abgesehen, wäre ein deviceName mit einem Bindestrich im Namen unzulässig.

[betateilchen]

Der Fehler kommt vermutlich aus dem Umbau auf CUL_HM_getPeers()

Code Auswählen Erweitern

DEBUG>name: wz_TC_chn-05 :type: IDs

Beispielsweise ist hier:

Code Auswählen Erweitern


sub CUL_HM_getPeers($$)   { #return peering information - status and lists
   my ($name,$type) = @_;
   my $hashH = $defs{$name}{helper};
   return () if(!defined $name || !defined $defs{$name}{DEF});


die Reihenfolge der Prüfung auf die Existenz zu spät.

Das "return() .." müsste auf jeden Fall VOR der Zuweisung von Werten aus %defs erfolgen, weil im Falle der Nichtexistenz des in $name enthaltenen Namen (wz_TC_chn-05) ein Eintrag mit diesem Namen im hash %defs angelegt wird, der allerdings kein device ist.

Die Fehlemeldung

Code Auswählen Erweitern

Error: >wz_TC_chn-05< has no TYPE, but following keys: ><

kommt dann aus einem in der weiteren Verarbeitung ausgeführten devspec2array(), das das fehlerhafte "device" bemängelt.

Es reicht allerdings nicht, die Reihenfolge der oben genannten zwei Zeilen einfach zu vertauschen (return vor der Zuweisung), danach taucht der Fehler immer noch auf.
Es muss also noch weitere Stellen geben, in denen der gleiche Fehler im Code steckt. Aber zum Weitersuchen hatte ich jetzt keine Lust.

Vielleicht hilft diese Kurzanalyse ja ein bisschen bei der Fehlerbeseitigung

[MadMax-FHEM]

Danke für die weitere Analyse...

Das mit den Channel-Nummern (1-3 und 6-7) hatte ich auch bemerkt und erst gedacht vielleicht ist da was passiert.
Weil ich eigentlich fest der Meinung war es war (mal): 1-5

Aber ist wohl mindestens seit 2018 schon 1-3 und 6-7...

Hatte auch schon überlegt einen diff zwischen Mitte Dezember und der Version jetzt Mitte Januar zu machen...
...weil es laut meinem Log in der Zeit bzw. mit der Version vom 16.01. passiert sein müsste...

Aber aktuell leider andere Baustellen und da es bis auf die Meldung im Log ja tut auch nicht die höchste Prio...

Mal sehen was Martin dazu sagt...

Gruß, Joachim

[betateilchen]

...weil es laut meinem Log in der Zeit bzw. mit der Version vom 16.01. passiert sein müsste...

natürlich ist es mit der Version vom 16.01. passiert, das hatte ich doch oben schon geschrieben

Der Fehler kommt vermutlich aus dem Umbau auf CUL_HM_getPeers()

Der Umbau war eine ziemlich umfangreiche Baustelle, da kann man sowas schonmal übersehen.

[MadMax-FHEM]

natürlich ist es mit der Version vom 16.01. passiert, das hatte ich doch oben schon geschrieben

Nein hattest DU nicht, ich hab es (leider) 2x geschrieben: sorry dafür!
EDIT: nur mit welchem Umbau es wohl passiert ist. Also "indirekt" vielleicht... ABER: führt das zu was, wenn man es anmerkt? (selbst wenn es so gewesen wäre) Aber erneut: egal...

Egal, Joachim

[betateilchen]

Sorry, die Möglichkeit, selbst im change log nachzusehen, welche Änderung am 16.01. passiert ist, hatte ich als bekannt vorausgesetzt.
Vermutlich war das mein Fehler 

[FSausF]

Moin Loide,

gibt es bei der Geschichte eigentlich schon irgendwie Rauchzeichen am Horizont?
Irgendeinen Workaround?

Ich hab' nämlich vier von den Teilen am Start.
Und die ballern mir trotz Verbose=0 das Log zu, Größenordnung 360 Zeilen pro Stunde.
Dabei wechseln sie sich gerne mal ab. So etwa alle 90 Minuten bis zwei Stunden.
Das macht das Log erstens recht groß und zweitens schwer lesbar.
Das ist schade, denn ich hätte noch ein, zwei andere Baustellen...

Bin da nicht so firm. Kann man irgendwie einstellen, dass dieser Fehler nicht ins Log geht?

Danke für Eure Ideen,

FSausF

[betateilchen]

gibt es bei der Geschichte eigentlich schon irgendwie Rauchzeichen am Horizont?
Irgendeinen Workaround?

Vielleicht mal dein FHEM updaten?

[FSausF]

Vielleicht mal dein FHEM updaten?

Au ja, das probiere ich.
Hier im Thread stand nix von wegen "Problem mit Update gelöst", sondern es klang eher nach "Entwickler hat grad' echt keine Zeit.".
Ich werde berichten, wie es lief...

[FSausF]

Vielleicht mal dein FHEM updaten?

Jepp, das sieht so aus als ob es tut!
Mir war aus dem Thread entgangen, dass der Fehler korrigiert wurde und es ein Update gab.

(Weil es aktuell ein, zwei Devices gibt, die noch ein wenig rumzicken, versuche ich, die Software drumherum eher seltener und nur punktuell zu ändern...)