muller licht 404010fr remote

[thertp]

I'm trying to get this remote working. It's the same model as in https://www.amazon.fr/dp/B07FJZKZRB/ref=twister_B0877BBQVK?_encoding=UTF8&psc=1. My device is seen in the logs as:

Status: (zigate) [1] NEW OBJECT: e3bd Model Name: ZBT-Remote-ALL-RGBW
Status: (zigate) [-] NEW OBJECT: e3bd Active Endpoint Response Ep: 01 RSSI: 156
Status: (zigate) [-] NEW OBJECT: e3bd Request Simple Descriptor for Ep: 01
Status: (zigate) [1] NEW OBJECT: e3bd Model Name: ZBT-Remote-ALL-RGBW
Status: (zigate) [-] NEW OBJECT: e3bd Simple Descriptor Response EP: 0x01 RSSI: 156
Status: (zigate) [-]    NEW OBJECT: e3bd ProfileID 0104
Status: (zigate) [-]    NEW OBJECT: e3bd ZDeviceID 0800
Status: (zigate) [-]    NEW OBJECT: e3bd Application Version 0001
Status: (zigate) [-]    NEW OBJECT: e3bd Cluster IN Count: 03
Status: (zigate) [-]       NEW OBJECT: e3bd Cluster In 1: 0000 (Basic)
Status: (zigate) [-]       NEW OBJECT: e3bd Cluster In 2: 0003 (Identify)
Status: (zigate) [-]       NEW OBJECT: e3bd Cluster In 3: 1000 (Touchlink)
Status: (zigate) [-]    NEW OBJECT: e3bd Cluster OUT Count: 08
Status: (zigate) [-]       NEW OBJECT: e3bd Cluster Out 1: 0004 (Groups)
Status: (zigate) [-]       NEW OBJECT: e3bd Cluster Out 2: 0003 (Identify)
Status: (zigate) [-]       NEW OBJECT: e3bd Cluster Out 3: 0006 (On/Off)
Status: (zigate) [-]       NEW OBJECT: e3bd Cluster Out 4: 0008 (Level Control)
Status: (zigate) [-]       NEW OBJECT: e3bd Cluster Out 5: 0300 (Colour Control)
Status: (zigate) [-]       NEW OBJECT: e3bd Cluster Out 6: 1000 (Touchlink)
Status: (zigate) [-]       NEW OBJECT: e3bd Cluster Out 7: 0019 (Over-the-Air Upgrade)
Status: (zigate) [-]       NEW OBJECT: e3bd Cluster Out 8: 0000 (Basic)

I'm running the stable5-fix branch, zigate 1 and firmware 031a.

I found that there's a Conf/Certified/TDURM0D01/ZBT-Remote-ALL-RGBW.json file so I was expecting to get it working, even if not everything is working out of the box. But nothing. Not events generated.

I'm trying to debug this. So far, after code hacks, only the "power","dim+","dim-" buttons are working. I've enabled the debug
log options and they seem to suggest that there's nothing received when other buttons are pressed.

Any way to debug further in order to fix/add the support ? [ If I can avoid updating the zigate firmware atm, it would be nice ]

[pipiche38]

Did you read the Wiki ?
https://github.com/pipiche38/Domoticz-Zigate-Wiki/blob/master/en-eng/Corner_Tint.md

[thertp]

yeah, I've read it but as said in my report, before I start hacking the code, nothing was working because they're not exactly the same remote control devices and now, the scene color buttons are still not working. Moreover, this doc doesn't mention if the limitation is only missing code or if it's a device or zigare or whatever limitation.

I'm ready to dig into the code in order to get a full support of my device but I'm not sure how to proceed [In the end, I really hope to be able to close this bug with a PR].

[pipiche38]

If I understood you are running firmware 31a.

I would be interesting to understand what you mean by hack the code to get power, dim+ and dim- to understand what is the issue.

On the other side, I'm not surprise that the you don't get events, I think that for the tint, a change in the firmware was made to get those type of event going through.
At least 31d must be the minimum, and I think that even some stuff were fixed in 31e. SO I strongly recommend you to test with 320 which is the latest.

[thertp]

ok. So, I'll try to update my firmware and reply only once done then.

