Your Own Flexa Application for Barionet with Claude AI

Barionet Flexa Skill for Claude AI

Build your own I/O and control application on the Barix Barionet — guided by Claude AI.

Don't just build it. Build it on Barix. The Barionet has been the Swiss-army knife of Barix automation for years: relays, digital and analog inputs, temperature sensors, counters, RS-232/RS-485, USB I/O extensions and an embedded Linux runtime, all on a DIN-rail-friendly device. The Barionet Flexa Skill is a specialised instruction set that teaches Claude how to generate complete, deployable Flexa applications — manifest, configuration form, application code, optional web interface, and a ready-to-upload package — for the Barionet M44 and the newer M82. Every capability in this guide was verified on real M44 and M82 hardware.

This guide walks you through downloading the skill, importing it into Claude.ai, and using it to develop your first Barionet app. An annotated example conversation is included at the end so you can see exactly how a session typically unfolds.

1. What the Skill Does

The Barionet Flexa Skill turns Claude.ai into a Barionet-aware code generator. Once loaded, Claude will:

Ask a short set of questions to capture what the app should do, which device it targets (M44 or M82), and which I/O resources it needs.
Help you decide how the app is configured — a built-in SDF settings form or a custom web page — and design it before writing any code, so you can review and adjust it.
Generate the full Flexa package: manifest.json, install.json, the application code (main.py, main.lua, or a compiled binary), config/sdf.json, any web_ui/ pages, and the tested helper modules the app needs.
Validate the package and bundle everything into a ZIP that is ready to upload to your Barionet — no manual editing required.

Supported hardware

Barionet M44 — 4 relays, 4 universal input terminals, 2 user LEDs
Barionet M82 — 2 relays, 4 digital outputs, 8 universal input terminals, 2 Wiegand readers, a second serial port

The skill discovers the hardware at runtime, so the same app can run on either model and automatically picks up attached UX8 extensions.

Supported I/O resources

The skill knows the complete Barionet M44 and M82 I/O address map and will wire any of these into your app on request:

Relays — onboard relay outputs (4 on the M44, 2 on the M82), with a hardware timed-pulse mode that opens the contact automatically even if the app is restarted.
Digital outputs — 4 solid-state outputs on the M82 (also with hardware timed pulse).
Digital inputs — contact state (4 on the M44, 8 on the M82), with optional change-notification callbacks and switchable pull-ups.
Input counters — pulse counting for flow meters, gate sensors and energy meters.
Analog inputs — millivolt readings for sensors and 0–10 V signals (each input terminal is also usable as a digital input and counter).
1-Wire temperature sensors — millidegrees Celsius, for any connected temperature probes.
Wiegand card readers — the M82's two readers (on input terminals 5–8), decoded into facility code and card number for access-control apps.
Serial — RS-232 on /dev/ttyS1 (both models) and a second port on the M82, with a ready-made framing/serial helper for line, fixed-length and binary protocols, plus Modbus.
Front-panel LEDs — two app-controllable user LEDs on the M44.
Supply current, supply voltage, CPU temperature, uptime — built-in housekeeping values.
UX8 extensions — automatic detection of attached Barionet UX8 I/O extensions at runtime, with safe handling of the USB link (a lost extension is detected, logged and reported instead of returning wrong data).

Programming languages

Python (default)
Lua
C / C++ (compiled)
Rust (compiled)

Claude uses Python unless you ask for something else. Python and Lua apps use the Barionet's pre-installed iomapping library — no pip install, no external dependencies, no manual library packaging. For maximum performance or reuse of existing native code, the skill can also produce C++ or Rust apps; because there is no compiler on the device, those are cross-compiled on your machine and shipped as a binary. Native apps read and write the same I/O either through the on-device D-Bus service (by address, with scaled values) or directly through sysfs. The skill includes verified C++ and Rust examples and the exact cross-compile commands.

Configuration: SDF form or custom web UI

Every app gets a tab in the device web interface. The skill helps you choose between two approaches and builds whichever fits:

SDF settings form — a JSON description of your settings that the firmware renders automatically. Best for configuration that takes effect when saved. No front-end code.
Custom web UI — a live status/control page served by the app on its own port. Best when you need real-time values, action buttons or a bespoke layout. The two can be combined (a settings tab plus a live page).

Optional features the skill can wire in

