Originally built in 2016 · TMS 2.0 planned for 2027

Stop Wondering.
Start Monitoring.

Temperature, humidity and refrigeration monitoring for Australian small businesses. Receive alerts, track trends and gain visibility into refrigeration systems from anywhere.

MONITOR • MANAGE • RESPOND

Stop Wondering. Start Monitoring. • A GEMXIT innovation

24/7Monitoring
IoT + AWSCloud architecture
RS-485Controller integration
TMS showing refrigeration monitoring dashboard, Raspberry Pi gateway and isolated RS-485 integration
Why TMS exists

What happens when your cool room fails at 2:00am?

Most businesses do not discover refrigeration problems until somebody opens the door the next morning. TMS is being developed to provide visibility before small issues become costly stock losses.

📉

Lost Stock

Temperature excursions can lead to spoiled inventory, lost revenue and unnecessary waste.

🔔

Early Warning

Receive notifications and monitor trends so problems can be identified sooner.

📱

Anywhere Visibility

View conditions, trends and alerts from your phone, tablet or browser.

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 why we’re bringing back TMS — Temperature Monitoring System.

Building on the original TMS monitoring platform, TMS 2.0 is being developed to provide temperature and humidity monitoring, historical trends and configurable alerts, whether refrigeration is run by a simple thermostat or a compatible electronic controller. Where a controller provides a documented compatible interface, TMS may also collect additional operating information, without replacing the existing refrigeration controls or safety protections.

Contact Us ↗
Built to see more

More than a thermometer. An instrumented, security-focused telemetry platform.

TMS brings environmental monitoring together with deeper refrigeration insight, without the complexity of a traditional PLC or SCADA deployment.

🌡️

Temperature Monitoring

Time-stamped readings, quality flags, historical trends, configurable thresholds and out-of-range events for cool rooms and freezers.

Core TMS Technology
💧

Humidity Intelligence

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

TMS 2.0 Enhancement
🔌

RS-485 / Modbus

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

Compatibility Dependent
🔔

Smart Alerts

Proposed SMS and email notifications, alert hysteresis, acknowledgement, escalation and cloud-side missing-heartbeat detection.

Advanced Alerts Planned
☁️

Secure Cloud Platform

AWS-based IoT connectivity with a security roadmap covering device identity, encrypted cloud communications and controlled multi-location access.

AWS Security Architecture
📈

Monitoring, Management & Control

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

Where Supported
Connectivity engineering · Event delivery · Time-series integrity

Assume the network will fail. Design so the data does not.

TMS 2.0 is being designed around a resilient edge-to-cloud pipeline: local acquisition, timestamped storage, optional cellular connectivity, delayed synchronisation and independently evaluated alarms. These are proposed capabilities undergoing engineering and validation, not a guarantee of uninterrupted monitoring.

📶

Optional 4G LTE failover

Where a supported cellular modem or router and active data SIM are installed, TMS Edge is intended to detect primary WAN failure and transition to a cellular uplink. Recovery includes route preference, link-health checks, backoff and controlled return to the primary connection.

Network Continuity
💾

Durable edge buffering

A local persistent queue is proposed to retain validated observations during outages. Each sample carries an acquisition timestamp, device identity, sequence number and quality indicator. Reconnection triggers bounded replay with duplicate detection and acknowledgement tracking.

Store & Forward Architecture
📲

SMS and email alerts

Configurable thresholds, dwell times, hysteresis, escalation and recovery notices are proposed, with Amazon SNS and Amazon SES as candidate delivery services. Alert state, acknowledgement and delivery attempts are separate audit events.

Intelligent Notifications
📚

Historical data logging

Proposed time-series records preserve measurement time and ingestion time, calibrated units, source, quality and event provenance. Reporting can include trends, exceptions, CSV export and retention-controlled archives.

Historical Data Integrity
🫀

Heartbeat and stale-data detection

Cloud-side watchdogs are intended to identify missing device heartbeats even when the gateway cannot communicate. Sensor disconnects, impossible values and expired readings are explicitly marked unavailable rather than silently presented as normal.

Continuous Health Monitoring
🔋

Power-loss resilience

Optional UPS-backed gateway and network equipment can reduce interruptions. Local alarms, cellular backup and cloud notifications have distinct power and network dependencies; no alert channel is represented as infallible.

Power Resilience
01 / Acquire Sensor + controller