As regards the code changes, I've done that : https://gist.github.com/thertp/ad35cf8e0bf4d7f49e519bf09c667fc0
Without this the power on/off and dim+/dim- are not working. I've modified other places in Modules/inRawAps.py to test tint-Remote-white and ZBT-Remote-ALL-RGBW but iirc these changes had no effect.

[pipiche38]

The inRawAPS will work only with the firmware above 31d Envoyé de mon iPhone

…

Le 26 oct. 2021 à 10:47, rtp ***@***.***> a écrit :  ok. So, I'll try to update my firmware and reply only once done then. As regards the code changes, I've done that : https://gist.github.com/thertp/ad35cf8e0bf4d7f49e519bf09c667fc0 Without this the power on/off and dim+/dim- are not working. I've modified other places in Modules/inRawAps.py to test tint-Remote-white and ZBT-Remote-ALL-RGBW but iirc these changes had no effect. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[pipiche38]

happy to merge your PR when ready

[thertp]

I've upgraded over the week end my zigate. Now, I'm getting the commands 0x7 ("move to color") and 0xa ("move to color temperature"). The "scene" buttons and the group button are still generating nothing.
For the "scene" buttons, looks like it's a command called "write" according to Koenkk/zigbee-herdsman-converters#281 but I didn't look at that.

As regards the plugin and domoticz:

• I've tried to compute rgb colors from the "move to color" command with xy_to_rgb function but the results doesn't make a lot of sens. I also don't know how to report the color to domoticz
• For the dim+/dim- buttons, domoticz doesn't seem to allow pressing several times the button. For instance, several press on dim- is generating only 1 even in the device log
• While I would expect the color temperature command to send the new color temperature to domoticz, I can live with using the "scene" for the levels.

I'll send a PR once these problems will be solve, unless they can't be solved...

[pipiche38]

For "scene" and "group" buttons

• did you enable debugInput ? As if it is "For the "scene" buttons, looks like it's a command " we should get a Data Indication under message type 0x8002

if you really get nothing, it would be good to sniff the Zigbee traffic in order to understand what is going on

[thertp]

iirc, there are wireshark captures in the bug report I mentionned. At least, the logs I found on one of the few bug report on some github projects, for the scene buttons, the interesting decoded part is:

ZigBee Cluster Library Frame, Mfr: Mueller-Licht International Inc. (0x121b), Command: Write Attributes, Seq: 37
    Frame Control Field: Profile-wide (0x14)
    Manufacturer Code: Mueller-Licht International Inc. (0x121b)
    Sequence Number: 37
    Command: Write Attributes (0x02)
    Attribute Field, Uint8: 3
        Attribute: 0x4005
        Data Type: 8-Bit Unsigned Integer (0x20)
        Uint8: 3 (0x03)

I've yet to understand the code flow in the plugin and in the zigate firmware to understand where the packet is dropped. What's possible is that the zigate is dropping the write to attribute 0x4005 as I don't remember seeing any data in the 8002 decoding functions for this event.

[pipiche38]

I'm missing some information. Is the write attribute from the Device to the Controller or vice-versa ?

Is the remote which want to write attribute 0x4005 (on which Cluster ????) to the Controller (Zigate)

[thertp]

Yes, it's the remote which want to write to the 0x4005 attribute to cluster 0. The whole decoded frame is:

No.     Time           Source                Destination           Protocol Length Info
     53 16.139166      0x1b0f                Broadcast             ZigBee HA 66     ZCL: Write Attributes, Seq: 37

Frame 53: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface \\.\pipe\zboss_sniffer, id 0
ZBOSS dump, IN, page 0, channel 11
IEEE 802.15.4 Data, Dst: 0x6ed4, Src: 0x1b0f
    Frame Control Field: 0x8861, Frame Type: Data, Acknowledge Request, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
    Sequence Number: 76
    Destination PAN: 0x1a62
    Destination: 0x6ed4
    Source: 0x1b0f
    [Extended Source: Jennic_00:03:8c:30:8e (00:15:8d:00:03:8c:30:8e)]
    [Origin: 6]
    TI CC24xx-format metadata: FCS OK
