LCN binding

[crosenbe]

I will start this binding, help is welcome.

[Blumi]

Hey, I'm currently reading into openHAB2 to write an LCN binding as well (haven't started developing yet). Are you still into it?

I'm still figuring out the details, but the big picture of my concept is this:

I just don't know yet, how many things, channels, ... etc. I need. Maybe some openHAB pro can give me a kickstart on this? Kai???

[kaikreuzer]

@Blumi I doubt it makes much sense to start another LCN binding - as far as I know, @crosenbe is actively working on it.

[crosenbe]

@Blumi i started with this plugin, but within the last weeks i didn't have as much time i would like to spend, i created some parts of code which connects to PCHK and get data from LCN. Next steps are to do a base design and check out if and how discovery could be used.

[Blumi]

@crosenbe could you commit your work to your github fork, so I can have a look at it, please?
What do you think of my idea (see image above) to use the XML export of the LCN-PRO project as configuration for the openHAB-binding?
For the discovery - I don't think we will get far with LCN/PCHK. Officially there is no "scanning" of the bus supported. However I found out that you can send an undocumented PCK message on which every busmodule answers with it's ID. But nothing more. AFAIK you cannot scan the bus for specific sensors, actors or displays. Hence my idea to use the LCN-PRO XML.

[crosenbe]

I could upload the code but it will not work because i started a redesign. I don't know if the export will work but perhaps there are users which do not have LCN-Pro and want to use openHab anyway. I try to find a way to include LCN into openHab with less user configuration as possible. On the bus interface it's possible to fetch every ID to collect the modules, afterwards there are commands to get more informations about these modules, i.e. the firmware release.

The firmware is essential to define the function the module provides, you know v14 use three variables, v17 could use 10. The idea is to define the functions per release in a static way and use the templates after reading of the module firmware.

The attributes which could not read, have to be configured by hand. But that's just an idea how it could be handled, i don't know if it's a practical solution or not.

[myghost77]

Hi,

I'm also working an a binding for LCN. I've started with the development before I have read this issue :-( .

What is the current status of your binding?

I'm already able to dim my lights :-) . I'm going to implement further features soon ...

Can I find your implementation somewhere?

By the way: It is not important to have an XML-export from LCN-Pro to create the item configuration automatically. I think it is a better approach to configure the LCN items manually. It will be hard to create reasonable names for the items during automatic export.

[Blumi]

But the XML Export contains the item names that you see in LCN-PRO, everything you'll need is in there:

<Module xsi:type="LCN-UPP" firmwareDate="17070A" serialNo="17070A1*****" foundInBus="false" moduleId="10">
<Name>Schlafzimmer</Name>
<Comment/>
<PeripheryList>
<Periphery xsi:type="PerTypeKeyboard_BT4HorBT4R" name="BT4H/R"/>
</PeripheryList>
<PropertyList>
<BeepOn enabled="true">
<KeyPress>true</KeyPress>
<Errors>true</Errors>
</BeepOn>
<StatusMessages enabled="true">
<NotificationMode>local</NotificationMode>
<NotificationDelay>normal</NotificationDelay>
</StatusMessages>
<SendInternalCommandsToBus>true</SendInternalCommandsToBus>
<PowerFailureCausesKeyD8>false</PowerFailureCausesKeyD8>
<PermitKeyLockTableA>false</PermitKeyLockTableA>
<TransponderEnabled>false</TransponderEnabled>
<OutputPorts xsi:type="OutputPortsDefault">
<StatusCommands>
<Output id="1" destTable="D" destKey="1">false</Output>
<Output id="2" destTable="D" destKey="2">false</Output>
<Output id="3" destTable="D" destKey="3">false</Output>
<Output id="4" destTable="D" destKey="4">false</Output>
</StatusCommands>
<Output id="1" mode="dimmer" extra="disabled" charTable="linear">Deckenlampe</Output>
<Output id="2" mode="dimmer" extra="disabled" charTable="linear">Wandlampe</Output>
<Output id="3" mode="switch 1%" extra="disabled" charTable="halogen"/>
<Output id="4" mode="switch 1%" extra="disabled" charTable="halogen"/>
</OutputPorts>
<TPort xsi:type="TPortDefault">
<MakeDetection>long</MakeDetection>
<ContactMode>make</ContactMode>
</TPort>
<IPort xsi:type="IPortNoSensor"/>
<PPort xsi:type="PPortVirtualRelays">
<RelayStatusCommands>
<Relay1-4>false</Relay1-4>
<Relay5-8>false</Relay5-8>
</RelayStatusCommands>
</PPort>
<Keys>
<Table id="A">
<Key id="1" comment="Tür Lichtschalter">
<Fnct id="1" destSeg="0" destType="module" destId="0">
<Command type="hit">Ausg.1: UMschalten, Rampe: 1.00 Sek</Command>
<Command type="make">Ausg.1: UMschalten, Rampe: 4.00 Sek</Command>
<Command type="break">Ausg.1: Rampe stop</Command>
</Fnct>
</Key>
<Key id="2" comment="Tür Doppelwippe li">
<Fnct id="1" destSeg="0" destType="module" destId="6">
<Command type="hit">Relais: - - - - U U - -</Command>
<Command type="make">Relais: - - 1 1 1 0 - -</Command>
<Command type="break">Unprogrammiert</Command>
</Fnct>
<Fnct id="2" destSeg="0" destType="module" destId="0">
<Command type="hit">Unprogrammiert</Command>
<Command type="make">Ausg.1: =100%, Rampe: 30.00 Sek</Command>
<Command type="break">Unprogrammiert</Command>
</Fnct>
</Key>
<Key id="3" comment="Tür Doppelwippe re">
<Fnct id="1" destSeg="0" destType="module" destId="6">
<Command type="hit">Relais: - - U U - - - -</Command>
<Command type="make">Relais: - - 1 0 1 1 - -</Command>
<Command type="break">Unprogrammiert</Command>
</Fnct>
</Key>
<Key id="4" comment="Bett Lichtschalter">
<Fnct id="1" destSeg="0" destType="module" destId="0">
<Command type="hit">Ausg.1: UMschalten, Rampe: 3.00 Sek</Command>
<Command type="make">Sende Tasten: 1 - - - - - - - D=kurz</Command>
<Command type="break">Unprogrammiert</Command>
</Fnct>
</Key>
</Table>
<Table id="B"/>
<Table id="C"/>
<Table id="D">
<Key id="1">
<Fnct id="1" destSeg="0" destType="module" destId="6">
<Command type="hit">Relais: - - 1 0 - - - -</Command>
<Command type="make">Unprogrammiert</Command>
<Command type="break">Unprogrammiert</Command>
</Fnct>
</Key>
</Table>
</Keys>
</PropertyList>
</Module>

[myghost77]

You are right: In case you have added comments to your LCN-Pro configuration, you will have the possibility to create reasonable names. I do not have that much comments in my LCN-Pro. I will use the openHAB configuration as documentation for my system ;-) . So, the XML-converter would have a very, very low prio on my side ...

