search

Koenkk / zigbee-herdsman-converters

Collection of device converters to be used with zigbee-herdsman
MIT License
880 stars 2.92k forks source link

Adding Support for GLEDOPTO GL-C-001P #3016

Closed KingJ closed 2 years ago

KingJ commented 3 years ago

GLEDOPTO have a new "5 in 1" Zigbee LED Controller, which can change modes between RGBCCT, RGBW, RGB, CCT and just dimming by physically pressing a button on the controller. Although the device itself has a model number of GL-C-001P printed on it, it identifies itself as a GL-C-003P in zigbee2mqtt.

I've been able to add a new local device definition for this, and it is working for me in RGBCCT mode. However, i'm a little unsure how to contribute this back with full support for detecting which mode it is in. GLEDOPTO's support have said that the model will vary depending on the current mode, however i've not been able to see this happen unless I add a basic device definition. Without one, regardless of mode the modelID in the database under the genBasic endpoint's attributes is always GL-C-007P. After adding the following basic device definition, the genBasic modelID does get updated when changing the mode, although this does force a re-pair. To see this model change in the database file, I have to go and run a query for genBasic modelID, then send a configure request.

const definition = {
    zigbeeModel: ['GL-C-003P'], // The model ID from: Device with modelID 'lumi.sens' is not supported.
    model: 'GL-C-003P', // Vendor model number, look on the device for a model number
    vendor: 'Gledopto', // Vendor of the device (only used for documentation and startup logging)
    description: 'Zigbee 5 in 1 Smart LED Controller', // Description of the device, copy from vendor site. (only used for documentation and startup logging)
    extend: extend.light_onoff_brightness_colortemp_color(),
};

GLEDOPTO support said the mapping is as follows;

GL-C-001P is the model of the controller and this controller can realize the five types of RGBCCT\RGBW\RGB\CCT\DIMMER. Each type of lamp searched for is different. Corresponding to GL-C-008P\GL-C-007P\GL-C-003P \GL-C-006P\GL-C-009P

Which would map to;

Any ideas on how best to add support for this? I think I need to use the fingerprint functionality, but all the existing examples match on endpoints. Would it be possible to match on the genBasic modelID instead?

Sample database entry, captured in RGBCCT mode;

{
    "id": 12,
    "type": "Router",
    "ieeeAddr": "0xcc86ecfffebfb226",
    "nwkAddr": 15450,
    "manufId": 4687,
    "manufName": "GLEDOPTO",
    "powerSource": "Mains (single phase)",
    "modelId": "GL-C-003P",
    "epList": [
        1,
        242
    ],
    "endpoints": {
        "1": {
            "profId": 260,
            "epId": 1,
            "devId": 258,
            "inClusterList": [
                0,
                3,
                4,
                5,
                6,
                8,
                768,
                4096
            ],
            "outClusterList": [
                25
            ],
            "clusters": {
                "genBasic": {
                    "attributes": {
                        "modelId": "GL-C-008P",
                        "manufacturerName": "GLEDOPTO",
                        "powerSource": 0,
                        "zclVersion": 3,
                        "appVersion": 0,
                        "stackVersion": 0,
                        "hwVersion": 0,
                        "dateCode": "",
                        "swBuildId": "10276801"
                    }
                },
                "lightingColorCtrl": {
                    "attributes": {
                        "colorCapabilities": 31,
                        "colorTempPhysicalMin": 158,
                        "colorTempPhysicalMax": 495,
                        "colorMode": 1,
                        "currentX": 22378,
                        "currentY": 11189,
                        "enhancedCurrentHue": 0,
                        "currentSaturation": 0,
                        "colorTemperature": 158
                    }
                }
            },
            "binds": [],
            "configuredReportings": [],
            "meta": {}
        },
        "242": {
            "profId": 41440,
            "epId": 242,
            "devId": 97,
            "inClusterList": [],
            "outClusterList": [
                33
            ],
            "clusters": {},
            "binds": [],
            "configuredReportings": [],
            "meta": {}
        }
    },
    "appVersion": 0,
    "stackVersion": 0,
    "hwVersion": 0,
    "dateCode": "",
    "swBuildId": "10276801",
    "zclVersion": 3,
    "interviewCompleted": true,
    "meta": {
        "configured": 2
    },
    "lastSeen": 1631359856262
}

Dimmer mode (but with the same device definition above, which may explain the presence of lightingColourCtrl attributes?);

