Gem binary formats and btmon.py

[nbegin]

Hi mwall, ben; have either of you experienced your GEM sending $ signs for the binary packets. I tried all the binary formats and just get $ signs. btmon obviously errors when not getting the required 0xfe, 0xff headers.

[mwall]

the $ is the keepalive character - the gem sends this to keep its connection to the serial-to-ethernet/wifi device.

is the gem in real-time mode? i think the gem sends the keepalive character only when it is not in real-time mode. if you run the gem *not* in real-time mode, then you must run btmon.py in polling mode by specifying a polling interval.

here is the easiest way to get up and running:

1) put the gem in server mode, listening on port 5000

2) set the packet type to green-eye binary with date

3) put the gem in real-time mode, emitting a packet every 10 seconds

4) do a quick test by running btmon like this:

Code: Select all

btmon.py --device-type gem --ip --ip-mode client --ip-host X.X.X.X --ip-port 5000 --print

5) put this into the file config.cfg:

Code: Select all

[source]
device_type = gem
ip_read = true
ip_host = X.X.X.X
ip_port = 5000
ip_mode = client
[seg]
smartenergygroups_out = true
seg_upload_period = 60
seg_token = XXXXXXX

6) start btmon like this:

Code: Select all

btmon.py -c config.cfg --print --debug

once everything works, remove the --debug.

[nbegin]

Thanks. Sending Real-Time was the key. Odd, though, all the readings are negative values in btmon where as they are positive in the GEM setup app. Is that normal?

[mwall]

are all of the readings opposite from what you see in 'greeneye monitor setup', or only some of them?

are the magnitudes the same even when the polarity is not?

which firmware version is the gem running?

i have seen the difference in polarity that you describe. with firmware 1.59 it has not been consistent - some channels are opposite, others are not. with firmware 1.63 the polarity seems to be consistently opposite.

the math used by btmon is described in this thread:

http://brultech.com/home/community/view ... f=29&t=530

i am pretty sure that greeneye monitor setup is not doing any calculations, but simply displaying values from the gem (ben would have to confirm this).

greeneye setup 1.9
com firmware 1.63
btmon 3.0.3

[nbegin]

All the values are the same just with opposite polarity. I'm running:

Comm v1.65 / Engine v1.37 and btmon 3.0.3 as well.

[mwall]

apparently btmon interprets the polarized watt-seconds counter differently than the gem firmware.

btmon interprets an increase to the polarized watt-seconds counter as 'positive' energy.

Code: Select all

positive_kwh = polarized_ws / 3600000
negative_kwh = (absolute_ws - polarized_ws) / 3600000
total_kwh = positive_kwh - negative_kwh
total_kwh = (2 * polarized_ws - absolute_ws) / 3600000

the gem firmware seems to interpret an increase to the polarized watt-seconds counter as 'negative' energy.

Code: Select all

total_kwh = (absolute_ws - 2 * polarized_ws) / 3600000

perhaps ben or paul could confirm this?

there are a few ways to flip the polarity:
- change the CT orientation
- reverse the CT leads
- reverse the polarity on the gem for each affected channel
but none of these will resolve the difference between what btmon reports and what greeneye monitor reports.

to achieve consistency with the gem firmware (and the forthcoming brultech home server?) the values from btmon should probably be inverted. however, btmon uses the same calculations for the ecm-1240. i will have to see if this difference exists between btmon and the brultech software that communicates with the ecm-1240 or ecm-1220.

[ben]

perhaps ben or paul could confirm this?

there are a few ways to flip the polarity:
- change the CT orientation
- reverse the CT leads
- reverse the polarity on the gem for each affected channel
but none of these will resolve the difference between what btmon reports and what greeneye monitor reports.

to achieve consistency with the gem firmware (and the forthcoming brultech home server?) the values from btmon should probably be inverted. however, btmon uses the same calculations for the ecm-1240. i will have to see if this difference exists between btmon and the brultech software that communicates with the ecm-1240 or ecm-1220.

Confirmed, to go from positive or negative, you reverse the polarity of the channel.

Ben

[mwall]

here are results of some polarity tests on a gem.

channels 31 and 32 are each monitoring a 110V circuit, each with a split 100 CT. each circuit is on a different leg of a single-phase panel.

each CT is installed with the L toward the load, i.e. K is toward the breaker, and the arrow points toward the load.

the polarity of each channel is set to 0 (the gem default).

there is a constant load on each circuit of about 250W

the sign of the load on each channel is enumerated in the following table:

Code: Select all

channel  btmon  setup  list  seg  APIWAT
31       -      +      +     +     +
32       +      -      -     +     -

so the only unexpected behavior is that the value for seg (calculated by the gem) is positive for both channels whereas the realtime, list, and APIWAT values have opposite signs.

the calculation of positive/negative used in btmon dates back to the pattern defined in ecmread 0.1.4.

btmon - output from btmon using binary packets
setup - output from the realtime panel of 'greeneye monitor setup'
list - list format from gem using btcfg.py
seg - seg format from gem using btcfg.py
APIWAT - output from gem using the APIWAT command in btcfg.py

btmon: 3.0.3
green-eye monitor setup: v1.9
com firmware: 1.63

[j0dan]

I set all my channels to net metering to solve this problem.