Story of a fhem & HomeMatic CCU installation

[rudolfkoenig]

                                                   

I received an interesting story of an unusual installation. I am not
excited about tearing it apart and pasting it into different HOWTOs,
but it contains a lot of information, so it would be a pity to waste
it. Any ideas on how to "conservate" the info would be welcome, if
somebody does the "conservation", than it is even better.

========================

This is to document how I came about to have a FHEM-HomeMatic setup
and to write down some details, which are maybe not that common.

The beginning was the old question what system to choose. In my case
there is a classical installation but KNX-Wiring has been put into
place everywhere just in case. There is structured Ethernet cabling in
almost every room, one port for ISDN-lines and one for LAN per room
(some empty spare tubes are present, but not currently cabled).

After running through discussion groups and documents the evident was
yet more evident: home installation and automation is just a big mess.
So many standards, incompatible from protcol up to physical dimension
of the switches.

KNX? Zigbee? Z-Wave? FS20? HM? Meshed networks or star topologies?
Encryption or not? Not to speak about LON, LCN and DALI... or music
streaming.

While we lived happily for some time at some point I felt the need to
act.  It all started with the copies of my kids' CDs lying around
everywhere.  After some discussion I decided to put a NAS (synology
410j) into the basement and to put the CDs there. Of course I jumped
on the occasion and also put photos there along with the home
directories of the computers in the house (one for my wife, one for
the kids and a note-book).

The NAS (linux-based) seemed like a good starting point for further
activities. While login and home directories still await LDAP
integration, we can now listen to music and radio stations through a
Philips NP2900 streaming device. And the kids can watch the photos of
the donkey trail at the same time, they like it.

As every year St. Martin came along and with it the usual load of
lanterns (candles) and lights (electric).  After some complains from
my kids when I had forgotten to switch on, from my wife when I had
forgotten to switch off the lights, I decided it was time to act.

After some thinking I decided on a combination of FHEM and HomeMatic.
The reason was that I did not want to invest a lot of money into an
area where nobody knows how it will all end up. I wanted nice figures
(FHEM), but new technology (MH with encrypted protocol). And the
option to use the wires present some day (MH).  Would FHEM have had a
full HM support, I would not have bought a CCU, but alas I had to.

The general setup is as follows:
- FHEM runs on the 410j in the basement (gathers data and makes nice
  plots, which tell me using 8 super cheap S300 sensors, where the
  heat goes in the house)
- A CUN device is connected to the ethernet in another part of the
  basement
- A CCU is on the first floor (taking care of the HM actors and
  sensors)
- A CUL is connected to the CCU, receiving FS20 data via CUxD (I
  wanted to be able to react on the data, not only look at them)
- The CUL is configured as a repeater for the CUN, thus sending all
  data from the higher regions of the house into the basement

* FHEM installation

The first step was FHEM installation. Evidently I did not want to run
a separate computer (which is why I did not choose IP-Symcon), so FHEM
should run on the NAS.  Of course there is no package for it and the
page in the Wiki just states that information will come really soon
now (TM).

While I am not aspiring to write something detailed and good enough
for a wiki, I want to line out how I did the installation. First step
was to prepare the NAS for package installation.  There is a huge
amount of pages out there, talking about every imaginable problem, but
for me it was quite easy.  I just followed the section "Installing
compiled/binary programs using ipkg" in the Wiki:
http://forum.synology.com/wiki/index.php/Overview_on_modifying_the_Synology_Server%2C_bootstrap%2C_ipkg_etc#What_can_I_do_by_Modifying_a_Synology_Server

there is also a German one, section "Installation" (I did not do what
was proposed in the rest of the document, still works for me) in:
http://www.synology-wiki.de/index.php/IPKG

Then installing the essential like screen, tcsh and by the way apache
and ldap.  At that time I still thought that I would need an apache
for FHEM.  I tried to install below /usr/syno/synoman/ but when I
upgraded the base system of the 410j everything had dissapeared (no
wonder).  It was then when I also understood that at least the default
UI of FHEM brings its own web-server and thus installed it under /opt/

If you are really into this and maybe want to package a FHEM package
for synology (hint, hint), there is an official "Synology NAS Server
3rd-Party Apps Integration Guide" from the synology folks at:

