Brultech ECM-1240 Software Development
- Thread starter 3tones
- Start date
It looks the ability to store data in the ECM to download later is the major improvement. Not sure if there are others.
No joy in the firmware install here. Using both methods of reset the flash program will get as far as the "y/n" after pushing the F1 button, but after pushing the button, the DOS screen disappears and nothing is updated.
You are using the RS-232 port?
Are you using RS-232/USB adaptor?
Paul
No joy in the firmware install here. Using both methods of reset the flash program will get as far as the "y/n" after pushing the F1 button, but after pushing the button, the DOS screen disappears and nothing is updated.
You are using the RS-232 port?
Are you using RS-232/USB adaptor?
Paul
Using RS-232 Port without USB adapter.
I'm still using the unit that had its settings corrupted by power flickering, although it appeared to still be working reasonably well on the default cal values. I also tried a reset routine that we had discussed via email prior to attempting an update, but no luck.
I successfully upgraded my ECM-1240 to the new firmware without a problem (after I found the directions). I started to play with the data logging which looks pretty good. I'm tired of losing data because my server reboots or is offline for more than a minute or two. It would be great if once a day it just downloads the info and puts it in the database. I've been digging around the download functionality and here's some questions/discoveries (in case anyone else has dug into them).
1) When downloading data, how are the records indexed? In the resulting CSV, it has date and time, but I assume this is "fake" and it just based on the computer time, since the ECM has no ability to set the time.
2) I've been poking at the serial lines trying to figure out the protocol. I've nailed down how to send the query, and set all the options presented in the dialog box. However, I'm stuck on the data returned. It seems that retrieving 1 record actually retrieves 2, and 2 retrieves 3, etc. I can only assume that it is logging the counters that keep incrementing and 1 "record" as shown in the CSV is actually the difference between 2 data points.
3) The "header" and "footer" of the data retrieved seem to echo back some of the settings for that paticular data retrieval.
Thoughts??? Maybe someone "in the know" could enlighten some of the developers here to kick off some new software features.
1) When downloading data, how are the records indexed? In the resulting CSV, it has date and time, but I assume this is "fake" and it just based on the computer time, since the ECM has no ability to set the time.
2) I've been poking at the serial lines trying to figure out the protocol. I've nailed down how to send the query, and set all the options presented in the dialog box. However, I'm stuck on the data returned. It seems that retrieving 1 record actually retrieves 2, and 2 retrieves 3, etc. I can only assume that it is logging the counters that keep incrementing and 1 "record" as shown in the CSV is actually the difference between 2 data points.
3) The "header" and "footer" of the data retrieved seem to echo back some of the settings for that paticular data retrieval.
Thoughts??? Maybe someone "in the know" could enlighten some of the developers here to kick off some new software features.
Good News!
I've documented enough of the logger protocol to effectively get and decode the data. There are a few things I don't understand (because I didn't program it) but most of it is pretty simple once you get down to it. I'm working writing some documentation for it tonight, and hope to have something for people towards the end of the weekend, including the start of some python code I used to figure it out.
I haven't decided if I am going to post it on the forum or not. If you're interested email me.
Tom
I've documented enough of the logger protocol to effectively get and decode the data. There are a few things I don't understand (because I didn't program it) but most of it is pretty simple once you get down to it. I'm working writing some documentation for it tonight, and hope to have something for people towards the end of the weekend, including the start of some python code I used to figure it out.
I haven't decided if I am going to post it on the forum or not. If you're interested email me.
Tom
A quick update -
I did finish the documentation of the logger download protocol, but I Did The Right Thing and asked Paul@Brultech if it was OK to post it. As a result, I discussing with him the documentation of the protocol overall, which is why I have decided to hold off posting it. Hopefully the conversation will end up filling in a couple of the holes I have, and result in better documentation overall.
I did finish the documentation of the logger download protocol, but I Did The Right Thing and asked Paul@Brultech if it was OK to post it. As a result, I discussing with him the documentation of the protocol overall, which is why I have decided to hold off posting it. Hopefully the conversation will end up filling in a couple of the holes I have, and result in better documentation overall.
Here is the download protocol. I welcome comments and corrections (and I hope some people double check my work).
I do have self-written documentation for the real-time protocol as well as most of the commands in the ECM setup program, however, Paul has asked that I do not post it... hence you won't see it here. However, it is pretty obvious if you look at some of the code that is out there.
==Edit==
I'm putting this in the download section hopefully this works:
http://www.cocoontech.com/forums/index.php...mp;showfile=122
I do have self-written documentation for the real-time protocol as well as most of the commands in the ECM setup program, however, Paul has asked that I do not post it... hence you won't see it here. However, it is pretty obvious if you look at some of the code that is out there.
==Edit==
I'm putting this in the download section hopefully this works:
http://www.cocoontech.com/forums/index.php...mp;showfile=122
Any idea as to why?
I am considering buying a 1240, but it appears to me that support seems somewhat spotting at best (just my opinion from casually watching the threads)
It would seem to me that Brultech ought to be encouraging you.....your helping them w/ product support (again, hjust my opinion).
They are coming out with some new software (according to their support page and in discussion with Paul). I can only assume something might change. This is purely speculation. However, the real-time protocol is easily found in the source code of many of the available third-party programs.
I don't want to hijack the thread or cross post... I just want to post it here for people watching this thread.
But I posted a sneak preview of the new Brultech software here:
http://www.cocoontech.com/forums/index.php...692#entry124472
But I posted a sneak preview of the new Brultech software here:
http://www.cocoontech.com/forums/index.php...692#entry124472
I have put together a perl script which listens to an EtherBee device connected to an ECM-1240. The script works in two modes, server and client.
Server: Listens for EtherBee connections, decodes ECM-1240 packets and writes them to a shared memory segment.
Client: Reads the shared memory segment and can update rrd files directly, print the readings to stdout or relay them to another system. Any number of instances running in client mode can be started.
NOTE: The rrd files must already be created. Given I have my ECM-1240 setup for a 1 second interval, I have individual rrd files - one for each reading.
I hope people find it useful. Since this is my first post here, I'm forced to make the URL a bit cryptic.
Point your browser to mentasm com <slash> brultech <slash> brultech.pl
- Mark.
Server: Listens for EtherBee connections, decodes ECM-1240 packets and writes them to a shared memory segment.
Client: Reads the shared memory segment and can update rrd files directly, print the readings to stdout or relay them to another system. Any number of instances running in client mode can be started.
NOTE: The rrd files must already be created. Given I have my ECM-1240 setup for a 1 second interval, I have individual rrd files - one for each reading.
I hope people find it useful. Since this is my first post here, I'm forced to make the URL a bit cryptic.
Point your browser to mentasm com <slash> brultech <slash> brultech.pl
- Mark.
Awesome! I was planning on adding RRD support to that python script that is floating around out there, but now I don't have to. I will fix your URL:
http://mentasm.com/brultech/brultech.pl
I didn't look over the code yet. Couple of questions:
- How do you handle multiple units?
- How does the perl script handle counters that wrap? The python one that is out there didn't handle these well, and you'd end up with enormous spikes in your database that didn't exist.
I wanted to get this all dumped into RRD, then then use something like this to generate my graphs/charts:
http://yaketystats.org/redmine/wiki/yaketystats
There used to be a demo of Jart up somewhere, but I can no longer find it. There was a way to gather cost information and stuff also.
You guys may want to take a look at the Brultech thread over on the CQC forums (Beta Drive Developments sub-forum). Brultech has a version of their server software that will stream the info over a TCP/IP connection. It will support up to six ECM's and may even have Google PowerMeter support in it. It's currently in beta.
