|
|
|
|
| Re: EnOcean Binding [message #1706245 is a reply to message #1705135] |
Tue, 25 August 2015 09:17   |
 Oliver Fischer
Messages: 2
Registered: August 2015 |
Junior Member |
|
|
Hello together,
as a system integrator we were looking for a good EnOcean/IP Gateway and there were only "tunnel" gateways, which transport the EnOcean stack over IP but leave the complexity to the one who wants to use it. Basically the well known USB stick over IP. So we started about two years ago in developing a Smart IP Gateway for EnOcean with a REST/JSON Interface. We are currently approaching market release and support already the most used profiles together with functions like Smart Ack and UTE. Functions like Remote Management or Remote Commissioning will be integrated soon.
EnOcean has a complex protocol and the representation of all the existing EEPs and their functions is not the easiest part.  Looking around, there are a lot of "started" implementations or bindings out there but none of them is really finished. Things get worse when new features like security or remote commissioning are coming up the roadmap, which will then have to be implemented over again by everybody.
We believe that there should be an abstraction layer when connecting EnOcean to the IP world, the IoT at the end. We are currently working close together with other EnOcean Alliance partners to define such a standard for EnOcean.
Right now (a week ago), we started developing a binding for Eclipse SmartHome based on the REST Interface. The goal is to get a full integration of EnOcean into OpenHab2
The website for the Gateway is www.enocean-gateway.eu where there is some information about the product.
We have also the EnOcean JSON API online (www.enocean-gateway.eu/index.php/en/api-uk-uk), if you want to look at it and play around. Remarks welcome.
The range of working together we are looking for could be from simple exchange of information/Know-how up to working on the binding together. We could provide you also with a Gateway to work with. In any case, feel free to contact me.
As soon as we have something worth contributing, we will open a project on git.
Thank you,
Oliver Fischer
|
|
|
| Re: EnOcean Binding [message #1707220 is a reply to message #1706245] |
Thu, 03 September 2015 07:38 |
|
If an EnOcean binding is part of Eclipse SmartHome and so licensed by the EPL, the SOFTWARE is free to use also for commercial products.
What are the impacts for the EnOcean Alliance at all?
At which time in "bring a product to market" I have to be a member of the EnOcean Alliance?
If I sell hardware that contains the TCM?
Can I offer a commercial product that contains the binding and all the software to be able to communicate with EnOcean devices but without a EnOcean hardware?
So a consumer could buy a USB Stick themselves, plug it into and all is working.
Which EEPs are allowed to implement under the EPL?
Could someone say, that I must not decode some bits and bytes because a document contains a watermark?
Before further development of a binding (with the target to bring it into a Eclipse project) I would like to have some information about the license impacts, the EnOcean Alliance and so on.
|
|
|
|
|
| Re: EnOcean Binding [message #1709019 is a reply to message #1707383] |
Wed, 23 September 2015 11:15 |
Oliver Fischer
Messages: 2
Registered: August 2015 |
Junior Member |
|
|
Hello together,
sorry for being away a little bit but September was a busy month so far...
Well, indeed it is a tricky point with the EEPs and the Intellectual Property of the EnOcean Alliance. So, i would try to clarify a little bit the discussion.
It is true, that the EnOcean Alliance considers the EEPs as its Intellectual Property and thus, any company that makes a software product that uses the EEPs (as well as any manufacturer of EnOcean Hardware Devices) must be member of the EnOcean Alliance.
This makes a full integration from the bottom up (starting with the EnOcean Serial Protocol from the chip) as an open source stack nearly impossible.
Further on, it is not only the EEPs which need to be integrated in the stack but also the functionality of the more complex EnOcean functions as UTE (Universal Teach-in), Smart-Ack (Smart Acknowledgement technology for energy harvesting devices that "sleep" most of their time), ReMan (Remote Management) and ReCom (Remote Commissioning), Generic Profiles and of course Security on the Radio side.......
The EnOcean Alliance is on the other side aware of this and at the moment, there is an ongoing task-group which is defining an "IP-Representation of all the EEPs" in a RESTful, JSON description (together with the core transport layer) which will then be standardized by the Alliance (no Intellectual Property here).
So, a binding in ESH could be written against this IP-Representation without violating any intellectual property-Rights and can so be part of the ESH. Any willing member of the EnOcean Alliance is then able to write (in closed source) the interface part that produces the defined IP-Output which then would fit to that binding.
As we understand it, this way seems for all parties the best solution so that no one is losing any Intellectual Property.
I hope this helps a little bit - comments welcome.
Oliver
|
|
|
|
Powered by
FUDForum. Page generated in 0.04053 seconds
] 
Search
Help
Register
Login
Home
