Closed mcm246 closed 7 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: @.***>
Pull request created! #10
I've been testing this version since last night and it seems to be working for me. Hopefully this fixes it!
Separate question: are you able to share an API reference for the CWS REST API? I'm interested in extending this plugin to support additional devices (i.e. media, climate...) but I can not find documentation for it anywhere.
Published 1.1.7 including the fix. Thank you for your work!
Separate question: are you able to share an API reference for the CWS REST API? I'm interested in extending this plugin to support additional devices (i.e. media, climate...) but I can not find documentation for it anywhere.
I downloaded "Crestron Home and Pyng REST API_v5.pdf" from Crestron dev portal. The latest change in the API was made on 06/24/2019 and according to Crestron they don't develop or manage the project.
Separate question: are you able to share an API reference for the CWS REST API? I'm interested in extending this plugin to support additional devices (i.e. media, climate...) but I can not find documentation for it anywhere.
I downloaded "Crestron Home and Pyng REST API_v5.pdf" from Crestron dev portal. The latest change in the API was made on 06/24/2019 and according to Crestron they don't develop or manage the project.
Any way you can share the PDF? I don't have access to the dev portal.
Also, I noticed you added code to truncate the devices if more than 149: https://github.com/evgolsh/homebridge-crestron-home/blob/9f2834b290bf92d5cbe07014390cdcaa47508345/src/platform.ts#L81
I'm worried that this could be unnecessarily triggered in cases where a user has more than 149 "items" in Crestron (including devices and scenes), but only has a subset of those enabled in the plugin. For example, I have about 60 switches + dimmers + shades in my home as well as another ~100 scenes. I keep the scenes disabled since 1) they're not very useful to me, and 2) it would put me over the device limit. I think the plugin should only warn/truncate if the enabled device count is >149. Let me know if you agree.
Also, I noticed you added code to truncate the devices if more than 149:
I'm worried that this could be unnecessarily triggered in cases where a user has more than 149 "items" in Crestron (including devices and scenes), but only has a subset of those enabled in the plugin. For example, I have about 60 switches + dimmers + shades in my home as well as another ~100 scenes. I keep the scenes disabled since 1) they're not very useful to me, and 2) it would put me over the device limit. I think the plugin should only warn/truncate if the enabled device count is >149. Let me know if you agree.
You are absolutely right. Fixed in 1.1.8
Separate question: are you able to share an API reference for the CWS REST API? I'm interested in extending this plugin to support additional devices (i.e. media, climate...) but I can not find documentation for it anywhere.
I downloaded "Crestron Home and Pyng REST API_v5.pdf" from Crestron dev portal. The latest change in the API was made on 06/24/2019 and according to Crestron they don't develop or manage the project.
Any way you can share the PDF? I don't have access to the dev portal.
Not sure I can share it publicly, can send you in a private channel.
Thanks!
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: