OH2 and EnOcean?

Items are being loaded alright (no error messages). I’m beginning to think there is something fundamentally wrong with my installation: other things are not working either (e.g. rules involving non-EnOcean Things).

I have a particular problem: it is getting cold here (summer has been suddenly replaced by autumn) and my heating isn’t working (not to mention parts of my lighting). So I think I’m going to have to shelve the upgrade to OH2 and go back to OH1.

That would be a shame, especially with OH2 final around the corner.

No personal experience with EnOcean but looking at the wiki article, some ideas:

  • Did you set your serial port through the configuration file? You need to create /etc/openhab2/services/enocean.cfg containing “serialPort=/dev/ttyUSB0” or similar (without “enocean:”)

  • Please increase the log level of the enocean binding to DEBUG as described here - then look at your logfile

Hi Thom

Thanks, I’ve done both of those things right from the start.

As I said, I think there’s a fundamental problem and not just EnOcean. The rules I imported from OH1 are not working (they are producing Java stack dumps) because of a global Item. In fairness, the SmartHome Designer complains about the global Item too, but it was no problem in OH1.

Oh, too bad.
I’m still convinced that it should work.

Would you be okay to start with a fresh setup? Errors by not working rules and other bindings might be in your way of finding the EnOcean problem.
Clean your installation, then add the enocean binding through addons.cfg, increase the log level of this binding, add the enocean.cfg file, add one item, add this one item to a sitemap so you have easy access to it. While this whole process, have a console with both log files open http://docs.openhab.org/installation/linux.html#viewing-log-messages

I’ll think about what you suggest (the cold has made me hungry and I need to go and eat).

What I am currently observing (using ssh openhab@localhost -p 8101) is:

  • Homematic Things are being logged as they change
  • no trace of EnOcean, but there are no EnOcean Things, of course (because it’s OH1)
  • rules when system started are firing
  • rules when Item xxx changed are not firing

I conclude that that the Items are not connected to the Things. I haven’t changed the Item files (i.e. I still have the OH1 definitions). I didn’t think I had to change the Item files. Is that the problem? That still doesn’t help with the EnOcean stuff, of course.

Have a look at the Migration tutorial:

You can and probably should for now just stick with the 1.9 bindings instead of the 2.0 version of the bindings. That will work like and behave more like what you are coming from. Once it works that way gradually migrate to those bindings for which there is a 2.0 version one at a time.

Minimize the amount of change you are introducing at the same time so errors are easier to identify.

A couple of things you mentioned do raise questions/concerns:

Things are a way to map openHAB Items to devices. They are essentially the equivalent to the stuff you put inside the { } in the old openHAB 1.x Item config. I don’t think you can directly refer to Things within your Rules. And even if you can I don’t think that would be considered a best practice. You should only be referencing Items inside your Rules.

Do you mean a “global variable?” What is the error, it could be relevant. It could also be the case that the OH 2 rules engine is less tolerant of such errors, particularly if it occurs when loading/parsing the rules file.

At all or just EnOcean triggered rules?

Things are only relevant for OH 2.0 bindings. If you are using OH 2.0 bindings (e.g. it sounds like you are for Homematic) you must change the stuff in the {} of your Items to be

channel="<channel ID>"

The channel ID can be obtained from PaperUI or the Karaf console. See the migration tutorial above for where to look.

For 1.9 bindings, you should be able to leave your Item definitions unchanged.

Hi Rich

Thanks for all this. I think this may solve my problems. I hadn’t realised that I had to change the ‘{}’ stuff in Items.

My current theory:

Since all my EnOcean connections occur in '{}'s, ...
* EnOcean appears not to be working;
* the Homematic Items are so connected to the Homematic Things;

Since the Items are not set up properly the rules don't fire.

The problem with the “global” Item has gone away in the log files, though it still exists in the Designer. It really is an Item:

Number House_Heating_Default "Default Temperature [%.1f °C]" <temperature>   (Heating)

