GEM & btmon.py Not Talking

[G550_Pilot]

Trying to get my GEM to talk to btmon.

My main server is located in an offsite datacenter so I need the GEM to reach out to btmon, not the other way around. I have configured btmon like this:

Code: Select all

[source]
device_type = gem
ip_read = true
ip_port = 8083
ip_mode = server

[openenergymonitor]
oem_out=true
oem_token=skdhksdhkdsjhfdskjhfskjhsksdjfhk

I can access the server on 8083 from my local network just fine and I see the connection in the debug output of btmon, so I know my firewalls are not the issue.

I have configured the GEM in client mode with the IP address as that of my server and the port the same port as my btmon instance is listening on, but so far, the GEM has yet to send any data to the btmon.

screen 2016-04-18 at 6.20.41 PM.jpg (70.7 KiB) Viewed 2255 times

My GEM is configured with wifi (unused), ethernet (used with static IP assignment of 192.168.1.7) and is connected to my DB using COM1.

I see all the data just fine on my DB, but the GEM does not appear to even attempt to send data to my server. Using wireshark, there is no attempt from the GEM to communicate to anything on port 8083.

Hopefully I am missing something simple. I read somewhere is some document about the ethernet being linked to a com port or something like that an now I cannot find it again, so I think I missed something in my configuration some where.

Looking for some guidance!

Thanks



GEM CONFIG

Code: Select all

Serial#: 00000000
COM firmware ver: 4.15
ENG firmware ver: 1.49
RealTime Status: ON
Packet Send Interval: 8
Pri. Packet Format: 4
Sec. Packet Format: 0
Sys Status: OK	Wifi/Ethernet Module: Enabled
GEM Ver: Single or Polyphase
PCB Ver: 3
BootLoader Ver: 2
COM1 Flow: OFF
COM2 Flow: OFF
Current Constant: 221
Sys Info: 00100001 OK
Sys Flags: 00000000 OK	Keep Alive String:""
COM1 Baud: 115200
COM2 Baud: 115200
Phase Setting: Single Phase
Freq: 60Hz
Hardware Configuration: 166
WiFi and Ethernet V2

Output from btmon in debug mode:

Code: Select all

haarp btmon # ./btmon.py -c btconfig.cfg --print --debug
2016/04/18 18:34:13 btmon: 3.1.1
2016/04/18 18:34:13 python: 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2]
2016/04/18 18:34:13 platform: linux2
2016/04/18 18:34:13 device type: gem
2016/04/18 18:34:13 device list: ['']
2016/04/18 18:34:13 packet format: gem48ptbin
2016/04/18 18:34:13 schema: counters
2016/04/18 18:34:13 buffer size: 120
2016/04/18 18:34:13 SOCKET: bind host: 
2016/04/18 18:34:13 SOCKET: bind port: 8083
2016/04/18 18:34:13 OEM: upload period: 60
2016/04/18 18:34:13 OEM: timeout: 15
2016/04/18 18:34:13 OEM: url: http://emoncms.xxxxxxxxx.com/api/post
2016/04/18 18:34:13 OEM: token: ksjhfksjdhfskjhfklsjfhksjhfkjsdh
2016/04/18 18:34:13 OEM: node: GEM
2016/04/18 18:34:13 packet format is GEM48PTBinaryPacket
2016/04/18 18:34:13 using collector SocketServerCollector
2016/04/18 18:34:13 using 2 processors:
2016/04/18 18:34:13   PrintProcessor
2016/04/18 18:34:13   OpenEnergyMonitorProcessor
2016/04/18 18:34:13 setup SocketServerCollector
2016/04/18 18:34:13 SOCKET: binding to :8083
2016/04/18 18:34:13 setup PrintProcessor
2016/04/18 18:34:13 setup OpenEnergyMonitorProcessor
2016/04/18 18:34:13 SOCKET: waiting for connection

[mwareman]

I have a feeling that the network interface(s) are bound to COM1 - and you have that feeding your Dashbox.

To have the network send data, I had to configure COM2 for the Dashbox, and connect it there. Then I could use COM1 for network sends.

My GEM is WiFi only though.

[ben]

I have a feeling that the network interface(s) are bound to COM1 - and you have that feeding your Dashbox.

To have the network send data, I had to configure COM2 for the Dashbox, and connect it there. Then I could use COM1 for network sends.

My GEM is WiFi only though.

Yeah, you're best off separating the instances.

You could likely have them both running on the same COM port but you'd have to remove the STS cables Rx line so the DashBox is just listening in and not conflicting with the WiFi/Ethernet module. But you'd also lose any polling the DashBox does back.

