Powerview Polling causing timeout errors

kingy444 commented 2 years ago

I put some logging in the new polling implemented under https://github.com/home-assistant/core/pull/73659 This PR resolvee https://github.com/home-assistant/core/issues/70043 but has unfortunately created an issue where shades will timeout from time to time.

While the hub can process the requests the shades cannot always return a result in a timely manner. I have 5 hardwired shades but only 2 enabled for polling and still see these around every 6 hours or so.

These shades are all TDBU, which the current code would cause to poll twice however this is unrelated as testing is the same under PR to resolve that issue: https://github.com/home-assistant/core/pull/73899

Originally posted by @kingy444 in https://github.com/home-assistant/core/pull/73659#issuecomment-1162798204

wez commented 1 year ago

I just had to grub around and reboot my hub; this is definitely still an issue.

kingy444 commented 1 year ago

Nothing has changed at this stage, hoping a fix in gen3 resolves it otherwise this may need to be closed as an unresolvable hardware/firmware fault.

chrisjenx commented 1 year ago

I think some sort of back off will help. It definitely is related to over whelming it. Dunno if it's possible for the integration to implement an internal queue that only executes one request at a time?

wez commented 1 year ago

I found some docs that seem more up to date than those in the aio-powerview repo; these were collated and curated by the openhab folks:

There's a section on the v2 API that describes an /api/homeautomation endpoint which has an optional boolean that can be enabled to perform position verification with automatic position refreshing, which seems like the kind of thing we might want here. It also describes some delaying functionality for position requests that is taken care of by the hub.

kingy444 commented 1 year ago

I think some sort of back off will help. It definitely is related to over whelming it. Dunno if it's possible for the integration to implement an internal queue that only executes one request at a time?

Backing off the requests is exactly what is implemented 😉

kingy444 commented 1 year ago

I found some docs that seem more up to date than those in the aio-powerview repo; these were collated and curated by the openhab folks:

https://github.com/openhab/openhab-addons/files/7583705/PowerView-Hub-REST-API-v2.pdf

https://github.com/jlaur/hdpowerview-doc/

There's a section on the v2 API that describes an /api/homeautomation endpoint which has an optional boolean that can be enabled to perform position verification with automatic position refreshing, which seems like the kind of thing we might want here. It also describes some delaying functionality for position requests that is taken care of by the hub.

Yea I worked through getting aio-PowerView-api to a state where it supported all shades through collab with their team

I haven't seen that endpoint though, I'll check it out, but I think it may be related to a scene and not a normal move command

wez commented 1 year ago

I spotted an undocumented field in the /api/homeautomation endpoint, and I think it means that polling can be replaced with a webhook.

$ curl 'http://192.168.1.184/api/homeautomation'
{"homeautomation":{"enabled":false,"timeoutSec":60,"configNum":0,"postBackUrl":"localhost:7041","active":false}}

That postBackUrl sounds like it's a source for events/reports.

In another window, I set up a quick and dirty listener:

$ nc -l -k 192.168.1.92 7042

Then try setting the URL to this box and enabling this resource:

$ curl -i -H 'Content-Type: application/json' 'http://192.168.1.184/api/homeautomation' -X PUT -d '{"homeautomation":{"enabled":true,"postBackUrl":"192.168.1.92:7042"}}'
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 114
Date: Sat, 26 Aug 2023 12:14:31 GMT
Connection: keep-alive

{"homeautomation":{"enabled":true,"timeoutSec":60,"configNum":0,"postBackUrl":"192.168.1.92:7042","active":false}}

Now switching back to my listener, and moving a shade:

$ nc -l -k 192.168.1.92 7042
POST / HTTP/1.1
Host: 192.168.1.92:7042
User-Agent: Wget
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

configNum=3

POST / HTTP/1.1
Host: 192.168.1.92:7042
User-Agent: Wget
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 164

W3siZHVyYXRpb25NcyI6MTA4LCJpbml0aWFsUG9zaXRpb24iOjAsInNlcnZpY2UiOiJwcmltYXJ5Iiwic2hhZGVJZCI6NjAwNSwidGFyZ2V0UG9zaXRpb24iOjEsInR5cGUiOiJ0YXJnZXRMZXZlbENoYW5nZWQifV0=

POST / HTTP/1.1
Host: 192.168.1.92:7042
User-Agent: Wget
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 468

