My first steps with OpenHab

Now trying to work out how to add my Enocean sensors

Noticing that a lot has been going on in the Enocean binding, I decided to update OH to get the latest bindings. It turned out to be quite a bit more painful than expected. You get the choice of whether to overwrite the log config file with the new one or keep the modified version. I opted for the new one - I now keep a file with my modifications handy. My redirection of the logs to a USB stick was also overwritten, so I had to fix that. I have a file with a list of any modifications I make to files liable to be overwritten in a update. Then my one and only rule appeared not be working, but the problem turned out to be that the debug log is turned off by default for rules, whereas before it was turned on. This post describes how to modify the log configuration to turn debug logging back on, and also redirects the output to separate files, which is clearer:

Would be perhaps be a good idea to have a separate configuration file for custom additions and overrides to the log configuration, so that the default config can be updated without messing with these customisations?

It would also be a good idea if the update script would kick off the backup script for you :wink:! A persional custom logging configuration has been discussed and will likely be implemented in OH 3.0.

For the helper libraries, you can simply do thisā€¦

log:set DEBUG jsr223

ā€¦ in the Karaf console, which is one of the entries from that post. Iā€™ve also toyed with the idea of adding the log configuration to the Jython addon or into the default logging configuration file.

1 Like

Yes, I see that you can use the console command, but I donā€™t want to have to enter that after every reboot.

Why would you need to? Entering this in the Karaf console will add the entry to your org.ops4j.pax.logging.cfg file. If rebooting is changes the file, then I would think this would also be an issue after manually editing the file.

Ahh, I was under the impression that this command just enables logging for the current session, not that it changes the file. That doesnā€™t seem clear in the documentation.

Both my Enocean sensors are now working - the ElTako light sensor and the Trio2Sys temperature sensor. The Trio2Sys sensor was a bit fiddly because I had to get it down from an awkward spot to press the button. Thank goodness the teach-in telegram for the ElTako is activated by a magnet.
The new Enocean binding is clearly working much better now.

Incidentally, I noticed that the lux values of the ElTako are different from those in the Zipabox. Turns out the Zipabox is interpreting the values incorrectly. :man_facepalming:

So, so far I have:

9 Somfy blinds and awnings
2 Enocean sensors
A 433Mhz temperature sensor
Sonos Connect, Boost and various Play:1s
A Brink Sky 150 ventilation unit via Modbus

The next big target is Z-Wave.

The nice thing is that, so far, Iā€™ve been able to construct the OH system in parallel with the Zipabox. In theory, I should be able to set up the Z-Wave stick as a secondary controller and connect all the Z-Wave devices without disturbing the Zipabox, either. This means I can build my rules up until Iā€™m ready to throw the switch.

Besides Z-Wave, the outstanding devices/services are:

  • Nest thermostats & smoke detector - this is the trickiest because of Googleā€™s evil shenanigans with the API. Right now I can access the API to obtain data, although apparently I can no longer renew the access token automatically. But so far I havenā€™t found a way to alter set temperatures.
  • Awair air sensor - I may have to add a binding for this myself.
  • Wunderground weather API for those with a personal weather station, which I (sort of) have. Well, I have a sensor or two. Itā€™s different from the old API and (apparently?) not supported in OH.
  • WeatherUnlocked weather API. Again, I might have to add a binding myself
  • DarkSky weather - I canā€™t figure out whether this is supported or not.
  • AirVisual pollution/weather - same as WeatherUnlocked

Ahh. I spy a DarkSky binding in the new OH.

Check out the Works With Nest - Deprecating on August 31, 2019 - #174 by McFly from some work-arounds that appear to work for now. Beyond that we need to wait for the Works with Google API to be released and then the individual access to that API being enabled.

I was under the impression that the binding was rewritten for the new API. @hilbrand IIRC you worked on something to get those with weather stations working with the new API. Any advice?

Donā€™t bother. Apple bought them out and theyā€™ve killed support for everything including their API which will close down less than a year from now. As an aside, their little notification in the Android app telling me to ā€œupgradeā€ in order to continue using DarkSky, meaning of course dropping my phone and buying an iPhone is why, at least for good while, Iā€™ll never be responsible for sending any money Appleā€™s direction. I donā€™t care that they shut the service down, but they donā€™t have to flip us the bird on the way out the door.

1 Like

Grrr. Aeris weather has also gone. It used to be possible to renew the token on a monthly basis, but apparently even thatā€™s been removed.

WeatherUnlocked is probably the best of whatā€™s left.

Not that I know of, so canā€™t give any advice here. Maybe there is a PR open for other implementations, but I havenā€™t checked that.

1 Like

The Weather Company (formerly Wunderground) is fully supported in openHAB using the Weather Company binding, if you have an API keyā€¦

Do you mean the API for people with personal weather stations? Itā€™s different from the old one.

Iā€™m not sure what you are asking. The Weather Company binding requires an API key, which you cannot get unless you have a personal station and are providing data to TWC. This will not work with the old Wunderground API key.

There are two different APIs. Thereā€™s the old one, which included data like temperature and wind speed, and then new one (accessible only if you have personal weather station), which excludes this information. Yes, the API keys are different. When I looked at the Wunderground binding, it appeared to be the old API (and my PWS API key didnā€™t work). But that was before I upgraded OH. Iā€™ll take a look at it again.

Looks to be the same as before. Using my API key (which I use with https://api.weather.com/v3/wx/forecast/daily/5day?format=json&units=m&apiKey=), I get ā€œunknownā€ on the bridge thing.

Continuing the account of my first stepsā€¦ as discussed on this thread:

I managed to get my Aeotec Gen5 Z-Stick set up as a secondary controller, by following this sequence:

  1. Plug Z-Stick Gen5 into any USB port
  2. Open Silicon Labs Z-Wave PC Controller v5.39 (getting hold of this can be a bit tricky. Itā€™s discussed elsewhere on this forum. I can try to elaborate if anyone needs to know - if I can remember! Suffice to say that you need to register on their site.)
  3. Click the gear button (settings). Click the row showing the COM port, then detect, then OK
  4. Click network management
  5. Click Select learn mode and NWI (Classic may also work if the Zipabox is close)
  6. Go to the Zipabox and add device, Z-Wave. Zipabox says ā€œstarting exclusionā€¦ā€. Donā€™t press anything on the Z-Stick. It will automatically be excluded.
  7. When Zipabox says ā€œstarting inclusionā€, go back to Z-Wave PC Controller and go into learning mode again. Now the Zipabox will find the Z-Stick. At this point I got: ā€œDevice inclusion completed. Secure inclusion failedā€. I didnā€™t worry about this because I donā€™t have any security-related devices. Perhaps I should worry more, but for the moment Iā€™m happy to get this far.
  8. When I tried to connect the Z-Stick to the RPi, initially I got nothing because the extension cable I was using didnā€™t play well with the Z-Stick. When I connected it to another extension cable, the one I was using for the Enocean transceiver (both are too wide to be plugged directly into the USB sockets), I could see the device with the command: ls /dev/serial/by-id
  9. As described above, I think, I created a symlink so that would always get a clearly understandable symbolic name for whatever device is connected to the port in question. In my case, the vendor and device IDs are:
    idProduct=ā€œ0200ā€
    idVendor=ā€œ0658ā€
    These can differ according to the version of the Z-Stick, I think.
  10. That done, I added the Z-Stick manually in PaperUI. All I had to do was select the USB port (symbolic link name in this case). And 28 Z-Wave devices popped up.