drc38

The modification stops the ChargePoint instance from responding and replying to messages ocpp received from the charger after the websocket half-close, without generating an error. I will capture a debug...

> Thanks for the PR @drc38. > > > In the integration we want to keep the ChargePoint instance and simply reconnect the websocket > > This make sense. I've...

> The debug log doesn't help me much, unfortunately. > > Assuming this PR gets merged, how you're planning to catch any exception related to connection issues? When you handle...

To prevent the connected charger from incorrectly assuming the websocket is still open after `super().start()` has completed, the following two lines are required in the finally statement: ``` await self._connection.close()...

@OrangeTux, another reason for the PR is for our upstream integration to easily close the `super().start()` awaitable that is initiated by gather. If gather has more than one indefinite awaitable,...

> Are the safety features purely hardware or some security requirements are handled by the ESP32? I'd be hesitant to do this because of safety... From your photo it looks...

Where have you come across "fallback" in the Ocpp standard? If there's an issue with communication any "failsafe" action would need to happen at the charger end.

The SupportedFeatureProfiles and connector_id changes look fine to me. I think there is an easier way to deal with change availability, in `post_connect` move `await self.set_availability()` to the "nice to...

Are you on the latest HA version? If not you need to be on at least 2022.8. Otherwise try a reinstall of the integration ensuring you set the max current...

@bananaslug123 it looks like your charger is isn't conforming to the ocpp standard. You'll need to log the actual messages and look at the response before the index error is...