From v1.2.x, a blank puck S/N breaks HomeBridge/HomeKit #5
Comments
|
There was presumably an issue with the dimmers when blinds were set. v1.2.1 (just about to be released) should hopefully fix this. If it still breaks, please have a look at the output from DEBUG mode After the update you might have to remove the config, restart homebridge, add config again and restart again. |
|
Tried following: Still breaking all other plugins. |
|
Sorry to hear that! Let's see if we can find the root cause and a fix. I've had quite some undocumented "feature" in the API to work around. One was related to shades and the information returned by the API vs. the API docs. IIRC, you have your DingZ configured with Shades on Output 3&4, i.e. DIP=1. May I ask you to paste in the issue what you get when you access (Just remove the MAC address/serial numbers): |
|
No worries, I don't have any Shades. Both DIP-Switches are set to lights. v1/device v1/dimmer v1/shade |
|
OK. Let’s continue. Do you have Auto Discovery enabled? If so, what happens if you turn it off? (It could be it clashes with your Homebridge-Docker environment) Otherwise we’ll have to find out how to access your Homebridge error log somehow. |
|
Just reinstalled HB from scratch and added plugin by plugin to see if there is a problem on my end. Was also able to find how to enable debug mode in HB. I see |
|
If you see that message appear it means your DingZ has been successfully (auto-)discovered. You should see more output a bit earlier, just when Homebridge started about what device was discovered etc. The plugin will continue for another 10 minutes to discover devices so seeing that is normal (The plugin is still quite chatty to be able to debug smoothly). Seeing these messages also means that HB is not crashing anymore. It could take some time before the DingZ appears in HomeKit, though. Further up in the Debug log you should see something similar to the following (taken from my v1.2.1 install here): The "Service created" messages are when the various functions of the DingZ are created. If you see these then you should also see the Devices in HomeKit and/or Homebridge (there only if access to accessories is enabled). So far, this has reliably worked for me in different environments, when starting from scratch and when starting from cached accessories afterwards and also for at least one other user on a Raspberry Pi. |
|
After resetting everything I don't see the What I've found out in the meantime: Controlling devices in Config UI X still works but the connection between Home.app and HomeBridge is broken. Deleting the Bridge in Home.app and trying to add the Bridge again fails until your Plugin is uninstalled. Does the Auto discovery use mDNS and therefore interferes with Home.app? (Bear in mind that I don't use auto discovery at the moment) |
|
I don’t use mDNS in the plugin but I listen on port 7979 for auto discovery. It could be this breaks on docker. I’ll have a look at it later, thanks for the info! |
|
As you describe it, it really sounds like a problem with the plugin listening on a specific port it shouldn't be listening on. Which is weird. Could you tell me how your Docker image is configured? I guess you bind to the host network to be able to expose HomeKit to the outer world? I've made a small change to the way the plugin starts to listen for packets when auto-discovery is turned on so the socket is only created if we really start auto-discovery. In my understanding this shouldn't make a difference, but you never know ... If you want and have access to a terminal in your Homebridge Docker image, you can run a test this by installing a nightly version directly: Either configure your docker Homebridge to include You can revert by installing The other thing would be to get the Homebridge log and check what errors are thrown when it starts up: |
johannrichard
changed the title
|
I have now setup a vanilla docker image (x86_64) with the $ docker run --net=host --name=homebridge -e HOMEBRIDGE_CONFIG_UI=1 -e HOMEBRIDGE_CONFIG_UI_PORT=18888 -v /root/hba:/homebridge oznu/homebridgeWith that, I get output similar to the following (DEBUG is disabled), on the second run: So far, I haven't seen any special output and couldn't reproduce the problems you mentioned, which is strange. |
|
I'm running the oznu/homebridge in Docker on a Synology NAS, the only thing I changed from the vanilla install is the HB-Port to 8181 as 8080 is used for another service. I'll have to verify tomorrow, but I think it interferes with the 'Homebridge Hue' Plugin. I run this plugin to expose non native (not Philips) Zigbee-lights connected to the Hue Bridge to HomeKit. Maybe you have some Hue-Lights as well and can test? I'll run your nightly tomorrow when I'm at the office where my dingz are and report back. So far it doesn't make any difference if I let the dingz autodiscover (which works fine) or if I configure them manually. |
|
I couldn’t find anything in the logs hinting at a problem with exposed ports. The Docker uses the same network as the host, no ports are used twice.
The nightly also breaks the connection between HomeBridge and Home.app. I tested without any other plugins. dingz-homebridge doesn’t break the other plugins but the connection to the Home.app.
I’ve found following when starting up the container:
(node:1105) UnhandledPromiseRejectionWarning: TypeError: Cannot read property '0' of undefined
at DingzDaAccessory.updateAccessory (/homebridge/node_modules/homebridge-dingz/src/dingzDaAccessory.ts:901:29)
at /homebridge/node_modules/homebridge-dingz/src/dingzDaAccessory.ts:229:12
at Object.exports.execute (/homebridge/node_modules/homebridge-dingz/node_modules/cockatiel/src/common/execute.ts:23:25)
at RetryPolicy.execute (/homebridge/node_modules/homebridge-dingz/node_modules/cockatiel/src/RetryPolicy.ts:127:28)
at new DingzDaAccessory (/homebridge/node_modules/homebridge-dingz/src/dingzDaAccessory.ts:228:15)
at /homebridge/node_modules/homebridge-dingz/src/platform.ts:245:36
at processTicksAndRejections (internal/process/task_queues.js:97:5)
(node:1105) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:1105) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
|
|
This is really weird. One thing to try: could you access |
|
Clearing the Accessory cache didn't help. Here is my config:
|
|
Thanks, that was helpful: when I install and configure the Hue plugin (w/ and w/o NUPNP), my HomeKit connection is broken as well, even when my Hue is just trying to discover Hue bridges. I will investigate, I can't promise a quick fix right now. Thanks for providing all the info so far and for your patience. I'll update the ticket if I find out what it is / have a fix. |
|
So. It looks like the problem might actually be the other way around: That the You can check for yourself: If everything is OK, you will see the QR code and the HomeKit Code in the log. If you install this plugin or At some point, I couldn't even start homebridge anymore even if the only plugin I had installed was I will test/investigate further if I find a working combo of homebridge/homebridge-hue/homebridge-* (DynamicPlatformPlugin) but I fear there might not be an easy and quick fix. |
|
@simonnelli as a temporary work-around, you might want to run two Homebridge Docker images, one with your Hue and Sonos plugins and the other with the DingZ plugin (that's the beauty of Docker & Homebridge). You can then add both instances as two different accessories, avoiding the trouble with running the incompatible plugins in parallel. Just make sure the bridge listens on different ports both for HomeKit and Config UI X and obviously that the mounted directory with the HomeBridge configuration is different for the two instances. {
"bridge": {
"name": "Old Faithful",
"username": "xxx",
"port": 53774,
"pin": "xxx"
},
"platforms": [
{
"name": "Config",
"port": 8181,
"auth": "none",
"theme": "auto",
"tempUnits": "c",
"lang": "auto",
"platform": "config"
},
{
"name": "Hue",
"anyOn": true,
"hosts": [
"192.168.227.6"
],
"lights": true,
"nativeHomeKitLights": true,
"nativeHomeKitSensors": true,
"nupnp": true,
"resource": true,
"users": {
"xxx": "xxx"
},
"platform": "Hue"
},
{
"name": "Sonos",
"brightness": true,
"nameScheme": "% Sonos",
"service": "light",
"speakers": false,
"tv": true,
"platform": "ZP"
}
],
"accessories": []
}{
"bridge": {
"name": "The Shiny (New) Dingz Da",
"username": "xxx",
"port": 53574,
"pin": "xxx"
},
"platforms": [
{
"name": "Config",
"port": 9191,
"auth": "none",
"theme": "auto",
"tempUnits": "c",
"lang": "auto",
"platform": "config"
},
{
"name": "dingz",
"autoDiscover": false,
"devices": [
{
"type": "Dingz",
"name": "dingz Küche",
"address": "192.168.227.12"
}
],
"platform": "Dingz"
}
],
"accessories": []
} |
|
Thank you for the workaround, will set it up with two instances tomorrow. In the meantime I've written the author of homebridge-hue to take a look at this issue. |
|
Just to be clear: "it might be the other way round" 😅 🙊 – most probably there's something on my side I'm not seeing. 🙈 😅 Thanks for your patience here, anyway. (As a side note, I think the dynamic accessories are not exactly the same as the dynamic platform). |
|
Ah, I've misunderstood then. The author already replied on my comment. Maybe the second paragraph helps? |
|
Just tried your workaround by setting up a second container in docker with just the dingz-plugin. As soon as the Plugin is active the connection to Home.app breaks. my configs (same docker host, both exposed to same network as host):
|
|
I assume that the Homebridge with Hue & Sonos is now running correctly (i.e. you see the devices in Home.app and can control them if the "Homebridge dingz" is not running at all or w/o the Dingz plugin enabled). Then a question: If you start the "Homebridge dingz" Bridge with the Dingz Plugin enabled, do you see the QR Code in the logs of "Homebridge dingz" like the following: (it's important this appears in the logs and not just on the tile on the status page)?
If yes, that would mean that "Homebridge dingz" starts properly and is listening to Home.app requests. Then, can you try the following steps (Keep the working "Homebridge" container w/ Hue/Sonos running, treating it just as another accessory) :
Edit: I've published v1.3.1 last night which should remove quite some debug output which is not needed anymore so you should hopefully have less clutter in the debug logs. Some errors/warnings about unresolved Promises (undefined) or HTTP Connection errors might appear, that's nothing to particularly worry about if the Dingz device is otherwise properly detected and added to the system (which it lets you know with non-debug output as well) |
|
I don't ever see the QR code in the log. Not even in a vanilla install with only the dummy plugin. Tried all your steps, unfortunately still no luck! |
|
Sorry, I ignored that the Docker image only sends the code (w/o QR) in the log. So: when you add the plugin, do you at least see the code (XXX-XX-XXX) in the output or not at all? |
Yes, I see the Code in the log |
|
OK, this means HB is starting up properly which is good. I assume then you could re-add the accessory in Home.app? There’s an option to do an even more thorough reset in Homebridge (under Homebridge Settings, Reset Homebridge Accessory):
This will clean up more under the hood than what we’ve already tried, but maybe it helps. |
|
Once your plugin is loaded, HB can't be added anymore. I already tried the option to reset HB, I even did a complete fresh install. No improvement. |
|
One thing I couldn't try yet on my side but will do over the weekend is to remove my Home Hub (which isn't as simple as in the old days :-)). I didn't find any documentation about this but it could be that a Dynamic Platform Plugin needs a Hub to work properly as accessories could be added / changed / removed while your device is away. But as I said: so far I haven't found any indication this is the case, so I have to change my environment here and do some proper testing. I hope you can bear with me. |
|
Today I've added an Apple TV as a Home hub to see if it solves the issue. Unfortunately adding a hub didn't help. |
|
I'm really confused here why this doesn't work. The only remaining notable difference I see is that you run HomeBridge on Synology and I run it on a Raspi and in a Docker container on a VM (To be noted that I know of at leas one other user who got it to work instantly and without particular issues, however, of course with a different setup). Let me think about that and dig a bit into that matter. |
|
Yeah it's a very strange issue. I have a Raspi (also running Docker) at hand and will test if it works there. I'll report back about my findings! |
|
OK, just tried on my Raspi running docker: Unfortunately the behaviour is exactly the same. As soon as I add the dingz plugin the connection between HB and Home.app is broken. The raspi is connected to the core switch so any multicast blocking issues can be ruled out. |
|
Just noticed that running two HB instances not sharing any port, user or config both instances show all accessories of the other instance (even without matching config). Tried again to reset the cache but the accessories always show up Instance 1 docker on Synology: Hue and Sonos Instance 1 and 2 show all Hue, Sonos and dingz accessories. 🤪 EDIT: This only applies to the Config UI Accessories section. The accessories don't show up under the 'wrong' Bridge in Home.app |
|
Let's roll back: 1.0.x and 1.1.x did work, right? I had a change in the HTTP Library to v1.2.x and observed that my dev computer requested "listening" network access with that change. So, if you go back to v1.1.3, does it work (The Dingz probably won't work correctly when controlled from Home.app, but that's a different story)? |
|
Can't remember if I actually checked in Home.app if your plugin worked or not (or only Config UI X) until we reached 1.2.x (you acted quickly 😄) Whats the command to roll back? |
|
In oznu/homebridge Docker: |
|
Just verified by rolling back |
|
OK. Great, thanks for the support. I'll go through my commit[s] then and try to identify what's different and could be amiss. Thanks again for your patience in debugging this, this is much appreciated! 👍 |
|
No problem, thank you for developing this much needed plugin 😃 |
|
Found maybe something, so just a quick question: can you confirm that the field |
|
@simonnelli if you could try |
|
BTW: Once upgraded, don’t forget to clear the accessory cache as there were incompatible changes between 1.1.x and 1.2.x and higher. |
|
no improvement, sorry.
I have two dingz in place: one very early testhardware and one from production. Even if I only configure the one from production it breaks Home.app
|
|
Just took the test sample off the network to see if it interferes: no improvement |
|
I've created a Dummy Plugin based on the same code basis as this one to test a few things out. Right now, when – and so far only when – the SerialNumber is "undefined" or empty, I repeatedly and reliably get the same error message you see and Home.app stops working. So I can reproduce the problem -- somehow. As for the plugin, there is an edge case where the SerialNumber returned is not "undefined" but '' -- which is legit in HomeBridge terms but seems to break HomeKit itself reliably, and which is not caught upstream. 🙈 I have implemented further sanity checks in On top of that, could you add the output of both devices' Normally, I would expect that the "puck_sn" on both devices is either of value With that, I should be able to pin down whether a empty |
|
(See homebridge/HAP-NodeJS#824 for the bug report I filed) |
|
1.4.0-nightly.3 has done the trick! Thank you so much for your hard work :) As fast as I can see the difference is in the front. **Test Hardware (with PIR): ** {"type":"dingz","battery":false,"reachable":true,"meshroot":true,"fw_version":"1.1.49","hw_version":"1.0","fw_version_puck":"1.1.18","bl_version_puck":"1.0.0","hw_version_puck":"1.1.1","hw_id_puck":1,"puck_sn":"","puck_production_date":{"year":19,"month":12,"day":14},"puck_hw_model":"","dip_config":3,"has_pir":true,"hash":"cfb63dd7"}} Production sample (without PIR): {"type":"dingz","battery":false,"reachable":true,"meshroot":true,"fw_version":"1.1.49","hw_version":"1.1.2","fw_version_puck":"1.1.18","bl_version_puck":"1.0.0","hw_version_puck":"1.1.1","hw_id_puck":1,"puck_sn":"","puck_production_date":{"year":20,"month":1,"day":2},"puck_hw_model":"","front_hw_model":"dz1f-4b","front_production_date":"20/4/26","front_sn":"F20042600212","dip_config":3,"has_pir":false,"hash":"cfb63dd7"}} |
|
😅 😌 😂 I have to thank you for being so helpful and trying / testing so many different aspects. Hope you can fully enjoy your DingZ with HomeBridge now! In the end, you even helped uncover a bug/glitch Funnily enough, the moment I realized the problem was with the blank strings in SerialNumber, I remembered that when I wrote the myStrom plugin a few years back, I’d experienced a strange problem with HomeKit breaking when I set the SerialNumber (presumably to a blank string). I never investigated that further at that time though. 😢 😳 🙈 But I digress! Thanks a lot again for reporting and helping get to the bottom, and don’t hesitate to report further bugs! 🚀 I’ll close the ticket once the fix is integrated in the repository. |
in the upstream libraries which apparently has never been reported or ignored all the time: Blank SerialNumbers in HomeKit Accessories break HomeKit – every other Characteristic can be set to blank and nothing happens, but not so the SerialNumber. And both your DingZ don’t return a SN for the puck for whatever reason. So boom. 🔥 😅
johannrichard
changed the title
johannrichard
changed the title
johannrichard
changed the title
|
Fixed with 41298cf. |
In my setup v.1.2.0 breaks all other HB-plugins I use (Sonos and Hue). As soon as I uninstall homebridge-dingz the other plugins work again. Log looks normal.
The text was updated successfully, but these errors were encountered: