philips hue modul

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

Vorheriges Thema - Nächstes Thema

Damian

Zitat von: moskito am 07 Dezember 2018, 20:13:06
Oder mit dem Attribut "ignoreReachable" arbeiten!

Gruß
Danny

Danke für den Tipp, ich wollte gerade schon anfangen das Modul zu patchen :)
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

FunkOdyssey

Danke für eure Antworten und vor allem auch für den Tipp mit denn Attribut.
Mich nervt die Osram-Birne sowieso. Irgendwann geht die weg.

Damian

Zitat von: FunkOdyssey am 07 Dezember 2018, 21:02:15
Danke für eure Antworten und vor allem auch für den Tipp mit denn Attribut.
Mich nervt die Osram-Birne sowieso. Irgendwann geht die weg.

Sicherlich sind die HUE-Devices von Philips kompatibler. Allerdings sind Osram Zwischenstecker (12,50) bzw. LED-Stripes (29 €) immer wieder erheblich billiger zu haben als entsprechende Philips-Devices.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Shojo

Naben die Runde,

kann ich eigentlich das Polling komplett abschalten?
Da ich ja durch deCONZ eine Push fähige API habe.

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

FHEm2005

Hinweis: Ich habe dieses Problem im Zusammenhang mit VISU schon in diesem Thread beschrieben. Es kristallisierte sich m.E. heraus, dass das Lösung wohl der Arbeitsweise des  HUE-Moduls HUEDEVICE zu finden ist. Hier der Link https://forum.fhem.de/index.php/topic,94740.msg875272.html#new

Ich habe ehrlicherweise keine große Lust mich durch die 101 Seiten dieses Threads durchzuwühlen. Ich weiß, dass es eine Suchfunktion gibt, die aber nichts Passendes gefunden hat.

Zum Thema:
2 Tradfri-Lampen in einem Raum arbeiten wie sie sollen - keine Beanstandungen und Probleme In der HUE-Bridge wurde für diese beiden Lampen eine eigene Gruppe (Group3) aufgemacht und in FHEM definiert.

Die Definition der Bridge und der Gruppe:

Group3:
defmod Li_Sz_HUEGroup3 HUEDevice group 3  IODev=HUE
attr Li_Sz_HUEGroup3 userattr createActionReadings:1,0 createGroupReadings:1,0
attr Li_Sz_HUEGroup3 IODev HUE
attr Li_Sz_HUEGroup3 color-icons 1
attr Li_Sz_HUEGroup3 createGroupReadings 1
attr Li_Sz_HUEGroup3 delayedUpdate 1
attr Li_Sz_HUEGroup3 devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr Li_Sz_HUEGroup3 event-on-change-reading .*
attr Li_Sz_HUEGroup3 group Schlafzimmer
attr Li_Sz_HUEGroup3 room Licht,Unsorted->HUE
attr Li_Sz_HUEGroup3 webCmd on:off


Bridge:
defmod HUE HUEBridge 192.168.2.20
attr HUE userattr FstrFront FstrFront_map structexclude
attr HUE createGroupReadings 1
attr HUE event-on-change-reading .*
attr HUE icon hue_filled_bridge_v2
attr HUE key viele Zahlen und Buchstaben
attr HUE room System
attr HUE verbose 5


Wenn ich den Befehl set Li_Sz_HUEGroup3 on erwarte ich, dass das Reading state den Zustand on oder dimxx annimmt. Dem ist aber nicht so. Lediglich die Readings all_on und any_on verändern sich. Was muss ich machen, damit sich der state entsprechend dem Befehl ändert.

Hier die Meldungen des Event-Monitors:
Befehl: set Li_Sz_HUEGroup3 off
2018-12-22 14:28:45 HUEDevice Li_Wz_HUEGroup1 off
2018-12-22 14:28:54 HUEDevice Li_Sz_HUEGroup3 all_on: 0
2018-12-22 14:28:54 HUEDevice Li_Sz_HUEGroup3 any_on: 0
2018-12-22 14:28:55 HUEDevice Li_Wz_HUEGroup1 off
2018-12-22 14:28:55 HUEDevice Li_Sz_HUEDevice12 off
2018-12-22 14:28:55 HUEDevice Li_Sz_HUEDevice21 off


