evgolsh
commented
11 months ago Many thanks for detailed analysis. I believe a pull request would be highly appreciated by the community.
On Sun, 24 Dec 2023 at 21:29 mcm246 @.***> wrote:
Describe The Bug:
First of all, thank you for your efforts developing this plugin - for the most part, it works great!
As others have already reported, there seems to be a bug with the plugin where after a period of time, all Homebridge accessories will become unresponsive in the Home app. I'm creating a new issue since I think I may have found the root cause of it. As you'll see below, I believe that this bug is being caused by the Homebridge plugin starting up while the Crestron control system is still offline - this would explain why the bug appears to be related to power outages specifically (where the Crestron system losses power as well), and not just any typical restart. I've been able reproduce the bug consistently using the below steps.
To Reproduce:
- Setup the plugin as new (alternatively remove all cached devices and restart). This will result in all Crestron devices getting added to the Homebridge cache
- Restart your Crestron control system and Homebridge at the same time
- Homebridge will reboot before the Crestron system is back up, resulting in a login error during the 'discoverDevices()' call
- Eventually the Crestron system will come back up and an 'updateDevices()' call will login successfully and re-add all of the devices (as explained below)
- Restart Homebridge again and all devices will show as "No Response"
Potential Explanation and Solution:
What I think is happening is as follows: During the initial 'discoverDevices()' call, the plugin is appropriately checking if a discovered device UUID is already in 'this.accessories' and only adding devices as new accessories if the UUID is not already present. It's important to note that this method only appears to be called once during startup.
However, in the 'updateDevices()' call, when checking if a device is an 'existingDevice', the plugin is only checking against the currently loaded 'crestronDevices', and not the cached accessories (as is being done in 'discoverDevices()'). As a result, once the Crestron system comes back online, the 'updateDevices()' call sees all of the devices as "new" since they were never loaded into 'crestronDevices' during 'discoverDevices()' (again, since the initial login failed). The plugin then creates new Homebridge accessories for each of those devices using the same UUIDs as the original accessories. Upon a restart of Homebridge, the system is likely getting confused as there are now 2 of each accessory with the same UUID, resulting in "No Response" errors.
I can think of two potential ways to fix this:
- In 'updateDevices()', when checking if a device is an 'existingDevice', check the UUID against the cached accessories UUID list as well (instead of just checking the Crestron deviceID
- Keep track of the login state to ensure that 'discoverDevices()' is always ran after a successful initial login
Expected behavior:
Following a restart, the devices should be responsive in the Home app
Logs:
Show the Homebridge logs here, remove any sensitive information.
Plugin Config:
{ "bridge": { "name": "Homebridge XXXX", "username": "XXXX", "port": XXXX, "pin": "XXXX", "advertiser": "ciao", "bind": [ "eth0" ] }, "accessories": [ { "accessory": "HTTP-SWITCH", ........... } } ], "platforms": [ { "name": "Config", "port": XXXX, "auth": "form", "theme": "auto", "tempUnits": "f", "lang": "auto", "platform": "config" }, { "name": "Camera FFmpeg", "platform": "Camera-ffmpeg", .......... }, { "name": "Crestron Home Platform", "crestronHost": "XXXX", "token": "XXXX", "enabledTypes": [ "Switch", "Dimmer", "Shade" ], "updateInterval": 15, "platform": "CrestronHomePlatform" } ] }
Screenshots:
Environment:
- Plugin Version: 1.1.6
- Homebridge Version: 1.7.0
- Node.js Version: 20.10.0
- NPM Version: 10.2.3
- Operating System: Raspbian GNU/Linux Bullseye (11)
— Reply to this email directly, view it on GitHub https://github.com/evgolsh/homebridge-crestron-home/issues/9, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFGB6IZW6KTVN4KT46PXDTYLB7DJAVCNFSM6AAAAABBBXCKUOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA2TKMJZGU2DQNI . You are receiving this because you are subscribed to this thread.Message ID: @.***>
mcm246
Describe The Bug:
First of all, thank you for your efforts developing this plugin - for the most part, it works great!
As others have already reported, there seems to be a bug with the plugin where after a period of time, all Homebridge accessories will become unresponsive in the Home app. I'm creating a new issue since I think I may have found the root cause of it. As you'll see below, I believe that this bug is being caused by the Homebridge plugin starting up while the Crestron control system is still offline - this would explain why the bug appears to be related to power outages specifically (where the Crestron system losses power as well), and not just any typical restart. I've been able reproduce the bug consistently using the below steps.
To Reproduce:
Potential Explanation and Solution:
What I think is happening is as follows: During the initial 'discoverDevices()' call, the plugin is appropriately checking if a discovered device UUID is already in 'this.accessories' and only adding devices as new accessories if the UUID is not already present. It's important to note that this method only appears to be called once during startup.
However, in the 'updateDevices()' call, when checking if a device is an 'existingDevice', the plugin is only checking against the currently loaded 'crestronDevices', and not the cached accessories (as is being done in 'discoverDevices()'). As a result, once the Crestron system comes back online, the 'updateDevices()' call sees all of the devices as "new" since they were never loaded into 'crestronDevices' during 'discoverDevices()' (again, since the initial login failed). The plugin then creates new Homebridge accessories for each of those devices using the same UUIDs as the original accessories. Upon a restart of Homebridge, the system is likely getting confused as there are now 2 of each accessory with the same UUID, resulting in "No Response" errors.
I can think of two potential ways to fix this:
Expected behavior:
Following a restart, the devices should be responsive in the Home app
Logs:
Plugin Config:
Screenshots:
Environment: