FHEM meets EIB

[Guest]

Originally posted by: <email address deleted>

hi everybody,

it is a great pleasure to present an integration of EIB/KNX in FHEM.

EIB is a standard bus for house/building automation. It is merely used
in hotels, hospitals etc.
But it is now about to become used in private houses as well.

EIB defines a set of transport media, but the common transport medium
is a twisted pair cable. (for more information use google )

Since last week two new FHEM module have been committed to the CVS
repository:
- TUL
- EIB

The TUL module is used to define the transport device. The EIB
definitions will represent actuators (switches, lights, sensors,
etc..)
I will update the commandref.HTML right after my vacations end of
July.

The TUL module has been designed to work with EIBD server and TPUART
modems. Latter one will make FHEM users happy, who use a NAS or
FritzBox and do not want to have an own server for EIBD. So you could
just use the TUL stick from busware.de (see bus connection later).

So the definition of the io device will look like this:
EIBD:
define tul TUL eibd:[:] address>
example: define tul TUL eibd:localhost 1.1.249

TPUART:
define tul TUL tpuart:
example: define tul TUL tpuart:COM5 1.1.249

Now we need to define the actuators:
(in EIB actuators are controlled by sending commands on group
addresses)

define light1 EIB
attr light1 IODev tul
define light





**Bus-Connection**
Up to now EIB bus couplers for RS232, USB or even network are very
expensive.
Nowadays busware.de will soon offer an USB-Stick for connecting to EIB
on a reasonable price: http://busware.de/tiki-index.php?page=TUL