Befehl: set Li_Sz_HUEGroup3 on
2018-12-22 14:29:14 HUEDevice Li_Sz_HUEGroup3 all_on: 1
2018-12-22 14:29:14 HUEDevice Li_Sz_HUEGroup3 any_on: 1
2018-12-22 14:29:14 HUEDevice Li_Wz_HUEGroup1 off
2018-12-22 14:29:14 HUEDevice Li_Sz_HUEDevice21 dim06%
2018-12-22 14:29:14 HUEDevice Li_Sz_HUEDevice12 dim06%


Das Reading state tut so als wäre es gar nicht da. Ist das richtig? Ich weiß auch nicht , warum Gruppe 1 sich immer vorwitzig meldet.

Gruß Eberhard
Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

FHEm2005

Ich habe mal verbose 5 für die Gruppe3 hinzugenommen. Die Meldungen kann ich nicht interpretieren. HUEDevice12 und HUEDevice 21 sind die zur Gruppe gehörenden Tradfri Lampen.

2018.12.22 14:43:39 4 : using HUEBridge_HTTP_Request: PUT groups/3/action
2018.12.22 14:43:40 4 : using HUEBridge_HTTP_Request: GET groups/3
2018-12-22 14:43:40 HUEDevice Li_Sz_HUEGroup3 any_on: 0
2018-12-22 14:43:40 HUEDevice Li_Sz_HUEGroup3 all_on: 0
2018.12.22 14:43:40 4 : using HUEBridge_HTTP_Request: GET
2018.12.22 14:43:40 4 : parse status message for HUE
2018.12.22 14:43:40 4 : HUE: message for unknow sensor received: HUE-S1
2018.12.22 14:43:40 4 : HUE: message for unknow sensor received: HUE-S41
2018.12.22 14:43:40 4 : HUE: message for unknow sensor received: HUE-S30
2018.12.22 14:43:40 4 : HUE: message for unknow sensor received: HUE-S22
2018.12.22 14:43:40 4 : HUE: message for unknow sensor received: HUE-S26
2018.12.22 14:43:40 4 : HUE: message for unknow sensor received: HUE-S20
2018.12.22 14:43:40 4 : HUE: message for unknow sensor received: HUE-S5
2018.12.22 14:43:40 4 : HUE: message for unknow sensor received: HUE-S42
2018.12.22 14:43:40 4 : HUE: message for unknow sensor received: HUE-S44
2018-12-22 14:43:40 HUEDevice Li_Wz_HUEGroup1 off
2018-12-22 14:43:40 HUEDevice Li_Sz_HUEDevice12 off
2018-12-22 14:43:40 HUEDevice Li_Sz_HUEDevice21 off
2018.12.22 14:43:45 4 : using HUEBridge_HTTP_Request: PUT groups/3/action
2018.12.22 14:43:46 4 : using HUEBridge_HTTP_Request: GET groups/3
2018-12-22 14:43:46 HUEDevice Li_Sz_HUEGroup3 all_on: 1
2018-12-22 14:43:46 HUEDevice Li_Sz_HUEGroup3 any_on: 1
2018.12.22 14:43:46 4 : using HUEBridge_HTTP_Request: GET
2018.12.22 14:43:47 4 : parse status message for HUE
2018.12.22 14:43:47 4 : HUE: message for unknow sensor received: HUE-S22
2018.12.22 14:43:47 4 : HUE: message for unknow sensor received: HUE-S26
2018.12.22 14:43:47 4 : HUE: message for unknow sensor received: HUE-S20
2018.12.22 14:43:47 4 : HUE: message for unknow sensor received: HUE-S5
2018.12.22 14:43:47 4 : HUE: message for unknow sensor received: HUE-S1
2018.12.22 14:43:47 4 : HUE: message for unknow sensor received: HUE-S41
2018.12.22 14:43:47 4 : HUE: message for unknow sensor received: HUE-S30
2018.12.22 14:43:47 4 : HUE: message for unknow sensor received: HUE-S44
2018.12.22 14:43:47 4 : HUE: message for unknow sensor received: HUE-S42
2018-12-22 14:43:47 HUEDevice Li_Wz_HUEGroup1 off
2018-12-22 14:43:47 HUEDevice Li_Sz_HUEDevice12 dim06%
2018-12-22 14:43:47 HUEDevice Li_Sz_HUEDevice21 dim06%
2018.12.22 14:44:01 4 : using HUEBridge_HTTP_Request: GET lights
2018.12.22 14:44:13 1 : in ATTR
2018.12.22 14:44:13 1 : in ATTR
2018.12.22 14:44:15 1 : in ATTR
2018.12.22 14:44:15 1 : in ATTR
2018.12.22 14:44:21 1 : PERL WARNING: Use of uninitialized value $event in split at ./FHEM/93_RFHEM.pm line 164.
2018.12.22 14:44:21 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/93_RFHEM.pm line 166.


