philips hue modul

[volschin]

Etwas wenig Informationen.
1. Eventmonitor anwerfen und Deine Regex eingeben.
2. Schauen, was bei einer manuellen Operation alles für Events geworfen werden. Ich vermute, dein Regex ist zu globalgalaktisch.
3. Wenn Du dein Regex passend auf das Event hast, schauen, ob in EVT_PART1 auch das richtige steht.

[typturbo]

Hallo,

soeben die HueBridge auf "1934058060" geupdatetd. App funktioniert normal.

Status in Fhem Connected.
States der Geräte werden auch abgeholt.

Error beim setzen :"invalid/missing parameters in body" bei allen set Kommandos.

jmd eine Idee was zu tun ist?

[stera]

Hallo zusammen,

ich habe schon seit einiger Zeit ein HUE Gateway im Einsatz und habe mir vor kurzen ein Conbee II Stick von Dresden Elektronik bestellt.
Das ganze habe ich auf einem Stand-Alone Raspberry installiert und eingerichtet. Den Conbee Stick wollte ich eigentlich gerne parallel für Sensoren verwenden.
Komischerweise kam es nun paar Tage später zu erheblichen Problemen mit FHEM. Es fing damit an, dass die HUE-Bridge sich aufgehängt und nicht erreichbar war. Obwohl "attr httpUtils 1" ist, hängt FHEM beim nicht erreichen. Seit dem bzw. auch nach dem Neustart, bleibt FHEM sofort hängen, wenn ich den Stick nur reinstecke (Es würde nur Strom reichen)
Habe schon versucht die Zigbee Kanäle zu verändern, aber es hilft leider nichts. Wenn ich das HUE-Modul von der HUE-Bridge mit "Disable 1" vorher ausschalte ist alles Okay. Die HUE-App auf dem Handy lässt sich auch normal bedienen im Fehlerfall.

Hatte verbose leider auf "0". Werde sonst nochmal die Logs nachreichen mit "5".

Vllt. habt ihr schon eine Idee, was ich noch ausprobieren könnte bzw. was da so massiv stört! 

Danke,
Stefan

[volschin]

Also ich habe zwar nicht den ConBee II, sondern das RaspBee-Modul gleichen Herstellers. Das läuft bombenstabil.
Hast Du autocreate in FHEM abgeschaltet? Was hast Du sonst an Geräten an den USB-Buchsen?

Und mach mal ein List von deinem deCONZ HueBridge Device.

[stera]

Danke für die Antwort.

Ich denke ich muss das voerst korrigieren und bin mir nicht mehr sicher ob es überhaupt mit den HUEBridge - ConbeeBridge zusammenhängt.

Problem ist immer noch, auch wenn weniger, das Fhem für ca. 5min hängt und danach Fehlermeldung im Log sind, dass mehrere Netzwerkgeschichten nicht gefunden wurden.
Das gehe ich gerade mit verbose 5 auf den Grund. Satte 1,8Millionen Einträge in 2 Std (430MB)  Habe mir dann per Telegram jede Minute ein Alive geschickt und konnte die 4-5min im Log ausfindig machen, die fehlen. Habe nun erstmal die SynologyÜberwachung ausgestellt vom letzten Eintrag. Habe alles in einer VM laufen und habe schon ein Snapshot von weiter zurück hergestellt. Immer das gleiche. Scheint irgendein Netzwerkproblem zu sein.
Komische Sache..

Code Auswählen Erweitern



2019.09.16 15:16:15 4: parse status message for HUE_BWM_BadUnten
2019.09.16 15:16:15 4: HUE_BWM_BadUnten: use offsetUTC 7200 from bridge
2019.09.16 15:16:15 5: HttpUtils url=http://192.168.10.65:5000/webapi/entry.cgi?api=SYNO.SurveillanceStation.Camera&version=8&method="GetCapabilityByCamId"&cameraId=5&_sid="yxxxx"
2019.09.16 15:16:15 4: IP: 192.168.10.65 -> 192.168.10.65
2019.09.16 15:16:15 5: HttpUtils request header:
GET /webapi/entry.cgi?api=SYNO.SurveillanceStation.Camera&version=8&method="GetCapabilityByCamId"&cameraId=5&_sid="xxxx" HTTP/1.0
Host: 192.168.10.65:5000
User-Agent: fhem
Accept-Encoding: gzip,deflate
Accept: application/json

