[gelöst]BUG im Befehl set name regset shOnLevel 100 Peer ?

pwlr · 19 Juni 2018, 00:58:59

Moin,
es gelingt mir nicht mehr, das Register shOnLevel eines Peers von einem HM-LC-BL1-FM auf 100 zu setzen.
Status:
shOnLevel des Peers steht auf einem Wert <> 100(%) - zum Beispiel 0(%)
Befehl:

Code Auswählen

set Jalousie_KG_Kontor regSet shOnLevel 100 Jalousie_Timeclock_SwitchTr
Meldung im Log:

Code Auswählen

2018.06.19 00:34:40 1: PERL WARNING: Argument "on" isn't numeric in numeric lt (<) at ./FHEM/10_CUL_HM.pm line 4595.
2018.06.19 00:34:40 3: CUL_HM set Jalousie_KG_Kontor regSet shOnLevel on Jalousie_Timeclock_SwitchTr

Irgendwie scheint da der Wert 100 in on übersetzt zu werden. Die erste Meldung von PERL kommt nicht immer.
Im fhem sieht das Register dann so aus

Code Auswählen

2018-06-19 00:41:22 R-Jalousie_Timeclock_SwitchTr-shOnLevel set_0 %
Alle anderen Werte bis 99 funktionieren.

BUG oder mache ich etwas falsch ?
Moin
Bernd

Pfriemler · 19 Juni 2018, 08:17:14

Deine Erklärung klingt plausibel, aber bei mir kommt im Log

Code Auswählen

2018.06.19 08:13:55 3: CUL_HM set Terrassendachmarkise regSet shOnLevel 100 FB12_Btn_11
Stand aber vorher schon auf 100.

Edit: hier 10_CUL_HM.pm 16588 2018-04-11 18:21:53Z martinp876
~~EventMap dürfte bei regSet auch keine Rolle spielen.~~ tut es offenbar doch, siehe weiter unten.

pwlr · 19 Juni 2018, 11:15:00

Moin,
hab gestern vor dieser Fehlermeldung einen Update gefahren
10_CUL_HM.pm 16838 2018-06-09 05:15:46Z martinp876 $

Versuch heute mit dem Befehl (obwohl ich diesen max-Wert von 100.5 nie verstanden habe)

Code Auswählen

set Jalousie_KG_Kontor regSet shOnLevel 100.5 Jalousie_Timeclock_SwitchTr;

ergibt im Log

Code Auswählen

2018.06.19 11:04:43 1: PERL WARNING: Argument "on.5" isn't numeric in numeric lt (<) at ./FHEM/10_CUL_HM.pm line 4595.
2018.06.19 11:04:43 3: CUL_HM set Jalousie_KG_Kontor regSet shOnLevel on.5 Jalousie_Timeclock_SwitchTr

und im Device wird dann wieder vom alten Wert 99% in 0% geändert. Also im Prinzip genau wie bei set 100
Also lass mal Deine Terrassendachmarkise schön auf 100 stehen...

Moin
Bernd

Pfriemler · 19 Juni 2018, 11:22:54

100.5 entspricht "old level". Wird dieser Wert bei Dimmern als shOnLevel gesetzt, so schaltet der Dimmer bei einem Einschaltbefehl vom entsprechenden peer nicht auf 100%, sondern auf die zuletzt gedimmte Position vor dem letzten Ausschalten. Bei Rolladenaktor würde das der Position entsprechen.

Kannst Du mal ein Backup zurückspielen und schauen, ob es den Fehler da schon gab?

pwlr · 19 Juni 2018, 12:00:39

Danke für die Info zu den 100.5%

ZitatKannst Du mal ein Backup zurückspielen und schauen, ob es den Fehler da schon gab?

Also, das ist nicht meine Stärke... Habe mal im Raspi geschaut unter fhem/restoreDir/update -> da stehen doch die alten Versionen vor den Updates - oder ?
Ich habe aktuell 10_CUL_HM.pm 16838 2018-06-09 05:15:46Z martinp876 $
und davor $Id: 10_CUL_HM.pm 16588 2018-04-11 18:21:53Z martinp876 $

