philips hue modul

Begonnen von justme1968, 11 Februar 2013, 13:55:14

Vorheriges Thema - Nächstes Thema

Shojo

Bei mir läuft das Zigbee Netzwerk über den Conbee Stick & der  deCONZ / Phoscon App
FHEM auf: Shuttle PC (x64) (Docker)
Bridge: SignalESP 433mHz, ConBee (deCONZ in Docker)
Rest: ESP8266, SONOFF, Sonos, Echo Dot, Xiaomi Vacuum (root), ESP RGBWW Wifi Led Controller, Node-RED, LEDMatrix, Pixel It

StephanFHEM

Zitat von: justme1968 am 17 November 2018, 11:53:45
@StephanFHEM: dimUp und dimDown arbeiten mit bri, nicht mit pct und der default delta wert ist nicht 10 sondern 25. wenn deine bridge firmware halbwegs aktuell ist kannst du mit set <name> dimUp<delta> bzw set <name> dimDown<delta> einen anderen verwenden.

Klasse Danke! Funktioniert jetzt wie ein Traum. Das war vorher Bri 25. hat aber bei PCT immer 10 ergeben (und da hatte ich nur drauf geachtet). Mit Wert 50 ist es jetzt so wie ich mir vorgestellt habe.

hoppel118

#1487
Zitat von: justme1968 am 17 November 2018, 11:53:45
@cramu, hoppel118: weil die bridge (zumindest die alte) und auch fhem auf einem langsamen systemen deutlich in die knie gehen kann wann man viele geräte hat und es übertreibt.

wenn man in fhem direkt auf das schalten reagieren möchte kann man das Intervall für dieses device auch kürzer wählen. taster sollte man dann direkt in fhem abfragen mit 1-2 sekunden intervall. aber achtung: fhem wird auch dann nicht so schnell reagieren wie du möchtest weil der taster die lampe direkt steuert und die bridge davon auch nur verzögert erfährt.

die bridge ist für solche 'echtzeit' aufgaben nicht gemacht. dafür sollte man andere taster verwenden (homematic, zwave, ...) oder man schaut sich die deconz module an und verwendet das push api mit fhem. siehe anderer thread.

Moin @justme1968,

ich habe die neue Bridge (14 HUEDevices, 4HUESwitches, 13 HUEGroups) und einen XEON-Server mit 64GB RAM und SSD. FHEM ist da nur eine Anwendung von vielen. Der Server langweilt sich meistens. Was ist für dich "langsames System", "viele Geräte" und "es übertreiben"?

Ich schätze, dass ich mich mit meiner Umgebung noch lange nicht in diesen Bereichen bewege. ;)

Ich habe den Intervall gerade mal von Default (ich glaube 300 Sek., also keine Intervall-Angabe) auf 10 Sekunden reduziert:

define HUEBridge HUEBridge XXX.XXX.XXX.XXX 10

Jetzt geht das Ganze schon deutlich schneller. Für mich ist das so ok, auch wenn es kein Realtime-Status ist. Meistens dauert es keine 10 Sekunden, sondern der geänderte Status wird schneller erkannt.

Für was brauche eigentlich die folgenden drei Attribute?

attr HUEBridge pollDevices 1
attr HUEBridge httpUtils 1
attr HUEBridge noshutdown 1


Momentan sind alle drei Attribute bei mir nicht konfiguriert.

Testweise habe ich gerade mal "httpUtils 1" und "pollDevices 1" konfiguriert. FHEM einmal neugestartet und schon sehe ich die Meldung "empty answer received" im Logfile. Folgender Thread hat dann die Lösung gebracht, "noshutdown 1" ist zu konfigurieren:

https://forum.fhem.de/index.php/topic,84063.0.html

Siehe da, die "empty answer received" Meldung ist danach wieder weg.

Für was genau brauche ich eigentlich pollDevices und was ist der Unterschied bei 0/1/2?

attr HUEBridge pollDevices 0
attr HUEBridge pollDevices 1
attr HUEBridge pollDevices 2


