dwiechert / pi-temperature Goto Github PK

When #9 was implemented, it took away pretty-printing of the Alert information. Add pretty-printing of the JSON.

Currently doing synchronized on the name map, need to use a different object so it can be updated - http://stackoverflow.com/a/5861918/864369

Currently the sensors director is hard-coded to be /sys/bus/w1/devices/w1_bus_master1/. Make it a property that can be overridden for easier testing. Property name:

sensorsMasterDirectory

We should add a simple Alert that prints the sensor information to Sys.Out.

Would be nice to have an Alert that sends out an email.

Currently, clearing the sensors name map on each read of the sensors. This is done in case there is a new sensor or one is deleted so we don't have to keep track of that - we just make a new map on each read. Though, while making a new map each time, the names are being lost. Need to check to see if the sensor previously had a name and if so, put the name back in the map after the current read.

It would be nice to have an Alert that records the temperature data to a csv file.

Add the @Async annotation to Alert.alert() and @EnableAsync to SensorsController so each alert can asynchronously do its alerting without holding up the system.

• Reference - http://docs.spring.io/spring/docs/current/spring-framework-reference/html/scheduling.html

Currently, Alert.update is void. It should return a Pair<Boolean, String> so that we can return the appropriate HttpStatus upon update and the error message if the update was unsuccessful.

It would be nice to have an Alert that records the data in Excel so we can track the temperatures over time.

Add method public String getInfo() to Alert so each alert can provide information about itself.

When implemented, the old way of getting info should be removed and use getInfo() instead.

Currently, Alert.update takes a String input parameter. Should it take in some kind of ConfigurationClass and then the Alert itself would be updated to return that class?

public Class<T> getConfigurationClass();

The benefit of using a configuration class is that it'd be easier to see the input to the Alert and we would have a standard way to pass in the data - json. The downside is that each Alert would need to support this ConfigurationClass idea.

However, the AbstractAlert could have a default to just return String to keep it simple if a certain Alert only wanted String input.

Currently users can only list all of the Alerts. Add /alerts/list/{name} which returns List<String> of all of the Alerts that have the same name of that which is provided.

Currently users can only list all of the Alerts. Add /sensors/list/{name} which returns List<String> of all of the Sensors that have the same name of that which is provided.

Investigate on how to calibrate the sensor / if there needs to be calibration.