Add new Gledopto OTA (READ INFO)

[V4n1X]

Pay attention to the current sw_build_id of your device, there are 2 (maybe more) version of this device!

GL-C-008P_V11376801_only_for_Vxxx76801.ota
model: GL-C-008P (Vxxx76801)
sw_build_id: 11376801
current_file_version: 22

GL-C-008P_V11576802_only_for_Vxxx76802.ota
model: GL-C-008P (Vxxx76802)
sw_build_id: 11576802
current_file_version: 24

[github-actions]

Merging this pull request will add these changes in a following commit:

diff --git a/images/Gledopto/GL-C-008P_V11376801_only_for_Vxxx76801.ota b/images/Gledopto/GL-C-008P_V11376801_only_for_Vxxx76801.ota
deleted file mode 100644
index 1893242..0000000
Binary files a/images/Gledopto/GL-C-008P_V11376801_only_for_Vxxx76801.ota and /dev/null differ
diff --git a/index.json b/index.json
index 0b6d130..e672c84 100644
--- a/index.json
+++ b/index.json
@@ -8330,5 +8330,15 @@
     "manufacturerCode": 4678,
     "sha512": "8d536faa3fe43d469fe9ec4f92ea78cce1874872fb82b4401334a76f23158de62ecdfa1af49604726782ba6119c6c60d8363eabc023c2f0dcff3fe06dee2367f",
     "otaHeaderString": "Tue 06/03/2025 V.0020.0020"
+  },
+  {
+    "fileName": "GL-C-008P_V11576802_only_for_Vxxx76802.ota",
+    "fileVersion": 24,
+    "fileSize": 277306,
+    "url": "https://raw.githubusercontent.com/Koenkk/zigbee-OTA/master/images/Gledopto/GL-C-008P_V11576802_only_for_Vxxx76802.ota",
+    "imageType": 0,
+    "manufacturerCode": 4687,
+    "sha512": "cef0d4365b82330d6de70146931f055b57ef176e0b51b63d38551d64fda50957b4845b8cfaf899d058ddae7a191824723a92324ef0cdb9bd552587e45c294a7d",
+    "otaHeaderString": "EBL ARGBW_V_0_1"
   }
 ]
\ No newline at end of file
diff --git a/index1.json b/index1.json
index b916b71..2069f58 100644
--- a/index1.json
+++ b/index1.json
@@ -2452,5 +2452,15 @@
     "manufacturerCode": 4678,
     "sha512": "2be3ce5ff9e9b378a447285a7f2f099313a8ec067c5565b0ceb9fcb917ba663d022b05ceaeddd20d0205d9b98b1c2986570699d749031f4b54ffd04d14d593c8",
     "otaHeaderString": "Thu 11/09/2023 V.001C.001C"
+  },
+  {
+    "fileName": "GL-C-008P_V11376801_only_for_Vxxx76801.ota",
+    "fileVersion": 22,
+    "fileSize": 276878,
+    "url": "https://raw.githubusercontent.com/Koenkk/zigbee-OTA/master/images1/Gledopto/GL-C-008P_V11376801_only_for_Vxxx76801.ota",
+    "imageType": 0,
+    "manufacturerCode": 4687,
+    "sha512": "d8e682e9179ba9353e4ea7e8494ca440be6f5458772e37b82f99ec6184b0cbeace263e8787af5c69da7ab3275ea14b3cc3c2f318b2c9af72aa8c9b43a6d5344d",
+    "otaHeaderString": "EBL ARGBW_V_0_1"
   }
 ]
\ No newline at end of file

[Koenkk]

