philips hue modul

[justme1968]

meinst du die gruppe gibt es in der bridge nicht oder die gruppe gibt es in fhem nicht?

wenn es beides nicht gibt verstehe ich nicht woher die meldung kommt.
wenn es das fhem device gibt aber die gruppe in der bridge nicht: lösch das fhem device und alles sollte gut sein
wenn es die gruppe in der bridge gibt aber kein fhem device: leg das device an
wenn es beides gibt: es sollte keine meldung geben sondern alles einfach funktionieren.

wenn du eine gruppe in der bridge löschst solltest du auch das zugehörige fhem device löschen. bzw. direkt über deletegroup der bridge gehen. dann wird das fhem device mit gelöscht.

[Loredo]

meinst du die gruppe gibt es in der bridge nicht oder die gruppe gibt es in fhem nicht?

Gab es nur noch in FHEM, da ich die Bridge auf Werkseinstellungen gesetzt hatte.
FHEM könnte das aber entweder selbst tun oder zumindest das Device deaktivieren, anstatt solche Fehlermeldungen mit ARRAY(0x0) und so weiter zu frabrizieren. (ja ich mit meiner Convenience  ).

[justme1968]

fhem macht das ja auch selbst wenn du das dafür vorgesehene deletegroup kommando verwendest.

anders kann fhem nicht wirklich unterscheiden ob du absichtlich hinten rum etwas in der bridge gelöscht hast (und vielleicht auch wieder von hand anlegst) oder ob die bridge gerade 'spinnt'.

wenn bridge und fhem nicht mehr synchron sind kann man nicht automatisch feststellen welche der beiden seiten die 'richtige' ist. und wenn ich plötzlich automatisch devices lösche kommt der nächste und beschwert sich darüber

[Markus M.]

wenn bridge und fhem nicht mehr synchron sind kann man nicht automatisch feststellen welche der beiden seiten die 'richtige' ist.

Wenn es noch die gleiche Bridge ist, hat sie immer recht.
Kann das was dann in FHEM nicht mehr passt nicht zumindest deaktiviert werden?
Löschen würde ich wegen anderer Deviceeinstellungen nicht gleich, aber was in der Bridge gelöscht ist, kommt mit der gleichen ID definitiv nicht wieder.

[justme1968]

Wenn es noch die gleiche Bridge ist, hat sie immer recht

leider nicht. manchmal antworte die bridge leider auf grund von netzwerk problemen nicht wie erwartet. bei der nächsten anfrage ist dann alles wieder gut.

wenn du anfängst drüber nach zu denken wie man das einbauen könnte wird es immer komplexer wenn man vermeiden will das nicht aus versehen etwas deaktiviert wird das es gar nicht soll.

kommt mit der gleichen ID definitiv nicht wieder

das stimmt (leider) nicht. gruppen ids werden wiederverwendet. und ich glaube in neuen firmware versionen auch lampen ids.

ich finde es besser die meldung auszuspucken. sie deutet auf ein bestehendes problem hin das durch einen einfachen eingriff behoben werden kann.

[Loredo]

Kann das was dann in FHEM nicht mehr passt nicht zumindest deaktiviert werden?

Genau mein Punkt 

leider nicht. manchmal antworte die bridge leider auf grund von netzwerk problemen nicht wie erwartet. bei der nächsten anfrage ist dann alles wieder gut.

Bei Gruppen wäre es ja nicht wirklich schlimm diese zu deaktivieren und falls doch wieder eine Rückmeldung kommt wieder zu aktivieren.

ich finde es besser die meldung auszuspucken. sie deutet auf ein bestehendes problem hin das durch einen einfachen eingriff behoben werden kann.

Im Grunde auch ok, aber die Meldungen derzeit sehen halt eher aus wie nicht abgefangen  (z.B. ARRAY(0x0) und sowas).

[justme1968]

Bei Gruppen wäre es ja nicht wirklich schlimm diese zu deaktivieren und falls doch wieder eine Rückmeldung kommt wieder zu aktivieren.

