timmerz416 / thermostat-controller Goto Github PK

Need to create a capability to store any data that was to be sent over the LAN to the database. This will probably initially multiple attempts to transmit the data to the database, and if that continues to fail, store one the Raspberry Pi.

Longer term, need a capability to later upload the data once a connection is re-established.

Code currently uses logger, but output is to stdout. This is ok for now, but before putting the code out for release, want to build a capability to log to sequential log files on the Raspberry Pi.

Develop capability on the 4D Systems display to show the current rules and update them.

Create a queuing class that takes care of http transmissions and internally stores incomplete transmissions and deploys them to the main DB when it is available.

Currently, any communications issues (unresponsive sockets being a main concern) are not handled properly and is a critical error that crashes the thread. This needs to be handled for long-term reliability of the thermostat.

Create documentation identifying the full suite of testing to be applied to the thermostat to check for functionality. Need to think if this will include code tests as well.

This will involve either tying into the XBee messages and know which XBee address to use for this temperature, or reading the data from the database.

Develop capability to update the thermostat rules over the LAN, similar to currently developed for the Netduino version of the thermostat.

Develop capability to store changes in rules in the thermostat programming in the database. This would be useful for analysis to understand the programming logic in place at any given time.

Create a simple document with the language used to communicate with the thermostat controller over the LAN.

Create an indication on the display that the software is not running. Perhaps printing '--.-' for the current temperature, or a LED?

Need to develop code to manage an exception creating or managing the listening socket. This does not need to be a critical error, but it should notify the user and shut down the thread.

Need to look closer at this to protect against conflicts.

Need to think about materials, and then construct the box.

When in override mode, any changes to the temperature setpoint on the display are not updated for the control setpoint. Need to correct this so that a setpoint change is handled by the controller. This is not an issue for setpoint changes over the LAN.

Create a file and mechanism for initializing the thermostat user parameters. Expecting such things as:

• initial rules
• xbee radio names for sensor knowledge
• temperature limits (?)

Need to project from display inputs that can switch directly to override mode when the thermostat power is off.

Development of code to update the weather icon based on current weather. This is likely a tie into the CYKZ or CYTZ METAR and decode into a weather icon.

Current coding is not optimized for handling messages. Need to change messages so they are sent directly between modules and no back to the queue to sort out which module to send message to.