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:
set Jalousie_KG_Kontor regSet shOnLevel 100 Jalousie_Timeclock_SwitchTr
Meldung im Log:
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
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
Deine Erklärung klingt plausibel, aber bei mir kommt im Log
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.
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)
set Jalousie_KG_Kontor regSet shOnLevel 100.5 Jalousie_Timeclock_SwitchTr;
ergibt im Log
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
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?
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
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
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:
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:
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.
Nie aufgelöst :D -> https://forum.fhem.de/index.php/topic,69044.msg605246.html#msg605246
Aber der gleiche Fall ;D ???
Gruß Otto
So, jetzt kommt's:
Ich habe mal spasseshalber in meinem Aktor gesetzt (die Grenzen könnten vertauscht sein, weil ich levelInverse nutze):
attr Terrassendachmarkise eventMap on:100 off:0
und bekomme bei set Terrassendachmarkise regSet shOnLevel 100 FB12_Btn_11
den Fehler
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
2018.06.19 12:58:54 3: CUL_HM set Terrassendachmarkise regSet shOnLevel 100 FB12_Btn_11
Also: hattu eventMap und wenn ja welches?
ZitatNie aufgelöst :D -> https://forum.fhem.de/index.php/topic,69044.msg605246.html#msg605246
Aber der gleiche Fall ;D ???
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.
eventMap on:100 off:0eventMap 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
Alle Hochachtung genialer Gedankengang mit Volltreffer! :D
eventMap ist völlig neutral denke ich, der weiß nichts von Registern...
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 ;D
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
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.
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.