From v1.2.x, a blank puck S/N breaks HomeBridge/HomeKit

[simonnelli]

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.

[johannrichard]

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 homebridge -D.

After the update you might have to remove the config, restart homebridge, add config again and restart again.

[simonnelli]

Tried following: uninstalled 1.2.0, restarted HB, installed 1.2.1, restarted HB

Still breaking all other plugins. Using Terminal in Config UI X homebridge -D says: config.json (/root/.homebridge/config.json) not found. Which can't be true, it maybe looks in the wrong folder because it is running in Docker?

[johannrichard]

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):

http://<dingzIP>/api/v1/device
http://<dingzIP>/api/v1/dimmer
http://<dingzIP>/api/v1/shade

[simonnelli]

No worries, I don't have any Shades. Both DIP-Switches are set to lights.

v1/device {"XXX":{"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"}}

v1/dimmer {"0":{"on":true,"value":100,"ramp":0,"disabled":false,"index":{"relative":0,"absolute":0}},"1":{"on":true,"value":100,"ramp":0,"disabled":false,"index":{"relative":1,"absolute":1}},"2":{"on":false,"value":0,"ramp":0,"disabled":false,"index":{"relative":2,"absolute":2}},"3":{"on":false,"value":0,"ramp":0,"disabled":false,"index":{"relative":3,"absolute":3}}}

v1/shade {}

[johannrichard]

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.

[simonnelli]

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 [Dingz SmartHome Device] Accessory already initialized every second. Maybe this keeps HB from working?

[johannrichard]

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):

[18/05/2020, 17:07:56] [Dingz SmartHome Device] Auto-Discovered Dingz Device at  <IP> -> Attempting to identify and add.
[18/05/2020, 17:07:56] [Dingz SmartHome Device] Add configured device -> Auto-Discovered Dingz (<IP>)
[...]
[18/05/2020, 17:07:56] [Dingz SmartHome Device] Got Device -> {"XXXXXXXXX":{"type":"dingz","battery":false,"reachable":true,"meshroot":true,"fw_version":"1.1.48","hw_version":"1.1.1","fw_version_puck":"1.1.18","bl_version_puck":"1.0.0","hw_version_puck":"1.1.1","hw_id_puck":1,"puck_sn":"BXXXXXXXXXXX","puck_production_date":{"year":20,"month":5,"day":1},"puck_hw_model":"DZ1B-4CH","front_hw_model":"dz1f-pir","front_production_date":"20/5/1","front_sn":"FXXXXXXXXXXX","dip_config":3,"has_pir":true,"hash":"5758ee9b"}}
[18/05/2020, 17:07:56] [Dingz SmartHome Device] Registering new accessory: Auto-Discovered Dingz
[18/05/2020, 17:07:56] [Dingz SmartHome Device] Setting informationService Characteristics -> DZ1B-4CH
[18/05/2020, 17:07:56] [Dingz SmartHome Device] Adding output devices -> [...]
[18/05/2020, 17:07:56] [Dingz SmartHome Device] Service created -> Motion
[18/05/2020, 17:07:56] [Dingz SmartHome Device] Service created -> Temperature
[18/05/2020, 17:07:56] [Dingz SmartHome Device] Service created -> LED
[18/05/2020, 17:07:56] [Dingz SmartHome Device] Service created -> Light
[...]
[18/05/2020, 17:08:16] [Dingz SmartHome Device] Accessory already initialized

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.

[simonnelli]

After resetting everything I don't see the [Dingz SmartHome Device] Accessory already initialized too often, but HomeKit is still broken.

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)

[johannrichard]

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!

[johannrichard]

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 homebridge-dingz@testing as a plugin or if you're using the oznu/homebridge Docker image, you can also install it temporarily by running docker exec <container-name|container id> npm i homebridge-dingz@1.3.1-nightly.1 or docker exec <container-name|container id> npm i homebridge-dingz@testing from the Terminal or any of the ways described here.

You can revert by installing docker exec <container-name|container id> npm i homebridge-dingz@latest or recreating the container.

The other thing would be to get the Homebridge log and check what errors are thrown when it starts up: docker logs <container-name|container id>. If you see any errors about not being able to attach to certain ports, that would mean something in the plugin's listening on a port it's not supposed to.

[johannrichard]

I have now setup a vanilla docker image (x86_64) with the oznu/homebridge image and no fancy settings, but including auto-discovery. It starts right away, installs the plugin (I have added the plugin in "package.json"), discovers my DingZ and MyStrom Devices and, once I have added the bridge in Home.app, I see and can control all devices.

$ docker run  --net=host  --name=homebridge  -e HOMEBRIDGE_CONFIG_UI=1  -e HOMEBRIDGE_CONFIG_UI_PORT=18888  -v /root/hba:/homebridge oznu/homebridge