Gruß Eberhard
Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

popy

Hallo, verwende das Modul um meine 433 Mhz Lampen per HUE Bewegungsmelder usw. zu steuern.
In letzter Zeit habe ich aufgerüstet (6x BMs und je davon die 3 Devices angelegt).
Jetzt ist mir aufgefallen dass FHEM gähnend langsam wurde. apptime max bestätigt dass es an den hue updates leigt:


active-timers: 63; max-active timers: 66; max-timer-load: 22  min-tmrHandlingTm: 2.4ms; max-tmrHandlingTm: 1668.9ms; totAvgDly: 273.9ms

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
tmr-HUEBridge_GetUpdate                  HASH(0x14d9020)                       1368        6    7874.82  1312.47   334.77   197.95 23.12. 11:14:19 HASH(hueBridge1)
tmr-HUEDevice_GetUpdate                  HASH(0x23160d0)                       1186      286   17624.46    61.62  1645.61   272.67 23.12. 11:10:58 HASH(BM_Kueche_Tuer)
act_on_BM_Kueche_Tuer                    notify_Exec                           1018        5    2038.26   407.65     0.00     0.00 23.12. 11:13:32 HASH(act_on_BM_Kueche_Tuer); HASH(BM_Kueche_Tuer)
tmr-HUEDevice_GetUpdate                  HASH(0x1e85ea8)                        653      286   19454.56    68.02  1619.30   272.75 23.12. 11:08:49 HASH(BM_Badezimmer_Tuer)
tmr-HUEDevice_GetUpdate                  HASH(0x22c1ab8)                        614      287   17749.27    61.84  1612.10   272.76 23.12. 11:12:34 HASH(BM_Badezimmer_Wanne)
tmr-HUEDevice_GetUpdate                  HASH(0x1b45b78)                        593      286   15885.84    55.54  1630.34   272.71 23.12. 11:13:51 HASH(BM_Kammerl)
tmr-HUEDevice_GetUpdate                  HASH(0x2310d50)                        584      287   16599.39    57.84  1628.33   272.71 23.12. 11:11:36 HASH(LIGHT_Badezimmer_Wanne)
act_on_BM_Badezimmer                     notify_Exec                            575       22    5879.66   267.26     0.00     0.00 23.12. 11:08:49 HASH(act_on_BM_Badezimmer); HASH(BM_Badezimmer_Tuer)
tmr-HUEDevice_GetUpdate                  HASH(0x20415d8)                        529      286   17020.13    59.51  1626.64   273.12 23.12. 11:09:32 HASH(TEMP_Kammerl)
act_BM_Kammerl                           notify_Exec                            521        2     522.18   261.09     0.00     0.00 23.12. 11:13:51 HASH(act_BM_Kammerl); HASH(BM_Kammerl)
tmr-HUEDevice_GetUpdate                  HASH(0x2041018)                        521      286   16000.15    55.94  1623.80   273.15 23.12. 11:13:36 HASH(TEMP_Badezimmer)
KUECHE_Schraenke                         IT_Set                                 515        2    1029.76   514.88     0.00     0.00 23.12. 11:10:58 HASH(KUECHE_Schraenke); KUECHE_Schraenke; on
BAD_Decke                                IT_Set                                 514       11    5570.35   506.40     0.00     0.00 23.12. 11:10:12 HASH(BAD_Decke); BAD_Decke; on
CUL433                                   CUL_Get                                502       16    7903.55   493.97     0.00     0.00 23.12. 11:11:51 HASH(CUL433);  ; raw; isF0000FF00FFF
AR_Decke                                 IT_Set                                 501        3     503.39   167.80     0.00     0.00 23.12. 11:13:51 HASH(AR_Decke); AR_Decke; on
KUECHE_Decke                             IT_Set                                 494        2     988.54   494.27     0.00     0.00 23.12. 11:10:58 HASH(KUECHE_Decke); KUECHE_Decke; on
tmr-HUEDevice_GetUpdate                  HASH(0x2041c98)                        493      286   16485.81    57.64  1620.96   273.12 23.12. 11:09:42 HASH(TEMP_Toilette)
CUL433                                   CUL_Read                               411        9     451.44    50.16     0.00     0.00 23.12. 11:08:40 HASH(CUL433)
tmr-HUEDevice_GetUpdate                  HASH(0x232b3b0)                        408      286   15554.04    54.38  1616.77   272.66 23.12. 11:09:39 HASH(DIM_VR_Master_Dimmer)
tmr-HUEDevice_GetUpdate                  HASH(0x22f5b10)                        398      287   16242.91    56.60  1606.95   272.55 23.12. 11:13:38 HASH(TEMP_Kueche_Essbereich)
tmr-HUEDevice_GetUpdate                  HASH(0x2310690)                        350      287   15559.57    54.21  1688.70   272.72 23.12. 11:13:33 HASH(LIGHT_Kammerl)
WEB_192.168.0.1_57774                    FW_Read                                164        4     207.84    51.96     0.00     0.00 23.12. 11:11:53 HASH(WEB_192.168.0.1_57774)
tmr-HUEDevice_GetUpdate                  HASH(0x22c2028)                        133      287   15520.80    54.08  1608.62   272.58 23.12. 11:09:35 HASH(BM_Kueche_Essbereich)
tmr-HUEDevice_GetUpdate                  HASH(0x232c360)                        132      286   15319.82    53.57  1619.08   272.65 23.12. 11:11:45 HASH(DIM_SZ_Tobi_Dimmer)
tmr-HUEDevice_GetUpdate                  HASH(0x2316790)                        127      286   15347.53    53.66  1640.44   272.66 23.12. 11:14:35 HASH(LIGHT_Kueche_Tuer)
tmr-HUEDevice_GetUpdate                  HASH(0x230eba0)                        126      287   15157.71    52.81  1697.38   272.70 23.12. 11:13:25 HASH(LIGHT_Toilette)
tmr-HUEDevice_GetUpdate                  HASH(0x23051f0)                        122      287   15893.91    55.38  1706.74   272.71 23.12. 11:10:35 HASH(LIGHT_Kueche_Essbereich)
tmr-HUEDevice_GetUpdate                  HASH(0x1e85b60)                        120      287   15247.94    53.13  1697.26   272.72 23.12. 11:08:45 HASH(BM_Toilette)
tmr-HUEDevice_GetUpdate                  HASH(0x232bdd0)                        111      286   15272.45    53.40  1619.44   272.66 23.12. 11:12:15 HASH(DIM_SZ_Stefi_Dimmer)
tmr-WakeUpFn                             HASH_unnamed                           106        3     140.81    46.94   221.96   164.50 23.12. 11:08:54 HASH(0x25f0f08)
ECHO_Badezimmer                          echodevice_Set                         105        4     158.18    39.54     0.00     0.00 23.12. 11:08:54 HASH(ECHO_Badezimmer); ECHO_Badezimmer; volume; 22
tmr-HUEDevice_GetUpdate                  HASH(0x2315a10)                        104      287   14778.43    51.49  1636.09   272.73 23.12. 11:09:33 HASH(TEMP_Kueche_Tuer)
myBroker                                 MQTT::Read                             100        9     294.80    32.76     0.00     0.00 23.12. 11:14:06 HASH(myBroker)
WEB_192.168.0.1_57912                    FW_Read                                 90       12     325.49    27.12     0.00     0.00 23.12. 11:14:29 HASH(WEB_192.168.0.1_57912)
tmr-echodevice_GetSettings               HASH(0x1cd9330)                         88        6     226.10    37.68   377.56   195.67 23.12. 11:13:20 HASH(ECHO_Wohnzimmer)
WEB                                      FW_Read                                 86       44    2783.58    63.26     0.00     0.00 23.12. 11:09:10 HASH(WEB)
act_EchoVoice                            notify_Exec                             62      395     253.49     0.64     0.00     0.00 23.12. 11:14:39 HASH(act_EchoVoice); HASH(ECHO_Julians_Zimmer)
RoomCMD                                  dummy_Set                               45        4      78.27    19.57     0.00     0.00 23.12. 11:14:39 HASH(RoomCMD); RoomCMD; unknown
tmr-echodevice_GetSettings               HASH(0x1b1f800)                         36        6     198.09    33.02   394.12   189.69 23.12. 11:13:26 HASH(Alexas)
act_RoomCMD                              notify_Exec                             35        2      61.13    30.57     0.00     0.00 23.12. 11:14:39 HASH(act_RoomCMD); HASH(RoomCMD)
Alexas                                   echodevice_Get                          32        2      55.76    27.88     0.00     0.00 23.12. 11:14:39 HASH(Alexas); Alexas; settings


