Brultech ECM-1240 Energy Monitor

Plugins & Plugin Development General Plugin Discussion
21

@guessed,
In our typical ECM1240 deployment we use one channel (normally CH1) with split cores to monitor split-phase 240v on MAINs feeding the circuit breaker panel.

The problem that this represents for is that the total power shown in the parent Brultech device is “doubled” as the mains (which are channel 1) are added to the 6 other inputs (CH2 and AUX1-5).

It would be great if in future release you could add field to the parent Brultech device that allowed the integrator to specify which channels (comma separated string list) to aggregate in total power. So, for example, in our case, we would simply set this field to “1” which would be the channel that is connected to the Main and thus avoid “doubling” the total power shown. And “0” or Blank would mean ‘do not aggregate’ in which case the user of the UI would simply look at Meter input that is known to be tied to the mains to get “total” power consumption.

All in all looking great!!

Thanks
Sean

22

That’s always good to hear! You’re the second deployment of this code, after me, so it’s bound to have some rough edges on it.

Post a picture when you get a chance, and have some data behind it of course 8)

1) Is there anything in your plugin that will preclude me from using description other than "Brultech"? In other words, for future installs can i use any description i wish when creating the device?
Nope, you can label it whatever you want, but I like to be explicit in the instructions so that people have a step-by-step. You can change it afterwards also, by going into the Device's Dialog, and "clicking" on the Device Name string in the Top-left.... then (Save) afterwards of course...
2) Can i change the name of the individual sensors from Meter1 etc.. to more descriptive names?
They can be changed the same way as described above, using the Dialog for each. They're only populated during initial Device creation, so I needed some placeholder names.
So far, it looks really impressive. When do you expect your next release?
No idea. I generally do things when I need them, or when someone expresses a desire (that's readily implementable). For the moment, I have two units, but only one is wired and it's only wired to a test-rig (2 channels, low wattage)

The next logical steps would be:
a) Add support for the Binary mode (since that’s the default)
b) Add support for 2 or more ECM-1240’s on a single Serial bus (they multiplex them with a Serial#)

Haven’t been pushed to do these yet, since I’m working on something else at the mo (a Native SMS Plugin)

Let me know what specifically you’re looking for, and we can see how that’s going to work. The next few weekends are busy so it may wait a little.

23

[quote=“smilligan, post:21, topic:167492”]@guessed,
In our typical ECM1240 deployment we use one channel (normally CH1) with split cores to monitor split-phase 240v on MAINs feeding the circuit breaker panel.

The problem that this represents for is that the total power shown in the parent Brultech device is “doubled” as the mains (which are channel 1) are added to the 6 other inputs (CH2 and AUX1-5).

It would be great if in future release you could add field to the parent Brultech device that allowed the integrator to specify which channels (comma separated string list) to aggregate in total power. So, for example, in our case, we would simply set this field to “1” which would be the channel that is connected to the Main and thus avoid “doubling” the total power shown. And “0” or Blank would mean ‘do not aggregate’ in which case the user of the UI would simply look at Meter input that is known to be tied to the mains to get “total” power consumption.[/quote]
You wish has been granted. 8)

It already has code to handle that, but I just haven’t documented it. Each child Meter object has a setting, in it’s Device Dialog, as to whether the Parent “Total Watts” value should Include (add), Exclude (subtract) or Do nothing (ignore) the value from the Total wattage calculated.

In your specific deployment, you can use this to “Ignore” the value for Meter-1. If you have a Solar array, you can use it to offset the Total wattage.

I borrowed the idea from @futzle’s implementation for the CurrentCost plugin, although my UI implementation is different.

24

guessed,
Thanks for this info.

I am trying to remove the CH1 wattage value from the parent Brultech aggregate, but am confused…

When you say “Device Dialogue”, i assume you mean the “Advanced Tab” for the device… (accessible via the UI4 “tool” icon for device)

But in the “Advanced Tab” for the child meter devices, i cannot find any reference to a field/variable that would allow me to include/exclude a child meter’s value from the brultech parent aggregate.

Can you tell me what i might be doing wrong?

Thanks
Sean

25

Each Meter-n Device has it’s own Wrench/Spanner. This activates it’s own Device Dialog.

On the Control tab on that dialog, you’ll see the options to tt/(Subtract) or (Ignore)[/tt] the Wattage value under the “Include in Total Watts” heading.

See attached.

26

Guessed,

I understand that you currently do not have the ability to handle multiple ECMs.

If you would like to work with us to test a Multi-ECM setup via Etherbee gateway let me know…

In our lab/demo area we have 2 x ECM1240s that are zigby back to an Etherbee gateway. The setup of these two ECMs is as PnP to log the HTTP to the My1240 web site.

