Licht aus, an und dann dimmen

Begonnen von TWART016, 31 März 2020, 00:37:43

Vorheriges Thema - Nächstes Thema

frank

Zitat2021.02.23 16:01:41.234 0: HMLAN_Send:  HMLAN1 S:SCF690268 stat:  00 t:00000000 d:01 r:CF690268 m:83 A011 200DB8 617DE9 0201280320FFFF
bei dir wird aber eine default ramptime eingebaut.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Rockojfonzo

Ich hab jetzt mal in alle Register, die für mich halbwegs sinnvoll erscheinen, einen Wert eingetragen:


No regs found for:

Ball type:dimmer -
       self01                         
                       lg sh
ActionTypeDim toggleDim jmpToTarget
CtRampOff geLo geLo
CtRampOn geLo geLo
DimMaxLvl [%] 100 100
DimMinLvl [%] 0 0
DimStep [%] 90 90
RampOffTime [s] 0.5 0.5
RampOnTime [s] 5 5
RampSstep [%] 90 90
ActionTypeDim toggleDim jmpToTarget

Ja, bei einem pressS geht er schön langsam – auf 100%.
Aber bei einem "set Ball pct 10" oder "set Ball pct 70" geht es wieder ruckartig.
Ziel ist natürlich, dass auch bei Hoch- oder Runterdimmen über Web-Interface/Phone-App/Alexa/Taster(HM-PB-4DIS-WM) es sanft überblendet.
Das ging ja mal...
FHEM auf Shuttle XS 35V2 mit CUL und HM-LGW
9 x HM-CC-RT-DN; 2 x HM-LC-SW4-DR; 3 x HM-WDS30-OT2-SM; 3 x HM-SEC-SD; 1 x HM-LC-Bl1PBU-FM; 1 x HM-LC-SW1-PL2;1 x HM-LC-SW1-FM; 2 x HM-SEC-SC-2

Otto123

@Frank Dann habe ich die Zusammenhänge falsch verstanden  :-[ ich bewundere Dich ;)
Soll ich jetzt meine Versionen hier zum download anbieten? Oder ermitteln wie man die aus dem svn holt?
10_CUL_HM.pm    22022 2020-05-24 08:50:40Z martinp876
98_HMinfo.pm    21999 2020-05-22 11:05:41Z martinp876
HMConfig.pm     20888 2020-01-05 06:59:29Z martinp876
Und sagen wie man das schützt?
attr global exclude_from_update 10_CUL_HM.pm 98_HMinfo.pm HMConfig.pm
Sorry, ich bin da wirklich ratlos, ich verstehe auch wirklich nicht - warum man ein funktionierendes Modul (eines der größten in FHEM und mit Sicherheit nicht gerade wenig komplex) am Zeitpunkt der Einstellung jegliche Hardwareentwicklung seitens Hersteller, von den Füßen auf den Kopf stellen muss.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

besser wäre ein patch.  8)

ich denke mal laut:

cul_hm zeile 5409 wird scheinbar "unerwartet" ausgeführt:
      $rval = CUL_HM_encodeTime16((@a > 4)?$a[4]:2.5);# rampTime 0.0..85825945.6, 0=immediate
denn würde 2.5 an CUL_HM_encodeTime16 übergeben, käme der richtige wert zurück => "0320".