Habe dann in diesem Thread gestöber und bin auf httpUtils & pollDevices gestoßen.
polldevices ist ja default auf 1, da habe ich mal so belassen, der Intervall ist bei der Bridge auf 60 (default).
Habe dann httpUtils auf 1 gestellt (= non blocking) und Siehe da, fhem WEB läuft wieder flüssig.
Leider ist mein log dann voll von:


2018.12.23 10:58:51 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:51 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:51 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:51 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:51 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:51 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:51 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:51 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:52 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:52 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:52 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:52 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:52 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:52 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:53 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:53 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:53 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:53 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:53 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 10:58:53 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer


Und es funktioniert auch nicht mehr so richtig.
Ich habe eine Bridge erster Generation, kann es daran liegen?

Habt ihr noch eine Idee wie ich mein fhemWEB wieder etwas beschleunigen könnte?

Frohe Weihnachten
Danke
pOpY

popy

Habe das Problem gefunden.
Hatte alle Geräte (BM, Temperatur des BM, Helligkeit beim BM) mit Intervall 1 Sekunde angelegt gehabt (jaja, das liebe copy und paste)  ;)
Natürlich war jetzt fhem blockierend (httpUtils nicht definiert) damit beschäftigt die hue bridge zu pollen, was zu den hängern führte.
Habe jetzt bei allen nicht so wichtigen Geräten (Temperatur des BM, Helligkeit beim BM) das Intervall nicht definiert und pollDevices auf 2 gestellt.

