Brultech ECM-1240 Energy Monitor

Mr G…
Hope your holiday was good, and santa brought you all sorts of new toys to play with.

I have a “curve ball” i want to throw at you:

As you know we have an EtherX (Zigby to ethernet) gateway talking to two ECM1240s. Everything is working like a charm.

I now want to connect a third and fourth ECM to our VERA. THe issue is that the physical location of the circuit breaker panels is too-far from the currently provisioned EtherX gateway. (no zigby comms).

So i would like to use a Serial to IP server, or a second EtherX gateway. (most likely a Serial IP server as our private LAN is available at the location of these additional breaker boxes we wish to monitor)

  1. Can i provision/install TWO (or more) Brultech Plugins at the same time on Vera UI4? Each with different interface?
  2. What would be the possibility of aggregating all ECMs (even if coming in on different interfaces, thus requiring different/seperate plugin instances) to one Total, such as can be done now with multiple ECMs coming in on a single interface?

Let me know your thoughts and how best to proceed. (PS: #2 above is not even a requirement, but simply a “wondering”)

Thanks
Sean

Sean,
You can run as many discrete Brultech [“parent”] Devices off of the same Plugin code as the Vera will support. I currently have one Vera Device, supporting 2x ECM-1240’s, just as your setup, with 50sec samples across 14 Brultech sensors (7x per ECM-1240) and it works just fine (barring the occasional crash of UI4 itself, something that’s just been fixed in UI5)

If you cannot run on the same channel (EtherX, Bridged Serial etc) then you’ll have to fire up another device, but can use the same Plugin code (so you needn’t upload that again or anything). Technically speaking, it’ll crash UI4 less often if you split it out in the manner you describe for the 3rd ECM-1240.

You can only aggregate values from the same Device though, as I don’t [currently] have any form of cross-device aggregation (although someone wanted that for something else, so an Aggregation plugin could technically be built)

Hello All,

I was torn between posting this question in the PowerMeasuring topic, or in this Brultech topic, and chose this topic, as i felt is was “closer to home”

At any rate, i was wondering if any has had any experience with the ERGY Lite relative to data gather/reported by Mr. Guessed Brultech pllugin…

Specifically: Are there any changes that need to be made to the Ergy Plugin once it is downloaded/installed as part of the Ergy activation?

Also: Mr Guessed, do you know if anyone has tested your plugin on UI5? If so, any issues?

Thanks in advance for your support and advice.

Regards
Sean

[quote=“smilligan, post:63, topic:167492”]Also: Mr Guessed, do you know if anyone has tested your plugin on UI5? If so, any issues?

Thanks in advance for your support and advice.

Regards
Sean[/quote]
I’ve fired it up in a rudimentary form to validate that UI5 was “basically” working, but I’m not running it daily (yet).

It’s likely that issues will only be found once it’s being run full-time, as others have found with the different plugins from apps.mios.com/UI5. Unfortunately I’m a little underwater work-wise for the next few weeks, so Plugin updates/validation and UI5 “fix ups” will be slow.

You’ll want to split any ERGY questions out, and post them separately in the other area. There have been several performance-related items noted against that extension, notably on Vera2 boxes. I haven’t enabled it [yet] on my Vera3, since my focus is on building single-source UI4/UI5 compatible plugins (which is harder than it should be)

Looks like the Brultech lads posted some images of the new GreenEye model over on their forums:
http://brultech.com/home/community/viewtopic.php?f=3&t=437&sid=81683df8b5060e77318f7df8bac2edbe&start=20

it looks great.

Mr. G.

I have Vera2/UI5 host that i wish to test your latest brultech plugin.

I have read the posting Brultech Power Monitor and there is a reference to UI5

In addition, Vera will also report your data up so you can see it under the Energy Usage tab of your cp.mios.com account, or to the ERGY Plugin of UI5/Vera3.

but the link for installations reference UI4

For UI4 Installation, please follow the UI4 Installation procedure

Does one code/install link “fit all”? For my test bed (Vera2/UI5) do you recommend a different installation process, or can i simply install using the UI4 install at Installation-UI4 – Brultech Power Monitor

Thanks in advance for your support.
Sean

The same codebase works on both UI4 and UI5

Mr G,
Thank you for the clarification.
Installed the 0.1.5 version on our VERA2/UI5.
Installed without a hitch.
Thanks again for all of your support.
Sean

Mr G,
We have Vera2/UI5 (1.5.286)

The latest Brultech plugin is installed and configuration was complete on Mar 7.

All data is showing up realtime in all 7 metered channels, as well as the primary plugin aggregator.

At first we were able to view realtime data into the Energy Tab. But we would get “Invalid data rxd” when trying to look at history.
Now we get the “Invalid Data Rxd” on both real-time and historical views with the UI5.Energy interface pages.

It seems that the “Invalid Data Received” messages from the MIOS portal… So i have no idea where to even start on this.

Any pointers would be greatly appreciated.

Thanks
Sean

There are definitely a number of problem in UI5’s energy monitoring functionality. A number of folks across the boards have indicated the errors your seeing, and I’ve seen them myself, even without trying to get into ERGY (which has its own set of problems)

Since these components of the system are a black box, and they were working under UI4, it’s going to need the MCV team to diagnose.

I recommend you file a trouble ticket against them to get it prioritized for research.

Mr G,
Thanks for the quick reply.
As per your suggestion, i have opened up a ticket with MCV/Mios about this issue.
I will let you know what they say.

Thanks
Sean

Mr G,
Was wondering if you had considered adding various logging levels to the brultech plugin.
It seems to be pretty stable, and it would be nice to be able to turn off some of the logging…

Thoughts?
Sean

Hey Sean,
Unless you have Verbose logging, or MiOS log code 50, enabled in Vera the plugin should only emit messages @startup. Are you seeing these at other times?

I’d prefer to lock to the Vera log debug level, as there’s an existing way for users to enable/disable through the standard UI.

Mr G,
This is a recent VERA2 to UI5 upgrade.
With your latest plugin.
Verbose logging is disabled, but i cannot speak to “code 50” setting as i do not know how to set that.
We have enabled “show polling” and “show individual jobs”

What follows is what we see in the LuaPnP.log file: (maybe it is the “code 50” but i am not sure how to disable this)

Thanks in advance for your support.
Sean

06 03/14/12 20:38:36.489 Device_Variable::m_szValue_set device: 4 service: urn:micasaverde-com:serviceId:EnergyMetering1 variable: Log was: 250,283,293,1331779096,497 now: 248,281,293,1331779116,517 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x540c>
06 03/14/12 20:38:36.491 Device_Variable::m_szValue_set device: 4 service: urn:brultech-com:serviceId:PowerMeter1 variable: Volts was: 123 now: 123 #hooks: 0 upnp: 0 v:0x827418/NONE duplicate:1 <0x540c>
50 03/14/12 20:38:36.494 luup_log:4: Brultech PowerMeter: debug: processIncomingText:: Buffer=Host: my1240.com, Length=16 <0x540c>
50 03/14/12 20:38:36.495 luup_log:4: Brultech PowerMeter: debug: Skipping buffer=Host: my1240.com <0x540c>
50 03/14/12 20:38:44.968 luup_log:4: Brultech PowerMeter: debug: processIncomingText:: Buffer=GET /usr/ba/dev.php?sec=883922&v=1226&c1w=222&c2w=&wsa1=358323980&wsa2=81816289&wsap1=7515586&wsap2=29694&A1w=10&A1ws=19231168&A2w=170&A2ws=90704082&A3w=&A3ws=91846245&A4w=&A4ws=43022603&A5w=26&A5ws=152013077&dev=30049&id=1&Resp= HTTP/1.0, Length=238 <0x540c>
50 03/14/12 20:38:44.970 luup_log:4: Brultech PowerMeter: debug: decodeBufferText: buffer=sec=883922&v=1226&c1w=222&c2w=&wsa1=358323980&wsa2=81816289&wsap1=7515586&wsap2=29694&A1w=10&A1ws=19231168&A2w=170&A2ws=90704082&A3w=&A3ws=91846245&A4w=&A4ws=43022603&A5w=26&A5ws=152013077&dev=30049&id=1&Resp= <0x540c>
50 03/14/12 20:38:44.973 luup_log:4: Brultech PowerMeter: debug: Serial#30049, 123v, Seconds 883922, Channel 1=358323968ws, Channel 2=81816288ws, Polar Channel 1=7515586ws, Polar Channel 2=29694ws, Channel 1=222W, Channel 2=0W, Aux1=10W, Aux2=170W, Aux3=0W, Aux4=0W, Aux5=26W <0x540c>
06 03/14/12 20:38:44.974 Device_Variable::m_szValue_set device: 5 service: urn:micasaverde-com:serviceId:EnergyMetering1 variable: Watts was: 222 now: 222 #hooks: 0 upnp: 0 v:0x827060/NONE duplicate:1 <0x540c>
06 03/14/12 20:38:44.975 Device_Variable::m_szValue_set device: 6 service: urn:micasaverde-com:serviceId:EnergyMetering1 variable: Watts was: 0 now: 0 #hooks: 0 upnp: 0 v:0x827060/NONE duplicate:1 <0x540c>
06 03/14/12 20:38:44.976 Device_Variable::m_szValue_set device: 7 service: urn:micasaverde-com:serviceId:EnergyMetering1 variable: Watts was: 10 now: 10 #hooks: 0 upnp: 0 v:0x827060/NONE duplicate:1 <0x540c>
06 03/14/12 20:38:44.977 Device_Variable::m_szValue_set device: 8 service: urn:micasaverde-com:serviceId:EnergyMetering1 variable: Watts was: 170 now: 170 #hooks: 0 upnp: 0 v:0x827060/NONE duplicate:1 <0x540c>
06 03/14/12 20:38:44.977 Device_Variable::m_szValue_set device: 9 service: urn:micasaverde-com:serviceId:EnergyMetering1 variable: Watts was: 0 now: 0 #hooks: 0 upnp: 0 v:0x827060/NONE duplicate:1 <0x540c>
06 03/14/12 20:38:44.978 Device_Variable::m_szValue_set device: 10 service: urn:micasaverde-com:serviceId:EnergyMetering1 variable: Watts was: 0 now: 0 #hooks: 0 upnp: 0 v:0x827060/NONE duplicate:1 <0x540c>
06 03/14/12 20:38:44.979 Device_Variable::m_szValue_set device: 11 service: urn:micasaverde-com:serviceId:EnergyMetering1 variable: Watts was: 26 now: 26 #hooks: 0 upnp: 0 v:0x827060/NONE duplicate:1 <0x540c>
06 03/14/12 20:38:44.981 Device_Variable::m_szValue_set device: 4 service: urn:micasaverde-com:serviceId:EnergyMetering1 variable: Watts was: 248 now: 248 #hooks: 1 upnp: 0 v:0x827060/NONE duplicate:1 <0x540c>
06 03/14/12 20:38:44.982 Device_Variable::m_szValue_set device: 4 service: urn:brultech-com:serviceId:PowerMeter1 variable: Volts was: 123 now: 123 #hooks: 0 upnp: 0 v:0x827418/NONE duplicate:1 <0x540c>
50 03/14/12 20:38:44.985 luup_log:4: Brultech PowerMeter: debug: processIncomingText:: Buffer=Host: my1240.com, Length=16 <0x540c>
50 03/14/12 20:38:44.986 luup_log:4: Brultech PowerMeter: debug: Skipping buffer=Host: my1240.com <0x540c>

Mr. G,
Now that i think about, i suspect the “code 50” that you refer to is the “log polling activity” which would cause the device to log as it does in LuaUPnP.log.
Am I close?

Thanks
Sean

Short version…
It looks like code [tt]50[/tt] is part of the “standard” logs that are emitted in regular logging configuration so I’ll need to change that.

Detailed version…
Each log like is coded, and it’s the # that appears at the beginning of each log line. These codes are explained here, along with the [tt]LogLevels[/tt] configuration parameter that sets them up:
http://wiki.micasaverde.com/index.php/Luup_Loglevels

When you select Verbose mode, it puts a # (comment) in front of this line in [tt]/etc/cmh/cmh.conf[/tt], but without that it’ll display the log entries outlined in this parameter.

On a Vera3 unit, the defaults are:
[tt]LogLevels = 1,2,3,4,5,6,7,8,9,50[/tt]

Since I’m logging to [tt]50[/tt] for my debug calls, they’re coming out unconditionally. I’ll switch them to [tt]35[/tt] (debug) at some point and they’ll follow this config correctly.

Thanks for this update. No rush…
Kind Regards
Sean

Mr G.
We upgraded a VERA from UI4 to the latest UI5 (1.5.346)
This VERA previously had the Brultech plugin installed under UI4.
Prior to upgrading, we deleted the Brultech plugin.
Then SSH in and deleted all files from /etc/cmh-ludl that belonged to Brultech.
We then upgraded to UI5
Then installed Brultech plugin from the apps UI5 page.
All went well, and we assigned the Serial port to the plugin.
All seemed to go OK, but the PLUGIN is not showing any V or W for the any of the monitored channels. (we have another similar installation that is working fine under UI5)

We get this in the logs (see under signature line), and am wondering if the “partial row received” message is some how a corrupt message that keeps the plugin from doing its job?

Any pointers are greatly appreciated.

Thanks sean

50 03/21/12 12:29:16.162 luup_log:55: Brultech PowerMeter: debug: processIncomingText:: Buffer=Host: 192.168.30.11, Length=19 <0x4813>
50 03/21/12 12:29:16.163 luup_log:55: Brultech PowerMeter: debug: Skipping buffer=Host: 192.168.30.11 <0x4813>
50 03/21/12 12:29:26.116 luup_log:55: Brultech PowerMeter: debug: processIncomingText:: Buffer=GET /usr/312484/dev.php?sec=12085261&v=&c1w=&c2w=&wsa1=14334404593&wsa2=106125812&wsap1=22028595&wsap2=19661329&A1w=&A1ws=380019114&A2w=&A2ws=1773764640&A3w=&A3ws=354787998&A4w=&A4ws=3318523586&A5w=75&A5ws=1830658283&dev=12484&id=3&Resp= HTTP/1.0, Length=246 <0x4813>
50 03/21/12 12:29:26.118 luup_log:55: Brultech PowerMeter: debug: Partial row received, skipped=sec=12085261&v=&c1w=&c2w=&wsa1=14334404593&wsa2=106125812&wsap1=22028595&wsap2=19661329&A1w=&A1ws=380019114&A2w=&A2ws=1773764640&A3w=&A3ws=354787998&A4w=&A4ws=3318523586&A5w=75&A5ws=1830658283&dev=12484&id=3&Resp= <0x4813>
50 03/21/12 12:29:26.142 luup_log:55: Brultech PowerMeter: debug: processIncomingText:: Buffer=Host: 192.168.30.11, Length=19 <0x4813>
50 03/21/12 12:29:26.143 luup_log:55: Brultech PowerMeter: debug: Skipping buffer=Host: 192.168.30.11 <0x4813>
50 03/21/12 12:29:36.126 luup_log:55: Brultech PowerMeter: debug: processIncomingText:: Buffer=GET /usr/312484/dev.php?sec=12085271&v=&c1w=&c2w=&wsa1=14334404593&wsa2=106125812&wsap1=22028595&wsap2=19661329&A1w=&A1ws=380019114&A2w=&A2ws=1773764640&A3w=&A3ws=354787998&A4w=&A4ws=3318523586&A5w=74&A5ws=1830659033&dev=12484&id=3&Resp= HTTP/1.0, Length=246 <0x4813>

Sean,
There are no “volts” in the response, so it’s considered invalid in the Plugin’s code. There’s something amiss with your Brultech ECM-1240 device.

You’ve had a similar problem to this sometime in October last yr. We discussed it in an email series entitled:
ECM1240 and no voltage reading…

Here’s the relevant snippet from when it occurred that time around, not sure if you’re seeing a similar problem now:

IT turns out that something “flakey” happened with the ECM that caused the PT Range setting to change. (normally it is 3, but somehow got set to 67) This caused the voltage to be = ‘’” ... ..., we have changed the PT settings back to what they should normally be, and all is OK now.

Mr G.
Thanks for this update… I am thankful your memory is much better than mine.
We will update the ECM’s PT value and hopefully that will fix the problem
Thanks again for your support.
Sean