After switch to CC1352P-2: Error: Data request failed with error: 'MAC no ack' (233)

[odx]

As I don't want the discussion in #2761 to loose focus I am opening a separate issue.

After resetting the tradfri bulb using touchlink I was able to pair it again. But after unplugging it and moving it back to its location I get errors again. I had this same behavior after I switched the coordinator to CC1352P-2. It first paired and worked but after a short period of time it refused to respond. Another identical bulb works fine.

I changed all three when migrating to CC1352: channel (now 15), pan id and extended pan id. Might that be the issue? I wanted to pick something unique not to interfere with possible other networks nearby.

debug 2020-01-20 20:35:01: Received MQTT message on 'zigbee/tradfri/set' with data '{"state":"OFF"}'
debug 2020-01-20 20:35:01: Publishing 'set' 'state' to 'tradfri'
error 2020-01-20 20:35:01: Publish 'set' 'state' to 'tradfri' failed: 'Error: Data request failed with error: 'MAC no ack' (233)'
debug 2020-01-20 20:35:01: Error: Data request failed with error: 'MAC no ack' (233)
    at ZStackAdapter.<anonymous> (/app/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:578:27)
    at Generator.next (<anonymous>)
    at fulfilled (/app/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:5:58)
info  2020-01-20 20:35:01: MQTT publish: topic 'zigbee/bridge/log', payload '{"type":"zigbee_publish_error","message":"Publish 'set' 'state' to 'tradfri' failed: 'Error: Data request failed with error: 'MAC no ack' (233)'","meta":{"friendly_name":"tradfri"}}'

Debug Info

zigbee2mqtt version: 1.8.0
CC1352p-2 firmware version: 20191106

[Koenkk]

After migrating to the CC1352p-2 did you repair all your devices?

[odx]

Yes of course. I also changed the network key.

I just did a quick check this morning without observing the logs:
When I get switch the other bulb that used to work after pairing off physically (or unplug it) it also stops working.

I assume that the network parameters are not correctly stored for the tradfris. I will try to reproduce this with log observation and provide an update on this.

[odx]

So the second bulb works fine and reconnects to the network after a few seconds... It is only this device that keeps failing...

[henris42]

I'm getting this same message maybe every 10th time, the reason might also be that the antenna is bit far from the IKEA bulb.

MQTT is supposed to be reliable protocol, how about a configurable amount of retries before giving up with error message (and in user perspective failure to function)?

[Koenkk]

@odx try resetting the bulb using touchlink https://www.zigbee2mqtt.io/information/touchlink.html

[odx]

@Koenkk resetting through touchlink did not change anything. But today I moved the bulb to another location in the house and boom itt is functional again even without repairing. There must be an issue with the message routing. Maybe one of the routers are not working correctly.

Since today I also have an issue with a PIR sensor that is nearby the disfunctional location and now reporting movements only in rare cases.

I will check if the other sensors are all working and reset the routers to see if that helps.

[odx]

It seems this is the only device not working so far. This issue reappears again and again.

When I reset the device near to the coordinator it works until I move if away.

[Koenkk]

@odx try pairing the bulb at the place you want to keep it.

[odx]

The log was taken at That location.

[Koenkk]

Can you try:

• Pair the device close to the coordinator and remove it after that (no force_remove!! https://www.zigbee2mqtt.io/information/mqtt_topics_and_message_structure.html#zigbee2mqttbridgeconfigremove)
• Move device to location
• Pair device

I think there is something messed up with the routing tables, if it doesn't work we can try rediscovering the route.

[odx]

Here is what I did:

Starting Point:

• The device was currently not in the Database (Probably because I recently force removed it)
• The device did not have the network key (Because it has been reset recently)

Actions:

• Enable join
• Reset the device next to the Coordinator
• Wait until paring completed
• Remove (not force remove) the device
• Move to distant location
• Switch on the device

Here is the log:

info  2020-02-01 19:45:16: Device '0x000b57fffe976159' joined
info  2020-02-01 19:45:16: MQTT publish: topic 'zigbee/bridge/log', payload '{"type":"device_connected","message":{"friendly_name":"0x000b57fffe976159"}}'
info  2020-02-01 19:45:16: Starting interview of '0x000b57fffe976159'
info  2020-02-01 19:45:16: MQTT publish: topic 'zigbee/bridge/log', payload '{"type":"pairing","message":"interview_started","meta":{"friendly_name":"0x000b57fffe976159"}}'
debug 2020-02-01 19:45:22: Device '0x000b57fffe976159' announced itself
<CUT>
error 2020-02-01 19:46:36: Failed to interview '0x000b57fffe976159', device has not successfully been paired
info  2020-02-01 19:46:36: MQTT publish: topic 'zigbee/bridge/log', payload '{"type":"pairing","message":"interview_failed","meta":{"friendly_name":"0x000b57fffe976159"}}'

How can the route be checked? I have a CC2531 sniffer available.

[Koenkk]

As you have a sniffer, can you sniff when trying to control the bulb at the distant location after pairing it successfully close to the coordinator?

[odx]

This is what I see in the packet log when I try to control the device. 0xa34f is the affected bulb according to the "nwkAddr" of the database.db.

437	315.669474	0x0000	0xa34f	IEEE 802.15.4	48	Data, Dst: 0xa34f, Src: 0x0000, Bad FCS

Listing

FCS: 0x0000 (Incorrect, expected FCS=0xSOMEHEXVALUE)

in the IEE 802.15.4 Data.

What exactly should I look for in the network frames?

There are a few things that I noticed when grubbing through the packages:

• I found that on my channel there seem to be other 802.15.4 traffic. As there are network frames referencing network addresses not in my database and another PAN.
• I discovered network frames from 0x0000 to 0xa34f referencing a different PAN than what I have configured. (also being reported as Bad FCS).
• Lastly I saw a few network frames from network addresses not in my database but using my PAN.

[Koenkk]

This means that the packets are corrupted, I think there is too much interference on the current channel.

[odx]

Ok. Weird is that ist seems only this device is affected.

I will scan other channels and see if they are more quiet. Occasionally I will go back to default channel 11 which worked better earlier.

[odx]

@Koenkk any idea why this tends to happen mostly just to that single device and when its at its place far from the coordinator whereas another bulb in the same room works fine? I'd assume that the complete network is unstable when there is noise on the band.

[Koenkk]

• Can you swap the locations of the bulb?
  • Does the other bulb work at the "non-working" location?
  • Does the non-working bulb work at the location of the working bulb?

[odx]

@Koenkk i swapped the bulbs (I left the lamps in place and only exchanged the bulbs themselves):
The other bulb works
The problematic bulb initially did not respond but throughout the next few minutes it started to react to more and more commands until it emerged to function well.

I will observe if it this state remains. As sometimes after pairing it worked for several hours.

Now that the bulb is responsive, I see less bad control sequences but they have not completely gone away and are definitely also within my network.

Nevertheless I believe that moving the network to a different channel seems to be a wise idea. I also moved my 2.4 Ghz Wifi from Channel 6 to 11 in Order to free up the lower Zigbee channel bands so I might get good results on Zigbee channel 11.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mumlax]

Just my experience for others who have the same problem:
Moving my 2.4Ghz-Wifi to channel 11 solved this problem in my setup completely. Didn't do anything else.

[k-zakhariy]

@mumlax and which channel do you use for zigbee stick ?

[mumlax]

@k-zakhariy to be honest: I didn't configure a specific channel and just learned from you, that this is even possible :D
Is it possible to find out the used channel in z2m, without having configured it?