Mit httputils nicht gesetzt, sieht man jetzt in apptime nur mehr die getupdates der BM, und im Log keine Probleme.
Auch das fhemWEB geht schneller.

Jetzt möchte ich aber die http requests auf non blocking umstellen (=httpUtils 1), dann kommt ca. jede Minute ein paar mal "Connection reset by peer".
Funktionieren tut aber alles.

Gibt es da noch irgendwelche Einstellungen um die Fehler "Connection reset by peer" einzudämmen?
Hat von euch jemand BM, die ja schnell ansprechen sollen? Wenn ja, was für Intervall Einstellungen?
Oder einfach verbose des Geräts umstellen und damit leben?

Danke
pOpY



popy

Und nochmals ich mit einem Update.
Habe jetzt httpUtils auf 1 gesetzt um es zu aktivieren, da dann fhemWEB wieder top läuft (mit apptime max Bestätigt), auch sonst funktioniert bis auf die "Connection reset by peer" alles wunderbar und schnell. Ich glaube das Problem ist dass bei einem kompletten GET von der Bridge diese zu lange braucht und keine weiteren anfragen in der Zeit annimmt.
Sehen tut man das schön im Log wenn man verbose auf 5 stellt von der bridge, das intervall ist auf 60 Sekunden und alle 60 Sekunden kommen nun diese Fehler.
Meine BM pollt fhem im 1sec intervall (wegen der Ansprechzeit), alle anderen Devices haben kein INtervall gesetzt -> somit pollt das die bridge alles 60 Sekunden.

Beispiel 1 - das get um 14:25:11 & der erste connection reset by peer um 14:25:12
Hier das Log:


