FHEM – Temperature Sensors in multiple locations

One of the things that I want to use FHEM for is monitoring the temperature and humidity on a variety of locations (different rooms, patio, etc.)

I am using a set of TX 35 DHT sensors, the connection to FHEM is implemented using a JeeLink v3c USB device. I will describe that in a different post, also how you would pair the sensors with FHEM – for now, let’s just pretend that was done.

I use to define my FHEM Objects “manually” in the fhem.cfg file – so here is the definition for the TX 35 DHT on the patio.

As you can see, the sensor itself is a LaCrosse sensor, connected to my JeeLink device (called myJeeLink). The sensor is called pt.Temp – the prefix pt standing for patio. If you do not only want to display the current values but also would like to gather historic data (e.g. for graphs), you will have to log the readings somehow.

The easiest way is shown above – using a FileLog device. However, if you work with multiple sensors and record the data over a long time (which is the intention) than working with filelogs is not really the brightest thing to do: they are slow and they will use up your diskspace…quickly!

So let’s try and get this right stright away: instead of logging to a file, let’s log to a database. Sounds complicated? Maybe – let’s find out.

Connecting FHEM to a PostGreSQL Database

The connection requires two steps – the first one is to update the db.conf file to match your database definitions. A sample file for each database supported can be found in the /opt/fhem/contrib/dblog directory of the FHEM installation. For PostGreSQL, the following is needed:

%dbconfig= (
        connection => "Pg:database=fhem;host=localhost",
        user => "fhemuser",
        password => "fhempassword"
);

And of course, you will have to update this with our own database name, host, user, and password information!

And there is a really important thing to do – probably only if your PostgreSQL Server is on a remote machine but hey, it would not hurt either way: you need to install an additional Perl library:

sudo apt-get install libdbd-pg-perl

Otherwise, you will have your system continously “waiting for connection”…

Now, once you have the db.conf file set up and restarted your FHEM Server (shutdown restart) and you have created the database schema in the logging database accordingly (see /contrib/dblog/db_create*.sql scripts in the FHEM home directory!) you can create a global logging device:

define logdb DbLog ./db.conf .*:.*

This defined a Device logdb of type DbLog with the configuration file db.conf in the FHEM home directory and it logs… everything.

Mind the state property: it needs to say connected… using any sort of database maintenance tool, you should not be able to monitor data flowing in:

Now that we have connected the PostgreSQL Database sucessfully, it is time to return to the creation of the individual sensors.

Pairing new Tx 35 DHT Sensors

The TX 35 DHT sensor is actually a LaCrosse Sensor. Pairing – at least as far as I know so far – can only be done in one way:

1. Remove the batteries from the TX 35 DHT if there are any installed.
2. Go to FHEM and select the JeeLink Device (from the Everything tab)
3. It has a set command for LaCrossePairForSec – enter 60 for 60 seconds and click the set button.
4. Insert the batteries into the TX 35 DHT and wait for the temperature to show again…

Once you refresh the FHEM Interface, you will see a LaCrosse tab on the left. Select the Sensor and note the DEF value – that’s your Device ID!

If you want to edit your fhem.conf file manually (like I do), this is the ID to work with for that particular sensor!

I am actually repeating this for a total of seven sensors – one of them, the one on the patio, is an older model that does not do humidity. But the TX 35 DHT are marked as indoor use so I will keep the outside one for the moment.

So above is the list of all sensors in FHEM with their respective readings… and they are busily dumping their values into the PostgreSQL Database 🙂 – so far, so good.

For now, one last thing remains to be done: the constant logging of each and every value reported (as an event) quickly fills the database with garbage. I am only interested in those events that indicate a change to the previous status. And luckily, FHEM supports this out-of-the-box: by setting the object’s event-on-change-reading attribute to .* we will only see those value changes come up.. the “clutter” in the Event Monitor dies down dramatically… and that’s it for the moment, let’s gather some data in the logs.