EnOcean Binding

[Thomas Letsch]

Hi,

its now already a month that I own the EnOcean starter kit and it still lies there where I left it. I would love to have an EnOcean binding since I dream from solar powered temperature sensors in every room for my heating control.

There were discussions about whether to support the Thermokon STC-Ethernet Bridge or the ESK 300 USB Stick. Since I already bought the ESK, I would at least prefer both. What I understand, the main controlling of the EnOcean devices should be the same since the Thermokon is mainly acting as a bridge. I suppose the Windows software takes care about management etc. So a common EnOcean library for controlling (reading / writing values) EnOcean devices and a second one for the remote management protocol could be a valid way. Then add a serial based binding or a UDP / TCP based binding for both controllers. Is that feasible?

One thing I recognized when reading the API documents is that they change the way devices are described (the so called EEP) from a documented approach to a XML file based approach. These files are apparently only available for members of the enocean alliance (http://www.enocean-alliance.org/en/forum/?tx_mmforum_pi1[action]=list_post&tx_mmforum_pi1[tid]=127). Perhaps one could start without these files by supporting older devices, but eventually someone would have to require membership :-(

I can spend a little time on this binding, but I am still quite busy with the homematic binding. Who else is motivated?

Regards,
Thomas

[Kai Kreuzer]

Hi Thomas,

There were discussions about whether to support the Thermokon STC-Ethernet Bridge or the ESK 300 USB Stick. Since I already bought the ESK, I would at least prefer both.

I also think that supporting the USB stick would be the better option - it is much cheaper and many more users will invest in it. In the discussion it was just said that the implementation effort might be much higher...

One thing I recognized when reading the API documents is that they change the way devices are described (the so called EEP) from a documented approach to a XML file based approach. These files are apparently only available for members of the enocean alliance (http://www.enocean-alliance.org/en/forum/?tx_mmforum_pi1[action]=list_post&tx_mmforum_pi1[tid]=127). Perhaps one could start without these files by supporting older devices, but eventually someone would have to require membership :-(

That's a pity. It might also mean that even if someone of us joined the EnOcean Alliance we would not be allowed to open source our code… On the other hand, there are a couple of open source EnOcean libraries - we should clarify this topic.

Maybe it could also be an option to ask Rainer Hitz (see http://www.openremote.org/display/forums/EnOcean+support) if he is willing to collaborate on the code. As he already implemented quite something (according to http://www.openremote.org/display/project/2012/07) and all his code is in Java, this might be interesting. And we would find out how open openRemote is :-D

Just my 2 cents.

Kai

[Karel Goderis]

Hi Kai

On 28 Jan 2013, at 23:26, Kai Kreuzer <k...@openhab.org> wrote:

Hi Thomas,

There were discussions about whether to support the Thermokon STC-Ethernet Bridge or the ESK 300 USB Stick. Since I already bought the ESK, I would at least prefer both.

I also think that supporting the USB stick would be the better option - it is much cheaper and many more users will invest in it. In the discussion it was just said that the implementation effort might be much higher...

I would vote for the Bridge, and that has to do with distance/reach of the radio protocol. (I would place bridges "left and right"). From what I remember, the price between the 2 options was not that dramatic, but we could support both, it is just question of good code factoring ;-)

One thing I recognized when reading the API documents is that they change the way devices are described (the so called EEP) from a documented approach to a XML file based approach. These files are apparently only available for members of the enocean alliance (http://www.enocean-alliance.org/en/forum/?tx_mmforum_pi1[action]=list_post&tx_mmforum_pi1[tid]=127). Perhaps one could start without these files by supporting older devices, but eventually someone would have to require membership :-(

That's a pity. It might also mean that even if someone of us joined the EnOcean Alliance we would not be allowed to open source our code… On the other hand, there are a couple of open source EnOcean libraries - we should clarify this topic.

Maybe it could also be an option to ask Rainer Hitz (see http://www.openremote.org/display/forums/EnOcean+support) if he is willing to collaborate on the code. As he already implemented quite something (according to http://www.openremote.org/display/project/2012/07) and all his code is in Java, this might be interesting. And we would find out how open openRemote is :-D

 

I willing to support this/do some work for this binding, but only in a few months. Don't know how patient everyone is ;-)

K

[Victor Belov]

Hi,

We can make a "remote" stick based on raspberry. It will be cheaper and even more interesting, including wifi. All we need to do that is support multiply enocean interfaces and support serial and serial-over-tcp connections with the same protocol. 

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Karel Goderis]

mmh... would you then have an OH instance run on the remote raspberry, and have that one communicate with the "main" OH instance over remote OSGi?

[Victor Belov]

Hi,

You kidding??? Of cause not!!! :-) I thought about using raspberry as a remote serial server accepting tcp connections to usb enocean stick ;-) netcat? :-)

Sent from my iPhone

[Romain Bourdy]

Maybe ser2net ?

[Thomas Letsch]

Hi,

or take a few old DSL/WLAN routers (Fritz boxes) and use them as ser2net forwarder. There are still two of them in my basement :-). 

BTW, I had a look at Rainer Hitz's code and it seems quit far already. Also tried to contact him and now waiting for a response. To implement the protocol from scratch could be quite an effort, so we should try to use the existing implementation. Which is btw for the USB stick :-). He also seems to support also older API versions etc. Hope to hear from him.

Regards,

Thomas

[Kai Kreuzer]

Hi Thomas,

Thanks for taking action here already - let's see if Rainer answers :-)

Where did you find the code from him? DO you have a link?

Regards,

Kai

[Thomas Letsch]

HI Kai,

the code is AGPL licensed and available under the SVN URL https://openremote.svn.sourceforge.net/svnroot/openremote/workspace/rhitz. Had to search a little bit to find it :-).

My hope is that we can extract a common library to communicate with EnOcean devices. 

The thing is that I am currently rebuilding the basement floor and would like to only rely on OpenHAB + Homematic and EnOcean devices for heating control. To install a wired analog control would cost me quite a few hundred euros. So I am really motivated :-). 

R.,
Thomas

[Thomas Letsch]

HI All,

I have no really good news from my contact with Rainer :-(. They build their stuff with a dual license (AGPL and commercial) and therefore don't want to publish it as a separate library. Even my proposal to switch to a more commercial friendly ASL or similar was responded negative. I can only guess that they do not want to enable commercial competitors to use their work. Well, that proves that my decision to go with OpenHAB was right. OpenRemote seemed too commercial to me already in its early stages. 

From my point of view there are two possibilities:

1. We fork Rainer's code and adapt it to OpenHAB. AGPL should be compliant with GPL and so I think we can just use it. Disadvantages are that we would have to maintain the EnOcean protocol implementation fully for ourselfs, totally and with little chance of other projects using it. Advantage is the already big codebase (we would have to take a real close look)

2. We start a new EnOcean java library from scratch. Choose a business friendly license (ASL) and there is a big chance that other projects will use and support it as well. Advantage is that we have similar protocols for zwave and others and could share things. The disadvantage is clear and it will be quite an effort. Even if we only support the latest API.

The first one is more short term success, the second more long term. Well, my time is limited and short, so my preference is the first one (otherwise I would always have supported the second and in my point of view cleaner option).

OpenSource licensing is sometimes challenging :-)