{
    "id": 12,
    "type": "Router",
    "ieeeAddr": "0xcc86ecfffebfb226",
    "nwkAddr": 44722,
    "manufId": 4687,
    "manufName": "GLEDOPTO",
    "powerSource": "Mains (single phase)",
    "modelId": "GL-C-003P",
    "epList": [
        1,
        242
    ],
    "endpoints": {
        "1": {
            "profId": 260,
            "epId": 1,
            "devId": 258,
            "inClusterList": [
                0,
                3,
                4,
                5,
                6,
                8,
                768,
                4096
            ],
            "outClusterList": [
                25
            ],
            "clusters": {
                "genBasic": {
                    "attributes": {
                        "modelId": "GL-C-009P",
                        "manufacturerName": "GLEDOPTO",
                        "powerSource": 0,
                        "zclVersion": 3,
                        "appVersion": 0,
                        "stackVersion": 0,
                        "hwVersion": 0,
                        "dateCode": "",
                        "swBuildId": "10276801"
                    }
                },
                "lightingColorCtrl": {
                    "attributes": {
                        "colorCapabilities": 0,
                        "colorTempPhysicalMin": 158,
                        "colorTempPhysicalMax": 495,
                        "colorMode": 1,
                        "currentX": 22378,
                        "currentY": 11189,
                        "enhancedCurrentHue": 0,
                        "currentSaturation": 0,
                        "colorTemperature": 158
                    }
                }
            },
            "binds": [],
            "configuredReportings": [],
            "meta": {}
        },
        "242": {
            "profId": 41440,
            "epId": 242,
            "devId": 97,
            "inClusterList": [],
            "outClusterList": [
                33
            ],
            "clusters": {},
            "binds": [],
            "configuredReportings": [],
            "meta": {}
        }
    },
    "appVersion": 0,
    "stackVersion": 0,
    "hwVersion": 0,
    "dateCode": "",
    "swBuildId": "10276801",
    "zclVersion": 3,
    "interviewCompleted": true,
    "meta": {
        "configured": 2
    },
    "lastSeen": 1631360220867
}
github-actions[bot] commented 2 years ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

KingJ commented 2 years ago

Reopening - i'm still not sure how to properly add support for this device, and it doesn't look to have been added by anyone else yet.

cosmaz commented 2 years ago

I have the same problem!

uncle-fed commented 2 years ago

I have this device and can confirm most of the things from the first post, except that in my case, this device gets recognized as GL-C-008P every time, even when I change its mode of operation.

The device is great not only because it is universal in terms of colour mode selection, not only because it supports all PSU voltages from 12V to 54V, but it also allows to select power frequency parameter that helps to eliminate very annoying high frequency noise that comes from typical LED power supplies. I think this is an absolute killer feature and I personally plan to replace all of my LED ZigBee controllers with it. It would be a shame if this device wasn't properly supported in Zigbee2MQTT.

@Koenkk, I think we need some help here, as this is an unprecedented case, not a "just follow the instruction on how to add new device". The device is really like having 5 different ones (where you can switch between them), with different properties allowed in each case, but it is being recognized and paired as only one of them.

Let me know if any debug output or ZigBee network capture is needed to create full support, I would be glad to help.

Koenkk commented 2 years ago

Can someone try the following:

uncle-fed commented 2 years ago

After the first pairing as a simple "dimmer" (mode 5) of this device:

{
    "id": 33,
    "type": "Router",
    "ieeeAddr": "0xcc86ecfffebfb221",
    "nwkAddr": 28486,
    "manufId": 4687,
    "manufName": "GLEDOPTO",
    "powerSource": "Mains (single phase)",
    "modelId": "GL-C-008P",
    "epList": [
        1,
        242
    ],
    "endpoints": {
        "1": {
            "profId": 260,
            "epId": 1,
            "devId": 257,
            "inClusterList": [
                0,
                3,
                4,
                5,
                6,
                8,
                768,
                4096
            ],
            "outClusterList": [
                25
            ],
            "clusters": {
                "lightingColorCtrl": {
                    "attributes": {
                        "colorCapabilities": 0,
                        "colorTempPhysicalMin": 158,
                        "colorTempPhysicalMax": 495
                    }
                },
                "genBasic": {
                    "attributes": {
                        "appVersion": 0,
                        "stackVersion": 0,
                        "hwVersion": 0,
                        "dateCode": ""
                    }
                }
            },
            "binds": [],
            "configuredReportings": [],
            "meta": {}
        },
        "242": {
            "profId": 41440,
            "epId": 242,
            "devId": 97,
            "inClusterList": [],
            "outClusterList": [
                33
            ],
            "clusters": {},
            "binds": [],
            "configuredReportings": [],
            "meta": {}
        }
    },
    "appVersion": 0,
    "stackVersion": 0,
    "hwVersion": 0,
    "dateCode": "",
    "swBuildId": "10276801",
    "zclVersion": 3,
    "interviewCompleted": true,
    "meta": {
        "configured": 2
    },
    "lastSeen": 1643372393691,
    "useImplicitCheckin": true
}
uncle-fed commented 2 years ago

After another pairing as RGBCCT (mode 1):

{
    "id": 33,
    "type": "Router",
    "ieeeAddr": "0xcc86ecfffebfb221",
    "nwkAddr": 40754,
    "manufId": 4687,
    "manufName": "GLEDOPTO",
    "powerSource": "Mains (single phase)",
    "modelId": "GL-C-008P",
    "epList": [
        1,
        242
    ],
    "endpoints": {
        "1": {
            "profId": 260,
            "epId": 1,
            "devId": 269,
            "inClusterList": [
                0,
                3,
                4,
                5,
                6,
                8,
                768,
                4096
            ],
            "outClusterList": [
                25
            ],
            "clusters": {
                "genBasic": {
                    "attributes": {
                        "modelId": "GL-C-008P",
                        "manufacturerName": "GLEDOPTO",
                        "powerSource": 0,
                        "zclVersion": 3,
                        "appVersion": 0,
                        "stackVersion": 0,
                        "hwVersion": 0,
                        "dateCode": "",
                        "swBuildId": "10276801"
                    }
                },
                "lightingColorCtrl": {
                    "attributes": {
                        "colorCapabilities": 31,
                        "colorTempPhysicalMin": 158,
                        "colorTempPhysicalMax": 495
                    }
                }
            },
            "binds": [],
            "configuredReportings": [],
            "meta": {}
        },
        "242": {
            "profId": 41440,
            "epId": 242,
            "devId": 97,
            "inClusterList": [],
            "outClusterList": [
                33
            ],
            "clusters": {},
            "binds": [],
            "configuredReportings": [],
            "meta": {}
        }
    },
    "appVersion": 0,
    "stackVersion": 0,
    "hwVersion": 0,
    "dateCode": "",
    "swBuildId": "10276801",
    "zclVersion": 3,
    "interviewCompleted": true,
    "meta": {
        "configured": 2
    },
    "lastSeen": 1643372852028,
    "useImplicitCheckin": true
}
uncle-fed commented 2 years ago

