IoT Product Family — Overview & Specifications

Overview

SGT Systems Limited engineers a complete Internet-of-Things (IoT) product family designed to give Bangladeshi enterprises and South-Asian system integrators a single, dependable source for connected hardware. The family currently spans 15 production SKUs grouped into four functional layers — sensing nodes, edge gateways, programmable controllers, and remote terminal units — that interoperate with each other and with our cloud platform out of the box. Every device is designed in Dhaka, manufactured to industrial-grade tolerances, and pre-tested against our reference firmware so customers can move from procurement to a live deployment in days rather than months.

The product range targets three primary buyers: factory operations teams looking to instrument legacy machinery, facility and energy managers pursuing measurable utility savings, and OEMs who need a ruggedised, locally-supported alternative to imported Chinese or European hardware. Across all three segments the value proposition is the same — hardware that has been hardened for the heat, humidity, dust and unreliable mains supply typical of South-Asian industrial sites, paired with firmware that exposes data through open protocols (MQTT, Modbus TCP, REST, OPC UA) so customers are never locked into a single dashboard or cloud.

Compared to assembling a stack from multiple imported brands, the SGT family eliminates protocol-translation headaches, reduces spare-parts inventory, and gives the buyer one warranty contact and one firmware update channel. Every gateway in the family understands every sensor in the family at the wire-protocol level, and every controller can be commissioned from the same Android-based commissioning app that ships free with each unit. The result is a coherent, defensible technology stack that we have already deployed in garment factories, cold-chain warehouses, container terminals, public utilities and agricultural research stations.

This document is the entry point to the family. It summarises the product line, the specifications common to all SKUs, the recommended deployment architecture, the industries we serve, and the commercial terms under which we ship. Individual SKU datasheets — with pinouts, dimensional drawings, wiring diagrams and ordering codes — are available on request or via the per-product pages in this documentation library.

Product range

The table below lists representative product types in the IoT family. Each type ships in multiple SKU variants distinguished by connectivity, I/O count or sensor range.

Common specifications

While each SKU has its own datasheet, the IoT family is built on a common engineering baseline. This makes mixed-vendor deployments predictable and reduces the integration burden on the customer's IT team.

Communication protocols

• Northbound: MQTT v3.1.1 and v5 (TLS 1.2), HTTPS REST, OPC UA (gateways and controllers), AMQP optional
• Southbound: Modbus RTU, Modbus TCP, BACnet/IP, M-Bus (energy meters), SDI-12 (environmental probes)
• Wireless: 4G LTE Cat-1/Cat-M1, LoRaWAN 1.0.4, Wi-Fi 802.11 b/g/n/ac, BLE 5.2, Zigbee 3.0
• Wired: 10/100 Ethernet (gateways and controllers), RS-485 isolated, RS-232, USB 2.0 for commissioning

Power requirements

• Field sensors: industrial Li-SOCl₂ cells (3.6 V) with 3–7 year service life depending on duty cycle
• Controllers and RTUs: 9–36 VDC wide-range input, reverse-polarity and over-voltage protected
• Gateways: 12–48 VDC or IEEE 802.3af PoE, typical draw 3–7 W
• Energy meters and AC-powered devices: 90–300 VAC self-powered, no separate auxiliary feed required
• Solar variants: 20–40 W panel with 20 Ah sealed lead-acid or LiFePO₄ battery, MPPT charge controller built in

Environmental and mechanical

• Operating temperature: −20 °C to +70 °C for outdoor SKUs, 0–60 °C for indoor SKUs
• Humidity: 0–95 % RH non-condensing
• Ingress protection: IP65 standard for outdoor units, IP67 available, IP20 for DIN-rail indoor units
• Enclosures: powder-coated aluminium or UV-stabilised polycarbonate; DIN-rail, wall and pole mounts
• Vibration and shock: IEC 60068-2-6 (vibration), IEC 60068-2-27 (shock) for controllers and RTUs

Compliance and accuracy

• Regulatory: CE, FCC Part 15, RoHS, REACH; BTRC type-approval on all 4G/GSM SKUs; BSTI registration where applicable
• Sensor accuracy: ±0.3 °C (temperature), ±2 %RH (humidity), ±50 ppm (CO₂), Class 0.5S (energy meters)
• Gateway throughput: up to 500 messages/second (MQTT), 200 Modbus polls/second across multiple serial ports

Typical deployment architecture

The IoT family is designed around a three-tier architecture — sensing, edge, and cloud — with optional on-premises servers for customers with data-residency requirements.

   [Field Sensors / Meters / Beacons]        (LoRa, BLE, RS-485, 4-20mA)
                 |
                 v
        [SGT Edge Gateway / RTU]             local logic, buffering, OPC UA
                 |   (MQTT/TLS or HTTPS)
                 v
   [SGT Cloud  -or-  Customer MQTT broker]   data normalisation, alerts
                 |
                 v
   [Dashboard / SCADA / ERP / BI tools]      Grafana, Power BI, SAP, custom

Sensors and meters communicate with the nearest SGT gateway using whichever protocol best fits the physical environment — LoRa for kilometre-scale outdoor coverage, BLE for asset tracking inside buildings, RS-485 for in-cabinet equipment, and 4-20 mA loops for legacy process instruments. The gateway buffers data locally (up to 30 days of telemetry on internal flash), applies edge rules where required, and forwards normalised JSON over MQTT or HTTPS to either SGT's hosted cloud or a customer-operated broker. From there, dashboards, SCADA systems and ERPs subscribe to the relevant topics.

Industries we serve in this category

