Introduction:
Pseudo Reporting is a Smart Energy Framework Reporting method which enables attribute reporting for numerous Smart Energy devices which either don't support ZCL reporting (not required in the SE spec), or don't do it correctly. In ZCL Reporting, a Smart Energy device is configured to send attribute data changes based on the reporting configuration for the device. In Pseudo Reporting, a Gateway simulates "ZCL reporting" by sending ZCL read_attributes requests of the various device attributes, in order to poll the data at the ZigBee level.
A snapshot (attribute report) of all attribute data is taken and sent upstream to Device Cloud if any of the attribute values have changed outside the parameters setup by min/max_interval and reportable change at min_interval. If the max_interval is reached but none of the attribute values have changed enough to generate a report, an attribute report containing the current attribute value for all configured attributes is sent to Device Cloud anyway.
Pseudo Reporting is commonly used for reading Smart Meters, Thermostats, and many other Smart Energy devices which don't have the built-in ability to report their attribute data.
Available Pseudo 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 Pseudo Reporting configuration.
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 Pseudo reporting (simulated ZCL reporting by read_attributes polling):
| Parameter |
Type |
Description |
| pseudo_reporting* |
bool |
Either not set or set to True to enable pseudo reporting. |
| min_interval* |
int |
16-bit minimum time between attribute reports, in seconds. Defaults to 5 seconds for ZCL reporting. |
| check_interval* |
int |
Polling interval. An attribute will be read every this many seconds, once min_interval seconds have passed since the last attribute report was generated. Defaults to min_interval seconds. |
| max_interval* |
int |
16-bit maximum time between attribute reports, in seconds. An attribute report will be generated after this much time has passed since the last attribute report, even if the attribute value has not changed more than reportable_change. The exception is if this value is 0, in which case reports will only be generated due to reportable_change. |
| reportable_change* |
int |
The minimum value by which the attributes value must change before a report will be generated, excluding min and max interval restrictions. The type of this parameter corresponds with the ZCL type of the attribute. Note that this value is only meaningful for analog ZCL types; for discrete types any change is considered a reportable change.
|
How to configure Pseudo attribute reporting:
The following <start_reports> request example would configure Pseudo Reporting of two attributes on a Smart Meter's Simple Metering Cluster, on whose Smart Energy network a ConnectPort X2e SE Router has been fully provisioned. This configuration reports on the Current Summation Delivered (0x0) and Instantaneous Demand (0x400) of the Simple Metering server cluster (0x702) under endpoint 0x10, when either value has changed by 1 or more within a 5 minute period, otherwise wait 15 minutes and send the present readings anyway.
In the following example, 00:11:22:33:44:55:66:77 represents the EUI-64 address of the Smart Meter Coordinator:
<start_reports synchronous="true">
<record_list type="list">
<item type="StartReportRecord">
<destination_address type="MAC">00:11:22:33:44:55:66:77</destination_address>
<destination_endpoint_id>0x10</destination_endpoint_id>
<cluster_id>0x702</cluster_id>
<server_or_client>0</server_or_client>
<attribute_id>0x0</attribute_id>
<pseudo_reporting type="bool">True</pseudo_reporting>
<min_interval type="int">0x12C</min_interval>
<max_interval type="int">0x384</max_interval>
<check_interval type="int">0x12C</check_interval>
<reportable_change type="int">1</reportable_change>
</item>
<item type="StartReportRecord">
<destination_address type="MAC">00:11:22:33:44:55:66:77</destination_address>
<destination_endpoint_id>0x10</destination_endpoint_id>
<cluster_id>0x702</cluster_id>
<server_or_client>0</server_or_client>
<attribute_id>0x400</attribute_id>
<pseudo_reporting type="bool">True</pseudo_reporting>
<min_interval type="int">0x12C</min_interval>
<max_interval type="int">0x384</max_interval>
<check_interval type="int">0x12C</check_interval>
<reportable_change type="int">1</reportable_change>
</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
destination_endpoint_id - the ID of the Smart Meter endpoint under which the "interesting data" will be found
cluster_id - the ID of the Meter's Simple Metering server cluster (found under destination_endpoint 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 Current Summation Delivered attribute found under cluster_id pseudo_reporting - since we want pseudo_reporting, pseudo_reporting = TRUE
min_interval - an attribute report exceeding reportable change will not be generated sooner than this many seconds
max_interval - a new report must be generated at least this often, even if the value hasn't changed.
check_interval - typically set to match min_interval, which is the default
reportable_change - the amount of attribute change which is meaningful to generate a report
Conclusion:
The <start_reports> configuration above can be used to report on the readable ZCL attribute(s) of any Smart Energy device, whether or not the device supports ZCL attribute reporting.
Additional Information:
HOW TO: Configure ZCL (real) Reporting on the ConnectPort X2e for Smart Energy
HOW TO: Configure Scheduled (cron) Reporting on the ConnectPort X2e for Smart Energy
HOW TO: Run Smart Energy Framework RPC commands from Digi Device Cloud Web Services
Last updated:
Oct 04, 2024