But does it mean both grayed out “Double tap to full brightness” will stay there forever now? Not a big deal but it does looks weird.
Yeah, that’s what the Trace level log is from.
The Warn level log is the first click only, the Info level log is sent each time it’s clicked, and zigbee.updateFirmware() (and the Trace level log) is triggered on the 2nd (or subsequent) click within 2 seconds,
Yep, I’m on the latest version.
Bummer, that’s odd then – I had zero problems doing my 9 updates to 2.14.
I can’t believe this would be the issue, but I see your Blues are on 2.00… @mamber, that shouldn’t matter, right? 2.14 isn’t dependent on starting from 2.08 or anything like that, true?
3 Likes
some of the dependent updates to get the right params to flow into home assistant aren’t merged in yet. not sure enough how this all works to say if that will fix the problem though
I have other Blues on 2.08, and those have the same issue when I try to update the firmware.
You may need to reach out to Hubitat with that issue.
If you want that parameter gone, you’ll need to delete the switch from HA and then rediscover it in ZHA. The upside of Zigbee is that the device name/automations, etc stick around when you re-add it, but better to double check it just in case.
Alternatively, if you click the Double tap to full brightness > Settings > Advanced settings, you’ll be able to hide or disable that entity to hide it from your UI.
So on ZHA and HA with 160 devices. My blue’s started to update by visually seeing the flash green but when I check all the switches after 12 hours I still see them on firmware 0x01020208. Did they fail or is there a trick to get them to show correctly? Forgive me if I missed something in this thread.
1 Like
It looks like there are failing to upgrade. I’m assuming the network is congested.
Logger: aiohttp.server
Source: /usr/local/lib/python3.10/site-packages/aiohttp/web_protocol.py:403
First occurred: 10:08:29 AM (1 occurrences)
Last logged: 10:08:29 AM
Error handling request
Traceback (most recent call last):
File “/usr/local/lib/python3.10/site-packages/aiohttp/web_protocol.py”, line 332, in data_received
messages, upgraded, tail = self._request_parser.feed_data(data)
File “aiohttp/_http_parser.pyx”, line 551, in aiohttp._http_parser.HttpParser.feed_data
aiohttp.http_exceptions.BadHttpMessage: 400, message=‘Pause on PRI/Upgrade’
1 Like
Anyone have a good guide to downgrade firmware? I upgraded to 2.14 and some of the lights have a terrible buzzing sound now in a 3way, Aux, with Neutral configuration. I am using Zigbee2mqtt but can use whatever to downgrade
1 Like
It’s not possible to downgrade firmware.
It seems your lights preferred the leading edge dimming. You may lose out on peak brightness, but you should be able to swap back to leading-edge dimming by changing to Non-Neutral in your config. Eric alluded to possibly being able to change this with a parameter in a future release.
1 Like
Which bulbs are you using? You might also want to try a factory reset and re-inclusion.
Is there a way to force an upgrade in zha or ha? I killed power to most switches hoping that I can get them to upgrade one or two at a time.
Thanks Eric, they are a Phillips LED tube. They previously worked fine on fw 2.08. That is what Nate @ inovelli support recommended but it unfortunately didn’t help. The next recommendation was to downgrade the Firmware.
yes:
1 Like
This is awesome, thank you!
Oh it is indeed possible, just not the easiest depending on the platform you are on.
2 Likes
I was in the same boat with my updating last night. Huge shoutout to @tube for answering an email offering a solution I sent him in the middle of the night.
The solution he presented was reflashing my esp32 then pulling the air gap on all my switches and pushing back in the airgap a few (3-4) at a time and just letting those update. Once those fully update, do the next 3-4 switches, etc…
Working like a charm now that my zigbee network isn’t being crippled with so much traffic all at once.