2019.09.16 15:20:20 4: HttpUtils: <hidden>: Can't connect(2) to https://api.telegram.org:443:  SSL wants a read first
2019.09.16 15:20:20 5: TelegramBot_Callback TelegramInfoBot: called from Polling
2019.09.16 15:20:20 5: TelegramBot_Callback TelegramInfoBot: polling returned result? <undef>


[stera]

Hallo,

habe jetzt nochmal weiter Ursachenforschung gemacht und denke momentan wieder bisschen mehr an die HueBridge. Sobald ich die zweite HUEBridge(Conbee) hinzufüge, habe ich ganz oft die Hänger vom System. Habe nun das SynologyCam Modul abgestellt und alle Device mit ConbeeBridge gelöscht. Der Fehler tritt nun seltener, aber immer wieder noch auf. Auffällig war auch das S7-Modul, aber das hatte ich zwischenzeitlich auch rausgeschmissen ohne Erfolg.
Ich hänge mal eine Auswertung mit Apptime ran, dort ist die HueBridge doch etwas auffällig oder? Besonders beim MaxDelay. Hängt das ganze evtl mit dem Update um den 7.9 zusammen? Belastend scheinen ja generell das pollen vom Bewegungsmelder zu sein. Das ist ja einer der Gründe, diese auf Conbee umzustellen, um den Push zu nutzen.

Apptime maxDly

Code Auswählen Erweitern


name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
tmr-HUEDevice_GetUpdate                  HASH(0x55d391deec88)                   449    45692  740977.72    16.22 68145.60    53.29 18.09. 05:38:24 HASH(HUE_BadUnten_Schalter)
tmr-HUEDevice_GetUpdate                  HASH(0x55d391f43838)                   618    45692  693663.00    15.18 68141.30    53.31 18.09. 06:21:51 HASH(HUE_BWM_BadUnten)
tmr-HUEDevice_GetUpdate                  HASH(0x55d3911cc4c8)                   910    45692  663633.29    14.52 68135.85    53.36 17.09. 20:37:45 HASH(HUE_BW_Terrasse_motion)
tmr-HUEDevice_GetUpdate                  HASH(0x55d3919cb580)                  1586    45692  771448.10    16.88 68132.15    53.33 18.09. 07:00:25 HASH(HUE_BW_FlurUnten_motion)
tmr-HUEDevice_GetUpdate                  HASH(0x55d3919b1b90)                  1106    45692  753495.93    16.49 68130.14    53.34 17.09. 20:59:02 HASH(HUE_BW_FlurOben_motion)
tmr-HUEDevice_GetUpdate                  HASH(0x55d3919c3bd0)                   800    45692  725833.17    15.89 68012.53    53.29 18.09. 07:02:22 HASH(HUE_BW_HWR_motion)
tmr-HUEDevice_GetUpdate                  HASH(0x55d391e65488)                   191    45692  695902.86    15.23 68012.29    53.32 17.09. 18:27:45 HASH(HUE_BW_Terrasse2_motion)
tmr-HUEDevice_GetUpdate                  HASH(0x55d3919be100)                   831    45692  674739.25    14.77 68011.54    53.30 18.09. 07:02:52 HASH(HUE_BW_Carport_motion)
tmr-S7_GetUpdate                         HASH(0x55d3918d4528)                   768    45687  791426.32    17.32 67998.29    36.82 18.09. 05:35:31 HASH(myLogo)
tmr-at_Exec                              HASH(0x55d3918c11c0)                   283      803   35913.12    44.72 63044.88   145.30 18.09. 03:21:42 HASH(at_fp_time)
tmr-S7_GetUpdate                         HASH(0x55d391dc0c08)                   613    42937  456976.16    10.64 61307.72    17.51 18.09. 05:37:20 HASH(SPS_S7Aussen)
tmr-PRESENCE_StartLocalScan              HASH(0x55d38e4283b0)                   397      799   42143.04    52.74 61266.14    90.96 17.09. 22:02:35 HASH(LAN_Diskstation)
tmr-PRESENCE_StartLocalScan              HASH(0x55d390a82200)                   437      799   42145.35    52.75 58628.32    94.92 18.09. 07:22:16 HASH(WLANTabletLenovo)
tmr-WOL_UpdateReadings                   HASH(0x55d3919919c0)                   349      784   39922.87    50.92 58469.60    91.86 17.09. 19:01:30 HASH(WOL_SATReceiver)
tmr-ENIGMA2_GetStatus                    HASH(0x55d39188f6c8)                    54     1069    3795.92     3.55 51617.43    65.39 18.09. 06:52:51 HASH(SATReceiver)
tmr-HUEBridge_GetUpdate                  HASH(0x55d391896f00)                  1600      802  294451.74   367.15 48638.15    76.39 18.09. 05:33:57 HASH(HUEBridge1)
tmr-FHEM::GardenaSmartBridge::getDevices HASH(0x55d391e60698)                    46     1555    4997.45     3.21 47767.26    46.04 17.09. 20:21:43 HASH(GardenaBridge)
tmr-FW_closeInactiveClients              0                                       35      803    2323.19     2.89 45792.80   433.93 18.09. 06:56:45 0


