System.Net.WebSockets.WebSocketException (0x80004005) in OCPPMiddleware.OCPP16.cs
Closed this issue · 9 comments
Hello!
I get above error at this line when receiving data:
WebSocketReceiveResult result = await chargePointStatus.WebSocket.ReceiveAsync(new ArraySegment<byte>(buffer), CancellationToken.None); (this is line 32 of: OCPPMiddleware.OCPP16.cs)
Error (bolded) is below (along with leading context):
info: OCPPMiddleware[0]
OCPPMiddleware => Connection request with chargepoint identifier = 'my_station_ID1'
info: OCPPMiddleware[0]
OCPPMiddleware => SUCCESS: Found chargepoint with identifier=my_station_ID1
info: OCPPMiddleware[0]
OCPPMiddleware => No authentication for chargepoint 'my_station_ID1' configured
fail: Microsoft.AspNetCore.Server.Kestrel[13]
**Connection id "0HMUP3UVKMSG2", Request id "0HMUP3UVKMSG2:00000002": An unhandled exception was thrown by the application.
System.Net.WebSockets.WebSocketException (0x80004005): An exception caused the WebSocket to enter the Aborted state. Please see the InnerException, if present, for more details.
at System.Net.WebSockets.ManagedWebSocket.CloseWithReceiveErrorAndThrowAsync(WebSocketCloseStatus closeStatus, WebSocketError error, String errorMessage, Exception innerException)
at System.Net.WebSockets.ManagedWebSocket.HandleReceivedCloseAsync(MessageHeader header, CancellationToken cancellationToken)
at System.Net.WebSockets.ManagedWebSocket.ReceiveAsyncPrivate[TResult](Memory1 payloadBuffer, CancellationToken cancellationToken) at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder1.StateMachineBox1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token) at System.Threading.Tasks.ValueTask1.GetTaskForValueTaskSource(IValueTaskSource`1 t)
--- End of stack trace from previous location ---
at OCPP.Core.Server.OCPPMiddleware.Receive16(ChargePointStatus chargePointStatus, HttpContext context) in C:\Users\JOSKO\Documents\VisualStudioProjekti\OCPP.Core-main\OCPP.Core.Server\OCPPMiddleware.OCPP16.cs:line 32
at OCPP.Core.Server.OCPPMiddleware.Invoke(HttpContext context) in C:\Users\JOSKO\Documents\VisualStudioProjekti\OCPP.Core-main\OCPP.Core.Server\OCPPMiddleware.cs:line 404
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)**
Is this problem still open?
It doesn't seem to be caused by OCPP.Core. The websocket connections seems to get closed right after the connection was initiated. What client (=charger) are you using?
Dear Ulrich!
Charger is METRON „Duo“. Details from BootNotification:
BootNotification",{"chargePointVendor":"Metron","chargePointModel":"ME3 DYNAMIC OCPP","firmwareVersion":"1.04"}
This particular problem is solved but one another occured.
First of all, your code seems to have had a problem in the scenario where the charging is ended by a button and unplugging instead of ending with an RFID tag.
This problem was “Object reference not set to an instance of an object” in: …\OCPP.Core.Server\ControllerOCPP16.StopTransaction.cs line 49 and I have corrected it with:
stopTransactionResponse.IdTagInfo = new IdTagInfo();
The real trouble now is that after the charging-station has sent “StopTransaction” for the first time, Your OCPP backend did not respond properly but responded with:
[4,"1009298","FormationViolation","",{}]
due to the above described bug.
I cannot be 100% sure was this the reason but the fact is that immediately after that response, the station started to send same message again and again (every 10 seconds) regardless what is being done at the station:
[2,"1000001","BootNotification",{"chargePointVendor":"Metron","chargePointModel":"ME3 DYNAMIC OCPP","firmwareVersion":"1.04"}]
OCPP server always responds the same:
[3,"1000001",{"status":"Accepted","currentTime":"2023-11-28T19:40:22.2973429+01:00","interval":300}]
(of course the time is always different, i.e. . the current one).
Up to that point OCPP communication was normal.
The argument that supports this theory is the OCPP 1.6 document which says:
It is likely that The Central System applies sanity checks to the data contained in a StopTransaction.req it received. The outcome of such sanity checks SHOULD NOT ever cause the Central System to not respond with a StopTransaction.conf. Failing to respond with a StopTransaction.conf will only cause the Charge Point to try the same message again as specified in Error responses to transaction-related messages.
What I also notice is that after the charger-station connects to the server and sends the BootNotification, it TERMINATES the connection with the server.
This BootNotification and disconnection happens at roughly the same interval (every 10 seconds). The server responds to BootNotification immediately – without waiting. Nothing else can be obtained on the server no matter what they do in the charging station. Cars seem to be charged OK.
They restarted the charger-station several times and even tried reconnecting network cable, but nothing happened until this moment.
How to get charging station to behave normally like before?
Many thanks in advance!
Regards,
Joško
The answer to the boot notification seems to be correct. It sends "Accepted" and tells the charger the expected interval for heart beats messages. I have no idea why the charger disconnects!?
The disconnect results in errors in the log files but after the reconnect all should be fine again. So there's no critical problem. But if the charger does that every few seconds it is really bad.
Regarding the StopTransaction without IDTag there is the line
stopTransactionResponse.IdTagInfo = new IdTagInfo();
missing. You are correct.
I will fix that.
Please check V1.3.0 - the IdTag error should be fixed. But your fixed version basically does the same.
If I understand the behavior correctly, your charger now keeps disconnecting/reconnecting in a short interval und resends the boot notification. Is that correct?
I still have no idea what could be the reason. The response message looks perfect to me.
It is difficult to judge what the charger does internally. Obviosly the OCPP.Server wasn't supposed to reject the StopTransaction. But then the charger should resend THAT message until the server accepts it. So when you fixed the bug the situation should be resolved.
I don't see a reason why the charger keeps sending boot notifications unless it is in some kind of failure state and reboots or disconnects itself.
Is there a way to factory reset the charger?
Seems not. Distributor asked to unmount the controller and send to them for firmware upgrade.
Thanks for feedback!
By the way:
I never noticed the bug with the StopTransaction IdTag because our chargers always send an IdTag. Here a sample message where the transaction was forcibly ended by the car. The charger sends the tag from StartTransaction (I just replaced my real value with abcd :-))
[2,"4f00ebbc-da45-4cd9-af3a-153e4c10fb97","StopTransaction",{"transactionId":15,"idTag":"abcd","timestamp":"2021-04-09T05:46:22.212Z","meterStop":20138,"reason":"**EVDisconnected**","transactionData":[{"timestamp":"2021-04-08T18:49:11.802Z", ...
I see. I thought it was something like that!