DjsBlog: Softata -Blockly Session

Site Calendar

The top level code behind Softata Blockly (and its Swagger interface) are ASP.NET Controller methods. Whilst the overall state is maintained at the Arduino RPi Pico W end through the connection to it, what options for state are there at the top level and the middle level .NET SoftataLib API?

There are 3 levels of state with Softata

The Blockly/Blazor/Console app
The Softata .NET API
The Arduino Sketch

3. Sketch State

The Arduino Softata Sketch that runs on the RPi Pico W is quite stateful:

Some of the Sketch States:

Starting/Booting/Booted
Connected/Not Connected
Connected to IoT Hub/Not Connected
- Telemetry Running/Paused/Stopped
Bluetooth Connected/Not Connected

These states are in software and so are changed by that. Also upon reset/reboot there is a default for each. For example, at startup the device is NotConnected but becomes connected when Blockly/The Blazor App/The Console app connects to the service over WiFi.

Startup menu options are discussed in detail here: Softata-Arduino_Startup_Options including use of a simulated EEProm to store WiFi details, IoT Hub connection information and operation debug settings.

There are also some #define run modes:

#define USINGIOTHUB
#define SERIAL_DEBUG true

If these are changed the Sketch needs to be rebuilt rather than a runtime configuration change. The last of these though can be overridden at startup with the first menu option though.

1. Top Level State

The top level apps that directly interact with a user can maintain state, in particular the Pico Server’s IPAddress and Port. The 2 web based apps use the transitory Session whereas the Console uses System.Configuration

Blockly

From ASP.NET State Management Overview- MSLearn: A new instance of the Web page class is created each time the page is posted to the server. This would typically mean that all information associated with the page would be lost with each round trip. There are though various mechanisms for getting around this such as Session, Cookies and Query Strings.

If a web site/page was fully stateful then all users through all of time would be using the same data set until it was changed or the server restarts. Cookies and Query Strings do not store anything on the server. Information is passed back to the client that is then returned with the call to the server. The Session stores data on the server but is tagged to the client that makes the request an soi only available that client. Hence it facilitates multiple user simultaneous site use. There is also an Application entity but this would be, for example, site configuration data and wouldn’t normally be directly available to end users.

Session retains information for a limited time, eg 20 minutes, only and needs to be reestablished for longer periods onb non use. When using Blockly and repeatedly restarting the connection, it is desirable to not to have to enter the Pico’s IPAddress-Port each time. This is a good candidate for the session. The first time a connection is made, the IPAddress-Port is entered which upon successful connection is stored in the session.

There is now a new Start block called StartSession that takes no parameters but uses the connection information stored in the Session. There is also a ngrok one, StartNgrok.

Blockly Start options

First time you connect with the Start block or NgrokStart. In subsequent connections only need to use StartSession provided no more than 20 minutes apart.

Note that the Connect/NgrokConnect blocks do not store the connection data to the Session.

The session could also be used to store the Azure IoT Hub connection details, taking as input at the app app level, and storing in the Session if successful. Currently this information is stored on the device and retrieved at Setup, or can be overwritten using a menu there. The Session approach hasn’t been implemented at this stage.

Blazor

The between app starts as used by Blockly could be so implemented for the Softata Blazor app. There is the exact same ASP.NET context for Blazor. This hasn’t been implemented thus far. 2Do.

Console app

The Console app can take command line inputs of connection data which could be stored as environment variables. This app though uses System.Config MSLearn Link. The implementation here with the Console app is in a class SettingManager the code for which can be viewed here on GitHub AppSettingsManage.cs. The settings are saved to a file that can be read back in using that class. Whilst a file path can be specified (not in this case), by default,a file is created in the runtime folder called .dll,config, in this case SoftataConsole.dll.config.

To use System.Config you need to add System.Configuration.ConfigurationManager to the project.

To add or update you make a call such as:

  SettingsManager.AddUpdateAppSettings("IpaddressStr", ipaddressStr);

To read in back in:

  string? _ipaddressStr = SettingsManager.ReadSetting("IpaddressStr");
  if (!string.IsNullOrEmpty(_ipaddressStr))
  {
    ...
  }

A config file so generated is:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <appSettings>
        <add key="IpaddressStr" value="192.168.0.12" />
        <add key="Port" value="4242" />
    </appSettings>
</configuration>

As opposed to the ASP.NET Session, this data is unchanged between app runs, regardless of the time gap. The app loads the values from the file then prompts for changes. If changed, the values are saved.

2. SoftataLib API State

The library state is a little more problematic. As indicated there can be state directly at the app level and in the target Arduino sketch.

The SoftataLib classes are not instantiated but are called statically. For example:

private static Socket? client;

So when a connection is made via one of the web apps, the client that subsequently is used to to send and receive messages there is only one instance of the client. So all app users would/could use the same instantiated client to send messages. This suggests a future version of the library that requires instantiation of each class so that each simultaneous user connects to a different device.

This is not an issue for the Console app as the library access is specific the runtime instance. If though running two instances of the console app on the same desktop, they would have the same configuration file.

Level 2 Softaware State

There is a Dictionary in SoftataLib SoftataLibs to which values can be saved against a Guid key. This could also be a Database. These saved values are intact whilst the web service (Blockly or Blazor) continues to run. This could support multi-users. There is a Controller for this SoftataState with Blockly blocks (and Swagger) for each method in it:

  string NewLib();
  void ClearAll();
  IActionResult DeleteState(string key);
  object GetAValue(string key);
  IActionResult SetAvalue(string key, object avalue);
  IActionResult UpdateAvalue(string key, object avalue);

## Conclusion

When a top level app connects via the middle level to the Pico, the connected state is maintained in the middle level of the stack:

  public  static Socket? Client

This though is a static variable and so if the top level app is a web site (Blockly/Slack/Blazor) then only one user and one Pico can be hosted by the app. This is OK if running the web app locally with one user and one device. But if the user wants to simultaneously use multiple Picos at the same time or the web app is to be hosted remotely, say on Azure, with multiple simultaneous users the middle level of the stack needs to be made reentrant. This can be done by removing the static monica on variables in the middle level etc. 2Do.

	Topic	Subtopic

	*This Category Links*
*Category:*	Softata Index:	Softata
< Prev:	Softata	Open AI and Enums with Blockly & Swagger Part 3

Blog on Microsoft Technologies esp. IoT