Still no idea in how to handle the XML files problem, but I can just ask the EnOcean alliance. They should support any project adopting the EnOcean protocol.

What do you think?

R.,
Thomas

[Victor Belov]

Hi,

I would choose to be independent with option #2 :-)

Sent from my iPhone

--

[Karel Goderis]

I share Victor's opinion

I would also vote for #2, and get some "inspiration" from the code base in #1

IMHO, based on what I have learned from Sonos and Plugwise implementation, basically, the OpenHAB "side" is easy to do, with a copy/paste-in-large of these bindings, It is just a question of understanding the EnOcean message format and write a handler for that. I agree on the XML bit, but there are solutions to it as well. (Well, Kai needs to sanction it ;-)  which reminds me of my Xtend question for the IR binding.......)

Since enOcean is new to us all we are in a comfort position that we can choose an initial API to support. It is just a question to harmonize our HW choice (Bridge or stick) and implement towards that. Anything else thereafter is nice to have I would say. I.e. there is no legacy to take into account.

K

[Kai]

Hi,

I would also opt for option 2 as option 1 can lead us into the GPL trap - so AGPL is also not compatible with our approach to "ask every contributor to grant the openHAB project owner(s) the code contribution under the EPL as well." (see the licensing section at http://code.google.com/p/openhab/wiki/HowToContribute).

Karel, what solution do you see for the XML file problem?

Thomas, how did OpenRemote solve this problem? Have they become a member of the Enocean Alliance?

In any case, it can't be wrong to contact them about their position to support Open Source - maybe we are granted access to them.

Best regards,
Kai

[Thomas Letsch]

HI All,

ok, convinced :-).

And I agree with Karel that it should be enough for a first version to support the current API. AFAIK all of us have actual hardware so we can only test the actual API. The abstraction of the physical connection (USB or Network) should not be too complicated. So everyone can be happy with his hardware choice!

About the XML files: I don't think that they have access to the XML files already. The code was probably written with the (now outdated) EEP Spec. Which should actually work for most devices still, but not for the future. And it could make coding simpler if one don't have to code the support for each device, but only read the XML files and build a general logic on top of them.

R.,
Thomas

[Karel Goderis]

On 06 Feb 2013, at 21:19, Kai <kai.o...@gmail.com> wrote:

Hi,

I would also opt for option 2 as option 1 can lead us into the GPL trap - so AGPL is also not compatible with our approach to "ask every contributor to grant the openHAB project owner(s) the code contribution under the EPL as well." (see the licensing section at http://code.google.com/p/openhab/wiki/HowToContribute).

Karel, what solution do you see for the XML file problem?

I would create a general XML parser that reads the XML Equipment Profiles stored in a directory, and map them in a datastructure, and do some kind of translation as done in the KNX binding. then in the configuration file use references to the EP's to "tag" a device as being of a given type

Personally, I do not know how often these EP's change in the Enocean standard, if not too much, then maybe hardcoding a subset of what we need (for example, I presume we do need the teach-in functionality etc in OH), directly mapped to OH types would be an alternative.

K

[Victor Belov]

Hi,

In KNX binding DPT mapping to openHAB is hardcoded, so I don't see a reason not to follow this way with Enocean, at least for a first release...

Sent from my iPhone

[Thomas Letsch]

About the XML files: I don't think that they have access to the XML files already. The code was probably written with the (now outdated) EEP Spec. Which should actually work for most devices still, but not for the future. And it could make coding simpler if one don't have to code the support for each device, but only read the XML files and build a general logic on top of them.

Just seen, that I was wrong here. OpenRemote is Associate Member of the EnOcean Alliance. So they have access to the XML files. 

[Kai Kreuzer]

But I guess they did not check them into their source repo…?

Do they bundle them to the distribution as a jar instead?

Am Feb 7, 2013 um 2:17 PM schrieb Thomas Letsch <thomas.l...@googlemail.com>:

About the XML files: I don't think that they have access to the XML files already. The code was probably written with the (now outdated) EEP Spec. Which should actually work for most devices still, but not for the future. And it could make coding simpler if one don't have to code the support for each device, but only read the XML files and build a general logic on top of them.

Just seen, that I was wrong here. OpenRemote is Associate Member of the EnOcean Alliance. So they have access to the XML files. 

[Kai Kreuzer]

Hi Karel,

> I would create a general XML parser that reads the XML Equipment Profiles stored in a directory

As far as I understood, the "problem" is not the parsing of the files, but getting hold of them at all. As long as we are not an EnOcean Alliance member, we would simply not be allowed to have them.

Regards,
Kai

[Karel Goderis]

Ok my misunderstanding

Sure they are not cached by google by accident? :-)

K


Sent from my iPhone

[Kai Kreuzer]

> Sure they are not cached by google by accident? :-)

I was again unclear - it is not a matter whether we can get hold of them, but if it is legal for us to include them :-)

Regards,
Kai

[Karel Goderis]

It is not my day today

Maybe utterly stupid question, but, if you buy or posses an enocean device of some kind, aren't you entitled to the usage of the equipment profile(s) associated with that device?

K

Sent from my iPhone

[Thomas Letsch]

Hi All,

I just wrote a first email to the EnOcean Alliance help contact asking if they would support open source projects like us. Lets see how far that will go.

Am Donnerstag, 7. Februar 2013 22:36:44 UTC+1 schrieb karel....@me.com:

It is not my day today

Maybe utterly stupid question, but, if you buy or posses an enocean device of some kind, aren't you entitled to the usage of the equipment profile(s) associated with  that device?

I suppose not. That really depends on their license under which they distribute these files. You don't buy the spec, you buy the device.

Regards,

Thomas

[Timoh]

Very curious about EnOcean... I hadn't heard of them before.

I'm going to go out on a limb here...  EnOcean licenses it's patented technology to the alliance.  I don't think the EEP specification is patented.  The XML files is part of the EEP specification.  = Free to use.

That being said, the spec may be serious overkill for OpenHAB.  We can just extract the info we need from the pdf.  When I see stuff in the spec that is for which way my window handle is pointing, but yet OpenHAB doesn't even have a notion of a window handle, I have to ask the question about overkill of info.

Tim

[Romain Bourdy]

AFAIK they do support Open Source, they've even offered to lend devices for us to create the appropriate binding on another HA project.

--

[Thomas Letsch]

Sounds all very good. I agree with Tim that we probably do not need the XML files to get started. In Homematic we needed also only a little from the specs to get a first version working.

Lets start now? :-)

[Victor Belov]

Hi,

What is the initial enocean kit needed to test the future openHAB enocean stuff?

Best regards,

Victor Belov

[Romain Bourdy]

