nocin.eu

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

[CAP] Get service and approuter URLs of your running CAP application in a service handler

In your mta.yaml you can define environment variables, which are filled during deployment. They can be filled with MTA Development and Deployment Parameters. Click here for an overview.

To get the URL of your deployed CAP service, simply use the ${default-url} parameter and pass the value to a variable below the properties attribute, e.g. SRV_URL. The approuter has to provide its default-url, which can then be used in the service for a variable, e.g. APPROUTER_URL.

  #####################################################################################################################
  # Approuter
  #####################################################################################################################
  - name: approuter
    type: approuter.nodejs
    path: app/approuter
    provides: 
      - name: app-api 
        properties:
          app-url: ${default-url}   # <---------------------------- provides approuter url
          app-uri: ${default-uri}   # <---------------------------- provides approuter uri/hostname
          app-protocol: ${protocol} # <---------------------------- provides approuter protocol

  #####################################################################################################################
  # Business Service Module
  #####################################################################################################################
  - name: mySrv
    type: nodejs
    path: gen/srv
    requires:
      - name: app-api # <---------------------------------------- required to access the provided variables of the approuter
    properties:
      SRV_URL: ${default-url}
      APPROUTER_URL: ~{app-api/app-url}
      SUBSCRIPTION_URL: ~{app-api/app-protocol}://\${tenant_subdomain}-~{app-api/app-uri}

After deployment, you can now access the URL via process.env.SRV_URL in a service handler. During development, simply use the .env file to provide the SRV_URL value.

You can check all the variables via the BTP Cockpit: Subaccount → Space → Select application → User-Provided Variables

[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”! 🙂

Update 19.04.2024: The Zigbee network was now working without issues for a few days, but suddenly my ESP Devices started to drop off the WI-FI network… When searching, I found this blog post, where it’s recommended to avoid channel 12-14 when using ESP devices. As I didn’t want to get into conflict with the Zigbee network again, I changed the channel from 13 to 12 as a test. And after a few days, I can now say that Zigbee and ESP devices are running smoothly. Finally!

[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:

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

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

            sap.ushell.Container.attachLogoutEvent(e => {
                e.preventDefault()
                window.location.replace('/do/logout')
            }, false)

        })
    </script>

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>
<html>

<head>
    <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>
    <style>
        h2 {
            font-family: "Arial", sans-serif;
        }
        .centered {
            position: absolute;
            top: 50%;
            left: 50%;
            transform: translate(-50%, -50%);
        }
    </style>
</head>

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

</html>

[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 https://github.com/mercenaruss/zigstar_addons

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

Copy the firmware link from here: https://www.zigbee2mqtt.io/guide/adapters/

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 127.0.0.1 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.

Done.

[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:

req.http.req.headers['myCustomParameter']

And here is a nice code snippet, on how to read this header parameter in an ABAP system: https://answers.sap.com/answers/425621/view.html