Closed Nastras closed 1 year ago
I think this might indeed be a bug in deCONZ, that it reports 404 during initialisation, see https://github.com/ebaauw/homebridge-deconz/issues/36#issuecomment-1101643327. I would need to see the message before the warning, listing what request 3 is (and to whom) to be sure. And you would only see the warning when (re)starting deCONZ, not when (only) restarting Homebridge.
The dump file contains the full state from deCONZ, so I think Homebridge deCONZ should work for you.
The message only appears when I restart homebridge-deconz. deconz continues to run in the background without any changes.
I have my log level set to 0 currently. There it looks quite unsuspicious. Should I set it to 4 and check the journalctl again?
homebridge-deconz in debug mode
logLevel
of 1
(on the Gateway accessory) should be enough to log the requests that result in an error.
The message has now overlapped. Is that enough or additionally Log Level 1?
No I need the logLevel
through the Gateway dynamic setting.
What’s with the gateway name? 2 vs 3. And its version is 2.21.2?
I logged into the wrong gateway. But is the same error and same software status. I have now activated on the original server "Zigbeebridge 2" log level 1:
OK, that's somewhat worrying. Homebridge deCONZ tries to update its migration resourcelink with the resources it exposes, but apparently, that resourcelink no longer exists. I'll add a check that the resourcelink still exists and is still valid.
Note the migration resourcelink is used only by Homebridge Hue, to blacklist the resources already exposed by / migrated to Homebridge deCONZ.
Good morning,
I don't understand the technical background exactly but what I wonder is that it is related to homebridge-hue migration.
I have completely rebuilt the homebridge-deconz instance on my Pi with the Zigbeebridge 2 including OS. I have re-tuned all devices.
I installed homebridge-hue on this pi only to use ph. It was not used otherwise.
Would it mean if I uninstall homebridge-hue then the error should no longer occur even without fix?
I installed homebridge-hue on this pi only to use ph
Note that ph
will (eventually) no longer support the decONZ gateway, just like Homebridge Hue. The Homebrdige deCONZ version is deconz
.
Would it mean if I uninstall homebridge-hue then the error should no longer occur even without fix?
No. Homebridge deCONZ maintains the resourcelink for Homebridge Hue, but does neither care nor know whether Homebridge Hue actually uses it.
I use since yesterday to configure homebridge-deconz the curl commands from the wiki.
The PH tool I use only to control outlets through the homebridge-cmdtrigger plugin with delay switches via the api. I have hidden the real devices via homebridge-hue or now homebridge-deconz.
https://github.com/hans-1/homebridge-cmdtriggerswitch
Like this command:
ph -H 192.168.178.11 -u B12F5FXXXX put /lights/ID/state '{ "on": true }'
Should this no longer work with PH in the future? If you explain me with an example how to do this with the homebridge-deconz ui tools I would like to use them of course 😁?
I have now read through the description for the ui tool again. If I understand it correctly or you have already mentioned it, it works similarly to PH.
I have just tried a command where I think he should work. But get as feedback:
ui -G 00212EFFFFXXXXXXX put /lights/10/state '{"on": true}' ui put: error: cannot find config.json - please set HOMEBRIDGE_DIR
I still use real instances and not child bridges. My config is located in /var/homebridge-deconz.
I have no idea what to do here: WIKI: In case ui fails to locate config.json, set the HOMEBRIDGE_DIR environment variable to the Homebridge user directory.
ph
(for now) and deconz
are command-line utilities to interact with the deCONZ API offered by the deCONZ gateway.
ui
is a command-line utility to interact with the dynamic configuration API offered by Homebridge deCONZ.
Both APIs are based (more or less) on REST principles, so if you mean that by “similar”, yes. But no, you cannot set a light state through ui
, and you cannot tell Homebridge deCONZ to expose a group through deconz
nor ph
.
By design, ui
only works on the server running Homebridge deCONZ. It needs to retrieve the port Homebridge deCONZ uses to serve the dynamic configuration API from cachedAccessories
. It needs config.json
, to figure out which cachedAccessories
Homebridge uses for Homebridge deCONZ. If you have a non-standard Homebridge installation, you need to set HOMEBRIDGE_DIR
, so ui
knows where to find config.json
(and cachedAccessories
).
Now I understood the difference between the tools! Now I have also figured out how to control a lamp via deconz now i no longer need ph 😅
deconz -H 192.168.178.XX -K B12F5XXXXX put /lights/10/state '{ "on": true }'
What I did not understand what exactly do I have to do to set HOMEBRIDGE_DIR? Where and what do I have to do for ui to find it. Sorry if I am a bit stupid.
Thanks for your effort to explain it to me!
The Storage Path as shown by the UI under System Information, or the value of the -U
parameter (the user storage path) when starting Homebridge. This is the directory which contains config.json
, accessories
and persist
.
I'll add a check that the resourcelink still exists and is still valid.
In v0.1.11.
Me again 😅,
I now have three Raspberry Pi and each running their own deconz and associated homebridge instance. There are no other programs running like pihole etc. deCONZ is v2.20.1.
On all Pi I get the following warning after starting homebridge-deconz:
Apr 04 14:29:32 Gr-SHS-3 homebridge[14027]: [deCONZ] Zigbeebridge 3: warning: request 3: http status 404 Not Found
I originally ran deconz with its own port 192.168.178.XX:80XX. I also entered the IP address in config.json.
After looking around in the issues I found this: #36 Here the error was already discussed.
I then tried this hint from you: XXXXXXX@Gr-SHS-3:~ $ deconz -DD config deconz: localhost: request 1: GET /config deconz: localhost: request 1: GET http://localhost/api/config deconz: localhost: request 1: GET /config deconz: warning: localhost: request 1: connect ECONNREFUSED 127.0.0.1:80 deconz: fatal: localhost: deCONZ gateway not found
Afterwards I changed my config.json to "hosts": ["127.0.0.1"] and put the default port 80 for deconz back into deconz-gui.service. After that I did a reboot of the pi.
Now I get the following output for deconz -DD config:
XXXXXX@Gr-SHS-3:~ $ deconz -DD config deconz: localhost: request 1: GET /config deconz: localhost: request 1: GET http://localhost/api/config deconz: localhost: request 1: response: {"apiversion": "1.16. 0", "bridgeid": "00212EFFXXXXX", "datastoreversion": "93", "devicename": "ConBee II", "factorynew":false, "mac": "dc:a6:32:2c:XXXXXX", "modelid": "deCONZ", "name": "Zigbeebridge 3", "replacesbridgeid":null, "starterkitid":"", "swversion": "2.21.2"} deconz: localhost: request 1: 200 OK { "apiversion": "1.16.0", "bridgeid": "00212EFFFXXXXXXXX", "datastoreversion": "93", "devicename": "ConBee II", "factorynew": false, "mac": "dc:a6:32:2c:cc:8d", }, "modelid": "deCONZ", }, "name": "zigbeebridge3", "replacesbridgeid": null, "starterkitid": "", "swversion": "2.21.2" }
The warning in the journalctl of homebridge-deconz (warning: request 3: http status 404 Not Found) still remains. Since I haven't added the plugin to HomeKit yet I can't judge if it has an impact on the operation.
I could not find a solution so far. What do you think is it a bug or did I configure something wrong?
Attached is my config and the debug log: "platforms": [ { "platform": "deCONZ", "hosts": ["127.0.0.1"], "noResponse": "true" } ] }
[