Skip to content

Start and Stop Charging

RELEVANT BRANCH

https://github.com/Solenergy-Systems-Inc/envision-vps/tree/main-migration

OLD SYSTEM

sequenceDiagram
  participant FRONTEND
  participant AWS BE
  participant FLASK APP
  participant WebSocket SERVER
  participant EMBEDDED

  loop
    EMBEDDED->>WebSocket SERVER: HEARTBEAT & OTHER MESSAGES <br> (CHECK NOTE 1)
  end

  FRONTEND->>AWS BE: START CHARGING <br> VIA HTTP
  AWS BE->>FLASK APP: START CHARGING <br> VIA HTTP
  FLASK APP->>WebSocket SERVER: START CHARGING <br> VIA WebSocket <br> (CHECK NOTE 2)
  WebSocket SERVER->>EMBEDDED: START CHARGING <br> VIA WebSocket

  EMBEDDED->>WebSocket SERVER: RETURN RESPONSE <br> VIA WebSocket
  WebSocket SERVER->>FLASK APP: RETURN RESPONSE <br> VIA WebSocket <br> (CHECK NOTE 2)
  FLASK APP->>AWS BE: RETURN RESPONSE <br> VIA HTTP
  AWS BE->>FRONTEND: RETURN RESPONSE <br> VIA HTTP

NOTES

  1. Messages from the EMBEDDED are handled here.
    • When the WebSocket SERVER receives a heartbeat, it saves that connection to a global dictionary with the site ID as the key.
    • When the EMBEDDED side disconnects, the connection is removed from the global dictionary.
  2. I think this was a workaround. The reason why this connection uses WebSocket instead of HTTP is because the message/response from embedded is received in a separate loop.
    • With HTTP, the separate loop wouldn't be able to send the response.
    • With WebSocket, the connection object between FLASK APP and the WebSocket SERVER can be saved in a global dictionary, which can be accessed by the separate loop to send the response.

NEW SYSTEM

The diagram below includes the inner working of the FastAPI App.

sequenceDiagram
  participant FRONTEND
  participant AWS BE
  participant FastAPI APP
  participant EMBEDDED

  loop
    EMBEDDED->>FastAPI APP: HEARTBEAT & OTHER MESSAGES <br> (CHECK Sub-Graph 1)
  end

  FRONTEND->>AWS BE: START CHARGING <br> VIA HTTP
  AWS BE->>FastAPI APP: START CHARGING <br> (CHECK Sub-Graph 2)
  FastAPI APP->>EMBEDDED: START CHARGING <br> (CHECK Sub-Graph 2)

  EMBEDDED->>FastAPI APP: RETURN RESPONSE <br> (CHECK Sub-Graph 2)
  FastAPI APP->>AWS BE: RETURN RESPONSE <br> (CHECK Sub-Graph 2)
  AWS BE->>FRONTEND: RETURN RESPONSE <br> VIA HTTP

Sub-Graph 1

Whenever the FastAPI APP receives:

  1. Heartbeat from EMBEDDED: the connection object is saved in active_connections.py.
  2. CallResult or CallError from EMBEDDED: the response is sent to the Future objects in delayed_start_responses.py or delayed_stop_responses.py.
flowchart TB
   embedded_socket.py <--> EMBEDDED

   embedded_socket.py --> active_connections.py
   embedded_socket.py --> delayed_start_responses.py
   embedded_socket.py --> delayed_stop_responses.py

   subgraph " "
      GLOBALS

      active_connections.py
      auto_stop_threads.py
      delayed_start_responses.py
      delayed_stop_responses.py

      style GLOBALS fill:none, stroke:none
   end

Sub-Graph 2

  1. start_charging.py and stop_charging.py makes use of data the WebSocket objects in active_connections.py to send the start/stop requests to EMBEDDED.
  2. The Future objects in delayed_start_responses.py and delayed_stop_responses.py are awaited for the response of embedded from the start/stop request.
flowchart TB
   subgraph " "
      GLOBALS

      delayed_start_responses.py
      active_connections.py
      auto_stop_threads.py
      delayed_stop_responses.py

      style GLOBALS fill:none, stroke:none
   end

   active_connections.py --> start_charging.py
   active_connections.py --> stop_charging.py

   delayed_start_responses.py --> start_charging.py
   delayed_stop_responses.py --> stop_charging.py

   start_charging.py <--> AWS_BE[AWS BE]
   stop_charging.py <--> AWS_BE

Sub-Graph 3

  1. The global variable auto_stop_threads contains the Timer threads that will automatically stop the charging. This dictionary exists to have a way to cancel the timer if the charging is stopped manually.
flowchart TB
   subgraph " "
      GLOBALS

      delayed_start_responses.py
      active_connections.py
      auto_stop_threads.py
      delayed_stop_responses.py

      style GLOBALS fill:none, stroke:none
   end

   start_charging.py --> auto_stop_threads.py
   auto_stop_threads.py --> stop_charging.py

NEW NEW SYSTEM

sequenceDiagram
  participant FRONTEND
  participant FastAPI APP
  participant EMBEDDED

  loop
    EMBEDDED->>FastAPI APP: HEARTBEAT & OTHER MESSAGES
  end

  FRONTEND->>FastAPI APP: START/STOP CHARGING
  FastAPI APP->>EMBEDDED: START/STOP CHARGING

  EMBEDDED->>FastAPI APP: RETURN RESPONSE
  FastAPI APP->>FRONTEND: RETURN RESPONSE

In-Depth

Whenever EMBEDDED sends the FastAPI APP a:

  1. Heartbeat: the connection object is saved in embedded_connections.py.
  2. CallResult or CallError: the response is sent to the Future objects in future_responses.py.
flowchart LR
   CLIENT <--> clientSocket.py

   subgraph " "
      embedded_connections.py
      future_responses.py
   end

   clientSocket.py -- <<< --- embedded_connections.py -- <<< --- embeddedSocket.py
   clientSocket.py -- <<< --- future_responses.py -- <<< --- embeddedSocket.py

   clientSocket.py -->|Uses WebSocket object<br>from embedded_connections.py| EMBEDDED
   embeddedSocket.py -- <<< --- EMBEDDED