eine deaktivierte gruppe wird nicht mehr gepollt und es gibt keine möglichkeit festzustellen das sie wieder da ist. ausserdem kann man im modul nicht feststellen ob ein disable automatisch oder durch den benutzer erfolgt ist. wenn es der benutzer war sollte nichts automatisch wieder aktiviert werden.

d.h. man müsste ein deaktivieren unabhängig von disable einbauen das aber auch nur die meldung unterdrückt und trozdem weiter pollt. das klingt alles nicht gut.


aber ich schaue mal ob ich die meldung etwas schöner machen kann

[justme1968]

so...

ich habe eben eine version eingecheckt bei der die ARRAY... meldung aufgedröselt wird.

ich fürchte aber das hilft nur bedingt weil bei einer nicht vorhandenen gruppe die bridge normalerweise mit einer 'echten' error meldung antwortet und diese schon viel weiter vorne im code abgefangen. diese meldung landet schon immer in einem internal des device und es wird überhaupt keine log meldung erzeugt.

die meldung die du bekommen hast konnte ich weder durch löschen von gruppen, ändern des keys oder sonst wie provozieren. meine bridge zurück setzen wollte ich jetzt nicht .

zusammengefasst: die meldung taucht nur dann auf wenn etwas wirklich unerwartetes passiert und die bridge nicht sinnvoll antwortet. die 'normalen' fehlerzustände werden schon immer so gut es geht abgefangen.

[PsychoD]

Hi,

ich schalte eine Hue Aura mittels DOIF über einen Homematic Taster, den ich direkt über dem Bett angeklebt habe. Leider schaltet die Hue aus irgendeinem Grund Nachts manchmal nicht. Ich hab es schon soweit anhand der Logs rekonstruiert, dass es nicht am Taster und nicht am Doif liegt, also würde ich gern die Huebridge intensiver loggen.

Ich habe nun bereits versucht verbose hochzudrehen und entsprechende Logfiles anzulegen, doch leider kommen einige Einträge nicht im Logfile sondern im generellen FHEM-Log an. Was mache ich falsch?

Auszug aus FHEM.log

Code Auswählen Erweitern

2017.01.23 15:50:22 4: using HttpUtils_NonblockingGet: GET lights
2017.01.23 15:50:22 4: parse status message for wz_l_hueIris
2017.01.23 15:50:22 4: parse status message for sz_l_hueAura

Hier noch die config der Hue Devices:

Code Auswählen Erweitern

#======= HUE BRIDGE ==================================================
define wz_l_huebridge HUEBridge 192.168.1.5
attr wz_l_huebridge httpUtils 1
attr wz_l_huebridge icon hue_filled_bridge_v2
attr wz_l_huebridge key Hw4gKSV-xxx
attr wz_l_huebridge room FHEM
attr wz_l_huebridge verbose 5

define FileLog_wz_l_huebridge FileLog ./log/%Y-%m-wz_l_huebridge.log wz_l_huebridge
attr FileLog_wz_l_huebridge logtype text
attr FileLog_wz_l_huebridge room FHEM

define wz_l_hueIris HUEDevice 1  IODev=wz_l_huebridge
attr wz_l_hueIris userattr beleuchtung beleuchtung_map structexclude
attr wz_l_hueIris IODev wz_l_huebridge
attr wz_l_hueIris alias Iris
attr wz_l_hueIris color-icons 2
attr wz_l_hueIris devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr wz_l_hueIris icon hue_filled_iris
attr wz_l_hueIris model LLC010
attr wz_l_hueIris room Wohnzimmer
attr wz_l_hueIris subType colordimmer
attr wz_l_hueIris verbose 5
attr wz_l_hueIris webCmd hue:rgb:rgb ff0000:rgb 98FF23:rgb 0000ff:toggle:on:off
define FileLog_wz_l_hueIris FileLog ./log/%Y-%m-wz_l_huebridge.log wz_l_hueIris
attr FileLog_wz_l_hueIris logtype text