Move Tx/Rx/GND to COM2, change either the COM2 Baud Rate to 115200 or the DashBox to 19200 (as the GEM COM2 runs at 19200 by default).

[G550_Pilot]

Move Tx/Rx/GND to COM2, change either the COM2 Baud Rate to 115200 or the DashBox to 19200 (as the GEM COM2 runs at 19200 by default).

Thanks Guys -

Did as you suggested. Moved my DB serial connection to COM2, set to 115k. DB still working great, still able to access the GEM via the DB no problem, but still no data to btmon. Not sure if I have to disable COM1 somehow and if so, how or where do I do that, or is there another step to get COM1 to do 'network send' as @mwareman says.

Also, one other thing. As soon as I move the COM port, I am no longer able to access the GEM from the Windows GEM network utility via the IP address assigned to the GEM. In the GEM, under network, I have 192.168.1.7 and port 8000 set and I was able to access the GEM from the via the Gem Network utility at that IP and port, but no longer.

Thanks

[ben]

Move Tx/Rx/GND to COM2, change either the COM2 Baud Rate to 115200 or the DashBox to 19200 (as the GEM COM2 runs at 19200 by default).

Thanks Guys -

Did as you suggested. Moved my DB serial connection to COM2, set to 115k. DB still working great, still able to access the GEM via the DB no problem, but still no data to btmon. Not sure if I have to disable COM1 somehow and if so, how or where do I do that, or is there another step to get COM1 to do 'network send' as @mwareman says.

Also, one other thing. As soon as I move the COM port, I am no longer able to access the GEM from the Windows GEM network utility via the IP address assigned to the GEM. In the GEM, under network, I have 192.168.1.7 and port 8000 set and I was able to access the GEM from the via the Gem Network utility at that IP and port, but no longer.

Thanks

Once you set the WiFi/Ethernet module to Client mode it'll no longer let you connect. You have to switch it back to Server mode to access via 8000.

Can you try setting the GEM Network Utility to TCP Server, Port 8083, then change the IP in the Application Settings to your Computers IP? See if you get a connection with those settings.

[G550_Pilot]

Once you set the WiFi/Ethernet module to Client mode it'll no longer let you connect. You have to switch it back to Server mode to access via 8000.

Can you try setting the GEM Network Utility to TCP Server, Port 8083, then change the IP in the Application Settings to your Computers IP? See if you get a connection with those settings.

Hi Ben -

Understand on the GEM Network Utility. Made the change, still no data to port 8083. Wireshark shows the GEM is not outputting anything via it's ethernet IP of any consequence. I tried various ports, still nothing.

I do not have a suitable machine locally that I can use to test without some configuration, but a telnet from my local machine to my server on port 8083 goes right through and the btmon.py kicks out some errors since its a telnet session and not the GEM talking to it so I know it is not a firewall issue or an internet issue:

Code: Select all

2016/04/19 11:39:02 waiting for data from device
2016/04/19 11:39:02 reading 1 of 1 packets
2016/04/19 11:39:13 SOCKET: read 0 of 1 bytes from socket: 
2016/04/19 11:39:13 failed read 1 of 0
2016/04/19 11:39:13 expected START_HEADER0 0xfe, got nothing
Traceback (most recent call last):
  File "./btmon.py", line 2145, in _blockingread
    self._read(packet_format)
  File "./btmon.py", line 2132, in _read
    packets.extend(packet_format.read(self))
  File "./btmon.py", line 1522, in read
    return self._read1(collector, self.DATA_BYTES_LENGTH, self.PACKET_ID)
  File "./btmon.py", line 1410, in _read1
    self._checkbyte(data, 'START_HEADER0', self.START_HEADER0)
  File "./btmon.py", line 1401, in _checkbyte
    (label, hex(evalue)))
EmptyReadError: expected START_HEADER0 0xfe, got nothing
2016/04/19 11:39:13 waiting 60 seconds before retry

Can you verify that the GEM does not care that it is not talking to an RFC1918 address as opposed to a live, external IP address. The IP it talks to does not have to be on the same network as the GEM correct?

[ben]

Can you verify that the GEM does not care that it is not talking to an RFC1918 address as opposed to a live, external IP address. The IP it talks to does not have to be on the same network as the GEM correct?

It does not have to be on the same network, but I just realized you're connected via Ethernet. The settings in the manual won't work on IPs outside the network

I have a manual here with slightly different instructions for Ethernet we were working on. It involves leaving the module in AP mode, then the Ethernet should use the settings under STA Interface.

You'll also want to secure/hide the WiFi AP from the GEM once confirmed it's working.

[G550_Pilot]

Thanks Ben !!