Device Control Transactions

What it does

Operations sometimes have to reach the meter: disconnect a metering point at a move-out or for non-payment, reconnect it, switch a relay that controls a boiler or a charging point, or get a fresh reading now rather than at the next scheduled collection. Device Control Transactions lets operators and systems issue these commands from the platform in the standard CIM format and hands them to the head-end system that talks to the meter.

How it works

1. Choose the command. Two command types are supported: EndDeviceControl to connect or disconnect the meter's breaker or a named relay, and GetMeterReadings to request the readings of chosen channels for a chosen period on demand.
2. Start it on the meter. A command is a flow that is started on the meter's datasource, from the console or through the API. The module ships one flow per command type; the operation and the control type, or the channels and the period, are set in the flow design, so you typically keep one flow per command you use, for example disconnect breaker, connect breaker or switch a specific relay.
3. Check and send. The module checks that the command is issued on a meter, that the operation and the control type are valid and that a relay command names its relay, and then publishes the command message to the messaging topic the head-end system subscribes to.
4. Follow up. The meter's response arrives as a meter event or as new readings and is processed by Meter Events Processing and Meter Reads Processing. The executed commands are counted on the Meter events dashboard.

What you see

• The Meter events dashboard: the number of executed commands in devices by day.
• The effect of a command on the meter itself, as events and readings in the datasource view.

What you can configure

• The messaging topic per namespace that the head-end system reads from.
• The commands you offer, as flows with their operation, control type and relay name, or their channels and period.
• Like any flow, a command can be started for a single datasource or for a selection.

Verified behaviour

The package ships with automated acceptance scenarios that run against a live environment. Among others, they cover:

• a disconnect of the breaker and a connect of a relay being forwarded correctly;
• the relay name being ignored for a breaker command;
• a warning when the configured messaging topic does not exist;
• the command being refused when it is started on something other than a meter, when a relay command has no relay name, or when the operation or the control type is invalid.

Standard rules in this module

Rule	What it does
Standard End Device Control Forwarding	Sends an EndDeviceControl connect or disconnect message for the meter's breaker or a relay to the messaging topic.
Standard On Demand Request Forwarding	Sends a GetMeterReadings request for the chosen channels and period to the messaging topic.

Extending the module

• Put an approval step in front of a disconnect: a task for a supervisor whose completion triggers the command flow.
• Schedule commands, for example a nightly on-demand read of meters that did not report, with a trigger schedule.
• Add command types or head-end specific formats as your own forwarding rules.

Installation and updates: standard-packages.