mattdy/alarmpi

The Raspberry Pi Smart Alarm Clock

alarmpi's Issues

Minimum alarm time after event

It would be nice to have the option to specify a "minimum time" after an event finishes before another automatic alarm will be set.

For instance - if the "default wakeup time" is set to 0900, but we have an event finishing at 0700 (yay night shifts), then the automatic alarm will be set for 0900, whereas it would be nicer to set the alarm for a configurable "minimum time" after the event finished, or even just skip the day entirely.

Make timezone a configurable setting

There are several instances where Europe/London is hard-coded as the timezone to use in configuring alarms etc. It would be nicer to make this configurable in some manner, most likely through Settings.

However - the implications of putting an invalid timezone in here (ie: one not on this list) could be quite severe, so some kind of validation may be required before falling back to a sensible default?

Loading manual_alarm at startup sets an offset-naive nextAlarm

The loading of a manual_alarm setting in alarmpi.py (on startup) does not take into account timezones, and passes a offset-naive datetime object into AlarmControl.manualSetAlarm(), which then causes issues:

[2015-09-14 14:11:13,500]    ERROR       LcdThread: Error in LcdThread loop
Traceback (most recent call last):
  File "/root/alarmpi/LcdThread.py", line 121, in run
    message+=self.alarmThread.getMenuLine()
  File "/root/alarmpi/AlarmThread.py", line 216, in getMenuLine
    diff = self.nextAlarm - now
TypeError: can't subtract offset-naive and offset-aware datetimes

It should be possible to put the current timezone into the object by using datetime.fromtimestamp, which would fix this issue.

Back-off weather updates

Currently, if the OpenWeatherMap API is unavailable for any reason, then we end up making a request multiple times a second, once the Weather cache has expired it will continue to attempt refresh every time Weather.getWeather() is called.

It would be more sensible for a failed attempt to OWM results in the current cache being extended by a period of time (probably easier to make this fixed at 60s or so, rather than exponentially backing off), thus preventing spamming requests.

OpenWeatherMap requests now require APPID

As of November, OpenWeatherMap require a free account in order to use their APIs, as such all requests now require an APPID parameter to be included, or they will fail.

The request to OpenWeatherMap in Weather.py should be updated to allow inclusion of an APPID parameter, which could either be configured dynamically through Settings, or by inclusion in CalendarCredentials or similar static configuration.