GEM http returning binary from dashbox and wifi

[gabberdave]

I disconnected my GEM (ethernet/wifi module) from power today to make better connections between the cat5 and STS cable. When I reconnected the GEM to power, it seemed to come up - green left led with 5 sec red pulses that match my upload interval, yellow right led, however it was no longer communicating with the dashbox. Looking at the dashbox's 8001 port, I got back ERR_INVALID_HTTP_RESPONSEs (this presents when moving the dashbox next to the GEM and using the STS cable for the other GEM I have not finished installing to connect the dashbox directly to the COM1 pins on the GEM). I also got this back from the GEM's wifi ip 8000 port. curling the port, I get a bunch of binary:

$ curl http://192.168.1.6:8000 --output -
����������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

The block of binary come in about 5 sec blocks and repeats until I kill curl.

The wifi config pages function fine and I've reset the network (and then placed the GEM back on my home network without issue).

I don't seem to have a battery on the GEM (there is a blue disc on the underside of the bottom most logic board, but I think it is a cap) to pull before pulling power to the GEM - is there a method to 'reset the memory' that I need to do? A quick press of the reset button didn't seem to do much (I don't remember if it rebooted the unit or not).

Since I have access to the GEM via the wifi 8000 port, I haven't tried using the network tool - does that give me something the 8000 port does not?

[ben]

I disconnected my GEM (ethernet/wifi module) from power today to make better connections between the cat5 and STS cable. When I reconnected the GEM to power, it seemed to come up - green left led with 5 sec red pulses that match my upload interval, yellow right led, however it was no longer communicating with the dashbox. Looking at the dashbox's 8001 port, I got back ERR_INVALID_HTTP_RESPONSEs (this presents when moving the dashbox next to the GEM and using the STS cable for the other GEM I have not finished installing to connect the dashbox directly to the COM1 pins on the GEM). I also got this back from the GEM's wifi ip 8000 port. curling the port, I get a bunch of binary:

$ curl http://192.168.1.6:8000 --output -
����������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

The block of binary come in about 5 sec blocks and repeats until I kill curl.

The wifi config pages function fine and I've reset the network (and then placed the GEM back on my home network without issue).

I don't seem to have a battery on the GEM (there is a blue disc on the underside of the bottom most logic board, but I think it is a cap) to pull before pulling power to the GEM - is there a method to 'reset the memory' that I need to do? A quick press of the reset button didn't seem to do much (I don't remember if it rebooted the unit or not).

Since I have access to the GEM via the wifi 8000 port, I haven't tried using the network tool - does that give me something the 8000 port does not?

It looks like the binary coming in is the GEM sending its packet. It should correspond with a red flash on the GEMs Sys LED. A URL Request if repeated should eventually bring up the GEM Setup Webpage, it can take a few times to get it to go if it intercepts a packet when the request is sent. I would try a few times in a web browser tab to see if you can get it to respond.

The WiFi/Ethernet also uses COM1 on the DashBox so if you set it up with the STS cable make sure you're using COM2 (the default baud for COM2 should be 19200 unless changed). The GEM likely won't hear Rx signals as it'll be competing with the WiFi/Ethernet module. You can listen in on the Tx line with the DashBox however if you ever want to go that route and use COM1, just keep the Rx line disconnected.

You could try some commands via the GEM Network Utility via port 8000 to see if it's responding at all. The "Get GEM Info" button will pull all the settings.

The super cap is disengaged via the header above the Ethernet port. Just remove it, unplug the unit, wait a few seconds, then plug it back in and put the header back on. May as well give it a shot as it doesn't hurt anything.

The only way I can see the memory getting corrupted however is if it was unplugged for a long time or the hardware option isn't setup (draining the super cap).

[gabberdave]

The Network Utility can talk to the GEM via wifi on port 8000 but cannot retrieve the serial number (that fails) and the PT/CT table is full of incorrect information - all types are unspecified, type is either 0 or -935:

Screen Shot 2022-03-30 at 10.24.16 AM.png (1.25 MiB) Viewed 1318 times

The type and the x2 checkboxes walk around on refreshing the PT table.

The commands on the debug tab don't generate any response in the white boxes on the right (I assume that is where the output would be shown).

After probably 20 tries in the browser to reload :8000 and a similar number of curl attempts, I never received the GEM Setup page.

Is this something the Restore Factory Defaults button is likely to restore? Should I try to push a firmware update to the module? Use the recovery mode checkbox when doing so?

[ben]

Did you make sure you don't have the STS cable connected to COM1 on the GEM? The conflicting Rx signals will stop you from being able to send commands to the GEM. As-is it looks like the GEM Network Utility is just intercepting packets when you send a command.

Does http://192.168.1.6/ bring up the WiFi/Ethernet setup page? (default pass is admin). If so, report back with the Application Settings sections Baud Rate.

[gabberdave]

The port 80 pages all work fine. I was unsure if the Wifi-Uart settings page adjusted the wifi server process communicating with the GEM or the GEM's settings so I haven't touched them. They are:
Baud rate: 115200
data bits: 8
parity: None
stop: 1
flow control: disable
485 Mode: disable
baud rate adaptive: Enable

uart autoframe: disable

registered package type: off

custom heartbeat: off

socket distribution: off

modbus polling: off

httpdclient mode: long


Thinking about when I was doing the update to the serial port wiring, I would have disconnected the power to the GEM before futzing with it. I might have also knocked the jumper for the supercap off and plugged it back in a minute or two later (memory is hazy because the power was off and I didn't know the jumper was power related so it didn't hold much relevance at the time) when I was moving the cat5 cable around since the cable is routed near the jumper. In either case, I think I had the power off for 30 minutes to an hour. I think I read in a previous post that if the 5vdc power is disconnected and the battery (or in my case supercap) is pulled, that can have negative effects. Is what my GEM is presenting different from said negative effects? Or would those have been cleared when I did the proper 'pull the jumper, then disconnect power and reverse steps' type reset?

[ben]

Thinking about when I was doing the update to the serial port wiring, I would have disconnected the power to the GEM before futzing with it. I might have also knocked the jumper for the supercap off and plugged it back in a minute or two later (memory is hazy because the power was off and I didn't know the jumper was power related so it didn't hold much relevance at the time) when I was moving the cat5 cable around since the cable is routed near the jumper. In either case, I think I had the power off for 30 minutes to an hour. I think I read in a previous post that if the 5vdc power is disconnected and the battery (or in my case supercap) is pulled, that can have negative effects. Is what my GEM is presenting different from said negative effects? Or would those have been cleared when I did the proper 'pull the jumper, then disconnect power and reverse steps' type reset?

If the header was put back on when the GEM was off that can definitely cause some issues as it'll be in some unknown state.

Did you pull the jumper, unplug, wait a few seconds, plug it back in first, and put the jumper back on?

What's the LEDs on the GEM doing?

[gabberdave]

If the header was put back on when the GEM was off that can definitely cause some issues as it'll be in some unknown state.

Did you pull the jumper, unplug, wait a few seconds, plug it back in first, and put the jumper back on?

I assume you mean in trying to reset the GEM after it was not presenting the GEM setup page non the wifi 8000 port or the dashbox 8001 port. Yes, that is what I did.

If you mean when I accidentally disconnected the jumper, that would have been more like:
- unplug GEM
- a couple minutes go by
- the jumper gets knocked off when I pull the cat5 wire out to remove it from the COM pins
- after a minute I find what made the noise of something hitting the floor (the jumper) and put it back in place.
- 30 minutes to an hour later the GEM is plugged back in

The only thing here is this is a vague memory; it might have happened when I pulled the cover off the GEM and before I pulled the 5vdc power.

What's the LEDs on the GEM doing?

Throughout they seem to signal proper operation:
- Left is green with red blinks on 5 sec intervals that match the sampling interval I had setup.
- Right is yellow/green which signals that the wifi module has connected to the AP.

I think if there is a 'reset to factory defaults' on the GEM setup, that would be fine. Is that what the factory defaults button on the GEM Network Utility Firmware tab does? It only took 15 minutes to setup the CT mapping the first time iirc. I just wanted to get verification that that was likely a legitimate next step before I add more variables into the mix.

[ben]

Let's just try reloading the F/W.

Make sure nothing is trying to connect to the GEM (curl, etc) then to the following:

Download the GEM COM F/W here: http://brultech.com/software/files/down ... _5.39_.fmw

- Pull the jumper.
- Unplug the GEM.
- Hold the button at the bottom in.
- Plug it back in.

The Sys LED should be solid red now.

In the GEM Network Utility go to Firmware, checkmark Use Recovery Mode, select the F/W file, click Start. F/W should start loading.

Once it's back up, click Get GEM Info and see if you can pull settings from it.

[gabberdave]

Followed the procedure, and the left LED is solid red which I assume put the bootloader into a receiving state. When I went to load the firmware, the network utility connects (TCP connection OK), but the percentage never went above 0.0% and I got Error 222. After pulling the power again and plugging it back in, the GEM setup was available again and had retained the CT settings.

However, the COM1 serial line kept getting set to 19200 on the dashbox (took me a little bit to learn to correctly navigate the settings menu to see that).

So however it got in that state, it has been cleared up and the dashbox is logging again.

Is there any docs on the bottom switch, the reset button and the network module reset switch (I'm not clear on what each of them does). Or a discussion of the interconnections between the modules?

The WiFi/Ethernet also uses COM1 on the DashBox so if you set it up with the STS cable make sure you're using COM2 (the default baud for COM2 should be 19200 unless changed). The GEM likely won't hear Rx signals as it'll be competing with the WiFi/Ethernet module. You can listen in on the Tx line with the DashBox however if you ever want to go that route and use COM1, just keep the Rx line disconnected.

In the dashbox no-RX setup, all GEM setup then goes through the GEM's ip interface's 8000 port?

Does the ip interface using COM1 also mean that if I have multiple GEMs at different locations, only 1 can be reliably connected through direct serial connection while the others would have to use an ip connection? If the dashbox is listen only, is the CT data frame always parsed/extracted from the serial line and other frames that do not correlate with an active request thrown out (I'm not sure what the uart wire protocol looks like here which leaves me pontificating...). I'm still in the process of wiring the second subpanel

If I wanted to play around with an outside database + grafana (which from my memory when I was looking at the possibility a few months back, would require polling from the a dataloader), does that restrict me to using only an ip connection (or does it still not matter because the GEM can broadcast CT data frames over the COM port even when sharing it with the ip module?

[ben]

Just so we don't get things mixed up:

- COM1/2 refers to the terminal strip connections on the GEM.
- RS232 1/2 refers to the STS cable plugs on the DashBox.

I'm going to change that terminology on the "Change Baudrates" page as it's confusing.

Followed the procedure, and the left LED is solid red which I assume put the bootloader into a receiving state. When I went to load the firmware, the network utility connects (TCP connection OK), but the percentage never went above 0.0% and I got Error 222. After pulling the power again and plugging it back in, the GEM setup was available again and had retained the CT settings.

However, the COM1 serial line kept getting set to 19200 on the dashbox (took me a little bit to learn to correctly navigate the settings menu to see that).

So however it got in that state, it has been cleared up and the dashbox is logging again.

Is there any docs on the bottom switch, the reset button and the network module reset switch (I'm not clear on what each of them does). Or a discussion of the interconnections between the modules?

When in Recovery Mode it's just looping looking for the start of F/W. If it's stuck at 0.0% that confirms the GEM isn't receiving anything and it's not a F/W issue.

Try the following:
- Cycle power to the GEM to leave Recovery Mode, the Sys LED should be solid green.
- Disconnect everything from COM1/COM2
- Connect with the GEM Network Utility via TCP Client IP: 192.168.1.6 and Port: 8000.
- Click the "Get GEM Info" button.

Is your DashBox on the 4.2.4b-series? Update to the 4.2.4c series, should fix the baudrate toggling issue. http://brultech.com/software/files/down ... 2_4c9a.img

The switch operations are scattered in the manuals. Probably easier to just answer here.

- The bottom switch shouldn't be used beyond the Recovery Mode. it has a couple old functions linked to it that we don't use any more.
- The network module reset switch is used if you ever get locked out of the WiFi/Ethernet module. Long press for 8 seconds resets the module to factory defaults.

In the dashbox no-RX setup, all GEM setup then goes through the GEM's ip interface's 8000 port?

Does the ip interface using COM1 also mean that if I have multiple GEMs at different locations, only 1 can be reliably connected through direct serial connection while the others would have to use an ip connection? If the dashbox is listen only, is the CT data frame always parsed/extracted from the serial line and other frames that do not correlate with an active request thrown out (I'm not sure what the uart wire protocol looks like here which leaves me pontificating...). I'm still in the process of wiring the second subpanel

If I wanted to play around with an outside database + grafana (which from my memory when I was looking at the possibility a few months back, would require polling from the a dataloader), does that restrict me to using only an ip connection (or does it still not matter because the GEM can broadcast CT data frames over the COM port even when sharing it with the ip module?

Sorry, I didn't explain this well enough:

The GEM has 2 COM ports, COM1 and COM2. COM1 is where the WiFi/Ethernet module resides. COM2 has the Xbee footprint above the WiFi/Ethernet module. COM2 is usually left unpopulated.

The DashBox can listen/send via the 2 RS232 ports (they bridge to TCP via Ports 8001/8002). It can take 2 direct connected energy monitors via STS cables and (technically) unlimited units via TCP.

The STS connection is just a basic RS232 connection using a stereo cable for Tx/Rx/GND. The DashBox will throw away anything it doesn't recognize. Packets are framed with a header/footer and are validated with a checksum (FEFF## FFEE<Checksum>).

If you're looking at BTMon.py, it can be set up in numerous ways to work with Grafana. I would likely just use TCP Server and have the DashBox Packet Forward binary packets to it.

Ports 8001/8002 with the new firmware are also setup to take in binary packets via TCP Client so they can be Packet Forwarded to other services.