Validated measurements, monotonic sequence IDs and UTC acquisition timestamps.

02 / Persist Edge durable queue

Local write-ahead persistence; stale and invalid observations remain distinguishable.

03 / Transport Primary WAN → optional LTE

Connection health, exponential backoff and encrypted MQTT publication.

04 / Reconcile Cloud ingestion

Idempotent processing, ingestion timestamps, retention and alert evaluation.

Failure scenario Proposed response Important limitation
Wi-Fi or fixed internet unavailable Switch to optional 4G LTE if provisioned; buffer until acknowledged Cellular coverage, SIM plan and power still required
Both uplinks unavailable Continue local collection where power and storage permit; retry later Cloud SMS/email delivery cannot be assumed during total isolation
Gateway stops reporting Cloud-side missing-heartbeat alert Detection delay and alert-provider availability apply
Out-of-range temperature Threshold + dwell + hysteresis; notify and escalate according to policy Sensor accuracy, sampling cadence and recipient delivery affect response
Delayed replay after outage Preserve original timestamps; deduplicate on device + sequence Backfilled measurements must not masquerade as live readings

Design status: 4G failover, SMS/email delivery, local durable queueing and cloud reconciliation are TMS 2.0 engineering targets. The original TMS was a working product; this section does not claim that every new feature is implemented or tested. Final behaviour depends on gateway hardware, commissioned configuration and third-party services.

Security by design · TMS 2.0

Your refrigeration data. Protected by design.

TMS 2.0 is being engineered with cybersecurity at its core. Our security roadmap covers encrypted cloud communications, protected data storage, authenticated devices, secure customer access and independently constrained remote-control commands.

Encrypted Communications

Gateway-to-cloud telemetry and application connections are designed to use authenticated TLS encryption, with TLS 1.3 preferred where supported.

Secure Communications

Encrypted Data Storage

Cloud records and backups are designed to use encryption at rest, managed key access, retention policies and tested recovery procedures.

Data Protection

Secure Login & MFA

Individual user accounts, multifactor authentication, secure sessions and account recovery controls will help prevent unauthorised dashboard access.

Identity & Access Security

Trusted Device Identity

Each Raspberry Pi gateway is intended to have a unique device identity and certificate-based authentication, with narrowly scoped permissions.

Device Authentication

Role-Based Access

Administrators, managers and viewers will have distinct permissions, with customer data isolated between organisations and locations.

Least-Privilege Access

Monitoring & Audit Trails

Security events, configuration changes and any authorised remote-control requests are intended to be recorded and monitored for suspicious activity.

Security Monitoring
How secure TMS works

From your screen to the refrigeration controller

A proposed defence-in-depth architecture for authenticated monitoring and tightly controlled remote adjustments.

📱 TMS Web Dashboard & Mobile App Individual accounts · MFA / passkeys · Approved user roles
Authenticated HTTPS / TLS
☁️ TMS Cloud on AWS Tenant isolation · Encrypted storage · Command approvals · Audit trails
Mutually authenticated, outbound-initiated device connection
🖥️ TMS Edge Gateway Unique device identity · Hardened software · Local telemetry and command checks
Locally verified control request
🛡️ Independent Local Command Safety Gate Separate trusted enforcement · Approved registers only · Commissioned setpoint limits · Reject unsafe or expired requests
Isolated RS-485 / Modbus RTU — local link is not encrypted
❄️ Refrigeration Controller Local refrigeration logic and independent safety protections remain in control

Conceptual architecture, not a deployed system diagram. Telemetry travels back through the gateway to the cloud. The independent command gate is a proposed additional component, not a feature of a standard USB-to-RS485 adapter.

Protecting the refrigeration process

Security goes beyond passwords and encryption.

Safe Remote Control

Only commissioned, model-specific setpoint adjustments are proposed for remote control. Arbitrary Modbus writes, safety overrides and forced defrost are excluded from the initial release.

Operational Safety

No Exposed Gateway Ports

Gateways are designed to initiate secure outbound connections, with segmented networks and no routine public inbound management access.

Network Hardening

Verified Software Updates

Signed update packages, controlled deployment, vulnerability management and recovery procedures are planned to reduce tampering and downtime.

Software Integrity

Threat Detection & Isolation

Unusual logins, unexpected device activity and rejected control commands can trigger alerts and credential revocation, while local refrigeration remains independent.

