Notifications:

We have already changed the notifications to store all notifications to the database and made the reporting a company setting as with maintenance etc. I am storing the “action” from the notification message rather than the notification type as it makes for a more readable display. The notification reports are filtered according to the logged in user. What we would like to implement are:

Change the notification type field to allow more characters (so that the content isn’t truncated) or add a new field to store it.

Have a way of “acknowledging” notifications so that the they are no longer displayed or can be filtered by status. This could be tagged with the user_id as with completing a maintenance task and would be applied to all users who received the notification. You could also have a “note” field for comments.

Allow the ability to notify on selected events or inputs. For instance, if you have notifications enabled and GPIO1 enabled you receive notifications on every state change. What if you wanted to monitor GPIO1 so that you could view the state on the report but did not need to be notified?

Going further still, create notification “severities” and choosing to receive only notifications based on severity.

SMS notifications – we already added an phone number field to the user record for that purpose.

Maintenance:

We have done a bit to added the maintenance additions/edits in line with your suggestions. Other ideas include:

Add “note” field so that comments can be added.

Add new maintenance triggers?

Devices:

Mark devices as “Fixed location” while allowing them to be given location coordinates so that they are visible on the map. Use a modified version of the simulator or geofence creation tools to enter the default location information.

Extend devices to accommodate more transducers. We expect to be using devices with many more transducers and would like a flexible way of accommodating these.

Dashboards:

We would like to be able to use gauges and charts to display current and historical data from transducers.

Notifications
First off, it’s exciting to see modifications made to the core application and notifications are an area that we’ll be working to improve. This maybe a great opportunity to provide notification management/reports in a Rails plugin (need to think on that more). Your notification suggestions will be discussed internally and we’ll post more details in the near future.

Maintenance
I think the note field is a great idea and would be simple to implement. Can you clarify what you mean by “maintenance triggers”?

Devices
We’re doing some simple prototyping of “fixed assets” and we’ll likely release a preview today. We realize there will always be a need to support more transducers and have had many internal discussions. I think our objective will be to provide a simple and scalable way to allow developers to extend the schema to support this. Let us do some more thinking on this and if you have any suggested approaches we’d love to hear them.

Dashboards
We’ve tried to keep our software simple and elegant. Not to say that dashboards don’t fit into that model, but we haven’t had many requests to do much visualization (beyond maps). If there’s anything in particular that you’d like to see then please let us know. As I hear the term “Dashboard” I quickly think of charts and gauges. There are many packages out there that support XML and could be easily integrated with the core Rails app. Here are a few links of interest

http://code.google.com/apis/chart/types.html

http://www.fusioncharts.com/ (one of my favorites because of the visual design, have charts and gauges)

http://nubyonrails.com/pages/gruff

Thanks for all your thoughts and let us know if you come up with anything else!

By creating the the notifications reports we have, to a large extent, overcome the original reasons for adding new maintenance triggers but the idea was as follows:

The original concept was to use the maintenance task to implement some kind of Alarm functionality. Let’s say we’re monitoring a GPIO that is driven by some fault indicator. If a fault occurs we may receive a notification but once it goes away there is nothing that persists to tell you that the event happened and that action is required. Maintenance tasks, on the other hand, persist until someone takes action to complete it. Currently, tasks are only triggered by scheduled events - number of runtime hours or by date but what if you were able to trigger them based on a GPIO? Then you would have an action item that would remain until someone took steps to acknowledge it.

In reality, the notifications module are probably more suited to the “alarm” functionality and so we have been moving in that direction. With the notification reports, you can now view a history so at least that part will persist. My other suggestions regarding the notifications are also geared towards this goal. I was thinking though that there may still be a benefit to being able trigger a maintenance task from some other event, such as a GPIO or accumulated mileage.

There probably isn’t much call for Dashboards with these simple tracking devices as there simply isn’t that much to display. Our long term plans are to support a lot more in the way of fixed location sensor monitoring.

With respect to charting, this post has a comparison of a few charting packages, both free and commercial, which are Ruby/Rails compatible:

http://www.infoq.com/articles/sharma-charts-in-rails;jsessionid=6F1424DF39BA3322499EDC85ECDC33D6

Good informative post….. Cheers…..