GEM and btmon.py data drops

[ian351c]

Hello all,

I recently purchased and installed a shiny new GEM in my basement. It's been a fun project to see where all my electricity is going! Right now I have it running with btmon.py over ethernet and a local installation of Emoncms on FreeBSD. I have a few questions about getting the most out of my GEM, but since they're not all related, I'll do one topic at a time.

Today's topic: I am seeing the same issue pointed out in this thread: http://www.brultech.com/community/viewt ... der0#p4658

My GEM sends the invalid packet once out of every 38 times, just as described in the thread. This causes btmon.py data retrieval to pause for 60 seconds. My GEM is in real time mode and the btmon.py script connects to it via IP. Firmware versions on the GEM are COM: 4.0 and ENG 1.49.

Is this an issue on the GEM side and if so can it/will it be fixed?
If this is an issue on the btmon.py side, does anyone have any advice for fixing the issue, or at least configuring it to minimize the pause?
Also, is it possible to get data from the GEM directly to emoncms via an HTTP POST? It seems like it should be possible, but I can't find any documentation on it.

Thanks!

Ian

[ben]

Can you make sure that you don't have auto reset enabled on whichever COM port you're connected to?

It's possible to have the GEM send directly, but you're better off using btmon.py IMO. The direct send method has the chance of missing data if a packet doesn't get through.

A temporary workaround, find the line:

Code: Select all

# how long to wait after a failure before attempting to read again, in seconds
RETRY_WAIT = 60

And try changing it to 5 seconds or so.

We'll look into it to see if we can reproduce the issue.

[ben]

What packet format are you using?

[ian351c]

I double checked the GEM settings and the Auto Reset Timer is set to "0" for COM1 and COM2.

Thanks for the hint on the btmon.py settings. That is much better than waiting 60 seconds.

Let me know if there's anything I can do to help with the testing.

Thanks!

Edit: just saw your second reply. Packet format is BIN-48-Net-Time.