[gelöst] HUEBridge V1 startet nicht mehr

[wk]

Hallo justme1968,

diesen Vorschlag habe ich schon in Antwort #2 umgesetzt. Siehe Ergebnis und Frage daraus.

Als nächstes habe ich in fhem eine neue Bridge definiert mit Angabe der IP.
Resultat:

Code Auswählen Erweitern

2020.08.14 10:45:24 2: HB1: invalid json detected for http://192.168.205.25/api/4f51e44918e56768e940e0d6d89b3777/config: HASH(0x558b3e3da410)
2020.08.14 10:45:24 3: HUEBridge_Call: failed, retrying
2020.08.14 10:45:25 2: HB1: invalid json detected for http://192.168.205.25/api/4f51e44918e56768e940e0d6d89b3777/config: HASH(0x558b3e1fe818)
2020.08.14 10:45:25 3: HUEBridge_Call: failed, retrying
2020.08.14 10:45:25 3: HUEBridge_Call: failed
2020.08.14 10:45:25 2: HUEBridge_OpenDev: got empty config


Was bedeutet "invalid json detected"? Liegt das an der Bridge oder am Modul?

Edit:
Ich nehme Alles zurück und behaupte das Gegenteil 

Denn bei meinem Versuch von Antwort #2 hatte ich einen Zahlendreher in der Ip-Adresse.
Dieser ist mir die ganze Zeit nicht aufgefallen, sonst wäre das Problem schon lange gelöst. (Der Wald und die Bäume)

Anbei der Anfang des funktionierenden Lists:

Code Auswählen Erweitern

Internals:
   DEF        192.168.250.25
   FUUID      5f3cdbf5-f33f-d4cb-26de-0a555bd42b93de0d
   FVERSION   30_HUEBridge.pm:0.213660/2020-03-06
   INTERVAL   60
   NAME       HB1
   NOTIFYDEV  global
   NR         542
   NTFY_ORDER 50-HB1
   STATE      connected
   TYPE       HUEBridge
   apiversion 1.16.0
   host       192.168.250.25
   mac        00:17:88:1c:90:40
   manufacturer Royal Philips Electronics
   modelName  Philips hue bridge 2012
   modelid    BSB001
   name       Philips hue
   swversion  01043155
   updatestate 0
   zigbeechannel 11
   READINGS:
     2020-08-19 10:04:10   lastError       link button not pressed
     2020-08-19 10:10:16   state           connected
   helper:
     apiversion 69632
     count      1
     last_config_timestamp 1597824616
     offsetUTC  7200
     updatestate 0

Warum fhem plötzlich die Definition vergessen hatte ist mir zwar immer noch nicht klar, aber Hauptsache ist, es funktioniert wieder.

Vielen Dank für Eure Anregungen.
Walter

[marc2]

Hmm, also ich habe seit heute dasselbe Problem. Am Wochende hatte ich mein deCONZ umgezogen. Da lief noch alles. Heute nach der Neuinstalltion klappt es nicht mehr 

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        192.168.40.22
   FUUID      63f3f77b-f33f-13a0-8b6f-0e3169af2824903e
   FVERSION   30_HUEBridge.pm:0.264380/2022-09-22
   INTERVAL   60
   NAME       deCONZ
   NOTIFYDEV  global
   NR         1480
   NTFY_ORDER 50-deCONZ
   STATE      active
   TYPE       HUEBridge
   eventCount 2
   host       192.168.40.22
   manufacturer Royal Philips Electronics
   modelName  Philips hue bridge 2015
   Helper:
     DBLOG:
       state:
         myDbLog:
           TIME       1676933013.5164
           VALUE      active
   READINGS:
     2023-02-20 23:43:33   state           active
   helper:
     count      2
     last_config_timestamp 0
     bm:
       HUEBridge_Attr:
         cnt        1
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        20.02. 23:43:24
         max        7.15255737304688e-06
         tot        7.15255737304688e-06
         mAr:
           set
           deCONZ
           room
           Arbeitszimmer
       HUEBridge_Define:
         cnt        1
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        20.02. 23:43:15
         max        8.01697707176208
         tot        8.01697707176208
         mAr:
           HASH(0x561801721600)
           deCONZ HUEBridge 192.168.40.22
       HUEBridge_Get:
         cnt        5
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        20.02. 23:43:31
         max        1.31130218505859e-05
         tot        6.29425048828125e-05
         mAr:
           HASH(0x561801721600)
           deCONZ
           ?
       HUEBridge_Notify:
         cnt        9
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        20.02. 23:43:44
         max        2.59876251220703e-05
         tot        8.08238983154297e-05
         mAr:
           HASH(0x561801721600)
           HASH(0x5617f831f6a0)
       HUEBridge_Set:
         cnt        16
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        20.02. 23:44:19
         max        24.0671699047089
         tot        32.0873172283173
         mAr:
           HASH(0x561801721600)
           deCONZ
           autocreate
     ignored:
   hmccu:
Attributes:
   key        bd20e7713c59aa4ed153baea3f3e305b
   room       Arbeitszimmer


Den deCONZ habe ich vor dem "define" natürlich brav auf "unlocked" gesetzt. Per tcpdump ist zu sehen, dass Pakete vom FHEM ankommen. Im FHEM log finde ich aber nur Timeouts:

Code Auswählen Erweitern

2023.02.20 23:43:37 1: HUEBridge_HTTP_Request http://192.168.40.22/api/bd20e7713c59aa4ed153baea3f3e305b/config: Select timeout/error:
2023.02.20 23:43:37 3: HUEBridge_Call: failed, retrying
2023.02.20 23:43:41 1: HUEBridge_HTTP_Request http://192.168.40.22/api/bd20e7713c59aa4ed153baea3f3e305b/config: Select timeout/error:
2023.02.20 23:43:41 3: HUEBridge_Call: failed, retrying
2023.02.20 23:43:41 3: HUEBridge_Call: failed
2023.02.20 23:43:41 2: HUEBridge_OpenDev: got empty config


