Upgraded GEM, now shows errors.

[Teken]

Hello Micael,

Would you please confirm the second GEM is set with the same parameters for the packet chunks and similar. There is a thread which I will try to find where Ben states the packet chunks, com flow, and various other parameter should be set to lower, off, etc values.

Could you compare the two GEM's you have on site to one another and match the second GEM to the first incase there is a difference. Also, in the DB Settings-> Admin Settings-> Log Packet Every: Could you change the value to 2 and report back what you observe.

It should also be noted there are a few things happening just in case its not apparent or the same as to what I see.

Different Scenarios:

- I will receive a no packet received email from the DB. But, the system is in fact logging data packets and there is no loss present in the system. You can confirm this by looking at any circuit to see if data gaps are present.

- You will receive a loss of connectivity message from SEG. In this case I've observed the DB has indeed stopped sending packets to third party services / hardware. A reboot is the only method to restore that lost connectivity at this time.

- You see that the DB is displaying an error in the system LED or receive a loss of data packet email. The enable data logging button has been toggled off for what ever reason. The remedy is to re-enable data logging to restore logging.

As an aside I would create a secondary email to send these down events to Ben at Brultech. This would give him more insight as to the frequency and interval of the loss of communications. Please inquire with Ben if this next step is appropriate though.

Lastly, there have been instances where the power supply has been the culprit in random faults. You may want to review the Brultech *General* section as to how to identify if your PSU is one of the faulty units and replace it in case it is.

[vespaman]

Teken,

AFAICT, both GEM's are set-up identically. Both reports over serial to DB, and on other send channel to OpenHAB using two BTMon's. The OH connection never fails on any of the GEM's. Both packet outs are Bin 48 net time. 15s reporting, realtime enabled.
Changing the DB log every two minutes does not make any difference.

What I haven't done, is to switch GEM1 into DB Comms 1 and GEM 2 into DB Comms 2. But I fear I will have the exact same issue, but instead with GEM1.
Since GEM1 is fully populated, I prioritize to have it working over GEM2, which only has my BMW i3 at the moment.

I'm not using SEG or anything similar, data to DB stops at DB.

And:- it is rarer that GEM2/DB Comms 1 is working than it is not working. It is often hours downtime.

[Teken]

In the interim try to find the thread where it mentions changing the COM packet chunks, COM Flow, etc. There were a few minor changes from black vs blue board of the latest shipping GEM's which required these parameters to be set differently.

These are just checks and don't address the root issue of the DB going off line and declaring a data packet loss though. Because I am seeing them now only on my silver DB. As I have a black DB and it doesn't have this persistent issue.

Please ensure you send in a technical service request to the team so they can actively track and work on this with you.

[ben]

Teken,

AFAICT, both GEM's are set-up identically. Both reports over serial to DB, and on other send channel to OpenHAB using two BTMon's. The OH connection never fails on any of the GEM's. Both packet outs are Bin 48 net time. 15s reporting, realtime enabled.
Changing the DB log every two minutes does not make any difference.

What I haven't done, is to switch GEM1 into DB Comms 1 and GEM 2 into DB Comms 2. But I fear I will have the exact same issue, but instead with GEM1.
Since GEM1 is fully populated, I prioritize to have it working over GEM2, which only has my BMW i3 at the moment.

I'm not using SEG or anything similar, data to DB stops at DB.

And:- it is rarer that GEM2/DB Comms 1 is working than it is not working. It is often hours downtime.

Are the GEM Adv pages identical?

Flow Control can cause this issue and should be disabled. The GEM can get in a state where it doesn't think it's clear to send on one COM port.

I would also make sure that your 2nd connection isn't sending anything too lengthy back to the GEM as it'll try to process that before proceeding.

[vespaman]

I have now double checked the adv pages, and they where identical. They had com1 hardware enabled, which I have now disabled on both GEM.
I am pretty sure I have tested this before on both GEM, and now there's anyway no change on GEM2/DB input 1, which has not logged since 50 minutes.

I would also make sure that your 2nd connection isn't sending anything too lengthy back to the GEM as it'll try to process that before proceeding.

I'm not sure I follow here.. The second connection on the second GEM? It is BTMon, 48bin net time. Same on GEM1. Does BTMon send data back to GEM?

This is my set-up.
GEM1:
Com1 -> Dashbox Com2
Com2 (over ethernet)- -> BTMon -> MQTT-> OpenHAB
GEM2:
Com1 -> Dashbox Com1
Com2 (over ethernet)- -> BTMon -> MQTT-> OpenHAB

All Packets are all Bin48-NET-TIME 15seconds, 115200.

Everything works, apart form Dashbox input 1.

[ben]

I have now double checked the adv pages, and they where identical. They had com1 hardware enabled, which I have now disabled on both GEM.
I am pretty sure I have tested this before on both GEM, and now there's anyway no change on GEM2/DB input 1, which has not logged since 50 minutes.

I would also make sure that your 2nd connection isn't sending anything too lengthy back to the GEM as it'll try to process that before proceeding.

I'm not sure I follow here.. The second connection on the second GEM? It is BTMon, 48bin net time. Same on GEM1. Does BTMon send data back to GEM?

This is my set-up.
GEM1:
Com1 -> Dashbox Com2
Com2 (over ethernet)- -> BTMon -> MQTT-> OpenHAB
GEM2:
Com1 -> Dashbox Com1
Com2 (over ethernet)- -> BTMon -> MQTT-> OpenHAB

All Packets are all Bin48-NET-TIME 15seconds, 115200.

Everything works, apart form Dashbox input 1.

The Ethernet module runs on COM1 of the GEM. I would suggest having the DashBox connected to COM2 on the GEM, or alternatively, disconnect the Rx line from the GEM. The Rx line will conflict the Ethernet module, the Tx should be fine to listen in.

Reboot the GEM after disabling Flow Control if you haven't already.

This likely isn't the issue but make sure that Flow Control is disabled on the Ethernet modules. The GEM Network Utility doesn't expose these settings, you'll have to use the EtherX software for our ECM-1240 under "Serial"
(http://brultech.com/software/files/down ... Config.exe).

I would also make sure that your 2nd connection isn't sending anything too lengthy back to the GEM as it'll try to process that before proceeding.

BTmon shouldn't be sending anything back to the GEM, so you should be OK on the suggestion above.