I think it is  ESK300 kit. 

http://www.g-media.fr/esk-300.html

Worth appx 100€, mybe if someone contact them we could get a rebate for OH users/devs ?

Rgds,

Romain

[Evert van Es]

I have developed a simple connector for Enocean and micasaverde and would like to help. (see http://code.mios.com/trac/mios_enocean )

I have abandoned the micasaverde, well actually it abandoned me and broke down. Being disappointed with the company behind micasaverde I would like to join in with openhab on the assumption that it is a good platform and will eventually support zwave and enocean.

When I started developing for enocean products the protocol was very very limited. I heard that the new wave of devices finally has bidirectional support (but do not expect this on all devices!). Also there were problems of impersonation and I was having problems with sending signals to enocean actors, but this could be due to my limited knowledge and the fact that enocean documentation is very sparse and hard to understand.

The reason I work with enocean is because some of their devices are awesome. I do not like the dimmers, I much prefer zwave, but the batteryless window contact sensor, the batteryless remotes and switches are all excellent. What I want to achieve is use the enocean energy harvesting sensors and switch zwave dimmers.

I have just ordered the new usb enocean dongle and will start to experiment with that.

Has anyone started some code for enocean? 

My java experience is very limited but I hope my c# experience will help me get underway quickly.

[Kai Kreuzer]

Hi Evert,

Yes, we were already starting discussions around an EnOcean binding and Thomas Letsch will probably take the lead here - and additional forces are always welcome!

Plan is to first concentrate on our 1.2 release, which is scheduled for April 16 and start with EnOcean afterwards, i.e. in about 3 weeks time. You should expect to hear more on this topic here then.

I very much agree with you that EnOcean is a wonderful technology for sensors like window handles etc. as it does not require any batteries. For actuators, other things (with a reliable two-way communication) might be a better choice though.

Best regards,

Kai

[Thomas Letsch]

HI Evert,

sounds very good to have one who has already developed with EnOcean! And I can only confirm your thoughts about why and where to use EnOcean. I am planning to use it for temperature sensors and push buttons to avoid batteries there. Very cool technology for that. For my actors I am using homematic since it provides a bi-directional interface for very low cost. But its mainly on the german market.

Kai already mentioned almost everything. I just want to answer your last question:
Yes, I started already a little with an EnOcean binding. Still on my local disk yet. My main topic is at the moment the release of the Homematic binding for openhab 1.2.
It is really not much code, just part of the serial protocol of the latest protocol version (to get a feeling :-). Give a few more days to publish it.

Best regards,
Thomas

[Evert van Es]

Thomas,

I hope to receive my enocean dongle next week. Would like to receive a copy of your code so I can start tinkering.

My house is currently uncontrolled due to my vera breaking down... Funny how you get used to things happening automatically in my house....

All my devices do have manual control but it just is not the same....

Good luck with the pending openhab release.

kind regards,

Evert

[Thomas Letsch]

Hi Evert,

I just pushed the code to a new googlecode project:

https://code.google.com/p/java-enocean-library/

As you can see, there is not much in it yet.

R.,
Thomas

[Evert van Es]

Thomas,

for me the hardest part is the openhab osgi part. I was hoping that the basic plumbing was there already.

As I am familiarizing myself through the rfxcom binding I propose that I create a new binding based on the rfxcom implementation, and see how it goes from there.

Yesterday I received shipping confirmation, my enocean dongle should be underway from Germany to Holland now... Hope te receive it shortly!

thanks Evert

[Pauli Anttila]

Hi Evert,

there is unofficial binding template readme.txt developed by Thomas. I have used it to create my bindings stubs.

Br,

Pali

2013/4/18 Evert van Es <evert...@gmail.com>

--

[Thomas Letsch]

Hi Evert,

the good thing is that I now know a lot about the OSGI binding part since I just finished the first version of the homematic binding.

We should use the homematic binding as template for the EnOcean binding. The two protocols are very similar (both are complete wireless automation protocols).

The initial setup should not be a big thing (TM), I can try to copy the relevant parts from the HM binding.

Regards,

Thomas

[Evert van Es]

Thomas,

if you could setup a basic binding, that would be excellent!

thanks Evert

[Thomas Letsch]

Hi Evert,

I just checked in a first binding skeleton which I copied from the HM binding. You can find it here:

https://code.google.com/p/openhab-enocean/

Anyway I would suggest we try to get the protocol library running before "attaching" it to openHAB. IMHO it is easier to develop the EnOcean part for itself (therefore the different project https://code.google.com/p/java-enocean-library/) and then bind it to openHAB. 

A standalone EnOcean library in java has several advantages, one is the possibility for other projects to use it. So the wheel doesn't get reinvented every time :-)

R.,
Thomas

[Evert van Es]

Thomas,

Ok sounds reasonable. I might want to adjust some things in your project. Like the namespace 😃

Being new to java, eclipse, maven etc.. I am not to keen to learn git in the process, hg was new for me already. 

The serial driver dependency does not work, I managed to get it working by putting the jar in the folder.

I now have a working serial connection to the dongle and am trying to figure out what code should go where in your classes.

I will keep you posted on my progress.

Thanks Evert.

Verstuurd vanaf mijn iPhone

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/ETYu-zsAXX8/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.

[Evert van Es]

Thomas, I just pushed git. Hope it works.

I did not get very far but a basic message is coming in. I now need to find a way to convert object to the specific radio type of object.

cheers, Evert

[Thomas Letsch]

Hi Evert,

thanks for the start and cool that a first message appears!

Unfortunately it seems that there is something missing in the last checkin. Could you please check if you have pending changes locally (newly added files that not committed or similar)?

Another thing: The project relies on maven as dependency resolver. There should not be a library checked in into the project. Maven will provide you the jar when needed.

I compiled a small IDE setup that hopefully will show you how to setup Eclipse to work with the maven project:

https://code.google.com/p/java-enocean-library/wiki/IDESetup

Last thing: You can of course rename the packages :-). I forgot to rename them before checking in...

R,
Thomas

[Evert van Es]

Thomas,

my maven setup did not resolve correctly to the specific 3.8.8 version of the jar, that is why I downloaded it and put it in the folder. It suddenly worked then.

The git integration in eclipse was not active, I used the commandline version. I find it rather confusing compared to the versions I am used to using (primarily svn and recently hg, why you chose a different system is a little puzzling for me)

I tried git again, you should now have a working version. I needed to re-add a lot of files, I do not understand why...

Hope to find some time soon to continu with the project.

Thanks Evert

[Thomas Letsch]

Hi Evert,

thanks, version is working now. I have to try it out!

Choosing a versioning system is not that easy. SVN is probably the most popular, but lacking some functionality. From the distributed ones, GIT the most used. Choice of taste, I know GIT better, thats all :-). Sorry if it complicates things for you.

I corrected the maven setup today, it could indeed not find the 3.8.8 version. The pom uses now the 3.7.1, which is available in the main repository.

