Bring field devices onto one thing model
Chargers, meters, breakers, storage and environment sensors come online on their own protocols and register as one set of records on MeetCarbon Cloud. Business apps read state and send commands through the same API. Protocol differences stay in the foundation.
See energy management- 3
- TCP · MQTT · Modbus
- 3
- Properties · services · events
- 1
- Device record and groups
- HTTP
- One control entry
- Switchroom meter 1MQTT2s ago
- Garage chargerTCP18s ago
- Roof environmentModbus1m ago
Devices come in. Apps use one description
Protocols are decoded in the foundation. Charging, energy management and PV see the same devices, properties and commands.
- 01
Devices online
Chargers, meters, breakers, storage and sensors connect the way the site already works.
Field - 02
Protocol adapt
Charger TCP, meter and device MQTT, and Modbus become one message shape.
3 protocols - 03
Thing model
Properties, services and events follow the product template. Devices of one type share it.
Template - 04
Apps consume
Business apps read state and send commands through one API, without their own protocol work.
MeetCarbon Cloud
The foundation runs devices, not the business ledger
Records, thing models, protocols, rules, alarms and lab devices live here. Orders, energy analytics and generation revenue stay in their own products.
Devices and groups
Register devices once, then view online state by site, tag and group.
Products and thing models
Define the product first, then attach devices. Properties, services and events reuse the template.
Protocols and platforms
Built-in protocols register themselves. Devices on an existing platform can sync and map to a product.
Rules engine
When a device event matches a condition, run an action. Scheduled jobs are included.
Alarms and notify
Offline and limit alarms are recorded in one place and sent on the channels you configure.
Virtual devices
Before hardware arrives, simulate reports and commands to prove the protocol.
Properties, services, events. Apps use these three
When the protocol or the model changes, update the mapping in the foundation. Apps keep the same description.
Properties
Read current state. Values carry the units defined on the product, ready for business apps.
Services
Send an action. Calls go through one control API. The foundation translates the protocol.
Events
The device reports a change. Rules and alarms fire on events, without polling each protocol.
Once the product template is set, devices of that model share it. A new unit is attached to the product.
Records, operations, products and labs each have a view
Four roles share the same device records and open different pages.
Which devices are online, and which group holds the offline ones?
- Device list and detail
- Groups and tags
- Open alarms
The foundation stops at the device. Ledgers stay in each product
IoT device management covers onboarding, records, collection, control, rules and alarms. Operations and analytics stay in the products already on the site.
The foundation
- Register, discover, authenticate, online and offline
- Products, categories and thing models
- Protocol registry, platform sync and device mapping
- Property read/write, service calls and config push
- Rules, alarm history and notification channels
- Virtual devices and protocol labs
Business products
Charging operationsOrders, tariffs, payment and invoices. Charger presence and control come from the foundation.Open productEnergy managementSub-metering, analytics, electrical safety and reports. Meter data is collected by the foundation.Open productPV operationsGeneration, revenue and fleet monitoring. Inverters connect through the foundation.Open productAlign these before connecting a site
How do IoT device management and energy management split the work?
IoT brings meters, chargers and other devices online and keeps records, thing models and control. Energy management runs usage, analytics and reports. Meter readings are collected in the foundation and accounted in the energy product.
The site already uses a vendor platform. Can we still connect?
Yes. Devices can connect over TCP, MQTT or Modbus, or sync from an existing platform. Before a project we review the point list or API document and estimate the approach and schedule.
How does a new protocol get on?
It is registered in the foundation and mapped to a product thing model. Send the protocol note or point list and we estimate the work. Business apps keep calling the same control API.
There is no hardware on site yet. Can we still see the product?
Yes. Virtual devices simulate uplink and commands, so a protocol lab and a demo do not wait for hardware. Tell us the device types when you book.
Do alarms become maintenance work orders here?
The foundation records alarms and notifies the channels you set. Work orders, inspections and maintenance close in Smart O&M. Linking an alarm into operations is scoped per project.
See how the devices on site would connect
Tell us the device types and the protocols or platforms already in place. We will demo and suggest an onboarding path.