Threat Detection & Response

Command Accountability

Remote changes are designed to require the right permissions, fresh approval, bounded values, controller readback and a traceable audit record.

Auditing & Accountability

Tested Before Deployment

Our release plan includes security testing, simulated attack scenarios, communications-failure tests and independent refrigeration safety review.

Security Validation
Safety-first remote control: Remote changes will be disabled unless the exact controller, register profile, installation limits and independent protections have been validated. Internet or TMS failures must not prevent the refrigeration controller from operating locally. No connected system can be guaranteed immune to attack.
Security boundary: Standard Modbus RTU over RS-485 and directly wired sensors do not provide native encryption. TMS Edge will protect these local interfaces through physical access restrictions, gateway hardening and network isolation; encrypted communication begins at the gateway-to-cloud connection. The isolated RS-485 adapter provides electrical isolation, not cryptographic protection.

Built for monitoring and carefully controlled operation. Engineered for security.

Developed by GEMXIT, TMS 2.0 brings refrigeration monitoring and industrial IoT together with a security-focused architecture. Security controls described here are design objectives for the 2027 release and will be validated before production deployment; they are not a claim of completed security certification or an end-to-end encrypted Modbus link.

Ask about TMS security ↗
GEMXIT security engineering · AWS reference architecture

Zero implicit trust. Identity-bound telemetry from edge to cloud.

Our proposed AWS security architecture applies defence in depth across device provisioning, transport, cloud ingestion, tenant access, operations and incident response. A secure architecture is not a security certification: controls must be implemented, configured, monitored and independently tested.

Device planeUnique X.509 identities

Per-gateway credentials, restrictive IoT policies, certificate revocation and secure provisioning.

Transport planeMutual TLS + MQTT

AWS IoT Core certificate authentication, broker authorisation and device-scoped topic namespaces.

Data planeValidated ingestion

Schema checks, timestamp sanity, idempotency, per-tenant isolation and encryption at rest.

Operations planeAuditable administration

Least-privilege IAM, MFA, change logging, threat detection, backups and recovery drills.

Identity, authentication and policy

AWS IoT Core X.509 client certificates, explicit iot:Connect and iot:Publish permissions, certificate lifecycle management and device-bound MQTT client identifiers. IoT policy scope is separate from IAM policy scope.

Customer and tenant isolation

Every API request is authorised server-side against tenant and site membership. Storage keys, query filters, export jobs and alert recipients must enforce tenant boundaries. Client-supplied tenant IDs are never treated as authorisation.

Encryption and key management

Transport encryption, encrypted storage and managed key controls using AWS KMS where supported and appropriate. Secrets are not embedded in frontend code or source control; device private keys require protected provisioning and filesystem permissions.

Audit, detection and response

AWS CloudTrail for supported AWS API activity, CloudWatch metrics/logs, IoT operational logs and optionally AWS IoT Device Defender audits. Define alert ownership, log retention, credential revocation and incident response runbooks.

Secure release engineering

Dependency pinning, vulnerability scanning, signed firmware/application updates, rollback plans, hardened gateway images, restricted SSH access and configuration integrity monitoring. Software supply-chain verification belongs in the release pipeline.

Recovery and operational assurance

Backup encryption, restoration tests, retention/deletion schedules, disaster recovery objectives and simulated failure exercises. Cloud availability, notification delivery and gateway uptime are measured rather than assumed.

Industrial trust boundary: Modbus RTU is not natively encrypted or authenticated. Electrical isolation protects the serial interface electrically; it does not authenticate commands. TMS treats the RS-485 segment as an untrusted local interface and proposes read-only polling by default, explicit model profiles and independent local safety enforcement before any authorised write.

Threat model: attack paths and compensating controls

ThreatTrust boundaryProposed mitigation
Stolen gateway credentialEdge → AWS IoTUnique certificates, device-scoped policies, rapid revocation and anomalous-client detection
Cross-customer data exposureAPI → tenant storageServer-side tenant authorisation, scoped queries and isolation tests
Replay or duplicate telemetryMQTT → ingestionSequence IDs, timestamp checks, idempotent writes and quality states
Malicious remote setpoint requestCloud → local controllerRead-only default, role checks, expiry, bounded allowlists and independent local gate
Gateway software compromiseDevice OS → credentialsMinimal services, patching, file permissions, signed updates and credential rotation
Missing telemetry or alert deliveryOperations → responseHeartbeat monitoring, dead-letter/retry paths, alert audit and tested escalation