Kann ich die 16588 einfach in das Wirksystem kopieren und dann neu starten ? Und würden dann mit einem weiteren Update später wieder die 16838 (oder ggf. eine neuere) reinkommen? Will mir das System nicht zerschießen - ist zu groß und gibt Ärger mit der besten Ehefrau von allen

Moin
Bernd

Otto123 · 19 Juni 2018, 12:07:25

Hallo Bernd,

Du kannst das relativ ungefährlich direkt mit dem restore Befehl zurück holen.
https://commandref.fhem.de/#restore

Zur eigentlichen Frage, irgendwie kommt mir das bekannt vor: war da schon mal was?

Gruß Otto

Pfriemler · 19 Juni 2018, 12:23:02

Ein paar Basics:
a) Restore ist natürlich die beste Variante.
b) Einkopieren und neustarten geht auch.
c) Einkopieren und "reload 10_CUL_HM.pm" reicht auch.
d) Natürlich wird das Modul bei jedem Update durch die neueste Variante ersetzt.
e) Du kannst das Update für einzelne Module ausschließen, die Du im Global-Device (ist immer angelegt) per Attribut einträgst, etwa so:

Code Auswählen

attr global exclude_from_update 87_WS2000.pm 14_CUL_WS.pm

Hier sind das bspw. von mir modifizierte Module für (alte) Wettersensoren

Final aber wird Martin (hoffentlich) den Fehler finden und fixen und dann steht einem Update nichts mehr im Weg. Sowas kommt immer mal wieder vor, wird aber in der Regel in wenigen Tagen gefixt.

@Otto123: mir ist nichts erinnerlich.

Edit: Was ich jetzt nicht verstehe: Die Änderungen von der alten 16588 (linke Spalte) zur 16886 sind marginal und sollten das eigentlich nicht betreffen:

Code Auswählen

my $cndNo;
5947	5947	    if ($cond =~ m/[+-]?\d+/){
5948	 	      return "condition value:$cond above 200 illegal" if ($cond > 200);
 	5948	      return "condition value:$cond above 255 illegal" if ($cond > 255);
5949	5949	      $cndNo = $cond;
5950	5950	    }
... 	... 	 
5970	5970	        }
5971	5971	      }
5972	 	      return "cond:$cond not allowed. choose one of:[0..200],"
 	5972	      return "cond:$cond not allowed. choose one of:[0..255],"
5973	5973	            .join(",",sort @keys)
5974	5974	        if (!defined $cndNo);

Hinweis: Die Versionsnummern gelten global für alle FHEM-Änderungen. Zwischen zwei Moduländerungen können also durchaus wie hier >100 Zähler liegen.

Ich fürchte, das restore bringt also nichts und das Problem liegt woanders. Aber Versuch macht kluch.

Otto123 · 19 Juni 2018, 12:52:45

Nie aufgelöst

-> https://forum.fhem.de/index.php/topic,69044.msg605246.html#msg605246

Aber der gleiche Fall

Gruß Otto

Pfriemler · 19 Juni 2018, 12:59:55

So, jetzt kommt's:

Ich habe mal spasseshalber in meinem Aktor gesetzt (die Grenzen könnten vertauscht sein, weil ich levelInverse nutze):

Code Auswählen

attr Terrassendachmarkise eventMap on:100 off:0

und bekomme bei

Code Auswählen

set Terrassendachmarkise regSet shOnLevel 100 FB12_Btn_11

den Fehler

Code Auswählen

2018.06.19 12:55:41 1: PERL WARNING: Argument "on" isn't numeric in numeric lt (<) at ./FHEM/10_CUL_HM.pm line 4592.
2018.06.19 12:55:41 3: CUL_HM set Terrassendachmarkise regSet shOnLevel on FB12_Btn_11

Ohne das eventMap isses wieder

Code Auswählen

2018.06.19 12:58:54 3: CUL_HM set Terrassendachmarkise regSet shOnLevel 100 FB12_Btn_11