Apptime max

Code Auswählen Erweitern


name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
tmr-S7_connect                           HASH(0x55d391dc0c08)                 67989      447 1342776.89  3003.98   285.23     8.21 18.09. 05:46:44 HASH(SPS_S7Aussen)
tmr-TPLinkHS110_Get                      HASH(0x55d390990060)                  3531      157   12056.58    76.79   386.13    15.91 17.09. 18:31:59 HASH(TPLINK_SD_FernseherWZ)
myDbLog                                  DbLog_Get                             3324       15    5472.82   364.85     0.00     0.00 17.09. 22:00:57 HASH(myDbLog); myDbLog; HISTORY; INT; 2019-09-16_22:05:00; 2019-09-17_22:04:59; HM_Zaehlersensor_Gas:gasCntGesamt::delta-h
d_rpc010025BidCos_RF                     HMCCURPCPROC_Read                     2479     2600  152019.92    58.47     0.00     0.00 17.09. 18:18:53 HASH(d_rpc010025BidCos_RF)
tmr-DOIF_TimerTrigger                    REF(0x55d3964d4d18)                   1611        1    1611.99  1611.99     0.90     0.90 18.09. 04:20:01 REF(0x55d3964d4d18)
tmr-HUEBridge_GetUpdate                  HASH(0x55d391896f00)                  1600      795  292677.08   368.15 48638.15    77.05 18.09. 05:33:57 HASH(HUEBridge1)
tmr-HUEDevice_GetUpdate                  HASH(0x55d3919cb580)                  1586    45278  765225.81    16.90 68132.15    53.62 18.09. 07:00:25 HASH(HUE_BW_FlurUnten_motion)
tmr-HUEDevice_GetUpdate                  HASH(0x55d391d754e0)                  1355       14    7375.70   526.84   328.93    28.33 18.09. 05:59:48 HASH(HUE_BadOben_Gruppe)
HUEBridge1                               HUEBridge_Set                         1288      103   32001.62   310.70     0.00     0.00 18.09. 05:59:48 HASH(HUEBridge1); HUEBridge1; statusRequest
doif_Amad.Tablet                         DOIF_Notify                           1281    56603   36350.95     0.64     0.00     0.00 18.09. 07:00:25 HASH(doif_Amad.Tablet); HASH(HUE_BW_FlurUnten_motion)
tmr-Calendar_PollChild                   HASH(0x55d3918a7220)                  1234       13   10918.26   839.87   900.95    76.57 18.09. 00:00:04 HASH(Abfall)
tmr-HUEDevice_GetUpdate                  HASH(0x55d3919b1b90)                  1106    45278  747348.62    16.51 68130.14    53.63 17.09. 20:59:02 HASH(HUE_BW_FlurOben_motion)
doif_UeberwachungLampen                  DOIF_Notify                            957    56603   35674.78     0.63     0.00     0.00 18.09. 04:20:01 HASH(doif_UeberwachungLampen); HASH(Taktmerker)
tmr-DOIF_TimerTrigger                    REF(0x55d395eb0728)                    919        1     919.15   919.15     0.81     0.81 18.09. 03:15:00 REF(0x55d395eb0728)
tmr-ONKYO_AVR_connectionCheck            HASH(0x55d39198b000)                   918      784   33974.55    43.33 42575.11    71.06 18.09. 07:00:58 HASH(MusikReceiver)
tmr-HUEDevice_GetUpdate                  HASH(0x55d3911cc4c8)                   910    45278  657543.82    14.52 68135.85    53.66 17.09. 20:37:45 HASH(HUE_BW_Terrasse_motion)