The thought is that you could use our current hardware configuration to develop/test a multi ECM setup via IP interface back to Vera. We could give you VPN access to our network and SSH/Web to the VERA itself. We could then redirect the EtherBee gateway to send the IP HTTP traffic to the vera host for parse.‘’

I believe our current configuraiton is 7 cahnnels on one ECM and 5 channels on the 2nd ECM.

If you are interested in using our demo/lab as test bed for this effort let me know.

Thanks
Sean

27

I have the same hardware (2x Etherbee enabled ECM-1240’s), so it’s more of a “time” thing than anything. Wiring the test-rid is the easy part.

Still wrapping my head around how to make it work, cleanly, under Vera given they both have “device 1…7” and it’s just the Serial# that differentiates the feeds, and I didn’t want people keying those in.

28

Guessed,
Our current plugin does not show these buttons on the control tab for “Ignore, Add, Subtract”
Just the

We installed the plugin from the source that was available two nights ago (20JUN11)

Do i need to install new plugin? If so, i have not upgraded plugin before, do i simply need to install the plugin again, following original directions and all is OK? Or will i need to delete devices and start over?

Also, is there a version number for plugin that we can track?

Thanks
Sean

29

Oops, I’ve been switching machines and changing SVN (source control) clients so I forgot to Tag the newest release. I’ve now done this, and updated the Wiki instructions and download link.

To update, simply re-download the newest files from the link provided in the Documentation and then re-upload them to Vera. Everything else will just work, and you’ll have the new functionality.

No need to delete the Device, we try to avoid that, since it hoses any scripts you might have built (sometimes it will be unavoidable)

30

Guessed,
That did the trick. Thanks.

Let me know when you are ready to test a MULTI ECM setup on vera. We have lab/trial system in our demo room that is currently logging to my1240 from 2 ECMs via EtherBee gateway. Can point to vera host at any time.

Do not know how you will get around issue of “avoiding” having individual key in serial number to identify different ECMs. One thought (but a lot of work) simply specify port that is monitored, and over one minute period go into “acquire” mode and read the GETs from the device and look for different serial numbers and automatically build devices/meters. (This would assume send intervval of ECM is less than one minute) Only problem with this approach is “equipment swap” when ECM fails and losing historical data, but even ways around that.

Regardless of what you decide, let me know when you are ready for someone to test the change to the plugin.

GREAT WORK!!
Sean

31

Guessed,

It would be nice if we could use VERA not only as realtime view of power consumption, as well as automatic pass up to MIOS, but as a gateway to other richer web services.

Specifically: It is great to see realtime info in vera, and it would be the icing on the cake if you could simply “pass through” the raw PnP string with HTTP parameters (such as is available on Etherbee) to allow us to send the information further up the food chain to other web services.

In our case we want the option to log to “check-it.ca” or “my1240.com” or our own java web service for data accumulation.

What are your thoughts, comments?

Thanks
Sean

32

That’s how I was originally going to handle the Google integration. Basically reconfigure the Etherbee to call Vera, on one of it’s UPnP calls that, in turn, would effectively call an Action on my plugin… And then have the plugin call Google / my1240 / etc…

I decided against that for a few reasons:
A) it puts Vera in the middle of every transaction
These extra ‘hops’ add a certain degree of flexibility, but at the cost of lowered resilience on the overall path to the data being delivered, and I have an architectural pref for things to be autonomous (and keep working if the HA controller goes down, for example)

B) it requires reconfiguration of the Etherbee
Which adds manual configuration steps using a Windows-only tool. This makes it harder for people to just get going, simply. I have most of the code to decode the raw buffers, which is the default for the '1240 so it would be the cleanest route for most users…

Given Google is no longer going forward with PowerMeter, I might as well reconfigure my Etherbee back to it’s default configuration.

Still wrapping my head about how to make it interface cleanly with Vera given multiple 1240’s on a single channel. I have ideas, ones that will work with Vera’s notion of ‘upfront’ Device creation, but folks won’t be able to readily ‘know’ which MiOS device relates to which ECM unit…

33

Guessed,

I decided against that for a few reasons: A) it puts Vera in the middle of every transaction These extra 'hops' add a certain degree of flexibility, but at the cost of lowered resilience on the overall path to the data being delivered, and I have an architectural pref for things to be autonomous (and keep working if the HA controller goes down, for example)

But it seems you must plan for some mechanism to allow “unaltered” ECM data to get beyond the VERA platform. There are many people developing web services around the ECM protocol. Our company is an example.

Also, there is always a weak link in every chain, and yes VERA is the weak link by adding another HOP. However, the beauty of ECM message set is that it supports Watt Seconds in each GET, so regardless of howmany messages are dropped, i can always calculate energy usage between messages.

