We are currently working on a custom "Color Detector" app built for the ctrlX virtual OS environment. The application is designed to take a video stream/upload via a web interface, process it using computer vision to draw bounding boxes around detected colors, and then publish that metadata (frame count, object count, latest objects) to the ctrlX Data Layer.
While the computer vision and web UI components are working perfectly, I am completely unable to get the data to appear in the Data Layer.
Here is a breakdown of my setup and the exact issues I am facing:
1. The Workflow & Expected Behavior

• The app runs as a snap (color-detector).
  

• Users access the web UI via the device's IP, upload a video, and the processing begins.
  

• The web app successfully processes the video and tracks the objects (as seen in my UI).
  

• Expected: The metadata should be written to the Data Layer nodes (e.g., sdk/app/color-detector/objects/latest).
  

2. The Problem & Error Logs
Despite the app working locally, the Data Layer connection fails. I noticed a few critical warnings in my terminal:

• UI Status: In the top right corner of my web application UI, it clearly states "DATA LAYER: OFFLINE".
  

• Startup Logs: When I check the snap logs (sudo snap logs color-detector -n 30) upon startup, I see the following errors before the Flask app initializes:
  

Plaintext

ctrlx-datalayer native library not found - Data Layer disabled
[WARNING] datalayer_client: Data Layer SDK missing - running in fallback mode

• HTTP 200 Metadata: Once I upload the video, my logs show constant GET /metadata HTTP/1.1" 200 requests. The app is clearly generating the metadata, but it's stuck in "fallback mode" and cannot push it to the ctrlX Data Layer tree.
  

My Questions for the Community:

• How do I correctly bundle the ctrlx-datalayer native libraries and SDK into my snap build environment so that it doesn't default to "fallback mode"?

I’m currently working on a ctrlX CORE X7 where I deployed a custom Python backend (Flask + flask-sock for WebSockets) together with a WebIQ frontend. The backend exposes both REST endpoints (e.g. /config, /write) and a WebSocket endpoint (/ws) used by a WebIQ frontend.

