Ankündigung HM-LC-RGBW-WM Ansteuerung von RGB Stripes

Begonnen von eldrik, 05 August 2015, 09:15:35

Vorheriges Thema - Nächstes Thema

Bennemannc

Hallo,

ja, ist standartmäßig so vorgesehen. Im DimKanal - pct und im ColorKanal - color als WebCmd angeben und Du bekommst Slider zum Einstellen der Helligkeit und der Farbe. Die Programme sind eine DropDown Auswahl.

Gruß Christoph
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

Burny4600

#226
Danke für den Tipp.
Anbei ein komplettes Konfigurationsbeispiel.
Wäre vielleicht für FHEMWIKI nicht schlecht als Ergänzung.
define RGB CUL_HM 123456
attr RGB IODev HmUART_OG2
attr RGB IOgrp VCCU:HmUART_OG2
attr RGB autoReadReg 4_reqStatus
attr RGB expert 2_raw
attr RGB firmware 1.0
attr RGB group RGB Controller
attr RGB icon light_led_stripe_rgb
attr RGB model HM-LC-RGBW-WM
attr RGB serialNr Nxx1234567
attr RGB subType rgb
attr RGB webCmd getConfig:clear msgEvents

define RGB_Dim CUL_HM 12345601
attr RGB_Dim cmdIcon EIN:remotecontrol/black_btn_GREEN AUS:remotecontrol/black_btn_RED
attr RGB_Dim devStateIcon EIN:light_led_stripe_rgb@yellow AUS:light_led_stripe_rgb@gray
attr RGB_Dim eventMap on:EIN off:AUS
attr RGB_Dim group RGB Controller
attr RGB_Dim icon light_led_stripe_rgb
attr RGB_Dim model HM-LC-RGBW-WM
attr RGB_Dim peerIDs 00000000,
attr RGB_Dim webCmd pct:EIN:AUS

define RGB_Color CUL_HM 12345602
attr RGB_Color devStateIcon {my $icon=Color_devStateIcon(ReadingsVal($name,"rgb","000000"));;;;$icon=~s/on/light_led_stripe_rgb/;;;;$icon}
attr RGB_Color group RGB Controller
attr RGB_Color icon light_led_stripe_rgb
attr RGB_Color model HM-LC-RGBW-WM
attr RGB_Color peerIDs 00000000,
attr RGB_Color webCmd color

define RGB_Auto CUL_HM 12345603
attr RGB_Auto devStateIcon off:rc_0 0:rc_0 1:rc_1 2:rc_2 3:rc_3 4:rc_4 5:rc_5 6:rc_6
attr RGB_Auto group RGB Controller
attr RGB_Auto icon light_led_stripe_rgb
attr RGB_Auto model HM-LC-RGBW-WM
attr RGB_Auto peerIDs 00000000,
attr RGB_Auto webCmd colProgram


Eines was mich an dem Dimmerslider stört, ist dass dieser bei einer definierten Einstellung immer weg springt. Gibt es hierfür eine Lösung die ich noch nicht berücksichtigt habe?
MfG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

joshi04

Ich bin der Meinung das hing mit der Rückmeldung vom Aktuator zusammen, der nach Deiner "Eingabe" angezeigt wird. D.h. wenn Du einen Augenblick wartest, springt der Slider auf den Wert, der vom Aktuator zurückgemeldet wird, dem Wert, den Du eingestellt hast.

An welcher Stelle man für eine mögliche Abhilfe ansetzen könnte, geht über meinen Horizont hinaus. Allerdings vermute ich, dass dafür ein tiefer greifender Eingriff notwendig ist.
NUC: 2xJeeLink, PCA301/TX35DTH; HueBridge, LivingColors; vair-monitor (CO2); HMLan, Winmatic, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-ES-TX-WM, HM-WDS10-TH-O, HM-ES-PMSw1-Pl, HM-SEC-SC-2, HM-SEC-SCo; AVM DECT 200; panStamp; smartVISU

Burny4600

Gut, dann muss ich das einstweilen so belassen.
Mir ist dies nur aufgefallen, dass der Slider für die Farbe prompt reagiert, und der für die Helligkeit ein bischen eigenartig herumspringt wodurch ich mehrfach den Slider für die Helligkeit an die gewünschte Position führen muss.
MfG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

