Zigbee Diagnostic - Tracking Data Packets

[Teken]

I wanted to know if there is a method to track the Zigbee data that gets sent to the ISY Series Controller? During the last few years I have been seeing random high value spikes being reported by the ISY.

To date I have not been able to determine how these values can exist but wanted to inquire with Brultech to see if there is some method to track these high levels that seem to appear at random times. Below I will provide some very detailed examples as such and hope they shed some light as to what are the possible root cause.

First I would like to explain what I have done thus far to ensure or at least remove areas of potential concern.

ELECTRICAL SYSTEM:

1. The entire electrical system has been protected by four stages of electrical protection from Type 1, 2, 3, 4.

2. All of the systems are powered by a regulated pure sine wave UPS system.

3. There are filters on many circuits to reduce any RFI / EMI on the line.

4. Most of the circuits in the home are on dedicated lines and share nothing else on them.

GEM CONFIGURATIONS:

1. All of the circuits have jumpers on channels 1 & 2 to reduce any noise.

2. All CT's have been calibrated to reduce the amount of error when a load is presented.

3. The PT Transformer has been calibrated against a high accuracy Fluke true RMS DMM.

4. CT's have been swapped out to see if the noise moves to another circuit, it doesn't.

5. CT's have been replaced and the same random (spike wattage) noise appears on multiple appliances.

6. This noise or random values never appear in the Live View in the GEM.

7. These values are never captured by the Dash Box.

8. I have two data loggers which are monitoring the entire home and individual lines and these spikes are never seen on these monitors.

9. These unknown power values are present even when the breaker has been turned off to the appliance(s).

10. These unknown power values are only known to me because the ISY is sending me a e-mail about them. To date I have not seen these values actually in the ISY UI at all.

WHAT I AM LOOKING FOR:

1. I am looking for some method to track or view the Zigbee data packets from the GEM to the ISY.

2. What could be the root cause of this problem that has persisted over the last few years?

3. Can the GEM be programmed to buffer the signal for a few seconds prior to being sent over to the ISY? Specifically, can a new firmware be created to allow (multiple samples) be done prior to send off?

4. I would like to know how the system handles negative values?

RELATED INFORMATION AND SCREEN CAPTURES:

All of the relevant images and details are posted in my install thread to track my efforts and keep a time line.
http://www.brultech.com/community/viewt ... &start=100

Any insight, guidance, or solutions are most welcome!

[bgrubb1]

Teken
Just as a point of reference, I have the same issue with my GEM / DB / Micasaverde Vera 3 setup
GEM / DB never record the spike, but I occasionally (every couple of days) get a alert from the Vera 3 that one or more of my AC compressors saw a spike (usually > 1 Megawatt)
Even when the AC units are off
I suspect in my case, the GEM is ignoring them, but they still exist in the raw HTTP feed to the Vera 3
..Barry

[Teken]

Teken
Just as a point of reference, I have the same issue with my GEM / DB / Micasaverde Vera 3 setup
GEM / DB never record the spike, but I occasionally (every couple of days) get a alert from the Vera 3 that one or more of my AC compressors saw a spike (usually > 1 Megawatt)
Even when the AC units are off
I suspect in my case, the GEM is ignoring them, but they still exist in the raw HTTP feed to the Vera 3
..Barry

Hey Barry,

I was not aware of this data point impacting your Vera. Would you be able to provide more details about the loads and frequency of what you see either here or via email?




Encrypted By: Phoenix Security Solutions

[bgrubb1]

Will do
As soon as I get a text, will provide details. I have gotten to the point of automatically deleting the text and had planned on turning them off.
I have the alerts set on all 3 AC units with an alert if over 5KW on the 4 ton units and 7 KW on the 5 ton unit. I was seeing them pretty much daily on the AC units when I was using them. Now they are every few days.
In addition I have an alert if Voltage goes below 50 volts that I see once a month or so that I have never seen on the GEM or DB
...Barry

[Teken]