R.,
Thomas

[Evert van Es]

Thomas,

I have a 4 button remote working and a window sensor.

project is getting a little messy, need to cleanup later.

thanks Evert

[Thomas Eichstädt-Engelen]

Guys,

i've added issue http://code.google.com/p/openhab/issues/detail?id=290 to centralise the binding (and lib) discussions. It'd be great if you could take care of this issue and make your state of work transparent there.

Thanks for driving the EnOcean topic :-)

Regards,

Thomas E.-E.

--

You received this message because you are subscribed to the Google Groups "openhab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.

[Evert van Es]

I need some help getting the base osgi project up and running. I will post some updates to the project in my personal clone tonight.

For me all this new infrastructure is getting a little overwhelming, hg, git, java, eclipse, osgi and now shared libraries.

I find this is getting in the way of my personal progress. I want/need to get enocean integration working in openhab as quickly as possible and worry about better code sharing later.

Another problem for enocean and rfxcom for the matter is that I do not have alle device types available for testing. This means I can only implement code for the devices I have and others will need to add code for their devices. How do we tackle this problem?

Thanks Evert

[Thomas Letsch]

HI Evert,

sorry that I couldn't help lately. With two projects, an ill wife, and
two kiddies there is not much room for open source some time. That will
change soon and I would like to participate again intensively.

How about a session where we try to solve all your infrastructure
problems. E.g. with chat or even audio. That should be quite efficient.
I should have time next week in the evenings.

R.,
Thomas

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "openhab" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/openhab/ETYu-zsAXX8/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to

[Evert van Es]

Thomas, thanks for the offer.

Yesterday I finally got the binding to compile, I am now looking around your basic classes to see what goes where.

Maybe I can get this working. I will update when I make some progress.

I hope you getting time for OSS is because your wife is getting better.

Good luck,

Evert


Verstuurd vanaf mijn iPhone

[Thomas Letsch]

HI Evert,

yes everything is fine again.

And I finally got time to test your code changes and I can receive packages! The button from the ESK works quite well, even though I didn't pair anything.This is really cool!!!

Now I have to have a closer look at the structures and design. The code is indeed getting a little bit messy. Since my original idea of reading the bytes inside the Package classes doesn't work (I have to admit this :-) we should think about something else. Like factories for all kinds of packages.