With that, I get output similar to the following (DEBUG is disabled), on the second run:

    Thank you for using the oznu/homebridge docker image!

  If you find this project useful please STAR it on GitHub:

         https://github.com/oznu/docker-homebridge

[5/18/2020, 8:46:08 PM] [HB Supervisor] Homebridge Storage Path: /homebridge
[5/18/2020, 8:46:08 PM] [HB Supervisor] Homebridge Config Path: /homebridge/config.json
[5/18/2020, 8:46:08 PM] [HB Supervisor] Logging to /homebridge/homebridge.log
[5/18/2020, 8:46:08 PM] [HB Supervisor] OS: Linux 4.19.0-9-amd64 x64
[5/18/2020, 8:46:08 PM] [HB Supervisor] Homebridge Path: /usr/local/lib/node_modules/homebridge/bin/homebridge
[5/18/2020, 8:46:08 PM] [HB Supervisor] UI Path: /usr/local/lib/node_modules/homebridge-config-ui-x/dist/bin/standalone.js
[5/18/2020, 8:46:08 PM] [HB Supervisor] Starting Homebridge with extra flags: -I -P /homebridge/node_modules
[5/18/2020, 8:46:08 PM] [HB Supervisor] Started Homebridge v1.1.0 with PID: 1536
[5/18/2020, 8:46:09 PM] Loaded config.json with 0 accessories and 1 platforms.
[5/18/2020, 8:46:09 PM] ---
[5/18/2020, 8:46:10 PM] Loaded plugin: homebridge-dingz@1.3.1-nightly.1
[5/18/2020, 8:46:10 PM] Registering platform 'homebridge-dingz.Dingz'
[5/18/2020, 8:46:10 PM] ---
[5/18/2020, 8:46:10 PM] Loaded plugin: homebridge-dummy@0.4.1
[5/18/2020, 8:46:10 PM] Registering accessory 'homebridge-dummy.DummySwitch'
[5/18/2020, 8:46:10 PM] ---
[5/18/2020, 8:46:10 PM] Loaded plugin: homebridge-config-ui-x@4.19.0
[5/18/2020, 8:46:10 PM] Registering platform 'homebridge-config-ui-x.config'
[5/18/2020, 8:46:10 PM] ---
[5/18/2020, 8:46:10 PM] Loading 1 platforms...
[5/18/2020, 8:46:10 PM] [Dingz SmartHome Device] Initializing Dingz platform...
[5/18/2020, 8:46:10 PM] [Dingz SmartHome Device] Restoring accessory from cache: WiFi Switch v2 CH -> MyStromSwitchAccessory
[5/18/2020, 8:46:10 PM] [Dingz SmartHome Device] Restoring accessory from cache: Auto-Discovered MyStrom Lightbulb -> MyStromLightbulbAccessory
[5/18/2020, 8:46:10 PM] [Dingz SmartHome Device] Restoring accessory from cache: Auto-Discovered Dingz -> DingzDaAccessory
[5/18/2020, 8:46:10 PM] [Dingz SmartHome Device] Service created -> Motion
[5/18/2020, 8:46:10 PM] [Dingz SmartHome Device] Service created -> Temperature
[5/18/2020, 8:46:10 PM] [Dingz SmartHome Device] Service created -> LED
[5/18/2020, 8:46:10 PM] [Dingz SmartHome Device] Service created -> Light
[5/18/2020, 8:46:10 PM] [Dingz SmartHome Device] Restoring accessory from cache: WiFi Switch v2 CH -> MyStromSwitchAccessory
Setup Payload:
[...]

So far, I haven't seen any special output and couldn't reproduce the problems you mentioned, which is strange.

[simonnelli]

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. Just looking at the log and interacting with HomeBridge looks/works fine. But it somehow breaks the connection between HomeBridge and Home.app. I still don't have a Homekit Hub (iPad or AppleTV) in place, if you do, maybe disable it to verify if it circumvents the bug by having a HomeKit Hub in the mix.

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.

[simonnelli]

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.

[johannrichard]

This is really weird. One thing to try: could you access /settings (HomeBridge Settings) on your HomeBridge and manually clear the accessory cache (if you haven’t done so)? And would you mind posting your Config so I can recreate your environment as closely as possible?

[simonnelli]

Clearing the Accessory cache didn't help. Here is my config:

{ "bridge": { "name": "Homebridge", "username": "xxx", "port": 53674, "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" }, { "name": "dingz", "autoDiscover": false, "devices": [ { "type": "Dingz", "name": "dingz Küche", "address": "192.168.227.12" } ], "platform": "Dingz" } ], "accessories": [] }

[johannrichard]

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.

[johannrichard]

So. It looks like the problem might actually be the other way around: That the homebridge-hue plugin is not compatible with a new breed of DynamicPlatformPlugin like the one I wrote but also others like homebridge-esphome-ts: As soon as one of these plugins is added to an install with Hue, HomeBridge won't start listening on its HomeKit port.

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 homebridge-esphome-ts (and configure it with an empty devices section), you will find that the QR code does not appear anymore in the logs. Also, the Config UI will tell you that "HomeBridge" is not running, despite the log having output.