Problem ist, die Confihg ist nicht leer, ich bekomme sie mit curl problemlos:

Code Auswählen Erweitern


[fhem@fhem log]$ curl  -s http://192.168.40.22/api/bd20e7713c59aa4ed153baea3f3e305b/config | jq .
{
  "apiversion": "1.16.0",
  "bridgeid": "00212EFFFF02A3FE",
  "datastoreversion": "93",
  "devicename": "ConBee",
  "factorynew": false,
  "mac": "02:42:ac:11:00:02",
  "modelid": "deCONZ",
  "name": "Phoscon-GW",
  "replacesbridgeid": null,
  "starterkitid": "",
  "swversion": "2.20.1"
}


Das einzige, was ich wissentlich seit dem Wochenende geändert habe, ist ein Firmware Upgrade des Conbee auf 26400500. deCONZ selber ist unverändert auf "2.20.01 / 19.9.2022". Wenn FHEM das JSON plötzlich nicht mehr geparst bekommen sollte, würde ich andere Fehler erwarten. Zudem funtionieren anderen REST Zugriffe, z.B. auf Shellys, etc. problemlos. Ich stehe aktuell auf dem Schlauch 

VG, Marc

[marc2]

Also man sieht im tcpdump/wireshark eigentlich ganz gut, dass die Kommunikation funktioniert, erst wir die Description angefragt und ausgeliefert, das funktioniert noch. Dann wird die config angefragt und ebenfalls ausgeliefert. Allerdings wird dies von "HUEBridge_HTTP_Request" nicht erkannt/akzeptiert. Es kommt zum Timeout, danach wird config ein zweites Mal angefragt, erneut ausgeliefert und erneut nicht erkannt. Zweiter Timeout, Ende der Kommunikation. 

[marc2]

Moin!

Ich habe in 30_HUEBridge.pm die Funktion HUEBridge_HTTP_Request jetzt recht stumpf gemäß HttpUtils.pm ersetzt:

Code Auswählen Erweitern


sub
HUEBridge_HTTP_Request($$$@)
{
  my ($quiet, $url, $method, $timeout, $data, $noshutdown) = @_;
  return CustomGetFileFromURL($quiet, $url, $timeout, $data, $noshutdown, 3);
}


Damit ist der define auf Anhieb durchgelaufen

Code Auswählen Erweitern


023.02.22 23:39:55 3: http://phoscon/api/afb3c0209e5beba894ca7117b12d3d90/config: HTTP response code 200
2023.02.22 23:39:55 3: http://phoscon/api: HTTP response code 200
2023.02.22 23:39:55 3: http://phoscon/api/4E68643D05/config: HTTP response code 200
2023.02.22 23:39:55 3: deCONZ: websocket opened to phoscon:443
2023.02.22 23:39:55 3: http://phoscon/api/4E68643D05/lights: HTTP response code 200
2023.02.22 23:39:55 3: HUEDevice1: I/O device is deCONZ
2023.02.22 23:39:55 3: http://phoscon/api/4E68643D05/lights/1: HTTP response code 200
2023.02.22 23:39:55 3: HUEDevice2: I/O device is deCONZ
2023.02.22 23:39:55 3: http://phoscon/api/4E68643D05/lights/2: HTTP response code 200
2023.02.22 23:39:55 3: HUEDevice3: I/O device is deCONZ
2023.02.22 23:39:55 3: http://phoscon/api/4E68643D05/lights/3: HTTP response code 200
2023.02.22 23:39:55 3: HUEDevice4: I/O device is deCONZ
2023.02.22 23:39:55 3: http://phoscon/api/4E68643D05/lights/4: HTTP response code 200
2023.02.22 23:39:55 3: http://phoscon/api/4E68643D05/groups: HTTP response code 200
2023.02.22 23:39:55 3: HUEGroup0: I/O device is deCONZ
2023.02.22 23:39:56 3: http://phoscon/api/4E68643D05/groups/0: HTTP response code 200
2023.02.22 23:39:56 3: HUEGroup1: I/O device is deCONZ
2023.02.22 23:39:56 3: http://phoscon/api/4E68643D05/groups/1: HTTP response code 200
2023.02.22 23:39:56 2: deCONZ: autocreate: created 4/2/0 devices (ignored 0/0/0)
2023.02.22 23:39:56 3: http://phoscon/api/4E68643D05: HTTP response code 200
2023.02.22 23:39:56 3: deCONZ: websocket: Switching Protocols ok


[MadMax-FHEM]

Hast/hattest du es mal mit gesetztem Attribut httpUtils (bzw. und noshutdown) probiert?

Gruß, Joachim

[justme1968]

wie komst du eigentlich darauf das irgend ein x-beliebiger uralt thread mit einem titel der nicht zu deinem problem passt bei dem es um eine hardware geht die du nicht hast und der seit Ewigkeiten gelöst ist zu deinem problem passen könnte?

welche version habe deine fhem hue module?

[marc2]

Hi!

Die soweit ich sehe aktuelle Version 26438 vom 22.09.22. Ja, den Thread zu nutzen war suboptimal. Das nächste Mal mache ich einen neuen auf!

VG, Marc

[marc2]

Hast/hattest du es mal mit gesetztem Attribut httpUtils (bzw. und noshutdown) probiert?

Mit "httpUtils = 1" tut es, vielen Dank  War früher in meinem Setup nicht notwendig, jetzt offensichtich schon.

VG, Marc