Adapt LLKZMK11LM to new firmware and refactor

[McGiverGim]

This fixes Koenkk/zigbee2mqtt#7112 but I have some doubts and problems before merging it or before working more on it:

• The new "message" with the new firmware, is from a different cluster, so I added a new converter for it xiaomi_basic_raw.
• The converter needs a code very similar to the one of aqara_opple.
• The code of this converters is big, so I decided to refactor it moving to a "utility" library. I've seen there is one for Tuya so I added one for Xiaomi in the lib/xiaomi.js folder. I don't know if this is acceptable or not.
• This library has two methods: one to process the "raw buffer" into a more common object with attribute-value elements, and other to process this attribute numeric objects into a payload. I'm sure the refactor can be done deeply but it's a first step and I don't want this PR to be too big.

Here is my problem: I've tested the code with external_converters, and then moved into the code structure, but I'm not able to test it. I can open a bash into the docker, and replace files there, but it does not seem to work. What is the correct way to test this?
I think I've found a way to test it, I will report soon...

[McGiverGim]

Tested and it seems to work! I have tested succesfully with a LLKZMK11LM and a SSM-U01. Both devices use this code, and all seems to work.
There are lots of others devices that use the aqara_opple, but I think I have none of them to test it.
We are at the beginning of the month, so if we merge it soon we have a lot of time to test in the edge version until the next stable version.

[Koenkk]

@z-x-f can you test this in the latest z2m dev?

[leroyloren]

It works! @McGiverGim thank you. 👍

[z-x-f]

can you test this in the latest z2m dev?

Ok, i will test tonight.

[z-x-f]

debug 2022-03-07 19:45:41: Received Zigbee message from 'zncz15lm', type 'attributeReport', cluster 'aqaraOpple', data '{"247":{"data":[100,16,1,3,40,34,152,57,0,0,0,0,149,57,0,0,0,0,150,57,0,128,14,69,151,57,0,0,0,0,5,33,1,0,154,32,0,8,33,32,1,9,33,0,1,11,32,0,155,16,0,10,33,0,0,12,32,1],"type":"Buffer"}}' from endpoint 1 with groupID 0
debug 2022-03-07 19:45:41: lumi.plug.macn01: Processed buffer into data {"3":34,"5":1,"8":288,"9":256,"10":0,"11":0,"12":1,"100":1,"149":0,"150":2280,"151":0,"152":0,"154":0,"155":0}
debug 2022-03-07 19:45:41: lumi.plug.macn01: unknown key 8 with value 288
debug 2022-03-07 19:45:41: lumi.plug.macn01: unknown key 9 with value 256
debug 2022-03-07 19:45:41: lumi.plug.macn01: unknown key 11 with value 0
debug 2022-03-07 19:45:41: lumi.plug.macn01: unknown key 12 with value 1
debug 2022-03-07 19:45:41: lumi.plug.macn01: unknown key 154 with value 0
debug 2022-03-07 19:45:41: lumi.plug.macn01: unknown key 155 with value 0
debug 2022-03-07 19:45:41: lumi.plug.macn01: Processed data into payload {"temperature":34,"state":"ON","energy":0,"consumption":0,"voltage":228,"current":0,"power":0}
debug 2022-03-07 19:45:41: lumi.plug.macn01: Processed data into payload {"temperature":34,"state":"ON","energy":0,"consumption":0,"voltage":228,"current":0,"power":0}
info  2022-03-07 19:45:41: MQTT publish: topic 'zigbee2mqtt/zncz15lm', payload '{"button_lock":"ON","consumer_connected":false,"consumption":0,"current":0,"energy":0,"led_disabled_night":true,"linkquality":48,"overload_protection":2500,"power":0,"power_outage_memory":true,"state":"ON","temperature":34,"voltage":228}'

@Koenkk It looks like everything is working fine.

[sensei73]

Hello! Thanks to all for your hard work! It seems that the energy sensor (kWh) stale after a few days... If I unplug it and wait (1 min), it restart counting. Any idea?

[McGiverGim]

@sensei73 I think you have the same problem than me: I have three devices of this kind:

• Two of them work perfectly
• The third has the same problem than you
• After some time, this third device did not count more the energy, voltage or power. It worked to power on/off but it did not count. At this moment, a reboot or repair did not help neither.
• I replaced it
• After some days, the problem start happening again.

So I suspect this device is very sensitive to something, and ends breaking the sensors of the board. But I'm not sure. I don't know exactly why, because my other two devices are working since two years ago without problem.