Homematic Binding using CUL-Stick

[GoogleCodeExporter]

Hallo,

we commited a first version of homematic binding for the CUL-Stick.
Since we have only 5 different devices, we can only support these: 
DoorHandleSensor (HM-SEC-RHS), 
DoorContact(HM-SEC-SC), 
socket adapter dimmer, (HM-LC-Dim1T-Pl2), 
socket adapter switch (HM-LC-SW1-Pl-2) 
flush-mounted switch (HM-LC-Sw1-PB-FM)

The secure devices have a sabotaged message, which we provide in an extra 
Stringitem, independent from the normal state of the sensor 
(open/closed(/tilted)). This message can be cleared by an extra switch to say 
that everything is ok and only the battery has been exchanged. A screenshot of 
this function is attached to this issue.

What is still to be done for this binding?:
The dimmer will only be dimable via openhab not via the hardwarebutton. A 
register needs still to be overwritten. The dimmer ramps and the "On Timer" is 
still not accessable. For this, the code still has to rewritten in a way like 
it is done in the hue binding.

Please have a look at:
http://code.google.com/r/pgshtudo-openhab/

Original issue reported on code.google.com by pgsh.tudo on 3 Sep 2013 at 12:41

Attachments:

• Screenshot_2013-09-03-14-27-47.png

[GoogleCodeExporter]

Cool, looks good!
Just one question: Why is the sabotage information a string item and not a 
simple switch (per device)?

Original comment by kai.openhab on 3 Sep 2013 at 6:44

• Changed state: Started

[GoogleCodeExporter]

We wanted to combine all sabotage alerts at one position, like a display of an 
alarm system.

We force the user to switch off the alarm manually, otherwise the thief could 
bypass the sabotage switch implemented in the devices, because the sensors send 
a also a "fixed" message.
Do you know if and how it is implemented in the HomeMatic binding?

What we forget in in our first posting: We use the new CUL implementation of 
Till Klocke (Issue #227: http://code.google.com/p/openhab/issues/detail?id=227 
).

Original comment by pgsh.tudo on 4 Sep 2013 at 10:03

[GoogleCodeExporter]

Having single sabotage notification switches (and sabotage reset switches) per 
device would still allow the user to create a string item that reports the 
status for the devices he is interested in. I think this would be a more 
flexible solution (as a user you could e.g. also create different sabotage 
"zones" by grouping different sets of devices).
For the normal Homematic binding, see 
https://groups.google.com/d/msg/openhab/ft5hHV18jmA/FW42lS2jYzsJ.

Original comment by kai.openhab on 4 Sep 2013 at 6:27

[GoogleCodeExporter]

@pgsh.tudo
Interesting project. We should probably work a bit more together. I created a 
CUL transport in my clone. The target is to abstract all the hardware details 
away, so in the it shouldn't matter for a developer if the device is a CUL or 
CUN(O) or something else running culfw. But currently it is probably a bit 
optimised for the slow rf mode of the CUL, input here is very appreciated.
Also I have analyzed the XML files which come with the XML-RPC windows service. 
Nearly everything relevant is described here. I'm currently writing a generator 
which creates Java sources representing the packets and payloads described 
there. So full support of all availabe (and even unreleased and custom) devices 
is possible.
The packet format of the CUL HM mode and the HMCFG-LAN have much similiarities 
so a combined effort would make sense.

Original comment by till.klo...@gmail.com on 5 Sep 2013 at 7:10

[GoogleCodeExporter]

actually we just didn't think about creating a switch for each item and manage 
them via a rule, but it sounds actually not bad
but we think this will take some time and unfortunately we have to focus a 
little bit to other things for our project.
we added support to motiondetector hm-sec-mdir, dimmer hm-lc-dim1l-pl and 
switch HM-lc-sw1-pl 
but we also have to admit, that we actually don't support the configuration of 
the devices. we have done this so far via the usb configurator.
maybe don't look to the changelog, i don't know what i have done. commited a 
little bit to much. ;)

Original comment by pgsh.tudo on 13 Sep 2013 at 3:18

[GoogleCodeExporter]

Original comment by teichsta on 5 Nov 2013 at 10:53

• Added labels: To-Github

[GoogleCodeExporter]

Just stumbled upon this issue. Cool stuff, there are lot of requests for 
cheaper Homematic controllers.
Perhaps we really should work closer together, I fully agree with Till here. It 
would be awesome to have ONE homematic binding with serveral different low 
level controller supported: CCU1/2, CUL/CUN/LAN Adapter, USB Adapter. What do 
you think?
All should behave the same for their supported devices...

Original comment by thomas.letsch.de on 16 Nov 2013 at 3:53

[GoogleCodeExporter]

This issue has been migrated to Github. If this issue id is greater than103 its 
id has been preserved on Github. You can open your issue by calling the URL 
https://github.com/openhab/openhab/issues/<issueid>. Issues with ids less or 
equal 103 new ids were created.

Original comment by teichsta on 17 Nov 2013 at 8:08

• Added labels: Migrated-To-Github

[GoogleCodeExporter]

see above!

Issue has been migrated to Github and should be discussed there.

Original comment by teichsta on 21 Nov 2013 at 1:51

• Changed state: Invalid