Coming in 2027 · The next generation is in development

After 10 years,
TMS is coming back.

COMING IN 2027

The monitoring platform built for the businesses that need it most. Reimagining temperature, humidity and refrigeration intelligence for a connected world.

Stop Wondering. Start Monitoring. • A GEMXIT innovation

24/7 Monitoring vision
IoT + AWS Cloud architecture
RS-485 Planned integration
TMS concept showing refrigeration monitoring dashboard, Raspberry Pi gateway and isolated RS-485 integration
Built for small and medium-sized businesses

No PLC? No SCADA? No problem.

You don't need a PLC or a computer-controlled refrigeration system to know what's happening inside your cool room.

Not every butcher, florist, café, restaurant, seafood business or independent grocer has an industrial control system — and not every business needs one. That's exactly why we're bringing back TMS — Temperature Monitoring System.

TMS is being designed to give businesses straightforward temperature and humidity monitoring, useful historical trends and configurable alerts, whether their refrigeration is controlled by a simple thermostat or a compatible electronic controller.

Know when conditions drift outside your chosen limits, including when you're away from the business. Where a controller provides a documented compatible interface, TMS may also collect additional operating information — without replacing the existing refrigeration controls or safety protections.

Stop Wondering. Start Monitoring.

Register interest for 2027 ↗
Built to see more

More than a thermometer. A smarter way to protect what matters.

The all-new TMS roadmap brings essential environmental monitoring together with deeper refrigeration insight, without the complexity of a traditional PLC or SCADA deployment.

🌡️

Temperature Monitoring

Live readings, historical trends, configurable thresholds and out-of-range notifications for cool rooms, freezers and more.

Core roadmap
💧

Humidity Intelligence

Track environmental conditions and spot changes that could affect flowers, produce, stock and storage quality.

Core roadmap
🔌

RS-485 / Modbus

Planned communication with compatible refrigeration controllers via appropriately isolated RS-485 adapters.

Compatibility dependent
🔔

Smart Alerts

Configurable limits, alert delays, offline-device detection and escalation workflows designed to reduce missed failures.

Core roadmap
☁️

Secure Cloud Platform

AWS-based IoT connectivity, device identity, encrypted communications and access to multiple locations in one place.

Planned architecture
📈

Insights & Control

Equipment trends and diagnostics, with carefully safeguarded remote setpoint controls where supported by the existing controller.

Advanced roadmap
Clarity at a glance

Know what's happening. Wherever you are.

Imagine opening TMS and immediately seeing your cool room conditions, recent trends and equipment status — from a phone, tablet or browser.

Designed around a simple principle: critical information should be immediately understandable, even when you're away from the business.

Be part of the next chapter ↗
Cool Room 01
Illustrative interface concept
● Normal · Demo
Temperature 2.4°C Within example range
Relative humidity 82% Example reading
● Temperature ● Humidity • Concept only, not live telemetry
A new generation of TMS

Your refrigeration intelligence. In your pocket.

A first look at the visual direction for the next TMS mobile experience — live temperature, humidity, equipment status, alarms and trends, wherever you are.

Concept artwork showing the proposed next-generation TMS mobile app with a temperature gauge, humidity monitoring, historical charts and a refrigerated cool room
Next-generation TMS mobile app — concept visualisation. Screens and readings are illustrative, not live product screenshots.
Under the hood

Modern IoT. Practical engineering.

A modular architecture designed to grow from independent sensor monitoring into deeper controller integration.

🌡️
Sensors Temperature & humidity
🖥️
TMS Edge Raspberry Pi gateway, local buffering
🔗
Controller Link Optional isolated RS-485 / Modbus
☁️
TMS Cloud Secure AWS data & alerts
📱
Web & Mobile Dashboards, history & notifications

Controller integrations will require compatible equipment and qualified installation. Existing safety controls remain independent of TMS.

Engineering deep dive / TMS Edge

From refrigeration controller to cloud. See exactly how it works.

