Permanently disconnecting websocket in v201 when stop function is called

[Pietfried]

@mennodegraaf reported that a normal ChargePoint::stop() results in a segfault:

^CBBOC (main.cpp:48) [info ] Signal Interrupt received, closing backoffice communication application
BBOC (websocket_base.:85) [info ] [libocpp] Disconnecting websocket...
BBOC (websocket_plain:230) [info ] [libocpp] Closing plain websocket.
BBOC (websocket_plain:241) [info ] [libocpp] Closed plain websocket successfully.
BBOC (message_queue.h:309) [info ] [libocpp] Message queue stopped processing messages
BBOC (websocket_plain:200) [info ] [libocpp] Closed plain websocket connection with code: system:0 (Going away), reason:
BBOC (websocket_plain:96) [info ] [libocpp] Reconnecting in: 0ms, attempt: 1
BBOC (websocket_plain:33) [info ] [libocpp] Reconnecting to plain websocket at uri: ws://localhost:7364/tomahawk_test_menno with profile: 0
BBOC (websocket_plain:172) [info ] [libocpp] OCPP client successfully connected to plain websocket server
BBOC (database_handle:135) [error ] [libocpp] Error closing database file: unable to close due to unfinalized statements or unfinished backups
Segmentation fault (core dumped)

[Dominik-K]

Yes, this status was wrong (since the beginning), according to websocketpp's documentation:

 /// The endpoint was "going away", such as a server going down or a browser
/// navigating away from a page.
static value const going_away = 1001;

[mennodegraaf]

Looks good to me, I have tested before that a disconnect with status::normal does not result in a reconnect

[mennodegraaf]

For future reference: there are three issues when calling ChargePoint::stop(), only when the websocket is connected, when it is unconnected it is ok:

• It tries to reconnect after gracefully closing the websocket
• On close, it logs a message about a failure to open
• The database does not gracefully close, see the error message above about 'unable to close due to unfinalized statements'