If you are currently not working on the project, I would now rename the package names to a better naming. E.g. org.enocean.java (a domain which we unfortunately don't own) or com.google.code.enocean

Regards,
Thomas

[Evert van Es]

Thomas, I must admit to having a lot of trouble getting the osgi part working, which is very frustrating to me. I will checkin my progress but would greatly appreciate some support on getting the basic osgi working. I look forward to integrating the enocean stuff bit debugging maven, java, git is a little off putting.. The limited time I have is spent on the wrong subjects...

I will send you updates in a few minutes on my checkin.

Thanks Evert

Verstuurd vanaf mijn iPhone

[Evert van Es]

please see my latest checkin on https://code.google.com/r/evertvanes-openhab/source/checkout

[Evert van Es]

We have some success here.

Window contact and 4 button remote now work correctly. See the following log entries:

19:24:11.793 INFO  o.o.b.e.i.b.EnoceanSerialConnector[:244] - 1BS 00.00.D9.AB, Learn Button Not Pressed, Contact Closed

19:24:11.793 INFO  runtime.busevents[:46] - Door_Garden state updated to CLOSED

in my items file I have the following entry:

Contact Door_Garden  "Garden door [MAP(en.map):%s]" (gGF, Windows)  { enocean="00.00.D9.AB" }

Enocean uses a four byte identification. "00.00.D9.AB" is the device id.

My remote has four buttons with 2 pairs, A-on, A-off, B-on and B-off. I now define my items as follows:

Switch Enocean4ButtonA  "RemoteA" (gGF) { enocean="00.8B.78.14:A" }

Switch Enocean4ButtonB  "RemoteB" (gGF) { enocean="00.8B.78.14:B" }

now we need to add some real switches for enocean!

cheers, Evert

[Thomas Letsch]

Hi Evert,

you rock! That's great news. My first device to support be a temperature sensor. Still have to figure some things out, but we get there.

R.,

Thomas

[Andreas]

Does this EnOcean binding support the (USB?) dongle only? I have a Thermokon STC-Ethernet gateway running for EnOcean.

Cheers,

Andreas

[Evert van Es]

Currently dongle only.

But I do favour an Ethernet solution, so maybe in the future? 

Verstuurd vanaf mijn iPhone

--

[Thomas Letsch]

We had already some discussion about the Ethernet Gateway. I am very confident that the packet content is the same and that means we could support that in very short time. But that has to be proven still (or asking the manufacturer).

[Kai Kreuzer]

I remember some discussions between Karel and Victor that the Thermokon gateway had a much "higher-level" interface than the USB dongle - so I wouldn't expect it to be similar.

You received this message because you are subscribed to the Google Groups "openhab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.

[Thomas Letsch]

BTW there are some news:

I was heavily working on the integrating Everts work into the structure with separate library and binding. Also did some major refactorings and cleanup (Evert: hope you don't mind).

I have a version now that can read temperature and handle button switches. Extending them should be quite easy, since the code is now adopted to the EnOcean profile system.

The java-enocean-library is a osgi plugin project now and integrates therefore nicely with the enocean binding. At least it runs that way in my eclipse (import the binding and the library into eclipse and select them in the OpenHAB runtime launch config.

The new item definition needs more information:

<device_id>#<EEP (EnOcean Equipment Profile)>#PARAMETER_ID

The EEP is used that the knows which data arrives ind what format, the PARAMETER_ID is used to distinguish more than one value of the same device (e.g. temp and humidity). 

@Evert: I try to write a more detailed description about the code and put in some javadocs. Needs some time still.

R.,
Thomas

[Thomas Letsch]

Yes, I remember that as well. I know that you don't need to do all steps in the communication flow if you use the ethernet gateway. AFAIR (please correct if wrong) nobody talked in detail about what kind of protocol it uses.

[Thomas Letsch]

And more success with EnOcean binding:

09:31:35.936 INFO  org.enocean.java.ESP3Host[:57] - RadioPacketRPS[header=Header: dataLength=7, optionalDataLength=7, packetType=1, crc8h=122, payload=Payload: data=[F6, 10, 00, 89, 01, 76, 20], optionaldata=[01, FF, FF, FF, FF, 34, 00], crc8d=70], raw=[55, 00, 00, 07, 01, 6C, 01, FF, FF, FF, FF, 34, 00, 1E], [sender=00:89:01:76, repeaterCount=0]

09:31:38.348 DEBUG o.o.b.e.i.bus.EnoceanBinding[:214] - Received new value Pressed for device at EnoceanParameter: 00:89:01:76#BUTTON_A_DOWN

09:31:47.783 DEBUG o.o.b.e.i.bus.EnoceanBinding[:223] - Received new value ON for item PushButtonADown (Type=SwitchItem, State=Uninitialized)

09:31:47.791 INFO  runtime.busevents[:46] - PushButtonADown state updated to ON

09:31:58.997 INFO  org.enocean.java.ESP3Host[:57] - RadioPacket4BS[header=Header: dataLength=10, optionalDataLength=7, packetType=1, crc8h=-21, payload=Payload: data=[A5, 00, 00, 7D, 00, 00, 82, 90, 1D, 00], optionaldata=[01, FF, FF, FF, FF, 2E, 00], crc8d=88], raw=[55, 00, 00, 07, 01, 6C, 01, FF, FF, FF, FF, 2E, 00, CB], [sender=00:82:90:1D, repeaterCount=0], [db0=00, db1=7D, db2=00, db3=00, teachIn=false]

09:31:59.001 INFO  org.enocean.java.ESP3Host[:25] - Received RadioPacket with values {TEMPERATURE=20.4°C}

09:32:01.902 DEBUG o.o.b.e.i.bus.EnoceanBinding[:214] - Received new value 20.4°C for device at EnoceanParameter: 00:82:90:1D#TEMPERATURE

09:32:01.906 DEBUG o.o.b.e.i.bus.EnoceanBinding[:223] - Received new value 20.4 for item WorkTemp (Type=NumberItem, State=Uninitialized)

09:32:01.908 INFO  runtime.busevents[:46] - WorkTemp state updated to 20.4

09:32:22.072 INFO  org.enocean.java.ESP3Host[:57] - RadioPacketRPS[header=Header: dataLength=7, optionalDataLength=7, packetType=1, crc8h=122, payload=Payload: data=[F6, 70, 00, 22, 5B, FB, 30], optionaldata=[01, FF, FF, FF, FF, 47, 00], crc8d=86], raw=[55, 00, 00, 07, 01, 6C, 01, FF, FF, FF, FF, 47, 00, 83], [sender=00:22:5B:FB, repeaterCount=0]

09:32:22.073 INFO  org.enocean.java.ESP3Host[:25] - Received RadioPacket with values {BUTTON_B_UP=Pressed}

09:32:22.074 DEBUG o.o.b.e.i.bus.EnoceanBinding[:214] - Received new value Pressed for device at EnoceanParameter: 00:22:5B:FB#BUTTON_B_UP

09:32:22.074 DEBUG o.o.b.e.i.bus.EnoceanBinding[:223] - Received new value ON for item RockerSwitchBUp (Type=SwitchItem, State=Uninitialized)

09:32:22.075 INFO  runtime.busevents[:46] - RockerSwitchBUp state updated to ON

09:32:22.295 INFO  org.enocean.java.ESP3Host[:57] - RadioPacketRPS[header=Header: dataLength=7, optionalDataLength=7, packetType=1, crc8h=122, payload=Payload: data=[F6, 00, 00, 22, 5B, FB, 20], optionaldata=[01, FF, FF, FF, FF, 4A, 00], crc8d=-14], raw=[55, 00, 00, 07, 01, 6C, 01, FF, FF, FF, FF, 4A, 00, 6A], [sender=00:22:5B:FB, repeaterCount=0]

09:32:22.296 INFO  org.enocean.java.ESP3Host[:25] - Received RadioPacket with values {BUTTON_B_UP=Released}

09:32:22.297 DEBUG o.o.b.e.i.bus.EnoceanBinding[:214] - Received new value Released for device at EnoceanParameter: 00:22:5B:FB#BUTTON_B_UP

09:32:22.298 DEBUG o.o.b.e.i.bus.EnoceanBinding[:223] - Received new value OFF for item RockerSwitchBUp (Type=SwitchItem, State=ON)

09:32:22.299 INFO  runtime.busevents[:46] - RockerSwitchBUp state updated to OFF

the items look like:

Switch RockerSwitchBUp "Work button " () {enocean="00:22:5B:FB#F6:02:01#BUTTON_B_UP"}

Switch RockerSwitchBDown "Work button "  () {enocean="00:22:5B:FB#F6:02:01#BUTTON_B_DOWN"}

Switch RockerSwitchAUp "Work button "  () {enocean="00:22:5B:FB#F6:02:01#BUTTON_A_UP"}

Switch RockerSwitchADown "Work button " () {enocean="00:22:5B:FB#F6:02:01#BUTTON_A_DOWN"}

Switch PushButtonAUp "Work button " () {enocean="00:89:01:76#F6:02:01#BUTTON_A_UP"}

Switch PushButtonADown "Work button " () {enocean="00:89:01:76#F6:02:01#BUTTON_A_DOWN"}

Number WorkTemp "Work Temperature [%.1f °C]" <temperature> () {enocean="00:82:90:1D#A5:02:05#TEMPERATURE"}

R.,
Thomas

Am Montag, 20. Mai 2013 20:22:00 UTC+2 schrieb Thomas Letsch:

[Evert van Es]

Thomas,

Excellent! I look forward to working with your code.

Evert

Verstuurd vanaf mijn iPhone

--

[Evert van Es]

Thomas,

I read your implementation of the device mapping and have some questions and idea's:

{enocean="00:22:5B:FB#F6:02:01#BUTTON_B_DOWN"}

First of all, I started with the four byte id seperated by a colon, e.g. 00:22:5B:FB

In my implementation I decided against it because in other openhab bindings the colon is used as a seperator, I preferred a dot as a seperator, reading 00.22.5B.FB. I also looked at other enocean projects and they just use the direct hex representation: 00225BFB, which I find a little long and hard to read. Not a good idea in my mind.

I also started with all kinds of coding after the deviceid, but again reasoned it would be easier to configurate for beginners if the coding was as simple as possible. I find that the identification of some devices can be done just based on the message that arrives. I would therefore make configuration as minimal as possible.

How about adding optional EEP information to the coding in a format like:   

{enocean="00.22.5B.FB:EEP=F6.02.01"}

EEP only has meaning if the functionality is different when the message is different for specific EEP's.

And on your last parameter "BUTTON_B_DOWN", I am not inclined to use words like Button and Down. The documentation speaks of Rocker Switch, Position Switch, Button and Handle. Also Down implies Up, but there is not a clear Button Up command. There is a button Press with identification of which button, with multiples possible and a general release when we talk about a Rocker Switch. Even if we did define a parameter BUTTON_B_DOWN and a parameter RELEASE, I find it difficult to imagine this working in a rule. But then again, the data is there, so perhaps we should implement the messages and let the interpreting to the users.

I would favor the parameters to read like the documentation: Button ids are: AI, A0, BI, B0, CI, C0 , DI, D0, where I means On and 0 means Off. And the actions are Pressed and Released. So I could imagine AI_PRESSED and RELEASED being good messages. But do we need pressed and released? We do have state in openhab. The switch item knows if it is On or Off, so can we just use AI and A0. We would then need to send the Off command to each sub device on a release message.  This would make config a lot easier:

{enocean="00.22.5B.FB:AI"}

or
{enocean="00.22.5B.FB:EEP=F6.02.01:BI"}

For the window handle we would need to think of some coding, the documentation only has pictures...

Thomas, currently I have little time, but in which repository can I find the code?

thanks 

Evert

[Thomas Letsch]

Hi Evert,

this is a very interesting discussion!

Am 27.05.2013 21:05, schrieb Evert van Es:

Thomas,

I read your implementation of the device mapping and have some questions and idea's:

{enocean="00:22:5B:FB#F6:02:01#BUTTON_B_DOWN"}

First of all, I started with the four byte id seperated by a colon, e.g. 00:22:5B:FB

In my implementation I decided against it because in other openhab bindings the colon is used as a seperator, I preferred a dot as a seperator, reading 00.22.5B.FB. I also looked at other enocean projects and they just use the direct hex representation: 00225BFB, which I find a little long and hard to read. Not a good idea in my mind.

I also started with all kinds of coding after the deviceid, but again reasoned it would be easier to configurate for beginners if the coding was as simple as possible. I find that the identification of some devices can be done just based on the message that arrives. I would therefore make configuration as minimal as possible.

How about adding optional EEP information to the coding in a format like:   

{enocean="00.22.5B.FB:EEP=F6.02.01"}

EEP only has meaning if the functionality is different when the message is different for specific EEP's.

I agree with you that moving from ":" to "." is a good idea. Then we are conform to the other bindings.
For the EEP parameter: My expectation is the same, I think we won't need the EEP for all devices. My first thought was to just skip the EEP part and recognize that during parsing by counting the amount of parts when splitting. Actually thats very error prone, so your idea sounds better. Its hard to put much information in a readable way into that kind of one-liner. How about taking your idea another step forward by writing a JSON like one - liner?
enocean="{"id"="00.22.5B.FB", "EEP" = "F6.02.01", "PARAMETER" = "..."}. Still easy to write and kind of better to read (could skip the ").

And on your last parameter "BUTTON_B_DOWN", I am not inclined to use words like Button and Down. The documentation speaks of Rocker Switch, Position Switch, Button and Handle. Also Down implies Up, but there is not a clear Button Up command. There is a button Press with identification of which button, with multiples possible and a general release when we talk about a Rocker Switch. Even if we did define a parameter BUTTON_B_DOWN and a parameter RELEASE, I find it difficult to imagine this working in a rule. But then again, the data is there, so perhaps we should implement the messages and let the interpreting to the users.

I would favor the parameters to read like the documentation: Button ids are: AI, A0, BI, B0, CI, C0 , DI, D0, where I means On and 0 means Off. And the actions are Pressed and Released. So I could imagine AI_PRESSED and RELEASED being good messages. But do we need pressed and released? We do have state in openhab. The switch item knows if it is On or Off, so can we just use AI and A0. We would then need to send the Off command to each sub device on a release message.  This would make config a lot easier:

{enocean="00.22.5B.FB:AI"}

or
{enocean="00.22.5B.FB:EEP=F6.02.01:BI"}

For me this is not so easy to read and write. You have to know the EEP, which you probably won't as an OH user. I would really like to use some known names.
Actually I oriented the names a little bit at the homematic internal names. A BUTTON is very easy to understand (as is a SWITCH) and very generic. If we stick more to the EEP I propose to name it ROCKER_SWITCH or just SWITCH.
I chosed UP and DOWN because that is the common position of the switches (at least for the country they are intended to). Perhaps that is not as unique as I hoped. I would still prefer a name which a user can easily understand. I and O are IMHO very artificial. How should a user know which switch is the I one and which the O? We would have to write something like "the I switch is on the upper side and the O on the lower side" - then we can also choose UP and DOWN ;-)
Perhaps we should discuss more possibilities here? ON/OFF?

And another thing that came to me from the homematic binding:
They speak about channel in HM. The EEP also speaks about channel A and channel B. In homematic the channel has its own position in the address, we could do the same:
enocean="{id="00.22.5B.FB", EEP = "F6.02.01", CHANNEL = "B", PARAMETER = "ON"}

The good thing is that the addressing part is encapsulated in the EnoceanParameterAddress. We can change things easily there.

Its probably better to send the PRESSED / RELEASED information with an item update. Other wise you rely that OH always knows the actual state. For rocker switched that is probably most of the time true, but for normal switches it isn't. Really would prefer a way to handle rocker switches and normal one equally.  As you stated: openhab knows states and the rocket switch does. That just seems like a good fit...

For the window handle we would need to think of some coding, the documentation only has pictures...

ok. Have to have a look at it still.

Thomas, currently I have little time, but in which repository can I find the code?

Binding:
https://code.google.com/p/openhab-enocean/

Java Library:
https://code.google.com/p/java-enocean-library/


R.,
THomas

[Karel Goderis]

>
> And on your last parameter "BUTTON_B_DOWN", I am not inclined to use words like Button and Down. The documentation speaks of Rocker Switch, Position Switch, Button and Handle. Also Down implies Up, but there is not a clear Button Up command. There is a button Press with identification of which button, with multiples possible and a general release when we talk about a Rocker Switch. Even if we did define a parameter BUTTON_B_DOWN and a parameter RELEASE, I find it difficult to imagine this working in a rule. But then again, the data is there, so perhaps we should implement the messages and let the interpreting to the users.
>
> I would favor the parameters to read like the documentation: Button ids are: AI, A0, BI, B0, CI, C0 , DI, D0, where I means On and 0 means Off. And the actions are Pressed and Released. So I could imagine AI_PRESSED and RELEASED being good messages. But do we need pressed and released? We do have state in openhab. The switch item knows if it is On or Off, so can we just use AI and A0. We would then need to send the Off command to each sub device on a release message. This would make config a lot easier:

Mmh.... just as a side note, maybe a bit off-topic: don't assume that the state in OH is always the same as the physical state in the "real world". I came across a similar issue in one of the bindings I made (think Plugwise). You either assume that when you send a message over the radio (!) network, that the physical switches, and that you can update your OH item accordingly. Or, if you really want to be sure, you want to wait for an answer from the network, or you poll the status of the physical item, and then update the OH item to the desired state. I don't have any experience with enOcean in the real world, but at least with the ZigBee mesh used by the plugwise devices, I opted for the option to poll for the actual state.

Regards
K

[Thomas Letsch]

Hi Karel,

Mmh.... just as a side note, maybe a bit off-topic:  don't assume that the state in OH is always the same as the physical state in the "real world". I came across a similar issue in one of the bindings I made (think Plugwise). You either assume that when you send a message over the radio (!) network, that the physical switches, and that you can update your OH item accordingly. Or, if you really want to be sure, you want to wait for an answer from the network, or you poll the status of the physical item, and then update the OH item to the desired state. I don't have any experience with enOcean in the real world, but at least with the ZigBee mesh used by the plugwise devices, I opted for the option to poll for the actual state.

I have implemented the same for the homematic binding. It perfectly makes, but EnOcean is unfortunately a little bit different. To save energy, some devices do not send updates regularly or act as a message receiver (switches are one of these). They only have the energy they get from button press and that just is enough for sending out two frames (button pressed, button released). Energy harvesting is still not very effective :-)

