Closed robertklep closed 1 year ago
If I'm reading the code correctly, it might be caused by the connect/disconnect logic in Item.js
:
Item#connect()
, if this.io
doesn't exist, a new realtime subscription is createdItem#disconnect()
, the subscription is unsubscribed (io.unsubscribe()
) but this.io
remains definedItem#connect()
, this.io
already exists and no new subscription is created.A workaround would be to retrieve a new uncached device instance every time:
setTimeout(() => {
this.makeCapabilityInstance(await this.api.devices.getDevice({ id : 'ccafde03-6c28-44b8-8ace-78d867c19f48', $cache : false }));
}, 2000);
But that seems like a waste of resources.
Better workaround: when cleaning up the old listeners, I set device.io = null
, which confirms my suspicion from my comment about the realtime subscription handling.
I confirm this is fixed.
Thanks @jeroenwienk
Background: my HomeKitty app allows devices to be (un-)exposed from HomeKit. When a device is unexposed, I will stop listening to capability changes by destroying a previously created capability instance (using
device.makeCapabilityInstance()
).However, when a device is exposed to HomeKit again, it should start listening to capability changes and I create a new capability instance for that. But the listener for that instance is never called when the capability changes.
Code to reproduce (replace the device id with one of your own devices that has an
onoff
capability):This logs:
So the first change of
onoff
calls the listener, then destroys it, then waits 2s (to rule out a timing issue) and creates a new one, but the second listener is never called when I change the capability from the web app.