@Koenkk can this issue be re-opened, please?

Koenkk commented 2 years ago

@uncle-fed could you check whether the modelID changes per mode? So:

uncle-fed commented 2 years ago

@Koenkk I've done the required actions (the endpoint was "1", not "11" like on your screenshot, just reporting this for completeness sake. The other possible endpoint was 242, but it did not allow queries like that).

Basically, all 5 modes report different and correct modelID (as per first post here):

  1. RGBCCT: GL-C-008P
  2. RGBC: GL-C-007P
  3. RGB: GL-C-003P
  4. CCT: GL-C-006P
  5. Dimmer: GL-C-009P

Though the main log file always shows the same device name, in every mode: identified as: Gledopto Zigbee LED Controller RGB+CCT (pro) (GL-C-008P).

The web UI also does not change properly (i.e. when mode 5 dimmer is enabled, UI has all the controls for RGB, etc.)

Koenkk commented 2 years ago

@uncle-fed looks good, having this change on the fly might require more complicated changes. However I expect that the following should work:

uncle-fed commented 2 years ago

@Koenkk This did work, indeed! Thanks for the (hopefully temporary ;-)) workaround!

Koenkk commented 2 years ago

@uncle-fed so with this, the device is fully supported?

uncle-fed commented 2 years ago

@Koenkk Well, yes and no.

If by full support you mean that the manual manipulations (reading model id and z2m restart) eventually bring you to the state where you can control device as intended and it is recognized as one of the 5 devices, then yes, from that point of view the procedure is effective.

If you mean that every mode works 100%, then no. The RGB mode 3 is not working, because z2m does not include support for the GL-C-003P device in general. With the above manipulations the device is starting to be recognized as GL-C-003P, which can also be seen in the logs, but of course, the message Device '0xXXXXXXXXX' with Zigbee model 'GL-C-003P' and manufacturer name 'GLEDOPTO' is NOT supported, please follow https://www.zigbee2mqtt.io/advanced/support-new-devices/01_support_new_devices.html.

I hope I can help finishing the device support in that RGB mode by following the link. But what about 'more complicated changes' that will allow to correctly detect this device mode of operation without restarting z2m?

Koenkk commented 2 years ago

@uncle-fed

With the above manipulations the device is starting to be recognized as GL-C-003P

I've added support for the GL-C-003P could you check if it works?

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)

But what about 'more complicated changes' that will allow to correctly detect this device mode of operation without restarting z2m?

Could you check if just repairing the device also does the trick? If not, does a force remove + repair?

uncle-fed commented 2 years ago

@Koenkk

I've added support for the GL-C-003P could you check if it works?

Yes, it seems to work now in this mode as intended too, thank you!

Could you check if just repairing the device also does the trick? If not, does a force remove + repair?

If you mean to replace the step where you "restart z2m" with remove/force remove and then re-pair operation -- no, this does not do the trick. The device is still being recognized as the same (incorrect) one after re-pairing (as if the Model ID reading operation was never done). Only reading model ID and then restarting z2m forces z2m to change the model to the one that it got via the last manual "read Model ID" operation.

One other thing needs to be mentioned, there is no dedicated (re)pair button on this device. The button that causes the device to (re)pair is also the same one that changes the device mode of operation. In other words, it is not possible to simply re-pair without changing its current mode with some kind of "reliable" button press. You'd have to press the button many times to do the full circle of modes to go back to the same mode AND cause the re-pair, which is quite fiddly.

One more related thought. If this device is to be supported for OTA updates, then, I suppose, it needs to be recognized by z2m as the actual device in reality, i.e. GL-C-001P, and not one of the 5 devices it is trying to imitate. If this is so, then z2m should be fully aware that it operates GL-C-001P in RGBCCT mode rather than GL-C-008P. I have no idea how difficult that would be (or possible at all), but I can happily assist if any further debug or raw Zigbee traffic capture is needed. I only have older Gledopto devices (without P at the end), so unfortunately cannot compare things one-to-one, if that would be needed.

Koenkk commented 2 years ago

If you mean to replace the step where you "restart z2m" with remove/force remove and then re-pair operation -- no, this does not do the trick. The device is still being recognized as the same (incorrect) one after re-pairing (as if the Model ID reading operation was never done). Only reading model ID and then restarting z2m forces z2m to change the model to the one that it got via the last manual "read Model ID" operation.