ZigBee Network Layer Data, Dst: Broadcast, Src: 0x1b0f
    Frame Control Field: 0x2248, Frame Type: Data, Discover Route: Enable, Security, End Device Initiator Data
    Destination: 0xfffd
    Source: 0x1b0f
    Radius: 30
    Sequence Number: 237
    [Extended Source: Jennic_00:03:8c:30:8e (00:15:8d:00:03:8c:30:8e)]
    [Origin: 6]
    ZigBee Security Header
ZigBee Application Support Layer Data, Group: 0x4004, Src Endpt: 1
    Frame Control Field: Data (0x0c)
    Group: 0x4004
    Cluster: Basic (0x0000)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 133
ZigBee Cluster Library Frame, Mfr: Mueller-Licht International Inc. (0x121b), Command: Write Attributes, Seq: 37
    Frame Control Field: Profile-wide (0x14)
    Manufacturer Code: Mueller-Licht International Inc. (0x121b)
    Sequence Number: 37
    Command: Write Attributes (0x02)
    Attribute Field, Uint8: 3
        Attribute: 0x4005
        Data Type: 8-Bit Unsigned Integer (0x20)
        Uint8: 3 (0x03)

(from what I understand, the data is the scene button number)

[pipiche38]

And the Group 0x4004 exists in the plugin ? If you go to Group Management in the Plugin Web Ui , the group exists and ZiGate belongs to it ?

If not, it might explain, and you need to enable the zigatePartOfGroupTint in Plugin settings and restart the plugin to get it created.

1. Make sure to enable

   • debugInput
   • debugrawAPS

2. If it is created, it could be that the firmware is filtering the write command . In that case, can you switch the ZiGate in hybrid mode with the following command

   running the command from the host where domoticz and the plugin run

   wget http://127.0.0.1:9440/rest-zigate/1/zigate-mode/2

   and then check if there is anything else in the log when pressing the scene button

3. To switch ZIGate back to normal mode:
   wget http://127.0.0.1:9440/rest-zigate/1/zigate-mode/0

[thertp]

With the wget commands and some logs added, I get in the logs:

ZigateRead - Addr: 001a, MsgType: 8011, MsgLength: 0008, MsgCRC: 23, Data: 00c1600100001a, LQI: 0
decode8002_and_process Unknown Command: 0b NwkId: c160 Ep: 01 Cluster: 0000 Payload: 0482 - GlobalCommand: True, Sqn: b8, ManufacturerCode: 1b12
Reception Data indication, Source Address : c160 Destination Address : 0000 ProfilID : 0104 ClusterID : 0000 Message Payload : 141b12b80b0482
decode8002_and_process Sqn: 185/b9 ManufCode: 1b12 Command: 02 Data: 05402002
Reception Data indication, Source Address : c160 Destination Address : 4004 ProfilID : 0104 ClusterID : 0000 Message Payload : 141b12b90205402002
inRawAps Nwkid: c160 Ep: 01 Cluster: 0000 ManufCode: 1b12 Cmd: 02 Data: 05402002 Payload: 141b12b90205402002
inRawAps Nwkid: c160 Ep: 01 Cluster: 0000 ManufCode: 1b12 manuf:  manuf_name: MLI Cmd: 02 Data: 05402002 Payload: 141b12b90205402002

So, I guess this means that the firmware is responible for the issue. I've started looking at the code and looks like the firmware is sending a error with the default command (command 0x0b) since it doesn't have 0x4005 as valid attribute (see ModuleRadio/Firmware/src/sdk/JN-SW-4170/Components/ZCL/Clusters/General/Source/Basic.c).

[pipiche38]

Sound good. Give me a night. and I'll make that available

[pipiche38]

Please try to update to beta-5.2.263

You should get the handling of the write attribute (if I didn't do any mistake).

Could you confirm that you have got those messages with Mode 2 ?

[thertp]

Please try to update to beta-5.2.263

You should get the handling of the write attribute (if I didn't do any mistake).

Ok. Will try (but not today)

Could you confirm that you have got those messages with Mode 2 ?

yes. I don't get them otherwise. I did:

• wget http://127.0.0.1:9440/rest-zigate/1/zigate-mode/2
• Press buttons
• wget http://127.0.0.1:9440/rest-zigate/1/zigate-mode/0
• Look at the logs

[pipiche38]

no activity, please re-open if needed