Introduction:
Pseudo reporting is where a Gateway is configured to poll a Smart Energy device in order to simulate ZCL reporting. If the attribute value had exceeded a reportable_change amount during the min/max interval time period, the new value (along with all other attribute values) are reported.
Cron reporting is similar to Pseudo reporting, except that a cron string is used to specify exactly when data should be polled/reported (i.e. when the read_attributes requests are sent), rather than based on a configured min/max interval and reportable change. With cron reporting, every read is expected to generate a report unless some error occurs.
Available Cron Reporting configuration parameters:
The tables below, found within the
Smart Energy Framework User Guide for the ConnectPort X2e for Smart Energy documentation, describe the parameter options used in a <start_reports> request when creating a Cron Reporting request.
Key: A parameter type of int = integer, and bool = a value of True or False. Parameters listed with * specify
optional parameters).
Parameters common to all types of Reporting:
Parameter | Type | Description |
---|
destination_address | MAC | 64-bit extended address of the target device. |
source_endpoint_id* | int | 8-bit identifier of the endpoint on the local device from which the ZCL commands will be sent. Only provided if explicitly specified. |
destination_endpoint_id | int | 8-bit identifier of the endpoint on the target device containing the target cluster. |
profile_id | int | 16-bit profile identifier of the target endpoint. |
server_or_client | int | Whether the target cluster is a server (0) or client (1) cluster. |
cluster_id | int | 16-bit identifier of the cluster over which the ZCL command will be sent. |
manufacturer_code* | int | If applicable, the 16-bit manufacturer code of the ZCL attribute. |
attribute_id | int | 16-bit identifier of the attribute to be reported. |
force_configuration | bool | If True, this reporting configuration will continue to be reattempted until successful, rather than being dropped after the first failure. |
status | int | The status of the configuration operation, which may be 0 (“success”), some other ZCL status code (e.g. 0x86 “attribute not found”) or some internal status code (e.g. 0x202 “conversation timeout”). |
Parameters specific to scheduled reporting (reports are generated by sending reads on a cron schedule):
Parameter | Type | Description |
---|
pseudo_reporting* | bool | Either not set or set to True to enable pseudo reporting. |
schedule | cron | The schedule for when reads will be sent. Every read is expected to generate a report unless some error occurs. |
Note: When creating a
cron reporting configuring,
cron strings start with a “
seconds” field, NOT with a “minutes” field (as is the case with some other cron implementations). For example: */5 * * * * * means “every fifth second”, while 0 */5 * * * * would mean "every 5 minutes".
How to configure scheduled attribute reporting:
The following <start_reports> request example would configure a ConnectPort X2e for Smart Energy Router gateway to read and send upstream the Current Summation Delivered (0x0) and Instantaneous Demand (0x400) attribute data of a Smart Meter Coordinator's Simple Metering server cluster (0x702) every 10 seconds.
In the following example, 00:11:22:33:44:55:66:77 represents the EUI-64 address of the Smart Meter:
<start_reports synchronous="true">
<record_list type="list">
<item type="StartReportRecord">
<schedule type="cron">*/10 * * * * *</schedule>
<destination_address type="MAC">00:
11:22:33:44:55:66:77</destination_address>
<cluster_id>0x0702</cluster_id>
<server_or_client>0</server_or_client>
<attribute_id>0x0000</attribute_id>
</item>
<item type="StartReportRecord">
<schedule type="cron">*/10 * * * * *</schedule>
<destination_address type="MAC">00:
11:22:33:44:55:66:77</destination_address>
<cluster_id>0x0702</cluster_id>
<server_or_client>0</server_or_client>
<attribute_id>0x0400</attribute_id>
</item>
</record_list>
</start_reports>
What did the request do?
We can dissect the request above to see what is happening....
destination_address - the EUI-64 of the Smart Meter
cluster_id - the ID of the Simple Metering server cluster (found under the destination_endpoint specified above)
server_or_client - the type of Meter cluster for cluster_id above (0 = server cluster, 1 = client cluster)
attribute_id - the ID of the interesting attribute found under cluster_id
schedule - the cron schedule of when attribute reads will be sent
Conclusion:
The <start_reports> configuration above can be used to report the readable ZCL attribute(s) data of any Smart Energy device at a consistant interval, whether or not ZCL attribute reporting is supported.
Additional Information:
HOW TO: Configure ZCL (real) Reporting on the ConnectPort X2e for Smart EnergyHOW TO: Configure Pseudo (differential) Reporting on the ConnectPort X2e for Smart EnergyHOW TO: Run Smart Energy Framework RPC commands from Digi Device Cloud Web Services
Last updated:
Jan 01, 2024