meta data for this page
Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
sustcodecamp2016:group4:start [2016/03/04 14:46] omater [Java Application] |
sustcodecamp2016:group4:start [2016/03/11 15:19] omater |
||
---|---|---|---|
Line 91: | Line 91: | ||
For our reference scenario where heat is constantly kept at 20 Degrees Celsius: | For our reference scenario where heat is constantly kept at 20 Degrees Celsius: | ||
If the user remembers to turn off the heat during work hours (8-16), when the user is outside, at 20 degrees the total amounts to: 1100*16=18kWh | If the user remembers to turn off the heat during work hours (8-16), when the user is outside, at 20 degrees the total amounts to: 1100*16=18kWh | ||
+ | \\ | ||
+ | At a reference cost of 30 cents/ kWh, the savings with an automated system like ours is 90 cents/day, which represents roughly 30 euros / month. | ||
====Java Application==== | ====Java Application==== | ||
As an interface between the FHEM system and the user, we developed a Java based application retrieving essential values (temperature, | As an interface between the FHEM system and the user, we developed a Java based application retrieving essential values (temperature, | ||
The Dataflow of our domotic system can be interpreted as shown below: | The Dataflow of our domotic system can be interpreted as shown below: | ||
\\ | \\ | ||
- | {{: | + | {{: |
\\ | \\ | ||
We developed the Java Application to act as a GUI to retrieve information on the system and to act and set parameters. | We developed the Java Application to act as a GUI to retrieve information on the system and to act and set parameters. | ||
Line 111: | Line 113: | ||
We made the choice of retrieving from the html page rather than from a telnet session and the perl api of the fhem server simply because we were not really familiar with the entire API behind the FHEM server and the WEBFHEM was the tool that we understood most. | We made the choice of retrieving from the html page rather than from a telnet session and the perl api of the fhem server simply because we were not really familiar with the entire API behind the FHEM server and the WEBFHEM was the tool that we understood most. | ||
\\ | \\ | ||
- | Here is the code to set the temperature | + | Here is the example method (which sets the desired |
\\ | \\ | ||
< | < | ||
Line 131: | Line 133: | ||
} | } | ||
</ | </ | ||
- | ====Limitations and Future | + | \\ |
+ | Among many classes used by our application we use three, that reflect real devices. Those classes implement the following methods: | ||
+ | < | ||
+ | Thermostat | ||
+ | |_getDesiredTemperature() | ||
+ | |_setTemperature(double Temperature) | ||
+ | |_setScheduleTime(String dayTime, String time) | ||
+ | |_getMeasuredTemperatures() | ||
+ | |_getCurrentTemperature() | ||
+ | MovementDetector | ||
+ | |_checkIfThereWasMovement() | ||
+ | WindowDetector | ||
+ | |_checkIfWindowIsOpened() | ||
+ | </ | ||
+ | \\ | ||
+ | Class implementing our GUI creates new thread for movement detector and also for window detector. It checks the value returned by methods from suitable classes every given period of time. | ||
+ | |||
+ | |||
+ | ====Limitations and Future | ||
With the amount of time we had to work with the tools that were given, we decided to stick with the integrated schedule system of the fht80b thermostat. | With the amount of time we had to work with the tools that were given, we decided to stick with the integrated schedule system of the fht80b thermostat. | ||
\\ | \\ | ||
Line 140: | Line 160: | ||
This could be done using the GPS system from the user's smartphone for example. | This could be done using the GPS system from the user's smartphone for example. | ||
\\ | \\ | ||
+ | Our system could also propose some changes of the schedule, based on the registered behaviors of the user, that differ from current schedule (for example lack of movement in apartment during the period, in which it should be heated). | ||
====Protocol to present==== | ====Protocol to present==== | ||
=== X10 === | === X10 === | ||
+ | |||
* Invented in 1975 by Pico Electronics in Glenrothes, Scotland, the 10th project of the company. | * Invented in 1975 by Pico Electronics in Glenrothes, Scotland, the 10th project of the company. | ||
- | * Powerline based signal transmission | + | * Powerline based signal transmission |
- | * 4 bits-house code+4 bits unit code+4 bits command code | + | * signals are composed by 4 bits-house code+4 bits unit code+4 bits command code, allowing it to support up to 256 devices in one independent system, commands are sent through the entire network in one direction, it's up to each device to respond to a certain code. |
- | * The wireless protocol operates at 310 MHz in the U.S. and 433.92 MHz in Europe | + | * The wireless protocol operates at 310 MHz in the U.S. and 433.92 MHz in Europe, almost non usable due in EU because of electrical regulations |
+ | * Example: The protocol may transmit a message that says " | ||
\\ | \\ | ||
^ Advantages ^ Limitations ^ | ^ Advantages ^ Limitations ^ | ||
Line 152: | Line 175: | ||
| Time-proven | Limited functionality | | | Time-proven | Limited functionality | | ||
| Wide range of product | Lack of encryption | | | Wide range of product | Lack of encryption | | ||
- | | Losing of commands | Interference | + | | Losing of commands | Sensitive to attenuation, |
+ | * Conclusion: | ||
+ | * Popular technology for simple basic use, few potential for future development | ||
====Package==== | ====Package==== | ||
- | githublinke: https:// | + | github link (Source Code + fhem.cfg): https:// |
====Documentation==== | ====Documentation==== | ||
* Unordered List ItemProject Presentation: | * Unordered List ItemProject Presentation: | ||
- | * Unordered List ItemProject Poster: | + | * Unordered List ItemProject Poster: |
- | * Unordered List ItemProject Report: | + | * Unordered List ItemProject Report: |
====Refrences==== | ====Refrences==== |