Visualizing Device Data on InitialState.com

SiteWhere 1.2.0 introduces a new outbound event processor that allows device event data to be forwarded to InitialState.com for advanced visualization. InitialState supports creating interactive dashboards with visual components such as graphs, gauges, maps, and emojis. With the new outbound processor, streams are created for each device assignment and events are published to InitialState in real time for viewing.

To publish data to InitialState.com, you must first create a user account on the site. After creating a new account via the registration page, navigate to the account page and copy a Streaming Access Key that will be used to send data to InitialState:

In order to forward SiteWhere events to InitialState, a new outbound event processor must be configured in the tenant configuration file. With the tenant stopped, edit the configuration file and add the following to the outbound processor configuration:

[xml] [/xml]

After restarting the tenant, all events processed by the tenant will automatically be forwarded to InitialState.com. A separate stream is created for each device assignment as events are published. Now that SiteWhere is connected to InitialState, we need to generate some live data that will be forwarded. Open an existing device assignment and start the assignment emulator. Zoom in on the map and click on a location to add a new location event for the assignment:

Log in to your InitialState account and view the list of data streams in the drawer on the left side of the screen. A stream should have been added for the device assignment used in the previous step. Data from the emulator should now be available in the stream for the assignment. Open the Tiles application in your InitialState console to start visualizing the new data. Since the data is geospatial, use the dropdown on the default tile to choose the Map visualization. The new location data should show up as shown below:

Now that we have data successfully streaming into InitialState, we can start to visualize other types of events. Measurements and alerts can be added via the emulator or gathered from real devices. New tiles will be added for each unique type of data. For instance, adding measurements with names vehicle.speed and fuel.level will result in new tiles for the speed and fuel level of the vehicle being tracked. Alerts can also be added to track exceptional events such as critical fuel levels or movement of a vehicle outside of the work site. InitialState provides many visualizations that can bring the data to life:

Integrating SiteWhere data with InitialState is easy and provides a powerful stage for visualizing your data over time. Start testing out the visualizations with your own live device data and explore the many visualizations provided by the InitialState platform. Any input that generates data into SiteWhere can be visualized, including openHAB, Android clients, or other integrations. Have fun!

SiteWhere 1.2.0 introduces an advanced multiple tenant architecture that allows many IoT applications to run side by side in a single SiteWhere instance. Each tenant is isolated in terms of data storage and processing pipeline so that there is no chance of intermingling data. The new architecture is accompanied by an administrative interface for managing tenants and interacting with them.

The SiteWhere administrative application has been extended to offer tenant management capabilities. A new Tenants tab has been added to the application and is visible to system administrators. Clicking on the Tenants tab brings up a list of tenants registered in the system.

Each tenant has a unique id, a name, and a logo URL that identify it in the list of tenants. Each tenant is also associated with one or more system users, allowing them to log in an manage data for the tenant. If a user is only associated with a single tenant, the login page will proceed directly to that tenant. Otherwise, a list of associated tenants is shown and a tenant must be selected to continue into the administrative application. The logo image for the tenant is shown at the top left of the administrative application to indicate which tenant is currently being managed.

Clicking on a tenant in the list navigates to the detail page which provides information about the tenant and allows related actions to be taken.

The detail page shows information about the lifecycle status of the tenant — whether it is currently running or not. If the tenant is currently running, it shows the status of the entire hierarchy of components running within the tenant and the current XML configuration that is active. A running tenant also displays a button for shutting it down. Note that a running tenant does not allow its properties to be edited. A tenant may also show up as stopped as shown below:

A stopped tenant does not display hierarchy or configuration information. The list of action buttons changes as well. A stopped tenant may be edited, deleted, or started. Note that deleting a tenant does not delete the underlying tenant configuration file. In order to reconfigure an existing tenant at runtime, stop the tenant, make changes to the underlying xxx-tenant.xml configuration file, then restart the tenant. This process will not affect other running tenants on the SiteWhere instance.

The introduction of multitenancy resulted in significant architectural changes which affect many aspects of the system. Because of this, upgrading from previous versions is not recommended. Start with a clean installation from a downloaded bundle, then migrate your existing configuration to the new installation. Below are some of the key aspects of the system that changed to support multitenancy.

Before 1.2.0, all SiteWhere data was stored in one place. In MongoDB, there was a single database. In HBase, there was a single group of tables. The new architecture separates tenant data for the purpose of security, so the database storage strategy changed to match the requirements. There is now the concept of a core database (or tables in HBase) that stores the user management and tenant data. There is also a separate database (or tenant tables in HBase) for each tenant. The tenant database contains all sites, specifications, devices, assignments, etc. for the given tenant. In MongoDB, the default database is still named sitewhere and the tenant databases are named tenant-xxx where xxx is the unique tenant id. In HBase the core data is stored in the users table while tenant data is stored in the xxx-table table (e.g. default-devices specifies devices table for default tenant).

Before 1.2.0, all SiteWhere data was stored in one place. In MongoDB, there was a single database. In HBase, there was a single group of tables. The new architecture separates tenant data for the purpose of security, so the database storage strategy changed to match the requirements. There is now the concept of a core database (or tables in HBase) that stores the user management and tenant data. There is also a separate database (or tenant tables in HBase) for each tenant. The tenant database contains all sites, specifications, devices, assignments, etc. for the given tenant. In MongoDB, the default database is still named sitewhere and the tenant databases are named tenant-xxx where xxx is the unique tenant id. In HBase the core data is stored in the users table while tenant data is stored in the xxx-table table (e.g. default-devices specifies devices table for default tenant).

For users that only need a single tenant, most aspects of the system should work as they did before. For users that require support for multiple tenants, the new architecture and administrative options will allow any number of tenants to run concurrently while only introducing minimal overhead. Now that you understand how SiteWhere supports multiple tenants, try it out in your own installation. SiteWhere 1.2.0 is available for download and in the cloud. The SiteWhere team looks forward to your feedback!