[DS_Starter]

Hallo stera,

wenn ich das lese:

2019.09.16 15:20:20 4: HttpUtils: <hidden>: Can't connect(2) to https://api.telegram.org:443:  SSL wants a read first
2019.09.16 15:20:20 5: TelegramBot_Callback TelegramInfoBot: called from Polling
2019.09.16 15:20:20 5: TelegramBot_Callback TelegramInfoBot: polling returned result? <undef>

gehe ich davon aus, dass du ebenfalls dieses hier beschriebene Problem mit Telegrmbot-Polling hast: https://forum.fhem.de/index.php/topic,38328.msg975159.html#msg975159

Im Thread ff gibt es auch einen Lösungsweg dn wir gerade gemeinsam testen.

Grüße,
Heiko

[justme1968]

ich glaube nicht das die ursache im hue modul liegt. schon garnicht wenn die blockaden 5 minuten dauern.

wenn du ganz allgemeine netzwerk probleme hast wie sie logs oben andeuten dann siehst du die natürlich auch beim pollen.

stell mal alles auf nonblocking und setz das intervall hoch und schau ob das einen unterschied macht.

[DS_Starter]

Ich vermute wie geschrieben das Polling von Telegram. Da wäre stera nicht der einzige. Wir testen gerade eine Änderung in HttpUtils mit der das Problem beseitigt ist.

Grüsse,
Heiko

[stera]

Super vielen Dank für die Antworten.

@Heiko: Ich habe die httpUtils.pm gleich angepasst und nun abwarten.

Wäre schön, wenn es daran lag.

Danke,
Stefan

[cyablo]

Moin,

ich hab jetzt schon seit einiger zeit Probleme mir "on-for-timer" bei den Hue Lampen. Unregelmäßig schalten sich die Lampen nach ablauf des Timers nicht wieder aus. Das Problem besteht bei allen Lampen, nicht nur bei einer und ist nur auf Hue beschränkt. Sonoff kappt z.B. einwandfrei.

Leider gibt es keine Meldung dazu und ich erkenne auch kein System. Kann es aber bei ca. 1 von 5 Versuchen reproduzieren. Manuell lassen sich die Lampen über FHEM auch korrekt wieder aus schalten wenn Sie an bleiben.

FHEM sowie die Hue Bridge sind auf dem neusten Stand.

Jemand eine Idee wie dem ganzen auf den Grund gehen kann?

[Master_Nick]

Also bei mir tritt genau sowas auf, wenn die Lampen nicht so wirklich guten Wifi Empfang haben. Und eher sporadisch mit der Bridge sprechen können.

[cyablo]

Eine von denen hat eine Entfernung von 2m Sichtweite ohne Hindernis. Das möchte ich daher mal ausschließen. Es hat ja vorher auch monatelang einwandfrei funktioniert.

[Master_Nick]

   Ca. so dachte ich bei meinem auch. Gut das ist ein ESP8266 (also keine original Hue) ich stellte aber fest, dass mein Accesspoint wohl herum spackte...

Die HUE Kommunikation ist aus meiner Sicht nicht wie z.b. MQTT qualitätsüberwacht - also es wird nicht sichergestellt, dass etwas ankommt. Sobald dann einmal wo was aussetzt oder nicht passt.... bleibt es eben auf der Strecke (Lampe bleibt an)
(Belehrt mich wenn ich falsch liege)

[binford6000]

Code Auswählen Erweitern

Can't call method "Dumper" on unblessed reference at ./FHEM/31_HUEDevice.pm line 1215.

@binford6000: lösch die betreffende zeile aus dem modul. ich schau es mir an.

@justme1968: Hast du hier schon was machen können?
Ich habe seitdem die 31_HUEDevice.pm aus dem Update ausgeschlossen.

VG Sebastian