R.,
Thomas 

[Karel Goderis]

Fair point

Some time ago I saw some enocean devices with little voltaic cells embedded though. 

I can imagine that in some applications one will be clicking like a madman :-) I hope the reach and reliability of enocean networks is reasonable...

K

Sent from my iPhone

--

You received this message because you are subscribed to the Google Groups "openhab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

Visit this group at http://groups.google.com/group/openhab.

[Thomas Letsch]

Hi Evert,

I added support for contact switches (D5:00:01) in the java library. Since I don't have such a device, perhaps you can test it?

Have top add the converter mapping into the binding still.

R.,
Thomas 

[Thomas Letsch]

Hi Evert,

there was a long time no real update on the EnOcean side. Hope you are still playing with it.

I was quite busy the last days to get the EnOcean binding in its limited ways ready for openhab review. And also my house rework is coming to an end and need it working for switches and temps :-)

I hope you could check the code / binding and give me some feedback. Any other testers / coders out there?

I agree with you that moving from ":" to "." is a good idea. Then we are conform to the other bindings.

After switching to JSON like format, I came back to like more the ":" ways :-). I took the idea from MAC addresses (which are quite similar) and still find it quite readable. The other bindings use a lot different chars as seperators (":", "#", ",", "+" etc.). Since we will use the JSON like syntax, there should be no confusion. If you really see it as a problem, we can of course change it.

 

