search

Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
12.08k stars 1.68k forks source link

Aqara wall switch H1 (WS-EUK04) - not syncing state, not showing power measurement anymore #21679

Closed adynis closed 7 months ago

adynis commented 8 months ago

What happened?

My kids played with one wall switches - it was showing "red" leds ... 😡 it was removed from Z2M. (probably they pressed more than 6 seconds) Device: WS-EUK04 (lumi.switch.n2aeu1) I added it back to Z2M (1000 times) and I can not make it work properly:

  1. When I press the physical switch button, I don't get the updated state value in Z2M, it appears only if I manually press "refresh" icon to get the value, but not automatically.
  2. for some info fields, e.g.: power, energy, device_temperature I have N/A . If I press the "refresh icon" I get the error:
Zigbee2MQTT:debug 2024-03-05 02:08:30: Publishing get 'get' 'power' to 'copii_aqara'
Zigbee2MQTT:error 2024-03-05 02:08:30: Publish 'get' 'power' to 'copii_aqara' failed: 'TypeError: Cannot read properties of undefined (reading 'read')'
Zigbee2MQTT:debug 2024-03-05 02:08:30: TypeError: Cannot read properties of undefined (reading 'read')

Workaround for issue 1. : I found somewhere on internet this screenshot with the suggestion to add "Reporting" : WhatsApp Image 2024-01-28 at 05 53 20_57bb6ed0 I don't know if this is something ok to do, it looks like it has some slower reaction times then before, I'm not sure if this way I make any process to consume "energy" just to check from second to second the status of the switch ... somehow I feel that it's not ok to have this workaround ...

Some remarks:

Final thought: I'm not sure if it is from aqara device itself (since I was having this kind of issues also in the past), or from Z2M , or from new ember, or from something else ... but it would be helpful to have a solution when it happens. Also ... like I already wrote, the workaround I used doesn't "smell nice" to me now (unless someone confirms to me that it's ok :) )

Zigbee2MQTT version

1.36.0, ember

Adapter firmware version

7.4.1 [GA]

Adapter

Home Assistant Yellow - EZSP v13

Setup

HomeAssistant on HomeAssistantYellow

mojiro commented 8 months ago

Hello @adynis, I have a similar issue.

Is it possible to remember what versions your setup had when you paired them?

At which month/date maybe? - That could tell us which versions you might had..

adynis commented 8 months ago

oh ... @mojiro , sorry .. I missed your message. I observed it now by accident. I will answer to you immediately after my intended message. So .... today .. very strange experiences:

1.) Something ... less important but I can't avoid mentioning it ... Something very strange which I CAN NOT REPLICATE anymore :( My kid pressed 6 times quickly on the switch and ... "magic" ... for ~3 minutes the relay started to go ON/OFF/ON/OFF/ON/OFF at around 2 changes per second ... Unfortunately I didn't have the idea to start loging it :( My wife made a short video with the switch ... When I got home I also tried, it did the same (after 6 clicks it started to on/off/on/off....) and I just checked that when I restarted the Z2M addon from my HA instance, the on/off/on/off stopped. After that I just forced a re-join of the switch and .... from that moment I couldn't replicate the issue anymore ....

2.) This I consider it IMPORTANT: After the problem from point 1 , the state of the switch was not synced anymore 😠 😢 ... also power was NULL.... I tried agan to rejoin , restart HA, remove, force remove, add to aqara hub, remove, re-add, re-join, etc etc .... nothing. Then ... I changed back to ezsp !!! Then I tried to rejoin the device for ~10 minutes (it took me so long because of z2m crashing #21118 , but finally I succeded it) and ... surprize: state is syncing, power measurement is working !!! And I moved back from ezsp to ember, and the switch is still working fine . So ... my conclusion : there's a problem with ember & aqara switch for state syncing & power measurements !

wastez commented 8 months ago

@Nerivec Could that be the same reason like on the ikea motion sensor which we found today? Maybe aqara do such a same dumb thing on this device?

adynis commented 8 months ago

Hello @adynis, I have a similar issue.

Is it possible to remember what versions your setup had when you paired them?

At which month/date maybe? - That could tell us which versions you might had..

Sorry for not answering, I missed the mail when you initially wrote. I do not remember Z2M version, but ... : majority of switches ware installed in ~October.2023 Just that some of them (especially the one from my office-room) I tested a lot and it was removed/re-added multiple times.

In the same time, like in the poiint 2.) written above, with some effort I was usually succeeding to join it with power & state-sync working. I couldn't yet understand which was the trick to make it work ... I was trying various things until it was working ... . Things I was trying , independently or combined :

