Raspberry Pi or Other Lightweight Monitoring Computer?

[Exten]

I heard a rumor that Brultech is working on a self contained little monitoring computer.
I hope it could be mounted inside my GEM.

I could do it with a raspberry pi - but does Brultech have anything in the works?
I'd love to Beta Test if so.

[ben]

I heard a rumor that Brultech is working on a self contained little monitoring computer.
I hope it could be mounted inside my GEM.

I could do it with a raspberry pi - but does Brultech have anything in the works?
I'd love to Beta Test if so.

It has its own case as there's not enough room in the GEM case.

You could rig up a Raspberry Pi with btmon.py using COM1 or COM2 and a Serial-to-USB or RS232 shield, I don't think it'd fit into the case though as they're a bit bigger then our Ethernet modules.

[Exten]

Any pictures of the unit? Perhaps I'd rather stay with the Brultech monitoring computer
after all. Need to see it or get one and work with it - thx Ben.

[ben]

Any pictures of the unit? Perhaps I'd rather stay with the Brultech monitoring computer
after all. Need to see it or get one and work with it - thx Ben.

Attached one.

Ben

[Exten]

Sold! I'll get with sales in a week or 2...hope you'll have one for my GEM zigbee.
I also have an ECM-1240 (non zigbee) and will be getting another ECM-1240 Zigbee unit.

So in addition to collecting and totalizing data for the GEM unit, can it also
ride herd on the other 2 1240 units? Maybe I would actually need 2 of these little computers?

Thx.

[ben]

Sold! I'll get with sales in a week or 2...hope you'll have one for my GEM zigbee.
I also have an ECM-1240 (non zigbee) and will be getting another ECM-1240 Zigbee unit.

So in addition to collecting and totalizing data for the GEM unit, can it also
ride herd on the other 2 1240 units? Maybe I would actually need 2 of these little computers?

Thx.

Should be fine with the 2 ECM-1240 units, it should hold about a years worth of minute data (you can manually clear minute data, hour data is kept for historical readings).

There's some small issues with Zigbee we're resolving currently, but the Zigbee version should be available soon.

Ben

[Exten]

Okie dokie.....I'll get back w/sales in a couple weeks - put me in line for a zigbee unit.
Thank you.

[BaselineSolar]

Hey guys -
I've actually been experimenting with interfacing the Raspberry Pi and the ECM 1240. I have had terrific success with btmon.py receiving data via TCP/IP (through the etherbee on the network).

The simplest, ideal setup for any small computer receives data over wired serial communication and broadcasts to the network/internet wirelessly (wifi).

Be advised that the USB to serial data communication on the RPi has some serious unresolved issues. I think the only current option is to interface directly into the RPi through UART with an inline voltage regulator (3.3V max) so as to not overload the board (I still have not tried this). I have also had issues with powering wifi usb adapters without an extra powered USB hub. I really wanted to try to get this working without the etherbee (because it adds $100 to the system) but it seems like it is the easiest way to get the data into the pi. I would be curious if anyone else on the forum has made similar trials.

Regardless, kudos to Brultech for designing their own monitoring computer. I hope its a success!

- Ryan

[Exten]

Are you using a Rev. A or a B model Pi? My B model is still on back order.
If I do a Pi I'll probably make the data available via SNMP because the whole
charting/graphing world opens up once your data is available via snmp.
There's alot of tools that can do snmp queries and produce graphs.
If it will compile and run on a Pi, that is, who knows.

Most likely I'll end up with both the Brultech monitor and maybe the
home built custom solution too.

[Dominique]

Hi all,

I am also successfully using btmon.py with a Raspberry Pi and an ECM-1240, uploading to various online services: PlotWatt, Bidgely, Smart Energy Groups, COSM. Not sure which I will retain in the end (this could be another post...).

Using Ben's suggestion, I went with a USB-to-serial adapter having a FTDI chipset. A friend of mine gave me one he was not using. It is out of production (http://www5.ncix.com/products/?sku=17281), but uses FTDI's FT232R chipset. Note that it is not trivial to find a USB-to-serial adapter using such chipsets: when online vendors bother mentioning what chipset is used, it often ends up being a Prolific, which we are told to avoid with ECM-1240 as they seem unreliable.

So when I connected this FTDI-based adapter to the Raspberry Pi (without connecting to ECM-1240, initially), it was instantly recognized by the OS - Raspbian - getting exposed as /dev/ttyUSB0. At first, however, the OS crashed as soon as I tried accessing it (e.g.: ls > /dev/ttyUSB0). After some forum-reading, I found the solution: the USB ports had to be set to USB1 mode. This workaround does sacrifice speed, of course, but in my situation this was unimportant and I didn't want to get lost trying to get involved to fix this apparently faulty driver.

To control this USB mode, I had to change /boot/cmdline.txt, adding dwc_otg.speed=1:

Code: Select all

dwc_otg.lpm_enable=0 dwc_otg.speed=1 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

After changing this, one reboot proved the fix was working. I was able to use stty with the device, and able to feed data to it. I then proceeded to connect the ECM-1240 to it. Since this was done, a week ago, the communication between Raspberry Pi and the ECM-1240 has been perfect. Not one crash or drop.

One thing that was scary at first: my ECM-1240 came with the real-time mode set to on, with a period of 1 second. This means it emits one packet of information every second. Trying to use btcfg.py to turn this mode to off (so I could read the meter's setup info) required lots of attempts. It seemed the "off" command sent by btcfg.py for this purpose was always colliding with the incoming packet, resulting in apparent transmission errors. After dozens of tries, I was eventually successful. There was not much I needed to do with btcfg.py anyways - other than satisfy my curiosity - since people at Brultech had already kindly configured the channels to match the CTs I had purchased with the monitor.

Hope this information is useful to someone!

Dominique