TUL is an open source hardware module providing a powerful atmega32u4
and a TPUART. The current firmware is a transparent TPUART modem
providing bus connection over TPUART. It can be used over EIBD Linux
server or directly by FHEM module.


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi sorry I was only nearby finished an clicked wrong button ;(

So the FHEM integration is now in early beta state and will need some
work. But it is already very stable running on Dirs Tostmann's house.

The great thing is that the integration in FHEM will allow to combine
all different kind of protocols and devices to achieve tremendous
results and successs.

So the WAF of the EIB could be increased by combining the EIB module
with FS20 and use a FS20 remote control to control your light,
jalousies etc.
On the other hand a lots of environment monitoring sensors
(temperature, wind speed, etc.) are cheaper and better to install on a
radio basis (ie. 868Mhz devices) and can easily be integrated in FHEM
and so be used to control the jalousie ....

I hope you will like the integration.
Comments welcome
cu
Maz
http://mazcity.de
Blog/Tech Knowhow: http://knowhow.amazers.net

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi Maz, I probably will.
Quick question: when using:
 

> define tul TUL eibd:[:]
>
 
just to make sure: the "EIBD" is the generic bcusdk-eibd, right? Or is it
some other kind of daemon just running on the TUL?
Anyhow, EIB integration is really great! (and now reduces my bad feelings
about having posted EIB related stuff in this forum

Thanks, Best Regards, Jens

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[tostmann]

                                                 

Maz has in fact written two interface handlers:

FHEM => eibd => (any supported BCU i.e. TUL) => bus
FHEM => TPUART (i.e. TUL) => bus

The reason is mainly to make "eibd" expendable as it might not run on smaller embedded systems. So you can connect to the bus directly via TUL, which is a serial TPUART over USB.

eibd is of course:
http://www.auto.tuwien.ac.at/~mkoegler/index.php/eibd

Am 07.07.2011 um 13:47 schrieb auto-mate:

> Hi Maz, I probably will.
> Quick question: when using:
>  
> define tul TUL eibd:[:]
>  
> just to make sure: the "EIBD" is the generic bcusdk-eibd, right? Or is it some other kind of daemon just running on the TUL?
> Anyhow, EIB integration is really great! (and now reduces my bad feelings about having posted EIB related stuff in this forum
>
> Thanks, Best Regards, Jens
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

> Quick question: when using:
>
> > define tul TUL eibd:[:]
>
> just to make sure: the "EIBD" is the generic bcusdk-eibd, right? Or is it
> some other kind of daemon just running on the TUL?

Hi Jens,
wie Tosti bereits schrieb, ist mit eibd/eibd-Server die Implementation
von TU-Wien gemeint. Das musste auch das von Dir angemerkte bcusdk-
eibd sein.

Der eibd muss mit dem -i Parameter gestartet werden. z.B.
 eibd -i -t 100 tpuarts:/dev/ttyACM0


Die Firmware von TUL is so ausgelegt, dass eibd darüber sich mit dem
EIB-Bus verbinden kann. Aber eibd unterstützt auch ganz viele andere
Netzkonnektoren (Z.B. LAN-Konnektor, etc.).
TUL ist preislich sehr attraktiv, da Alternativen erst beim doppelten
Und weit darüber anfangen. Auch wenn nur ein Bus-Sniffer / Bus-Monitor
benötigt wird, ist TUL sehr gut geeignet, da es out of the Box alle
Telegramme auf dem seriellen Anschluss ausgibt.

Es sind aber auch einige Leute hier unterwegs, die FHEM nur auf ein
NAS oder ein Fritzbox laufen lassen und kein Extra-Server für eibd
haben wollen (obwohl TuxRail von busware eine sehr attraktive
Möglichkeit wäre anstatt von NAS und FB). Für diesen Einsatzzweck habe
ich dann noch ein Modus in FHEM-Modul aufgenommen, damit der TUL
direkt an NAS/Fritzbox angeschlossen werden kann und aus FHEM direkt
angesprochen werden kann.

Wenn Du das Modul  in Betrieb hast, wäre ein Feedback sehr hilfreich.

VG
Maz

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[jorge]

                                         

@Maz

hatte mich ja schon geoutet, dass ich mich für Wire-Kompontenen an
FHEM@FritzBox7390 interessiere. Zwar ist das TUL ja schonwieder-ein-
neues Teil, aber ohne Hardware-Interfaces geht ja wohl nichts..

Only for confirmation:
- The TUL works on FB7390 2.0 USB Port and adressed directly from
FHEM@FB7390

Questions:
The TUL has to be flashed like CUL (it is shipped without Software!)?
The EIB ist directly connected to TUL and then interacts with attached
EIB sensors and actors?
Are there (by now) any protokoll restrictions to existent EIB
Installations?

Jörg (JWK)

P.S.: Thanks for the enlargement of homeautomation@FHEM. Any
proprietary restriction looses its burden at any time.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi Jörg,


On Jul 11, 4:56 pm, jwk wrote:

> Only for confirmation:
> - The TUL works on FB7390 2.0 USB Port and adressed directly from
> FHEM@FB7390

This is also my expectation and what we (Tosti and me) had in mind
when we started the efforts.
As CUL is running on FB without any issues, I expect that TUL will do
as well.



> Questions:
> The TUL has to be flashed like CUL (it is shipped without Software!)?

Yes. But the firmware's available here: http://busware.de/tiki-download_file.php?fileId=54
BTW: And TUL is "officially" supported by LUFA so the current firmware
is a standard LUFA compilation.


> The EIB ist directly connected to TUL and then interacts with attached
> EIB sensors and actors?

Yes. I suppose you have insights in EIB. So you can send group
commands (Telegrams) using FHEM.

> Are there (by now) any protokoll restrictions to existent EIB
> Installations?

Depends which "protocols" you refer to. EIB defines a lot of protocols
on different layers and to be offered by different devices....

With the current firmware and FHEM modules you can receive/ send any
EIB group telegrams (switching on, off, values from sensors). I have
in my test installation a series of switches and lamps and I can
switch them all on off... and I have also a presence sensor that in
intervals sends the current lightning value in lumen as a two digit
hex value. This value is also captured in FHEM and you could write
notifications to act on that values... so switch lights when it is too
dark... etc....

So there is no restriction regarding the EIB-Group communication
protocol. However there is for simplicity some fields of the telegram
filled with default values (ie. repetition count, severity etc.) But
it is expected that this settings are best suited for FHEM
integration.

After my vacations (so by mid August) I will create a video explaining
this by examples.

The next step for the firmware is to implement support for the FT1.2
protocol, so you can use ETS directly over TUL (Now you would need
eibd server... but ETS is only needed at initialization time of the
components to assign physical addresses and define group adresses,
that is in most installations done by the system integrator)

The FHEM-Module is of course in betta status and will be improved day
by day. The TUL Stick is very promising and offers great opportunities
at a very competetive price and is in production stage.

I hope, all your questions are answered well. Let me know if there are
any more issues.
cu
Maz



>
> Jörg (JWK)
>
> P.S.: Thanks for the enlargement of homeautomation@FHEM. Any
> proprietary restriction looses its burden at any time.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi Maz,
it's it possible to use a EIB/IP Gateway without eibd? Or is it on the
roadmap to support this? I already tried eibd but it has to much
dependencies for my NAS. My preferred way is to connect directly with
the EIBnet/IP protocol.
If not, i'm order a TUL...
Did autocreate actual create the cfg entry's for the detected TUL EIB
devices?

Thanks for the Work!
Regards
Domi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

> it's it possible to use a EIB/IP Gateway without eibd? Or is it on the
> roadmap to support this?

unfortunately not now. I will keep it in mind for a later (really
later ) time.
(I do not want to reinvent everything... and right now eibd offers a
full list of protocols / connectors, so I think it is a good idea to
have in FHEM a support for eibd and let eibd do what it can do best...

> I already tried eibd but it has to much
> dependencies for my NAS. My preferred way is to connect directly with
> the EIBnet/IP protocol.
> If not, i'm order a TUL...

The direct TUL connection has been implemented for  NAS/FB devices...
also for you
(You might maybe consider a TuxRail from busware... (I think it will
support eibd and you have a full debian)

> Did autocreate actual create the cfg entry's for the detected TUL EIB
> devices?

I do not use autocreate and so I did not took care about that So I
am afraid it will not be supported now. I will check how autocreate
work and maybe contact Rudi for that and implement that in case this
is not so complex. For complex devices (like Rollos) it will not be
possible ;(
How many actors do you have in your installation?

BTW: As it seems that "Rolläden" work all in different ways, I am also
preparing an own smart module for that issue.

(Both to be expected right after my vacations by mid of August)

> Thanks for the Work!

You are welcome. I am looking forward to seeing your feedback.
cu
Maz

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> I will check how autocreate work ...

Autocreate listens for the "global:UNDEFINED" event, which is triggered if the
modules ParseFn() returns "UNDEFINED" to Dispatch(). As far as I see this is
done by 10_EIB.pm correctly, i.e. autocreate for EIB devices should work.

On the "UNDEFINED" event autocreate creates a device by calling the modules
DefineFn with the parameters reported by the UNDEFINED event, then it creates
the corresponding FileLog. If autocreate "knows" that the device is a sensor,
then it also creates a Plot for the device. This is not yet the case for EIB
devices.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi,
also
ich bekomms nicht zum laufen
Am TUL leuchtet bei den Busklemmen eine LED Orange wenn ich ihn mit
dem Bus verbinde.
Von den Adressen her hab ich dem TUL die des KNX/Ethernet Gateways
gegeben um eine Fehlkonfiguration ausschließen zu können.
Doppelbelegung durch ausschalten des Gateways vermieden.
Die vorgeschlagene 1.1.254 hab ich auch probiert.
Es wird weder etwas vom Bus angezeigt noch kann ich an eine
Gruppenadresse was senden.

Konfig ist:
CUL:
mknod /dev/ttyACM0 c 166 0
chmod 666 /dev/ttyACM0
TUL:
mknod /dev/ttyACM1 c 166 1
chmod 666 /dev/ttyACM1
Frage so nebenbei wie wird dabei eigentlich festgelegt welches Gerät
die eins und welches die zwei bekommt?

define TUL1 TUL /dev/ttyACM1 1.1.254
define lightOG EIB 0/0/2
attr lightOG IODev TUL1

Im Logfile hab ich:
2011.07.22 17:10:36 2: FHEMWEB port 8083 opened
2011.07.22 17:10:36 2: FHEMWEB port 8084 opened
2011.07.22 17:10:36 3: Unknown IODev specified
2011.07.22 17:12:47 3: CUL opening CUN868 device 10.0.1.12:2323
2011.07.22 17:12:47 3: CUL device opened
2011.07.22 17:12:47 3: HMLAN opening HMLAN1 device 10.0.1.13:1000
2011.07.22 17:12:47 3: HMLAN device opened
2011.07.22 17:12:47 3: CUL opening CUL868 device /dev/ttyACM0
2011.07.22 17:12:47 3: CUL device opened
2011.07.22 17:12:47 3: TUL opening TUL1 device /dev/ttyACM1
2011.07.22 17:12:47 1: /dev/ttyACM1 protocol is not supported
2011.07.22 17:12:47 3: TUL device opened
Use of uninitialized value in string eq at /usr/local/fhem/lib/FHEM/
00_TUL.pm line 824, <$fh> line 16.
2011.07.22 17:12:47 2: FHEMWEB port 8083 opened
2011.07.22 17:12:47 2: FHEMWEB port 8084 opened
2011.07.22 17:14:53 1: define: Define lightOG: wrong group name
format: specify as 0-15/0-15/0-255
2011.07.22 17:16:13 2: EIB set lightOG on
SimpleWrite data: 1
Use of uninitialized value in string eq at /usr/local/fhem/lib/FHEM/
00_TUL.pm line 849.
Use of uninitialized value in string eq at /usr/local/fhem/lib/FHEM/
00_TUL.pm line 849.
2011.07.22 17:16:35 2: EIB set lightOG off
SimpleWrite data: 0
Use of uninitialized value in string eq at /usr/local/fhem/lib/FHEM/
00_TUL.pm line 849.
Use of uninitialized value in string eq at /usr/local/fhem/lib/FHEM/
00_TUL.pm line 849.

Konsolenmeldung nach dem Start:
DiskStation> perl5.8.8 /usr/local/fhem/bin/fhem.pl /volume1/FHEM/
fhem.cfg
DiskStation> Use of uninitialized value in string eq at /usr/local/
fhem/lib/FHEM/00_TUL.pm line 824, <$fh> line 16.
Use of uninitialized value in concatenation (.) or string at /usr/
local/fhem/lib/FHEM/01_FHEMWEB.pm line 572.

Ideen?
Gruß
Domi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[tostmann]

                                                 

Am 22.07.2011 um 17:43 schrieb domi:

> Frage so nebenbei wie wird dabei eigentlich festgelegt welches Gerät
> die eins und welches die zwei bekommt?


Bitte somewhere in udev definieren:

/etc/udev/rules.d/50-udev.rules:

KERNEL=="ttyACM*", ATTRS{product}=="TPUART transparent", SYMLINK
+="tpuarttransparent"

dann in fhem.cfg z.B.:

define KNX TUL tul:/dev/tpuarttransparent 1.1.249

define Schlaf.Rollo EIB 8/0/7
attr Schlaf.Rollo IODev KNX
attr Schlaf.Rollo room Schlaf

Setzt natürlich vorraus, dass das TUL mit:
http://busware.de/tiki-download_file.php?fileId=54

geflashed wurde.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi Domi,

1. Wenn die grüne LED nicht leuchtet, dann hast Du wahrscheinlich noch
kein Firmware auf dem TUL.
Tosti hat ja den Link gesendet, wo Du die Firmware findest.

2. Die FHEM definition ist nicht korrekt. Da hat Tosti auch schon
bereits die korrekte Bezeichnung geliefert: tul:/dev/xxx (wichtig ist
tul: am Anfang)
Im Log wird korrekter Weise angegben, dass das Protokoll nicht
verstanden wird, aber da ist noch wohl ein Fehler, dass die
Fehlermeldungen mit "uninitialized values" erscheinen.
Werde ich noch ausbessern.

Falls es nicht klappt, schicke mir ein PN oder poste hier.
VG
Maz

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich bin einen Schritt weitergekommen

Ist bei mir nicht möglich da das Mini Linux in meiner NAS udev nicht
hat
> /etc/udev/rules.d/50-udev.rules:
>
> KERNEL=="ttyACM*", ATTRS{product}=="TPUART transparent", SYMLINK
> +="tpuarttransparent"

Vorerst behelfe ich mir mit mknod /dev/ttyACM0 c 166 0 für den CUL und
mknod /dev/ttyACM1 c 166 1 für den TUL
Wenn nach dem booten der CUL zuerst eingesteckt wird gehts

Hab ich jetzt auch abgeändert
> define KNX TUL tul:/dev/tpuarttransparent 1.1.249

Firmware ist aufgespielt LED leuchtet grün. Ist der KNX Bus
angeschlossen leuchtet zusätzlich noch eine orange LED.
> Setzt natürlich vorraus, dass das TUL mit:http://busware.de/tiki-download_file.php?fileId=54 geflashed wurde.

Das ganze kommt auch hoch jedoch wenn vom Bus was ankommt stürzt fhem
ab. Log:
2011.07.22 20:17:28 0: Server started (version =VERS= from =DATE=
($Id: fhem.pl,v 1.147 2011-07-15 08:59:31 rudolfkoenig Exp $), pid
5284)
2011.07.22 20:19:16 3: CUL opening CUN868 device 10.0.1.12:2323
2011.07.22 20:19:16 3: CUL device opened
2011.07.22 20:19:17 3: HMLAN opening HMLAN1 device 10.0.1.13:1000
2011.07.22 20:19:17 3: HMLAN device opened
2011.07.22 20:19:17 3: CUL opening CUL868 device /dev/ttyACM0
2011.07.22 20:19:17 3: CUL device opened
2011.07.22 20:19:17 3: TUL opening KNX device tul:/dev/ttyACM1
2011.07.22 20:19:17 3: TUL setting KNX baudrate to 19200
2011.07.22 20:19:17 3: TUL device opened
2011.07.22 20:19:17 2: FHEMWEB port 8083 opened
2011.07.22 20:19:17 2: FHEMWEB port 8084 opened
2011.07.22 20:19:32 3: EIB Unknown device 0102 (0/1/2), Value 01,
please define it
2011.07.22 20:19:32 2: autocreate: define EIB_0102 EIB 0102
2011.07.22 20:19:32 1: define: Define EIB_0102: wrong group name
format: specify as 0-15/0-15/0-255
2011.07.22 20:19:32 1: ERROR: Define EIB_0102: wrong group name
format: specify as 0-15/0-15/0-255
2011.07.22 20:19:32 3: Control Byte 0x9c does not match expected mask
0xB0
2011.07.22 20:19:32 1: tul:/dev/ttyACM1 disconnected, waiting to
reappear
2011.07.22 20:19:37 3: TUL setting KNX baudrate to 19200
2011.07.22 20:19:37 1: TUL tul:/dev/ttyACM1 reappeared (KNX)
Argument "" isn't numeric in right bitshift (>>) at /usr/local/fhem/
lib/FHEM/00_TUL.pm line 729.
Use of uninitialized value in length at /usr/local/fhem/lib/FHEM/
00_TUL.pm line 748.
Use of uninitialized value in unpack at /usr/local/fhem/lib/FHEM/
00_TUL.pm line 748.
Use of uninitialized value in length at /usr/local/fhem/lib/FHEM/
00_TUL.pm line 750.
2011.07.22 20:19:37 3: Control Byte 0x9c does not match expected mask
0xB0
2011.07.22 20:19:37 1: tul:/dev/ttyACM1 disconnected, waiting to
reappear
Use of uninitialized value in vec at /usr/local/fhem/bin/fhem.pl line
340.
Use of uninitialized value in vec at /usr/local/fhem/bin/fhem.pl line
390.
Can't call method "read" on an undefined value at /usr/local/fhem/lib/
FHEM/00_TUL.pm line 881.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo Domi,

Habe eine neue Version von 10_EIB.pm eingecheckt, die jetzt auch
autocreate voll unterstützt.
(Es hat bisher gehackt, weil die Gruppen-Angabe vom Bus in einem Hex-
Format vorliegt und das EIB Modul erwartete im define ein Format nach
1/1/2. Jetzt werden beide Formate angenommen und es geht.)

Bei der direkten Anbindung des TUL (also ohne EIBD-Server) ist mir nun
aufgefallen, dass es Stabilitätsprobleme bestehen, insbesondere, wenn
zwischen drin der TUL abgesteckt wird und neu eingesteckt wird, bzw.
wenn die Busklemme ab/an-gesteckt wird. HIer bitte ich um Nachsicht.
Ich arbeite ab nächster Woche an das Abfangen der Prolemfälle.

Es wäre sehr hilfreich, wenn Du vorerst den Loglevel auf 5 setzen
könntest.
Ab und an verfällt das FHEM-Modul in ein Endlosschleife. Das erkennst
Du daran, dass nur noch Ausgaben wie

2011.07.23 13:17:44 5: buf len: 1 expected: 3

erscheint.
Hier hilft ein beherztes Neustarten. (logs an mich schicken wäre
hilfreich maz.rashid@googlemail.com)

cu
Maz

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com