SensorBase Blog

Hey all,

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!

A number of users have requested that projects have more definable attributes, such as start and end dates, which could be interpreted as dates of the study or campaign a project is a part of. You can now specify these dates in the project settings page pertaining to each project you have build access to. Please let me know if you encounter any problems. More definable attributes to come soon!

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.

Just getting started on making searching through projects on Sensorbase more useful. Check out the Search page to see the new features as the come up. Currently the only additional feature is the ability to search through public projects by the creator’s email address or full name. More features are planned for the coming future. Let me know if you encounter any problems!

Remember that old feature we had in place that would direct you back to your main user page after you had clicked to go to some specific page on sensorbase and it turned out you were logged out and had log back in? Yeah, that’s the one. Well, we decided it was too good of a feature to keep on the site, so we’re replaced it with another which will redirect your back to your intended destination on the site after re-logging back in.  Hopefully, people enjoy this feature a little more : )

If you notice any problems, please let me know!

It is now possible to create your own account through the account creation page. Currently only a certain types of email addresses are supported, but the list will be expanded later. If you think your email domain should be included in the list, please let us know.

When you account is created, you will be sent an email to confirm your email address containing a link to activate your account.

Please let us know if you encounter any problems.

So, seeing how in the last week I’ve only seen 16 of the 330 registered users log into sensorbase, I thought I should add functionality to automatically reset a password and have a new one mailed to you. This lets anyone reset a password as long as they know a valid email, but only let’s this happen once a day.

Once a password is reset, the owner can log into sensorbase with this password and change it to another more appropriate password through the ol’ user_setttings page linked to from the top of the page when a user is logged in.

Perhaps I could make the resetter also be prompted for the the full name associated with the email before allowing a reset to occur, but for now it will just be an email that is necessary. Let me know if you encounter any problems.

It seems that the XML parsing feature for json location data that takes in something like this:

{”gps_module_name”:”Assisted GPS”,”latitude”:34.069239132371,”longitude”:-118.4429105267, “altitude”:124,”horizontal_accuracy”:60.79863357544,”vertical_accuracy”:65, “fix_time”:”2008-07-08T23:11:34.398000Z”,”speed”:0.5400000214577}

was not working. Going over the code, it seemed that the functionality had not been inserted over a course of rewritting the surrounding code. I added in the functionality again, and it seems to be working fine with the test cases I’ve provided. Let me know if you encounter any problems.

Hey all,

Now you can all have access to the Sensorbase code to play with on your own. Enjoy! Currently you only have read access to the repository, but if you’re someone we know who likes to contribute, send me an email and we might be able to discuss adding you on the list of contributors. Check it out at: SVN access

This is another one of those features people have been asking for a lot. The ability to specify whether or not a column within a table is to be UNIQUE or not. I have therefore implemented two functions to modify columns within a table to set and unset UNIQUEness for the specified column. If you want to set a column as UNIQUE, it must be the case that the existing rows not have any non-unique values for the column in question. Otherwise, I think it’s pretty straightforward. Let me know how it works out.
UNIQUE columns

I still have to work on updating this for the UI on the website, as well as displaying this information about columns in certain pages, but slogging now works according to how the column is specified. (If you try to add a row with a non-unique value for a UNIQUE column, you’ll get an error stating that you didn’t provide a unique value where required)

Adding on to the Inner Join SELECT query functionality, I’ve also included LEFT, RIGHT, and STRAIGHT types of joins for the query. There are still a few things you can’t do with these functions, but it’s all mentioned in the link: here. Anyways, hope these prove to be useful, let me know what other aspects of JOINS would be nice to have implemented.