I suggest you look at the post under mine and if you have an issue with a word may I suggest you pm the person. I don't consider a person who defends a brand to be derogatory. To each their own.
That's unfortunate. Or perhaps your understanding of the term ad hominem deviates from its common meaning. Ad hominem specifically refers to directing your sentiments about a position to an individual rather than the position expressed by them. The use of "fanboys with blinders" falls in that definition.
And for the record, there is nothing ad hominem in what either @bill.d wrote, or what @thebearmay wrote (the two individuals whose posts directly followed yours in this thread).
To be clear, if anyone said something derogatory about you personally, rather than your position, I would have no problem calling it out, even if their position coincided with mine.
10 Likes
No fanboyism here (not that there's anything wrong with being a fanboy). I told you not to use Hubitat. I gave you the most reliable and possibly cheapest way to do it. I like Hubitat and probably consider it the primary, but it's 1 of about 4 different ways I have devices attached to my automation ecosystem (thinking out of the box).
As you are undoubtedly aware Hubitat is a small company. They can't do everything. And they do it about as well as any other inexpensive DIY system. I imagine such a very small percentage of users would even think of updating firmware, so figuring all firmware update issues isn't going to be high on the list. The Z-Wave updater has its issues too, so you'll note frequent advice to use a secondary controller to do the work. Is it ideal? No. But if you want ideal you'd have a Lutron HomeWorks lighting system.
1 Like
@bill.d I appreciate your attempt to help, and you have been a great asset on my journey with Hubitat. As you might remember from this thread you helped me a lot. But my issues with Hubitat have always been around firmware updating and the fact that incorrect or unstable firmware can bring an entire mesh to a crawl, or brick, as documented in the aforementioned thread.
In that case It was necessary to purchase a z-wave stick, download software, remove all of my Inovelli switches, which was over 50, re-pair them to the stick, update the firmware, re-pair to HE and then re-do all of the rules, integrations etc. With my HE/HA/Google, Alexa, Sense etc integrations, updating firmware when you have to remove the device is not fun, especially when the current firmware causes things not to work and tension at home... ya, that happens. For those inovelli switches it took me at least 20 hours. My point is that here's yet another firmware issue that HE is trying to solve and it's, in my humble opinion, at alpha/beta stage at best.
I have a hue hub already with over 40 lights on it. I could do what you suggest, but it's a hassle and it's not the point I was trying to make and I don't feel that going through those steps is "smooth".
My original suggestion, although it's been beat down because of a word I chose to use, is that Hubitat use tooltips or pull update abilities from devices that aren't working as expected. If we go to the OP, the experience that's illustrated is very simple, easy to understand and should it work that way, would be amazing. But reality is that it doesn't.
Again Bill, I thank you for always being helpful and apologies if anyone is upset over my language.
4 Likes
One issue is that the length of time is very dependent on the device being updated and the routers in the zigbee network.
I’ve seen Hue motion sensors update in 10 minutes, and others take overnight. The suggestion to re-pair them directly to the controller eliminates the variable of an indeterminate number of routers messing with the zigbee packets. In my experience, this alone is sufficient to make the updates both reliable and timely (i.e under 20 minutes). Other suggestions, like picking a time when the network is less busy likely also help.
A separate issue is that the variability in a successful update, and the length of time it takes, is apparently coordinator independent.
1 Like
I'll attempt to illustrate a bit more clearly. I'm suggesting that HE make this clear because I have been attempting an update for more than 24 hours on a single sensor and there's 4 more to go. It still hasn't updated and I clearly get an experience that's documented in various other locations, 1 - 2 - 3 which is "failure".
Mike from Hubitat has confirmed this is a bug 2 months ago. So back to the original suggestion pull it from the updates.
Here's why. I know that I can come here and search for something and I can articulate the problem and possibly the solution. But there's a lot of users, as I mentioned, coming from ST and other platforms. Not everyone knows that they can come to the community and find solutions. It can get frustrating for people and they eventually give up.
Yep. I have turned in several bug reports ever since the Z-Wave Updater app was introduced, that the trashcan icon is so far off the screen to the right side of the screen that it is inaccessible on a mobile device, regardless of orientation. Each time I receive an apology that it will be fixed in the next release, which never arrives in the many months since the Z-Wave Updater app was released.
Works fine on my desktop computer, but slow.
I have now just shrugged my shoulders and use the SiLabs SLUSB001A UZB7 with PC controller. Fast, works well.
OBSERVATION: It seems you're trying to have it both ways here. It cannot be both such a hassle that HE staff should pull the update ability that never even existed prior to the last release, taking away the ability for users WHO DON'T HAVE your issues when doing the updates.
BUT NOT such a hassle that you've been given a solution to your issue but you just don't feel like doing it, even though you admit it would monetarily cost you nothing to do so as you already possess the equipment.
1 Like
Yes, and it was fixed if I recall as well. We can only report what the device tells us in regards to failure, assuming you are running the latest release it doesn't explain why your sensors are rejecting the payloads.
Zigbee updates are stupid simple, the device tells us what firmware file it wants, the maximum data size it will accept and the current offset onto that file. If we have the file, we transmit the requested bytes, if not we tell it we don't and send a message to the logs.
Percent status is sent at 20, 40, 60, 80 and 100 percent complete.
If the device bails and refuses to ask for more bytes there isn't currently much we can do.
In the first release we sent 10 percent less than what the device requested, this failed in busy networks. Currently we send half the bytes the device asks for, there isn't a way i know of to determine what the maximum payload size a given network will support for ota.
3 Likes
@waynespringer79 May I suggest you read my posts before making comments like that... This is a topic about Zigbee OTA Updates, using firmware version 2.2.7 and the Hubitat Hub. It's not a topic about "Todd updating his Hue devices". In your quote of my post it clearly says "it's not the point" referring to the fact that yes I have an avenue to update, however that's not why I'm posting here. I'm posting here as a suggestion to the update process that fails. I just got lambasted for Ad Hominem, so a friendly reminder to criticize ideas, not people.
Moving on ...
@mike.maxwell If the issue was resolved can you explain why I'm getting those errors?
Hubitat Elevation® Platform Version
2.2.7.128
Hardware Version
Rev C-7
It appears that the issue, which is widely reported, is specifically about a wildcard param. Unless I'm missing something how is that relative to the payload size? Seems like the hub is sending something that the device doesn't want to accept.
Have you followed the suggestions made by @aaiyar in the thread about this topic that you linked? Evidently, one of the failure modes of the Hue device is to complain about wildcard param. Yet, as @aaiyar reports, he succeeded in getting these updated.
One of the issues is the mesh between the hub and the device being updated. This is why @aaiyar suggests resetting the device and pairing it close to the hub. Also, this is directly related to @mike.maxwell's post about payload size. With mesh traffic, a larger payload fails at a higher probability. He reduced the payload size to improve this behavior, but there is a tradeoff involved wrt how long the update might take. That's the reason he brought that subject up.
I'm sorry you are having trouble with Zigbee OTA updates. I don't think that pulling the ability to do these at all is an appropriate remedy for something that still has issues for a few users. Most users have had success with this. Could it be improved? Possibly. I think people are reacting poorly to the tone of your posts... Perhaps you aren't aware how it comes across.
6 Likes
It isnt, that's my point! why the device is reporting that is unknown, but that error code is in error...
1 Like
For anyone reading this in the future, this doesn't mean remove it from the hub. Only reset the sensor itself. It won't wreck your automations or anything. You are just forcing the sensor to find a new path.
I believe this suggestion is to do this when the house is quiet, not specifically at 2 AM. If you can give it an hour without much network activity at 5 PM, go for it.
2 Likes
My bit of rampant speculation is that some specific routers (or combination of routers) mangle a zigbee packet. I’ve never seen that error when the device was directly communicating with the hub.
3 Likes
For the previous post which I mentioned regarding the Inovelli switches it was 100% necessary and I was instructed to do as much, by your staff, which completely destroyed all automations. So while this might be the case for some devices that's not true for all.
As you said earlier, in your response to @waynespringer79, this thread is about zigbee ota updates. Very different from zwave devices.
8 Likes
Not my staff, I am not an employee. Just a user like you.
And that was the basis of my statement, and the earlier one by Aaiyar.
8 Likes
After reading this thread and others, and attempting all suggestions 50 Times I am still not able to update firmware on my Hue Indoor Sensor using HE. Getting the wildcard errors. So I linked it to my Hue Bridge and ten minutes later it updated. When I re-linked it to HE the build number does seem to reflect the new build or firmware it still shows the old one. I have rebooted, re-saved the device and parameters, configured, refreshed, and tried update firmware again and get no success updating the Build number in the device on HE.
How can a force the build and firmware numbers to reflect the new Build on HE? Might this be a bug that is contributing to the Update Firmware problems people are experiencing?
I have another identical sensor and it reflects the latest build, how it got there I don’t know. It is actually older that the one I am having problems with.
Any help is appreciated,
LJ
If its not updating then you have a network issue of some sort, likely the very same reason you can't update the firmware on hubitat in the first place.
1 Like
