I have had the exact same issue as you and been through all the same steps trying to fix my SkyConnect.
I will share that I have finally been able to fix the SkyConnect through an unconventional mehtod. Note, the online firmware tool and the SSH manual method did not work for me.
FIX:
I have an raspberry pi 3 laying around (my HA is currently running on a Synology DS918+ VM). I downloaded and installed a fresh HA OS onto the Raspberry pi 3 after fully booted into a fresh instance I plugged in the SkyConnect and opened the ZHA Integration. BOOM, the SC was fixed.
Not sure what is going in the fresh install that cannot be replicated in my other Synology instance of the Online Firmware Tool.
I hope any others feeling like they have a bricked SC find this helpful.
Well that’s great news! Can I send my brick to you to unbrick it?
I did the same as you, albeit I started with a fresh VM image from Linux - Home Assistant
It seems not completely bricked, but it just can’t be flashed:
I can configure it as zigbee device (on the Hardware tab, “Home Assistant SkyConnect - Configure”)
I get an unknown error when installing ZHA, but it recognizes the dongle as ttyUSB0 (I also tried with entering the full path /dev/serial/by-id/usb-Nabu_Casa_SkyConnect_v1.0_xxxx....)
I can also configure it as Zigbee and OpenThread multiprotocol
NO, Pete, NO! It still looks like such a harmless ‘option’… I ticked the box, and now I’ve a blue table leveler and had to buy an other dongle.
I often install experimentals and beta’s, but this was a very expensive test.
I recommend to just not flash it and wait for succesful stories, and stable releases.
When they’re usable as zigbee devices, I would start with zigbee mode and wait for a while for the Thread / Matter integrations to become stable
You might be surprised with what the install of HA OS does.
When I download the ZHA diagnostics from the integration in my VM HA that the repaired SC is plugged into, I get the following when before I had the same problem as you:
I had to use a USB dongle as drive, to be able to install HA OS on my NUC, while I couldn’t swap the NVMe drive for a SSD drive.
Not recommended while it is damn sloooowwwww, it took several hours before I could use the system
But, unfortunately, I got exactly the same behaviour and errors, so I think I bricked my SkyConnect better than you
Anyone have any success on getting Matter + Thread working on Home Assistant Container + OpenThread Border Router?
I actually have quite a unconventional setup currently:
Instead of SkyConnect or HA Yellow, I have a ESP32-C6 flashed with OpenThread RCP firmware and directly connected to Raspberry Pi via UART GPIO pin
Self compiled OpenThread Border Router docker image with this instruction for home assistant support, I have published the docker image in github if anyone is interested
Installed and configured Matter, Thread and OpenThread Border Router integration in Home Assistant
I’ve also flashed another ESP32-C6 with an matter + thread example firmware, and tried to commission it using home assistant app, but it doesn’t work, here’s the error that shows up in the device
I (124318) chip[DL]: BLE GAP connection established (con 1)
I (124318) chip[DL]: CHIPoBLE advertising stopped
I (125088) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 112
I (125088) chip[BLE]: local and remote recv window sizes = 5
I (125098) chip[BLE]: selected BTP version 4
I (125098) chip[BLE]: using BTP fragment sizes rx 244 / tx 244.
I (125098) chip[DL]: Write request/command received for CHIPoBLE TX CCCD characteristic (con 1 ) indicate = 1
I (125118) chip[DL]: CHIPoBLE subscribe received
I (125118) NimBLE: GATT procedure initiated: indicate;
I (125118) NimBLE: att_handle=14
I (125198) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (125208) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 112
I (125218) chip[EM]: >>> [E:12954r S:0 M:14468822] (U) Msg RX from 0:688CB11788A4FC81 [0000] --- Type 0000:20 (SecureChannel:PBKDFParamRequest)
I (125228) chip[EM]: <<< [E:12954r S:0 M:96659770] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:21 (SecureChannel:PBKDFParamResponse)
I (125248) chip[IN]: (U) Sending msg 96659770 to IP address 'BLE'
I (125248) NimBLE: GATT procedure initiated: indicate;
I (125258) NimBLE: att_handle=14
I (125348) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication(con 1) status= 14
I (125348) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 112
I (125358) chip[EM]: >>> [E:12954r S:0 M:14468823] (U) Msg RX from 0:688CB11788A4FC81 [0000] --- Type 0000:22 (SecureChannel:PASE_Pake1)
I (125438) chip[EM]: <<< [E:12954r S:0 M:96659771] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:23 (SecureChannel:PASE_Pake2)
I (125448) chip[IN]: (U) Sending msg 96659771 to IP address 'BLE'
I (125448) NimBLE: GATT procedure initiated: indicate;
I (125458) NimBLE: att_handle=14
I (125538) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (125548) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 112
I (125558) chip[EM]: >>> [E:12954r S:0 M:14468824] (U) Msg RX from 0:688CB11788A4FC81 [0000] --- Type 0000:40 (SecureChannel:StatusReport)
E (125568) chip[SC]: Received error (protocol code 2) during PASE process: 38
E (125578) chip[SC]: Failed during PASE session setup: 38
E (125578) chip[SVR]: Commissioning failed (attempt 1): 38
I (125588) chip[BLE]: Releasing end point's BLE connection back to application.
I (125598) chip[DIS]: Updating services using commissioning mode 1
I (125608) chip[DIS]: Advertise commission parameter vendorID=65521 productID=32768 discriminator=3841/15 cm=1
E (125608) chip[DIS]: Failed to advertise commissionable node: 3
E (125618) chip[DIS]: Failed to finalize service update: 1c
I (125618) app_main: Commissioning window opened
I (126568) chip[DL]: Write request/command received for CHIPoBLE TX CCCD characteristic (con 1) indicate = 0
I (126568) chip[DL]: CHIPoBLE unsubscribe received
I (126578) chip[DL]: BLE GAP connection terminated (con 1 reason 0x213)
E (126568) chip[BLE]: no endpoint for unsub recvd
I (126588) chip[DL]: Configuring CHIPoBLE advertising (interval 25 ms, connectable)
I (126588) NimBLE: GAP procedure initiated: advertise;
I (126598) NimBLE: disc_mode=2
I (126608) NimBLE: adv_channel_map=0 own_addr_type=1 adv_filter_policy=0 adv_itvl_min=40 adv_itvl_max=40
I (126618) NimBLE:
I (126618) chip[DL]: CHIPoBLE advertising started
I (155598) chip[DL]: Configuring CHIPoBLE advertising (interval 500 ms, connectable)
I (155598) chip[DL]: Device already advertising, stop active advertisement and restart
I (155608) NimBLE: GAP procedure initiated: stop advertising.
I (155608) NimBLE: GAP procedure initiated: advertise;
I (155618) NimBLE: disc_mode=2
I (155618) NimBLE: adv_channel_map=0 own_addr_type=1 adv_filter_policy=0 adv_itvl_min=800 adv_itvl_max=800
I (155638) NimBLE:
I can see the network is formed in otbr web ui but this is how it shows up in home assistant
Thank you Peter, highly appreciated.
I resisted my temptation to proceed thanks to your previous posts but now I know this is the route you went that resulted in breaking your skyport.
I suppose this topic is the place to look for success stories.
If I am already using a Sonoff coordinator for Zigbee with ZHA, is it possible to configure SkyConnect as a Thread router exclusively (ie, no Zigbee)? Is that still considered “multiprotocol”?
I’m not entirely sure, but I suspect that if you add the SiLabs multiprotocol Add-On, that HA may attempt to automatically reconfigure your ZHA to use the multiprotocol stack instead of your Sonoff.
There is however an alternative where you can use the “OpenTread Border Router” Add-On instead of the Multiprotocol Add-On. This should leave ZHA alone and let it run as is, and use SkyConnect only for Thread.
I just got my skyconnect ordered months ago. Since then I have installed a Sonoff P and Zigbee2MQTT is working perfectly. I see no need to redo everything just to use the Sky Connect dongle - especially since there is nothing really I can use with Thread yet! I have been researching an easy way to migrate my Z2M to use multipan, and it looks like the easiest is just to add each device again… but this OpenThread looks like the answer to have the SkyConnect as thread only and keep things separate, especially with the potential of upgrading sky connect in future as new firmwares are required to fix bugs, potentially botching my Zigee. I will try later and see what it does.
I did flash my Skyconnect for Thread only but then it wanted me to use a beta version of HA to support it, so I’m gonna hold off. I don’t have any thread devices anyhow, hah.
I flashed my skyconnect using chrome to the multi-pan, but then I decided to flash back to the ezsp zigbee firmware just to see what happens.
I then plugged into home assistant, and installed the OT Addon and selected the USB port… according to logs if detected the ezsp firmware and flashed it… I restarted and the thread integration picked it up.
Under My network, It now shows the OpenThread Border Router along with the two HomePod minis under Other networks (which were there previously). Have nothing thread yet, but it is ready now
I just received my Yellow box, installation went without a problem. Restore Backup from my iMac dito.
I set up the tread interface and wanted to connect to my trhead network (2 AppleTVs as Border Router) so that I can se my EVE devices in HomeAssistant.
Only way that worked for me is using the pairing option from Apple Home and paired it to both Apple Home and Home Assistant. This seems to work fine but it is not actually using the Thread part in HA as it is still using the AppleTV I have as Home Hub for the Thread Border Router function.
I did the steps at SHARE A DEVICE FROM APPLE HOME.
Sometimes it failed for me and I needed to unplug/remove battery of the Eve devices and try again before it could pair. I have 12 Eve Door/Window sensors and 8 Eve plugs connected through both HA and Apple Home now. I have moved all my Automations to HA now and it reacts ok.
Thanks Daniel, can it be that all your Eve devices have been upgraded to Matter? Eve has not provided that update yet for Thermostats and Aqua. The procedure as described does not give the “ Turn On Pairing Mode” option in Apple Home. That only works for Matter devices and not Thread I believe.
Yes, this only works on devices with Matter firmware. The HomeKit firmware devices can only be paired to one ‘Hub’ at the same time. Thread works over Matter and HomeKit
So you could remove it from Apple Home and than add it to Home Assistant through the HomeKit Controller, as Home Assistant can now use your Apple Home Hub as Thread Border Router, at least it worked with the AppleTV 4K (2022 with ethernet).
Keep in mind you will lose some Eve specific features. With the Matter firmware only the Matter compatible data is given to Home Assistant, the rest is only visible through the Eve app.
Thanks, that’s what I did with the EVE Door/Window which I migrated to Matter. That worked fine.
My issue now is how to integrated the Thread Devices into HA. The HA Border router does not let me integrate the AppleTV Border router (or vice versa). See the screenshot in my post 74 of Aug. 5.
As I said, you can’t pair HomeKit over Thread devices to HomeKit and Home Assistant directly at the same time, this is a limitation of the HomeKit protocol.
Thread is just the communication protocol, but the Eve devices run in either HomeKit over Thread or Matter over Thread mode. Only with the Matter firmware you can pair to multiple platforms at the same time.
When I remove a HomeKit over Thread device from my Apple Home. Home Assistant directly finds a new HomeKit device to pair to Home Assistant. This also worked for the Thread devices.
Afterwards you can share the devices from Home Assistant to HomeKit with the HomeKit Bridge function, but keep in mind, for the Eve app the extra entities are gone, so you will have less features than when it is directly paired to HomeKit.
