Support for type 8 (TDBU) blinds

[gschot]

Checklist

• I need support with using the integration.
• I'm not avoiding to fill out the bug report form.

Describe the issue

Responding here to my remark in the other issue to support type 8 blinds (TDBU). Happy to help you out with some testing. Can't disconnect a shade from regular operation for long without being able to switchthem back to normal operation though, I will get in trouble with the missus. But if I can help you out providing info that's sniffable, or if there's a low-impact way of switching control back and forth I'd be happy to help you out. No expectations in result and time. I have to share my time so here and there as well. Let me know if I can help.

[patman15]

Hi @gschot! Sorry for the delay, working on multiple things in parallel ...

Can't disconnect a shade from regular operation for long

That's no issue the integration is prepared to work in parallel to the app. You "just" need to sniff your HOME_KEY once. While I'm looking into what makes type 8 blinds special, you could do that? Does the integration show you things like battery and position already now?
For getting the key, remove one shade from the app. At this point the integration should already allow you controlling "up/down" of the shade.
Then please follow the steps from this guide. Between step 2 and 3,

• please run the Powerview app and
• add the shade you have removed back to the app, then
• stop Bluetooth and
• follow the further steps to get the zip.

The file hci_dump.log can be opened with Wireshark then look for the communication between the phone and the shade (according to the MAC address). There should be a write command that starts with HEX value 0xFB02??10 and then I think it's something with cade... in total 32 characters. That is the HOME_KEY. You can enter it here:

hdpv_ble/custom_components/hunterdouglas_powerview_ble/const.py

Line 20 in e0185f1

HOME_KEY: Final = b""

Now should again be able to control the shade(s) in parallel to the app. Would be cool if you could send a debug log, no worries, HOME_KEY is not included in the log.
Hope we can take it from there, around the end of the year, I have more time and progress will be faster than the last week(s).

[gschot]

Hi,

No problem with a little delay, I know the feeling.

The 'type 8' blinds are Top Down Bottom Up, so in the app you can control positions for the bottom as well as the upper part of the blinds.

Both blinds show up as devices with 4 entities each:

