SteVe doesn't show failed websocket connections

[frmunozForcast]

Hi, I'm trying to configure SteVe with an specific charger station (Terra AC from ABB) but I get no connection nor failed websocket related message in SteVe logging. According to the charge station software, the handshake fails but SteVe does not register this attempt to handshake. How can I configure logging to debug this failed connection?

I know this can be catalogued as a charge station software problem and not related to SteVe. However, I've already validated that this charge station can connect to other ocpp servers without any issue, and furthermore, I can simulate an ocpp charger and connect to SteVe without problems. So I'm quite lost about where it is the problem.

Thanks

[lategoodbye]

@frmunozForcast Assuming your charging station is configured for a unencrypted websocket connection, you could capture a wireshark trace on the server side and attach it here.

[kobalihun]

Hello i have got a same problem. Last week i setup the SteVe on my raspberry pi. I have got an Legrand Green'up Charger. When i upload the WS url to my chaerger it can't connect to my SteVe, and i don't know why. I tested the communication an another solution. I install a home assistant to my another raspberry pi, and i add an OCPP addon. The communication with home assistanc is working. I see the charger id, name, serial number, and i can start stop the charging, reset the softwar ect. so conclusion the connection is working with HA. I don't know what is the problem with SteVe server. Any idea? or solution?

[goekay]

if the call in any shape or form arrives at steve, there must be an entry in the logs. if there is not, the packet probably cannot reach steve. and we cannot do anything in these cases.

[zacjack]

I'm currently in the process of testing some ABB chargers, but I've encountered difficulties when trying to connect them to SteVE. Upon investigation, I've noticed that the chargers use OCPP 1.6J and, when attempting the connection via WSS, they are not sending the OCPP version in the Sec-WebSocket-Protocol header. This omission is causing communication failure. Would it be possible to implement an interceptor to handle these cases where the charging station does not include this field in its communication? Alternatively, could we set this value by default in a variable in case the charging station doesn't send it? This would greatly facilitate integration and interoperability with different devices and protocol versions. I would greatly appreciate any assistance or suggestions regarding this matter.

[goekay]

This would greatly facilitate integration and interoperability with different devices and protocol versions.

according to ocpp spec, this header is a MUST. don't you think that the stations should do the correct thing and set it to facilitate integration and interoperability?