define sz_l_hueAura HUEDevice 2  IODev=wz_l_huebridge
attr sz_l_hueAura userattr beleuchtung beleuchtung_map flat flat_map room_map structexclude
attr sz_l_hueAura IODev wz_l_huebridge
attr sz_l_hueAura alias Aura
attr sz_l_hueAura color-icons 2
attr sz_l_hueAura devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr sz_l_hueAura icon hue_filled_bloom
attr sz_l_hueAura model LLC007
attr sz_l_hueAura room Schlafzimmer
attr sz_l_hueAura subType colordimmer
attr sz_l_hueAura verbose 5
attr sz_l_hueAura webCmd hue:rgb:rgb ff0000:rgb 98FF23:rgb 0000ff:toggle:on:off
define FileLog_sz_l_hueAura FileLog ./log/%Y-%m-wz_l_huebridge.log sz_l_hueAura
attr FileLog_sz_l_hueAura logtype text

define HUEGroup0 HUEDevice group 0  IODev=wz_l_huebridge
attr HUEGroup0 IODev wz_l_huebridge
attr HUEGroup0 alias Lightset 0
attr HUEGroup0 color-icons 2
attr HUEGroup0 delayedUpdate 1
attr HUEGroup0 devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr HUEGroup0 group HUEGroup
attr HUEGroup0 room FHEM
define HUEGroup1 HUEDevice group 1  IODev=wz_l_huebridge
attr HUEGroup1 IODev wz_l_huebridge
attr HUEGroup1 color-icons 2
attr HUEGroup1 delayedUpdate 1
attr HUEGroup1 devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr HUEGroup1 group HUEGroup
attr HUEGroup1 icon hue_room_living room
attr HUEGroup1 room FHEM
define HUEGroup2 HUEDevice group 2  IODev=wz_l_huebridge
attr HUEGroup2 IODev wz_l_huebridge
attr HUEGroup2 color-icons 2
attr HUEGroup2 delayedUpdate 1
attr HUEGroup2 devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr HUEGroup2 group HUEGroup
attr HUEGroup2 icon hue_room_bedroom
attr HUEGroup2 room FHEM

Danke & Gruß
Psy

[justme1968]

verbose bezieht sich grundsätzlich auf die ausgaben die für das fhem log gedacht sind. diese ausgaben haben nichts mit dem loggen der readings zu tun. diese kann man nicht durch verbose beeinflussen sondern durch die event-xxx attribute im device und durch die regex in der definition des log device.

wie genau hast du ausgeschlossen das es am taster oder DOIF liegt?

gruss
  andre

[PsychoD]

Ah, OK, das wusste ich nicht.

Ich habe beide geloggt, und sie kommen ordentlich an. z.B. hier das verzweifelte Beispiel von letzter Nacht das Licht anzumachen  :

Log Taster:

Code Auswählen Erweitern

2017-01-23_04:14:10 sz_taster battery: ok
2017-01-23_04:14:10 sz_taster CMDs_done
2017-01-23_04:14:10 sz_taster sz_taster_unten Short
2017-01-23_04:14:12 sz_taster battery: ok
2017-01-23_04:14:12 sz_taster CMDs_done
2017-01-23_04:14:12 sz_taster sz_taster_unten Short
2017-01-23_04:14:14 sz_taster battery: ok
2017-01-23_04:14:14 sz_taster CMDs_done
2017-01-23_04:14:14 sz_taster sz_taster_unten Short
2017-01-23_04:14:16 sz_taster battery: ok
2017-01-23_04:14:16 sz_taster CMDs_done
2017-01-23_04:14:16 sz_taster sz_taster_unten Short
2017-01-23_04:14:17 sz_taster battery: ok
2017-01-23_04:14:17 sz_taster CMDs_done
2017-01-23_04:14:17 sz_taster sz_taster_unten Short
2017-01-23_04:14:19 sz_taster battery: ok
2017-01-23_04:14:19 sz_taster CMDs_done
2017-01-23_04:14:19 sz_taster sz_taster_unten Short
2017-01-23_04:14:21 sz_taster battery: ok
2017-01-23_04:14:21 sz_taster CMDs_done
2017-01-23_04:14:21 sz_taster sz_taster_unten Short

Log DOIF:

Code Auswählen Erweitern


