COM 3.24 Firmware

[Teken]

I installed COM 3.24 firmware last week during the release day and wanted to let you know all seems to be rock solid.

I did notice a DB to GEM drop off that seems to repeat itself every 3 minutes? Upon rebooting both GEM COM / Engine via the Advanced Tab along with the DB all seem well.

There was a time sync message on the DB that seemed to stay present in the system for about 60 seconds which I have not seen for quite awhile.

Any release notes for this release would be great to see.

[ben]

I installed COM 3.24 firmware last week during the release day and wanted to let you know all seems to be rock solid.

I did notice a DB to GEM drop off that seems to repeat itself every 3 minutes? Upon rebooting both GEM COM / Engine via the Advanced Tab along with the DB all seem well.

There was a time sync message on the DB that seemed to stay present in the system for about 60 seconds which I have not seen for quite awhile.

Any release notes for this release would be great to see.

Paul is working out a couple bugs that we're introduced recently. Might fix that 3 minute problem.

[Teken]

I installed COM 3.24 firmware last week during the release day and wanted to let you know all seems to be rock solid.

I did notice a DB to GEM drop off that seems to repeat itself every 3 minutes? Upon rebooting both GEM COM / Engine via the Advanced Tab along with the DB all seem well.

There was a time sync message on the DB that seemed to stay present in the system for about 60 seconds which I have not seen for quite awhile.

Any release notes for this release would be great to see.

Paul is working out a couple bugs that we're introduced recently. Might fix that 3 minute problem.

Ben,

Good to know, and please note the system has not dropped off since the DB / GEM reboot.

[scyto]

Since installing this after a period of time no more packets get logged by the dashbox, this seems to happen about 8 minutes after everything has been rebooted.

No recent packets logged for device 01000029

•Make sure Real-Time is enabled.
•Check connection to DashBox.
•Check Raw Data section in Settings section to make sure data is coming in.

--edit--
sometimes it happens a few minutes after a reboot.
I can still access the GEM via http://DB-ipaddress:8001 so I assume com ports an baud are ok.

I tried rebooting the COM and ENG along with the DB and it started off red in the DB but after a minute or so became green again

[scyto]

after more research it seems my use of btmon.py is the culprit here

I saw in the DB manual that it exposes the GEM on 8001
So I configured btmon.py to pull data from the DB IP address on port 8001, hoping that the DB would log the DB packets itself and also allow the btmon.py script access the same data

after a few minutes of uploading data to emoncmw.org the status light on the DB goes red.

the btmon.py script seems to continue to upload just fine (though it wasn't last night when theses symptoms hit it would deny connection to the script too).

This is my command I was using (192.168.1.8 is my DB)

python btmon.3.1.0.py --device-type=gem --ip --ip-mode=client --ip-host=192.168.1.8 --ip-port=8001 --oem --oem-token=<mytoken> --oem-url=http://emoncms.org/input/post.json --oem-node=1 --reverse-polarity=1 --debug

after stopping this script the DB status went back to green (it didn't when I was troubleshooting tis last night - I think rebooting the COM and END helped)

I guess I should boil this back to my requirements - I want to send my GEM data to both the DB (and onwards to SEG and ISY) but also want to use btmon.py to try some of the other services. What is the right want to do this?

[ben]

Port 8001 interrupts data logging and allows you to service the GEM.

Can you run a serial-to-USB cable to your box running btmon? You can hook up through the Tx header and listen in.

[scyto]

Port 8001 interrupts data logging and allows you to service the GEM.

Can you run a serial-to-USB cable to your box running btmon? You can hook up through the Tx header and listen in.

I guess, it's a raspberry pi, what's the wiring for the TX header?

Of course would be great if the DB could multiplex / emulate the GEM someways?

[scyto]

Or better question:

Given I am not using the xbee module and can now plug the GEM into a CAT5 port is there a way to leverage the 2 COM ports on the GEM differently?

For example should I turn off wifi and xbee and configure btmon.py to access the GEM via the 8002 port?

Or should I configure btmon.py to access the GEM over the network in someway?

Or should I connect the btmon.py with serial in someway?

[ben]

Port 8001 interrupts data logging and allows you to service the GEM.

Can you run a serial-to-USB cable to your box running btmon? You can hook up through the Tx header and listen in.

I guess, it's a raspberry pi, what's the wiring for the TX header?

Of course would be great if the DB could multiplex / emulate the GEM someways?

GEM Communication layout.png (156.2 KiB) Viewed 2153 times

Or better question:

Given I am not using the xbee module and can now plug the GEM into a CAT5 port is there a way to leverage the 2 COM ports on the GEM differently?

For example should I turn off wifi and xbee and configure btmon.py to access the GEM via the 8002 port?

Or should I configure btmon.py to access the GEM over the network in someway?

Or should I connect the btmon.py with serial in someway?

The GEM can send 2 different packet formats. If you're not using Xbee, you're best off putting the DashBox on COM2 as COM2 is limited in terms of what it can send (only fixed-length packet formats).

If you have WiFi, Ethernet, or WiFi/Ethernet, that's on COM1.

[scyto]

Thanks, I did read the manual but found that picture and accompanying text hard to parse.

So I think you are suggesting connect the DashBox to Com2, disable the xbee and connect btmon.py over the Ethernet to the GEM.

Right? (sorry to be dense here)