The Next S-Curve · Machine Intelligence

We make machines
talkable.

For fifty years machines obeyed commands. The next curve is different — machines that explain, negotiate, and converse. IONECT builds the products and services that give any machine that capability.

Vision
Every machine, conversational
Stack
Silicon → Cloud → Language
Starting with
EV chargers · IoT fleets next
EV Charger · Bay 04

"Cable temperature is 62 °C. I'm derating to 38 kW until it cools."

Solar Inverter

"Forecast says clouds at 14:00. Want me to pre-charge batteries?"

Battery ESS · Site 12

"Peak is in 42 minutes. I'll cover 180 kW from storage — you'll save ฿3,400."

Fleet Operator

Show me any station below 90% uptime this week.

The Vision · An S-Curve

Machines had hands.
Then they had eyes.
Now they get a voice.

Every generation of automation rides an S-curve. Mechanical arms gave machines muscles. Sensors and vision gave them eyes. We are at the foot of the next curve — the one where machines understand language, hold a conversation, and explain themselves. IONECT exists to accelerate that curve and to build the products that live on top of it.

From control to conversation

A conceptual map of three overlapping eras of machine capability — illustrative, not to scale.

Mechanical Perception Talkable
PAST FUTURE Mechanical era muscles · control · logic Perception era eyes · sensors · telemetry EARLY DAYS Talkable era voice · reasoning · dialogue
Era 01 · The past
Controllable

Machines do what we tell them. Press a button, turn a valve, execute a program. The language is binary — commands in, state out.

Era 02 · The present
Observable

Machines report what they see. Sensors, cameras, telemetry — dashboards full of numbers. Humans still do all the thinking.

Era 03 · Emerging
Talkable Now

Machines explain, negotiate, propose. They speak our language and reason about their own. This is the curve IONECT builds on.

Why Talkable

A dashboard tells you what.
A talkable machine tells you why.

Every industrial operator today drowns in dashboards. Graphs. Numbers. Colour-coded alerts. The information is there — but a human still has to connect the dots. Talkable machines close that gap. They don't just report; they explain, recommend, and act.

Before · today

Dashboards and alerts.

09:42:11[2,"a4f1","StatusNotification",{connectorId:4,errorCode:"HighTemperature",status:"Faulted"}]
09:42:11[2,"a4f2","StopTransaction",{transactionId:8821,reason:"Other",meterStop:14820}]
09:42:48[2,"a4f7","MeterValues",{connectorId:4,value:"78.2",measurand:"Temperature"}]
09:43:02[2,"a4fa","StatusNotification",{connectorId:4,errorCode:"HighTemperature",status:"Faulted"}]
09:44:18[2,"a503","StopTransaction",{transactionId:8829,reason:"Other"}]
09:45:30[2,"srv01","RemoteStopTransaction",{transactionId:8829}]
09:47:00[2,"a511","StatusNotification",{connectorId:4,errorCode:"HighTemperature",status:"Faulted"}]

This is a typical machine communication log — the kind of system messages, process events and protocol traffic every connected device produces. It tells you what happened, not why. Operators have to read the stream, cross-reference manuals, check the values and call a technician to interpret it. The machine itself stays silent.

After · talkable

A machine that explains itself.

OPSWhat's happening with the EV charger at Sukhumvit Soi 24, Bay 04? Drivers are complaining.
BAY 04Three sessions in the last five minutes have aborted on the AC connector with a HighTemperature fault. The cable hit 78.2 °C just before each abort — above the 70 °C safety threshold. Your back-office remote-stop at 09:45 didn't recover it; the connector is still latched faulted.
OPSWhy is it overheating, and what should I do?
BAY 04Most likely a worn AC connector — the same pattern hit your Phra Khanong site last month and a cable swap fixed it. In the meantime I can cap this bay at 22 kW, which keeps cable temperature under 60 °C. You'd lose roughly 8% of revenue on this bay but avoid further safety trips. Want me to schedule a technician for tomorrow 10:00?

The operator asks in plain language. The machine reads its own communication log, correlates the events, explains the root cause, and proposes a concrete next step for a human to approve — minutes instead of hours, no protocol decoding required.

What We Build

Four capabilities that turn
a machine into a conversation partner.

Four building blocks — designed to be added step by step. Start with the foundation, layer in context, then reasoning, then conversation. Each one stands alone; together they make a machine talkable.

01 / Foundation

Machine self-awareness

The first step. The machine has structured access to its own protocols (OCPP, Modbus, proprietary), its firmware version, its error codes and its maintenance history — so questions about itself are answered from real data, not guesswork. This is the data foundation everything else stands on.

OCPP 1.6 / 2.0.1ModbusMQTTFirmware-aware
02 / Context