AWS services named here are candidate components and security design objectives, not a statement that GEMXIT has deployed or certified every control. Exact service selection, cost, regional availability and integration require engineering validation.

The GEMXIT security advantage · Cross-cloud engineering

Built by engineers. Secured with a threat hunter’s mindset.

TMS 2.0 is developed by GEMXIT, drawing on our Microsoft security training, cloud architecture and detection-engineering background. We apply the same disciplines used to investigate identity compromise, endpoint attacks and cloud misconfiguration to the design of industrial IoT telemetry.

Detection engineering

Experience with Microsoft Sentinel, Defender XDR and KQL informs proposed TMS detections for anomalous gateway behaviour, unusual authentication patterns, rejected commands and missing telemetry.

Security methodology

Identity-first architecture

Microsoft Entra identity-security experience informs the design of strong customer authentication, least privilege, access reviews and tenant boundaries. AWS IoT device certificates and IAM remain distinct implementation controls.

Identity principles

Cloud posture & response

Cloud security and incident-response practices inform AWS configuration reviews, central logging, credential revocation, vulnerability management, investigation runbooks and tested recovery procedures.

Defence in depth
From Microsoft security expertise to AWS IoT implementation

Different platforms. The same rigorous security disciplines.

GEMXIT Microsoft security experienceHow it informs TMS 2.0
Microsoft Sentinel + KQLTelemetry correlation, detection logic, investigation timelines and actionable security alerting.
Microsoft Defender XDRAttack-surface reduction, endpoint hardening, compromise indicators and incident triage methodology.
Microsoft Entra IDStrong authentication, role separation, least-privilege access and identity lifecycle practices.
Microsoft Defender for CloudCloud posture management principles, configuration assessment and prioritised remediation.
Security Copilot + investigation workflowsStructured incident investigation and analyst workflows; no autonomous control of refrigeration equipment is implied.

Potential cross-cloud security analytics

A future integration could route selected AWS CloudTrail, AWS IoT and application security events into Microsoft Sentinel for KQL-based correlation and investigations. This would require configured ingestion, field normalisation, access controls, retention planning and cost assessment.

Optional future integration

Security expertise behind the product

GEMXIT is a Microsoft Training Services Partner. Its managing director is a Microsoft Certified Trainer, and the company develops practical Microsoft security education through the Agent Foskett Academy. That expertise helps shape the TMS 2.0 security design and validation roadmap.

Explore GEMXIT ↗
Architecture clarity: TMS 2.0 is designed around AWS services. GEMXIT's Microsoft security background informs its engineering practices; this does not mean Microsoft Defender, Sentinel, Entra ID or Security Copilot are deployed in TMS or provide automatic protection for AWS workloads. Proposed integrations and controls require implementation and validation.

Security isn't something we add after development.

It's part of how GEMXIT designs, engineers and protects the systems we build.

Develop IT. Protect IT. GEMXIT.
Clarity at a glance

Know what’s happening. Wherever you are.

Open TMS and immediately see your cool room conditions, recent trends and equipment status, from a phone, tablet or browser. Critical information should be immediately understandable, even when you’re away from the business.

Be part of the next chapter ↗
Cool Room 01
Sample data
● Normal · Demo
Temperature2.4°CWithin example range
Relative humidity82%Example reading
12-hour monitoring history06:00–18:00 · Demo
Temperature°C · Example readings
0 2 4 6 06:00 08:00 10:00 12:00 14:00 16:00 18:00
Relative humidity% RH · Example readings
70 75 80 85 90 06:00 08:00 10:00 12:00 14:00 16:00 18:00

Illustrative data only · 2-hour sample intervals · Not live measurements

A new generation of TMS

Your refrigeration intelligence. In your pocket.

The next-generation TMS mobile app: temperature, humidity, equipment status, alarms and trends.

Artwork of the next-generation TMS mobile app with a temperature gauge, humidity monitoring, historical charts and a refrigerated cool room
Artwork is illustrative; final screens and readings may differ.
Under the hood

Modern IoT. Practical engineering.

A modular architecture that grows from independent sensor monitoring into deeper controller integration.