A technical look at the proposed TMS integration: isolated RS-485 physical connectivity, Modbus RTU register polling, Raspberry Pi edge processing and secure AWS telemetry. Real implementation patterns, with controller-specific values clearly marked as examples.

01 / Physical connection

Connect a compatible controller's documented RS-485 interface to a galvanically isolated USB-to-RS-485 adapter. The Raspberry Pi acts as the Modbus RTU client. Existing refrigeration control and safety functions remain local.

Existing equipment Refrigeration controller Modbus RTU device address 1 • documented RS-485 A/B terminals
↕   twisted-pair RS-485 A/B
Electrical isolation boundary Isolated USB ↔ RS-485 adapter Manufacturer-specified reference, shielding, bias and termination
↕   USB serial /dev/ttyUSB0
Edge processing Raspberry Pi • TMS Gateway Python polling • timestamps • validation • offline queue
↕   MQTT over TLS
Secure cloud AWS IoT Core → data processing → TMS app Device identity • access controls • alerts • time-series history
Wiring matters: A/B polarity labels vary by manufacturer. Use the controller's exact wiring and communications manual; confirm baud rate, parity, device address, termination and grounding. Installation on live equipment must be undertaken by qualified personnel.

02 / Reading a Modbus register

The gateway sends a Modbus RTU request to a controller address, receives a 16-bit register and decodes it using the manufacturer's register map. This example is read-only and does not alter refrigeration operation.

tms_edge/modbus_reader.py
# TMS Edge — illustrative read-only Modbus RTU polling
# pip install "pymodbus[serial]"
from datetime import datetime, timezone
import json
from pymodbus.client import ModbusSerialClient

client = ModbusSerialClient(
    port="/dev/ttyUSB0", baudrate=9600,
    bytesize=8, parity="N", stopbits=1, timeout=2
)

# DEMO ONLY: register 100 and scale 0.1 are placeholders.
# Replace using the exact controller manufacturer's map.
if not client.connect():
    raise ConnectionError("RS-485 controller unavailable")

try:
    result = client.read_holding_registers(
        address=100, count=1, device_id=1
    )
    if result.isError():
        raise RuntimeError(f"Modbus exception: {result}")

    raw = result.registers[0]
    signed = raw if raw < 32768 else raw - 65536
    telemetry = {
        "device_id": "tms-gateway-001",
        "controller_id": 1,
        "temperature_c": signed / 10.0,
        "timestamp": datetime.now(timezone.utc).isoformat()
    }
    print(json.dumps(telemetry))
    # Next: publish to AWS IoT Core using MQTT over TLS.
finally:
    client.close()
Register 100 , controller ID 1 , serial settings and scaling are illustrative placeholders. Real devices may use different function codes, offsets, signed formats and register layouts. Pin the PyModbus version when deploying.
03 / Multi-controller polling One correctly engineered RS-485 multidrop bus can address several compatible controllers. Each must have a unique address and matching serial configuration.
04 / Resilience and alarms Buffer readings locally during outages, detect stale data, apply alert delays and distinguish communications failures from temperature excursions.
05 / Controlled integration Remote setpoint changes are a future, optional capability: authenticated, authorised, constrained, logged and verified by controller readback. No direct compressor GPIO switching.

Developer reference: PyModbus 3.11 client API . The diagram and code describe a proposed architecture, not a certified installation or a tested controller-specific integration.

Controller integration / manufacturer pathways

Built for more than one brand. Designed around open interfaces.

TMS is exploring integrations with Danfoss, CAREL, Dixell, Eliwell, LAE Electronic and Full Gauge Controls. Support is determined by the specific model, firmware, communications module and documented protocol — not the brand name alone.

Integration candidate / verify model
Danfoss

Some refrigeration controller ranges expose serial communications. Confirm Modbus RTU rather than a proprietary network before selecting hardware.

Integration candidate / verify model
CAREL

