Appreciate your work

[midlan]

Hello @grafalex82 , I really appreciate your work you done here. I'm having very similar story. I built new flat and bought many of QBKG11LM and QBKG12LM. For long time I used them only as "dumb" switches and this year I finally got them connected to home assistant. After half of year using them in smart mode I am very disappointed with the result, I may not fully understand whats wrong with the switches, but my biggest problem is they are randomly turning off, as I described here https://github.com/Koenkk/zigbee2mqtt/issues/18369 I suspect that it is caused by many reconnecting events.

After many hours of trying to solve the issue I came to the same conclusion as you. The problem is most likely in the firmware of the switches itself. I disassembled the switch itself and saw the chip JN5169 inside. Googling if there is some other firmware option out there and bang, I've found your repository.

My goal is pretty same as yours. Since I have many of the switches, I don't want to throw them to trash bin, but rather make them work. If there is something I could help you with, please let me know. Do you need some money to further development? I see you work over year on this, I know that's hard to keep focus and motivation on such long project, but looking in your plan, you came really long way. Seems that you already have the schematics (article pending). Maybe I can check it and compare it to QBKG11LM. As I understand you only have QBKG12LM at your home?

[grafalex82]

Hi Milan,

Thank you for your interest to this project. I really appreciate your feedback,

Looks like your issue is little bit different than mine. Several of my switches just stopped communicating on the network, and did not forward messages from battery powered devices around. I was monitoring them for some time and identified 2 switches that were failing most often. I upgraded 2 switches to a newer Xiaomi Aqara D1 devices, and my issues have gone. Other 15 QBKG12LMs I have started working normally.

Also try upgrading stick version, and switches firmware - perhaps this helped me as well. Mine switches were working fine for about 2 years after firmware upgrade.

Your issue may also be cased by a power outage, or a similar power issue.

My QBKG12LM switches' main board is marked as LM15-LNS-PA-A-T0. I also have one QBKG11LM laying around with the identical board, but only 1 button soldered instead of 2. Here is the schematic of this board https://easyeda.com/editor#id=b0391376089940cbac394a6dbc02721e (only CPU board). Please check if you have the same (otherwise using my firmware may not be possible, or will require additional porting).

As for the project support. The main limiting factor is time at the moment, but I am trying to focus on this project when possible. Also preparing articles take some extra time, working on the code alone would be way faster. Fortunately next 2 or 3 articles are almost ready. Overall, I am pretty close to get to the real Xiaomi hardware, just need to do some more preparations.

If you are willing to support me on this project you can donate at https://www.buymeacoffee.com/grafalex

[midlan]

Yes I am running the latest firmware on coordinator and the switches as well. Problem still persist. The last thing I will try is other coordinator stick. Power outage is not my problem I would say, it would mean that other lights in my home would blink.

Yep my board is the same, LM15-LNS-PA-A-T0. I cannot open the schematic you have posted, it says "Permission denied".

I've found similar project (other JN chip) but may be helpful for you https://github.com/Schischu/aqara-opple

[grafalex82]

@midlan Thanks for the link to aqara-opple project, I'll check it out.

I fixed permissions for the board schematics. Please try this link https://easyeda.com/editor#project_id=b9d498220a3c4c2780df4b5b8948c4b4

The schematics does not include the power and RF parts, bit it is not relevant for for firmware development. KEY1 and KEY2 are used for 2-button versions, KEY3 is for 1-button version (KEY1 and KEY3 connected in parallel, but soldered only one of them)

[midlan]

thanks, schematics link now works 👍

On my home setup I moved one step futher, two steps back. Cleared zigbee2mqtt completely and started over on zigbee channel 15 (I've been on 11 before) with new pan_id, ext_pan_id and network_key. Now there is no reconnecting devices at all in my network, but new problem appeared, half of my switches couldn't be paired at all 😆 I literally waited for minutes, holding down the switch to keep it in pairing mode and nothing happened. Maybe I need start over again.

Aside that, how it's going with the firmware? I have one secret wish for final firmware: I would really love feature that the switch would send actions "down" and "up" immediately (without delay waiting for second click of doubleclick action). So instead of singlle doubleclick action, there would be four separate actions: down, up, down, up. It would really help to create even more customized automations and reduce the light ON delay. (some new switches have similar feature)

[grafalex82]

@midlan As for inability to pair devices. I also had a similar issue a few times. For some reason a few switches did not forward join request to the coordinator. Also coordinator for some reason did not answer with transport/security keys in some cases. The solution was:

• Cold boot of the coordinator (power off, then power on again. Simple reboot did not work for me). Surprisingly this was the main reason of pair failures for me.
• Power off as many devices as possible (physically switch off power for them). Ideally leave only the coordinator and paired switch, and power off all other devices.
• If some devices cannot be powered off individually - try cold boot for them.
• For the most problematic devices I moved coordinator close to the device when pairing (though not sure this is valid advise)

As for immediate actions. There are some modes already that provide fastest feedback:

• In the momentary switch mode actions are generated immediately upon press or release
• In the 'multifunction' switch mode you can assign actions on first press using front relay option - this activates the light immediately when button is pressed for the first time
• or you can assign actions to single/double/triple/long press if needed, so you do not have count presses on the receiver side.

The problem with delays during double click is conceptual, rather technical. Imagine you pressed the button twice quickly. Is this double click already? Or there will be a third click soon? In my switch there is a setting maxPause (typically set to 250 ms) that defines the timeout when the action is considered as happened, and the doubleClick action is sent to the network. Even if you try to count clicks on the receiver side, you will also hit the same problem.

[midlan]

Thanks for your tips about pairing. I will try them.

About the doubleclick, good to know you already implemented multiple modes! I didn't walk through your codes first, but I see now this section which is probably what you mean: https://github.com/grafalex82/hellozigbee/blob/479a0ac6839e68ffc4f27e96145fbe7104228e6e/src/ButtonHandler.cpp#L280

I know that the doubleclick problem is not technical, I am programmer and I know there must be wait delay to wait for the second click. Just wanted to note that up and down actions are 1:1 to what you physically did to the button, without any aggregation. With this 1:1 mapping you can code every possible scenario in your automation software, e.g. homeassistant. Introducing any aggregation between physical world and what is send to zigbee network, you are limiting the possibilities. Not saying you are doing it wrong now, just wanted to share my point of view to make it even better.

Example automation using up and down:

1. on down, light up the light to minimal brightness
2. increase brightness by 10% every 500ms (loop)
3. stop the loop increasing brightness once up is registred

[midlan]

thanks for the pairing tips @grafalex82 ! I was able to pair rest of devices in my home following your advices.

[grafalex82]

@midlan

I didn't walk through your codes first, but I see now this section which is probably what you mean

Yes, there is where all these modes are processed. However you do not have to study the code - I described all the modes in the Readme.

Just wanted to note that up and down actions are 1:1 to what you physically did to the button, without any aggregation

Sure. The momentary mode is for your convinience.

Example automation using up and down

FYI, the switch has Long Press Mode setting which can be tuned to emit LevelCtrl Up and Down commands directly. These commands can be bound to a dimmable light, so that it starts increasing/decreasing the brightness with some rate until the button is released. When the button is released it will send the LevelCtrl Stop command. Do not be confused with the setting name - it should work in the momentary mode same way (I'll rename it one day)