Any thoughts on this? I'm just worried it could accidentally happen again, it does seem like the hub had thought it found a compatible device to update but it wasn't and so it did get bricked. This is supposed to be impossible according to a previous forum post:
Perhaps it was defective and the update just finished it off.
The hub shouldn't have pushed an update to it if it didn't have the correct firmware to push though?
I don't have this controller but they seem to all work pretty much the same way. Have you factory reset the controller? On the ones I have you have to power cycle them 5 times to factory reset. Maybe contact BTF-lighting and ask how to factory reset. I don't think pressing the set button is going to factory reset it. You can try and exclude it from your hub by going to the device page and removing it, you most likely know this. Most zigbee 3.0 devices should just get removed when you go to the device and click remove. I doubt that you bricked it by trying to push a firmware though hubitat.
Unfortunately, it stopped responding to the reset button (nothing happened, even when pressing it 4 times as needed to pair it to the hub again). No light, and no pairing seen from the HE interface.
Do you have any more info about why you doubt it was the firmware update? It stopped working literally straight after the update was finished so it felt obvious to me.
If the logs are correct and it really did push firmware to the controller, and we've confirmed here that it shouldn't have done that because Hubitat doesn't have the correct firmware, I don't think it's all that unlikely.
I'm not trying to point blame or seek recompense, I just think this is an opportunity to fix a bug.
Correct behavior was Hubitat was supposed to report the firmware was up to date, according to the quoted forum post.
The bug would be on the device, and not the hub as far as I know. A device should not accept nor should it flash incorrect firmware. Typically a device has a hash or key or checksum or something that must match the existing firmware to the new firmware. No checksum match, it bombs out the flash.
I've done just about everything bad that you can do during firmware updates and never bricked a device yet. it's actually not that easy to do nowadays with half decent firmware. Is there a power Led on that controller? Have you tried power cycling it 5 times? Pretty weird that the Hubitat firmware updater actually found a firmware for that device.
I was under the impression the hub checks the model and current firmware and it then decides if it has a later version. At least, that's the way it seems to be explained
"The manufacturer, model ID and existing firmware of the device is inspected and if a match is found with a newer firmware version, then the device is updated, otherwise we bail with a log entry that the device is up to date"
From another thread:
"correct, we do not have any files for those manufacturers."
Indeed I did, in fact, with this controller the 'set' button appeared to just cut power to the controller and you had to press it 4 times. It kind of matches most other Zigbee items where you have to turn them off and on again rapidly to get them into pairing mode.
I came close to buying that controller when I picked up some of BTF's Led's Besides the Bricked part, how do you like the controller? Are the Reds actually red without having to try and fine tune things?
Sorry for the slow response.
I found the controller was 'meh'. It's actually a rebranded generic controller, because other company names are on the exact same controller.
The first one I bought, it was constantly disconnecting from Hubitat 10 seconds after pairing it and refusing to respond. I had this problem happen with one other device from a different brand, not sure if it's the device or Hubitat. Then it stayed connected whilst I was updating it's firmware, but as pointed out, Hubitat shouldn't have updated it's firmware because it doesn't have files for this device, so it was updated in error by Hubitat I think. That bricked and stopped working.
The second controller, the 'set' button wasn't causing the controller to enter pairing mode (was definitely using it correctly). It would pair when powering it up after being unplugged for a while.
I would say the reds were fine, I didn't notice anything odd there! But other than that, it was pretty underwhelming.
I'm using this now instead:
Thanks for the info, I have a few of the same controller. They seem to be good. A little chatty over zigbee. I just paired them to Home Assistant and noticed the colors are much more accurate. Maybe I was just doing something weird in the color settings but reds were pinkish and and some other colors were off. Was using the advanced rgbw driver. Most likely me just being lazy and using the color pallets built into the Apps and RM.
The hub doesnt "push" anything, the user requests an update, the hub checks the manufacture, device type as well as the firmware version reported by the device. If the first two match and the version we have is newer than what the device reports we update the firmware. It is the devices responsibity to report the correct data in the first place as well as verify the image before applying it.
Your beef is with the device manufacturer, not us.
LOl Priceless, pretty sure there's no beef over $20
Sorry if you found it offensive, but Shawnx1 is right - there's not really any beef. I understand that the hub checks the information of the device and then 'sends' (since 'push' is apparently no good) new firmware based on the information the hub receives from the device.
I thought you'd like to know that this method has led to a device being mistakenly updated with firmware that is not compatible, and I assumed you'd like to take a look at it to see if there's a way to prevent it happening to others. It was a pretty easy mistake - I just pressed one button and the device bricked.
More importantly, I've quoted you as saying this scenario is "impossible", I just thought it was worth some acknowledgement that maybe this type of situation wasn't considered before (it happens), even if it's not the Hub's fault, it still was able to happen.
I had read this thread when it was active and just noticed that this has been added to 188.8.131.52. Made me chuckle.
I think I would personally have tweaked the wording to give the "why" - right after "proceed at your own risk," maybe add a sentence that says, "Firmware update files are provided by the device manufacturer. Therefore, Hubitat is not responsible..."
I expect if you need to ask "why?", then you are likely someone who should be investigating the potential impacts of applying the update before proceeding. Granted, a link may be worthwhile, but planting the seed of doubt should be enough for most users. If they don't back out and pursue more info, then.... Well... they should not complain after having not followed the instructions. Something I am guilty of in less important situations...
My perspective was that it makes it more than just a generic warning one might see everyday and just click through - like when they accept terms and conditions for an app etc. If you give the ‘why’ it might carry more weight. But I see your point too.
I do think it's great for sure that the warning is there. Maybe one day in the future there could be a list of devices that Hubitat have official updates for but I won't push it this is a positive step regardless