🌡️
SensorsTemperature & humidity
🖥️
TMS EdgeRaspberry Pi gateway, local buffering
🔗
Controller LinkOptional isolated RS-485 / Modbus
☁️
TMS CloudSecure AWS data & alerts
📱
Web & MobileDashboards, history & notifications

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

TMS 2.0 · Engineering preview

From sensor to screen. A real-world hardware demonstrator.

We have designed and built a compact test panel to bring together a Raspberry Pi gateway, a Danfoss refrigeration controller, isolated RS-485/Modbus communications, and dedicated temperature and humidity monitoring.

It will give us a practical development platform for validating controller integrations, collecting telemetry and demonstrating how TMS 2.0 connects refrigeration equipment to modern monitoring software.

Raspberry Pi gatewayDanfoss controllerIsolated RS-485Temperature + humidity
Concept artwork of a TMS 2.0 demonstration board with Danfoss controller, Raspberry Pi, isolated USB-to-RS485 converter, temperature and humidity sensor, DIN rails and protected power components.
Concept visualisation — hardware demonstrator. Concept layout of the TMS 2.0 hardware demonstration panel. Final components, wiring and installation may differ depending on controller.
Engineering deep dive / TMS Edge

From refrigeration controller to cloud. See how it works.

Proposed TMS Edge design: isolated RS-485 connectivity, Modbus RTU register polling, Raspberry Pi edge processing and secure AWS telemetry. Controller-specific values in the examples are placeholders.

01 / Physical connection

Controller’s documented RS-485 A/B terminals → twisted-pair bus → galvanically isolated USB-to-RS-485 adapter → Raspberry Pi USB (e.g. /dev/ttyUSB0) → MQTT over TLS → AWS IoT Core → TMS app. The Pi is the Modbus RTU client; refrigeration control and safety functions stay local to the existing controller.

Follow the manufacturer’s guidance for reference conductor, shield, biasing and termination, and avoid star wiring on a multidrop bus.

Wiring matters: A/B polarity labels vary by manufacturer. Use the controller’s exact communications manual and confirm baud rate, parity, address, termination and grounding. Work on live equipment must be done by qualified personnel.

02 / 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 are reported as stale / unavailable, never as healthy readings.

03 / Multi-controller polling. One correctly engineered RS-485 bus can address several compatible controllers, each with a unique address and matching serial settings, polled sequentially.

04 / Resilience. Buffer readings during outages, detect stale data, apply alert delays, and distinguish communications failures from temperature excursions.

05 / Controlled integration. Remote setpoint changes are optional, off by default and, where supported, authenticated, authorised, constrained, logged and verified by readback. No direct compressor GPIO switching.

Code examples are in Developer Code below. Example register values are placeholders; each controller integration is validated against the manufacturer’s documentation and the controller itself before it is enabled. Reference: PyModbus 3.11 client API.

Controller integration / manufacturer pathways

Built for more than one brand. Designed for documented interfaces.

TMS 2.0 is being developed with integration pathways for selected refrigeration controllers, including models from Danfoss, CAREL, Dixell, Eliwell, LAE Electronic and Full Gauge Controls. Compatibility depends on the specific model, firmware, communications interface and available technical documentation. Integrations will be tested and validated individually; manufacturer names do not imply an existing integration or endorsement.

Trademarks: Danfoss, CAREL, Dixell, Eliwell, LAE Electronic and Full Gauge are trademarks of their respective owners. Names and logos are the property of their owners and are shown for identification only. TMS is not affiliated with or endorsed by any of them. Compatibility is confirmed model by model; this is not a certified compatibility list.
Per-model validationDanfoss logo

Some ranges expose serial communications. Modbus RTU is confirmed against the specific model, rather than a proprietary network, before hardware is selected.

Per-model validationCAREL logo

Selected families offer RS-485 / Modbus via built-in or optional serial interfaces, depending on model (for example the ir33 family, subject to verifying its serial option and protocol for that exact model).

Per-model validationDIXELL logo

Controller-specific Modbus interfaces, serial accessories and documented parameter tables are validated per model.

Per-model validationELIWELL logo

Model-specific protocols and serial interface availability are confirmed before an adapter is enabled.

Per-model validationLAE logo

Supported models and any serial module or gateway requirements are confirmed per model.

Per-model validationFULLGAUGE logo

Documented protocols and any required gateway or adapter are confirmed per model.