I see, making this better will require quite some changes to z2m and I don't think that is worth it:

One more related thought. If this device is to be supported for OTA updates, then, I suppose, it needs to be recognized by z2m as the actual device in reality, i.e. GL-C-001P, and not one of the 5 devices it is trying to imitate. If this is so, then z2m should be fully aware that it operates GL-C-001P in RGBCCT mode rather than GL-C-008P. I have no idea how difficult that would be (or possible at all), but I can happily assist if any further debug or raw Zigbee traffic capture is needed. I only have older Gledopto devices (without P at the end), so unfortunately cannot compare things one-to-one, if that would be needed.

We cannot distinguish these devices since the GL-C-001P misuses the model ID of the other P controllers. Note that the OTA update matching does not rely on the modelID. There are 2 possible ways gledopto implemented this:

uncle-fed commented 2 years ago

making this better will require quite some changes to z2m and I don't think that is worth it

How about automating the step "Read model ID" as a part of the pairing procedure? As I described above, this device leaves zigbee network and enters pairing mode every time you change its mode of operation. So with that in mind, it is impossible that you can change the mode/modelID without causing the device to re-pair. Can this extra "reading the model ID" step be done as a part of the "configuring the device" that you see in the log files at the end of the pairing often? Or is that "configuring" operation something that cannot be extended with the custom actions? I mean, if this was possible to add into a standard pairing routine for this device, then another very simple (automated) check could compare the model ID that device reports during paring and during the "get" operation and if they differ, another message in the log file can say that you should be restarting z2m manually to finish the setup. And yes, of course the behaviour needs to be documented.

There are 2 possible ways gledopto implemented this

Just shows me again that one should never assume. I know very little about how the OTA works in z2m and I assumed that it is z2m that is programmed with the logic and URLs for each device OTA. But it sounds, from what you're saying, that z2m has very little to do with the choices here, and the implementation of picking the right firmware is on the vendor side. If that is the case, then of course there is very little one can do about it.

MartB commented 2 years ago

Slightly offtopic, but seeing as these device enter the wild i wanted to add sth:

I got the GL-C-002P (mini version of the 001P) based on a Telink TLSR8258 and its beyond busted in my setup. It initially pairs once and after a power loss loses the connectivity and can never be re-paired again.

Is this the same for the 001P? It also does the model switching exactly like described here.

I bought an older GL-C-007 pro controller to verify if this also drops of the network with a leave message. Also talking with gledopto support to hopefully shine some light on this issue.

Pairing the thing with an amazon alexa echo show works fine.

Koenkk commented 2 years ago

@uncle-fed

As I described above, this device leaves zigbee network and enters pairing mode every time you change its mode of operation.

I missed this. Z2M will always reconfigure devices when they leave and after that join again. So we can read modelID in the configure. I've implemented this now, does the following work?

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)

uncle-fed commented 2 years ago

@Koenkk I've tested the change, it does work as you've described, so thanks very much so far.

Perhaps, something worth considering for further improvement:

  1. There are the following messages now in the log file during z2m startup:

    Feb 03 21:02:41 rpi systemd[1]: Started zigbee2mqtt.
Feb 03 21:02:42 rpi npm[16313]: > zigbee2mqtt@1.23.0-dev start /opt/zigbee2mqtt
Feb 03 21:02:42 rpi npm[16313]: > node index.js
Feb 03 21:02:45 rpi npm[16313]: 'GL-C-006P' has configure in extend and device, this is not allowed
Feb 03 21:02:45 rpi npm[16313]: 'GL-C-007P' has configure in extend and device, this is not allowed
Feb 03 21:02:45 rpi npm[16313]: 'GL-C-003P' has configure in extend and device, this is not allowed
Feb 03 21:02:45 rpi npm[16313]: 'GL-C-008P' has configure in extend and device, this is not allowed
Feb 03 21:02:45 rpi npm[16313]: 'GL-C-009P' has configure in extend and device, this is not allowed

  2. When device changes mode and thus performs (re-)pairing, it produces the following messages in the log:

Feb 03 21:07:47 rpi npm[16313]: Device '0xxxxxxxxxxxxxxxxx' left the network
Feb 03 21:07:47 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:07:47: MQTT publish: topic 'z2m/bridge/event', payload '{"data":{"friendly_name":"0xxxxxxxxxxxxxxxxx","ieee_address":"0xxxxxxxxxxxxxxxxx"},"type":"device_leave"}'
Feb 03 21:07:47 rpi npm[16313]: Zigbee2MQTT:warn  2022-02-03 21:07:47: Device '0xxxxxxxxxxxxxxxxx' left the network
Feb 03 21:07:47 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:07:47: MQTT publish: topic 'z2m/bridge/event', payload '{"data":{"friendly_name":"0xxxxxxxxxxxxxxxxx","ieee_address":"0xxxxxxxxxxxxxxxxx"},"type":"device_leave"}'
Feb 03 21:07:48 rpi npm[16313]: Zigbee2MQTT:warn  2022-02-03 21:07:48: Device '0xxxxxxxxxxxxxxxxx' left the network
Feb 03 21:07:48 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:07:48: MQTT publish: topic 'z2m/bridge/event', payload '{"data":{"friendly_name":"0xxxxxxxxxxxxxxxxx","ieee_address":"0xxxxxxxxxxxxxxxxx"},"type":"device_leave"}'
Feb 03 21:08:11 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:08:11: Device '0xxxxxxxxxxxxxxxxx' joined
Feb 03 21:08:11 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:08:11: MQTT publish: topic 'z2m/bridge/event', payload '{"data":{"friendly_name":"0xxxxxxxxxxxxxxxxx","ieee_address":"0xxxxxxxxxxxxxxxxx"},"type":"device_joined"}'
Feb 03 21:08:11 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:08:11: Configuring '0xxxxxxxxxxxxxxxxx'
Feb 03 21:08:11 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:08:11: Starting interview of '0xxxxxxxxxxxxxxxxx'
Feb 03 21:08:11 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:08:11: MQTT publish: topic 'z2m/bridge/event', payload '{"data":{"friendly_name":"0xxxxxxxxxxxxxxxxx","ieee_address":"0xxxxxxxxxxxxxxxxx","status":"started"},"type":"device_interview"}'
Feb 03 21:08:11 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:08:11: MQTT publish: topic 'z2m/bridge/event', payload '{"data":{"friendly_name":"0xxxxxxxxxxxxxxxxx","ieee_address":"0xxxxxxxxxxxxxxxxx"},"type":"device_announce"}'
Feb 03 21:08:12 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:08:12: Successfully interviewed '0xxxxxxxxxxxxxxxxx', device has successfully been paired
Feb 03 21:08:12 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:08:12: Device '0xxxxxxxxxxxxxxxxx' is supported, identified as: Gledopto Zigbee LED Controller W (pro) (GL-C-009P)
Feb 03 21:08:12 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:08:12: MQTT publish: topic 'z2m/bridge/event', payload '{"data":{"definition":{"description":"Zigbee LED Controller W (pro)", ........ }'
Feb 03 21:08:13 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:08:13: MQTT publish: topic 'z2m/0xxxxxxxxxxxxxxxxx', payload '{"linkquality":145,"state":"ON"}'
Feb 03 21:08:13 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:08:13: MQTT publish: topic 'z2m/0xxxxxxxxxxxxxxxxx', payload '{"brightness":254,"linkquality":149}'
Feb 03 21:08:14 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:08:14: MQTT publish: topic 'z2m/0xxxxxxxxxxxxxxxxx', payload '{"linkquality":153,"update":{"state":"idle"}}'
Feb 03 21:08:20 rpi npm[16313]: Zigbee2MQTT:info  2022-02-03 21:08:20: Successfully configured '0xxxxxxxxxxxxxxxxx'
uncle-fed commented 2 years ago

@MartB

It initially pairs once and after a power loss loses the connectivity and can never be re-paired again. Is this the same for the 001P?

I cannot confirm this. After power loss, the device continues to function as if it never left the network in my case. How long is the power loss in your case?

MartB commented 2 years ago

@MartB

It initially pairs once and after a power loss loses the connectivity and can never be re-paired again. Is this the same for the 001P?

I cannot confirm this. After power loss, the device continues to function as if it never left the network in my case. How long is the power loss in your case?

Check https://github.com/Koenkk/zigbee2mqtt/issues/11202 it seems like the "mini" version is different to the regular 5in1. The older pro controller works and i assume the regular 5in1 would work for me too.

Thanks for testing this though and sorry for the offtopic!

Koenkk commented 2 years ago

There are the following messages now in the log file during z2m startup:

Fixed

is this normal / expected that "device_leave" related messages repeat 3 times?

This device send this 3 times apparently, so no good or bad here

Regarding the other points; I've added some changes which should make it possible to immediately show the new model after changing it. Could you check if it works?

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)

basmeyer commented 2 years ago

Wow, thanks for looking into this on such short notice, @Koenkk. I will give Z2M another go then with the GL-C-002P 5 in 1 mini LED controllers. I have 5 of these now and really want to use them into HA.

In a ZHA integration (Sonoff ZBDongle) I could manage to pair 2 in a row successfully in RGBCCT/GL-C-008P mode. The only thing what I encountered out of the ordinary was that I had to enable the "unavailable" main entity and give it a few minutes to settle down. These keep being found and are 100% fully functional and stay that way, even if you power cycle them, or restart HA.

After I tried pairing device no.3 in Dimmer/GL-C-009P mode (device reset, then set to red status LED Dimmer mode) things got hairy. The device seems to get paired is not really working/controllable after. Also, even saying in green "The device is ready to use" during the paring process, there are 4 yellow triangles with exclamation marks. That started off with one triangle at the first time it went wrong, by the way. It is like @MartB said in his contribution, once out, never paired back in again. Only with me I was still able to pair 2 devices, and the 3 brand new and truly just coming out of the box devices were 'rejected'...

Tried all sorts of things just to rule out bad wireless connections but the coordinator and had device just put next to or near each other but that made no difference.

In Zigbee2MQTT the GL-C-002P mini is displayed as the bigger black GL-C-008P device. It stays paired for like 10-15 seconds, then Z2M comes with a red warning message including log entry that the device has left the network and is kicked off the list of paired devices. If reset and put in Dimmer/GL-C-009P mode, then paired (always has to be like this I guess) the device is paired as RGBCCT/GL-C-008P anyway, so with all controls, which is not good. One would expect just brightness and on/off. If pairing is staying on 'Permit join (all)' the device is coming in and out, is cycling leaving and pairing. Cannot tell if switching mode after pairing works, it just stays paired too short for that.