Selected refrigeration controller families can offer RS-485 / Modbus via built-in or optional serial interfaces, depending on model.

Additional manufacturer
DIXELL

Investigate controller-specific Modbus interfaces, compatible serial accessories and documented parameter tables.

Additional manufacturer
eliwell

Assess model-specific communication protocols and serial interface availability before developing an adapter.

Additional manufacturer
LAE electronic

Evaluate supported refrigeration models and any serial communication modules or gateway requirements.

Additional manufacturer
FULL GAUGE

Check documented communication protocols and whether a supported gateway or adapter is needed.

Engineering transparency: These are proposed manufacturer integration pathways, not a certified compatibility list or an endorsement by the manufacturers. The brand names above are styled text wordmarks, not official logo artwork. Manufacturer logos can be substituted with approved official assets.
TMS compatibility strategy

Three ways to connect refrigeration equipment

Connection When TMS uses it Engineering requirement
Native Modbus RTU Controller explicitly supports Modbus over RS-485 Isolated adapter, verified register map, bus commissioning
Manufacturer gateway Controller uses a proprietary serial or network protocol Approved gateway/API, vendor documentation and permissions
Independent sensors Controller has no supported data interface Dedicated calibrated temperature / humidity probes connected to TMS Edge
Danfoss / confirmed manufacturer documentation

Danfoss programming versus TMS integration

KoolProg is a Danfoss configuration and service tool for supported refrigeration controllers; it is not a general-purpose programming language or proof that a controller exposes a third-party Modbus interface. TMS Edge would normally be developed in Python , using a documented protocol and verified register profile without modifying Danfoss firmware.

Controller / tool What official documentation establishes What TMS must verify
AK-CC55 Compact Danfoss publishes a Modbus RTU programming guide and parameter list; documented default serial framing is 8 data bits, even parity, 1 stop bit; baud rate defaults to auto detection. Exact product code, firmware, RS-485 connection, network address, baud-rate negotiation and the matching register map
AK-CC55 Single / Multi Coil Part of the AK-CC55 family, but software and integration details vary by variant. Obtain the specific variant's guide; do not reuse the Compact map without validation
ERC / EET and other ranges Some are configurable using KoolProg and KoolKey or a manufacturer gateway. Confirm whether any accessible port actually supports an approved third-party data protocol; do not assume the service connector is standard RS-485 Modbus

Important: The Danfoss AK-CC55 Compact serial defaults above are documented for that controller; they are not universal Danfoss defaults. TMS examples elsewhere on this page use fictional registers and different illustrative serial settings. Never attach an arbitrary RS-485 adapter to an undocumented programming port. Keep monitoring read-only until a model-specific integration has been commissioned.

Official references: AK-CC55 Compact Modbus programming guide (PDF) · Danfoss KoolProg · KoolProg user guide (PDF) .

01 / Danfoss

Danfoss refrigeration controllers

For compatible Danfoss models with a documented Modbus RTU interface, TMS would poll the controller's exposed measurements and status registers using a dedicated profile for that model.

  • Confirm the exact controller model , firmware and supported communication module.
  • Verify whether its serial port is Modbus RTU or a different Danfoss protocol.
  • Map documented temperature, setpoint, alarms, relay states and defrost parameters.
  • Read first; validate scaling, signed values and status bitmasks against the controller display.
Danfoss AK-CC family variants can differ in interface and protocol. A Danfoss-branded controller is not, by itself, proof of Modbus RTU support. Use the specific model's official documentation.
02 / CAREL

CAREL refrigeration controllers

For compatible CAREL models, a TMS integration profile would decode the manufacturer's documented Modbus register table, including any optional serial interface requirements.

  • Identify the exact CAREL model (for example, a compatible ir33 or other supported series).
  • Check whether an RS-485 interface card or serial accessory is required.
  • Configure address, baud rate, parity and supported function codes.
  • Validate engineering units, register offsets, alarm states and supported operations.