Three ways to connect refrigeration equipment

ConnectionWhen TMS uses itEngineering requirement
Native Modbus RTUController explicitly supports Modbus over RS-485Isolated adapter, verified register map, bus commissioning
Manufacturer gatewayController uses a proprietary serial or network protocolApproved gateway/API, vendor documentation and permissions
Independent sensorsController has no supported data interfaceDedicated calibrated temperature / humidity probes connected to TMS Edge

Danfoss programming versus TMS integration

KoolProg is a Danfoss configuration and service tool for supported controllers. It is not a general-purpose programming language, nor proof that a controller exposes a third-party Modbus interface. TMS Edge is written in Python and works from a documented protocol and verified register profile, without modifying Danfoss firmware.

Controller / toolWhat official documentation establishesWhat TMS verifies
AK-CC55 CompactDanfoss 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, address, baud-rate negotiation and the matching register map
AK-CC55 Single / Multi CoilPart of the AK-CC55 family, but communication options and details vary by variant.Obtain the specific variant’s guide; do not reuse the Compact map without validation
ERC / EET and other rangesConfiguration and service tooling varies by model; check the manufacturer documentation for the exact controller.Confirm whether any accessible port supports an approved third-party data protocol; never assume a service connector is standard RS-485 Modbus
Important: The AK-CC55 Compact serial defaults are documented for that controller only; they are not universal Danfoss defaults. Examples on this page use fictional registers and illustrative serial settings. Never attach an arbitrary RS-485 adapter to an undocumented programming port, and 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)

Open engineering approach

Actual Python patterns. From Modbus RTU to AWS IoT.

These examples illustrate the proposed TMS Edge approach. Register addresses and scaling are placeholders; each controller integration uses values verified from that controller’s register documentation.

Read-only polling with a model-specific register map

Addresses and scaling are deliberately fictional to prevent accidental use on live equipment. Serial settings are illustrative, not Danfoss defaults.

tms_edge/controller_reader.py
# pip install "pymodbus[serial]==3.11.1"
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 = {
        "device_id": "tms-gateway-001",
        "controller_id": PROFILE["unit_id"],
        "controller": PROFILE["model"],
        "temperature_c": raw * reg["scale"],
        "timestamp": datetime.now(timezone.utc).isoformat(),
        "quality": "sample_read_only",  # example value
    }
    print(payload)
finally:
    client.close()
A single-read example. Production TMS Edge confirms function code, addressing, scaling and data format from the controller manual and applies range, stale-data and fault checks before accepting any measurement.

Publish readings to AWS IoT Core

The gateway authenticates with its own provisioned device certificate and private key. Payloads carry 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,
    "controller_id": 1,
    "temperature_c": 2.4,  # placeholder: publish a validated reading
    "quality": "sample_read_only",
    "timestamp": "2026-11-04T00:00:00Z",  # illustrative UTC timestamp
    "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()
Simplified example. MQTT QoS 1 confirms broker receipt, not application processing or durable storage. Production TMS adds durable offline queuing, reconnect/backoff, credential rotation, device-specific IoT policies and cloud-side validation.

Controller profiles

Each integration ships with a versioned, verified profile rather than assumptions shared across manufacturers. This example is intentionally not a Danfoss or CAREL register map.

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
}

How remote setpoint requests work

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

  • Default to read-only integrations.
  • Role-based access and audit logs for every change.
  • Verify controller readback after a write; show failure if unconfirmed.
  • Rate-limit and expire commands; reject when communications are stale.
  • Never bypass compressor protection, defrost logic or safety interlocks.
Remote writes are optional and off by default. They are enabled only after controller-specific approval and qualified commissioning.
Advanced security and data-integrity examples

Policy enforcement, durable ingestion and telemetry provenance

These reference snippets illustrate security engineering patterns rather than a complete deployable TMS implementation. Placeholder account IDs, device names and readings must be replaced during provisioning.

Least-privilege AWS IoT device policy

security/iot-policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iot:Connect",
      "Resource": "arn:aws:iot:ap-southeast-2:123456789012:client/tms-gateway-001"
    },
    {
      "Effect": "Allow",
      "Action": "iot:Publish",
      "Resource": "arn:aws:iot:ap-southeast-2:123456789012:topic/tms/tms-gateway-001/telemetry"
    }
  ]
}

Edge store-and-forward persistence