enocean="{"id"="00.22.5B.FB", "EEP" = "F6.02.01", "PARAMETER" = "..."}. Still easy to write and kind of better to read (could skip the ").

Did it and like it :-). See https://code.google.com/p/openhab-enocean/wiki/EnOcean_Binding for examples.

 

Perhaps we should discuss more possibilities here? ON/OFF?

Actually after thinking more about it, I agree with you. The parameters are now named "I" and "O" (A/B/C etc. are channels).

 

Its probably better to send the PRESSED / RELEASED information with an item update. Other wise you rely that OH always knows the actual state. For rocker switched that is probably most of the time true, but for normal switches it isn't. Really would prefer a way to handle rocker switches and normal one equally.  As you stated: openhab knows states and the rocket switch does. That just seems like a good fit...

Implemented that partly, at least pressed is working quite well. See for yourself.

 

For the window handle we would need to think of some coding, the documentation only has pictures...

I implemented a first version, but of course with out hardware unable to test it. Perhaps you wanna give it a try.

 

Binding:
https://code.google.com/p/openhab-enocean/

Java Library:
https://code.google.com/p/java-enocean-library/

Still the same repositories. The binding now contains the the jar file generated from the java-enocean-lib. In this way it is easier to deploy. For development, I normally switch back to a OSGI dependency from the enocean-binding to the java-enocean-lib project.

I would love to have the binding ready for introduction into OH 1.3. Perhaps you could give it a try. 

You can download a binary from http://thomas-letsch.de/org.openhab.binding.enocean-1.3.0-SNAPSHOT.jar. Again, see https://code.google.com/p/openhab-enocean/wiki/EnOcean_Binding for details.

R.,
Thomas

 

[Evert van Es]

Thomas,

Its been murder at the office these last months. My enocean devices work just fine with my coded plugin. I seem to dread next revision of openhab due to all these rogue repositories. Can't say I like the distributed model much....

Will go on holiday this week. Sorry I don't have the time to look at code the next few months...

Project has not lost my interest, will get back to it as soon as I have time.

Good luck with your house Thomas !!

Verstuurd vanaf mijn iPhone

--

You received this message because you are subscribed to a topic in the Google Groups "openhab" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/ETYu-zsAXX8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

Visit this group at http://groups.google.com/group/openhab.

[Evert van Es]

Thomas, I just downloaded and tried 1.3.1 version

Unfortunately the window contacts do not work.

In my config I defined the following:

Contact Window_GF_Tuin "Tuindeur [%s]" (gGF, Windows) { enocean="id=00:00:D9:AB, eep=D5:00:01, parameter=CONTACT_STATE" }

and this is the result when the contact switch changes:

20:30:01.692 ERROR org.enocean.java.ESP3Host[:82] - Error

java.lang.ArrayIndexOutOfBoundsException: 1

at org.enocean.java.packets.RadioPacket1BS.getDataByte(RadioPacket1BS.java:21)

at org.enocean.java.packets.RadioPacket1BS.toString(RadioPacket1BS.java:26)

at org.enocean.java.ESP3Host.run(ESP3Host.java:76)

at java.lang.Thread.run(Thread.java:680)

20:30:04.121 ERROR org.enocean.java.ESP3Host[:82] - Error

java.lang.ArrayIndexOutOfBoundsException: 1

at org.enocean.java.packets.RadioPacket1BS.getDataByte(RadioPacket1BS.java:21)

at org.enocean.java.packets.RadioPacket1BS.toString(RadioPacket1BS.java:26)

at org.enocean.java.ESP3Host.run(ESP3Host.java:76)

at java.lang.Thread.run(Thread.java:680)

I also found that my rocker switch no longer works. I do not understand your definition of parameter I and O with a Switch. A switch has two states but the rocker, does not. I understand your interpretation of the roller shutter item, but I would expect the switch to turn to state ON when the upper rocker is pressed and to have the state off when the down rocker is pressed. This is a different model to what you have defined. I will try and go with the dimmer option because this seems more like the behavior I am looking for.

Thanks for the good work.

Sorry I am unable to tinker with the code...

Evert 

 

[Thomas Letsch]

HI Evert,

thanks for the hint. Another user also told me about. Its fixed in my clone and I will try to get it into OH when they are on github...

I will update the Wiki for now.

R.,
Thomas

Am Sonntag, 22. September 2013 20:41:09 UTC+2 schrieb Evert van Es:

Thomas, I just downloaded and tried 1.3.1 version

Unfortunately the window contacts do not work.

Nachricht auf Deutsch übersetzen   

[Evert van Es]

Super, could you send me a jar to test?

Thanks Evert

Verstuurd vanaf mijn iPhone

--

[Kai Kreuzer]

 and I will try to get it into OH when they are on github...

We already are!

[Thomas Letsch]

Yes, seen it and forked it!
@evert: I will prepare a bin...

Kai Kreuzer <k...@openHAB.org> schrieb:

 and I will try to get it into OH when they are on github...

We already are!

G.,
Thomas

[leboycote]

Hello,

I'm new to EnOcean.

For my studies (Home Automation Degree), i'm trying to build a little software, based on Raspberry PI, to manage EnOcean Devices.

That's why i'm interested in the java-enocean-library.

It has been a long time since somebody has post a message to this forum regarding this topic !? Is this project still relevant ?

Could somebody give some news about the project ?

