New Ubisys Firmware can not be installed #19129
Labels
problem
Something isn't working
Comments
|
I've seen this one or twice if the device had issues communicating with the coordinator, it will basically timeout fetching blocks. Moving the device closer to the coordinator might help. (Although when they are install in wall it can be difficult to do so) |
Danit2
changed the title
|
I'm having the very same issue with my 2 Ubisys D1-R, both less than 2 meters away from my Sonoff-P dongle (LQI > 170), using Z2M 1.33.0-1. |
|
Is the Sonoff-P the TI or EmberZNet variant? |
|
Me too. With env:
The updates to the previous fw 2.21 from June was fine. Without any problems. The s1-r is only 20 cm from yellow. But there was a hint from Ubisys fw 2.21 doc. They h‘ve „Added safeguards against some misbehaving third party OTA servers“ . Could this be the issue? From which fw version did you start the update? |
|
I seem to be able to replicate it with my C4, will try to do some more digging this weekend. While sniffing the traffic. |
|
At a quick glance it does seem the device never enters the OTA mode and is bot requesting new blocks. It might indeed be related to the changes from the previous update. I wonder what we might be doing different from what they expect. |
The "P" is the TI CC2652P variant. |
|
I am having the same issue with all 17 devices. Interestingly, I had to exchange one due to a defect this weekend. Updating from 1.9.2 to 2.3.0 worked fine. |
Yep it looks like none on 2.2.1 are requesting blocks once z2m initiates the OTA. And older device i had around for testing worked fine when i tried when i got originally pinged. That was on my dev network, not realizing there was a new fw. All Ubisys devices on my prod netwerk are on 2.2.1 and none (only tried one of each type) seem to want to update. (I tried H1, S1, S2, C4, and J1) I fear that the devices in 2.3.0 will probably also refuse a future update as they should have the same fix as devices on 2.2.1. There are a few intermediate firmwares needed for a full upgrade chain, but 2.x should all work. So in the case if a device < 2.x it will just go to the latest 2.x it can get. I'll try and sniff traffic this weekend to see what z2m sends to the device and if it responds at all or not. Based in herdsman logging, it doesn't respond at all. |
|
I just came across exactly the same issue with LD6 for which I'm trying to implement a converter. |
|
@Koenkk it seems when the device does a OTA check we respond either no image available. It seems the Ubisys device then won't requests blocks when we the coordinator try to start one later. I wonder it will only so it if we send them after the device itself requests it. Would that make sense? |
|
how often does the device check? |
~ every 1 minute |
|
@sjorge does it work after increasing the timeout to e.g. |
|
The timeout already seems to be 150000 ? Basically what seems to happen is, the device requested OTA, we so we have no image. |
Do you see a |
|
I upped it to Seems to just be stuck doing nothing. |
|
Interesting, I got with the massive time out is working The cover one, is stil stuck. I also got a 3rd one that didn't make any progess at all that just timed out.
I also noticed a lot of info publishes that don't seem to have a trigger associated with it. Without grep the log is too verbose to be readable unfortuantely. Edit: grepped with -B4 doesn't show anything related to the device before it either. 🤷 |
|
I am not sure if it helps. Request: Response: But then, the ubisys immediately responds with a default answer: For me (without any zigbee knowledge), this could be the reason, why it won't start pulling the image blocks. Meaning we have some sort of specialities in our response which makes the ubisys stack unhappy. Maybe anyone has a ubisys bridge to sniff their traffic? Edit: |
|
That one switch did manage to update for me, no luck with any of the others though 😞~ sjorgeOn Oct 3, 2023, at 21:18, Sven Soltermann ***@***.***> wrote:
I am not sure if it helps.
I sniffed the traffic this evening. After restarting Zigbee2Mqtt, the first time, a ZCL OTA Query Next Image Response is sent to the device:
Request:
Response:
But then, the ubisys immediately responds with a default answer:
For me (without any zigbee knowledge), this could be the reason, why it won't start pulling the image blocks.
Meaning we have some sort of specialities in our response which makes the ubisys stack unhappy.
Maybe anyone has a ubisys bridge to sniff their traffic?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Not sure if this might be helpful, but this happens right after I turn the LD6 on: and this after pressing "Update device firmware" button from UI: Without knowing anything about it, the
|
|
Also, check #19161 : Could this be a generic issue? |
@sjorge this is basically what we do when the timeout is big enough (since the device requests an update any minute it's not a problem). I don't understand why this doesn't already work:
Could you add some @svenso thanks for the sniff, but to compare the behaviour a sniff with the original hub is needed. However I expect that that hub just waits for the |
|
@Koenkk
Here is the working Query Next Image Response Frame: I am able to share the whole dump privately, if it helps / is required. |
Koenkk
added a commit
to Koenkk/zigbee-herdsman
that referenced
this issue
Oct 7, 2023
Koenkk
added a commit
that referenced
this issue
Oct 7, 2023
Koenkk
added a commit
to Koenkk/zigbee-herdsman-converters
that referenced
this issue
Oct 7, 2023
|
@svenso found the issue, we responded with the wrong transaction sequence number. This probably also explain why device kept requesting OTA even when we responded with a Integrated all the fixes! Changes will be available in the dev branch in a few hours from now. (https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html) |
|
I was just about to add some console logs, but since its already fixed i just verified it is indeed fixed. Working now! Strange it ever worked without. |
|
Please re-open with reference to #19283 None of my Ubisys Devices (S1, H1) can be updated using latest-dev, Build: 81a8df9 |
FabianMangold
pushed a commit
to FabianMangold/zigbee2mqtt
that referenced
this issue
Oct 31, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened?
When i want to update the new firmware i receive the following error:
This happen on all my 16 devices.
Is this a problem of the device or from Z2M?
@sjorge do you habe the same problem?
What did you expect to happen?
I can update the firmware.
How to reproduce it (minimal and precise)
Try to update.
Zigbee2MQTT version
1.33.0
Adapter firmware version
20221226
Adapter
Sonoff-P
Debug log
No response
The text was updated successfully, but these errors were encountered: