Reqirements for V2.0

[steand]

With one year experience I like to start a 2.0 after summer.
In this issues i will discuss new requirements and features for this.

My first idea is to make the handling between OH2 and optolink more flexible.

1. Change the northbound API to REST (I have no experience in REST; need help for this).
2. More easy generic data model for OH2 -> needs maybe a re implementation of OH2 binding.
   2.1 The Idea is, that we implement only a hand full channel-types/data-points like: Temperature Sensor/Aktor, Pump, valve,ect.
   2.2 on the OH2 site a binding that generate the thinks and channels from the discovery (here I must first understand/clarify what OH2 supports)
3. ....

(German comments are welcome also/ Auch Kommentare in Deutsch sind willkommen)

[FulvioSpelta]

Available for testing and for analyze REST interface.
Thanks for the effort.

My current status
You know currently i'm using your northbound optolink in order to connect to the vitotronic and a self build minimal script (nodejs) in order to get values from optolink and update, using the rest interface, openhab 1 items.

I'm moving to a new OH2 based controller and, currently, tested ok the same architecture.
I'll try the native OH2 binding in the near future (I need to understand how it works because I'm new in OH2). I've done a quick test installing the binding and discovering successfully the optolink adapter but no more. (Any hints will be welcome :-) )

[Sbried]

I like the idea to start an 2.0 version with a "more modern" communication. I was also thinking about MQTT.

I was also thinking about kind of "auto-configuration" of things & channels in OH2. But I don´t know if it is possible to add things and channel apart from what is defined in thing-types.xml in OH2.

I´m open to contribute ...

[FulvioSpelta]

Just an open thought: i'd prefer to avoid mqtt because it needs a broker so an additional architectural module to add/install/update etc. My idea is to have a "self contained" object.

[steand]

@FulvioSpelta
Yes I remember. But my goal is to implement a native REST in java.
@Sbried
auto-configuration" of things & channels: My feeling is that it is possible, my understanding is that the homematic binding has only the bridge defined. I didn't understand concept of device really but If I had more time i going to a deep dive. Maybe we can ask @gerrieg .

[steand]

Things can be generic 😎
see: Documentation of eclipse smarthome
The consequence is that the description of things/channels are moved to optolink.xml.
Is this what we want?

First idea's:
OH: We have only one Bridge -> HeadingSystem.
OH: Things and channels are create by discovery.
optolink: channel value type (like: switch, number,..) has been define in the optolink.xml.
The open point: What we do if optolink.xml is changed?

• ignore (I think: is no possible)
• delete address in optolink.xml -> delete channels in OH
• same for things
• channel renamed -> create new channel in OH && delete or keep old channel?

Final:
This is going to a generic binding in OH and is not depend to Viessmann.
It looks like more a protocol Interface (like MQTT) extend by a data model (discovery).
Or a implementation of Web Thing
I think, first we need a discussion in the Community (I going to start after my trip on "Jakobsweg", middle may)

[gerrieg]

I'm loading all metadata from the Homematic gateway at bridge startup in model classes (HmDevice, HmChannel, HmDatapoint). Then i'm generating all ThingTypes, ChannelGroups, ChannelTypes, ... from that data, see HomematicTypeGeneratorImpl
It's fully dynamic, because defining the XML's for all the different devices would be a huge work.

[FulvioSpelta]

@FulvioSpelta
Yes I remember. But my goal is to implement a native REST in java.

I only like to remember my current usage. I understand and like your goal, I'll be available for contributing (if my knowledge will be sufficient) and for testing.

[steand]

I have open the discussion on OH Community CoAP Binding? yes or no
@FulvioSpelta
by the way: I will think about REST also (parallel to CoAP). But for a OH Implementation CoAP sounds good.

[c4rd0n]

hi Stefan,

for your optolink V2.0, I purpose you to add multiples connexions support. Today with the optolink RC1.0, when OH2 is connected, We can't open an other session to otpolink. And when OH2 restarts, optolink keeps the old session open and don't respond to the new instance of OH2.

To solve this problems I replaced the open function by a thread creation.
If you want I can create a pull request : my branch.

Thank's for your work,

Best Regards,

Félix

[steand]

Thanks, I am in France for long time. If I am back I going to test it, middle May. Regard Stefan Am 10. April 2017 22:10:53 MESZ schrieb "Félix CARDON" <notifications@github.com>:

…

hi Stefan, for your optolink V2.0, I purpose you to add multiples connexions support. Today with the optolink RC1.0, when OH2 is connected, We can't open an other session to otpolink. And when OH2 restarts, optolink keeps the old session open and don't respond to the new instance of OH2. To solve this problems I replaced the open function by a thread creation. If you want I can create a pull request : [my branch](https://github.com/c4rd0n/optolink/tree/feature/multithreading). Thank's for your work, Best Regards, Félix -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #5 (comment)