I guess the question is: Do you intend to “stop” the message at VERA? If so, that pretty much rules us out as we must be able to get the messages to more powerful reporting services, and be forced to configure ECM to point to existing web services where power reporting is richer and has more momentum. Maybe start another “fork”? or?? let me know your thoughts.

One final note: You can simply add a field to the main brultech device that allows the user to specify a “prepended” string to the PnP string, and simply PASS this up the WAN interface if the field is populated (length > 0). Then is available if needed, or not.

B) it requires reconfiguration of the Etherbee Which adds manual configuration steps using a Windows-only tool. This makes it harder for people to just get going, simply. I have most of the code to decode the raw buffers, which is the default for the '1240 so it would be the cleanest route for most users.... Given Google is no longer going forward with PowerMeter, I might as well reconfigure my Etherbee back to it's default configuration.

I did not know Google pulled the plug (no pun intended) on powermeter. Nonetheless there are other services that have been around for sometime that can be used as well… Google Power Meter is not the only service…

Still wrapping my head about how to make it interface cleanly with Vera given multiple 1240's on a single channel. I have ideas, ones that will work with Vera's notion of 'upfront' Device creation, but folks won't be able to readily 'know' which MiOS device relates to which ECM unit...

hmmm… ECM used to “print” serial numbers on the 1240s. These serial numbers were also used in the binary, ascii and PnP message sets. Not sure why they stopped putting Serial #s on outside of unit. At any rate you could always TELL the user to ADD one ECM at a time to the Etherbee network. Once it is added, they can label the device in VERA. Furthermore, you could have somehere in the Plugin primary device the actual serial number that was presented as the PnP data string and instruct the user to “brother label” it to the ECM. And then start on next, etc… Or maybe get Brultech to start labelling the ECMs again with Serial #s… But BOTH of the above assume you have a field in the VERA device that shows the “scraped” serial number as derived from GET. The above is just some thoughts, and i may be WAY off base… Nonetheless, I am very interested in seeing/testing what you develop once you decide the best route for addressing this next phase of your plugin.

In Closing: Your plugin is great!!! You should be very proud of your work. I wish I were as altruistic as you, but unfortunately, my father’s capitalism runs deep in my blood.

Kind Regards

34

It’s not that it can’t be done, it’s just that it’s not my first priority. The best way to do what you’re describing is to outline, and implement, a common UPnP Service that can “send stuff” to remote Power Collection entities.

If this can be standardized, and made neutral of the specific “format” that the data must be sent over the wire (eg, not a URL-like ECM string), then ALL of the Energy Monitoring plugins could call it.

In turn, there would be multiple implementations of this Service, to handle sending stuff to My1240.com, Check-it.ca, etc).

If you build that Service/Device, and it’s vendor neutral, then I’m sure you’ll get all of the Power measurement Plugins connecting to it… meaning you’d not only cover the ECM-1240, but likely the TED5000, and the CurrentCost EnviR…

It’s probably the way that Vera’s own EMonitoring should be done, so we can “unplug” it if folks wanted to (along with plugins for Notification that could be plugged)

BTW, they still write the Serial# on each device, but that’s not the problem. The problem is that the data will come in some unpredictable ordering, and I’ll have to “allocate out” Children to each ECM as it does.

It’ll be first come, first served… at least the first time around.

