Autor Thema: colorpicker scheint nicht zu gehen?!  (Gelesen 1446 mal)

Offline andies

  • Hero Member
  • *****
  • Beiträge: 2153
colorpicker scheint nicht zu gehen?!
« am: 07 Oktober 2017, 23:19:21 »
Guten Abend, kann mir mal jemand helfen? Ich kriege bei diesem dummy den colorpicker nicht hin:

Internals:
   CFGFN
   NAME       dummy
   NR         2535
   STATE      RGB 785970
   TYPE       dummy
   READINGS:
     2017-10-07 23:15:34   RGB             007812
     2017-10-07 23:16:02   state           RGB 785970
Attributes:
   room       1
   webCmd     RGB
   widgetOverride RGB:colorpicker,RGB
Zwar erscheint der Colorpicker und ich kann drauf klicken, aber das Reading RGB wird nicht entsprechend angepasst. Was mache ich da falsch?
FHEM 5.9 auf RaspPi3 (Raspbian:  4.14.34-v7+ ); Perl: v5.20.2
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline andies

  • Hero Member
  • *****
  • Beiträge: 2153
Antw:colorpicker scheint nicht zu gehen?!
« Antwort #1 am: 08 Oktober 2017, 08:40:55 »
Ich habe selber ein wenig experimentiert. Der Befehl widgetOverride ist wie folgt zu lesen: das erste Wort (hier RGB) vor dem Doppelpunkt definiert, wie man den Colorpicker im Webcmd ansprechen und damit aufrufen oder anzeigen kann. Pickt man dann eine Farbe, so ändert sich der Internal STATE, was bei mir aber zeitverzögert dargestellt wird. Was sich sofort ändert ist ein Reading state, es bekommt den Inhalt „RGB <Farbcode>“, wobei RGB wieder dem ersten (!) Wort vor dem Doppelpunkt entspricht.

Wozu das RGB hinter dem Komma steht, habe ich nicht herausbekommen. Wenn ich es weglasse, geht alles genau so?!


Gesendet von iPad mit Tapatalk Pro
FHEM 5.9 auf RaspPi3 (Raspbian:  4.14.34-v7+ ); Perl: v5.20.2
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19265
Antw:colorpicker scheint nicht zu gehen?!
« Antwort #2 am: 08 Oktober 2017, 09:51:21 »
der colorpicker kümmert sich nicht um STATE.

er benutz das kommando/reading das du angegeben hast.

bei einem dummy musst du readingList verwenden um andere readings außer state zu setzen.

beim einem dummy ist widgetOverride normalerweise unnötig. dort wird setList verwendet.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline andies

  • Hero Member
  • *****
  • Beiträge: 2153
Antw:colorpicker scheint nicht zu gehen?!
« Antwort #3 am: 08 Oktober 2017, 10:10:46 »
Wird denn das Reading, das dann beeinflusst wird, automatisch angelegt? Oder muss ich das per Hand anlegen? Ich möchte einen Colorpicker bei einem Sonoff device anlegen, was geht – aber ich „sehe“ die gepickte Farbe weder in einem Reading noch anderswo. Type des Gerätes ist MQTT_DEVICE.


Gesendet von iPad mit Tapatalk Pro
FHEM 5.9 auf RaspPi3 (Raspbian:  4.14.34-v7+ ); Perl: v5.20.2
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19265
Antw:colorpicker scheint nicht zu gehen?!
« Antwort #4 am: 08 Oktober 2017, 12:58:22 »
schau in der doku nach. probier es aus.

wenn es um ein nicht dummy device geht musst du natürlich die vorhandenen kommandos verwenden.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline the ratman

  • Hero Member
  • *****
  • Beiträge: 2015
  • cosmoprolet & intelligenzdiabetiker
Antw:colorpicker scheint nicht zu gehen?!
« Antwort #5 am: 08 Oktober 2017, 13:15:27 »
wenn ihr schon wegen colopicker am reden seits ...