I also had this once in the log but I am not able to reproduce:

2022-02-05 02:17:40 WARNING (MainThread) [homeassistant.components.mqtt.light.schema_json] Invalid color mode received
2022-02-05 02:17:40 WARNING (MainThread) [homeassistant.components.mqtt.light.schema_json] Invalid color mode received
2022-02-05 02:17:49 WARNING (MainThread) [homeassistant.components.mqtt.light.schema_json] Invalid color mode received
2022-02-05 02:17:49 WARNING (MainThread) [homeassistant.components.mqtt.light.schema_json] Invalid color mode received
2022-02-05 02:17:49 WARNING (MainThread) [homeassistant.components.mqtt.light.schema_json] Invalid color mode received
2022-02-05 02:17:49 WARNING (MainThread) [homeassistant.components.mqtt.light.schema_json] Invalid color mode received

The Z2M log only consist of the warnings that the device is leaving every 10-15 seconds. I have to rule out tomorrow if all 3 of the 5 are broken. Hope this is still a bit on-topic. If not, just let me know. Thanks!

MartB commented 2 years ago

@basmeyer Thanks for confirming my hunch! Let's move to here with the mini5in1: https://github.com/Koenkk/zigbee2mqtt/issues/11202

This issue is primarily aimed at the 5in1 modelid switching part but the mini pairing being completely broken seems to be more "low level" than this. Maybe you can also help with sniffing this!

basmeyer commented 2 years ago

OK

uncle-fed commented 2 years ago

Regarding the other points; I've added some changes which should make it possible to immediately show the new model after changing it.

@Koenkk I've tested the changes and it looks like it is almost perfect now.

On the last point: can the configure step output the log message with correct model ID that would "override" previous identified as: Gledopto Zigbee LED Controller XXX? This message could state that "device mode was detected / changed" and then list the actual model and it's capabilities, similarly to how it's done during pairing. I think, if such message is added, then the support is pretty much done, and much better than we hoped after the initial discussion. Fantastic job!

Koenkk commented 2 years ago

the only time when you do want a z2m restart is to see that the currently selected model is being detected correctly in the z2m logs

I'm not sure what you mean with this? Can you provide this log?

uncle-fed commented 2 years ago

What I tried to say is that everything works fine now without the need to restart z2m at all. Your last changes to the code allow the user to switch device mode with a button press after which it enters pairing and then z2m does device configuration step during which it adjusts everything correctly (it starts treating the device with the currently selected model ID and everything is correct in the Web UI). The only thing which is NOT 100% describing the actual state of things is the main log file.

If you don't look in the WebUI and only go by the log file, then this is what happens there (I will use "MODE A", "MODE B", etc. to simplify description of the model / mode of operation:

# press the button on the device and it starts going from its current mode A to go mode B

> Device 'xx' left the network
> MQTT publish: topic 'z2m/bridge/event', payload '{"data": "friendly_name":"xx.","ieee_address":"xx."},"type":"device_leave"}'
> Device 'xx' joined
> MQTT publish: topic 'z2m/bridge/event', payload '{"data":{"friendly_name":"xx","ieee_address":"xx"},"type":"device_joined"}'
> Configuring 'xx'
> Starting interview of 'xx'
> MQTT publish: topic 'z2m/bridge/event', payload '{"data":{"friendly_name":"xx","ieee_address":"xx","status":"started"},"type":"device_interview"}'
> MQTT publish: topic 'z2m/bridge/event', payload '{"data":{"friendly_name":"xx","ieee_address":"xx"},"type":"device_announce"}'
> Successfully interviewed 'xx', device has successfully been paired
> Device 'xx' is supported, identified as: Gledopto Zigbee LED Controller W (pro) (MODE A)
> MQTT publish: topic 'z2m/bridge/event', payload '{"data":{"definition":{"description":"Zigbee LED Controller W (pro)", ........ }'

# Note that the device has already switched to MODE B but the message above says it was detected as MODE A
# Also, at this stage the Web UI shows MODE A information and MODE A controls 

> MQTT publish: topic 'z2m/xx', payload '{"linkquality":145,"state":"ON"}'
> MQTT publish: topic 'z2m/xx', payload '{"brightness":254,"linkquality":149}'
> MQTT publish: topic 'z2m/xx', payload '{"linkquality":153,"update":{"state":"idle"}}'
> Successfully configured 'xx'

# Now the successful 'configuration' routine has been done, the information and controls in the web UI change
# It now shows correct controls and About info for the MODE B
# You can simply start using the device correctly now as is, but in the log file there is absolutely no clue
# about the fact that the device has been reconfigured from MODE A to MODE B

# Without any Z2M restart, try switching the mode on the device again, from MODE B to MODE C now.

