I’m still not confident that the primary gateway will always be primary. I think from an integration standpoint all gateways should be configured and then the client should switch to the next one in the list if it ever receives a 400 from the current gateway.
if you send a move command to gateway 2 for a shade on gateway 1 will they respond (i notice your shades in $.gateways[#].shd_Ids are different)
I assume that all shades on gateway 2 are responding to gateway 1 move commands currently (As the primary and gateway 2 is a reapeater?)
Not much point even considering the failover situation you mention if gateway 2 doesnt work that way. Can you test by unplugging gateway1 and see if after x period gateway2 becomes primary ?
Follow on question @nugget
You mention http://gateway1.local:80/home/id returns a 200 and http://gateway2.local:80/home/id returns a 400
does http://gateway2.local:80/home also return a 400, or does the id need to be called direct to determine if the hub is primary
your answer to this may mean i need the JSON of the other gateway2/home aswell (PM me of course) as the current code for Gen3 may make API think hub2 is also the primary
@nugget apologies for the spam - feel free to respond in one 
This made me have a thought - and just wanted to confirm that despite the shd_ids being bound to a particluar gateway - can you confirm that a call to http://gateway1.local:80/home/shades returns all shades, including those from gateway2
Just to clarify, the secondary gateway returns a 400 for all the /home API endpoints listed on the swagger page, including /home/id and /home/id/silent. The only API endpoints that are responsive on the secondary gateway are the /gateway endpoints.
/home/shades:
- primary gateway definitely returns a list of all shades in the system, not just those bound to that gateway.
- secondary gateway returns 400
I unplugged the ethernet from my primary gateway and waited 10 minutes and the secondary gateway never seemed to figure it out. It’s possible that a failover happens later, but 10 minutes seems like a long time to me for that to happen.
No fail over will occur automatically. Losing the primary is not a great situation as all shade commands must route through the primary.
The primary is always the primary and should be identified by using the dns lookup powerview-g3.local . The Gen3 in-App setup process helps identify the best placements for multiple Gateways within a home using proximity and load calculations for the Gateways. There is no automatic failover to another Gateway by design as the App fails over to Bluetooth if the configured Gateway system is not available in order to provide the most consistent user experience. Personally, since most of my shades are rechargeable battery powered, I have my primary Gateway on a UPS along with my HomeAssistant to provide access in case of a power outage.
identified by using the dns lookup powerview-g3.local
@Wes or @nugget do the secondary not have the same dns lookup ?
we would be coding discovery via discovery suffix ._powerview-g3._tcp.local. currently
All the gateways in the system, commissioned or not, are under the discovery prefix ._powerview-g3._tcp.local so it’s not that useful. All communications with the Gen3 system need to occur exclusively on the primary Gateway endpoint. If the PowerView App is used to reconfigure the network, the primary will always be accessible via the primary endpoint at powerview-g3.local so it’s advised to just use that endpoint as not all the devices under the discovery prefix are useful.
Anyone have context on how the hub treats the velocity attribute for future calls ?
The API doco mentions this controls the speed of the shade, and I have written required code for HA to handle this, but not having a Gen 3 hub to test against, could someone confirm if the hub remembers the Velocity attribute for future calls?
HA will currently remember the value set, but, should the hub return 0 (Say on reboot) this could inadvertanlty overwrite the value
The JSON i have seen only seems to have velocity: 0 which could just be a result of the call never being made.
This does raise a question though - I have the default set to 1.0 under the assumption that is full speed, should the default actually be 0.0 ?
I’ve been meaning to play with that. Was hoping to see it actually in HA first. From that app you can only do Discreet and Normal speeds and you can only do it through a scene.
I’ll see if I can figure out what value those speeds are at least and try to set them and see if they stick.
I have the ability to run tests on Gen3 gateways as well.
The gateway does not remember the last velocity parameter passed in so omitting velocity or passing in 0 results in it falling back to the default speed.
To answer your question about default speed: Full speed != shade default speed. A velocity of 1.0 is much faster than the shade’s default speed. The HomeAssistant default would likely want to be 0 or omitted as full speed is faster than typical operation.
I have a house full of gen 3 blinds with a new gateway but not the one that connects via ethernet.
At the point you’re ready to test, I’d be happy to do that provided you have some install instructions.
Hey hey. I have a house with Gen3 PowerView. I have 6 roller style shades and shutters as well. I have 4 powerview hubs in order to make sure all the spots get reached. I’m not a Home Assistant power user, but I’m happy to download a preview w/ some instructions to help w/ testing. Just LMK.
Good morning. I hadn’t seen any posts in this thread for a while, I’m wondering if there is progress in getting the generation 3 gateway integrated into home assistant?
Any responses? Not pushing developers, just asking.
Also curious if anyone thinks that using BLE will be an option. My shades came with a pushbutton control, could that be used to spoof commands?
Yes the shades, remotes, phone (app), and gateway talk to each other via BLE using a low level protocol. The gateway converts that to TCP HTTP REST API.
1 Like
So is any progress happening with this integration?
Personally I dunno about the HA integration.
(But I can tell you that I released the integration into OpenHab a couple of months ago).