Was genau verbirgt sich hinter "httpUtils" und "noshutdown" (beides kann ich wahrscheinlich mit "0" und "1" aus- bzw. einschalten)?

Danke euch und Gruß Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

justme1968

@Shojo: das ist noch kein grund :)
aber im ernst: im api werden alle komponenten getrennt als eigenes gerät angezeigt. ein zusammenfassen ist zwar möglich aber nicht so trivial wie es auf den ersten blick ausschaut. was macht man mir gleichen readings die in jedem sensor vorkommen? was macht man mit state? eventuell ist für jeden typ ein anderes polling Intervall sinnvoll. vielleicht sollen realigns ja nicht im gleichen fhem räum angezeigt werden, ...

deshalb noch mal die frage: was genau möchtest du erreichen? was geht nicht wenn es wie jetzt getrennte einzel devices sind?


@Paul: Iden denke du meinst colordimmer? aber auch das kann ich bei mir nicht reproduzieren. wann genau passiert das bei dir? mit welcher hardware?


@hoppel118: dein xeon server ist nicht direkt das problem. aber die bridge selber ist schwachbrüstiger als man denkt. un wenn man schaut wie lange eine komplette abfrage tatsächlich dauert und berücksichtigt das früher alles synchron ging, wenn man bedenkt das auch wenn auf fhem seite die abfrage inzwischen asynchron ist, die bridge aber trotzdem noch alle daten erst mal zusammen stellen muss. je nach anwendung sollte man auch berücksichtigen das die bridge nur 10 kommandos pro minute erlaubt. hier zählt jeder einzelne parameter für jede lampe. 5 Lampen ein schalten und auf eine bestimmte farbe dimmen ist also scho deutlich über der grenze wenn man jede lampe einzeln behandelt und nicht mit szenen arbeitet. man sieht hier sich deutlich verzögerungen wenn sich die lampen direkt nebeneinander sind. wenn dann noch abfragen im sekunden takt kommen ist das nicht hilfreich. auch möchte man eventuell einzelne lampen oder taster deutlich öfter abfragen. dann ist es besser bei den nicht so wichtigen mehr zeit zu erlauben.

wichtig ist immer zu bedenken das das ganze system was das api angeht und vor allem das pollen nicht echtzeitfähig ist und auch nicht dafür gedacht ist. eine push funktion fehlt hier eindeutig. das geht aktuell nur mir dresden elektronik und deren bridge.

es kommt also auf den einzelfall an. wenn es bei dir geht und du keine probleme beobachtest ist doch alles ok.


die einzelnen attribute sollten alle in der commandref beschrieben sein. hier ist es wichtig zu wissen das features wie non-blocking io, das pollen aller devices auf ein mal, ... nach und nach dazu gekommen sind und je nach bridge und anzahl der lampen kombiniert werden sollten um optimale ergebnisse zu erhalten. auch hier kommt es auf die eigenen vorstellungen an. die defaults einfach zu ändern geht aber nicht ohne das verhalten bereits installierter systeme zu beeinflussen.

ob noshutdown nötig ist hängt ebenfalls von der hardware und verwendeten firmware ab. das verhalten hat sich über die zeit geändert. noshutdown ist inzwischen (fast) immer nötig und auch der default.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Paul

Zitat von: justme1968 am 20 November 2018, 08:56:10

@Paul: Iden denke du meinst colordimmer? aber auch das kann ich bei mir nicht reproduzieren. wann genau passiert das bei dir? mit welcher hardware?


Guten Morgen,

nein, ich meine die "normalen" Dimmer.  Die bleiben beim dimmen grün erst bei 100% werden sie gelb.  Bei den extcolordimmern wird berreits beim dimmen die  Farbe angezeigt. ich habe nochmals ein Bild angehängt. Es sind auch verschiedene Dimmer:

