-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System.Net.WebSockets.WebSocketException (0x80004005) in OCPPMiddleware.OCPP16.cs #31
Comments
Is this problem still open? |
Dear Ulrich! Charger is METRON „Duo“. Details from BootNotification:
This particular problem is solved but one another occured. 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:
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:
OCPP server always responds the same:
(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:
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. How to get charging station to behave normally like before? Many thanks in advance! |
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!? Regarding the StopTransaction without IDTag there is the line |
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? |
Yes, correct. Every 10 seconds.
Does the quotation from the OCPP 1.6 doc (in my last post) about case if server does not respond correctly on StopTransaction looks to you that can cause such behavior of charger-station? Doc does not mention how to fix that behavior, maybe a reboot is implied?
But it didn't help anyway.
|
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. |
Seems not. Distributor asked to unmount the controller and send to them for firmware upgrade. |
By the way:
|
I see. I thought it was something like that! |
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](Memory
1 payloadBuffer, CancellationToken cancellationToken) at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder
1.StateMachineBox1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token) at System.Threading.Tasks.ValueTask
1.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)**
The text was updated successfully, but these errors were encountered: