So I know there hasn’t been many updates in the last month, and that’s mostly because I’ve been working on a big addition to Sensorbase, which as it gets expanded upon, will be very useful. In fact, I think it’s pretty useful as it is stands right now. Today, we introduce a new feature called Notifications.

Notifications allow for users to define specific table-level conditions which, when applied to the incoming sensor data, can determine whether or not a user should receive some sort of notification. For example, say you have a table which stores temperature data and you would like to be notified when an inputted value exceeds a certain threshold, you can specify all of that in the Manage Notifications page, accessible by navigating to a table page within Sensorbase, and then clicking on “Manage Notifications” or the right side menu bar.

This feature also allows for multiple conditions to be combined in order to create a more exclusive notification. When multiple conditions are defined for a specific notification, it is necessary for all the conditions to be met in the incoming data, in order for the notification to trigger and be sent to a user.

Currently, the only users who can receive notifications of met conditions are the Owners of the table in question. Later on, support for those with write access to tables may be added.

In addition, the method of notification is currently limited to an email sent to the owner’s email address as listed through Sensorbase, containing information on which condition(s) were met and what incoming data was responsible for the triggering.

Another feature available to notifications is the ability to create recurring notifications vs. one-time firing notifications. Recurring notifications are the default which will fire every time its conditions are met and won’t be removed until explicitly done so in the “Manage Notifications” page. One-time notifications will be exist until they fire for the first time. At this point, they are automatically deleted from the list of table notifications.

There are currently several different conditions which can cause notifications to fire. Below is a detailed list of each type and how they work:

• By Last Active - refers to the last time an entry was slogged into the table, in terms of days. A value of 0.083 represents 1 hour, the smallest interval which can be computed. Values smaller than this will still be accepted but will not be guaranteed to result in an accurate notification. However, they will be accurate to within the hour.
• Equals to - The parameter entered must be a numeric value, representing the number of days you wish the table to be inactive before being notified.
• Table Row Count - This condition refers to the current number of rows stored in the table after the last entry has been stored.
• Equal to - The parameter must be a positive integer. If the number of rows is equal to this number, a notification will be sent.
• Greater than - The parameter must be a positive integer. If the number of rows is greater than this number, a notification will be sent.
• Less than - The parameter must be a positive integer. If the number of rows is less than this number, a notification will be sent.
• By User Slogged - This condition deals with the user who slogged the last entered row. Users are specified by entering text representing the UserID of an account, or most likely, their email address.
• UserID is equal to - The parameter must be a string representing the UserID of an account, most likely an email. If the slogger of the last row is equal to this user, a notification will be sent.
• UserID is not equal to - The parameter must be a string representing the UserID of an account, most likely an email. If the slogger of the last row is not equal to this user, a notification will be sent.
• By Slog Time - This condition deals with the time at which the last row was entered into the database.
• Date is equal to - The parameter must be a string representing a date in the yyyy-mm-dd format, specifying the date to match. If the last row entered was submitted on this date, a notification will be sent.
• Date is before - The parameter must be a string representing a date in the yyyy-mm-dd format, specifying the date to match. If the last row entered was submitted before this date, a notification will be sent.
• Date is after - The parameter must be a string representing a date in the yyyy-mm-dd format, specifying the date to match. If the last row entered was submitted after this date, a notification will be sent.
• By Specific Table Column - These conditions depend on user defined columns within the table in question. All possible columns are separated into four different categories: text, number, date/datetime, or time.
• Text - Column types such as TEXT, TINYTEXT, MEDIUMTEXT, and VARCHAR fall under this category.
• Equal to - The parameter must be a string representing the value which the text column must match in order to signal a notification.
• Starts with - The parameter must be a string representing the value which a text column must start with in order to signal a notification.
• Contains - The parameter must be a string representing the value which a text column must contain in order to signal a notification.
• Number - Data types such as INT, TINYINT, SMALLINT, MEDIUMINT, BIGINT, BINARY, FLOAT, and DOUBLE fall into this category.
• Equal to - The parameter is a string representing the number which the inserted column must match in order to signal a notification.
• Greater than - The parameter is a string representing the number which the inserted column must be greater than in order to signal a notification.
• Less than - The parameter is a string representing the number which the inserted column must be less than in order to signal a notification.
• Date or DateTime - Data types such as DATETIME and DATE fall under this category.
• Date equal to - The parameter specifies a string representing a date in yyyy-mm-dd HH:MM:SS or yyyy-mm-dd format which must be matched in order to signal a notification.
• Date before- The parameter specifies a string representing a date in yyyy-mm-dd HH:MM:SS or yyyy-mm-dd format for which the column value must be a date before in order to signal a notification.
• Date after- The parameter specifies a string representing a date in yyyy-mm-dd HH:MM:SS or yyyy-mm-dd format for which the column value must be a date after in order to signal a notification.
• Time - The TIME data type is the only type in this category.
• Time equal to - The parameter specifies a string representing a time in HH:MM:SS format which must be matched in order to signal a notification.
• Any column of type BLOB, TINYBLOB, or MEDIUMBLOB within your table is ignored and not offered as a condition for notification.

That concludes the description of the new notification feature, if you have any questions please respond with your comments to this post, I’m sure others might have the same questions. As always, I appreciate your help in detecting bugs, so please let me know.

To finish up this post, I also wanted to state a few other changes that you may have noticed:

• I replaced the interactive google map on the front page with a image to save on load time. It was unnecessary to actually use.
• Modified the navigation links at the top of the page to better show the hierarchy of where you are relative to your projects, tables, etc.
• Removed some dead links and labeled project and table tags in the respective “view” pages (project_view and table_view).
• Other subtle global CSS changes.

Again, please let me know if you experience any problems or bugs. Thanks all!

Sorry again,

Keith

Edit: Please note, if you’re having trouble using some of the javascript related features on the site, please do a full reload of the page, ctrl+F5 in firefox, so that any cached files will be redownloaded to your machine. This should fix any recently developed problems.

If you notice any problems, please let me know!