2018.12.23 14:25:09 4: using HttpUtils_NonblockingGet: GET sensors/11
2018.12.23 14:25:09 4: using HttpUtils_NonblockingGet: GET sensors/14
2018.12.23 14:25:09 4: using HttpUtils_NonblockingGet: GET sensors/17
2018.12.23 14:25:09 4: using HttpUtils_NonblockingGet: GET sensors/20
2018.12.23 14:25:09 4: using HttpUtils_NonblockingGet: GET sensors/22
2018.12.23 14:25:09 4: using HttpUtils_NonblockingGet: GET sensors/5
2018.12.23 14:25:09 4: using HttpUtils_NonblockingGet: GET sensors/8
2018.12.23 14:25:10 4: using HttpUtils_NonblockingGet: GET sensors/11
2018.12.23 14:25:10 4: using HttpUtils_NonblockingGet: GET sensors/14
2018.12.23 14:25:10 4: using HttpUtils_NonblockingGet: GET sensors/17
2018.12.23 14:25:10 4: using HttpUtils_NonblockingGet: GET sensors/20
2018.12.23 14:25:10 4: using HttpUtils_NonblockingGet: GET sensors/22
2018.12.23 14:25:10 4: using HttpUtils_NonblockingGet: GET sensors/5
2018.12.23 14:25:10 4: using HttpUtils_NonblockingGet: GET sensors/8
2018.12.23 14:25:11 4: using HttpUtils_NonblockingGet: GET sensors/11
2018.12.23 14:25:11 4: using HttpUtils_NonblockingGet: GET sensors/14
[b]2018.12.23 14:25:11 4: using HttpUtils_NonblockingGet: GET [/b]
2018.12.23 14:25:11 4: using HttpUtils_NonblockingGet: GET sensors/17
2018.12.23 14:25:11 4: using HttpUtils_NonblockingGet: GET sensors/20
2018.12.23 14:25:11 4: using HttpUtils_NonblockingGet: GET sensors/22
2018.12.23 14:25:11 4: using HttpUtils_NonblockingGet: GET sensors/5
2018.12.23 14:25:11 4: using HttpUtils_NonblockingGet: GET sensors/8
2018.12.23 14:25:12 4: using HttpUtils_NonblockingGet: GET sensors/11
2018.12.23 14:25:12 4: using HttpUtils_NonblockingGet: GET sensors/14
[b]2018.12.23 14:25:12 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer[/b]
2018.12.23 14:25:12 4: using HttpUtils_NonblockingGet: GET sensors/17
2018.12.23 14:25:12 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 14:25:12 4: using HttpUtils_NonblockingGet: GET sensors/20
2018.12.23 14:25:12 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 14:25:12 4: using HttpUtils_NonblockingGet: GET sensors/22
2018.12.23 14:25:12 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 14:25:12 4: using HttpUtils_NonblockingGet: GET sensors/5
2018.12.23 14:25:12 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 14:25:13 4: using HttpUtils_NonblockingGet: GET sensors/8
2018.12.23 14:25:13 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 14:25:13 4: parse status message for hueBridge1
2018.12.23 14:25:13 4: hueBridge1: message for unknow sensor received: hueBridge1-S1
2018.12.23 14:25:13 4: hueBridge1: message for unknow sensor received: hueBridge1-S13
2018.12.23 14:25:13 4: hueBridge1: message for unknow sensor received: hueBridge1-S9
2018.12.23 14:25:13 4: using HttpUtils_NonblockingGet: GET sensors/11
2018.12.23 14:25:13 4: using HttpUtils_NonblockingGet: GET sensors/14
2018.12.23 14:25:13 4: using HttpUtils_NonblockingGet: GET sensors/17
2018.12.23 14:25:13 4: using HttpUtils_NonblockingGet: GET sensors/20
2018.12.23 14:25:13 4: using HttpUtils_NonblockingGet: GET sensors/22
2018.12.23 14:25:13 4: using HttpUtils_NonblockingGet: GET sensors/5
2018.12.23 14:25:14 4: using HttpUtils_NonblockingGet: GET sensors/8
2018.12.23 14:25:14 4: using HttpUtils_NonblockingGet: GET sensors/11
2018.12.23 14:25:14 4: using HttpUtils_NonblockingGet: GET sensors/14
2018.12.23 14:25:14 4: using HttpUtils_NonblockingGet: GET sensors/17
2018.12.23 14:25:14 4: using HttpUtils_NonblockingGet: GET sensors/20
2018.12.23 14:25:14 4: using HttpUtils_NonblockingGet: GET sensors/22
2018.12.23 14:25:14 4: using HttpUtils_NonblockingGet: GET sensors/5
2018.12.23 14:25:15 4: using HttpUtils_NonblockingGet: GET sensors/8
2018.12.23 14:25:15 4: using HttpUtils_NonblockingGet: GET sensors/11
2018.12.23 14:25:15 4: using HttpUtils_NonblockingGet: GET sensors/14
2018.12.23 14:25:15 4: using HttpUtils_NonblockingGet: GET sensors/17
2018.12.23 14:25:15 4: using HttpUtils_NonblockingGet: GET sensors/20
2018.12.23 14:25:15 4: using HttpUtils_NonblockingGet: GET sensors/22