CAREL controller families and optional interface boards vary. Register addresses in the examples below are placeholders, not CAREL or Danfoss register assignments.
Wiring / site commissioning

Physical connection checklist

Controller RS-485 A/B → twisted-pair bus → galvanically isolated USB-to-RS-485 adapter → Raspberry Pi USB. Follow manufacturer guidance for reference conductor, cable shield, biasing and termination. Avoid star wiring on a multidrop bus.

For multi-controller deployments, assign unique slave IDs and poll each device sequentially. Keep refrigeration protection and fail-safe control entirely within the existing controller.

Protocol / commissioning

From bytes to trustworthy telemetry

A Modbus read returns raw registers. TMS must apply the controller-specific address convention, register type, byte/word order, signed encoding, scale factor and validity checks before storing a temperature or alarm state.

Connectivity failures should be reported as stale / unavailable , never silently displayed as healthy readings.

Open engineering approach

Actual Python patterns. From Modbus RTU to AWS IoT.

These implementation examples show the proposed TMS Edge software design. They are not live-tested against a specific Danfoss or CAREL controller. Replace every model-dependent field with verified values from its register documentation.

Controller Modbus RTU slave
Isolated adapter RS-485 A/B ↔ USB
Raspberry Pi PyModbus + validation
AWS IoT Core MQTT over mutual TLS
TMS App History + alerts
Python / controller profile

Read-only polling with a model-specific register map

Use a configuration profile for each verified controller. The addresses and scaling below are deliberately fictional to prevent accidental use on live refrigeration equipment. The serial settings shown are illustrative, not Danfoss defaults; confirm baud rate, parity and stop bits from the exact controller documentation.

tms_edge/controller_reader.py
from datetime import datetime, timezone
from pymodbus.client import ModbusSerialClient

# EXAMPLE ONLY: replace with the official register map
PROFILE = {
    "model": "verified-controller-model",
    "unit_id": 1,
    "room_temp": {
        "address": 100,  # FICTIONAL, NOT a vendor address
        "scale": 0.1,
        "signed": True,
    },
}

def decode_word(raw, signed=False):
    if signed and raw >= 0x8000:
        return raw - 0x10000
    return raw

client = ModbusSerialClient(
    port="/dev/ttyUSB0",
    baudrate=9600, parity="N", stopbits=1,
    bytesize=8, timeout=2,
)

try:
    if not client.connect():
        raise ConnectionError("RS-485 adapter unavailable")

    reg = PROFILE["room_temp"]
    reply = client.read_holding_registers(
        address=reg["address"], count=1,
        device_id=PROFILE["unit_id"],
    )
    if reply.isError():
        raise RuntimeError(f"Modbus error: {reply}")

    raw = decode_word(reply.registers[0], reg["signed"])
    payload = {
        "controller": PROFILE["model"],
        "temperature_c": raw * reg["scale"],
        "timestamp": datetime.now(timezone.utc).isoformat(),
        "quality": "sample_read_only",  # Not yet validated against a real device
    }
    print(payload)
finally:
    client.close()
Example targets the PyModbus 3.11-style API (install with serial support, e.g. pip install "pymodbus[serial]==3.11.1" ). This is a single-read demonstration, not a production polling service. Confirm function code, register addressing, scaling and data format from the exact controller manual; apply range, stale-data and fault checks before declaring any measurement valid.
Python / secure cloud telemetry

Publish verified readings to AWS IoT Core

The gateway uses its own provisioned device certificate and private key to authenticate to AWS IoT Core. MQTT payloads include device identity, measurement time and quality status.

tms_edge/aws_publish.py
# pip install paho-mqtt
import json
import os
import ssl
import paho.mqtt.client as mqtt

ENDPOINT = os.environ["AWS_IOT_ENDPOINT"]
THING_ID = os.environ["TMS_THING_ID"]
TOPIC = f"tms/{THING_ID}/telemetry"