Internals:
   DEF        11  IODev=HUE
   ID         11
   INTERVAL   
   IODev      HUE
   NAME       FlurOG
   NR         458
   STATE      on
   TYPE       HUEDevice
   desired    1
   manufacturername Philips
   modelid    LWB010
   name       FlurOG
   productid  Philips-LWB010-1-A19DLv4
   swconfigid FF6681C4
   swversion  1.29.0_r21169
   type       Dimmable light
   uniqueid   00:17:88:01:02:fc:21:9a-0b
   READINGS:
     2018-11-19 22:52:38   alert           none
     2018-11-20 09:13:02   bri             254
     2018-11-20 09:12:58   onoff           1
     2018-11-20 09:13:02   pct             100
     2018-11-19 22:52:38   reachable       1
     2018-11-20 09:13:02   state           on
   helper:
     alert      none
     bri        254
     colormode 
     ct         -1
     devtype   
     effect     
     hue        -1
     pct        100
     reachable  1
     rgb       
     sat        -1
     update_timeout -1
     xy         
Attributes:
   IODev      HUE
   alias      FlurOG
   color-icons 2
   devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
   icon       hue_filled_white_and_color_e27_b22
   model      LWB010
   room       HUEDevice
   subType    dimmer
   webCmd     pct:toggle:on:off

Internals:
   CHANGED   
   DEF        15  IODev=HUE
   ID         15
   INTERVAL   
   IODev      HUE
   NAME       FlurKeller2
   NR         466
   STATE      off
   TYPE       HUEDevice
   desired    0
   manufacturername IKEA of Sweden
   modelid    TRADFRI bulb GU10 W 400lm
   name       FlurKeller2
   swversion  1.2.214
   type       Dimmable light
   uniqueid   90:fd:9f:ff:fe:15:23:a8-01
   READINGS:
     2018-11-19 22:52:38   alert           none
     2018-11-20 09:10:22   bri             78
     2018-11-20 09:12:25   onoff           0
     2018-11-20 09:12:25   pct             0
     2018-11-20 08:39:40   reachable       1
     2018-11-20 09:12:25   state           off
   helper:
     alert      none
     bri        78
     colormode 
     ct         -1
     devtype   
     effect     
     hue        -1
     on         0
     pct        0
     reachable  1
     rgb       
     sat        -1
     update_timeout -1
     xy         
Attributes:
   IODev      HUE
   alias      FlurKeller2
   color-icons 2
   devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
   model      TRADFRI bulb GU10 W 400lm
   room       HUEDevice
   subType    dimmer
   webCmd     pct:toggle:on:off
Cubietruck, HM-USB, CUL, FS20, FHT, HUE, Keymatic

justme1968

normale dimmer bekommen vom modul überhaupt keine farbe.

die icons verenden die farbe die der aktuell von dir verwendete style für das icon vorsieht. bei dark ist das z.b. immer weiss.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Shojo

Zitat von: justme1968 am 20 November 2018, 08:56:10
@Shojo: das ist noch kein grund :)
aber im ernst: im api werden alle komponenten getrennt als eigenes gerät angezeigt. ein zusammenfassen ist zwar möglich aber nicht so trivial wie es auf den ersten blick ausschaut. was macht man mir gleichen readings die in jedem sensor vorkommen? was macht man mit state? eventuell ist für jeden typ ein anderes polling Intervall sinnvoll. vielleicht sollen realigns ja nicht im gleichen fhem räum angezeigt werden, ...

deshalb noch mal die frage: was genau möchtest du erreichen? was geht nicht wenn es wie jetzt getrennte einzel devices sind?

Ganz ehrlich... weil ich es schöner finde :D
Ich verstehe ja auch deinen Standpunkt, dachte aber ja so halt optional ;)

Aber danke das du dir die Zeit genommen hast um dich mit meiner Anfrage zu beschäftigen!

Gruß
Dennis
FHEM auf: Shuttle PC (x64) (Docker)
Bridge: SignalESP 433mHz, ConBee (deCONZ in Docker)
Rest: ESP8266, SONOFF, Sonos, Echo Dot, Xiaomi Vacuum (root), ESP RGBWW Wifi Led Controller, Node-RED, LEDMatrix, Pixel It

Paul

Zitat von: justme1968 am 20 November 2018, 09:28:26
normale dimmer bekommen vom modul überhaupt keine farbe.

