Build industrial IoT and device software

Our industrial IoT software for energy sites runs on a controller at the site. It reads batteries and inverters over Modbus, decides what the storage should do and reports to the cloud over MQTT or Azure IoT Hub. The energy side of this work, from the energy management system (EMS) to trading and flexibility, is covered on our Energy Hub.

IIoT solutions we have built for energy

• Skyfri: the EMS behind a portfolio of solar and battery sites. It decides when batteries charge and discharge, runs peak shaving and energy trading, and works with batteries and inverters from several manufacturers. Energy meters on the grid, battery and solar side feed its data pipelines. From June 2024 it ran across 7 plants and controlled more than 5 MWh of storage capacity and more than 4 MW of battery power.
• Zeronest: an EMS platform for home solar and storage that we have built since January 2024. It works with 16 inverter brands through Zeronest's own devices, the Bzyk D200 and the Świetlik D300, wired to each inverter over RS485 and Modbus. The device reports over LTE, independent of the manufacturer's cloud and the homeowner's Wi-Fi, and talks to AWS IoT Core over MQTT and TLS 1.2, with client data staying in the EU. Every minute the platform decides whether a home battery charges, discharges or sells to the grid, and installers work in a dedicated app. As of April 2026 it served more than 3,000 prosumer storage installations.
• Global Green: a PV and battery storage operator in Germany and Canada. Since December 2025 we have built the software on the controller next to its batteries and in the cloud, across 15 MWh of storage. It covers Modbus register maps for batteries from two manufacturers, MQTT, a trading controller, commands from the distribution system operator and aFRR (automatic frequency restoration reserve) balancing. A device simulator in AWS tests the control logic before it touches storage on a site.
• KYOTO: three and a half years of industrial IoT and digital twin work for Kyoto Group's thermal energy storage. We took a UX/UI MVP to a SCADA-based system that monitors and controls the flow of energy in real time, with a digital twin layer for weather data, energy price analysis and plant performance simulation. In 2024 our scope added secure cloud infrastructure that connects the devices, sensors and systems of the solar plant and the thermal storage. A management system for the molten salt heat store steers valves, pumps and the flow of hot liquids. Surveillance with infrared cameras and image recognition alerts staff to hazards.

Earlier projects with AP-TECH

Our earlier work with partner AP-TECH includes the airport systems Monster (lighting management) and ATOS (tracking of aircraft and airport vehicles).

More project detail is in our industrial IoT examples, and the terms are explained in our IoT glossary.

At Global Green the controller next to the batteries reads three channels over Modbus from a local device of the trading partner: the requested power, a flag that says whether the request is valid, and a life counter, a heartbeat that keeps changing while the link is up. While the request is valid and the link is alive, the controller sends the batteries an active power setpoint every cycle, for charging and for discharging alike. A request for 0 kW counts as a valid request.

Holding the last valid request

The link counts as lost when the life counter stops changing for longer than a configured threshold. From then on the controller holds the last valid request until the end of the current 15-minute window (UTC) and returns to idle afterwards. In an example from the requirements, the link drops at 13:06:07, the controller holds 500 kW until 13:14:59 and issues no command from 13:15:00. When the link returns, fresh data replaces the held request at once.

The setpoint is capped by the limits that are active on the controller.

Maintenance of an industrial IoT system starts with knowing when a device has gone quiet and catching a fault before the customer calls.

Warnings and errors, active and archived

The alert module of the Zeronest platform splits events into warnings and errors, active and archived, with one global list for all installations. The alerts let the team reduce the number of service visits. The guard tour platform described below plans patrols and maintenance routines and raises an alert when a schedule is breached.

Data quality at the device and in the pipeline

Zeronest treats a device that sends no data packet for longer than a set time (120 seconds by default) as offline. When production jumps above a threshold (400 W by default), the values from the last meter packet are not passed on. Two more alerts watch the pipeline: one fires when the job that processes modem data fails 4 times within an hour, the other when the newest data in the database is older than 20 minutes.

Once a day the platform reads an inverter's configuration registers, writes them and reads them again, and raises an alert when the value read back differs from the one written. An installation changes its status to running only after the first correct reading from the inverter, and the initialisation of devices runs in stages that are shown separately. Data can be exported to CSV as energy aggregated every 15 minutes or every hour, or as raw readings.

Forecasts on top of the data

The Zeronest app shows how the storage is predicted to behave until the end of the day, the predicted consumption and production, and the saving in zloty that follows from them. The backend calculates the forecast for the next day from the statistics of day-ahead market tariff prices and updates it after the hourly aggregate is recalculated.

Access and security of the system

Zeronest's web panel is multi-tenant: data is separated between organizations, and permissions have two levels, so a manager sees all installations of the company and an installer only the ones assigned. Users sign in with a one-time six-digit code; password login was switched off in January 2025.

In the field the conditions set the design: a site with no signal, or a scanner that must not lose a scanning session. Custom IoT development for field hardware connects the devices people carry or install on site to the apps and back-office systems that depend on them.

Checkpoints read by QR codes, NFC tags and beacons

Since 2021 we have built a client's SaaS platform for guard tours. It manages inspections, service tickets and audit documentation in facilities through a web and a mobile app that keeps working offline and syncs when it reconnects. Guards confirm checkpoints by scanning QR codes, NFC tags or iBeacons, and paths plan patrols and complex maintenance and inspection patterns. The integration with tracking devices over TCP/IP grew from a prototype into a solution in use. The platform's clients operate in Poland, South Africa and Australia.

Scanners and logistics

For a wholesaler of products covered by the EU tracking system we build an Android app for industrial handheld scanners. Workers scan packs, cartons and pallets when goods arrive, when they leave against an invoice, when they are moved and in other events. The backend processes each type of session and registers it at the right moment in the central router of an EU institution. It is also the API of the app and an admin panel for verifying data and submissions.

In the background, tasks fetch the customer's documents (invoices, corrections and payments) over SFTP. After each session is submitted, the result comes back to the scanner: accepted, accepted conditionally or rejected with a list of codes. The app integrates the Datalogic and Zebra scanner SDKs, with support for the Zebra MC3300X added in January 2024 and for the Datalogic SDK in 2026, and buffers scanning sessions when the network drops. The app is written in Kotlin, and the backend runs on Django and Celery.

Every engagement starts with a free discovery workshop. It is the basic discovery: one meeting after which you have a scope, an estimate and a basic mockup or proof of concept that shows what the build will cost. In it we map the hardware and who makes it, the protocols it speaks, what has to keep working offline, how updates reach the device and where the security boundaries sit. Extended discovery, with the full set of artifacts, is a separate and wider scope.

From the workshop to a specification

Skyfri shows what can follow the workshop. Before we built the EMS, a Technical Feasibility Study ran from 20 November 2023 to 7 January 2024: seven weeks that produced a feasibility study and a technical specification. The architecture and the implementation of the EMS started in January 2024.

Requirements before code

At Global Green every function gets a requirements document with acceptance criteria and open questions, linked to its task; the trading controller is one example. Register maps of the devices are prepared before the code is written.

Long-term support

Hardware stays in the field for years, so the software around it has to follow new device models and new Android versions. On RAW Cyber, keeping RAW OS in step with Copperhead's changes and with new hardware was a workstream of its own. When Copperhead moved to Android 11, we merged our changes into Android's framework code and finished the move in September 2021. What building on the Android Open Source Project means for updates and security patches is in our AOSP entry.