• cover.xxx:xxx_shade: this shows a weird percentage (800%, 1200%), I'll elaborate on states below.
• sensor.xxx:xxx_battery: this looks ok, but I understood it only works with steps like 100% = good, 50% = halfway, 20% = charge soon, 0% = empty. I currently see them only on 100% (I don't have them that long yet)
• binary_sensor.xxx:xxx_charging: reports charging state correctly
• sensor.xxx:xxx_signal_strength: disabled by default but seems to report a logical value after enabling.

Regarding states of the cover:

• When I start lowering the lower rail of the blinds, the state shows 'closing' during moving the bottom rail. The shown percentage does not make any sense and is a >100% number.
• When the bottom rail is fully lowered, the state shows 'closed'.
• When the bottom rail is retracted, the state shows 'opening' during moving the bottom rail.
• When the bottom rail is fully retracted, the state shows 'closed' as well.
• When the bottom rail is fully lowered and I then lower the upper rail, the state shows 'closing' while the upper rail is in motion. The % of this rail makes actually sense and showing similar behaviour as the % shown in the app for the upper rail. (0% is fully up, 100% is fully down).
• When the upper rail is fully lowered, the state shows 'open'.
• When the upper rail is brought back up, the state shows 'opening' while the upper rail is in motion. Shown percentage matches the % of the upper rail position.
• When the upper rail is fully back up, the state shows 'closed' again.

I will work on the other requests and get back to you on that. Note that the blinds are also communicating to the PowerView hub I got along with it (not knowing that it could be done through a BT proxy as well). Would I need to remove blinds from that as well?

[patman15]

I will work on the other requests and get back to you on that.

No need to rush.

Note that the blinds are also communicating to the PowerView hub I got along with it (not knowing that it could be done through a BT proxy as well). Would I need to remove blinds from that as well?

No, you do not need to remove them from the hub. It is just to capture the communication once on the phone.

Could you please attach a (generic) picture of the shades from, e.g. the Internet, so I get an idea how it works? I will look into the gateway implementation to fix the data reporting and controls to accommodate your type.

Thanks,
Patrick

[gschot]

Could you please attach a (generic) picture of the shades from, e.g. the Internet, so I get an idea how it works? I will look into the gateway implementation to fix the data reporting and controls to accommodate your type.

For this, here's an image giving you an idea. Both upper and lower beam can be lowered (Top Down Bottom Up). It's a Luxaflex Duette.

[sdekker90]

I have this type of covers as well and would be happy to test.

[sdekker90]

In addition to type 8, I also have type 51 and 62 that I would like to be able to control using this custom integration. Here are pictures:

Type 51 - Aluminium Venetian blinds - 230V

Type 62 - Aluminium Venetian Blinds - PowerView /w external battery

They both are regular venetian blinds; they can be tilted and pulled up.

Please let me know how I can help.

[patman15]

@sdekker90, @gschot I just had a look (too much free time) on how to get started with your types of shades. Can you please help me a bit? If you use the modified branch (linked to this issue) or you have your HOME_KEY set, all your shades should appear. What I would need is a debug log of the integration with one shade of each type added to HA while you run your shade to different positions. If you could tell me your starting position (ideally just open) and then the sequence of positions you moved the shade to via the app, I could check the log and get some verification data. Please wait a bit (~10-30s) between setting new positions so that the shades communicate the new setting.
@sdekker90 I think the type 51 and type 62 should be even simpler to add.
Are you guys able to provide me logs? That would help me incredibly to get things integrated for you.

[gschot]

1_hdpv_ble_fullyopened_lowerbeamgoingdown.log
2_hdpv_ble_fullyclosed_upperbeamgoingdown.log
3_hdpv_ble_fullylowered_upperbeamgoingup.log
4_hdpv_ble_fullyclosed_lowerbeamgoingup.log
Hi, I used the code from the type_8 branch, added the home key to the const.py in the integration, restarted HA, but the integration still only shows me monitored values, no entities to actually control the shades? Just to make sure, how should the home key be entered in the const.py file? I added it as:

HOME_KEY: Final = b"1234567890abcdef1234567890abcdef"

Or should I add a 0x in front of the string, or remove the b?

Meanwhile, I have generated logs for the following actions on one of the shades:

1. Starting with shade fully opened (both beams in upper position) and lowering the bottom beam fully down
2. Now the shade is fully closed, and the upper beam is lowered to the fully down position
3. Now both beams are in the lowest position, the upper beam is fully pulled up to the topmost position
4. The shade is fully closed again, now the lower bean is fully pulled up again to the topmost position bringing the shade back to fully opened again.

I can add the files to this post if they can give you information, as I don't know if I configured the home key correctly.

[patman15]

Hi! Thanks for recording, you can simply attach them to your previous comment with a meaningful name so I can identify them. The HOME_KEYneeds to have exactly 16 bytes and the easiest way to write them is b"\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f". As soon as you add them controls will be enabled, but the shade might do really strange things, as the commands are still the ones for the types listed in the README.

[gschot]

Done, the numbers with which the files start also correspond with the description in steps in my comment.

And yes, I am able to control the shades now. The shade entity shows an up and down arrow, which seem to control the upper beam of the shade in reverse direction. So pressing the up pointing arrow, actually lowers the upper beam, and the down arrow brings it back up. The slider control does not seem to make any sense yet though.

For regular control with the hub, I was looking for a two sided slider, one side to control the lower beam, one to control the upper. In the Powerview app, it shows as the attached images. The first image shows a static shade ready to be controlled, the second image is when I drew the top beam up where an animation shows the progress of the beam going to the selected position.

[patman15]

Thanks ❤️! At first glance the logs look good. Will investigate deeper.