pojd / hawa Goto Github PK

Currently we only fetch last week and then locally change what is displayed - array is passed on to calendar, so change this to allow calendar invoking REST directly, i.e. have a new rest API for the calendar events only

Log events to new database table and then view it in the view (new view security)

So if for any reason one of the outdoor sensors fails reading, the respective value is not stored into DB and the result graph data series lengths (pressure, temperature, humidity) have different lengths and nvd3 then fails to render the graph.

Fix this, so that the history is always there - maybe still log a warning about sensor, but try taking the previous reading instead of avoiding save. Issue is if e.g. a sensor fails completely from the startup (e.g. humidity sensor). Then nothing will be stored at al for that sensor. Maybe this could be somehow caught on startup too? E.g. take last valid value? Or throw an error straight away?

SImilar issue will also occur if tomcat is bounced in the middle of refresher doing its work. SOme readings then won't be saved either.

Or maybe split out the graphs to 3 separated graphs since the values do not really scale anyway...?

Each room now has light motion sensors (optional), light switch and light control, all should be displayed in the view to see its status and be able to manipulate all from GUI

Currently I can only run the app freely on RPi given all the dependencies. Change this so that I can continue working locally too, just getting false or random date and not being forced to hack the code to be able to do so. While still being able to easily deploy to tomcat using mvn tomcat7:redeploy

• Display all rules now, allow them to be enabled/disabled
• Allow the security mode to be switched from the web

Based on the logged data from outdoor, attempt some simple weather forecast (use humidity and evolution of pressure probably)
Show current state and show some sort of evolution?

• start up local webapp from maven or at least par of it
• simulate raising events from GPIO - potentially using mock
• verify the net result (e.g. security, etc)

• Each room can have a list of window reed switches
• Hookup changes to security system - either open should raise security event

So from detail to entity (rooms and outdoor) it works fine, but not vice versa.

• raised to test MCP23017 real hookup to Raspberry Pi and perform any changes in the project that would be needed

• should it be hardcoded or somehow maybe in time configurable through web?
• should be at least somehow visible now in web, if not configurable

Room detail view should list all last readings
And graph of the room temperature, by default all data from last day, customizable in UI, be able to move the range, etc

• A new DAOCleanup service should be created that should purge all data at regular intervals (e.g. say run evey 24 hours)

• somehow think over the FTPlet or maybe hookup later. Ideally avoid a stupid timeout to wait a bit longer after ftplet was launched

portlets:

• dmesg
• system properties
• uptime
• file systems, etc
• switch off raspberry pi - run "shutdown -h now" - or better add console - send system commands and paste their outputs back to console...
• enhance system state service - get all the above data, but ideally zipped since the log could be MBs big....

Being able to send out emails from the application and hooking that app to the security system

Right now only one sensor uses I2C, but that will change soon once the expander chips arrive. Then I will need to connect the relays through them and they will need some I2C setup code too. So refactor the current sensor generic code out (similar as Gpio) and control from one place only (including closing on spring context closing).

Use this new base logic to manipulate the expander chips and be able to control or read stuff through them

Probably play an audio through audio of raspberry if a security event is detected, could be more types of audio. Maybe play only if we are inside the house? Or better always?

configurable, to be able to call on a predefined number (email)

Debug and try to find the root cause. Either way probably introduce some sensible filter in DAO - do not save values that are too off

The user should be able to change the default view from past 1 week to any sub range of that. The graph should re-render itself then

Currently they effectively read the temperature twice on start-up since both the constructor and refresher do so. This slows down start-up.

Error about unable to connect to 0x29 - TSL light sensor in hall, fix that so that these errors are not there untill all is wired up together

Live view page to see the actual state at home/around the house from the camera

Currently these fail with Unsatisfied link errors and tomcat has to be bounced, which slows development a lot down

Every 5 mins a scheduler should trigger some logic to read the actual sensor values and store into DB
Then anytime web invokes getAll, it would get the last state
All transparent via DAO
Tests added to cover this functionality

• New LDR connected, translate its readings through SPI and connect this one up to the rooms and outdoor as opposed to the existing digital lux sensor (that one uses I2C, so we will not be able to route that through long wires in the house)

• new maven project to wrap up security
• should use motion sensors, ftp server for camera uploads, email, potentially gtalk? Maybe google calendar too?

Create room service API, rest service, hook up into the main view and maybe some mock service to get some data to show

Make it optional, but both outdoor and halls should now depend on a light sensor - only if it gives little light (configurable), then trigger the light, otherwise ignore

The idea is that motion sensor should only control lights in a room or outdoor when the light switch itself is off.

• links in portlets about system should lead to system state
• the runtime logger should not see thread name and class name

Follow BRD and implement all those rules