Homelab, Linux, JS & ABAP (~˘▾˘)~

[Home Assistant] Zigbee2MQTT – ‘MAC channel access failure’ (225)

Suddenly, some weeks ago, devices in my Zigbee network started to become sometimes unavailable and did not respond. This occurred at random times and on random devices. When checking the Zigbee2MQTT logs, it was flooded with MAC channel access failure error messages.

When searching for this error message, this GitHub issue pointed me to the potential issue: Network Interferences (probably Wi-Fi). See also the official docs here.

I have two ZigBee networks in parallel. One using ZHA and the Conbee II stick running on channel 20. And one using Zigbee2MQTT using a Sonoff ZBDongle-P (CC2652P) running on channel 11, which had the network issues. Without further investigation, I thought, let’s check what channel my own Wi-Fi is using and if it is on channel 11, simply change it to something else (which turned out to be a completely wrong approach). In my FritzBox router, the channel selection was configured as “auto”. So no specific channel set. That made sense to me, as the ZigBee issues randomly appeared, so perhaps only when the Wi-Fi switched to a channel, ZigBee was already using.

Without further investigation, I simply set the Wi-Fi channel to 1, so that it does not interact with Zigbee channel 11 (just to mention it here again: this is completely incorrect!). But things got worse, instead of better.

After reading this great blog post about building a stable Zigbee network and seeing the graph from Metageek about Wi-Fi and Zigbee channels, I noticed my issue…

Wi-Fi Channel 11 <> Zigbee Channel 11

By simply looking at the Metageethek graph, I understood why I made things even worse. My newly selected Wi-Fi channel 1 interfered directly with Zigbee2MQTT channel 11.
SmartHomeScene is recommending the following channel settings in their blog post:

  • Zigbee channel 11, Wi-Fi channel 6 or 11
  • Zigbee channel 15, Wi-Fi channel 11
  • Zigbee channel 20, Wi-Fi channel 1
  • Zigbee channel 25, Wi-Fi channel 1 or 6

So I tried switching my WI-FI to channel to 11, which should not interference with ZigBee channel 11. And yes, Zigbee2MQTT was now running fine, but suddenly the MAC channel access failure error messages appeared on ZHA. Seems like the ZHA ZigBee channel 20 was sill too close to WI-FI channel 11. So I thought, why not using a WI-FI channel, which is completely out of the ZigBee range. I switched my Wi-Fi from channel 11 to channel 13, and everything runs smooth since then. Finally, my ZigBee network is “rock solid”! 🙂

[SAPUI5] Add your own Logout functionality to the Launchpad Sandbox

Use the attachLogoutEvent of the ushell container to trigger your approuter logout endpoint, that needs to be configured in your xs-app.json. The code in my launchpad.html looks like this:

        sap.ui.getCore().attachInit(() => {

            sap.ushell.Container.createRenderer('fiori2', true).then(renderer => renderer.placeAt("content"))

            sap.ushell.Container.attachLogoutEvent(e => {
            }, false)


This way, you can reuse the default logout dialog logic the launchpad provides.

For completeness, find also my approuter configuration and custom logout page below.

My xs-app.json:

  "welcomeFile": "index.html",
  "authenticationMethod": "route",
  "logout": {
    "logoutEndpoint": "/do/logout",
    "logoutPage": "/logged-out.html"
  "sessionTimeout": 60,
  "routes": [
      "source": "^/logged-out.html$",
      "localDir": ".",
      "authenticationType": "none"
      "source": "^/launchpad.html$",
      "localDir": ".",
      "authenticationType": "xsuaa",
      "cacheControl": "no-cache, no-store, must-revalidate"
      "source": "^/appconfig/(.*)$",
      "localDir": ".",
      "authenticationType": "xsuaa"
      "source": "^/user-api(.*)",
      "target": "$1",
      "service": "sap-approuter-userapi",
      "authenticationType": "xsuaa"

My logged-out.html file, placed in the approuter folder next to the launchpad.html:

<!DOCTYPE html>

    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Logged out</title>
        h2 {
            font-family: "Arial", sans-serif;
        .centered {
            position: absolute;
            top: 50%;
            left: 50%;
            transform: translate(-50%, -50%);

    <div class="centered">
        <h2>You are now logged out</h2>


[Home Assistant] Update firmware on Sonoff Zigbee USB Dongle-P

First, confirm that you have a Sonoff Zigbee 3.0 USB Dongle Plus. Go to Settings → Hardware → All Hardware → Search for Zigbee

Check your current firmware version:

Important: Stop Zigbee2Mqtt before flashing, as described in the docs!

Now let’s add the ZigStar repository: Settings → Add-ons → Add-on Store → Three dots → Repositories → Add

After that, install the Add-on for Texas Instruments CC2652P7 based radios.

Copy the firmware link from here:

Got to the Configuration of the installed ZigStar Add-on and paste the firmware link and select the two radio buttons like bellow.

If you receive an error when saving the configuration, simply add as Network Device and save again.

If the Configuration is successfully saved, start the Add-on and flashing will start immediately.

Switch to the Log tab and hit refresh until you see the “successfully stopped” message.

Now you can stop the ZigStar Add-on and start Zigbee2Mqtt again and check your new installed version.


[SAPUI5] Add custom header parameter to all oData queries

Simply go to your Component.js file and add this line to the init function:

this.getModel().setHeaders({"myCustomParameter": "test"})

In a CAP Backend, you get this parameter from the express req object, which can be accessed via the req.http property:


And here is a nice code snippet, on how to read this header parameter in an ABAP system:

[SAPUI5] Suppress default oData error message / display meaningful error messages

Create a separate ErrorHandler.js file, like it is described here and either do your own error handler implementation, or take the sample from here. To avoid displaying multiple errors at once, follow this chapter.

Thanks to the provided dsag sample, this is takes only a few minutes and improves the user experience a lot!