Updating the game-config (sam-config).

This Issue is for determining what needs to be sent from simoc-sam (socketio server) in terms of default values and/or mission configurations to include its structure. Currently sam-config is loaded from a file (src/assets/sam-config.json) on the simoc-web repository. It takes the following form,

{
   "agents":{

   },
   "storages":{
      "air_storage":[
         {
            "id":1,
            "atmo_o2":0,
            "atmo_co2":0,
            "atmo_n2":0,
            "atmo_ch4":0,
            "atmo_h2":0,
            "atmo_h2o":0,
            "total_capacity":{
               "value":1,
               "unit":"kg"
            }
         }
      ],
      "water_storage":[
         {
            "id":1,
            "h2o_potb":0,
            "h2o_urin":0,
            "h2o_wste":0,
            "h2o_tret":0,
            "total_capacity":{
               "value":0,
               "unit":"kg"
            }
         }
      ],
      "nutrient_storage":[
         {
            "id":1,
            "biomass_totl":0,
            "biomass_edible":0,
            "sold_n":0,
            "sold_p":0,
            "sold_k":0,
            "sold_wste":0
         }
      ],
      "power_storage":[
         {
            "id":1,
            "enrg_kwh":0
         }
      ],
      "food_storage":[
         {
            "id":1,
            "food_edbl":0
         }
      ]
   },
   "termination":[

   ],
   "single_agent":1,
   "total_amount":10
}

Currently, we have decided to keep the sam-config on the frontend. Initially, the simoc simulation would create a game-config from the backend using the configurations provided by the user and send it to the frontend. This step was bypassed since the configuration menu is not available in live mode.

The socketio server on simoc-sam, sends a little json object as follows,

{
   humans: 4,
   volume: 272
}

We need to determine the following,

Do we want to keep the structure of this little json object used to set sam-config values on the frontend?
What key-value pairings do we need to include, at the minimum, for any live sensor run?
Are these the key-value pairings we want or need in sam-config, in order for the dashboard to work?

Do we want to keep the structure of this little json object used to set sam-config values on the frontend?

What key-value pairings do we need to include, at the minimum, for any live sensor run?

Are these the key-value pairings we want or need in sam-config, in order for the dashboard to work?

Currently it seems that the only two panels that need the habitat volume are the AtmosphericMonitors and InhabitantsStatus panels (ctrl+f for total_capacity). The latter also requires the number of humans.

Technically if you don't use these two panels and/or if you create new panels that only use the step data, then we don't even need an initial object.

The information that the SAM backend has (whether they are useful for the clients or not) are:

"dynamic" info about the connected sensors (how many, what types, their update frequency, etc.).
- currently we only know how many, but we could update the sensors to inform the socketio server about their capabilities when they connect
- we should also be careful about race conditions, in case a client connects before all the sensors are registered
- there could also be a separate event to get an updated list, since sensors might connect and disconnect at runtime
"static" info about the habitat (that could be set and stored in a local file), such as:
- the number of inhabitants
- the volume of the habitat
- possibly the location/altitude
- others?

The object could eventually look like:

{
  habitat: {
    inhabitants: 4,
    volume: 272
  },
  sensors: [
    {id: "...", model: "adafruit_scd30", update_frequency: "3", location: "greenhouse",
     units: {co2: "ppm", humidity: "%", temperature: "C"}},
    {id: "...", model: "adafruit_scd30", update_frequency: "3", location: "crew quarters",
     units: {co2: "ppm", humidity: "%", temperature: "C"}},
    {id: "...", model: "vernier_xxx", update_frequency: "1", location: "crew quarters",
     units: {co2: "ppm"}}
  ]
}

We could also create two events to retrieve these value and maybe avoid sending the initial object altogether.

Currently it seems that the only two panels that need the habitat volume are the AtmosphericMonitors and InhabitantsStatus panels (ctrl+f for total_capacity). The latter also requires the number of humans.

The latest commit in the capstone-ctrls branch associated with the PR into capstone on simoc-web can demonstrate this pretty easily. The state variables in step.js are all initially set to empty objects, 0's and nulls which are all grouped together in a step_data object. If none of these values are set using the mutators they stay their initial values and are passed to the dashboard. If a value is needed, the dashboard will throw an error and that indicates that that state variable needed to be updated using a mutator. I'm still working on step.js but it'll be even easier to determine the exact agent values that are required once I finish it.

The information that the SAM backend has (whether they are useful for the clients or not) are

The store step.js is set up so that there is only one place that needs to be updated when the structure of the sensor data sent from the backend is updated i.e. when the key names change. This place is in the function parseData at the end of the file. When the sensor data is passed to this function state variables are updated depending on the data collected. It does this by comparing keys. So if the names of any keys are changed or nested inside of an object, this is the location that needs to be updated.

overthesun / simoc-sam

Updating the game-config (sam-config). #5