edge/offline-queue.py
# Illustrative local queue: sqlite3 is in Python's standard library.
# Cloud ingestion must independently validate and deduplicate.
import json
import sqlite3
from datetime import datetime, timezone

with sqlite3.connect("/var/lib/tms/telemetry.db") as db:
    db.execute("PRAGMA journal_mode=WAL")
    db.execute("""CREATE TABLE IF NOT EXISTS pending (
        device_id TEXT NOT NULL,
        seq INTEGER NOT NULL,
        captured_at TEXT NOT NULL,
        payload TEXT NOT NULL,
        PRIMARY KEY(device_id, seq)
    )""")
    # seq must come from a persistent per-device counter.
    # Do not generate it from the current process memory.
    seq = 1042  # DEMO ONLY
    reading = {
        "device_id": "tms-gateway-001",
        "seq": seq,
        "captured_at": datetime.now(timezone.utc).isoformat(),
        "temperature_c": 2.4,
        "quality": "example_validated"
    }
    db.execute("INSERT OR IGNORE INTO pending VALUES (?, ?, ?, ?)",
               (reading["device_id"], seq,
                reading["captured_at"], json.dumps(reading)))

# Production: publish queued records in order; delete only after
# application-level durable-ingestion acknowledgement, NOT merely
# after an MQTT QoS 1 broker acknowledgement.
# Provision durable storage, capacity limits and safe shutdown.

Telemetry schema with data lineage

schemas/telemetry.json
{
  "device_id": "tms-gateway-001",
  "site_id": "site-example-01",
  "seq": 1042,
  "captured_at": "2026-11-05T02:00:00Z",
  "received_at": "2026-11-05T02:00:03Z",
  "temperature_c": 2.4,
  "relative_humidity_pct": 82,
  "quality": "valid",
  "source": "modbus_rtu",
  "profile_version": "example-1.0"
}

Security implementation checklist

Commissioning requires a unique device identity, certificate lifecycle plan, secure key storage, IoT topic policy tests, tenant-isolation tests, timestamp and duplicate checks, cloud-side heartbeat detection, restore testing and verified alert escalation.

For remote commands, require a separate approval path, an independent enforcement component, replay protection, explicit parameter allowlists and controller-specific readback.

Security caveat: An MQTT broker acknowledgement is not proof that a time-series record was durably committed. Design an application-level acknowledgement or reconciliation protocol before removing locally buffered readings.

References: PyModbus · AWS IoT protocols · Danfoss · CAREL. Consult model-specific 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 built for businesses that need dependable visibility without industrial-system complexity.

🐟
Fish & chip shops
💐
Florists
🥩
Butchers
☕
Cafés & restaurants
🛒
Grocers
The TMS story · 2016 to 2027

Built in 2016. Reimagined for 2027.

A decade of ideas, engineering and hands-on experience — and a new chapter for GEMXIT's original monitoring platform.

Original TMS temperature monitoring kit: branded Raspberry Pi enclosure, stainless-steel temperature probe, product box and printed brochures
From the original TMS project: real hardware, a temperature probe, packaging and brochures.
20162027

In 2016, GEMXIT set out to make remote refrigeration temperature monitoring practical for smaller businesses — without the need for a PLC or complex industrial control system.

We designed and built the original TMS Temperature Monitoring System using Raspberry Pi hardware, temperature probes, cloud infrastructure and mobile applications. It grew into a working, packaged product, complete with brochures and real-world installations.

Now we're bringing TMS back. TMS 2.0 builds on that experience with a modern approach to temperature and humidity monitoring, connected gateways and optional RS-485/Modbus integration for compatible refrigeration controllers.

The technology has evolved. Our mission hasn't: Stop Wondering. Start Monitoring.

Explore the new technology
The rebirth starts here

Be there when TMS returns in 2027.

Originally developed by GEMXIT in 2016, the Temperature Monitoring System is returning with enhanced monitoring, modern cloud connectivity and security-focused engineering. TMS 2.0 is independently developed and owned by GEMXIT, bringing together our expertise in software development, industrial IoT and cybersecurity.

Interested in TMS for your business? Contact GEMXIT to learn more about the next generation of temperature and refrigeration monitoring.

Enquire About TMS ↗

Or email evolve@gemxit.au

TMS 2.0 is planned for release in 2027. Developed and owned by GEMXIT PTY LTD.