http://forum.synology.com/wiki/index.php/Synology_NAS_Server_3rd-Party_Application_Integration
and
http://download.synology.com/download/ds/userguide/Synology%20NAS%20Server%203rd-Party%20Apps%20Integration%20Guide.pdf

If you stumble on the "mount bind" concept, you could look here
(German):

        http://www.synology-wiki.de/index.php/Mount_Bind

The installation was then pretty straightforward. Download FHEM from:

        http://www.koeniglich.de/fhem/fhem.html#Download

Then start to read the HOWTO:

        http://www.koeniglich.de/fhem/HOWTO.html

If you read about serial ports and try to do something like:

         ipkg install perl-device-serialport

be prepared that ipgk tries to install all the perl anew.

I interrupted the installation then and understood that for FHEM you
only need:
  - perl (which is already on the synology)
  - CUL (USB!): perl Device:SerialPort, Kernel Module cdc_acm.ko or
                fallback usbserial.ko
  - CUN (Ethernet) does not require this module

Trust me and forget anything else what you may read on the net, for a
minimal FHEM install you don't need databases, Perl:LWP or others. I
have this from Rudolf in person, so it must be true

So if you have a CUN(O) device like I had, don't get confused, unpack
FHEM and adapt the Makefile. Mine looks like:

DiskStation:pts/3:/opt/fhem-5.0.source# diff Makefile*
1,13c1,6
< BINDIR=/opt/fhem/bin
< MODDIR=/opt/fhem/share
< VARDIR=/opt/fhem/var/log
< DOCDIR=/opt/fhem/share/doc
< MANDIR=/opt/fhem/share/man/man1
< ETCDIR=/opt/fhem/etc
<
< #BINDIR=/usr/bin
< #MODDIR=/usr/share/fhem
< #VARDIR=/var/log/fhem
< #DOCDIR=/usr/share/doc/fhem
< #MANDIR=/usr/share/man/man1
< #ETCDIR=/etc
---
> BINDIR=/usr/bin
> MODDIR=/usr/share/fhem
> VARDIR=/var/log/fhem
> DOCDIR=/usr/share/doc/fhem
> MANDIR=/usr/share/man/man1
> ETCDIR=/etc

As recommended in the HOWTO just compile and start (using my paths):

        make install-pgm2
        perl /opt/fhem/bin/fhem.pl /opt/fhem/etc/fhem.cfg

Stopping might come in handy:

        perl /opt/fhem/bin/fhem.pl 7072 shutdown

If you want to talk to fhem on a more technical base, just do a (and
type help to see, what can be done there):

        telnet localhost 7072