> Device 'xx' left the network
> MQTT publish: topic 'z2m/bridge/event', payload '{"data": "friendly_name":"xx.","ieee_address":"xx."},"type":"device_leave"}'
> Device 'xx' joined
> MQTT publish: topic 'z2m/bridge/event', payload '{"data":{"friendly_name":"xx","ieee_address":"xx"},"type":"device_joined"}'
> Configuring 'xx'
> Starting interview of 'xx'
> MQTT publish: topic 'z2m/bridge/event', payload '{"data":{"friendly_name":"xx","ieee_address":"xx","status":"started"},"type":"device_interview"}'
> MQTT publish: topic 'z2m/bridge/event', payload '{"data":{"friendly_name":"xx","ieee_address":"xx"},"type":"device_announce"}'
> Successfully interviewed 'xx', device has successfully been paired
> Device 'xx' is supported, identified as: Gledopto Zigbee LED Controller W (pro) (MODE B)
> MQTT publish: topic 'z2m/bridge/event', payload '{"data":{"definition":{"description":"Zigbee LED Controller W (pro)", ........ }'
> Successfully configured 'xx'

# You see that device is now in mode C, the web UI acts and shows mode C,  but the latest log message says "MODE B".

I hope the above makes it clear that if you don't restart z2m (and it is not really needed anymore), the log file never shows correct model ID anywhere, even if the "configure" step changes everything correctly internally.