In local development everything works exactly as expected. The backend runs via the SDK, the WebIQ frontend is served locally (the HMI browser preview runs on http://localhost:10124), and communication over HTTP (http:// + ws://) works perfectly, including subscriptions, live updates, and write operations. So from a functional standpoint, both backend and frontend are correct and stable.

Since WebIQ is served over HTTPS on ctrlX, the browser enforces secure communication. As soon as the frontend tries to connect to my backend running on port 5055, I start getting multiple issues. Initially, the browser blocks requests due to mixed content (HTTPS frontend trying to call HTTP backend). To address this, I updated the frontend in WebIQ localscripts to dynamically switch protocols (http/https and ws/wss) based on window.location.protocol.

Here's a few examples:

const protocol = window.location.protocol === "https:" ? "https" : "http";
const configUrl = ${protocol}://${window.location.hostname}:5055/config/${plcName};

const protocol = window.location.protocol === "https:" ? "https" : "http";
await fetch(${protocol}://${window.location.hostname}:5055/write, {...});

const protocol = window.location.protocol === "https:" ? "wss" : "ws";
ws = new WebSocket(${protocol}://${window.location.hostname}:5055/ws);

I also enabled CORS in Flask (CORS(app) and in a second moment CORS(app, resources={r"/*": {"origins": "*"}})), but this did not resolve the issue. The browser still reports errors or blocks the requests entirely.

I then tried to enable HTTPS directly in Flask. After that, I also did generate proper HTTPS certificates with the following command:
openssl req -x509 -newkey rsa:2048 -nodes -keyout https_key.pem -out https_cert.pem -days 7305

In this way it actually worked, with the following setup:
The application is configured to use HTTPS with: ssl_context=("https_cert.pem", "https_key.pem").
The server will be available at: https://[ctrlX_IP]:5055
After generating the certificates, you must manually access: https://[ctrlX_IP]:5055/health
This step is required to accept the certificate and allow trusted communication with WebIQ.
On first access, the browser will warn that the certificate is not trusted. Click "Proceed" (or the equivalent option).
If everything works correctly, you should see the following response: {"status":"up"}.

But it requires me to repeat these steps every x hours.

From the WebIQ community I got the following feedback:

This is a browser security issue, not related to WebIQ.
You cannot mix HTTP and HTTPS, and you need either proper HTTPS or a reverse proxy.

Which I agree with in general.

So with the current HTTPS setup using a self-signed certificate, I noticed the following behavior:

• The backend becomes reachable at https://[ctrlX_IP]:5055

• However, the browser requires manually visiting https://[ctrlX_IP]:5055/health to accept the certificate

• After accepting it, communication with WebIQ temporarily works

• After some time, the browser seems to reject the connection again and the process must be repeated

This makes the setup unstable and not suitable for a production-like scenario.

I also looked into the official reverse proxy approach using Caddy and tried to follow this guide:
https://community.boschrexroth.com/ctrlx-automation-how-tos-qmglrz33/post/howto-view-content-from-multiple-web-servers-in-one-web-page-reverse-cI11ECmiI2GyvxP and https://boschrexroth.github.io/ctrlx-automation-sdk/package-assets.html

However, I have to admit I didn’t fully understand how to apply it to my setup. Additionally, I am running on WebIQ version 2.17, and from what I understood, starting from 2.14 Caddy should already be integrated and handling routing, so I expected less manual configuration.

So I suspect that the correct approach here is not to access the backend directly via https://hostname:5055, but instead to configure routing through the ctrlX reverse proxy (Caddy), so that:
- REST endpoints are reachable via something like /api/...
- WebSockets via /ws
- all under the same HTTPS origin

This would also naturally solve:
- mixed content issues
- certificate handling
- WebSocket upgrade handling

At this point I’m trying to better understand how to properly integrate a custom backend into the ctrlX routing layer, rather than exposing it directly.

If anyone has a working example of:
- exposing a custom backend via ctrlX reverse proxy
- handling WebSocket upgrades correctly in that setup

that would be extremely helpful.

Thanks again for your input!

When we create a backup and encrypt it with a password, does it only encrypt it for restore? Because the zip contents are viewable if we view it from the zip file and it also let's us unzip and extract the zip.

Is this understanding correct? Or does it also encrypt the zip itself?

CodeShepherd

There is an error message in the logbook:
Main diagnostic code: 080F0829
Detailed diagnostic code: 0C64100E
Description 1: App connection failed
Description 2: App connection not allowed for apps from unknown sources
Description 3: Connection of plug <myappname>:home is not allowed
Source 3: web.packagemanager / snap.rexroth-deviceadmin.web.service

In the app settings, apps from unknown sources are allowed. Otherwise, I couldn't even have installed the app.

Description 3 of the error message says that plug "home" is not allowed, which is needed for file access. But file access is working.

UDP communication is also working. But the data layer access is not working.

Any idea what the issue could be?

I want to create same snap like OPC UA, "create token app" which will get installed and In the menubar When clicked "Create token app" opens the gui in the right side where it will take two inputs username and password and save button when clicked in the backend it will call restapi to create token

I want to develop in python

Which will have UI for configuration & On the backend it will read the parameter from that UI and call the rest api to create backup.

Can I create that snap in c++ does it support UI creation ??

One more thing how can we call the rest api using c++ ?using libcurl

I want to create a variable in datalayer using restapi in python snap.

Variable will be int type and I want to read and write that also.

Could you please help me

I am calling the api like below

url = "https://" + self.ctrlx_ip_address + "/automation/api/v2/nodes/datalayer/test/value"

        payload = {
            "value": "ok",
            "type": "types/string"
        }

But I am getting response

Error: 400 {"type": "about:blank","title": "DL_TYPE_MISMATCH","status": 400,"detail": "Invalid type field","instance": "datalayer/test/value","severity": "Error"}

i installed the datalayer nuget in visual studio vb.net 2019, but when i run the code i get the error : Exception thrown: 'System.DllNotFoundException' in datalayer.dll

An unhandled exception of type 'System.DllNotFoundException' occurred in datalayer.dll

Unable to load DLL 'comm_datalayer.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

over the christmas break I have been implementing a PLC4X compatible driver for CtrlX. So far it supports Browsing, Reading and Writing (Subscriptions will follow soon).

However I noticed a few things, that I think either I'm using it wrongly or that could use improvement.

In order to test my drivers in various protocols, I developed a standard set of variables, UDTs and values I statically assign to them to test my drivers (Attached that as DATA.txt). Then I have a test setup, where I read each tag, compare it to the expected value and then I write the same value back individually. As soon as they pass, I then read all tags at once in random order, then write them back and do that 100 times, each time with a different order.

That's basically the test I try to run on each device to test the driver functionality.

Here with CtrlX I ran into a few problems Added "trivial, minor and major" to indicate how they impact my work or the functionality of the driver:

• (minor) Time types are correctly supported within the CodeSys PLC, but when exported to the datalayer, they are all reduced to simple numeric values and the metadata doesn't provide means of interpreting them as a time, date or duration, they just become numeric values.

• (minor) All other PLC types I have worked with support addressing parts of multi-dimensional arrays. In CtlrX it seems that you can either address the full array or leaf-elements, but not branches. So if for example /plc/app/Application/sym/PLC_PRG/g_matI16_2x3 addresses the full 2x3 array and /plc/app/Application/sym/PLC_PRG/g_matI16_2x3/2,3 one element, there's no way to address all 3 elements of array 1 (/plc/app/Application/sym/PLC_PRG/g_matI16_2x3/1)

• (trivial) When fetching a multi-dimmensional array, the result is a flat array and my driver needs to convert that back into a multi-dimmensional array.

• (major) Even if fetching multi-dimmensional arrays of simple types seems to work, this doesn't seem to work in case of multi-dimmensional arrays of user-defined types. Here I'm only getting errors, from the remote when trying to fetch them.

(I added my unit-test as ManualCtrlXDriver.java as "txt" file) This also contains notes I did.

Will now try to convert the temporal types to numeric and at least continue checking the functionality of the reading and writing of UDTs.