Telemetry use case: Home energy monitoring and control
Smart meters collect more detail about energy consumption than traditional meters.
Smart meters are often coupled with a local telemetry network to monitor and control individual appliances in a home. Some are also connected remotely for monitoring and control at a distance.
The remote connection could be set up by an individual, by a power utility, or by a central control point. The remote control point can read power usage and provide usage data. It can provide data to influence usage such as continuous pricing and weather information. It can limit load to improve overall power generation efficiency.
Smart meters are beginning to deployed widely. The UK government, for instance, is in consultation about deployment of smart meters to every UK home by 2020.
Unless the user wants to be involved in saving energy by using the meter, the meter must not require user intervention. It must not reduce the reliability of the energy supply to individual appliances.
An MQTT client can be embedded in the software deployed with the meter, and does not require separate installation or configuration.
- Uneven connectivity
The communication between appliances and the smart meter demands different standards of connectivity than between the meter and the remote connection point.
The connection from the smart meter to appliances must be highly available and conform to network standards for a home area network.
The remote network is likely to use various physical connections. Some of them, such as cellular, have a high transmission cost, and can be intermittent. The MQTT v3 specification is aimed at remote connections, and connections between local adapters and the smart meter.
Connection between power outlets and applicances, and the meter, use a home area network, such as Zigbee. MQTT for sensor networks (MQTT-S), is designed to work with Zigbee and other low bandwidth network protocols. IBM® MQ Telemetry does not support MQTT-S directly. It requires a gateway to connect MQTT-S to MQTT v3.
Like home patient monitoring, solutions for home energy monitoring and control require multiple networks, connected using the smart meter as a hub.
There are a number of security issues associated with smart meters. These issues include non-repudiation of transactions, authorization of any control actions that are initiated, and privacy of power consumption data.
To ensure privacy, data transferred between the meter and the remote control point by MQTT can be encrypted using SSL. To ensure authorization of control actions, the MQTT connection between the meter and the remote control point can be mutually authenticated using SSL.
The physical nature of the remote network can vary considerably. It might use an existing broadband connection, or use a mobile network with high call costs, and intermittent availability. For high cost, intermittent, connections MQTT is an efficient and reliable protocol; see Telemetry use case: Home patient monitoring.
Eventually power companies, or central control points, plan to deploy tens of millions of smart meters. Initially, the numbers of meters per deployment are in the tens to hundreds of thousands. This number is comparable to the initial MQTT target of 50,000 open client connections per queue manager.
A critical aspect of the architecture for home energy monitoring and control is to use the smart meter as a network concentrator. Each appliance adapter is a separate sensor. By connecting them to a local hub using MQTT, the hub can concentrate the data flows onto a single TCP/IP session with the central control point, and also store messages for a short period to overcome session outages.
Remote connections must be left open in home energy use cases for two reasons. First, because opening connections takes a long time relative to sending requests. The time to open many connections to send
load-limitationrequests in a short interval is too long. Second, to receive load-limitation requests from the power company, the connection must first be opened by the client. With MQTT, connections are always initiated by the client, and to receive load-limitation requests from the power company, the connection must be left open.
If the rate of opening connections is critical, or the server initiates time-critical requests, the solution is typically to maintain many open connections.