Local logging to the device LOGS tab, plus optional remote syslog forwarding
Change-notification callbacks on digital inputs, so the app reacts to state transitions instead of polling
MQTT publishing/subscribing, a live status web page, or a serial-to-network gateway
Configurable thresholds, hysteresis, polling intervals, and any other parameter you want to expose
Multi-section configuration tabs with grouped fields, dropdowns, checkboxes, toggles, sliders, repeating lists and password fields

2. What You Need

A Claude.ai account on a Free, Pro, Max, Team or Enterprise plan.
Code execution and file creation enabled in your Claude account settings (this is required for skills to run).
A Barionet M44 or M82 reachable over the network for upload.
The latest Barionet firmware on the target device (the skill targets minFwVersion 2.3.0 by default; Claude will raise it if a feature requires a newer version).
The skill ZIP file — attached to this article.

3. Download the Skill

The skill is distributed as a single ZIP file attached to this help-center article. Download it to your computer; do not unzip it — Claude.ai expects the ZIP exactly as provided.

CLICK TO DOWNLOAD

Contents: SKILL.md plus a set of reference documents (the full M44/M82 I/O address map and iomapping API, the SDF specification, serial and Wiegand notes, packaging and firmware details, the language guide, and the list of pre-installed packages on the Barionet OS), a library of tested helper modules, several ready-to-read example apps (Python, Lua, C++ and Rust), and a package validator/builder script.

4. Import the Skill into Claude.ai

Follow these steps once. Once the skill is installed it stays in your account and can be enabled or disabled at any time.

Sign in to Claude.ai in your web browser.
Open Settings → Capabilities and make sure Code execution and file creation is enabled. Skills will not run without it.
Open Customize → Skills.
Click the + button, then + Create skill, then choose Upload a skill.
Select the downloaded skill ZIP file.
Wait for the upload to complete. Barionet Flexa App will appear in your Skills list.
Toggle the skill ON. You are ready to use it.

Team and Enterprise accounts

Organisation owners can provision the skill account-wide so it appears automatically for every member. Open Organization settings → Skills, enable Code execution and file creation and Skills, then upload the skill ZIP as a provisioned skill.

5. How to Use the Skill

Start a new chat in Claude.ai and ask Claude to build a Barionet app. The skill will trigger automatically when you mention Barionet in a development context. If you want to be explicit, simply say:

Use the Barionet Flexa Skill to build me an app for my Barionet M82.

The skill drives the conversation in three phases:

Phase 1 — Requirements gathering

Claude asks a short set of focused questions:

Which device — M44 or M82 (or should it run on both)?
What should the app do?
Which I/O resources does it need (relays, digital inputs/outputs, analog inputs, counters, temperature sensors, serial, Wiegand, LEDs, UX8)?
Which parameters do you want the user to be able to configure, and via an SDF form or a custom web page?
Language preference (Python, Lua, C++ or Rust)?
What should the configuration tab be called in the Barionet web interface?

Answer them in a single reply — Claude reads all your answers together.

Phase 2 — Plan confirmation

Claude prints a compact summary: app name, device, language, tab name, the I/O addresses that will be read or written, the configuration sections and fields, and the files that will be generated. Review it, then say yes to continue. If anything is off, just tell Claude what to change.

About the SDF

SDF stands for Settings Definition File. It is a JSON file (config/sdf.json) that describes the configuration page shown for your app inside the device's web interface — every field, default value, dropdown and grouping. The firmware reads the SDF and renders the form automatically; whatever the user enters is saved into the app's configuration and read by your code at run time. The skill generates the SDF for you based on your answers in Phase 1, so you get a fully working configuration page without writing any UI code. On the very first install, before the form has ever been saved, the app supplies its own built-in defaults, so it runs correctly out of the box.

Phase 3 — File generation

Claude generates every file in order, validates and packages them into a ZIP, and tells you the ZIP filename, how to upload it to the Barionet, and what to fill in on the configuration tab after the first launch.

Deploying the generated app

Download the ZIP file produced by Claude (for a C++ or Rust app, cross-compile the binary first using the command Claude provides).
Open your Barionet's web interface and go to the HOME tab.
Click Install Package and select the ZIP.
Open the app's configuration tab and fill in the SDF fields Claude documented at the end of the chat.
Submit the form. The app starts (or restarts) automatically on submit. Its log lines appear in the device LOGS tab.

6. Alternative Approach: Start From a Working Example

Building from scratch with the skill is the most flexible route, but it is not always the fastest one. If your target application is close to something that already exists, it is often quicker — and the result is often more reliable — to start from a working example app and let Claude modify it, rather than asking Claude to generate everything from a blank page.

