Can someone point me at a complete guide on how to make the EnOcean binding (OH1 1.9.0) work with OH2 under Ubuntu 14? I’ve installed it using Paper UI, I’ve set up serialPort=/dev/ttyUSB0 in conf/services/enocean.cfg, and the logs show that EnOcean is connecting to /dev/ttyUSB0.
But nothing is happening. My existing devices, which worked with exactly the same hardware under OH1, have no effect: nothing appears in openhab.log or events.log, and no events are triggered.
I have even passed “-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0” to the JVM at start up. But there is no sign of EnOcean doing anything anywhere.
Apart from saying that the EnOcean binding is installed, Paper UI shows no information about EnOcean or its Things.
I’m obviously missing something, and I’ve reached the end of my Googling capabilities. Can anyone help me please?
I don’t know enocean specifically but you did not mention creating any Items. Only OH 2 bindings have anything t do with Things. For 1.9 bindings you need to create Items just as you always have.
If they don’t show up in Habmin that implies the .items files are not being
loaded. Have you confirmed that the file with the enocean Items in it is
being loaded by OH? In openhab.log you should see Loading model 'alarm.items' followed by Refreshing model 'alarm.items' (obviously with
it listing your .items file instead of alarm.items) and you should not see
any errors.
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
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.
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.
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.
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.
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.
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.
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.