joshi04

Das ist tatsächlich spannend.  ???

... bei mir aber auch so (kein Zurückspringen bei Color, dafür aber beim Helligkeitsregler).
Auch wenn hier und dort noch kosmetisches Potential ist, bin ich unabhängig davon derzeit schon sehr froh, mit dem Regler in den produktiven Betrieb habe gehen können (Flurlichtsteuerung).

Bei mir muss ich den Slider für die Helligkeit allerdings nicht mehrfach an die Position führen, sondern nach dem Wählen einfach nur warten. Er springt dann einmal zurück und dann nach einer kurzen Zeit an die Position, die ich gewählt habe. Ist das bei Dir anders?
NUC: 2xJeeLink, PCA301/TX35DTH; HueBridge, LivingColors; vair-monitor (CO2); HMLan, Winmatic, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-ES-TX-WM, HM-WDS10-TH-O, HM-ES-PMSw1-Pl, HM-SEC-SC-2, HM-SEC-SCo; AVM DECT 200; panStamp; smartVISU

ext23

Moin,

ich hab jetzt mal mein panStamp RGB Controller durch diesen von HM ersetzt, der lag noch im Schrank... Mit den panStamps hatte ich zu viele Probleme das diese nicht funktionierten.

Gibt es für den HM RGB Controller eigentlich auch Firmware Updates? Das fading ist ja extrem schlecht. Das flackert ja sowas von stark. Und dann nervt das Pfeifen der MOSFETs auch gewaltig. Aber das hängt wohl stark von der charge ab wie ich feststellen musste.

Es gibt nur leider kaum alternativen außer DMX. PanStamps unzuverlässig im Funk, HM hat Probleme mit dem Grundsätzlichen und diese ESP Variante mit WLAN möchte ich nicht im Schlafzimmer neben meinem Kopf haben...


Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

joshi04

Hi Daniel,

oh jeh, wenn selbst Du die panStamps außer Betrieb nimmst... Das Vorgehen sieht bei mir ganz genauso aus.

Der HM-Controller scheint derzeit noch recht stiefmütterlich betreut zu werden, war z.B. zu Beginn ewig lange nicht lieferbar und gibt es erst seit einiger Zeit als Fertigteil (zu horrenden Preisen). Einige Implementierungen haben teilweise noch recht "viel Potential nach oben" oder kranken gar an generell falsch gewählten Grundsätzen (wenn ich mir diese Meinung erlauben darf).

Eine neue Firmware habe ich noch nicht gesehen, bzw. wäre auch überrascht, wenn EQ3 hier nur auf einmal Fahrt ausnehmen würde.

Bei meiner Anwendung stören derzeit die Unzulänglichkeiten glücklicherweise weniger, so dass ich zwischen diesen und der eingeschränkten Zuverlässigkeit der panStamps ersteres wähle.
Aber Grund für mich, alle panStamps zu ersetzen, soweit würde ich derzeit definitiv in keinem Falle gehen. Ist eher eine Wahl zwischen zwei unterschiedlichen Übeln.

Schöne Grüße,
John
NUC: 2xJeeLink, PCA301/TX35DTH; HueBridge, LivingColors; vair-monitor (CO2); HMLan, Winmatic, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-ES-TX-WM, HM-WDS10-TH-O, HM-ES-PMSw1-Pl, HM-SEC-SC-2, HM-SEC-SCo; AVM DECT 200; panStamp; smartVISU

ext23

Ich hau ja nicht alles raus. Die Temp Sensoren machen z.B. ihren Dienst 1A. Aber das RGB Board ist irgendwie misst, das ist aber ein Software Fehler. Da fehlt das neu senden der Befehle und alle solche Sachen. Und wenn ich dann zum x ten male die Meldung bekommen das der Befehlt 10 Byte sein muss und so, dann habe ich irgendwann auch als Bastler die Schnauze voll von dem Misst.

