Unfortunately it looks as if, even if you could obtain the unit code/ID for each blind/awning, the RFXCom transmitter refuses to work with a code/ID that it hasn’t stored as a “remote”, which means you have to pair the device anew from the RFXCom using the “program” command… which means picking a new code/ID combination.
@marcel_erkel set me right. Apparently you can pair the same blinds multiple times with different remotes/controllers, and each pairing has different codes. I figured out the symlink stuff (to ensure the rfxcom has a consistent device identifier on each reboot) - read the tutorial! - and successfully added one of my blinds to openHab. I can now control it from both home automation systems. The ID.UnitCode that you need to put in the shutter thing configuration uses the decimal ID, not the hex ID. This tripped me up at first (although it’s in the tutorial!). You can see it in the rfxmngr output window, or just do the conversion on a calculator.
1 Like
Oh, there’s also some confusion about whether you need to cut the power to all other blinds and awnings before pairing one with rfxcom - you don’t, at least not with the Telis remote I have. You select the right one, and press the button on the back. Doesn’t interfere with the others at all.
Added all 4 blinds and 5 awnings to OH.
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 
! 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. 
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.