Beispiel 2 - das get um 14:26:11 & der erste connection reset by peer um 14:26:12 (alles genau eine Sekunde später)
Hier das Log:


2018.12.23 14:26:09 4: using HttpUtils_NonblockingGet: GET sensors/14
2018.12.23 14:26:10 4: using HttpUtils_NonblockingGet: GET sensors/17
2018.12.23 14:26:10 4: using HttpUtils_NonblockingGet: GET sensors/20
2018.12.23 14:26:10 4: using HttpUtils_NonblockingGet: GET sensors/22
2018.12.23 14:26:10 4: using HttpUtils_NonblockingGet: GET sensors/5
2018.12.23 14:26:10 4: using HttpUtils_NonblockingGet: GET sensors/8
2018.12.23 14:26:10 4: using HttpUtils_NonblockingGet: GET sensors/11
2018.12.23 14:26:10 4: using HttpUtils_NonblockingGet: GET sensors/14
2018.12.23 14:26:11 4: using HttpUtils_NonblockingGet: GET sensors/17
2018.12.23 14:26:11 4: using HttpUtils_NonblockingGet: GET sensors/20
2018.12.23 14:26:11 4: using HttpUtils_NonblockingGet: GET sensors/22
2018.12.23 14:26:11 4: using HttpUtils_NonblockingGet: GET sensors/5
2018.12.23 14:26:11 4: using HttpUtils_NonblockingGet: GET sensors/8
[b]2018.12.23 14:26:11 4: using HttpUtils_NonblockingGet: GET [/b]
2018.12.23 14:26:11 4: using HttpUtils_NonblockingGet: GET sensors/11
2018.12.23 14:26:11 4: using HttpUtils_NonblockingGet: GET sensors/14
2018.12.23 14:26:12 4: using HttpUtils_NonblockingGet: GET sensors/17
2018.12.23 14:26:12 4: using HttpUtils_NonblockingGet: GET sensors/20
2018.12.23 14:26:12 4: using HttpUtils_NonblockingGet: GET sensors/22
2018.12.23 14:26:12 4: using HttpUtils_NonblockingGet: GET sensors/5
2018.12.23 14:26:12 4: using HttpUtils_NonblockingGet: GET sensors/8
[b]2018.12.23 14:26:12 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer[/b]
2018.12.23 14:26:12 4: using HttpUtils_NonblockingGet: GET sensors/11
2018.12.23 14:26:12 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 14:26:12 4: using HttpUtils_NonblockingGet: GET sensors/14
2018.12.23 14:26:13 2: hueBridge1: http request failed: 192.168.0.2: Connection reset by peer
2018.12.23 14:26:13 4: parse status message for hueBridge1
2018.12.23 14:26:13 4: hueBridge1: message for unknow sensor received: hueBridge1-S13
2018.12.23 14:26:13 4: hueBridge1: message for unknow sensor received: hueBridge1-S9
2018.12.23 14:26:13 4: hueBridge1: message for unknow sensor received: hueBridge1-S1
2018.12.23 14:26:13 4: using HttpUtils_NonblockingGet: GET sensors/17
2018.12.23 14:26:13 4: using HttpUtils_NonblockingGet: GET sensors/20
2018.12.23 14:26:13 4: using HttpUtils_NonblockingGet: GET sensors/22
2018.12.23 14:26:13 4: using HttpUtils_NonblockingGet: GET sensors/5
2018.12.23 14:26:13 4: using HttpUtils_NonblockingGet: GET sensors/8
2018.12.23 14:26:13 4: using HttpUtils_NonblockingGet: GET sensors/11
2018.12.23 14:26:14 4: using HttpUtils_NonblockingGet: GET sensors/14
2018.12.23 14:26:14 4: using HttpUtils_NonblockingGet: GET sensors/17
2018.12.23 14:26:14 4: using HttpUtils_NonblockingGet: GET sensors/20
2018.12.23 14:26:14 4: using HttpUtils_NonblockingGet: GET sensors/22
2018.12.23 14:26:14 4: using HttpUtils_NonblockingGet: GET sensors/5
2018.12.23 14:26:14 4: using HttpUtils_NonblockingGet: GET sensors/8
2018.12.23 14:26:14 4: using HttpUtils_NonblockingGet: GET sensors/11
2018.12.23 14:26:15 4: using HttpUtils_NonblockingGet: GET sensors/14
2018.12.23 14:26:15 4: using HttpUtils_NonblockingGet: GET sensors/17
2018.12.23 14:26:15 4: using HttpUtils_NonblockingGet: GET sensors/20
2018.12.23 14:26:15 4: using HttpUtils_NonblockingGet: GET sensors/22