W3siY3VycmVudFBvc2l0aW9uIjoxLCJyZW1haW5pbmdEdXJhdGlvbk1zIjowLCJzZXJ2aWNlIjoicHJpbWFyeSIsInNoYWRlSWQiOjYwMDUsInR5cGUiOiJiZWdpbnNNb3ZpbmcifSx7InNlcnZpY2UiOiJwcmltYXJ5Iiwic2hhZGVJZCI6NjAwNSwic3RvcHBlZFBvc2l0aW9uIjoxLCJ0eXBlIjoic3RvcHMifSx7InNlcnZpY2UiOiJwcmltYXJ5Iiwic2hhZGVJZCI6NjAwNSwidHlwZSI6Imhhc09wZW5lZCJ9LHsic2VydmljZSI6InByaW1hcnkiLCJzaGFkZUlkIjo2MDA1LCJ0eXBlIjoibGV2ZWxDaGFuZ2VkIn0seyJzZXJ2aWNlIjoicHJpbWFyeSIsInNoYWRlSWQiOjYwMDUsInR5cGUiOiJzdGFydHNPcGVuaW5nIn1d

Decoding the base64 in the body of those responses (it's a bit weird that no Content-Transfer-Encoding is listed for those):

[
  {
    "durationMs": 108,
    "initialPosition": 0,
    "service": "primary",
    "shadeId": 6005,
    "targetPosition": 1,
    "type": "targetLevelChanged"
  }
]

[
  {
    "currentPosition": 1,
    "remainingDurationMs": 0,
    "service": "primary",
    "shadeId": 6005,
    "type": "beginsMoving"
  },
  {
    "service": "primary",
    "shadeId": 6005,
    "stoppedPosition": 1,
    "type": "stops"
  },
  {
    "service": "primary",
    "shadeId": 6005,
    "type": "hasOpened"
  },
  {
    "service": "primary",
    "shadeId": 6005,
    "type": "levelChanged"
  },
  {
    "service": "primary",
    "shadeId": 6005,
    "type": "startsOpening"
  }
]

wez commented 1 year ago

Moving the shade further (so the movement takes long to complete) causes multiple post backs while the shade is moving:

[
  {
    "currentPosition": 9,
    "remainingDurationMs": 6178,
    "service": "primary",
    "shadeId": 6005,
    "type": "beginsMoving"
  },
  {
    "service": "primary",
    "shadeId": 6005,
    "type": "levelChanged"
  },
  {
    "service": "primary",
    "shadeId": 6005,
    "type": "startsOpening"
  }
]

[
  {
    "service": "primary",
    "shadeId": 6005,
    "stoppedPosition": 66,
    "type": "stops"
  },
  {
    "service": "primary",
    "shadeId": 6005,
    "type": "hasOpened"
  }
]

wez commented 1 year ago

The enabled field doesn't have to be set to receive postback events

trullock commented 1 year ago

Nice work @wez

bdraco commented 1 year ago

Seems to work for me as well 👍

bdraco commented 1 year ago

Need to see if it supports https. A lot of users won't have a valid SSL cert so we would need to start another webserver on an alternate port to receive the post backs if the device doesn't work with unsigned SSL.

emulated_hue does something like this (its a bit of a bad example of code practice though since legacy though so it would need to be done in the library and not in HA directly)

wez commented 1 year ago

I noticed that the postback doesn't trigger if I move the blind outside of the hub eg: by pressing the button on the blind, and I assume using a pebble remote, but I don't have one in the room where I was testing this.

What I think is desirable for the integration is:

A config option to disable forced refreshing. Those of us affected by this issue probably will want to disable that. Speaking for myself, I don't depend on the position in hass, so I don't mind if that info isn't up to date.
An option to disable the current periodic polling in favor of the postback reporting when supported by the hub; I'm assuming this is v2 and perhaps v3. Speaking selfishly, I only care about v2 at this time. I'm assuming that this feature can be probed for simply by going a GET /api/homeautomation and testing whether postBackUrl is present in the json it returns.
Consider setting homeautomation enabled=true. The docs suggest that that will enable an automated forced refresh of the positioning information when the hub notices a discrepancy, which sounds like it happens when attempting to control a shade. I'm not sure whether that relates to the root cause of this issue at all, but I wonder if it might help the hub to heal itself without rebooting if it gets into a bad state.

Having those options should give a bit more freedom for folks to discover what will work for them without breaking the folks that are happy with the current forced refreshing.

trullock commented 1 year ago

I agree with Wez.

I never use the Pebble and even if I did, having the blinds not come down when its time for the crying baby's nap and then being unable to shut them without rebooting the hub is an almost daily pain for me and I'd gladly use a separate remote.

I also don't care about the position, except that HA UI doesn't let you shut a blind it already thinks is shut, for example.

Happy to test dev branches or forks

wez commented 1 year ago

Happy to test dev branches or forks

Likewise!

chrisjenx commented 1 year ago

Yeah I talked to hunter Douglas about that, the pebles talk to the shades independent of th hub. It's really dumb you would think they design it so if you have a hub the pebble talks to that instead

On Sun, Aug 27, 2023 at 3:07 PM Wez Furlong @.***> wrote:

Happy to test dev branches or forks

Likewise!

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/73900#issuecomment-1694762301, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI5DMNMX4SXEKR44NPYULTXXOZKDANCNFSM5ZUF2Z7Q . You are receiving this because you were mentioned.Message ID: @.***>

glyph-se commented 1 year ago

Nothing has changed at this stage, hoping a fix in gen3 resolves it otherwise this may need to be closed as an unresolvable hardware/firmware fault.

I think some sort of back off will help. It definitely is related to over whelming it. Dunno if it's possible for the integration to implement an internal queue that only executes one request at a time?

Backing off the requests is exactly what is implemented 😉

The problems started around the time the polling was changed about a year ago. At that time I believe that more frequent requests were added to the hub to get an more up-to-date position. E.g. after sending commands and in the background?

Apologies if I'm wrong here, but I believe that there are several users that would be more happy with an out-of-date position but retain the possibility to send commands to the hub.

Though the new API above sounds promising!

kingy444 commented 1 year ago

@glyph-se i assume if the polling affected you most of your shades are hardwired?

As a temporary you could use something like the below (this is completely wrong code, maybe search the forums, but you can override the should_poll)

customize:
  should_poll: false

Alternative, you could just change the power type of the shades to battery or wand powered - only hardwired shades are polled

glyph-se commented 1 year ago

@kingy444 I only have shades with battery wand (and disabled polling in the Home Assistant UI for the integration)

I was referring to the update of position that Home Assistant does after sending a command. I thought that update always were performed?

kingy444 commented 1 year ago

Weird you only started to experience when polling was added, as mentioned only changed for hardwired. Other shades had the same polling for some time.

The new code will allow some time between each refresh as a good start. Once all the Gen3 code is in I can take a look at the suggestions here if still required.

homeontherocks commented 1 year ago

Not sure if this is the same bug but I can reproducibly cause the hub to freeze and lose connection to all blinds. If I use HA to initiate any of the scenes or try to change >1 shade at the same time the automation or action will not initiate and the hub freezes. Rebooting the hub fixes the problem. Interestingly, scheduling a scene automation in the Powerview app works fine. This is my workaround as the automations that I use in HA (much more sophisticated than Powerview) are one shade at a time and do not cause the hub to freeze. Happy to do any additional testing if interested.

chrisjenx commented 1 year ago

Yeah not sure if something has changed in the last month or two. But it went from having to reboot the controller maybe once every week or so to multiple times a day. Dunno if there was a change power view side or HA side?

On Fri, Sep 15, 2023 at 2:30 PM homeontherocks @.***> wrote:

Not sure if this is the same bug but I can reproducibly cause the hub to freeze and lose connection to all blinds. If I use HA to initiate any of the scenes or try to change >1 shade at the same time the automation or action will not initiate and the hub freezes. Rebooting the hub fixes the problem. Interestingly, scheduling a scene automation in the Powerview app works fine. This is my workaround as the automations that I use in HA (much more sophisticated than Powerview) are one shade at a time and do not cause the hub to freeze. Happy to do any additional testing if interested.

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/73900#issuecomment-1721831680, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI5DMMWUVDQZ7WIIQLNX7DX2S3FXANCNFSM5ZUF2Z7Q . You are receiving this because you were mentioned.Message ID: @.***>

homeontherocks commented 1 year ago

For me this has been a problem for >1 year. I just now decided to spend enough time to figure it out so I can't comment on recent changes. I spent quite a bit of time with HD support and I doubt they're going to spend any time on v2 problems now that v3 is out. For anyone else trying to use HA with Powerview, only change one shade at a time and don't use any Scenes from Powerview as they will freeze the hub if multiple shades are changed at once.

chrisjenx commented 1 year ago

Yeah it's always been a problem just got much worse recently. What's the status on PV3 and do we know if PV2 shades talk to the PV3 hub?

I'm also interested how you did your automations to only move one shade at a time?

homeontherocks commented 1 year ago

Everyone I've talked to has said there is no way to get PV2 working or communicating with PV3 and no way to retrofit.

I have placed pauses between different shade actions in HA automations to reduce polling related freezing. Anything I can automate in Powerview app I do and only use HA for azimuth, elevation and brightness related triggers.

kingy444 commented 1 year ago

Unfortunately @homeontherocks I've tried to replicate and my hub seems to handle that scenario fine

Is your hub Gen2 or Gen1 maybe?

homeontherocks commented 1 year ago

Gen 2

homeontherocks commented 11 months ago

Just an update on my gen 2 HD Powerview system. I have Polling for Updates turned off and I have 5-10 second pauses between individual shade calls in my automations and I haven't had a hub freeze since (6 weeks). FYI in case this helps others who are stuck dealing with gen 2 systems.

trullock commented 11 months ago

Its rebooting HA that reliably kills it for me, and occasionally it does it without a reboot

homeontherocks commented 11 months ago

@trullock Do you have polling for Updates turned off? I have rebooted probably a hundred times in the last 6 weeks and haven't had any hub freezes.

trullock commented 11 months ago

Yeah polling is off. It did make it better but its still very much an issue

homeontherocks commented 11 months ago

If you turn off your automations is the hub stable? Would help isolate the issue(s). On Nov 11, 2023, at 5:28 AM, Andrew Bullock @.***> wrote: Yeah polling is off. It did make it better but its still very much an issue

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

wez commented 11 months ago

FWIW, I have polling disabled but I have to automate power cycling my hub twice per day (via a zigbee power outlet) in order for the hub to remain mostly functional when used together with automations in hass. If I don't have any hass automations, and having polling disabled, then the hub will remain functional without power cycling for weeks at a time.

Even with cycling the hub twice daily, I do still need to manually intervene and cycle every so often. I'm close to just ripping out the hass integration; I'm only really using it because I find it more convenient to specify time and positions in hass than in the powerview mobile app.

What I really want is a more ergonomic interface to editing and maintaining the schedules in the powerview hub.

homeontherocks commented 11 months ago

May not work for you, but what fixed my hub freezing was only sending commands to one shade and then pause for 5-10 seconds until the next. Try slowing it all down and don’t use any scenes that send multiple commands at once. On Nov 11, 2023, at 7:45 PM, Wez Furlong @.***> wrote: FWIW, I have polling disabled but I have to automate power cycling my hub twice per day (via a zigbee power outlet) in order for the hub to remain mostly functional when used together with automations in hass. If I don't have any hass automations, and having polling disabled, then the hub will remain functional without power cycling for weeks at a time. Even with cycling the hub twice daily, I do still need to manually intervene and cycle every so often. I'm close to just ripping out the hass integration; I'm only really using it because I find it more convenient to specify time and positions in hass than in the powerview mobile app. What I really want is a more ergonomic interface to editing and maintaining the schedules in the powerview hub.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

wez commented 11 months ago

Yeah, I already added in 15 second delays all over the place; it's a huge PITA because I have >30 shades and it makes the automations much harder to edit, see and understand. It also does not eliminate the issue for me.

skdiv4 commented 11 months ago

Hi folks,

I've got a V1 hub with 5 shades, and while it's not crashing to the point that it needs to be power cycled, I believe I'm seeing a related issue.

I've been moving from Homebridge (and HomeKit) to Home Assistant (and HomeKit). Moving the shades has been pretty reliable through Homebridge (https://github.com/keybuk/homebridge-powerview), and when I set a scene that changes all the shades, it takes ~5 seconds until the last shade starts moving.

When I try to move all the shades at once through HA:

It takes between 30-60 seconds until the last shade starts moving.
Several exceptions are reported in the HA log similar to the ones king444 reported.
The shades are often left for some time in an "unknown" or "unavailable" state.

Given that the Homebridge PowerView integration has been reliably working for the last ~2 years, I compared that code to HA's code. I'm new to HA's architecture, but as far as I can tell:

Homebridge's integration will place all requests to the PV hub into a single queue, and wait 100ms after any request that requires the hub's radio.
Home Assistant serializes polling requests (through setting PARALLEL_UPDATES=1 and using DataUpdateCoordinator), but requests to change state (moving shades, changing scenes, etc) are just sent directly (in https://github.com/sander76/aio-powerview-api/blob/master/aiopvapi/helpers/aiorequest.py).

To test this theory, I set up a single-threaded HTTP proxy server (see https://gist.github.com/skdiv4/a4b933405ad7f216f746e2f685bea451) and added that server and port as a PowerView integration in Home Assistant. It worked! I can now start moving all 5 shades within ~5 seconds, and I no longer get errors in my HA logs.

Aside: I clicked "Add entry" on the PowerView integration page, but instead of creating a new instance, it overwrote the existing one. I'm a bit new to HA and this confused me.

I don't know how best to implement this kind of queuing/ordering in HA, but the proxy is a quick way to verify if this is causing problems for others.

wez commented 11 months ago

I tried to use the proxy approach, but it wasn't successful for me. In case it matters, I have a v2 hub and >30 devices.

Two problems:

hass will periodically autoconf and update the host entry to use the true device address, so the proxy will stop being used not too long after restarting hass with the new configuration.
The proxy itself blocks on the hub (which I know is kinda the point), but in a number of cases, it would stall for a very long time for various requests, leading to hass marking the associate device as unavailable, and there are a number of errors like this output from the proxy:

Exception occurred during processing of request from ('192.168.1.5', 41008)
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/socketserver.py", line 318, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/local/lib/python3.12/socketserver.py", line 349, in process_request
    self.finish_request(request, client_address)
  File "/usr/local/lib/python3.12/socketserver.py", line 362, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/lib/python3.12/socketserver.py", line 761, in __init__
    self.handle()
  File "/usr/local/lib/python3.12/http/server.py", line 436, in handle
    self.handle_one_request()
  File "/usr/local/lib/python3.12/http/server.py", line 424, in handle_one_request
    method()
  File "/pv/powerview-proxy.py", line 18, in do_GET
    self._handle_request("get", requests.get)
  File "/pv/powerview-proxy.py", line 62, in _handle_request
    self.wfile.write(resp.content)
  File "/usr/local/lib/python3.12/socketserver.py", line 840, in write
    self._sock.sendall(b)
BrokenPipeError: [Errno 32] Broken pipe
----------------------------------------

skdiv4 commented 11 months ago

I guess somewhere between 5 and 30 devices there's a problem.

I haven't seen either of those issues yet. I tried introducing a delay in the proxy script and was not able to see that exception, only the devices being seen as unavailable to HA. Does HA have a max number of pending HTTP connections?

downercc commented 11 months ago

I have been having this issue more and more lately. It is driving me insane! I have 10 blinds and the hub v2 in a smart outlet which I set to turn off/on twice a day to reboot the hub. In the past, I had to manually reset the hub every other week. Then it turned to once a week, now it is 50/50 whether the blinds are in the correct position when I get home from work despite many, many more reboots to the hub.

The PowerView app has worked consistently for me, but it did not have the additional functionality I needed, such as lowering the blinds if the shower light gets turned on, keeping the blinds in the guest room down if the murphy bed is lowered, and keeping the blinds from opening if our home projector is turned on.

One thought I had which you may find helpful (assuming it works) is the following workaround.

Disconnect the integration with HA and the PowerView hub.
Configure routine automations via the PowerView App that are not dependent on other factors/inputs.
Use a Bond Hub and program the RF frequencies used in the Pebble Remote (I checked the Pebble Remote manual, and it does indeed seem based upon RF).
Configure all automations that are dependent on other factors/inputs using the Pebble Remote frequencies via the Bond.
For dashboard purposes, you can use a mix of Bond + configured input Booleans to reflect (to some extent) the current position of the blinds.

I used to use a Bond for ceiling fans in the house but converted all fans to Lutron Caseta a couple years back. I forget how complicated setting up Bond can be, but I do not remember it being a pain. Using Bond to use the RF signal of the Pebble remote completely bypasses the PowerView hub and eliminates that problem causes son of a b**** from the system.

Just some thoughts that you may find helpful. Good luck!

Update

I wish I would have researched this further before drafting the above. I thought the Bond worked as an RF copier. It does not. From all appearances, it will not copy the requisite RF signal for the Pebble Remote. I am looking into what other solutions there may be based upon the RF signal from the Pebble Remote to bypass the hub. Stay tuned.

downercc commented 11 months ago

To those who may find it helpful, I just completely removed the PowerView integration. Instead, I set up all the potential scenes I use via the PowerView App--which always worked just fine for me prior to connecting it to HA.

To run any automations which open/close the blinds within HA, I am use the Google Assistant SDK integration. This works well. Just as before, I can control the opening/closing of blinds based upon the states of other devices connected to HA. I implemented this 5 days ago and have had zero problems. The only bad thing is that I cannot see the current status of a blind in my dashboard (though I could create input Booleans to do this). Instead, I placed buttons in my dashboard for each room which run scripts to lower/close/open blinds to the extent I want to control them via the HA app.

Although it is slightly more limited than using the PowerView app, it is infinitely less frustrating. Good luck.

wez commented 10 months ago

I've also now removed this integration; it was just too frustrating. My solution was to build pview, a utility for interacting with the powerview hub. The pview serve-mqtt subcommand is a PowerView to MQTT bridge; all of my shades and scenes are made available via the MQTT integration. This implementation ties into the api/homeautomation webhook that I posted about previously. The result is that the shade status updates in near-real-time as shades are updated either via MQTT, via the PowerView app, or via the HomeKit integration. The home automation mode of the hub will probe and verify shade placement automatically after about a minute, eliminating the need for pview or any other client to force shade refreshes.

You can run the mqtt bridge in docker; details are in the readme of my repo.

trullock commented 10 months ago

I've also now removed this integration; it was just too frustrating. My solution was to build pview, a utility for interacting with the powerview hub. The pview serve-mqtt subcommand is a PowerView to MQTT bridge; all of my shades and scenes are made available via the MQTT integration. This implementation ties into the api/homeautomation webhook that I posted about previously. The result is that the shade status updates in near-real-time as shades are updated either via MQTT, via the PowerView app, or via the HomeKit integration. The home automation mode of the hub will probe and verify shade placement automatically after about a minute, eliminating the need for pview or any other client to force shade refreshes.

You can run the mqtt bridge in docker; details are in the readme of my repo.

Well this is a nice Christmas present. Will review this asap

dvhub commented 10 months ago

I've also now removed this integration; it was just too frustrating. My solution was to build pview, a utility for interacting with the powerview hub. The pview serve-mqtt subcommand is a PowerView to MQTT bridge; all of my shades and scenes are made available via the MQTT integration. This implementation ties into the api/homeautomation webhook that I posted about previously. The result is that the shade status updates in near-real-time as shades are updated either via MQTT, via the PowerView app, or via the HomeKit integration. The home automation mode of the hub will probe and verify shade placement automatically after about a minute, eliminating the need for pview or any other client to force shade refreshes.

You can run the mqtt bridge in docker; details are in the readme of my repo.

Smart solution and thank you! Is this stable? Have you had to reboot your hub since switching to this solution?

wez commented 10 months ago

No reboots so far, but it's only been 1 day. However, I was rebooting my hub twice daily with the hass integration.

dvhub commented 10 months ago

Keep us posted. I'm rebooting twice a day also and try to time it with a few automations.

On Sun, Dec 24, 2023, 8:25 PM Wez Furlong @.***> wrote:

No reboots so far, but it's only been 1 day. However, I was rebooting my hub twice daily with the hass integration.

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/73900#issuecomment-1868645058, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABU7GZG42DLKHET34G3SN7TYLDIXTAVCNFSM5ZUF2Z72U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBWHA3DINJQGU4A . You are receiving this because you are subscribed to this thread.Message ID: @.***>

wez commented 9 months ago

BTW, if you want to detect whether the hub has hung, based on a sample size of 1 from the other day, I think you can curl http://HUB-IP/api/userdata -s to decide; if that takes longer than a few seconds to respond then the hub will not be able to send additional commands to the shades. Not every endpoint will hang like this, but since that one tries to retrieve the rfStatus (whether the radio is busy), it seems like it would be a good indicator to hook up to some kind of automation to alert you to when it has gone bad.

trullock commented 8 months ago

I can confirm that after running @wez's integration for a week I've not had any freezes 👍

wez commented 8 months ago

FWIW, the addon has been flawless for me since my last post. No reboots, no hangs, shades always respond, automations always run, no need for artificial delays the hass side.

chrisjenx commented 8 months ago

Dang thats awesome to hear, wonder if we could replace the current Powerview implementation with this one?

kingy444 commented 8 months ago

The current implementation is currently going through the PR cycle to support Gen 3

It still uses the old polling and not Wez method but will have some improvement to the hub spamming for Gen 2 in addition to Gen 3 support

Would still be good once it is out to confirm if the hub freezing is still an issue or not.

I haven't looked much at the web socket stuff wez has developed but as I understand it needed some manual config where the current implementation is automatically detected.

Would be good to test Gen3 once it is out to know if this is even needed, are there any other benefits than the hub freezing issue?

home-assistant / core

Powerview Polling causing timeout errors #73900