Thank in advance and sorry for my bad English....

Best Regards.

Michel.

Le mardi 24 septembre 2013 08:37:02 UTC+2, Thomas Letsch a écrit :

Yes, seen it and forked it!
@evert: I will prepare a bin...

Kai Kreuzer <> schrieb:

 and I will try to get it into OH when they are on github...

We already are!

G.,
Thomas

[Thomas Letsch]

Hi Michel,

yes it has been quite calm around the enocean library and binding. But they are not dead, there are quite some people using them (including myself :-). Just that time is limited and so progress was very little in the last moths. 

To simplify things, I created a discussion group for the Enocean Library (https://groups.google.com/forum/#!forum/java-enocean-library). So if you have questions about the library post it there, if you have questions about the openhab binding, this group is best choice.

Regards,

Thomas

[rahul...@gmail.com]

Hi,

I am new to openhab and enocean. I am tryin to bind enocean using openhab in windows, but i am not able to detect it for some reason :(

Heres the excerpt from my items file

Switch EnOceanI () {enocean="{id=FE:FF:98:2B, eep=F6:02:01, channel=A, parameter=I}"}

And my rule,

rule "EnOcean"

when 

    Item EnOceanI received update 

then

    say("EnOcean Connected")

end

Could some one tell me what I am doing wrong here? Any help is appreciated. :( :(

Thanks

Rahul

[Petr Klus]

Slightly off topic, but I am very interested in using EnOcean for some sensors and switches. What is your experience - are they reliable enough for light switches etc? What kind of starter-kit would you recommend to get 3-4 light switches going? 

[Thomas Letsch]

Hi Rahul,

please check your openhab log file if it say something about the EnOcean binding and post it. There should be some message about the binding if it is active. If you don't see anything with enocean, try the start_debug script.

R.,
Thomas

[Thomas Letsch]

Hi Petr,

I use EnOcean switches to control dimmable lights (dimmer from Homematic) and for controlling roller shutters. The switches don't have a very big working radius, in my case a big wall (ceiling) and about 5 meters are almost the limit. But they are otherwise quite reliable. Sometime the first button press is not recognozed, but I still don't know if it is an error of the binding or the hardware :-)

R.,

Thomas

Am Montag, 12. Mai 2014 14:35:21 UTC+2 schrieb Petr Klus:

[Thomas Letsch]

and some temperature sensors, I forgot. They have also a very limited range...

[Petr Klus]

Thank you Thomas!

I think this would not be a good fit for me - I suppose I would need multiple devices to cover my flat, so I guess I will go for zwave..

Best,

Petr

[Thomas Letsch]

HI Petr,

yes, thats probably the price of being batterie-less. For me it works quite well now, the enocean usb stick is situated directly in the middle of the house :-).

R,
Thomas

[thoern....@gmail.com]

Hello Gents,

I would appriciate, if support for the combined temperature and humidity sensor (STM 330 + HSM 100) could be implemented. The EEP is A5:04:01

Further information:
http://www.enocean.com/en/enocean_modules/hsm-100/
http://www.enocean.com/en/enocean_modules/stm-330/

Also support for the Hoppe window handle would be great.

I openend 2 issues for these enhancements (1097 and 1098):
https://github.com/openhab/openhab/issues/1097
https://github.com/openhab/openhab/issues/1098

Regards,
Thomas

[gilles.l...@gmail.com]

Hi Thomas,

I want to use my window contacts, I can see windows contact working in debug log but the binding don't work.

Sorry but the syntax in the wiki is incomplete.  Is this:

Contact test_Window "" (gGF, test) { enocean={id=00:8A:DA:DE, eep=D5:00:01, parameter=CONTACT_STATE}} or what else. Gilles.

[gilles.l...@gmail.com]

Ok I confirm it's working and the right syntax for binding is:

{ enocean="{id=00:8A:DA:DE, eep=D5:00:01, parameter=CONTACT_STATE}" }

For others, my mistake is not to add accolade inside general accolade. This behaviour isn't the same as others bindings and can be confused.

So I can See "Open" or "close" for my door sensor on a string format.

Gilles.

[pascal....@gmail.com]

I made this support see here http://www.element14.com/community/community/design-challenges/forget-me-not/blog/2014/08/17/pas-home-openhab-hsm-100-humidity-sensor

[gilles.l...@gmail.com]

Hi,

I use enocean conact state, it's working in log in debug mode whereas in site map there are no information.

Is this a bug or there is something to do for door contact in sitemap.

Gilles.

[Evert van Es]

Strange, I do see contact state. What version are you using?

Verstuurd vanaf mijn iPhone

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/ETYu-zsAXX8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.

For more options, visit https://groups.google.com/d/optout.

[Gilles L]

I use 1.51. I think I found the problem. I use Habmin to manage my sitemap. It's fully working with modifying sitemap file by hand. If I do a modification with habmin, the format go away. I don't touch anything until tomorrow, and will tell you if it's ok.

[gilles.l...@gmail.com]

It's ok I don't touch anything, and I can get my contact door state since last night.

Now I have to search when Habmin save or not the string format.

Thank you.

Gilles.

[Marc]

Hello,

I am quite new with OpenHab. I am currently struggling with my EnOcean Contacts.

They are using a different EEP and producing values Up, Down, Middle which I can see in Debug modus but no status is shown in the App.

I am using following config

Contact Fenster "Fenster [MAP(de.map):%s]" <contact> (All) {enocean="{id=00:14:94:19, eep=F6:10:00, parameter=CONTACT_STATE}"}  

In the sitemap I have

Text item=Fenster  

In the log I have the following:

11:07:48.377 [INFO ] [opencean.core.eep.WindowHandle:52   ] - Current window handle: 00:14:94:19, position: Middle

11:07:48.380 [INFO ] [org.opencean.core.ESP3Host    :15   ] - Received RadioPacket with value Middle

11:07:48.384 [DEBUG] [.e.internal.bus.EnoceanBinding:276  ] - Received new value Middle for device at EnoceanParameter: {id="00:14:94:19", parameter="CONTACT_STATE"}

11:07:48.390 [WARN ] [b.e.i.profiles.StandardProfile:72   ] - No converter found for EnoceanParameter: {id="00:14:94:19", parameter="CONTACT_STATE"} - doing nothing.

I only get that warning No converter found for EnoceanParameter. What dies it mean?

The EnOcean contacts are Hoppe SecuSignal.

Is it an issue of OpenHab or I am just not founding my mistake?

Thanks!

[Sabrina]

Hello everybody,

Glad to find this discussion!

I managed to connect my rocker switches, my tempurature sensors and my contact sensor to OpenHab

And I want to know if the following profils (occupancy and dimmers with Energy Measurement and Local Control) are also supported:

*EEP: A5-07-01

*EEP: D2.01.08

and if not, can you help me with impIementing a support for them?

Are there steps that I can follow to update the OpenHab EnOcean binding to be able to support a new profile?

Thanks a lot!