Group 3

• Hanting Zhang
• Omar Mater
• Shaghayegh Royaee
• Bartosz Rzepkowski

• Thermostat+Control FHT80B-3+FHT8V-3
• FS20 PIRI-HR Mouvement Sensor
• FS20 TFK Window Sensor
• RPI B, FHEM Server

Firstly, the first schedule is defined by the user. The prior can define when he needs the temperature to be warm or chillier (at home, or sleeping) and when heating is unnecessary (at work or away from town). An example: At night, turn temperature down. During the day, if away from home, turn heater off. Else, turn heater up. This schedule will be time adjustable by the user using either the thermostat or the web/mobile app. Also, this schedule can change depending on the day of the week.

Then, in our scenario, 2 events are susceptible to modify or override the schedule. A sensor for detecting opening doors and windows sends a signal to indicate that the heating should be turned off if doors and windows are opened for too long. A movement sensor is also used to detect if there is anyone in the house. If there is no movement detected in at least 48h hours, the heater should be turned off.

Moreover, our application will display Energy usage statistics and comparative Energy saving with a manual handling of the heater. We could also imagine a comparative graph for each week or month, showing the evolution of the Energy consumption.

Lastly, though we will not implement it during the code camp intensive week, our system could detect the proximity of the user and turn the heat up if the user is approaching in a certain radius.

At first, it might be a good idea to set the auto-create function to enabled. This function lets the FHEM server to define a device every time it encounters a new one on its logs. That way, it is possible to detect and manipulate any FS20 device in the reach of the transceiver.

To define manually a device, we need its code. By default, the fhem server logs every signal it gets. Then the house code of the device can be find using the timestamps of the logs.

It is thus possible to define the device by command line or in the fhem.cfg file as follows:

define thermo_Group3 FHT 5012
# Defines a device for the FHEM server
# The attributes are the type of device and its house code defined in the factory settings
# Or by the user
attr thermo_Group3 model fht80b
# This line defines the specific type of device model, here a thermostat FHT80B
attr thermo_Group3 room FHT
# This line defines a logical “room” for the device
# Rooms can make it easier to regroup devices in a system
define FileLog_thermo_Group3 FileLog ./log/thermo_Group3-%Y.log thermo_Group3
# Defines a log file and its path on the server
attr FileLog_thermo_Group3 logtype fht:Temp/Act,text
# Defines the type of the file log: text or just values of Temperature and Actuator
define weblink_thermo_Group3 weblink fileplot FileLog_thermo_Group3:fht:CURRENT
# Defines a file for the plot
attr weblink_thermo_Group3 label "thermo_Group3 Min $data{min1}, Max $data{max1}, Last $data{currval1}"
# Determines the values needed for the plot tracing

3 devices registered and paired with our transceiver:

• thermo_Group3: our FHT80b thermostat
• PIRI_Group3: our PIRI2 motion detector
• TFKCHA1_Group3: our opening window sensor

Using FHEM, it is possible to link devices via events. For example, every time a window is opened, the temperature of thermostat should go down. Using the “notify” command, it is possible to set conditions and causalities. Let’s look back at our example: Every time the server sees the state of the TFKCHA1_Group3 switching to ON, this means that the window is opened. Then, the desired temperature (variable desired-temp on FHEM) should go down to 18°C. For this, it is possible via the fhem command line to set a notify function as follows:

define mvtNotify notify PIRI_Group3:on.* set thermo_Group3 desired-temp 18

For our calculations, we need a reference appartement: 30 meters square, 2.5 meter in height, normally isolated. Also, the outside temperature is around 10 Degrees Celsius

As a reference for comparison, heating constantly this appartement at 20 degrees takes 1100 Wh. For 16 degrees, it takes 700 Wh.

Here is our sample scheduled for the user:

• From 6-8: temp at 20
• From 8-16: heater off
• From 16-23: temp at 20
• From 23-6: temp at 16

So the total arrives at: 1100*(2+7)+700*7=15kWh 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
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.

As an interface between the FHEM system and the user, we developed a Java based application retrieving essential values (temperature, status of sensors) from our system and also able to set those values through FHEM. 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. In our prototype, the GUI is composed of 2 tabs.
The “Basic” tab, where informations about the system is shown and where the user can set the temperature of the thermostat:

The “Scheduled” tab, where the user can define night/day cycles for the temperature of the appartment:

Our JAVA code retrieves information directly from the html web page of the FHEM server. 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 example method (which sets the desired temperature on thermostat) that shows the idea in which our application sets and retrieves information:

public void setTemperature(double temperature) throws Exception {
		
	    @SuppressWarnings("resource")
		WebClient webClient = new WebClient(BrowserVersion.FIREFOX_38);
	    // Get the page
	    HtmlPage page = webClient.getPage("http://157.24.191.6:8083/fhem?detail=thermo_Group3");
	    HtmlSelect select = page.getElementByName("arg.setthermo_Group3");
	    List<HtmlOption> options = select.getOptions();
	    select.setSelectedAttribute(options.get(2), true);
	    
	    HtmlSelect temperatureSelect = page.getElementByName("val.setthermo_Group3");
	    temperatureSelect.setSelectedAttribute(Double.toString(temperature), true);
	    
	    HtmlSubmitInput button = page.getElementByName("cmd.setthermo_Group3");
	    button.click();
	}

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.

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.
However, it would be feasible to consider an external scheduling system, developed independently, where the user could define more than 2 configurations per day, and even schedule the heating system for custom time ranges (weeks, months etc.).
Though our prototype limits itself to the use of 3 sensors, we did consider a proximity sensing system that would detect the user within a certain radius and possibly override the schedule. For example, when at work, the schedule is configured to turn the heat off. However, if the user returns back home, the proximity system would detect the user within a certain distance and override the configuration to turn the heat on.
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).

• Invented in 1975 by Pico Electronics in Glenrothes, Scotland, the 10th project of the company.
• Powerline based signal transmission over 60Hz system, at each zero-crossing via 120kHz carrier, data rate is around 20bits/s, making it difficult to transmit more complex commands.
• 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, almost non usable due in EU because of electrical regulations
• Example: The protocol may transmit a message that says “select code A3”, followed by “turn on”, which commands unit “A3” to turn on its device.

* Conclusion:

• Popular technology for simple basic use, few potential for future development

github link (Source Code + fhem.cfg): https://github.com/gothic17/CodeCamp

• Unordered List ItemProject Presentation: group3_presentation.pdf
• Unordered List ItemProject Poster: poster.pdf
• Unordered List ItemProject Report: lut_codecamp_theinternationals.pdf

• FHT80B thermostat: http://www.produktinfo.conrad.com/datenblaetter/550000-574999/557894-an-01-en-FUNK_HEIZTHERMOSTAT_FHT80B_3.pdf
• FS20 TFK window detector: http://www.produktinfo.conrad.com/datenblaetter/600000-624999/620346-an-01-en-FUNK_TUER_FENSTER_KONTAKT_FS20_TFK.pdf
• FS20 PIRI motion sensor: http://www.produktinfo.conrad.com/datenblaetter/600000-624999/620594-an-01-en-FS_20_PIRI_2.pdf
• FHEM documentation: http://fhem.de/fhem.html