Weird experience with Skyconnect / ZHA on two HA instalations

Hi,

I have a HA on a Raspberry Pi 4 4 GB in my camper and one in my house. The one in my camper has a SSD and the one in the house a micro SD card. Both of them work fine.

I now wanted to implement Aquara Door / Window sensors via my Skyconnect stick from HA. I tested it with one sensor on the HA in my house, what works as expected. Then I bought 5 more sensors and moved the Skyconnect stick (Yes it is at the extension cord away from USB 3) to my camper HA.

But there no sensor could be paired!

Any idea what could be the problem?

Thanks for help!

Hi,

took the real original cable for the Skyconnect and got one door window sensor paired. But sadly just one. The two others fail to get paired. But I got a log entrance. Just can not understand what it will tell me


??

This is a pain in the a…! Pairing is not working! Anyone an idea what to do?
LOG: [0x9AD0](lumi.sensor_magnet.aq2): Device seen - marking the device available and resetting counter
[0x9AD0](lumi.sensor_magnet.aq2): Update device availability - device available: True - new availability: True - changed: False

I have a maybe similar issue here: I moved my Home Assistant instance from SD card to SSD, restored from backup and my ZHA integration just broke completely as well as the OTB - with a delay of 1-2 days.
Already found another user with the same problem. Could these issues be related? is the sky connect firmware for multiprotocol somehow mapped to the explicit device or installation type?
Sorry I only got guessed here I didn‘t fix it yet but assume I might have to reconfigure the whole ZHA and Matter stuff :confused:
Do you only use Zigbee or Thread as well?

@micky-bamboleo I only use Zigbee and it worked last time after having the same problem before. Dont know why.

Got this new log output
Received a packet: ZigbeePacket(src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x463F), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), dst_ep=1, source_route=None, extended_timeout=False, tsn=154, profile_id=260, cluster_id=0, data=Serialized[b'\x1c_\x11~\n\x01\xffB\x1d\x01!\xef\x0b\x03(\x16\x04!\xa8\x13\x05!(\x00\x06$\x01\x00\x00\x00\x00\n!\x00\x00d\x10\x00'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=200, rssi=-50) [0x463F:1:0x0000] Received ZCL frame: b'\x1c_\x11~\n\x01\xffA\x1d\x01!\xef\x0b\x03(\x16\x04!\xa8\x13\x05!(\x00\x06$\x01\x00\x00\x00\x00\n!\x00\x00d\x10\x00' [0x463F:1:0x0000] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=True, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True), manufacturer=4447, tsn=126, command_id=10, *direction=<Direction.Client_to_Server: 1>) [0x463F:1:0x0000] Decoded ZCL frame: BasicCluster:Report_Attributes(attribute_reports=[Attribute(attrid=0xFF01, value=TypeValue(type=LVBytes, value=b'\x01!\xef\x0b\x03(\x16\x04!\xa8\x13\x05!(\x00\x06$\x01\x00\x00\x00\x00\n!\x00\x00d\x10\x00'))]) [0x463F:1:0x0000] Received command 0x0A (TSN 126): Report_Attributes(attribute_reports=[Attribute(attrid=0xFF01, value=TypeValue(type=LVBytes, value=b'\x01!\xef\x0b\x03(\x16\x04!\xa8\x13\x05!(\x00\x06$\x01\x00\x00\x00\x00\n!\x00\x00d\x10\x00'))]) [0x463F:1:0x0000] Attribute report received: 0xFF01=b'\x01!\xef\x0b\x03(\x16\x04!\xa8\x13\x05!(\x00\x06$\x01\x00\x00\x00\x00\n!\x00\x00d\x10\x00' [0x463F:1:0x0001] Voltage mV: [Min]:2820 < [RAW]:3055 < [Max]:3100, Battery Percent: 84.0 [0x2069]

1 Like

Okay thanks does in fact not look very similar, my logs complain about some python stuff going wrong, but I guess it was worth a try. Can’t help here I’m afraid :confused: Good luck though!

1 Like

@micky-bamboleo thanks for trying! Ordered a Conbee radio. Hopefully it will work. Then the skyconnect stick will be sold!

1 Like

But you do use an extension chord at both of your hardware, right?

Yes, I do use the USB-cable in the package.

1 Like

Did you try this?

Sounds as if this could fix at least your problem, for me it unfortunately didn‘t work.

Hi, I reinstalled everything and then I was able to add new DW devices. But not the water leak sensor. This one worked the next day. Do not know why! I am sorry.

1 Like