könnte man eventuell was mit highdpi-geräten machen?
schon mit 1200*1920 auf nem 7" tablet ist die farbwahl mit touch quasi unmöglich.
bei größeren auflösungen kann man dann nicht mal mehr den hex-code der farbe lesen.
es müsste sich das bild der farbwahl also zumindest dynamisch an die auflösung anpassen.

ich frag dass, weil ja der "colorpicker,hsv" gar nimma, bzw. nur mehr teilweise mag ( https://forum.fhem.de/index.php/topic,77607.msg695884.html#msg695884 ) und mir langsam die optionen ausgehen, meine farbstripes und rgb-lampen direkt von fhem aus zu regeln, was meinen waf derzeit verdammt in die knie zwingt *g*.
→do↑p!dnʇs↓shit←

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20642
Antw:colorpicker scheint nicht zu gehen?!
« Antwort #6 am: 10 Oktober 2017, 14:42:43 »
Zitat
schon mit 1200*1920 auf nem 7" tablet ist die farbwahl mit touch quasi unmöglich.
Welchen Style (touchpad/scmallscreen/etc) hast du gesetzt?
Evtl. hilft bei dir das viewport Attribut zu setzen.

Offline the ratman

  • Hero Member
  • *****
  • Beiträge: 2015
  • cosmoprolet & intelligenzdiabetiker
Antw:colorpicker scheint nicht zu gehen?!
« Antwort #7 am: 10 Oktober 2017, 15:58:01 »
kann man den "button"nicht einfach als svg machen, ähnlich wie die fablich angepassten glühbirnen bei z.b philips hue lampen? für mich braucht der nicht mal den hexwert drauf stehen haben, der is dem waf sowieso nur abträglich.

für die farbverlaufs-gfx fallt mir allerdings auch nix ein - oder ginge so n regenbogen auch in nem svg, ohne den speicher zu sehr zu strapazieren?
da könnte man dann ja sagen: wenn svg-button größe x hat, dann hat der svg-gradient x*10 oder oder gleich 90% bildschirmbreite.

zur frage:
ich verwend nur web und floorplan mit eigenen css. alles techn. vom darkstyle inspiriert, ohne small oder sonst was.
z.b. beim fully browser unter android "use wide viewport"zu nehmen, is ne gute idee, macht nur leider keinen unterschied bei der grafikgröße - siehe anhang (fully browser auf 1200 x 1920 mit vieport on)
als größenvergleich: die höhe des farbverlaufs liegt bei ca. 1,5 cm am tablet.
→do↑p!dnʇs↓shit←

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20642
Antw:colorpicker scheint nicht zu gehen?!
« Antwort #8 am: 10 Oktober 2017, 16:45:23 »
Ich meinte das FHEMWEB viewport Attribut. In der "touchpad" mode wird es auf width=768 gesetzt.

Wer die Desktop Ansicht auf einem 7-Zoll Bildschirm mit Riesen-Aufloesung verwendet, der sollte sich nicht wundern, dass manches klein ist.

Offline the ratman

  • Hero Member
  • *****
  • Beiträge: 2015
  • cosmoprolet & intelligenzdiabetiker
Antw:colorpicker scheint nicht zu gehen?!
« Antwort #9 am: 10 Oktober 2017, 17:23:08 »
das könnte jetzt ne grundsatzdiskussion geben *g*

1920x1080 oder 1920x1200 hab ich nur mehr bei den chinesenschrott-tablet an der wand und einem ebenfalls schrottigen handy meiner holden.
der rest hier is wesentlich besser - meinereiner empfindet das als extrem augenschonend ... so surf ich grad auf 12,3" mit 2736x1824 und der rest hier hat 4k2k.
ich bin also scheints arm dran ... zumindest, sobald ich farbe auf meine lampen kriegen will. frei nach spaceballs: zimmerservice!
→do↑p!dnʇs↓shit←

 

decade-submarginal