So the first ECM would get Child devices 1…7, the next would get 8…14, etc, and the user would have to indicate that they have 14 children (as they do today). The problem is that with ECM-1 and ECM-2, you’d never know which one “got” 1…7 and which got 8…14 (etc) - at least not without opening up the Child and looking at it’s properties (where I can store the Serial#)

Not really a big deal, but overall I preference making it simpler for the user (and not having them configure Serial#'s and the like)

35

[quote=“guessed, post:34, topic:167492”]The best way to do what you’re describing is to outline, and implement, a common UPnP Service that can “send stuff” to remote Power Collection entities.

If this can be standardized, and made neutral of the specific “format” that the data must be sent over the wire (eg, not a URL-like ECM string), then ALL of the Energy Monitoring plugins could call it.[/quote]

This is exactly what I recommend. I have a script that bridges Vera to the free sysadmin monitoring software Nagios. It polls a device’s “Watts” variable every minute (this period is configurable) and plops the result into my network status along with ping times and UPS statuses and disk usages.

It’s all done with curl and xsltproc, and the fact that the energy monitor is a CurrentCost EnviR isn’t known to Nagios. Vera abstracts that away.

Anyone who wants the script can PM me.

36
It's not that it can't be done, it's just that it's not my first priority. The best way to do what you're describing is to outline, and implement, a common UPnP Service that can "send stuff" to remote Power Collection entities.

I think one of the problems that might be experienced with this approach is that everyone’s logging requirements might be different relative to the specific power monitoring device. Not that the uPnP forwarding service cannot format the info, but rather the raw info as captured by plugin might “drop” important info that it in turn makes available to the uPnP service.

For example, in the case of brultech, they have a nice piece of info called WattSeconds for each channel. From any logging/reporting service this is probably the most crucial.

My guess is that in your current Brultech plugin you discard that in the stream and just show current wattage of last message set.

So developing uPnP service to “forward info” as gathered by your plugin might not work as expected.

If this can be standardized, and made neutral of the specific "format" that the data must be sent over the wire (eg, not a URL-like ECM string), then ALL of the Energy Monitoring plugins could call it. In turn, there would be multiple implementations of this Service, to handle sending stuff to My1240.com, Check-it.ca, etc).

I see your point, and this makes perfect sense in theory.

If you build that Service/Device, and it's vendor neutral, then I'm sure you'll get all of the Power measurement Plugins connecting to it.... meaning you'd not only cover the ECM-1240, but likely the TED5000, and the CurrentCost EnviR...

I like the way you are thinking, and in theory it would be great to have this uPnP service for each monitoring device and service logging combination. This would allow services (like ours) to monitor record various monitoring hardware via VERA. And it would be great… I wonder that even if you can get everyone to “play nicely” you would find that you have similar data from various monitoring devices that would allow for single point of logging/reporting.

BTW, they still write the Serial# on each device, but that's not the problem. The problem is that the data will come in some unpredictable ordering, and I'll have to "allocate out" Children to each ECM as it does. It'll be first come, first served... at least the first time around. So the first ECM would get Child devices 1..7, the next would get 8..14, etc, and the user would have to indicate that they have 14 children (as they do today). The problem is that with ECM-1 and ECM-2, you'd never know which one "got" 1..7 and which got 8..14 (etc) - at least not without opening up the Child and looking at it's properties (where I can store the Serial#)

Yes, this is the way i would suspect it needs to be done. It may not be plug and play, but it will work and gives you some level of control. Especially from a support perspective when you need to “swap” equipment.

Not really a big deal, but overall I preference making it simpler for the user (and not having them configure Serial#'s and the like)

Wish i could offer up a suggestion to provide this level of Plug/Play operation, but right now my mind is drawing a blank.

Nonetheless, once you have something ready that supports multiple ECMS via Etherbee, let me know. Have “guinea pig” will travel.

PS: We continue to be impressed with your plugin. Thanks for your hard work.

Kind Regards

37

Support added for multiple ECM-1240’s on a single EtherBee or Mux’d Serial port. Changes pushed to the latest over at the home, along with full source code history:

http://code.mios.com/trac/mios_brultech-power-monitor
38

Looks like they stopped selling the Plug & Play packages. Maybe a result of Google PowerMeter going away?

Does anyone know how hard it is to configure a standard package to work with this plugin?

I don’t have MS Windows around, but I’m comfortable configuring things via a serial port. The downloads I can see on the Brultech website look like they are for windows only. Couldn’t find a manual either.

Any pointers on getting this to work now that Plug & Play seems to be gone are much appreciated.

TIA

39

All of Brultech’s current [re]configuration tools are Windows-based.

If you had/borrow a Windows machine, you could reconfigure the ECM-1240 to emit the ASCII format that I’m using, it’s just a few radio button options and you’d have it… even when GPM goes away. The reconfig is really simple (if you have a box to run their tools)

I had a number of HW Devices that all did the same thing (X-CTU for XBee’s, WIZNet for SR110’s, and the Brultech stuff… which partially uses the former) so I broke down and got myself a Netbook. It made things a little easier than running VirtualBox (or whatever) just to get a Windows machine on my Mac.

Anyhow, I have most of the code “inside” the Plugin for handling the Binary format for the non-PnP models, but I’ve never reconfigured mine over to the “default”. With GPM going away, it’s probably a good time to complete that support.

Give me two weekends and I’ll complete (and test) the code so it can work without reconfiguration on the Binary-format models.

40

Guessed,
Hopeful you can help me out with a slight problem.

We have latest vera, with your latest brultech plugin (i think it is latest, as i am not sure what changes you may have made in last few weeks)

Configuration:

  1. Vera
  2. EtherX Gateway
  3. Two ECM1240s connected to EtherX gateway

The brultech plugin seems to work ok for some period of time (not sure how long), but then stops refreshing data. I have found that simply hitting “save” button on VERA web interface seems to wake up the plulgin and i start getting data realtime… at least for a short period. After which point the web UI plugin stops updating and i must click on “Save” again.

I am not 100% positive that the “save” fixes the problem or it is merely coincidental, but it seems to have solved teh problem the last 4 times it has occured.

Any ideas would be greatly appreciated.

PS: we have a USB drive connected to VERA for USB logging and not sure if this new addition might be related to problem. We added USB logging about the same time we noted this strange behavior.

Thanks
Sean