Web Server for a stack via Wifi
Wifi module AP Server Functionality
This block provides web server functionality on a stack to serve simple web apps using Wifi hardware. Using any web browser, from the desktop or mobile, authenticated end users can connect to the stack over wi-fi to view, edit, update data and control other aspects of the stack. This block is available in Library under Network & Communications section.
The Webserver is accessible from the IP address of the Wifi module [at the time it got assigned by DHCP of the router its connected to] AND via the Access Point IP Address if the WIFI block is setup to act as an Access Point. See WIFI module for details on AP functionality.
By default, the root of the webserver is /. There are a few paths from the root that are predefined such as
/webapp/ –> Path under which all web applications [single page webapps(html+css+js)] are hosted. For example, a web application ‘sensordashboard’ that displays sensor data as a form layout could be specified at /webapp/sensordashboard [Note: we didn’t specify the port in the host address if we are using the standard HTTP server port of 80 which is the default setup]
/data/ –> Path under which data for each of the web applications are accessed. Using the above example, the data for the ‘sensordashboard’ web app could be retrieved and updated independently at the URL /data/sensordashboard
/stack/ –> Path for stack related web services
PROPERTIES:
‘webapp’ : This is a dictionary that specifies the parameters of your default web application. Each web app can have the following specs: ‘path’ –> which will point to /webapp/, ‘label’ –> human readable name which could also be used as a title on the web app if used by the template, ‘template’ –> single page webapp(html+css+js) that is either a blob of text or a UUID of some yet to be defined file type (maybe .html), ‘data’ –> which has any dynamic data to show that will be referenced by GET and PUT/POST at /data/ i.e, the data and webapp paths are parallel structures. The stack web server has a built-in template to display forms and charts which will be used as default it a value is not specified (See Template info for details)
‘credentials’: a list of dictionaries of the form {‘username’:xxx,’password’:yyy,’path’:[‘/zzz’,’/www’]}, where the path, if specified, limits access to THAT user for the specific list of paths (and sub trees below those paths). If path is not specified, the default behavior is that the entire webroot (/) is accessible by that user. This model provides a flexible, fine grained multi-user access control for individual web applications and other web services. Since this property stores sensitive access information, use caution to make sure this is not set on Blueprints directly but is instead allocated via the more secure Stack Environment setup.
‘port’: port number of the HTTP server to which clients connect to access the web server. Default is the standard HTTP port 80
INPUT TERMINALS:
1:init – Any message received by this terminal will initialize the server to start listening on the specified port. Typically this is triggered only once to kickstart the process.
3: in – This is a generic terminal that can handle multiple messages types. The common message is a dictionary of the form similar to the ‘webapp’ property. This can be used to create new web apps or update the data displayed by an existing web application. From our earlier sensordashboard example, when our sensor values changes, we can update them on the webserver by sending a message {‘path’:’sensordashboard’, data:}
In the case of a default web app hosted at /webapp/ as specified in the ‘path’ attribute of the ‘webapp’ property, a convenience feature is to send the data directly without having a need to specify the web app’s path [since it is the only one]. In this case, the data message must always be sent as a list even for a singleton data value.
More than one web app can be created, updated anytime by sending a dictionary that contains at least the ‘path’ attribute along with other attributes optionally.
OUTPUT TERMINALS:
2: out – This is a generic terminal that outputs multiple message types. Typically the output is a dictionary of the form specified in the ‘webapp’ property and is emitted whenever data is modified via a POST or PUT method. For example, in the ‘sensordashboard’ web app, when the user updates a value using the web form template, a dictionary message of the form similar to the ‘webapp’ property is sent out to be handled by the stack application logic which can then proceed to update the sensor configuration and values. In the sensordashboard example, the message will be of the form {‘path’:’sensordashboard’, data:[]}
In the case of a default web app hosted at /webapp/ as specified in the ‘path’ attribute of the ‘webapp’ property, a convenience feature is to send the data directly without having a need to specify the web app’s path [since it is the only one]. In this case, the data message will always be sent as a list even for a singleton data value.
Default Template:
Any web app that doesn’t have a ‘template’ attribute will make use of the default template(s). There are two templates that are available for use based on the user needs.
Form Template:
This is a simple template that provides a form based interface to view and edit properties and their values, say sensor data, in a simple clean layout based on a stripped down version of a light weight css (just 4KB) called Pure – https://purecss.io/
The form template will render the web app based on the data associated with that web app. For instance, in our sensordashboard example, if we want to display three sensor values for Co2 levels, Humidity and Temperature, we would then need to have the data associated with the web app (say via the ‘data’ attribute of the ‘webapp’ property or via any dictionary that has a key value pair of ‘data’:[datavalues]) sent to the 3: in terminal along with the ‘path’ key to associate the data with the corresponding webapp) as follows
[{
"name": 'co2',
"label": 'Co2',
"type": 'number',
"value": 300
}, {
"name": 'humidity',
"label": 'Humidity',
"type": 'number',
"value": 34.3,
}, {
"name": 'temp',
"label": 'Temperature',
"type": 'number',
"value": 79.2,
"editable": True,
}]From the structure above, each data item has a “name” which serves to identify the data item, a “label” which will be used as a label on the form layout, a “type” that describes the value type associated with this data item [numbers, strings etc], a “value” attribute that has the value for the data item and an “editable” attribute that determines if the value can be changed using the web app.
Note: The template will auto-update the data associated with the web app every 4 seconds.
Displaying Graphs:
Any web app using the default template can also display the data as a graph or chart by simply adding a parameter, ?display=graph, to the URL of the web app. For example, if we want to visualize the sensordashboard app as a series of graphs, one for each data sensor type, we can do so by
<ipaddr>/webapp/sensordashboard?display=graph
Note: The graph template will auto-refresh the data associated with the web app every 2 seconds and will render the graph as a time series graph with a sliding window of 100 values that translates to 200 seconds of time series data.
Example Project – Simple Webservice
In the above project, the ‘dashboard data handler’ block provides the data on startup to intiliaze the ‘stackdashboard’ webapp and every few seconds, based on the refresh property, randomizes the values(hence the channels to the Base block’s Random number generation terminals). The following image shows the block details
With the blueprint loaded and having known the IP address of the Wifi block, opening a web browser and pointing it to the ipaddr (in this example it is 192.168.1.105) will bring up a login prompt for the first time (in each browser until the browser is closed). Providing the valid credentials as specified in the credentials property will allow access to the web apps.
Refer to documentation on many other topics at interstacks.com/knowledge-base.
Please email info@interstacks.com with any questions.
IoT account settings