Context & unstructured understanding

Layer in the human-written context. PLCs and historians log structured data well — registers, alarms, timestamps. What they cannot do is read the manual, parse a vendor's release notes, or interpret a free-text fault description. We build a knowledge base of manuals, firmware notes, fault history and operator playbooks — so the machine can connect structured telemetry to unstructured documents and explain the root cause in plain language.

Manuals · PDFsFault historyOperator playbooksRoot-cause in plain language
03 / Reasoning

Reasoning & recommendation

Now the machine can propose. It weighs trade-offs — revenue vs safety, comfort vs cost, now vs later — and recommends an action for a human to approve. Autonomy is opt-in, scoped, and always bounded by safety policies you control.

Agent loopsTool-useHuman-in-the-loopPolicy guard-rails
04 / Conversation

Voice & language interface

Finally, expose it to humans. Operators, technicians and drivers speak to the machine in plain English or Thai across chat, voice or app. Under the hood, an LLM grounds every answer in the foundation, context and reasoning layers below — designed to minimise hallucinations and cite the data behind every response.

LLMRAGEN · THVoice · Chat · App
How It Works

Five layers turn a silent machine
into a talkable one.

We can build at every layer of the stack — but every engagement is different. Some pieces we bring off the shelf, others we custom-build for your machines, your protocols and your operators. The point is end-to-end coverage with no vendor seams.

01
Data ingestion
The body
We pull from wherever the data lives — OPC-UA, PLCs, dataloggers, embedded firmware on the device, EV chargers direct via OCPP, or indirect through an existing CSMS or SCADA. Whatever the source, we normalise it into a single event stream.
Ingest
02
Protocol gateway
The nervous system
OCPP, Modbus, OCPI, MQTT — we translate every industrial dialect into a common event stream. Every heartbeat becomes a sentence the AI can understand.
Protocol
03
Context & memory
The identity
A knowledge base of the machine's own manuals, firmware notes, fault history and operator playbooks. This is what grounds every answer in reality.
Knowledge
04
Reasoning engine
The mind
LLM plus a guarded agent loop. Analyses the stream, plans an action, checks it against safety policies, then either recommends it to an operator or — within scopes you define — writes back.
AI · Agent
05
Conversation surface
The voice
Chat, voice, white-label app, SMS, line, whatever channel your operators live in. Same machine, same memory, every surface.
UX
What You Can Buy

Products and services that
make your machines talkable.

Buy a product. Commission a service. Or both — we design for whichever shape fits your operation.

Product · Platform

Talkable EV charging platform

A white-label CSMS where operators, drivers and technicians interact with chargers through conversation as well as the dashboard. OCPP-native and operating in pilot deployments.

  • White-label operator console
  • In-app driver conversations
  • Self-diagnosing chargers
  • Protocol: OCPP 1.6 / 2.0.1
Product · Edge · Roadmap

Talkable gateway

An IoT gateway designed to bring legacy fleets — chargers, ESS, HVAC, generators — onto the conversational layer. Reference designs in development; available for design-partner engagements.

  • Modbus · OCPP · BACnet · MQTT
  • Edge inference for low latency
  • OTA firmware, signed & secure
  • Works with your existing SCADA
Service · Build

Custom talkable product

Your hardware, your brand, your domain. We co-design the conversation, write the firmware glue, build the context layer, and ship a product your customers can talk to — across chat, voice or app.

  • Discovery & conversation design
  • Embedded + cloud engineering
  • Voice / chat / app front-ends
  • Run & maintain, or hand off
The Foundation

We didn't pivot into this.
We were built for it.

Making a machine talk is not an AI problem. It is a full-stack problem — silicon, protocols, cloud and language, all the way through. We have spent seven years assembling exactly that stack.

7yrs
Industrial protocols, deep
OCPP 1.6 / 2.0.1, OCPI, Modbus, BACnet, Profinet, Profibus and more — we deep-dive each protocol and write the ingestion layer from scratch when a custom fit is needed.
4layers
Full vertical stack
Sensor & PLC programming, embedded firmware, IoT gateway, cloud platform, AI reasoning — ground level to language model, one team, no seams.
Cloud+Edge
Grounded AI, hybrid by design
Heavy reasoning runs in the cloud; the device handles fast, deterministic actions — a balanced architecture that's safe to deploy today.
EV→ next
Beyond EV
EV today; ESS, solar, HVAC and manufacturing on the roadmap. The stack is designed to be machine-agnostic.
Let's Build

Which of your machines
should learn to talk first?

Tell us about the machine, the operator, and the job to be done. We'll come back with a conversation flow, a candidate stack, and a plan tailored to your scope.

The talkable curve is moving fast — first movers shape the conversation.