Also: hattu eventMap und wenn ja welches?

pwlr · 19 Juni 2018, 13:17:50

ZitatNie aufgelöst -> https://forum.fhem.de/index.php/topic,69044.msg605246.html#msg605246

Aber der gleiche Fall

und denn auch noch von mir - hab ich vergessen

Also mal der Reihe nach - danke für die Infos zu restore, hab ich begriffen und gemacht. Fehler ist unverändert - klar, siehe weiter unten.

Code Auswählen

eventMap on:100 off:0

eventMap rausgenommen und siehe da, shOnLevel lässt sich brav auf 100 setzen !

wer die CommandRef lesen kann ist klar im Vorteil:

ZitateventMap
Replace event names and set arguments.

bei set name on usw. war mir das klar, aber ist das auch bei den Registerinhalten so gewollt ?
Finde ich eigentlich nicht richtig..
Ist das jetzt ein Fehler beim eventMap-Handling ?

Danke für Eure Hilfe !
Bernd

Otto123 · 19 Juni 2018, 14:01:17

Alle Hochachtung genialer Gedankengang mit Volltreffer!

eventMap ist völlig neutral denke ich, der weiß nichts von Registern...

Pfriemler · 19 Juni 2018, 15:01:50

pwlr war ja selbst auf der richtigen Spur: "Irgendwas hat ..."

Ich war stillschweigend - aber warum eigentlich - auch davon ausgegangen, dass regSet Argumente nicht anfässt. Die Übersetzung a la eventMap findet offenbar weiter oben statt, dafür müsste man gezielt Ausnahmen erlauben.
Das wird ein jahrelanger Diskussionsprozess

pwlr · 19 Juni 2018, 22:09:54

ok,

ich fasse mal zusammen, für später

Das von mir beschriebene Verhalten beim regset shOnLevel 100 stellt keinen Fehler dar, sondern wird durch das attr eventMap ausgelöst. Bei der von mir genutzten eventMap

ZitateventMap on:100 off:0

wird also der Wert "100" gegen "on" ersetzt und führt zu dem geschilderten Verhalten.

siehe Commandref

ZitatReplace event names and set arguments. The value of this attribute consists of a list of space separated values, each value is a colon separated pair. The first part specifies the "old" value, the second the new/desired value.

Allerdings lese ich die Commandref so, dass (mit meiner eventMap) zwar "on" gegen "100" ersetzt werden würde, aber nicht anders herum.

Mein Fazit : alle eventMaps wegrationalisiert und nun funktioniert auch der regBulk wieder

Danke an Pfriemler und Otto123 für Eure Hilfe - allein wär ich nicht darauf gekommen !

Moin
Bernd

Pfriemler · 19 Juni 2018, 22:33:22

eventMap funktioniert durchaus beabsichtigt andersherum.
"on:100" bedeutet, dass ein vom Gerät erzeugtes Event mit "on" in FHEM mit "100" dargestellt wird - gut für Slider, die auf state arbeiten (man nutzt dafür aber lieber pct oder position).
Umgekehrt bedeutet das aber auch, dass ein abgeschicktes "100" von FHEM auf "on" übersetzt wird. Genau das ist passiert.
Wie auch bei einem Switch, wo "on:an off:aus" bedeutet, dass als Status immer "an" oder "aus gezeigt wird und im Webinterface der Befehl "an" auf "on" rückübersetzt wird, bevor er an den Aktor geht.

pwlr · 19 Juni 2018, 23:21:26

Moin,

ja, das ist passiert - aber wenn es gewollt ist, gibt es dann nicht ein Dokuproblem?

ZitatThe first part specifies the "old" value, the second the new/desired value.

ZitatWie auch bei einem Switch, wo "on:an off:aus" bedeutet, dass als Status immer "an" oder "aus gezeigt wird und im Webinterface der Befehl "an" auf "on" rückübersetzt wird, bevor er an den Aktor geht

Das ist sinnvoll, aber in der Doku so nicht beschrieben.