Da müsste eigentlich mal jemand die Software anfassen, aber das ist nicht mein Streckenpferd :-(

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

LJ_Skinny

Wie ist denn der Stand bei den Modulen? Besteht noch interesse an einem richtig guten Modul? Ich habe hier mal ein Projekt angefangen. Mir geht es um ordentliche Farbmischung und sauberes dimmverhalten..

Die Homematikvariante ist absoluter Mist wenn man sich mal mit der Materie auskennt. Thema Weissabgleich und dann eine kalibrierte Farbmischung. Ideal nach Cie Farbraum.

Leider wurde mein alter Account gelöscht.


ext23

*lol* deswegen ist der HM Kram misst ?!? Da setzt du aber weit oben an! Die arbeiten mit einer zu geringen PWM Frequenz, und außerdem ruckelt das wie sau bei den Übergängen weil die wohl nur 8 Bit haben vermute ich mal. Dann pfeifen die Teile, ich vermute mal EMV technisch auch nicht der Hit. Als wenn da die Widerstände vor den MOSFETS fehlen ... Da bist du aber mit deinem Farbraum aber auf einem ganz anderem Level ;-)
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

chris1284

Zitat von: LJ_Skinny am 23 Juni 2017, 21:57:51
Die Homematikvariante ist absoluter Mist

was meinst du, die cul_hm integration des lc-rgbw? was genau ist dein projekt? ob interesse an einem vermeintlich "richtigen" modul (cul_hm ist auch ein richtiges modul im sinne von modulen in fhem) besteht kann man nur beurteilen wenn man wüsste ob dein projekt einen mehrwert bietet.

wenn du schreibst die "homeatikvariant"  ist mist könnte man auch gut denken du hast ein hardwareprojekt am laufen weil homematik die hardware namentlich beschreibt und nicht das fhem modul zur ansteuerung.

bisher habe ich noch nie gehört das accounts gelöscht werden (und wenn dann sicher aus sehr guten gründen).

ext23

Ich nehme mal an er meint mit Modul das Hardware Modul, nicht ein Software Modul. Aber gut man weiß es nicht ;-)
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Pfriemler

Ich hab das Homematic-Teil seit geraumer Zeit am Laufen. Da pfeift nix. Ist aber wohl chargenabhängig.

PWM liegt bei wenn ich recht liege bei >350 Hz, wohingegen die Zwischendeckendimmer (CV) nur 200Hz haben, hatte ich vorher. Das Ruckeln beim Dimmen liegt nicht an den 8bit (der CV hat auch nicht mehr), sondern daran dass das Modul die Rampen hart stufig (mW in 5%-Schritten schaltet), was der CV besser löst. Das wäre per Firmware besserbar. M.W. gibt es auch ein Register für die Stufigkeit, wäre ein Versuch wert.

Gesendet von meinem SM-G900FD mit Tapatalk

"Ä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 ..."

ext23

Naja alles unter 1kHz ist misst und auch für das Gehirn nicht sonderlich gut. Bei 1kHz kommt man natürlich in andere Probleme.

Was meinst du mit Rampen hart stufig? Du meinst die PWM Schritte sind zu groß oder wie. Also wenn er von den 256 Schritten nur 10 nutzt über den gesamten Bereich oder wie? Und da gibt es ein Register?!?

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Pfriemler

Zitat von: ext23 am 24 Juni 2017, 19:21:07
Naja alles unter 1kHz ist misst und auch für das Gehirn nicht sonderlich gut.
...
Und da gibt es ein Register?!?

/Daniel

woher hast Du das mit den 1kHz? Epilepsiegefahr? Manchen Handydisplays wird Flimmern im Backlight vorgeworfen. Sonst kenne ich da nix.

Die Short-Rampen laufen für mich genauso weich wie bei den CVs. Für das Dimmen per long press an gepeerten Buttons kann man mit lgDimStep die default 5% ändern. Bei 1% ist es deutlich glatter - dauert dann aber auch 5x so lange. Der CV macht das eben besser.

Ansonsten ist die Farbsteuerung im Farbkreis auch nicht mein Fall. Und dass der Aktor nach einem Stromausfall mit rot startet statt mit weiß,  behebt bei mir ein verzögertes DOIF was auf powerOn triggert.

Gesendet von meinem SM-G900FD mit Tapatalk
"Ä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 ..."