Thus, there was my idea that after the message Successfully configured ... you should be seeing something more in the log file to give you a clue that device has just jumped to the "next" mode of operation (compared to what it was detected as) according to z2m internal actions that just taken place. Because, as you can see from the logs above, the device always gets detected in "previous" mode after re-pairing (and I guess you can't change that logic).

If you restart z2m, of course then the device will be listed correctly (at the end of the example above, in MODE C) in the logs, but there is no real need to restart z2m anymore.

Koenkk commented 2 years ago

@uncle-fed I see, added this now. Please test and I think this issue can be closed once confirmed.

uncle-fed commented 2 years ago

@Koenkk I've tested the changes and now the message comes up Detected Gledopto device mode change, from 'GL-C-...P' to 'GL-C-...P'. Very nice! Not sure if the current documentation describes this device behaviour with all the changes that were done, but if so, then I think this can be closed now. Thank you very much!

Koenkk commented 2 years ago

@uncle-fed adding some documentation makes sense indeed. It would be great if you make a pr to https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/GL-C-008P.md (and the other P devices) to add a GL-C-001P section below notes describing how to switch modes and what to expect in the z2m logs.

uncle-fed commented 2 years ago

@Koenkk I can create a PR no problem, I just want to make sure that I understand it right. Do you want to place information at the bottom of each of the 5 emulated GL-C-..P devices about GL-C-001P, instead of creating a separate page for it?

Koenkk commented 2 years ago

@uncle-fed the z2m docs are generated from the zigbee-herdsman-converters definition. And since we cannot add a separate definition for this device no page will be generated for it. What we can do is mark it as a white label of e.g. the GL-C-008P such that it will appear in the supported devices overview. What model does this device initially use? (without switching modes)

uncle-fed commented 2 years ago

@Koenkk I suppose, we can deem GL-C-008P to be the "default" mode, since it is listed first on the device body and in the manual. It is also one of the 5 modes that the device chooses if you perform full reset. I am wondering, though, if we should mention anything on the other devices pages. I guess not really, right? Since people will end up on the GL-C-008P page if they look for this device anyway, won't they? Then they can read the section dedicated to this device on that page, right?

Koenkk commented 2 years ago

@uncle-fed

MartB commented 2 years ago

If we already go through all these steps we could also include the 5in1 mini aka GL-C-002P. We need to mention that it is broken despite being detected as supported at the moment, as it does the same "identifying" model changing magic.

The gledopto mini 5in1 seems to be our only false positive "supported" device right now if im not mistaken

uncle-fed commented 2 years ago

@Koenkk I've left my comment in the PR

some docs to the 8P page and linked to it from the other controllers. Could you review

https://github.com/Koenkk/zigbee2mqtt.io/pull/1224#pullrequestreview-877516836

While browsing the docs earlier, I also discovered two other things, not related at all to the current issue. Sorry about hijacking this issue but I am not sure where to ask about this, so I will use the opportunity here, since we are discussing the docs and it's kind of related to docs.

One thing is Web UI / doc page related. When you click on the Manufacturer link in your Web UI / About page, it normally takes you to the https://www.zigbee2mqtt.io/supported-devices/ search page that should list all devices by that manufacturer. If the manufacturer name contains whitespace, the web UI replaces it with underscores. But then, the web site is actually programmed to handle whitespace rather than underscores, so it finds nothing. I am not sure what should be changed in this situation - the Web UI, or the web site itself...

And another thing I (hopefully correctly) opened a new issue. But I am not sure if this is documentation or configuration or really the general code issue for the entire device class (occupancy sensors).

Koenkk commented 2 years ago

One thing is Web UI / doc page related. When you click on the Manufacturer link in your Web UI / About page, it normally takes you to the https://www.zigbee2mqtt.io/supported-devices/ search page that should list all devices by that manufacturer. If the manufacturer name contains whitespace, the web UI replaces it with underscores. But then, the web site is actually programmed to handle whitespace rather than underscores, so it finds nothing. I am not sure what should be changed in this situation - the Web UI, or the web site itself...

@nurikk can you fix this one? Spaces should be replaced by %20 instead of _, e.g. manufacturer Ajax Online should be https://www.zigbee2mqtt.io/supported-devices/#v=Ajax%20Online

And another thing I (hopefully correctly) opened a https://github.com/Koenkk/zigbee2mqtt/issues/11183. But I am not sure if this is documentation or configuration or really the general code issue for the entire device class (occupancy sensors).

Will check

Assuming this can be closed now.

uncle-fed commented 2 years ago

@nurikk I've just realized that this issue got closed, but the "spaces vs underscores" problem from the last comment is still there. Should I open a new issue in the web interface repo for this?

nurikk commented 2 years ago

@nurikk I've just realized that this issue got closed, but the "spaces vs underscores" problem from the last comment is still there. Should I open a new issue in the web interface repo for this?

Hi, yes. Kindly create an issue in frontend issue tracker so I would not miss it next time

M1cN commented 1 year ago

@Koenkk The option to control the Gledopto on option 5 dimmer mode: GL-C-009P is not working as expected. It should have the option to control each of the channels separately. But at this point, it only shows a single control that adjusts all 5 channels simultaneously.

mgabor3141 commented 1 year ago

@Koenkk I'm seeing the same issue. In the "Dimmer" mode the 5 channels are supposed to be reported independently. Can this be implemented somehow?

Exposes page looks like this:

Screenshot 2023-05-26 at 17 34 29
Koenkk commented 1 year ago

Can you provide the data/database.db entry of this device?

mgabor3141 commented 1 year ago

Thanks for the reply. Here's the entry. By the way I had to switch the mode over to Dimmer on the device, then had to remove and re-add the it to get it to show up as GL-C-009P with the controls shown above. Before I did that it kept showing as 008P with an RGB picker.

{
    "id": 7,
    "type": "Router",
    "ieeeAddr": "0xa4c13882f0993705",
    "nwkAddr": 3319,
    "manufId": 4417,
    "manufName": "GLEDOPTO",
    "powerSource": "Mains (single phase)",
    "modelId": "GL-C-009P",
    "epList": [
        11,
        242
    ],
    "endpoints": {
        "11": {
            "profId": 260,
            "epId": 11,
            "devId": 257,
            "inClusterList": [
                0,
                3,
                4,
                5,
                6,
                8,
                768,
                4096
            ],
            "outClusterList": [
                25
            ],
            "clusters": {
                "lightingColorCtrl": {
                    "attributes": {
                        "colorCapabilities": 0,
                        "colorTempPhysicalMin": 158,
                        "colorTempPhysicalMax": 495
                    }
                },
                "genBasic": {
                    "attributes": {
                        "modelId": "GL-C-009P"
                    }
                },
                "genLevelCtrl": {
                    "attributes": {
                        "currentLevel": 199
                    }
                },
                "genOnOff": {
                    "attributes": {
                        "onOff": 1
                    }
                }
            },
            "binds": [],
            "configuredReportings": [],
            "meta": {}
        },
        "242": {
            "profId": 41440,
            "epId": 242,
            "devId": 97,
            "inClusterList": [],
            "outClusterList": [
                33
            ],
            "clusters": {},
            "binds": [],
            "configuredReportings": [],
            "meta": {}
        }
    },
    "appVersion": 1,
    "stackVersion": 2,
    "hwVersion": 2,
    "dateCode": "20230111",
    "swBuildId": "20051203",
    "zclVersion": 3,
    "interviewCompleted": true,
    "meta": {
        "configured": -2112165295
    },
    "lastSeen": 1685198610662,
    "defaultSendRequestWhen": "immediate"
}
Koenkk commented 1 year ago

Can you explain what you mean with 5 channels? This device has just a single endpoint (242 is for Zigbee greenpower). How does this work when using the original hub?

mgabor3141 commented 1 year ago

Accrding to the manual, 5 different strips can be connected to the controller in dimmer mode:

image

I would assume that this means that they can be dimmed individually.

How does this work when using the original hub?

I'm not sure as I haven't tried yet, but I might give it a go. It's just a lot of work to switch back and forth, so I was trying to make Z2M work first if possible. I'll see if I can give it a go, I have a deConz adapter.

M1cN commented 1 year ago

Hi, i also hoped this was the case But after consulting the vendor i learned that all 5 outputs are controlled as a single channel to balance the power over multiple outputs for led strips etc.

Op zo 28 mei 2023 15:19 schreef mgabor @.***>:

Accrding to the manual, 5 different strips can be connected to the controller in dimmer mode:

[image: image] https://user-images.githubusercontent.com/9047995/241562276-e5565831-51e2-47f0-9b90-67e220d42a8d.png

I would assume that this means that they can be dimmed individually.

How does this work when using the original hub?

I'm not sure as I haven't tried yet, but I might give it a go. It's just a lot of work to switch back and forth, so I was trying to make Z2M work first if possible. I'll see if I can give it a go, I have a deConz adapter.

— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee-herdsman-converters/issues/3016#issuecomment-1566138658, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3ULYAWNZWU74P6RIAZ3J3XINGFZANCNFSM5D23U7JA . You are receiving this because you commented.Message ID: @.***>

mgabor3141 commented 1 year ago

That's very disappointing. Thank you @webnar for relaying the info. I propose we add this piece of information to the docs if possible.

This means that my previous request is invalid, thank you @Koenkk for looking into it regardless.