in CUL_HM_encodeTime16 wird auch das aktuelle warning in der return zeile erzeugt, wodurch die funktion dann "0000" zurückliefert:
sub CUL_HM_encodeTime16($) {####################
  my $v = shift;
  return "0000" if($v < 0.05 || $v !~ m/^[+-]?\d+(\.\d+)?$/);



2021.02.23 13:37:17.733 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at ./FHEM/10_CUL_HM.pm line 9027.
2021.02.23 13:37:17.734 1: stacktrace:
2021.02.23 13:37:17.735 1:     main::__ANON__                      called by ./FHEM/10_CUL_HM.pm (9027)
2021.02.23 13:37:17.735 1:     main::CUL_HM_encodeTime16           called by ./FHEM/10_CUL_HM.pm (5409)
2021.02.23 13:37:17.736 1:     main::CUL_HM_Set                    called by fhem.pl (3812)
2021.02.23 13:37:17.737 1:     main::CallFn                        called by fhem.pl (1918)
2021.02.23 13:37:17.737 1:     main::DoSet                         called by fhem.pl (1950)
2021.02.23 13:37:17.737 1:     main::CommandSet                    called by fhem.pl (1250)
2021.02.23 13:37:17.738 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2717)
2021.02.23 13:37:17.738 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (945)
2021.02.23 13:37:17.739 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (593)
2021.02.23 13:37:17.739 1:     main::FW_Read                       called by fhem.pl (3817)
2021.02.23 13:37:17.739 1:     main::CallFn                        called by fhem.pl (758)




mit dieser änderung der zeile 5409 kommt wieder die default ramptime und die warning ist weg:
      $rval = CUL_HM_encodeTime16(($a[4])?$a[4]:2.5);# rampTime 0.0..85825945.6, 0=immediate

2021.02.23 18:31:50.686 3 : CUL_HM set DimUP01 pct 20 
2021.02.23 18:31:50.753 0 : HMLAN_Send:  hmlan1 S:SCFF27BD6 stat:  00 t:00000000 d:01 r:CFF27BD6 m:EA A011 1ACE1F 1F64D8 0201280320FFFF
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Otto123

Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Pfriemler

#80
franks Patch hier nachgestellt: perfekte Funktion, und auch bei mir sind die Fehlermeldungen weg.

Mehr sag ich dazu jetzt mal nicht  :-X

BTW: Es hagelt inzwischen so dermaßen viele Fehlermeldungen bei mir ständig, dass ich mit dem Debuggen schon aufgehört habe. Es gibt jeden Tag ein neues Logfile und gut isses.
Schön, dass es noch Bugfixes gibt.

edit: Otto, genau das habe ich mich nicht getraut :-)
Habe gestern, mit viel Ruhe im Rücken, mal das ganze FHEM geupdatet inklusive CUL_HM, das schlimmste befürchtend.
Und was war? Nix. Keine Probleme. Kann also wieder mitreden.

Nur bei manchen HM-Geräten bekomme ich mit der beta-hm.js wieder "connection lost". Melde mich aber dazu bei frank selbst.





"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

frank

ZitatNur bei manchen HM-Geräten bekomme ich mit der beta-hm.js wieder "connection lost". Melde mich aber dazu bei frank selbst.
seit einiger zeit sehe ich auch gelegentlich connection lost, konnte aber noch keinn fall reproduzieren.
mein bauch meint, es liegt an firefox. eventuell hat die anzahl der geöffneten tabs damit zu tun.

damit martin den patch nicht übersieht, habe ich ihn auch mal in den ürsprünglichen thread gepackt:
https://forum.fhem.de/index.php/topic,118015.0.html
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Pfriemler

Zitat von: frank am 24 Februar 2021, 09:08:27
seit einiger zeit sehe ich auch gelegentlich connection lost, konnte aber noch keinn fall reproduzieren.
Da könnte ich vll. helfen.

Zitatmein bauch meint, es liegt an firefox. eventuell hat die anzahl der geöffneten tabs damit zu tun.
Krieg ich hier gerade sicher auch mit einem Chrome mit nur einem Tab hin.

Die Frage ist: Wo sollen wir das weiter diskutieren? Ich finde inzwischen zu viele Threads zu dem Thema ...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

frank

#83
ZitatWo sollen wir das weiter diskutieren?
ich denke hier:
https://forum.fhem.de/index.php/topic,112156.0.html
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Pfriemler

#84
???
Edith meint, ich solle ruhig sagen dass ich damit nichts anfangen kann ... frank hat den Link korrigiert, jetz geht's.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

TWART016

Wie übertrage ich die Register & Werte von einem Gerät in ein Template bzw. auf ein anderes Gerät?