2017-01-23_04:14:10 di_sz_taster cmd_nr: 2
2017-01-23_04:14:10 di_sz_taster cmd: 2
2017-01-23_04:14:10 di_sz_taster cmd_event: sz_taster_unten
2017-01-23_04:14:10 di_sz_taster cmd_2
2017-01-23_04:14:12 di_sz_taster cmd_nr: 2
2017-01-23_04:14:12 di_sz_taster cmd: 2
2017-01-23_04:14:12 di_sz_taster cmd_event: sz_taster_unten
2017-01-23_04:14:12 di_sz_taster cmd_2
2017-01-23_04:14:14 di_sz_taster cmd_nr: 2
2017-01-23_04:14:14 di_sz_taster cmd: 2
2017-01-23_04:14:14 di_sz_taster cmd_event: sz_taster_unten
2017-01-23_04:14:14 di_sz_taster cmd_2
2017-01-23_04:14:16 di_sz_taster cmd_nr: 2
2017-01-23_04:14:16 di_sz_taster cmd: 2
2017-01-23_04:14:16 di_sz_taster cmd_event: sz_taster_unten
2017-01-23_04:14:16 di_sz_taster cmd_2
2017-01-23_04:14:17 di_sz_taster cmd_nr: 2
2017-01-23_04:14:17 di_sz_taster cmd: 2
2017-01-23_04:14:17 di_sz_taster cmd_event: sz_taster_unten
2017-01-23_04:14:17 di_sz_taster cmd_2
2017-01-23_04:14:19 di_sz_taster cmd_nr: 2
2017-01-23_04:14:19 di_sz_taster cmd: 2
2017-01-23_04:14:19 di_sz_taster cmd_event: sz_taster_unten
2017-01-23_04:14:19 di_sz_taster cmd_2
2017-01-23_04:14:21 di_sz_taster cmd_nr: 2
2017-01-23_04:14:21 di_sz_taster cmd: 2
2017-01-23_04:14:21 di_sz_taster cmd_event: sz_taster_unten
2017-01-23_04:14:21 di_sz_taster cmd_2


Def vom DOIF:

Code Auswählen Erweitern

([sz_taster_oben:"Short"]) ({toggle("sz_l_regal")})
DOELSEIF ([sz_taster_unten:"Short"]) (set sz_l_hueAura toggle)

Es blieb jedoch dunkel, daher muss ich nun alles weitere loggen und hoffen, dass es nicht einfach nur Funkstörungen o.ä. sind...

Viele Grüße
Psy

[hauwech]

Hallo zusammen,

... vorweg: Sehr nützliches Modul, danke dafür!

Wiki und commandref sind noch nicht sehr ergiebig.
Wo kann ich denn nachlesen, was die Parameter bei den set-Befehlen bewirken, die nicht ganz so intuitiv sind?
z.B.: "alert [none|select|lselect]"

<blink> z.B. finde ich gar nicht - nicht soo schlimm, die Parameter kann man selbst testen, das ist intuitiv.
[<ramp-time>] habe ich so interpretiert, daß die Lampen in der angegebenen Zeit langsam hoch- (on) oder runterdimmen (off). Egal mit welchen Werten zwischen 5 und 60 z.B. ich probiert habe:
- set HUEDevice1 on 10 oder
- set HUEDevice1 on [10] oder
- set HUEDevice1 on <10>
schalten die Lampen sofort. Sowohl [] als auch <> verstehe ich als Indikatoren für einen optionalen Parameter. Da in der commandref beide angegeben sind, habe ich alle drei Syntaxvarianten probiert. Wie wäre denn die korrekte Syntax für "set on/off <ramp-time>"? Ich habe mein Ziel allerdings auch mit "transitiontime" erreicht.

Danke und Gruß
Roland

[hauwech]

Die Erklärung für "alert none|select|lselect" habe ich jetzt hier https://forum.fhem.de/index.php/topic,11020.msg233987.html#msg233987 gefunden.

Gruß Roland

[SirMarco]

Besteht die Möglichkeit einen Hue mit einen RGB Farbcode anzusteuern und das der letzte DimmStatus erhalten bleibt?

[justme1968]

nein... wie soll denn das gehen? ein rgb wert enthält implizit die helligkeit.

wenn du nur die farbe ändern willst und die helligkeit gleich bleiben soll musst du über hue und/oder sat gehen.

gruss
  andre