I’ll go and try all this out and report back. If EnOcean doesn’t miraculously start working as a by-product, I’ll try Thom’s suggestion about starting with a fresh installation.

Now I really am confused. You are defining an Item in a .rules file?

@stephen_winnall I’m a bit confused too :smiley:
Regarding your homematic setup may I point you to my (working) setup: 1, 2.

That’s all for now, I’m waiting for your update.

No, the Item is defined in an .items file, but is referred to in the .rules file (hence it is “global”).

By that definition all Items referred to in a Rules file are global. So calling it global is meaningless and a little confusing. That is where the confusion on my part came from.

Agreed.

It has taken time (and some cursing) but I have achieved progress.

On the basis of Thom’s configuration I have what appears to be a working Homematic configuration. My Hue stuff seems to work too. There’s a load of strange error messages still, but they don’t seem to affect the workings of the overall system. I’ll pursue them later.

But I still wasn’t getting any trace of EnOcean activity in my logs. So I added the line

log4j.logger.org.openhab.binding.enocean = DEBUG

to my ./runtime/karaf/etc/org.ops4j.pax.logging.cfg file and now I get debugging info from the EnOcean binding.

So now to set about debugging my ENOcean stuff… I’ll report back with my results.

Thanks for your help, @rlkoshak and @ThomDietrich.

Lest I forget: THINGS I HAVE LEARNT

Paper UI seems to remember the Things that it discovered previously, even if you declare them explicitly in a .things file. This results in multiple instances for the same Thing. So delete the instances that Paper UI discovered. This makes everything easier to understand: whether it is technically significant, I’m not sure.

It all works at last, including EnOcean.

The EnOcean problem may ultimately have been banal: I’ve recently replaced a plain rocker switch with one labelled O/I, which I mounted in accordance with the label on the back of the switch. I was obviously using the old switch upside-down. Since a single EnOcean switch is really a double with a single rocker, the single rocker only transmits on one EnOcean channel (A or B). The newly mounted rocker uses channel B, whereas I had been using A. I only noticed this after I got the logging working.

So, after I rebooted everything again it all started working nicely. The only problem I have now is that the EnOcean receiver is out of range of some of my switches, but that’s another story.

Thanks once again for your help!

For the Out-Of-Range Problem - my solution:
Eltako Repeater and it works perfektly. :wink:

Hi Hubertus

Thanks for the tip. I’ve already ordered a different one (“Unterputz”) but also from Elatko, I think.

Steve

Hello Stephen,
I don’t want to take over your thread, but as you succeeded in running enocean with openhab2 I hope you can give me a hint what I’m doing wrong:
I have several unidirectional actuators of which I don’t have any IDs.
Under FHEM I could simulate a switch which is sending a command over the Enocean USB.
With that I was able to train the actuators to the Enocean USB Stick.
In FHEM I am not able to adress the actuators directly but I simply send a command like AI and the actuator reacts on that.
Now I’m searching for a solution in Openhab like in FHEM.
I hope I’m on the right way, but actually my actuators don’t react on my commands.

My Enocean USB has the following IDs:
BaseID FFB59680
ChipID 019E6B2D

I made several tests with the item configuration, like this one:
Switch Rocker (All) {enocean="{id=FF:B5:96:80, eep=F6:02:01, channel=B}"}
But the actuators don’t react.

Do you have any idea where to look for the solution.
Unfortunately enocean seems to be not very common in the openhab community…
Thanks in advance,
Patrick

Hi Patrick

Take a look at https://groups.google.com/forum/m/#!topic/openhab/REmsBmOaCyU

Perhaps that will help you.

As I understand it, EnOcean switches don’t have state so they can’t be declared as a Switch in OpenHAB. To make them work you have to associate them with another OH item, as in the given examples (which are Hue _Switch_es).

My interpretation may be wrong, but it helps me to understand how it works! :slight_smile:

Steve

1 Like

Hi Steve,
Thanks for your answer.
Maybe that’s my misunderstanding.
I’ll give it a try.

Greetings,
Patrick