There are many example apps made for Barionet that you can download, install on your Barionet unchanged, and use as a starting point for your own development. The skill itself also ships several read-to-read example apps (a broad IO gateway, a serial bridge, a Lua monitor, and native C++/Rust samples). Each example is fully functional out of the box: a complete install.json, application code, and configuration are already in place and known to work on the target firmware.

To use this approach:

Download an example app ZIP and install it on your Barionet to verify it runs.
Unzip the package on your computer so you can see all the source files.
Open a new chat in Claude.ai with the Barionet Flexa Skill enabled.
Upload the example files to the chat (drag and drop the unzipped folder, or paste the contents of individual files).
Describe the changes you want — for example using the MQTT Client app: "Here is a working Barionet app that reads a temperature sensor and toggles a relay. I want to extend it so it also publishes the temperature to an MQTT broker every 30 seconds. Please modify it and give me back a deployable ZIP."
Claude will read the existing structure, apply your changes consistently with the skill's conventions, and re-package the result.

When to prefer this approach over starting from scratch:

Your new app is a variation of an existing one (different thresholds, different I/O channels, an extra feature, a different reporting target).
You want to preserve a specific code structure, comment style, or naming convention that already works for your team.
You need to retain compatibility with an external system (a particular MQTT topic layout, a specific Modbus register map, a specific log format) and want to avoid Claude reinventing those details.
You are learning what a well-structured Barionet app looks like and want a concrete reference to read alongside the skill's instructions.

When to start from scratch instead:

The new app does something fundamentally different from any example you have on hand.
The example you are tempted to start from is significantly more complex than what you actually need — Claude is faster at generating a lean app from a clear specification than at trimming a large one down.

Either approach uses the same Barionet Flexa Skill in the background; the difference is only what Claude has on the table when the conversation starts.

7. Example: Temperature-Driven Cooling Relay Controller

The following is an example of a real session with Claude using the Barionet Flexa Skill. The target is a Barionet used as a thermostat: it reads a temperature sensor, closes a relay to start a downstream cooling system when the temperature rises above a configurable threshold, and opens the relay once the temperature has dropped below threshold-minus-hysteresis. All transitions are logged. The conversation is reproduced here for illustration; your exact wording will differ.

👤 You

Use the Barionet Flexa Skill to build me an app for my Barionet M44. I want a thermostat: read temperature sensor 1, close Relay 1 above a configurable threshold to start a cooling unit, open it again once the temperature has dropped by a configurable hysteresis. Everything should be configurable from the web UI, and I want syslog forwarding.

🤖 Claude

Happy to put that together. A few quick questions and we'll be ready to generate the package:

App name and tab name for the web UI?
Confirm the I/O: temperature sensor 1 (address 601) for reading, Relay 1 (address 1) for the cooling output — correct?
Polling interval — how often should the app read the temperature? (Typical: 1–10 seconds.)
Configurable parameters to expose in the web UI: Threshold (°C), Hysteresis (°C), Polling interval (s) — anything else? (Manual override, on/off enable switch, …)
Syslog server address and default port (514)?
Language: Python (default), Lua, C++ or Rust?
One-line description of what this app does (used as a comment header in the generated code).

👤 You

Here are the answers:

App name: cooling-thermostat, tab name: "Cooling Thermostat"
I/O confirmed: temperature sensor 1 (read), Relay 1 (write).
Polling interval: 2 seconds default, configurable.
Configurable parameters: Threshold (°C) default 28; Hysteresis (°C) default 2; Polling interval (s) default 2; Enable switch (boolean) — when off, the relay stays open regardless of temperature.
Syslog: default 10.0.10.4 port 514, with an enable toggle.
Language: Python.
Description: "Thermostat — Relay 1 follows Temperature Sensor 1 with configurable threshold and hysteresis."

🤖 Claude

Got it. Here is the build plan:

App: cooling-thermostat
Language: Python
Tab name: Cooling Thermostat

I/O addresses:
Read: 601 (Temperature Sensor 1, m°C)
Write: 1 (Relay 1, cooling output)

SDF sections:
thermostat
- enable (boolean, default true)
- threshold_c (number, default 28, range -20..80)
- hysteresis_c (number, default 2, range 0..20)
- poll_interval_s (number, default 2, range 1..60)
logging
- enable_syslog (boolean, default false)
- syslog_address (string, default "10.0.10.4:514")

Files to generate:
- manifest.json
- install.json
- main.py
- config/sdf.json
- config.json (shipped defaults)

Does this plan look correct? Shall I generate the package?