die icons verenden die farbe die der aktuell von dir verwendete style für das icon vorsieht. bei dark ist das z.b. immer weiss.

Vielleicht habe ich mich mit Farben falsch ausgedrückt.
Die Farbe ändert sich ja auch im Dark Modus auf weiß. Das passiert aber nur wenn die Lampe bei 100% ist.
Darunter werden zwar die ,,Strahlen" angezeigt. M.E. Müßte schon bei >0% die Lampe auf weiß gehen.
Cubietruck, HM-USB, CUL, FS20, FHT, HUE, Keymatic

justme1968

ich weiss was du meins, aber wie oben geschrieben wird die farbe in diesem fall nicht vom modul gesetzt sondern kommt direkt aus dem style.

in defaultCommon.css wird nur für den fall on die icon farbe auf orange gesetzt:svg.on,svg.FS20_on { fill:orange!important; }

wenn du das auch für die dim icons haben möchtest muss das ebenfalls im style gemacht werden und hat mit dem modul nichts zu tun.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Paul

Zitat von: justme1968 am 06 Dezember 2018, 20:32:05
ich weiss was du meins, aber wie oben geschrieben wird die farbe in diesem fall nicht vom modul gesetzt sondern kommt direkt aus dem style.

in defaultCommon.css wird nur für den fall on die icon farbe auf orange gesetzt:svg.on,svg.FS20_on { fill:orange!important; }

wenn du das auch für die dim icons haben möchtest muss das ebenfalls im style gemacht werden und hat mit dem modul nichts zu tun.

Danke, ich dachte es kommt vom Modul, da es bei den Colorlampen funktioniert.
Cubietruck, HM-USB, CUL, FS20, FHT, HUE, Keymatic

justme1968

nein. weil modul nicht weiß welche farben der aktuelle style verwendet.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Paul

Zitat von: justme1968 am 06 Dezember 2018, 21:27:05
nein. weil modul nicht weiß welche farben der aktuelle style verwendet.

Habe gerade gesehen das es bei nicht Hue-Dimmern genauso ist, dort ist es mir nur nicht aufgefallen.

D.h. Aber das alle .css Dateien ,,falsch" sind und eigentlich schon bei !on die Farbe wechseln müßten.

Danke, da für mich das umschreiben der cssßDateien zu hoch ist beende ich hier das Thema.
Cubietruck, HM-USB, CUL, FS20, FHT, HUE, Keymatic

FunkOdyssey

Ich weiß nicht, was plötzlich passiert ist, aber bei mir wird der Status einer Osram-Birne (an Huebridge angelernt) nicht mehr in FHEM angezeigt.
Alles andere passt. Nur die Osram-Birne ist immer "unreachable". Befehle von FHEM werden aber akzeptiert. Nur halt nicht als Readings angezeigt.

Kennt jemand dieses Problem? Laut Log war das vor wenigen Tagen noch anders. Und es lag nur ein FHEM-Neustart dazwischen.

Die Varianten mit "noshutdown", "queryAfterSet", "httpUtils" und "pollDevices" habe ich alle durchgespielt. Ohne Erfolg.

Damian

Tja, das Problem habe ich leider auch. Diverse Osram-Devices (Zwischenstecker, LED-Strips) über HUE-Bridge sind irgendwann nicht mehr erreichbar, obwohl sie sich schalten lassen.

Ich konnte das Problem leider nicht genauer verifizieren. Vermutlich eine Inkompatibilität zwischen Osram und Philips ZigBee-Umsetzung. Man kann aber statt Status das Reading onoff bzw. pct auswerten. Diese Readings werden beim Schalten korrekt belegt. Daran kann man erkennen, ob die Lampe an oder aus ist.

Besser wäre es im HUE-Modul den Zustand unreachable statt im Status in einem anderen Reading z. B. error festzuhalten.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

moskito

Oder mit dem Attribut "ignoreReachable" arbeiten!

Gruß
Danny
FHEM auf Intel NUC/Proxmox & Debian 12 + HM-CFG-USB + zigbee2mqtt + Zwave + Enocean