Lost Stock
Temperature excursions can lead to spoiled inventory, lost revenue and unnecessary waste.
Temperature, humidity and refrigeration monitoring for Australian small businesses. Receive alerts, track trends and gain visibility into refrigeration systems from anywhere.
Stop Wondering. Start Monitoring. • A GEMXIT innovation
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.
Temperature excursions can lead to spoiled inventory, lost revenue and unnecessary waste.
Receive notifications and monitor trends so problems can be identified sooner.
View conditions, trends and alerts from your phone, tablet or browser.
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 ↗TMS brings environmental monitoring together with deeper refrigeration insight, without the complexity of a traditional PLC or SCADA deployment.
Time-stamped readings, quality flags, historical trends, configurable thresholds and out-of-range events for cool rooms and freezers.
Core TMS TechnologyTrack conditions and spot changes that could affect flowers, produce, stock and storage quality.
TMS 2.0 EnhancementCommunication with compatible refrigeration controllers via appropriately isolated RS-485 adapters.
Compatibility DependentProposed SMS and email notifications, alert hysteresis, acknowledgement, escalation and cloud-side missing-heartbeat detection.
Advanced Alerts PlannedAWS-based IoT connectivity with a security roadmap covering device identity, encrypted cloud communications and controlled multi-location access.
AWS Security ArchitectureEquipment trends and diagnostics, with carefully safeguarded remote setpoint controls where supported by the existing controller.
Where SupportedTMS 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.
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 ContinuityA 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 ArchitectureConfigurable 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 NotificationsProposed 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 IntegrityCloud-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 MonitoringOptional 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 ResilienceValidated measurements, monotonic sequence IDs and UTC acquisition timestamps.
Local write-ahead persistence; stale and invalid observations remain distinguishable.
Connection health, exponential backoff and encrypted MQTT publication.
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.
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.
Gateway-to-cloud telemetry and application connections are designed to use authenticated TLS encryption, with TLS 1.3 preferred where supported.
Secure CommunicationsCloud records and backups are designed to use encryption at rest, managed key access, retention policies and tested recovery procedures.
Data ProtectionIndividual user accounts, multifactor authentication, secure sessions and account recovery controls will help prevent unauthorised dashboard access.
Identity & Access SecurityEach Raspberry Pi gateway is intended to have a unique device identity and certificate-based authentication, with narrowly scoped permissions.
Device AuthenticationAdministrators, managers and viewers will have distinct permissions, with customer data isolated between organisations and locations.
Least-Privilege AccessSecurity events, configuration changes and any authorised remote-control requests are intended to be recorded and monitored for suspicious activity.
Security MonitoringA proposed defence-in-depth architecture for authenticated monitoring and tightly controlled remote adjustments.
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.
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 SafetyGateways are designed to initiate secure outbound connections, with segmented networks and no routine public inbound management access.
Network HardeningSigned update packages, controlled deployment, vulnerability management and recovery procedures are planned to reduce tampering and downtime.
Software IntegrityUnusual logins, unexpected device activity and rejected control commands can trigger alerts and credential revocation, while local refrigeration remains independent.
Threat Detection & ResponseRemote changes are designed to require the right permissions, fresh approval, bounded values, controller readback and a traceable audit record.
Auditing & AccountabilityOur release plan includes security testing, simulated attack scenarios, communications-failure tests and independent refrigeration safety review.
Security ValidationDeveloped 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 ↗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.
Per-gateway credentials, restrictive IoT policies, certificate revocation and secure provisioning.
AWS IoT Core certificate authentication, broker authorisation and device-scoped topic namespaces.
Schema checks, timestamp sanity, idempotency, per-tenant isolation and encryption at rest.
Least-privilege IAM, MFA, change logging, threat detection, backups and recovery drills.
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.
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.
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.
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.
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.
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.
| Threat | Trust boundary | Proposed mitigation |
|---|---|---|
| Stolen gateway credential | Edge → AWS IoT | Unique certificates, device-scoped policies, rapid revocation and anomalous-client detection |
| Cross-customer data exposure | API → tenant storage | Server-side tenant authorisation, scoped queries and isolation tests |
| Replay or duplicate telemetry | MQTT → ingestion | Sequence IDs, timestamp checks, idempotent writes and quality states |
| Malicious remote setpoint request | Cloud → local controller | Read-only default, role checks, expiry, bounded allowlists and independent local gate |
| Gateway software compromise | Device OS → credentials | Minimal services, patching, file permissions, signed updates and credential rotation |
| Missing telemetry or alert delivery | Operations → response | Heartbeat 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.
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.
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 methodologyMicrosoft 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 principlesCloud security and incident-response practices inform AWS configuration reviews, central logging, credential revocation, vulnerability management, investigation runbooks and tested recovery procedures.
Defence in depth| GEMXIT Microsoft security experience | How it informs TMS 2.0 |
|---|---|
| Microsoft Sentinel + KQL | Telemetry correlation, detection logic, investigation timelines and actionable security alerting. |
| Microsoft Defender XDR | Attack-surface reduction, endpoint hardening, compromise indicators and incident triage methodology. |
| Microsoft Entra ID | Strong authentication, role separation, least-privilege access and identity lifecycle practices. |
| Microsoft Defender for Cloud | Cloud posture management principles, configuration assessment and prioritised remediation. |
| Security Copilot + investigation workflows | Structured incident investigation and analyst workflows; no autonomous control of refrigeration equipment is implied. |
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 integrationGEMXIT 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 ↗It's part of how GEMXIT designs, engineers and protects the systems we build.
Develop IT. Protect IT. GEMXIT.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 ↗Illustrative data only · 2-hour sample intervals · Not live measurements
The next-generation TMS mobile app: temperature, humidity, equipment status, alarms and trends.

A modular architecture that grows from independent sensor monitoring into deeper controller integration.
Controller integrations require compatible equipment and qualified installation. Existing safety controls remain independent of TMS.
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.
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.
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.
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.
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.
DanfossSome ranges expose serial communications. Modbus RTU is confirmed against the specific model, rather than a proprietary network, before hardware is selected.
CARELSelected 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).
DIXELLController-specific Modbus interfaces, serial accessories and documented parameter tables are validated per model.
ELIWELLModel-specific protocols and serial interface availability are confirmed before an adapter is enabled.
LAESupported models and any serial module or gateway requirements are confirmed per model.
FULLGAUGEDocumented protocols and any required gateway or adapter are confirmed per model.
| 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 |
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 / tool | What official documentation establishes | What TMS verifies |
|---|---|---|
| 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, address, baud-rate negotiation and the matching register map |
| AK-CC55 Single / Multi Coil | Part 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 ranges | Configuration 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 |
Official references: AK-CC55 Compact Modbus programming guide (PDF) · Danfoss KoolProg · KoolProg user guide (PDF)
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.
Addresses and scaling are deliberately fictional to prevent accidental use on live equipment. Serial settings are illustrative, not Danfoss defaults.
# 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()
The gateway authenticates with its own provisioned device certificate and private key. Payloads carry device identity, measurement time and quality status.
# 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()
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.
{
"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
}
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.
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.
{
"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"
}
]
}
# 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.
{
"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"
}
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.
References: PyModbus · AWS IoT protocols · Danfoss · CAREL. Consult model-specific manuals for protocol support and register maps.
From a single freezer to multiple locations, TMS is built for businesses that need dependable visibility without industrial-system complexity.
A decade of ideas, engineering and hands-on experience — and a new chapter for GEMXIT's original monitoring platform.
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 technologyOriginally 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.