Class: ResourceMonitor

[Dean Roddey]

General Description

This thread is for discussion of the Resource Monitor device class. This is a very generalized class that can be used by any devices that report usage of some resource, power, water, etc... It can be used in the usual way, by just choosing the resources you wish to monitor, by selecting the appropriate fields. But it also will report via backdoor commands in a more generalized way that can be used by smart tools such as the CQC auto-generation system, allowing resources to be selected by name from among those available from the driver.

Fields Provided

[INDENT]Fields for this class MUST be in one of these forms:

RESMON#sub~fieldname
RESMON#fieldname

As long as the 'fieldname' portion follows the standard CQC field name conventions, that is all that is required from a field naming point of view.

The two forms are intended to deal with two different likely scenarios. If the device just offers completely configurable values that represent individual resources, then you would likely use the second form. The fields might be something like:

Code:

RESMON#RefrigWatts
    RESMON#Sub1_TotalWatts

and so forth. Each resource monitored are just separate things that aren't necessarily related. The whole field name would be user/device defined.

On the other hand, if the device provides multiple channels where the same information is provided for each channel, then the first form SHOULD be used, and the user/device provided name would be the sub~ part, and the field name part would be the name of the specific measurements, such as:

Code:

RESMON#Kitchen~TotalWatts
    RESMON#Kitchen~WattSeconds
    RESMON#Garage~TotalWatts
    RESMON#Garage~WattSeconds

In this case, there are two channels, which have been named Kitchen and Garage, and the device provides the same values for each channel, so the field names are just repeats of the same values, for each named channel.

Fields MUST be numeric, so Card, Int, or Float, and of course in some cases may be negative values, if the consumption is negative. They MUST be read only. If a usage counter reset capability exists, it is outside of this device class.
[/Indent]

Backdoor Commands/Queries

[INDENT]This device class defines a standard backdoor query via the QueryTextVal driver interface. The Value Id is "QueryResInfo" and the Data Name is "ResourceList", both case sensitive. The driver will return a double quoted comma list, where the first list is of short descriptions of the resources being monitors, and the second are the corresponding field for those resources. The descriptions provided by the driver should be very short and to the point, and include a name and units in parenthesis, e.g. "Refrigerator (KwH)", or "Irrigation (CuGal)" and so forth. There is no attempt to standardize the units, they are just for human consumption in selection lists.

The two lists are separated by a new line, which is a form understood by user interface list browsers. You can directly load such a list into a list browser and it will put the first list into the visible list and will store the second list into the hidden values. This allows you to make a connection between the selected item and the field that contains that information. Of course both lists must be of equal size and the xth item in both lists must represent the same resource.
[/INDENT]

Event Triggers

[INDENT]None at this time[/INDENT]

[Dean Roddey]

(reserved 1)

[Dean Roddey]

So, anyone have any thoughts on this? I don't know a lot about these types of devices. What is the core functionality that should be available (or can be provided in the driver itself based on other available features) broadly for these devices?

Maybe it should be even more general, i.e. any sort of monitor of resource consumption?

[Ron Haley]

I have a Brultech GEM power monitoring unit. It's a step up from the ECM 1240, in that it monitors 32 breakers, supports pulse counters and One-wire.
I currently interface to it through an ecm-1240 emulator, which isn't ideal.
No one wire support, and no pulse counter support. The emulator also only supports the equivalent of 6 ecm-1240's, and given that I already have 3 of them, I can only access 21 of the GEM monitoring ports.

So a native GEM driver would be something I would be willing to help fund. Anyone else interested?

Ron

[Ron Haley]

Most solar customers have a good idea of what they generate, but no idea of what they consume. I think this is a big market for CQC. So individual usage by breaker, plus total home consumption and nett consumption along with power generated real time. It's also useful to know what the nett position is for peak and off peak times. This then allows real time costing.

You can see what I am doing here;

https://security.haleycentral.com:5001/f...g/P23FNPyf

It's a secure link - will download a small jpg file for you.

Ron

[Dean Roddey]

A big issue here is how much can we generalize it. Could a device class for this type of device be something like a set of fields, each one of which indicates consumption of a particular type of resource, in a particular unit, with a name that identifies the specific resource being consumed?

Maybe the device class can define a backdoor command that lets a client query a list of resources and their types and measurements, which can be used by the auto-generation system to allow the user to select particular ones, and that can be set up with the appropriate title and usage units for display and that sort of thing. Of course some of those could be summary values if the device supports it (or the driver creates them itself.)

For that matter that list could be used dynamically at viewing time as well, you could let the user select a resource and display it by updating field associations dynamically.

And this would allow this device class to be used for any sort of resource consumption, water, power, whatever. I think that would be a pretty generic scheme that could support what you want plus other things, right?

[znelbok]

with reference to this thread - http://www.charmedquark.com/vb_forum/sho...p?p=154040

I dont know a lot about metering, I do have mine in place at the moment connected to CQC via a PLC (Pulse inputs)

When you reference the API/docs they have it looks like there are quite a lot of variable to be considered
Voltage, Current, Max Demand, KWhr (interval, daily), interval, Power factor, No. of phases, Power (real, apparent)

In my case I look at the daily total (kWh), interval totals (kWh), and cost

[Dean Roddey]

I guess that's also a good reason to try to keep this more generic, so that it doesn't have to provide any fixed set of values. It can just advertise what values it provides, a description of what the value represents, and the units its in (mainly just for display purposes.)

Then each driver can expose whatever it has available, and clients can make use of that info however they want.

[Dean Roddey]

I updated it to be a generic resource monitoring device class, so that it can represent any sort of resource usage in a way that can be easily incorporated into auto-generated content.

Does it make sense as I described it?

[Dean Roddey]

I updated this one a bit to better define the common scenarios. I'm looking at a new Brultech GEM module driver and it really does lend itself to a multi-unit type naming convention, which I'd originally said wasn't used by this device class. But in a case like the GEM, which offers multiple channels, each of which provides the same measurements. it makes use to use sub-unit naming and let the user/device provided name to be the sub part and the field names for each sub unit to be the (identical, repeated) values provided.

If it's just a free form type of thing, where each value is really a separate thing, not really a set of repeated values, then don't use the sub-unit naming. Sub-unit is only ever valid when all sub-units have identical values.