zGuy981

Apologies, let me outline what I tried but was unable to replicate why they stopped responding: Activated a scene through ISY that included the slider shade - did not result in the error in the log and it did not stop responding right away, sometime later it stopped responding. Activating a scene through ISY that did not include the slider shade - closest to getting error/non-responsive behavior almost immediately but immediacy was still not consistent but always ended in unresponsive. I tried activating a scene/controlling a shade from the Powerview App - no error did not stop responding until a little while later I disabled the network resources that I have that control the shades during the debug sessions above to make sure the activity is coming from the integration. Basically, I tried to debug the scenarios I could think of but found nothing besides the error log. The issue is consistent eventually integration becomes unresponsive and there is a capabilities error is in the logs. Let me know if there is anything you would like me to try.

Hey, It's me again, the key capabilities issue is popping up somewhere else. Unfortunately, I tried to find a pattern to provide more helpful info but I can not find one. Weirdly, I can activate a scene involving the slider shade, and no issue. Then some time passes and all the shades stop responding to the ISY. I have tried activating only from ISY to see if external changes were causing a bad state update but that does not seem to be. I can activate a scene with or without the slider in that scene but they may or may not stop responding soon after. The result is the same within an hour the service needs to be restarted. I have attached the log file I hope it helps. There is no rush on this as my workaround of daisy chaining to control shades works, so if you can please help when you can. It would just be nice to have direct control and have the chance to integrate shade status to fine-tune some programs. debug 4.log

Thank you so much! That worked!

I tried the beta version and unfortunately, it had the same error. I uninstalled the previous version. I tried it twice the first time I used the slot I had been using and the second time a new slot. Both had the same capabilities error. I have attached the log. According to the details page, it is on 1.12.4. Please let me know if there is something else I can try. debug.log

Thank you for looking into this. That is correct 35640 firmware and motor info match the left to right slider info in the app. Thanks again!

Thank you for getting back to me so quickly! Out of the 4 shades, 3 are both ways and the last is a slider, left to right. I do have 18 rooms as I am integrated with homekit, so they are populated on the homekit side but 30 are empty on the powerview side. The same goes for scenes between homekit/isy integration there are about equal multiroom/single shade scenes. Currently, I use network resource to IFTTT Powerview integration for a number of scenes to allow for limited integration. Let me know if I can help in any way and thanks again.

I added the plugin and updated the gatewayip to my HD Powerview Gen 2's IP address as my single hub. After doing so it only adds one shade. Upon inspecting the log it looks like it is encountering an error on init of that first shade. It does not appear to process anymore after that. I tried with both the production and beta versions but the same error happens in both: 2024-11-02 04:07:17.525 Thread-3 (parameterHandler) udi_interface ERROR udi_interface:write: KeyError 2024-11-02 04:07:17.525 Thread-3 (parameterHandler) udi_interface ERROR udi_interface:write: : 2024-11-02 04:07:17.525 Thread-3 (parameterHandler) udi_interface ERROR udi_interface:write: 'capabilities' I have attached the prod debug.log, the beta debug_2.log, and the shades and scenes dump. Any help would be greatly appreciated. My EISY is on the latest firmware as well. Let me know if I can provide any additional information. debug_2.log debug.log shades.txt scenes.txt

I had the same issue of programs triggered by controls not working but it was after a PLM failure. It had been connected to an EISY and working fine. After the PLM replacement and restoration this happened. I tried both options above neither worked. I ended up having to delete the device that would not trigger a program, re-add it, and then update the program with same command. I had to do both steps to make it work again.

Mine is back to normal as well.

I am having the same issue with the same ghost devices.