Given Gledopto OTA updates caused a mess before (#827), I'm inclined to not accept any new Gledopto OTAs anymore, because how are we going to guarantee this is not going to break more devices?

[V4n1X]

Yes you are right, thats only the case if there is ability to check the current installed sw_build_id for the matching hardware revision, and to serve then only the right version, I don't know if that is possible.

Maybe we put the Gledopto Updates into a category for manual updates, with informations about it.

[Koenkk]

Yes you are right, thats only the case if there is ability to check the current installed sw_build_id

This can be added but the problem is that older z2m instances and ZHA won't check for this so they will feed the wrong OTAs to the device. I propose to keep it manual indeed with some instructions. Maybe we can document it on the device page

[Nerivec]

Not sure what the devices are reporting (i.e. if possible), but looks like this wouldn't work anyway without at least one of these:

    hardwareVersionMin?: number;
    hardwareVersionMax?: number;
    minFileVersion?: number;
    maxFileVersion?: number;

(as can be seen, the detection put one in index1 - detected "older")

[davux]

It looks like there is still a confusion around Gledopto OTAs. See #865 for example.
For example, I'm getting this log in z2m:

zhc:ota: [0xa4c138a7bb787072 | GL-C-008P] Getting latest image, meta: {"fileName":"C-ZB-LC20_V30151203_20250904.ota","fileVersion":838938625,"fileSize":203346,"url":"https://raw.githubusercontent.com/Koenkk/zigbee-OTA/master/images/Candeo/C-ZB-LC20_V30151203_20250904.ota","imageType":5145,"manufacturerCode":4687,"sha512":"8effcb4304d10f0af0fa5b3dc40d0724844f23d3cbfbd409bbfff7549c3483cd04c01652c17cb423ffb6ca3ce24e9589290109530fa19e3bc5033476ae3a17ee","otaHeaderString":"Telink OTA Sample Usage"}

So in my example it's a Gledopto GL-C-008P but for some reason it's fetching Candeo/C-ZB-LC20_V30151203_20250904.

[Koenkk]

@davux this is because Gledopto uses the spec very badly (I fixed this case)

[Anemia7635]

Just semi-bricked two Gledopto GL-C-008P while OTA flashing via ZHA (not using z2m). They can no longer change mode, are stuck in RGBW, and one is now presenting itself as "C-ZB-LC20v2-RGBCCT by Candeo". Both flash angry red leds when trying to change mode. Naming is not so important to me, but mode is. Will it be possible to reflash/salvage somehow? The one with new name is also stuck in an upgrade loop, running 0x31013001, repeatedly trying to install 0x32013001.

[Ltek]

@V4n1X @Koenkk I suspect none of this is Gledopto's fault.

I just posted some enhancement requests that would make OTA easier for users and more failure proof.
... #869

I've been working with the Gledopto firmware dev for over a week now to create a customer FW for me. He's been really great. The FW you are all talking in this thread he told me that was never posted by Gledopto. It is a custom FW that a user posted which was never meant for public release.

The enhancements I hope you put in place would make all these problems easily avoidable and easily reversible... which they are not currently either of those since the user is blind to any real info about the FW that Z2M presents the user. The user must 'trust' that Z2M has proper FW to give, and in the above case, it did not.

[MartB]

@Ltek any updates on this?

[Ltek]

@Ltek any updates on this?

Not sure what you are looking for. I dont believe any enhancements have been made to Z2M's OTA system.

Adding a local OTA file is not intuitive and the docs are super unclear (though it does work). Knowing what OTA file the system is deciding to use (local or online) is impossible since the system does not tell you where the 'suggested update' is coming from.

[drylith]

@Ltek
I think you've got the local override feature, which has worked for me seamlessly:

Update your z2m to the latest version (2.9.2 as today) docker pul koenkk/zigbee2mqtt:latest

In the configuration.yaml do:

ota:
  zigbee_ota_override_index_location: <path_to_my_index.json>

It you are running z2m in a container, create a my_index.jsonin the shared volume as follows and edit to your needs:

[
  {
    "fileName": "my.ota",
    "url": "path/to/my.ota",
    "fileVersion": 8194,
    "fileSize": 147232,
    "imageType": 11,
    "manufacturerCode": 4742
  }
]

Then place your custom ota file path/to/my.ota in the shared volumes as well.

Restart z2m and check the device for update on the ota section. You should see an information about the update in the logs which points at your path/to/my.ota

In general, when trying to update, z2m searches in the index.json (index1.json after maybe?) of this repo. When the override configuration is set, this gets searched first.

[andrei-lazarov]

@drylith no need for this. You now have the user interface

Index1 is searched when downgrading

[wojciechczyz]

Hi, so which is the correct firmware to flash manually in those cases? I have firmware ID is 20220923, Firmware version 20, after some power outages I am left with some controllers disconnected. Sometimes power cycling again helps, sometimes not...

[ccutrer]

I've been working with the Gledopto firmware dev for over a week now to create a customer FW for me. He's been really great. The FW you are all talking in this thread he told me that was never posted by Gledopto. It is a custom FW that a user posted which was never meant for public release.

Any update on this? I've got several (actual) GL-C-008P, and I'm having a helluva time with them. Some of them work fine, but some of them seem to just drop off the Zigbee network after only a few seconds. If I reset it locally, it starts working again-- for a few seconds. I'm running firmware ID 20551203 (dated 20240513).

[Ltek]

Any update on this? I've got several (actual) GL-C-008P, and I'm having a helluva time with them. Some of them work fine, but some of them seem to just drop off the Zigbee network after only a few seconds. If I reset it locally, it starts working again-- for a few seconds. I'm running firmware ID 20551203 (dated 20240513).

Your issue is most likely weak signal or signal lacks stability, not likely a FW issue. Make sure your RGB controllers are near devices that route or have a strong signal strength. I've not had any issues with these controllers dropping off the network. I have a 74 device zigbee network where ~25 are wall powered and do routing, I've had stability issues until I added 3 strategically place (aka, try a few different places in the house and let settle for a day -- a few diff locations/days) wall outlets (routers) until it became stable. It makes no sense, but it worked.. zigbee mesh is just not very good, zwave is 10x better (I have large networks for both, and used Zwave before zigbee was mainstream)

If you have the GL-C-008P in the attached image, those are not what I have, no idea if the FW is compatible, and would not want you to brick your device...

I have these...

[ccutrer]

Yeah, it's not signal... I have 293 devices in my Zigbee network, 285 of them are routing. Once one joins and is stable, it's good to go from there. It's just the initial join - the device forcefully leaves the network every 30 seconds. I was able to get all but one of them working eventually. My trick seemed to be to cut power at 20-25 seconds. I'd guess a firmware bug that was causing it to leave 30 seconds after joining, but if I could cut power after it had persisted the network join, but before it hit the "leave" loop, the next boot wouldn't hit it and I was good.

And yes, I have actual GL-C-008Ps. I needed the "pro" line because it has a much wider supported voltage range, and I'm running my lights at a very unusual voltage of 35V (though I was using a 12V source to do the initial join on the problematic ones, because it was much easier to unplug at my workbench with a regular DC barrel connector power supply). I need a whole bunch (and the unusual voltage) because I'm converting basically commercial grade LED ceiling panels that are over 1 amp each.

[Ltek]

And yes, I have actual GL-C-008Ps. I needed the "pro" line because it has a much wider supported voltage range, and I'm running my lights at a very unusual voltage of 35V (though I was using a 12V source to do the initial join on the problematic ones, because it was much easier to unplug at my workbench with a regular DC barrel connector power supply). I need a whole bunch (and the unusual voltage) because I'm converting basically commercial grade LED ceiling panels that are over 1 amp each.

Gotcha, yea I've not seen/used anything beyond commercial 24v. My commercial Prolux strips are 24V DC • 350Lm/ft • 7W/ft so high wattage and the controllers I have run them fine, they dont even get warm.