• Garments and textiles: boiler and compressor monitoring, energy sub-metering by floor, ETP compliance telemetry
• Cold chain and pharma: warehouse temperature and humidity logging with audit-grade reporting
• Public utilities: water-treatment plant monitoring, distribution-network pressure and flow telemetry
• Commercial real estate: tenant sub-metering, indoor air-quality monitoring, BMS retrofit
• Telecom and infrastructure: tower-site DG fuel level, battery health, intrusion detection
• Research and academia: environmental research stations, smart-campus and lab monitoring

Customisation & OEM

Roughly a third of our IoT shipments leave the factory in some customised form. Customisation engagements typically fall into four buckets: firmware modifications (custom Modbus register maps, bespoke MQTT topic structures, vendor-specific authentication), enclosure variants (custom gland positions, branded labels, IP67 upgrades, explosion-proof versions for petrochemical sites), private-label / OEM rebranding (silk-screen, boot logo, custom packaging and documentation under the partner's brand), and integration adapters (drivers for proprietary instruments, custom REST connectors into the customer's ERP or maintenance system).

Our standard engagement is a paid design study (typically 1–2 weeks) that produces a firm bill of materials, a fixed firmware-modification quotation, and a sample timeline. Customisation MOQs depend on the scope but typically start at 25 units for label / firmware changes and 100 units for enclosure changes.

Ordering & logistics

• Lead times: in-stock SKUs ship within 3 working days inside Bangladesh; build-to-order variants 2–3 weeks; fully imported components 4–6 weeks
• Minimum order quantity: 1 unit for evaluation, 5 units for production pricing, 25+ for project pricing
• Warranty: 12-month standard manufacturer's warranty on all SKUs; optional 36-month extended warranty and on-site AMC available
• Shipping: same-week courier inside Bangladesh, 2–4 weeks for regional South-Asian destinations, DAP / DDP Incoterms supported
• Payment terms: 50 % advance, balance against pro-forma invoice for first orders; 30-day net terms for repeat enterprise customers

Support & documentation

Every SGT IoT shipment includes installation guidance, a commissioning checklist, and free remote technical support for the first 90 days. Customers on AMC contracts additionally receive same-business-day response, periodic firmware updates pushed over-the-air, on-site visits where the contract specifies, and quarterly health-check reports for fleets above 50 devices. Our applications engineering team in Dhaka runs free online onboarding sessions for buyer engineering teams and paid in-depth training courses (1–3 days) on request.

Full per-SKU datasheets, firmware release notes, MQTT topic specifications and Modbus register maps are accessible through the SGT documentation library. To speak to an application engineer about a specific project, please use the contact form or email our pre-sales desk.

Reference deployments

The IoT Product Family is currently deployed across more than 80 customer sites in Bangladesh and the wider region. A typical garments-factory deployment instruments 8–12 boilers and compressors with vibration and temperature sensors, sub-meters every production floor with a three-phase energy meter, and feeds the data into a Grafana dashboard hosted on a single edge gateway in the IT room — a complete project that pays back in under nine months on energy savings alone. A typical cold-chain warehouse deployment combines 60–120 wireless temperature and humidity sensors with two indoor LoRaWAN gateways and our compliance-reporting module to produce the audit packs needed for pharma customers. A typical telecom-tower deployment uses a single solar-powered RTU per site, monitoring fuel level, DG run-hours, battery health and door intrusion, and reporting back to a single national operations centre over 4G.

What these deployments have in common is that they all rely on the same gateway firmware, the same MQTT topic structure and the same commissioning app — which means the customer's operations team learns one platform, stocks one set of spares, and trains its engineers once.

Security and data handling

Industrial IoT deployments increasingly attract the attention of corporate IT and security teams, and rightly so — a poorly secured gateway can become an entry point into the wider corporate network. The SGT IoT family addresses this at multiple layers. All MQTT and REST communication uses TLS 1.2 (TLS 1.3 on newer firmware) with mutual certificate authentication where the customer requires it. Gateway firmware is signed and verified at boot. Devices ship with unique per-unit credentials rather than shared default passwords. Remote SSH and web-management interfaces are disabled by default and must be explicitly enabled per device. Firmware updates are delivered over an authenticated channel from a customer-controlled update server (or our cloud, at the customer's option).

For customers with strict data-residency requirements — banks, public utilities, hospitals — every part of the stack can run on the customer's own infrastructure. The same gateway firmware, MQTT broker, dashboard and management server can be installed on-premises, in a private cloud, or in an isolated subnet with no internet connectivity at all.

Frequently asked questions

Can SGT IoT devices integrate with my existing SCADA / BMS?

Yes. Every gateway and controller exposes both an OPC UA server and a Modbus TCP server, which between them cover the vast majority of SCADA and BMS systems. For systems with proprietary interfaces (Siemens Desigo, Schneider EcoStruxure, Honeywell Niagara), we have integration playbooks available on request.

Do you support over-the-air firmware updates?

Yes. All gateways, controllers and RTUs support signed, authenticated OTA updates from either the SGT cloud or a customer-operated update server. Battery-powered sensors typically receive parameter updates OTA but firmware updates only through a wired commissioning interface, to preserve battery life.

What happens if the cloud or 4G link goes down?

All gateways have local flash storage with at least 30 days of buffered telemetry. When the link recovers, buffered messages are flushed to the cloud in chronological order with their original timestamps preserved. For closed-loop control applications, local logic continues to run on the gateway / controller without any dependence on the cloud.

Can I mix SGT hardware with third-party hardware?

Yes — and we encourage it. The whole family speaks open protocols (MQTT, Modbus, OPC UA, REST) precisely so that customers can pair our gateways with third-party sensors, or our sensors with a customer's existing PLCs and dashboards.