I only ever used the "inform timer" command and some strange get/set
commands to access the CUL/N device without connecting directly to it.
Here it should be said that you can address the CUN also via telnet
(it gets an IP-adress via DHCP), but if you do so, FHEM can't talk to
it anymore.  So you better logoff before starting FHEM (well you need
to define the device first anyway .

On a higher level FHEM should be alive too, just get a browser an
type

        http://diskstation:8083/fhem/

and you will see the PGM2 interface. I have experimented with other
interfaces a bit and they look less barbones, but you need webservers
for them and so I stuck with PGM2 for the time being.

I also did no automatic startup or any other fancy integration
stuff. I don't reboot my 410j normally and if I do, I can start fhem
by hand no problem.

* Configuring FHEM

If you read very carefully and have enough imagination you might be
able to configure FHEM just by reading the documentation.  I have
neither and a CUN, which is not really described in much detail, so I
got lost right from the start.

What you should know is that FHEM has a autocreate module, which
configures all the sensors it recognizes automatically. It is enabled
by default and e.g. for a TH sensor, it will do all of the following
for you (so you do *not* need to type all this, but you can find it in
the etc/fhem.cfg file, if you are interested):

        define CUL_WS_1 CUL_WS 1 0.3 -0.2
        attr CUL_WS_1 room CUL_WS

        define FileLog_CUL_WS_1 FileLog .../var/log/CUL_WS_1_%Y.log
CUL_WS_1
        attr FileLog_CUL_WS_1 logtype hms:Temp/Hum,text
        attr FileLog_CUL_WS_1 room CUL_WS

One word of warning though: should you make the definitions yourself
or do a rename later, *never* *ever* use a dash ('-') in the name.
You will run into unlimited trouble at the strangest places, if you do
so.  This is related to the fact that FHEM is intelligent and
interprets dashes as ranges

What FHEM can not do for you is to define the receiver module itself.
You need to enter it yourself.  To this effect on the FHEM page there
is a text widget on the top of the page.  You can enter any FHEM
command there (or via the telnet). For a CUN device this sould be
something like:

        define CUL1 CUL 192.168.1.203:2323 0000

You can choose freely the name (here CUN1) and the IP.  The CUL must
stay as is (even for CUN(O) devices), the port also.  Be careful
though, since the IP is either allocated via DHCP (and you need to
find out what it is via nmap, Fritz-Box or other) or set by you (but
of course for this you need a PC with some terminal program (screen
comes to mind)) it is of course not a free choice.

Once you have done this and having a sensor (like S300TH) around, FHEM
should start to receive data.

Now ATTENTION! All this is very well, but if you don't save your work,
FHEM will forget about everything you told it (even if I hear that the
autocreate module does saves too...).  So you better *save* your work
by typing "save" into the text widget.

If you want to know more read (in this order)

        http://www.koeniglich.de/fhem/HOWTO.html
        http://www.koeniglich.de/fhem/commandref.html
        http://groups.google.com/group/fhem-users


* Setting up HomeMatic

On the HomeMatic side first steps are pretty straightforward.  Unpack
the CCU, connect switches or dimmers and learn them as described in
the manual.

Switchin on/off St. MArtins lights is also ok, blinds a bit more
complicated (68-855-57), if you want to trigger intermediate states
like 50% closed.  I have not succeeded to do this, neither how to dim
lights on the remote.  But time will come


* Integrating FH20 into HM
Since I had another CUL device, I put it into the CCU (that's where
things get complicated) to read the FS20 data and use it in HM.  There
is a CUxD software out there, which is easy to install (CCU has a
package installation mode) and works well for me.

So the CUL reads FS20 signals, hands them to CUxD and CUxD makes them
available for HM as if it were native HM devices (or nearly).  Works
nicely, the devices show up along the native HM ones.  Now I can act
on the FS20 data in HM.

Soon I will have more native HM devices an can only hope that Rudolf
has nothing better to do on those long winter evenings than to extend
FHEM

One first insight seems to be that the dimmers can not be addressed
with a lot a configuration variables in one call.  The variables seem
to program the hardware button on the dimmer device and need to be set
separately from the dimming action itself.  Which means that if you
use the hardware button you get the configuration wich was loaded
there the last time.  The number of variables that can be set on a
trivial thing like a dimmer is BTW amazing...


* Using a RPR device

Since I am reading signals with the CCU on the first floor, but have
the CUN in the basement, it seemd logical to use the CUL device
connected to the CCU not also as a package gatherer for the CCU, but
also als a relay (RFR) for the CUN device addressed by FHEM. This
actually works and is not very complicated. I'll explain...

As you have imagined, all this is contained (look for CUL_RFR) in:

        http://www.koeniglich.de/fhem/commandref.html#CUL_RFR

In a nutshell what you need to do is to configure one device as a
receiver, the other one as a relay.  For the CUN that would be ID 01
and no relay (00):

        set MyCUL raw ui0100

MyCUL should be the name your device has, in my case CUL1.  The name
is just for device selection (there might be several on the network).

On the CUL you need to use another ID (02) and tell it to send
everything to ID 01. Just type:

        set MyCUL raw ui0201

Again, MyCUL should be the name your device has, if you are connected
serially it does not matter at all (since you are already talking to
the correct device).

Et voilà, autocreate will create the rest for you and you will see
lines appearing like:

        CUL1: 0207UK0186016113;
        CUL_RFR_07: K01860161 -64.5

Of course you can use the telnet interface of CUN and the CUxD
terminal window to issue the "ui" commands directly if you wish.  Be
aware though that parallel logins are not possible with culfw
currently, so you need to stop FHEM first.

If you get messages like the following:

        CUL1: 0207UK01861160;
        CUL_RFR_07: K018611 -26
        CUL_WS Cannot decode K018611

issue the "X21" command on the RFR device. CUxD initializes with "X01"
(which does not add the RSSI-byte) but is able to understand the "X21"
output format too. Just use it and it will work

Hope all this is of help to someone...
===================

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.