First of all I want to have a running binding as soon as possible!

[myghost77]

So, I have finalized the first version of my binding for LCN !!! You can find it here: https://github.com/myghost77/openHAB
I have also added a very rough documentation ...

In the mean time the manufacturer has also released a binding for LCN :-( . Had I known it earlier, that the manufacturer is working on a binding, I would not have begun. This means that I will not bring my version to the openHAB project, but will use it in my own LCN system @home :-) .

Now I will start to create the item configuration for my binding for my home to see how it behaves in a large, real system ...

[kaikreuzer]

Hi @myghost77,

Yes, that was also a big surprise to me that Issendorff developed an LCN binding - it would indeed have been much better if they had announced that in advance as many people now spend efforts in vain. Although it is not clear, which implementation is better, this is something only LCN users can judge.

Actually, this issue here is about an LCN binding for openHAB 2 - and if I get you right, your binding is for openHAB 1, right? So we are still lacking an openHAB 2 version. We should discuss together how to proceed best on this. I'm trying to contact Issendorff to see how much they would / want to involve themselves.

Best regards,
Kai

[kaikreuzer]

FTR: There is now an official openHAB 1 LCN binding that also works on the openHAB 2 runtime (and it is included in the openHAB 2 addon zip).
@Blumi: Are you actively looking into porting it to OH2 or is it good enough and we close this issue for now?

[Blumi]

I think this issue can be closed, I'm not porting it anytime soon, sorry.
Maybe the author of the official LCN binding @Issendorff plans on porting it to OH2. I think this depends on the public response and the impact on the commercial sales of the LCN hardware.

[Issendorff]

I will port it to OH2 in the near future. Still waiting for customer feedback for the current binding though (hope it will be included in the Add-Ons binary package anytime soon).

[kaikreuzer]

Still waiting for customer feedback for the current binding

openHAB 1.8 will be released on Jan 11 and this is the first release that contains the LCN binding. I will also specifically highlight it in my announcement, so I hope that more people will learn about it, start using it and provide feedback!

[fwolter]

I finished porting the LCN binding to OH2. Just mentioned, that nobody else takes effort to port it in the meantime. I'll test it with my busses and send a PR if everything is fine.

[amut41]

Cool. I‘d be happy to offer a test on my LCN/openHAB set, if it might be of any help.

[fwolter]

Thanks for the response! I'd be happy to have testers as well. Please drop me an email. I will come back to you as soon as I finished some tests and documentation. [email protected]