The problem was that all these tests were DIFFICULT because of the Z2M restart issue ( https://github.com/Koenkk/zigbee2mqtt/issues/21118 ) . But somehow in ... ~5-30 minutes of testing I was usually able to make it work ... despite the z2m restarts in the middle of "device configuration" or despite all the "non-understandings" which I have with regards to all previous points while testing

wastez commented 8 months ago

@adynis Can you post logs with herdsman debug logging on? https://www.zigbee2mqtt.io/guide/usage/debug.html

adynis commented 8 months ago

Yes, but what do you think it would worth "adding" in the log:

Nerivec commented 8 months ago

@adynis wastez may be right. Hopefully, the pending ember PR should also take care of this issue. All newly reported issues (since ember release) are being fixed in dev branch at the moment, to allow some testing before release (every 1st of the month). If you can, try with dev/edge version after that PR is merged and available, and let me know if you still encounter the issue.

As for the magic on/off, it will be hard to say without debug logs. It almost sounds like the device got into a "special state" by triggering it in a very specific way (kind of like some devices that need to be plugged/unplugged 5 times at regular interval to reset them...).

adynis commented 8 months ago

@Nerivec : I would be glad to test ! Jsut that .. being in home assistant (on a "productive environment" ) I ask first: can I just change to Z2M-edge addon in HA and all devices will still be there ?

wastez commented 8 months ago

@adynis I wanted to have a look if the problem is the same thing like on ikea motion sensor because it’s very probably. But I didn’t know that @Nerivec is sooooooo fast. So the best thing is you try the edge release as soon the PR is pushed to it. I‘m pretty sure it will solve it.

wastez commented 8 months ago

@adynis Yes everything is there, the same db is used. You can swap between them without problems.

adynis commented 8 months ago

In the meantime here's one log:

log ember 5:
 - 01:51 EET - hobby_aqara (was working fine) -> pressed 6 seconds on the physical switch to force it re-join
    -> PermitJoin was previously enabled; Device was succesfuylly added back with the same name
    -> state not syncing anymore
    -> power measurements not working anymore (but still shows 0 in browser, not NULL, maybe because of a browser caching ? )
 - 01:54 EET - Press "remove device button in Z2M (Permit Join still on)
    -> Device removed and added back succesfully (added with the default name 0x54ef441000720a04 )
    -> onOff not synced, Power , Energy, DeviceTemperature show NULL now. 
    -> If I press the "refresh" icon in Z2M for onoff state then it works. If I press for Power/Energy/DeviceTemperature then it gives error.

log_ember_5.txt

PS.

Nerivec commented 8 months ago

Flash https://github.com/darkxst/silabs-firmware-builder/blob/ember-nohw/firmware_builds/yellow/ncp-uart-hw-v7.4.1.0-yellow-115200.gbl again, just to be sure, then definitely set rtscts: false in config. I'm seeing strange behavior in your logs, that's likely the cause. Then try getting logs again please.

adynis commented 8 months ago

EZSP logs, 2 files combined, since it was a Z2M restart in the middle:

log_ezsp_1_and_2:
 - 2:14 EET - removed device from Z2M interface
  - various things: Z2M crashed once, I pressed again on the physical switch for 6 seconds , then it didn't finish the interview, then I pressed again 6 seconds, then it worked ... 
 - ~2:19 EET - succcesfully added, and things are sincing correctly

log_ezsp_1_and_2.txt

adynis commented 8 months ago

Oh, I've seen you message now, @Nerivec . Oky , I reflash, set rtscts to false and re do the log 👍

adynis commented 8 months ago

Firmware log:

universal-silabs-flasher --device /dev/ttyAMA1 flash --allow-cross-flashing --firmware ncp-uart-hw-v7.4.1.0-yellow-115200.gbl --force 2>&1 | tee log_fw_no_hw3.log
2024-03-08 02:29:28.324 a0d7b954-ssh universal_silabs_flasher.flash INFO Extracted GBL metadata: NabuCasaMetadata(metadata_version=1, sdk_version='4.4.1', ezsp_version='7.4.1.0', ot_rcp_version=None, cpc_version=None, fw_type=<FirmwareImageType.NCP_UART_HW: 'ncp-uart-hw'>, baudrate=115200)
2024-03-08 02:29:28.325 a0d7b954-ssh universal_silabs_flasher.flasher INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
2024-03-08 02:29:30.329 a0d7b954-ssh universal_silabs_flasher.flasher INFO Probing ApplicationType.EZSP at 115200 baud
2024-03-08 02:29:31.570 a0d7b954-ssh universal_silabs_flasher.flasher INFO Detected ApplicationType.EZSP, version '7.4.1.0 build 0' (7.4.1.0.0) at 115200 baudrate (bootloader baudrate None)
2024-03-08 02:29:37.789 a0d7b954-ssh universal_silabs_flasher.flasher INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
2024-03-08 02:29:38.806 a0d7b954-ssh universal_silabs_flasher.flasher INFO Detected bootloader version '2.0.1'
2024-03-08 02:29:38.807 a0d7b954-ssh universal_silabs_flasher.flasher INFO Detected ApplicationType.GECKO_BOOTLOADER, version '2.0.1' at 115200 baudrate (bootloader baudrate 115200)
ncp-uart-hw-v7.4.1.0-yellow-115200.gbl

Does this mean that ... it worked ... or not ... ❓

adynis commented 8 months ago

a new log:

log_ember_6:

 - 2:38 EET 
    - Permit Join
    - 0x54ef441000720a04 device (which was working ok, state synced, power measurements working), press 6 seconds on phisical button
    - device removed and successfully re-added
    - onOff not synced , power measurements not working
 - 2:40 EET
    - press also "remove device" from Z2M interface
    - device successfully removed and re-added
    - onOff not synced , power measurements not working

log_ember_6.txt

Let me know what other logs are helpful to make (ezsp? something else?)

Nerivec commented 8 months ago

This device is terrible, awful. I'd take a hammer to it if it was mine... 😞 It's spamming the network with duplicate messages for no reason whatsoever; it's like it's trying really hard to crash the network or something...

With ezsp, I'd bet the setManufacturerCode workaround is the reason behind the crashes; it's triggering this dozens of times. I'm sure the coordinator doesn't like that... @kirovilya Seems there is a need to throttle the triggering of setManufacturerCode somehow when a xiaomi/lumi device joins the network? I'm guessing that's the cause of the crashes...

ember manages to survive, but I'm not surprised things aren't working well after that. I'll have to dig deeper...

adynis commented 8 months ago

Thanks @Nerivec for looking into it ! If you need any kind of test/log and you estimate I can do it, please let me know, I'm willing to help :)

kirovilya commented 8 months ago

@Nerivec Sorry, I don't understand what's wrong? in the ezsp adapter setManufacturerCodeis set separately to 0x115F for Lumi/Xiaomi/Aqara devices when they connect to the network

Nerivec commented 7 months ago

@kirovilya Check the logs here. You will see the setManufacturerCode is triggered in rapid succession from the join handler. For 3 joins, I count 25 setManufacturerCode triggered...

kirovilya commented 7 months ago

@Nerivec hmmm... So many trustCenterJoinHandler events - so many setManufacturerCode... I saw this - the device repeatedly tried to connect to the network, but the coordinator did not provide a key to connect (I looked at this with a sniffer). As a result, the device went offline. And then again... but I still didn’t understand the reasons. If you install a new network, it connects normally.

This also happened when connecting via routers - it was solved like this https://github.com/Koenkk/zigbee-herdsman/pull/938

Nerivec commented 7 months ago

@kirovilya The log in the post I linked is with ezsp driver with 1.36.0 (herdsman 0.35.1) so the PR you linked is included (0.34.9). It must be something else; but this Aqara device is definitely no good, so it could be a lot of problems... 😓

kirovilya commented 7 months ago

I saw similar behavior not with Aqara devices, but with Tuya. It's as if the coordinator goes into closed mode and stops sending the key. maybe it was a firmware bug

adynis commented 7 months ago

I'm not sure if it is relevant at this moment/commit_version, but I just tried also with edge, and still no change:

Zigbee2MQTT version: 1.36.0-dev commit: 14e0440 Coordinator revision: 7.4.1 [GA] zigbee_herdsman_version: 0.36.2 Home Assistant with Zigbee2mqtt Edge addon, with config:

adapter: ember port: /dev/ttyAMA1 baudrate: 115200 rtscts: false

I tried removing and re-adding my aqara switch, and here's the log: log_ember_edge-14e0440_1.txt

  23:10 EET:
 - permit join
 - add 0x54ef441000720a04 device
 - rename it to: hobby_aqara
 - OnOff state doesn't sync, Power masurements are NULL

log_ember_edge-14e0440_1.txt

PS. before making the log I tried a couple of times more, and still nothing. PS2. I just put the edge, I need also to test, but ... first feeling is that it reacts faster ... I'm not sure if it is "placebo" since I read somewhere about such an optimization, but ... right now this is what I feel :-p I will test more this version.

Nerivec commented 7 months ago

@adynis I was waiting for a few related changes to be released, since you swapped to edge, before coming back to this. Can you update your edge version so you get herdsman 0.38.0, then let the network settle for an hour or so after the update (it changes a few configs, so just to make sure the mesh readjusts as needed). After that, if you can:

adynis commented 7 months ago

Yes. Just to confirm what I will do (please correct me if I got it wrong) :

adynis commented 7 months ago

so ... It's a big log, but I tried to write my steps to allow you "focus" only on what you find useful:

HomeAssistant Yellow , with Zigbee2Mqtt Edge addon.

Zigbee2MQTT version 1.36.0-dev commit: 56feb77 Coordinator revision 7.4.1 [GA] zigbee_herdsman_converters_version 19.1.0 zigbee_herdsman_version 0.38.0

Z2m addon config:

adapter: ember port: /dev/ttyAMA1 baudrate: 115200 rtscts: false

Device Under Test:

"0x54ef441000720a04" with name "hobby_aqara" Before starting the test device was in the network in a "not-working" state with respect to syncing OnOff state from physical buttons and showing measurements.

What I did: After updating Z2m edge to the newest version, I let it 1h (PS. I have also that log if you need), then I restarted Z2M Edge addon and .. started what's written below:

00:55 EET:
 - Permit join on Coordinator ONLY
 - pressed 6 seconds on physical button
 - device removed/readded quickly
 - device still does NOT work (no sync, no measurements)
 - disable join coordinator
00:58 EET:
 - Permit join on non-aqara router
 - device removed but .... not added !?
 - 00:59 pressed one more time 6 seconds (it's still PermitJoin on this 'another router' )
 - nothing .... 
01:01 EET:
 - Trying another non-aqara router
 - nothing ....
01:03 EET:
 - trying another AQARA (lumi) router (another identical device like the one I'm playing with )
 - nothing ....
01:04 EET:
 - PermitJoin again on coordinator
 - device immediately added with the "hobby_aqara" name
 - Disable "PermitJoin"
01:05 EET:
 - Remove device from "remvoe button" in Z2m (without force)
 - device removed (interesting, I was expecting ~20 "device removed" messages)
01:06 EET:
 - PermitJoin on non-aqara router 
 - nothing ....
01:08 EET:
 - PermitJoin ALL
 - Device added with "0x54ef441000720a04" name
 - Device still doesn't work (no sync, no power mewasurements)
 - DisableJoin ALL
01:09 EET:
 - Remove device from Z2M
1:10 EET:
 - PermitJoin on non-aqara router
 - nothing ...
01:11 EET:
 - thinking what else to test ....
01:11 EET:
 - PermitJoin on coordinator again
 - device added immediately as "0x54ef441000720a04"
01:13 EET:
 - I renamed the device back to hobby_aqara
 - Device still not syncing onOff state from physical button (only if I press "refresh" icon) and  not showing measurements

PS. something offtopic:

log_ember_edge_3.txt Something is broken with file uploading on github I think ... I uploaded the log also HERE

Nerivec commented 7 months ago

Thanks! Details much appreciated! Can you re-upload the log file? Seems github lost it, I'm getting a 404. Can you also post a network map while we're at it?

It tells you just how much that device's firmware is broken when it doesn't even want to join with another Aqara router... 😞

adynis commented 7 months ago

Something is very strange with uploading files ... I can not make it work ... I try also in this comment. Regarding the network map ... it's big and hard to see ... let me know what do you exactly need, to zoom there :) image Later Edit: Soemthing is problematic with updating my log file .... so I've uploaded it on my host and the link is in my previous post.

Nerivec commented 7 months ago

Something is very strange with uploading files ... I can not make it work ... I try also in this comment.

Might be some temporary github problem.

let me know what do you exactly need, to zoom there :)

I've found the best way is usually to make an outer circle like you did with green devices (end devices), grouping them near their router, and then a smaller circle inside with blue devices (routers/coordinator). I'm most interested in the links between those Aqara routers (including the coordinator).

adynis commented 7 months ago

Now I'm adding more screenshots (I challange github while attachments do not work properly ... ) PS. I hope you were able to get the log from the "external" link I've added in that previous post https://github.com/Koenkk/zigbee2mqtt/issues/21679#issuecomment-1992734515

After I arranged as you suggested me, I found 3 things as interesting :

2024-03-13_02h55_34 2024-03-13_02h55_55 2024-03-13_02h56_13 2024-03-13_02h56_34 2024-03-13_02h56_57 2024-03-13_02h57_22 2024-03-13_02h57_47 2024-03-13_02h58_09

Nerivec commented 7 months ago

I got the log file yes. Much cleaner with new 0.38.0 version (no more duplicate "device left"), so that's a plus. Unfortunately, it isn't very descriptive in the problems without herdsman debug enabled. I can tell you however, that all the routers you tried to pair the Aqara device to, flat out denied it from joining.

[TRUST CENTER] Device 24426:0x54ef441000720a04 was denied joining via 59335.
[TRUST CENTER] Device 6500:0x54ef441000720a04 was denied joining via 45709.
[TRUST CENTER] Device 55155:0x54ef441000720a04 was denied joining via 59218.

Any chance you could try enabling herdsman debug, then re-do one remove/pairing with Coordinator only, and one remove/pairing with a specific router (one from your previous tests, doesn't matter which)? Then you can disable herdsman debug and restart Z2M.

Coordinator is connected to all routers

That's normal, through the mesh, they all eventually go back to the coordinator.

that green "end device" which I pus in the left side is very "special"

Likely another Aqara firmware "mishap" where the device is reporting as an end device, even though it is a router... 😞

Offtopic: I can also tell you from your network map, that most of your end devices have pretty poor connections (below or near 100 LQI). I'm not sure if that makes sense (I'm guessing not!) based on the areas/distances to routers/coordinator, but on top of possibly creating network issues, that can seriously affect battery life. If you have a strategic place where it could be put (need a socket and an old phone charger or something like that), I'd suggest getting a coordinator that you can flash as dedicated router (example here). The device can be quickly paid off by not spending $$$ on batteries... and should increase reliability by a large margin in the area it covers.

adynis commented 7 months ago

Oh ... I forgot to enable hardsman debug in the edge addon 🤦‍♂️ sorry. Yes, I'll re-do the test tonight (in ~10 hours) , no problem.

Related to LQI ... interesting ... in the Z2M main page, with the list of devices (Except ~4 exceptions) all numbers are much bigger .. All above 100, Majority around 200. I'll check tonight some concrete examples but now it looks like there are different LQI numbers in Z2M devices page vs. LQI numbers from the map 🤔

adynis commented 7 months ago

I re-did the test. The only differences in settings comparing to https://github.com/Koenkk/zigbee2mqtt/issues/21679#issuecomment-1992734515 are:

00:14 EET:
 - Permit Join Coordinator
 - Device removed and readded quickly ("hobby_aqara" )
 - Device not working (no onoff sync, no power measurements)
 - Disable join
00:16 EET:
 - Permit Join - non-aqara router 1
 - (waiting all ~4 minutes just to be sure)
 - Pressing one more time 6 seconds on phisical button 
 - device NOT added !
00:21 EET:
 - Trying another non-aqara router 2
 - nothing ... device not added
00:22 EET:
 - Trying a similar aqara router
 - nothing ... (PS. this router is ... ~1.5m distance away)
00:23 EET:
 - Permit join (ALL)
 - immediately added (in ~1 sec)
 - Disable join
00:25 EET:
 - remove device in Z2M (without force)
 - Permit Join (again) : non-aqara router 1
 - nothing ....
00:28 EET:
 - Permit join (Coordinator)
 - Added instantly as "0x54ef441000720a04"
 - Device not working (no OnOff state sync, no power measurements)
00:31 EET:
 - tested also another remote and I still have that error : 
" No converter available for 'TS0042' with cluster 'genOnOff' and type 'commandTuyaAction' and data '{"value":0}'"
00:32 EET:
 - Rewmove device from Z2m with "force" option
 - Permit Join Coordinator
 - rename back to "hobby_aqara"
 - Device not working (no OnOff state sync, no power measurements)
00:34 EET:
 - I stopped Z2M addon

log_ember_edge_5.txt

Thanks for looking on this and, as before: Just let me know what other tests I could do in order to help debuging (and hopeuflly fixing) this behavior !

adynis commented 7 months ago

Something I just observerd: Shortly: on EZSP mode it did work only 2nd or 3rd time, not necessary from the 1st time, but I got a log with the 2 failed trials and 1 successfull trial of joining the device on ezsp so that OnOff are synced and measurements are shown.

Longer: I had some strange behavior on ember (one door sensor did not update since 1 week. I re-added to network and ... quite immediately 3 OTHER devices left the network :-| :-| :-| (2 switches like the one in this thread and one MiBoxer RGBCCT controller). Since those switches had some automations on phisical-button-pressed, I moved back to ezsp to add them in that way when they work propertly. On both ... I observed something: 1st re-join it still didn't work, but 2nd re-join it worked. So ... I said ... let's do a log with this example, maybe it helps seeing the difference (on ezsp) for when it doesn't work versus when it works. So ... here it is:

~02:30:
 - Permit Join All
 - Press 6 seconds on the switch to re-join
 - immediately removed and re-joined, but still N/A, and still no OnOff sync
~02:31:
 - Press 6 seconds on the switch to re-join
 - immediately removed and re-joined, but still N/A, and still no OnOff sync
~02:32:
 - Press 6 seconds on the switch to re-join
 - immediately removed and re-joined, and it WORKS !! Power, Energy and Device Temperature have values. State is updated in Z2M as I press the buttons on the wall-switch.
 - Disable Permit Join

After that I stoped Z2M, changed back to ember, and the switch still works.

log_ezsp_edge_2.txt

Later Edit

I re-did things ALSO with latest edge version: and I found the SAME BEHAVIOR

Same test as above on EZSP with re-joining aqara device, it worked from the 2nd time: log_ezsp_edge_5.txt Additionally, if you are curious, I re-did also the test from the previous comment https://github.com/Koenkk/zigbee2mqtt/issues/21679#issuecomment-1996012154 but with the "new edge version" and it did the same:

03:03: removed device (but forgot to press permit join);
03:04: permit join - coordinator only; added quickly, still not working;
03:06: permit join on non-aqara-router; nothing;
03:08: permit join on other aqara router; nothing;
03:09: permit join coordinator; added but stil not working;
03:10: permit join coordinator; removed from Z2M button (without force); added but not working;

log_ember_edge_9.txt

Nerivec commented 7 months ago

The ember fix (hopefully) should be included in next herdsman version (the PR is merged but the version not yet). https://github.com/Koenkk/zigbee-herdsman/pull/975

Let me know how it goes after it is available 😉

adynis commented 7 months ago

Initial quick & partial test:

zigbee_herdsman_version 0.39.0

IT WORKS !!!!!!!!!! 🎉 🎉 🎉

I removed my "hobby_aqara" and re-joined it 2 times (like previously in last weeks) and now it immediately worked each time: OnOff is synced, measurements values are shown !! 🥳 I need to test more tomorrow evening (because now I can't stay anymore too much) but at least on the first quick, short test it worked. Thank you, @Nerivec . I will come back after a longer testing.

adynis commented 7 months ago

After more days of testing, I can really confirm some things:

Log for showing the error of trying to join a device on a router, not on coordintor:

2024-03-24T00:47:39.081Z zigbee-herdsman:adapter:ember:ezsp ezspTrustCenterJoinHandler(): callback called with: [newNodeId=14428], [newNodeEui64=0x54ef441000720a04], [status=STANDARD_SECURITY_UNSECURED_JOIN], [policyDecision=DENY_JOIN], [parentOfNewNodeId=14880]
[TRUST CENTER] Device 14428:0x54ef441000720a04 was denied joining via 14880.
2024-03-24T00:47:39.082Z zigbee-herdsman:adapter:ember:uart:ash:parser <<<< [FRAME raw=75a6b1a9702a498a5d9e3825ba7d317d5d1d9d4c079188e77e]
2024-03-24T00:47:39.082Z zigbee-herdsman:adapter:ember:uart:ash <--- [FRAME type=DATA]
2024-03-24T00:47:39.082Z zigbee-herdsman:adapter:ember:uart:ash <--- [FRAME type=DATA ackNum=5]
2024-03-24T00:47:39.082Z zigbee-herdsman:adapter:ember:uart:ash <--- [FRAME type=DATA ackNum=5 frmNum=7] Added to rxQueue
2024-03-24T00:47:39.084Z zigbee-herdsman:adapter:ember:uart:ash ---> [FRAME type=ACK frmRx=0]
2024-03-24T00:47:39.085Z zigbee-herdsman:adapter:ember:uart:ash:writer >>>> [FRAME raw=8070787e]
2024-03-24T00:47:39.086Z zigbee-herdsman:adapter:ember:ezsp <=== [FRAME: ID=36:"TRUST_CENTER_JOIN_HANDLER" Seq=228 Len=19]
2024-03-24T00:47:39.087Z zigbee-herdsman:adapter:ember:ezsp ezspTrustCenterJoinHandler(): callback called with: [newNodeId=14428], [newNodeEui64=0x54ef441000720a04], [status=STANDARD_SECURITY_UNSECURED_JOIN], [policyDecision=DENY_JOIN], [parentOfNewNodeId=14880]

full log (search for : 'was denied joining via' ) :

log_ember_edge_22.txt

One last question: should I be worried about those strange messages ? (especially those with many not-ASCII values) like: 

WS-EUK03: unknown key 223 with value !  !  ! !�! !c !g"!$2#!  $  %#��Y��!  �!  �#    �#    �#�  
WS-EUK03: unknown key 229 with value  �ev$........
WS-EUK04: unknown key 14 with value 0
WS-EUK04: unknown key 220 with value 맏-�C  K���.....
WS-EUK04: unknown key 223 with value ! 
WS-EUK04: unknown key 252 with value 0
RTCGQ14LM: unknown key 19 with value 0
RTCGQ14LM: unknown key 20 with value 0
SP-EUC01: unknown key 155 with value 1
Nerivec commented 7 months ago

The workaround to make these Aqara devices work is to make them think the coordinator is the Aqara Hub, so I'm not surprised that they don't pair properly with other devices. Basically Aqara is trying to prevent you from using their devices without their hub... My advice: when you add/replace devices from now on, stay far away from Aqara...

should I be worried about those strange messages ?

These are just unknown values that are not hexified before being printed to logs. Not a problem, just unsupported attributes for a device model. When the device has all expected attributes working in Z2M, that usually means the brand is using extra attributes to exchange with their hub & co, that Z2M doesn't care about.

I'll let you close this issue if that's alright with you. Thanks ;)

adynis commented 7 months ago

Thanks a lot @Nerivec for fixing this topic (and for offering such a great support) ! 🎉 🥳 🥇 The problem stated at the begining is now fixed (tested in edge version, soon will be in public release) so I'm closing the issue .