# Paths to securely provisioned device credentials
CA = "/etc/tms/certs/AmazonRootCA1.pem"
CERT = "/etc/tms/certs/device.pem.crt"
KEY = "/etc/tms/certs/private.pem.key"

client = mqtt.Client(
    callback_api_version=mqtt.CallbackAPIVersion.VERSION2,
    client_id=THING_ID,
    protocol=mqtt.MQTTv311,
)
client.tls_set(
    ca_certs=CA,
    certfile=CERT,
    keyfile=KEY,
    cert_reqs=ssl.CERT_REQUIRED,
    tls_version=ssl.PROTOCOL_TLS_CLIENT,
)

telemetry = {
    "device_id": THING_ID,
    "temperature_c": 2.4,
    "quality": "sample_read_only",  # Not yet validated against a real device
    "source": "modbus_rtu",
}

client.connect(ENDPOINT, port=8883, keepalive=60)
client.loop_start()
try:
    result = client.publish(
        TOPIC, json.dumps(telemetry), qos=1
    )
    result.wait_for_publish(timeout=10)
    if not result.is_published():
        raise TimeoutError("MQTT publish not confirmed")
finally:
    client.disconnect()
    client.loop_stop()
Illustrative telemetry only. Production TMS would include durable offline queuing, reconnect/backoff, credential rotation, device-specific IoT policies and cloud-side validation.
JSON / device configuration

Controller profiles make integrations maintainable

Each controller integration should ship with a versioned, verified profile rather than hard-coded assumptions shared across manufacturers.

profiles/example-controller.json
{
  "vendor": "EXAMPLE_ONLY",
  "model": "VERIFY_EXACT_MODEL",
  "protocol": "modbus_rtu",
  "serial": {
    "baudrate": 9600,
    "parity": "N",
    "stopbits": 1,
    "slave_id": 1
  },
  "registers": {
    "room_temperature": {
      "address": 100,
      "function": "holding",
      "signed": true,
      "scale": 0.1,
      "unit": "celsius"
    }
  },
  "read_only": true,
  "verified_against_manual": false
}
This example is intentionally not a Danfoss or CAREL register map. A profile must be verified and tested before being enabled for a customer's equipment.
Safety / control-plane design

How remote setpoint requests would work

App → authenticated API → policy validation → signed/authorised cloud command → gateway → controller. The gateway checks the device model, approved parameter, permitted range, freshness and command expiry before any write.

  • Default to read-only integrations.
  • Require role-based access and audit logs for every requested change.
  • Verify controller readback after a write; show failure if unconfirmed.
  • Rate-limit and expire commands; reject requests when communications are stale.
  • Never bypass compressor protection, defrost logic or safety interlocks.
Remote writes are an advanced roadmap feature, not enabled by the examples on this page. Qualified commissioning and controller-specific approval are essential.

References: PyModbus · AWS IoT protocols · Danfoss · CAREL . Consult model-specific official technical manuals for protocol support and register maps.

Made for real businesses

Enterprise thinking. Small-business simplicity.

From a single freezer to multiple locations, TMS is being designed for businesses that need dependable visibility without industrial-system complexity.

🐟 Fish & chip shops
💐 Florists
🥩 Butchers
☕ Cafés & restaurants
🛒 Grocers
A decade in the making

The original idea never went away.

About 10 years ago, we built TMS using Raspberry Pi hardware, AWS infrastructure and a dedicated mobile app. It gave small businesses visibility into their refrigeration temperatures, alarms and historical data.

We loved building it. But the product never found its commercial footing, and eventually it was put on the shelf.

Now we're bringing it back. Same mission. New technology. Bigger possibilities.

The rebirth starts here

Be there when TMS returns in 2027.

We're exploring the next generation of affordable environmental and refrigeration monitoring. Interested in a pilot, a partnership or updates on development? We'd love to hear from you.

Register Your Interest ↗

TMS 2.0 is in planning and development, with a target launch in 2027. Features and timing are subject to change.