👤 You

Looks good — go ahead.

🤖 Claude

Generating the package now…

Wrote cooling-thermostat/manifest.json
Wrote cooling-thermostat/install.json
Wrote cooling-thermostat/main.py
Wrote cooling-thermostat/config/sdf.json
Validated and created cooling-thermostat.zip

Your package is ready: cooling-thermostat.zip

To deploy:

Open your Barionet web interface and go to the HOME tab.
Click Install Package and select cooling-thermostat.zip.
Open the Cooling Thermostat tab.
Set the threshold, hysteresis, polling interval and syslog server, then submit.
On submit, the app starts. Relay 1 will close when Temperature Sensor 1 rises above the threshold and re-open once it has dropped below threshold-minus-hysteresis. Transitions and the current temperature are logged, and appear in the device LOGS tab.

That is the complete development loop: less than five minutes of conversation, and a tested, deployable Barionet application at the end of it. The same flow applies to MQTT bridges, Modbus gateways, Wiegand access control, counter-based event triggers, scheduled relay control, serial gateways, and any combination of these — just describe what you need.

8. Tips for Getting Good Results

Name your device. Tell Claude whether you are targeting an M44 or an M82 (or both) — the I/O counts and some features differ between them.
Be concrete about I/O. Tell Claude which addresses to read and write, or describe the physical signals and let Claude pick the right addresses. Vague prompts produce vague apps.
Answer all questions in one reply. The skill is designed to capture all requirements in a single round so it can produce a coherent plan.
Always review the plan before generation. It is faster to correct the plan than to regenerate files.
Remember the app restarts on every form submit. Design your app to start cleanly from scratch every time; do not rely on in-memory state surviving a configuration change.
Iterate. If the generated app needs adjustments, simply describe the change — Claude will edit and rebuild the ZIP.
Test on the device. Generated code targets the exact Barionet firmware environment, but every deployment has its own wiring and external systems; always verify on the real hardware, using the LOGS tab to see what the app reports.

9. Security & Hardening

The Barionet Flexa Skill is a development aid: it generates application code and packages it. It does not change how your device is accessed, and it contains no exploits, credentials or ways to bypass any login. The security of a deployed Barionet depends on how you install and expose it — the points below are the ones that matter.

The trust boundary is "who can install a package." A Flexa app runs with full privileges on the device, so anyone able to install a package can make the device do anything. Everything else follows from protecting that step:

Set the web-interface admin password and use a strong one. The package-upload page and the whole web UI sit behind this login; a device left without a password lets anyone on the same network upload and run code.
Do not expose the device to untrusted networks. Keep the web UI, the management/registration channel, and any port your app opens on a trusted LAN or VPN, behind a firewall. Do not port-forward the Barionet to the public internet.
Install only packages you trust, and review generated code before deploying it — because it runs as root, treat an app package the way you would treat any software you grant full control of the device. The skill makes the code easy to read for exactly this reason.
Keep the firmware up to date so the device carries the latest Barix security fixes.

Good practice for the apps you build. When you describe an app to Claude, a few habits keep it safe:

Don't hard-code secrets. Put API keys, broker passwords and the like in the configuration form (use a password field), not in the source; ask Claude to do this.
Validate what comes from outside — serial data, network requests, Wiegand reads — and fail safe on unexpected input.
Remember a custom web page or status server the app opens is not authenticated by default. Keep it on a trusted network, and don't put control actions (relays, configuration) on an open port without at least a shared secret.
Avoid logging sensitive values to the LOGS tab or a remote syslog server.

In short: the skill does not weaken the device, but the device's safety in the field is set by your password, your network boundaries, and the packages you choose to install.

10. Support and Limitations

The Barionet Flexa Skill is provided as part of Barix's AI Ready ecosystem. Please note the following support policy:

No code troubleshooting. Barix provides the hardware, the firmware environment and the Claude AI skill, but cannot provide technical support for troubleshooting, debugging or fixing application code — whether it is written by you or generated by AI.
No guarantee of performance. Barix does not guarantee the success, stability or performance of self-programmed applications. The responsibility for the final application's functionality and reliability rests solely with the developer.
Paid support services. Our hardware and standard firmware are backed by the Barix global warranty. Engineering assistance for custom product development or code-specific issues is available as a paid professional service.
Barix terms and conditions apply: https://www.barix.com/terms-and-conditions/

For product information, ordering numbers and the latest list of Flexa-optimised devices, see the Barix Flexa + Claude AI product page.

Don't just build it. Build it on Barix.