Habe dann daraufhin verbose der bridge auf 1 anstatt (global) 2 gestellt und nun sind diese Meldungen versteckt.
Wie macht ihr das (pollDevices, httpUtils, Intervall usw.)?

PS.: Ich hoffe das ist noch verständlich was ich da von mir gebe :-)

Danke
pOpY


obelix221

Guten Morgen zusammen,

seit gestern habe ich das Problem, dass sich meine lightify Lampen nicht mehr einzeln schalten lassen, nur über Gruppen scheinen diese ansteuerbar zu sein.

Zusätzliche Info:
1) Das Ausschalten in fhem über eine Gruppe klappt problemlos
2) Das Anschalten über eine scene über eine Gruppe in fhem klappt nicht. Hier werden nur die original HUE Lampen angeschaltet, die Osrams bleiben aus.
3) Das gleiche Verhalten habe ich auch mit der HUE App auf iOS. Die einzelnen Osram Lampen lassen sich nicht mehr schalten.


--> Also kein FHEM Problem, ich gehe davon aus, dass es wohl an einem Update der Bridge liegt. Kennt jemand das Problem?
Auch wenn es kein FHEM Problem ist, sind sind hier so kompetente User unterwegs, die entweder das Problem schon kennen, oder mir eine Hilfestellung geben können.


VG
Obelix
RPi3 als FHEM-Server, 868 MHz CUL, 433 MHz Transmitter, Homematic Aktoren und Sensoren, Yamaha AVR, Logitech Harmony, Fritzbox, Logitech SB, 433 MHz Steckdosen, HUE, EnOcean

ralfix

Nachtrag:
Meine 2. und letzte  Osram Classic A60 RGBW an der HUE-Bridge hat sich soeben mit einem unangenehmen Geruch verabschiedet.
HUE und Tradfri zeigen noch keine Ermüdungserscheinungen.

Gruß Ralf

justme1968

die einzige osram birne die ich in verwendung hatte ist auch nach einer weile mit knall und gestank über den jordan gegangen.

osram hat aus kulanz ohne irgendwelche nachweise ersatz geschickt. die liegt aber immer noch im schrank.

keine phillips lampe hat bis jetzt ausfälle.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

P.A.Trick

Zitat von: justme1968 am 03 Januar 2019, 21:15:58
die einzige osram birne die ich in verwendung hatte ist auch nach einer weile mit knall und gestank über den jordan gegangen.

osram hat aus kulanz ohne irgendwelche nachweise ersatz geschickt. die liegt aber immer noch im schrank.

keine phillips lampe hat bis jetzt ausfälle.

Sieht bei mir ähnlich aus. Keine Ausfälle bei Phillips und Ikea. Die A60RGBW haben sich alle nach ungefähr 2 Jahren verabschiedet. Die OSRAM Lightstrips funktionieren aber bisher einwandfrei.
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

DazDavid

Hallo Zusammen,

ist es irgendwie möglich, die Ikea Tradfri Fernbedienung (nicht den Dimmer) über das Hue Modul nach FHEM zu bekommen um ihn als Trigger für Notifys zu verwenden?
Ich nutze das Raspbee Gateway von Dresden Elektronik und bekomme über autocreate lediglich die Gruppe des Schalters, nicht aber den Schalter selbst wie bei den Hue Dimmschaltern.

Gruß
David
FHEM (up2date) on Raspberry Pi 3B | nanoCUL 868 MHz | Raspbee Zigbee Gateway | Philips Hue | Osram Lightify | MAX Thermostate

justme1968

sensoren müssen von hand angelegt werden. nur lampen werden automatisch angelegt.

wie es geht steht im wiki.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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