openHAB project - considerations and questions of a newbe

My two cents. I use Z-wave extensively (although not exclusively).

If at all possible use mains-powered z-wave devices. Battery-powered are OK when there is no alternative BUT I find the “battery-level percentage” reporting to be highly suspect. Quality level seems to vary by device though – I have some devices reporting battery-level of 100 after 3 years of same battery. Others seem (at-least) reasonable depletion.

I pair my Aeon Gen 5 controller with a new zwave device and let OH discover it. This makes it a THING in OH-world. (You can write a manual THINGS file, but it is pretty arcane.) HOWEVER, I configure my ITEMS in text files. (You need the result of OH discovery to get the specific binding info for that text file, BUT I find it easier to maintain labels etc in text files, as well as referencing the text files when writing rules. e.g…

Switch	SW_u_01_LIGHT_Bath1	"FX Master Bathroom Light"	<light>	(  gSwitch, gSwitch_u_01,gBath_u_01)			{ channel="zwave:device:8426aca6:node19:switch_binary" }

For a text-based items file you need the channel info in the code slice above – you get that from the Paper UI interface to the discovery process. BUT with a text-based items file, you can change the various labels easily in “your basic editor” without having to go thru Paper UI.

I think you know this, but for safety’s sake — zwave (mains-powered or NOT) is independent of both your Wi-Fi and non-mains-cabling situation.

I like HabPanel. Accessing it from outside your home (without using openHAB cloud-which does seem to have ongoing stability problems (nevermind the privacy aspects)) requires that you have a strongly-controlled VPN access to your home network. Definitely doable, but also falls into the realm of the “dark arts”. “First you crawl, then you walk, then you run–but don’t ever try to FLY”. Highly-dependent on your router and your ISP. Getting a stable VPN into your home network is one of the few things for which you might consider paying an expert.

As for your general “wish-list” — aside from external access, your main vulnerability is power-failure, either generally to the “mains” or to the OH server specifically. The latter could (and SHOULD) be addressed with a UPS. As for general power failure, you have to decide whether you want to be generally impervious to power-loss of length T – OR — have UPS support for your OH server AND some failure recovery logic for the situation when mains-powered devices go OFFLINE and then come back ONLINE after a period of time.

1 Like

Thomas, thank you very much for your help. We are talking a ready building out of 1994. This means we have some options to wire but will not reach all spots on cable. This is why I was considering in parts Z-Wave components. In example I bought 12 smoke detectors Popp 004001 already. For thermostatic radiator heads I am thinking about Eurotronic Spirit Z-Wave Plus. As this is all battery powered devices. I may need cabled devices in order to create a sufficient Z-Wave Mesh. I was thinking about switches (Fibaro FGS-213) for the main lights.

Anyhow you seem to be very experienced with cabled devices. What options do I have here? You are mentioning KNX which seem to be somehow the common standard but quite expensive as well.
What source do you recommend to check for KNX?
What about 1-Wire
Do I need for all the wired systems a gateway? If yes which ones are recommended?

ok, talking about existing buildings. And I guess, you don’t restructure the whole thing for new installations and stuff…
Unless you have some empty pipes (Leerrohre in german) leading to each room, I guess, this rules KNX out. KNX is depending on each actuator having seperate cables (mainly 240V) - e.g. if you’d like to have lights ON/OFF, you have a seperate phase at least for each light or outlet you want to control to your switchboard - in there are all actuators like dimmer or switches or stuff. So KNX is most powerful, if you can plan it from scratch in a greenfield approach. For more information on KNX you should ask an electrician.
1-wire is cabled and connects your devices via one wire (in fact it’s two :wink: ). For that you’ll need some kind of “gateway”: either an USB-Host and a RPi (what I have) or a fullblown wiregate. With that you can have some kind of sensors (temperature are the most common), which can be polled and e.g. put into items in openHAB. You can also have iButtons, but normally they’re not used for switches, but for security at entrances.
Then there’s Z-Wave and as you already have Z-Wave devices, I’ll recommend, you’ll have a look at the Z-Wave universe. I don’t know much about it, but there are buttons/dimmers for lighting, sensors for all kinds of stuff and actuators for blinds, heating, …

So, as you don’t seem to want to renovate your whole house, go with Z-Wave (and keep in mind the mesh, but you have already :wink: )

Bob, thank you very much for your insight into Z-Wave.
Of course I will use cabled devices where possible but will have to use others battery powered such as smoke detectors and thermostatic heads for radiators.
Are there cabled multi sensors available? What brands are you using? Experiences and observations on things? Is it a must that the Z-Stick is connected direct to the machine OH is installed on?

To create a stable solution I have for now chosen an Intel NUC with a SSD. Eventually I will create a virtual Linux machine for OH later on our vmWare host. This would ease back up in example as I could include it in our Veeam backup solution. This would probably mean that the Z-Stick would ideally move to another machine as radio in our server room to outside is not nice. Of course we are using strong overvoltage protection, a powerful UPS, highly redundant server hardware… Probably way higher level than you would see it in most set ups as we are using it mainly for busines purpose.

I have absolutely no problem if higher automation stuff does not work anymore at a server failure as the chance to see this is small. Anyhow I am a fan to keep basic functionality bullet proof. EQ3 had problems with their cloud solution at least in fall 17 it seems. Funny stories about people not being able to switch off their hull protection in a Homematic IP setup…

Wow you are fast…No chance to reach every single light with bus wires. As I have stated at least in the offices we do have wide cable channels (Brüstungskanäle) with separate sections for high and low voltage. Many others are equipped with channels around the rooms just under the ceiling. As mentioned as well there is a lot of an 4 wire telephone cabling eco system left over in the channels. So what I was thinking about one wire for sensor stuff and other purpose as it seems to be reasonable priced and more fail save than Z-Wave and other non-wired components.
What prices do I look into for USB-Host and a RPi or a fullblown wiregate? Recomendations?

Thank you again for your kind assistance and insight.

  • the USB-Host costs 25€ alone (https://shop.wiregate.de/wiregate/usb-produkte/usb-produkte-ecoline/ds9490r-1-wire-usb-adapter-raw.html) - aaaand lots of hours getting behind onewire Server and that stuff on the Pi
  • wiregate (https://shop.wiregate.de/wiregate-starker-pack.html) comes with 500€ - but has a out-of-the-box setup, is german based near Munich and doesn’t add something proprierty except the Server, which not only eases the pain of setting up your devices, but also comes with a whole bunch of rules and a framework for your installation - if I understand it correctly. As I only have 1-wire sensors attached, I felt I don’t need it as I just Import the 1-wire sensor’s information in openHAB (temperature, S0-interface, …). If you like to have some more advanced interaction with 1-wire devices it makes more sense.

I strongly suggest to use files for as much as possible. I have a fairly large system with around 120 devices, mostly homematic (about 60, no HmIP, Homegear as a base), hue, lightify and several multimedia brands. All basic functions (heating, lighting) work without openHAB or Internet access. I don’t think i am running something cloud based, but am not sure. From my mind, the hue is local gateway based, the lightify binding uses also local access. Homegear as well.

With almost all data in files, i can easily start from scratch, disable a bunch of devices etc. I also can work with the powerful Search & Replace functions of VS Code. Additionally, i put all my files into Subversion, to have a proper history.

If i knew beforehand, i would not use any devices which are impossible to use with files. (Lightify Binding :()

So, @cl-oh, since your project is far larger than mine, i strongly suggest paying attention to the possibility of file usage. (I use Auto-Discovery to identify devices, then i translate the information into files.)

Thank you very much Joachim,
I had already the strong impression this is what I have to do. For a beginer not easy but I think with the help of this great forum I will manage to dive into it.

The zwave controller does need to be on the machine running OH2. (It looks like a serial port to the underlying OS.) Posssibly you could set up a RPi with the zstick for zwave radio coverage, place it outside your server room connect it to wired Ethernet and use MQTT to put the the main automation automation logic on your NUC or vmWare host.

You will need some mains-powered zwave switches to get a stable mesh. Battery-powered devices generally cannot act as relays in the mesh (because the are not always “awake” – to conserve power). Light switches are a good choice. I don’t have any experience with cabled multisensors.

Another option is Share Z-wave dongle over IP (USB over IP using ser2net / socat ) guide which would provide a little more direct connectivity between the controller on the remote machine and theOH server.

Hello gentlemen,
thank you very much for your assistance. In the meantime I found some posts about the same issue – openHAB on virtual machine and Z-Wave stick on another machine – i. e. Seems not to be very easy to set up but should work well.

Which solution would you prefer and why?

I’d choose the ser2net/socat approach myself if only to not have to run two copies of OH and set up a bunch of MQTT topics to bridge between the two. With ser2net/socat the USB dongle will appear to OH as if it were connected to your VM directly.

But there is nothing wrong with the MQTT approach either. It might be more work overall but might be easier to set up and it might be a little more resilient.

will post another thred in Hardware and list what I have found in means of radio controled eco systems. I did not find a general listing talking pros and cons in the forum. Of course there is discussions about speciffic stuff but not something liek an overfew which should be helpfull.

Sounds like a plan Rich. Could simply put it to a Raspi which is located at a central position in the building. Still possible to remoove the stick and pair it with new Z-Wave devices when they are cable based and cannot be brought to the computer hosting the Z-Stick. Could the Raspi be used for other purpose at the same time?

Or if you use one of those power bricks used to charge phones you could take the whole dongle and RPi to the device.

Absolutely.

Or use a compatible industrial grade, dedicated hardware with most of the needed interfaces on board

I’m also new to openHAB 2. Many years ago I used to be a programmer. using C and Visual C and a few other languages.
My experience with OpenHAB has also been poor. It seems to lack an intuitive approach. I think they should be going more in the direction of Node-Red which has a more sophisticated interface altogether. At the moment it seems to be a mish-mash of both GUI and text files which is actually a bit of a nightmare to understand at first with combinations of translations JSON and all sorts of rubbish mixed in. If I had written such a messy thing as this when I was programing, I would have got fired. The writers say they have some sort of altruistic vision or something. c’mon guys it’s only for home automation when all said and done. You’re not supposed to be re-inventing the wheel.
the 3 main rules of good software are Elegance Elegance and Elegance. You have missed out on all 3.
Scrap what you’ve done so far and start again. Maybe throw in some auto discovery and have all network devices appear automatically on a Node-Red type interface. Now that would be useful and visionary.

think this has to do somehow with the history of openHAB. The started of text based for somehow themselves - kind of a framework. Step by step people like me are comming aboard - some technical understanding but no real coding skills.For people like me they are just working on nice graphical interfaces - just try habmin i. e.
As in many open source solutions people simple decide something would be cool and the just do it. This ends in several options to solve the same problem. Maybe somehow a comparisan would be helpfull in order to udnerstand how a goal can be reached. Anyhow lot of nice options in opnHAB and assistance of people with real know how. I did not find anything better so far. Thanks to people like @rlkoshak, @bob_dickenson

A text-based THINGS file still eludes me – although I admit that the discovery process works well enough that I have not tried to “pick the nits” of making that work. OTOH, I find text-based ITEMS files to be immensely useful. Your-Mileage-May-Vary, BUT…I like them.

Ditto the text RULES files vs some of the graphical alternatives. OH is an event bus and orchestrating events across items (and time) is generally beyond-the-scope of extant graphical rules editors.

I’m sure @rlkoshak will have his own (VALUED) opinion here—just my two cents (or your local minor currency element :slight_smile: ).

It is. It just isn’t there yet. These sorts of advances don’t happen overnight and are particularly slow with open source projects, particularly well-established ones with a lot of history and the need to remain backwards compatible.

But for the record, it is not hard to use Node-Red as your Rules engine in OH. While not necessarily common, it is an approach that is used.

You assume that it was written that way in the first place. OH has been in development for years and is currently undergoing transition from text based to UI based config. It is in transition.

And, this is an opensource project. Noone gets paid to write any of it.

I look forward to your new visionary build from scratch system.

Rant, do not read unless you want to get my unfiltered letting off steam

NOTE: While I am directly addressing @Jimmy_Jones comments, the below is letting off steam in response to all the people who drive by this forum, drop a bag of burning shit, and move on. @Jimmy_Jones, please do not take it personally.

This is going to be a rant and it is going to piss off a lot of people but I’m grumpy today so don’t care. If asked, I’ll delete it.

I am sick of all these people coming on this forum and bitching on and on about how awful OH is with

  • no knowledge of its history
  • no knowledge of what is currently in work
  • no knowledge of the direction it is headed in
  • little appreciation for how hard home automation actually is

If you want an “Elegant” solution go buy something from a commercial vendor.

If you want to provide actionable suggestions for improvement we would love to hear your thoughts. Even better we would love to get your Issues and PRs.

If you want to bitch, at least give us something actionable. “This program is shit” is less than helpful. We can’t do anything with it. There is no change we can make to address it, not addition to the docs, no new feature to add or remove to address the concern. No discussion to be had.

And if you just want to come and call OH a piece of shit, at least do your F@!#$ing homework to know what you are talking about. OH 2 IS a “scrap what you’ve done so far and start again.” It IS heading towards a more Node-Red like approach (see the Experimemntal Rules Engine). And it has taken two years to get to this point (i.e. from all text based config to actually having UI based administration and automatic discovery and configuration of devices).

Do we still have a long way to go? Hell yes! And the developers and maintainers are working harder than anyone could reasonably expect from a group of people with day jobs and families and who are donating their time and efforts. There are plans and lots of things in work to make them happen.

But there are three choices:

  • gradually grow a system towards a shared vision
  • tell the thousands of existing users to f*#$ off and create something new and incompatible or with no migration path
  • hold back everything until it is “perfect” and “elegant”

The developers rightly chose to gradually grow OH towards.

To come on this forum and say that OH is shit and should just be scrapped is so offensive and insulting to the tens of thousands of manhours that people have donated to this project I fail to find the words to express it.

If OH is too hard for you, that is fair. Home automation IS hard and not for everyone. If OH isn’t “elegant” enough for you, please go and find a solution that works better for you or pitch in and help out to make OH better. Lots of people are successful with Node-Red. If you have something actionable to suggest for improvements we would love to discuss it. Shit can everything and start over is not actionable.

If you just want to shit over all our efforts with no knowledge of where OH came from and is going to, please take your comments somewhere else. It is not helpful and only serves to denigrate the efforts of the developers and does nothing to help.

11 Likes