At some point, I couldn't even start homebridge anymore even if the only plugin I had installed was homebridge-hue, and on different setups (once in Docker, once in my dev environment).

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.

[johannrichard]

@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": []
}

[simonnelli]

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. It seems that dynamic accessories for homebridge-hue are a long way coming: https://github.com/ebaauw/homebridge-hue/issues/4

[johannrichard]

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).

[simonnelli]

Ah, I've misunderstood then. The author already replied on my comment. Maybe the second paragraph helps? https://github.com/ebaauw/homebridge-hue/issues/4#issuecomment-631093928

[simonnelli]

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):

{ "bridge": { "name": "Homebridge", "username": "xxx", "port": 53674, "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": "Homebridge dingz", "username": "xxx", "port": 51301, "pin": "xxx" }, "accessories": [], "platforms": [ { "name": "dingz", "autoDiscover": false, "devices": [ { "type": "Dingz", "name": "dingz Küche", "address": "192.168.227.12" } ], "platform": "Dingz" }, { "name": "Config", "port": 9191, "auth": "none", "theme": "auto", "tempUnits": "c", "lang": "auto", "platform": "config" } ] }

[johannrichard]

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) :

• Clear the Accessory Cache in "Homebridge dingz"
• If you see the "Homebridge dingz" Bridge in Home.app under "Home Settings" -> "" -> "Hubs & Bridges", select it and delete it from HomeKit (it doesn't matter if HomeBridge dingz is running or not, this will just properly clear it from Home.app. But you should see the bridge in Home.app as it's been added in the past)
• Change the PIN and Username of this "Homebridge dingz" instance to something different than before
• Launch "Homebridge dingz" with these new PIN/Username settings
• Add the "Homebridge dingz" Bridge again as a new accessory in Home.app with the new QR Code

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)

[simonnelli]

I don't ever see the QR code in the log. Not even in a vanilla install with only the dummy plugin. But until I add the dingz-plugin everything works as expected 😅

Tried all your steps, unfortunately still no luck!

[johannrichard]

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?

[simonnelli]

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

[johannrichard]

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.

[simonnelli]

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.

[johannrichard]

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.

[simonnelli]

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.

[johannrichard]

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.

[simonnelli]

Yeah it's a very strange issue. I have a Raspi (also running Docker) at hand and will test if it works there. Another thing I'll test is to hook the Synology to my main Networkswitch (instead of the 10GbE), doing this ensures that all multicast traffic is being transfered to the other clients (connected to the 1GbE core switch). I've encountered multicast blocking (Sonos Airplay2) in the past between the two Switches.

I'll report back about my findings!

[simonnelli]

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.

[simonnelli]

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 2 docker on Raspi: dingz

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

[johannrichard]

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)?

[simonnelli]

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?

[johannrichard]

npm i -g homebridge-dingz@1.1.3 :smile:

In oznu/homebridge Docker: npm i homebridge-dingz@1.1.3 or just add the plugin in the package.json with the right version number.

[simonnelli]

Just verified by rolling back 1.1.0 and older working 1.1.2 and newer broken

[johannrichard]

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! 👍

[simonnelli]

No problem, thank you for developing this much needed plugin 😃

[johannrichard]

Found maybe something, so just a quick question: can you confirm that the field puck_sn returned under /api/v1/device is indeed empty for your Dingz (as per your comment very early on)? If so, then we might have found the culprit!

[johannrichard]

@simonnelli if you could try homebridge-dingz@1.4.0-nightly.1? It contains a patch for pucks where the S/N is missing.

[johannrichard]

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.

[simonnelli]

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

[simonnelli]

Just took the test sample off the network to see if it interferes: no improvement

[johannrichard]

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 homebridge-dingz@1.4.0-nightly.3 to make sure we use a valid SerialNumber. I would be grateful if you could test that version once you have some time too (clear the accessories cache 😄).

On top of that, could you add the output of both devices' /api/v1/device endpoint to the bug report?

Normally, I would expect that the "puck_sn" on both devices is either of value "" or not available at all, but I need to see it.

With that, I should be able to pin down whether a empty puck_sn can be ruled out or not and whether there are other values of the DingZ Info that might break things.

[johannrichard]

(See homebridge/HAP-NodeJS#824 for the bug report I filed)

[simonnelli]

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"}}

[johannrichard]

:sweat_smile: :relieved: :joy: 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 :octocat: 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. :fire: :sweat_smile:

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. :cry: :flushed: :see_no_evil:

But I digress! Thanks a lot again for reporting and helping get to the bottom, and don’t hesitate to report further bugs! :rocket: I’ll close the ticket once the fix is integrated in the repository. :octocat:

[johannrichard]

Fixed with 41298cf3bad79c8f5b71b20ec4ea43826e93ae80.