Websocket EOF on some operations

[villanyibalint]

We are using Steve for some OCPP16.J configured charge points. On some operations, e.g. Set Charging Profile or Send Local List, we are encountering an error: [INFO ] 2019-04-14 16:22:23,564 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=gyor25kwdc, sessionId=5f34ee1f] Sending: [2,"2f4ebba5-58e7-4ee8-9f2c-84a14be9c7df","SetChargingProfile",{"connectorId":0,"csChargingProfiles":{"chargingProfileId":3,"stackLevel":0,"chargingProfilePurpose":"ChargePointMaxProfile","chargingProfileKind":"Absolute","recurrencyKind":"Daily","validFrom":"2019-04-14T17:00:00.000Z","validTo":"2019-04-30T18:00:00.000Z","chargingSchedule":{"duration":3600,"startSchedule":"2019-04-14T17:01:00.000Z","chargingRateUnit":"A","chargingSchedulePeriod":[{"startPeriod":3600,"limit":11,"numberPhases":3}],"minChargingRate":11}}}] [WARN ] 2019-04-14 16:22:25,526 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=porschegyor25kwdc, sessionId=5f34ee1f] Connection is closed, status: CloseStatus[code=1006, reason=WebSocket Read EOF]

So it has something to do with the websockets, maybe the sent JSON is too long? We are set up in Azure VMs, but I doubt that's the problem, because supposedly it has native websocket support. Regular management messages, like heartbeat and boot notifications never had this problem.

Thank you very much in advance if you can assist us!

[goekay]

are there any other warnings or exception stack traces? did you modify steve to meet your use cases or infrastructure?

i doubt it's because of the length of the message. the thing that i find alarming is that there are two charging stations (gyor25kwdc and porschegyor25kwdc) and they are assigned the same session id.

[villanyibalint]

Right, I wanted to exclude the beginning of the charging profile name, I just missed the second one. :) They are the same charging profile and have the same name in the original logs. No other stack traces relating to this issue. We haven't modified Steve at all (at least yet). To me, it seems that three things could be the source of this problem: the Azure config (unlikely), Steve itself (also unlikely), and the charging point. So if you have never seen this error message before, then it seems likely to me that the charging point could be the origin. I am going to try to run Steve on a local machine, but testing that is going to take much longer, since I also have to reconfigure the charging point.

Also thank you very much for the quick response, I appreciate it.

[goekay]

I am going to try to run Steve on a local machine..

this looks like a good starting point to debug. since this is the first issue report of this kind, i tend to believe that the charging station is at fault. maybe it cannot process/interpret the received message, and unexpected things happen which causes the premature connection close. looking at charging station logs would be helpful, as well.

just to reassure you, here is the timeout and message size configuration, which is more than generous (imho),

On some operations, e.g. Set Charging Profile or Send Local List...

buggy implemention on station side might be the source of the problem. see: https://github.com/RWTH-i5-IDSG/steve/issues/126#issuecomment-480416281

[villanyibalint]

Unfortunately we don't have access to chargepoint logs :/ I'm going to try a client side script and simulate a charge point. If that works, then it's very likely that the charge points are the problem. I could also confirm this if I had access to charge points from other manufacturers, but I don't. Thanks very much for the help. In the unlikely situation that I find that it was in fact Steve misbehaving, I'll reopen.

[goRaspy]

Unexpected closed web sockets may come from sim cards infrastructures.

If you use a sim card try to reduce heartbeat to 4 minutes in steve and look if problems happen again. It can be helpful to verify if cell network do kill communication before websocket ping/pong.

Le dim. 14 avr. 2019 à 20:02, Villányi Bálint notifications@github.com a écrit :

Closed #129 https://github.com/RWTH-i5-IDSG/steve/issues/129.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/RWTH-i5-IDSG/steve/issues/129#event-2275007508, or mute the thread https://github.com/notifications/unsubscribe-auth/AJnQzD-EutjEHyXVVabLWsDsMkUWQvHBks5vg200gaJpZM4cuuaM .

[villanyibalint]

Well we do use SIM cards in all charging points, although we already used a heartbeat of only 20 minutes. But I'm going to try lowering it even more. This would also mean that the error shouldn't appear right after a boot sequence when the connection is still fresh, would that be correct? Thank you very much for the suggestion.

[goekay]

guys... please consider that the connection close happens 2 seconds after sending the request. so... the connection is not idle or something. i really am betting on buggy implementation.