Will do
As soon as I get a text, will provide details. I have gotten to the point of automatically deleting the text and had planned on turning them off.
I have the alerts set on all 3 AC units with an alert if over 5KW on the 4 ton units and 7 KW on the 5 ton unit. I was seeing them pretty much daily on the AC units when I was using them. Now they are every few days.
In addition I have an alert if Voltage goes below 50 volts that I see once a month or so that I have never seen on the GEM or DB
...Barry

Barry,

Yes, I too am seeing the following which is detailed in the install link I provided here.

1. Random high value wattage on multiple circuits. These are the same circuits being impacted all the time and does not appear in other monitored circuits.

This is good because I know its not spreading in that respect.


2. I am seeing low voltage readings being detected but this is much less frequent than the high wattage readings.

3. I am seeing negative values showing up only on the fridge.

4. Items that are being impacted are as follows: Fridge, sump, dryer, solar array, washer, dish washer. These are the same circuits since day one and most of them are on dedicated lines so no cross talk or injection of power from something else being on the line.

5. These values seem to appear in the dead of night or early in the AM. I do recall seeing a voltage drop issue in the Dash Box which Ben indicated was some type of sampling error?

I can't help but think these two things are related some how but have no facts to back it up at this point in time. What is very interesting is that the DB, GEM, has been able to alert me of actual voltage drops when they occur.

I have been able to confirm this via other data loggers which I have in place. What is hard to understand is if this is from a surge / spike in the electrical line why doesn't it send me an (exaggerated) e-mail when these (real) events occur?

One would think that would be the ideal time for a fictitious event to be shown, no? I guess the reason this has been on the back burner for me for so long was that I had so many other elements that needed to be addressed. Since the development of the DB / GEM has been so consistent, and resolved so many other issues, this was not as important and also did not happen as frequently as they did in the past.

Fast forward to now: I am near the critical point in my HA deployment where having accurate information and data is foundation of what I need. I am really trying to avoid having mission critical systems go off line when the condition is not real.

In the big picture I may be asking too much of the system as its not intended as a diagnostic tool or advertised as being sold or capable of mission critical sampling.

I dunno . . .

Maybe its the eat the pie and have it too syndrome!

[ben]

There's no way to really track the packets without either the ISY spitting them out or using a different Zigbee end-point.

You can tap into COM2 (same but that doesn't take into account what the Zigbee module is doing.

What's the Vera3 being fed by?

[Teken]

There's no way to really track the packets without either the ISY spitting them out or using a different Zigbee end-point.

You can tap into COM2 (same but that doesn't take into account what the Zigbee module is doing.

What's the Vera3 being fed by?

Ben,

Is there some method to buffer the data that streams from the GEM's Zigbee radio to the ISY? Right now I am taking a complete wild ass guess here. It appears to me that this is related to the voltage drop issue I wrote about a few months back that some of us were seeing in the DB at like 2-3 AM.

I am also thinking these random and erratic values which I see are related somehow. If there is a method to sample / buffer the data a few times before it gets fired off to the ISY. I truly believe this might address what I have been seeing for the better of two years.

I am sure you have seen the inbound e-mails that I have CC both you and UDI on. So, this will give you an idea of the frequency and time of incident. If this is something Paul can review and come up with some kind of action plan this might resolve this pressing matter.

As always I thank you both!

[bgrubb1]

Ben
In my case the Vera is fed from the GEM via Ethernet / Http Get
No Zigbee for me
.Barry

[bgrubb1]

At 1:41 AM this morning I received the text / email from the Vera 3
Your trigger "MBR_AC_Excessive_Current_Draw" occurred.

The originating device ID:71 03_MBR_AC in room: Power_Meter

The ID is: 4464579041
Code: Watts Value:293720564
Serial #30011809

In looking at the DB graph, no spike seen

[Teken]

Today at 12:20:59 AM I received a text the voltage in the house dropped to 2.72 VAC. The DB indicates also 0 VAC condition? Looking at the actual DB line graph for that time does show a drop in voltage to 104.6 VAC.

I will confirm this from the two other data loggers and report back. What I believe is the system is able to detect extremely fast pulses of line variation. The two devices (appear) to provide a snap shot of that condition even if its exaggerated in this one case.

All other times there have been no collaborating evidence to say either way. I will post up a screen shot later for review etc.