My Problem with OpenHab

I use OpenHab since some time. Its not bad. But there are some annoying things why as a whole system never worked for me like it should:

  1. I use mostly z-wave items. Different vendors like Danalock, Aeotec, Fibaro, Qubino. With every item the same problem. After switching them with OpenHab or manually, they have just 50-60% chance to send the status or electricity consumption or battery status. In 40-50% i get no information, and is not important how i configure the items. I tried different items, but the same result, so it can not be because the item, it must be somewhere in OH.
  2. I know OH is a free thing, and because this no real support, but i think lot of people would be happy to pay something if they would know, that the Home Automatisation system they try too make would work. Just 2 examples:
    a. I changed my network system to unify, because there was a good binding to unify in OH. Some time later i evolved my system, and there was some updates from unify side and after this the binding dont worked anymore. After a time someone else made an another binding, which should be downloaded and installed manually, thats worked a bit, but since this no bugfix or change in OH, so that the working binding would be added to automatically download.
    b. I planned to make an entry system with e-key, which have a binding too, but where is the garantie that if i invest 2k euro in the ekey system it would work with the binding, and that the binding would be updatet for later use? After my 1500 Euro investment in Unify almost was for nothing i fear to invest in anything which should work with OH.

This is not necessarily true, the problem is more likely in your z-wave network. If you post a question on the forum, I’m sure someone could help you with that, there’s a lot of people here who use z-wave.
On a side-note, I’m not sure what you mean by “tried different items”. Item has a special meaning in openHAB, and the channels on the Things mostly just support one type of Item, so i can’t see how trying different Items would prove anything.

Large investments like this should probably not be based on whether they can integrate with openHAB. I can certainly be a factor in the decision, but not the primary one (IMHO).
If you want paid support, and use OH for your smart home, I know there are people here on the forum who runs a business of selling installations (might not be available in your region though), but I think in that case they don’t let you mess to much with the system, because it would be very difficult for them to offer any form of guarantee of reliability. That’s one of the main reasons why commercial alternatives is less flexible than openHAB is. If they let the users do what they want, their support would be overwhelmed by people who mess up their installation and demand that the company fix it. You just can’t have both the freedom om managing everything yourself, and someone else who guarantees that it will always work.

5 Likes

This is not necessarily true, the problem is more likely in your z-wave network. If you post a question on the forum, I’m sure someone could help you with that, there’s a lot of people here who use z-wave.
On a side-note, I’m not sure what you mean by “tried different items”. Item has a special meaning in openHAB, and the channels on the Things mostly just support one type of Item, so i can’t see how trying different Items would prove anything.

Maybe you have right, but if there is the same problem with Danalock, Fibaro single switch, Fibaro double switch, Fibaro shutter relay, Qubino single switch, Qubino double switch, Qubino shutter relay and with two different z-wave usb keys, than for me is very possible that the problem is in OH or in the OH ZWave binding.

Large investments like this should probably not be based on whether they can integrate with openHAB. I can certainly be a factor in the decision, but not the primary one (IMHO).

Its not the primary primary factor, but i need to plan such thing. for example i use danalocks on different doors, and i need this items to communicate with a fingerprint scanner. The simplest thing would be(because ekey have a OH binding) to bind the E-Key to OH, and the OH could send commands to the danalock. But if this is not possible, i need to change doors, make wires, and so on…
So is the less expensive investment with e-key, but if in 6 months there would be a not working binding, thats still a waste of money.

https://www.bountysource.com/teams/openhab

If you want to pay someone to fix your problem go ahead. My rate is too high too accept any of the current ones.

You helped me already on the discord more than enough. You was the one of the few who was able to help mostly.

1 Like

Yeah the problem is as soon as you involve money in it people loose interest. Most of the help you receive on the forum is from people with a day job that they are experts in there field. If you turn it into a job they will loose interest.

You maybe right, but so is not possible to plan longer than some months, because there would be never even the simplest garantie, that something that now work in OH would in some months too.

All of these things are linked by a radio mesh of course. What would happen if just one was faulty and jamming the mesh, I wonder?

Anyway if you want to progress anywhere with it, do what it tells you in the binding docs and get a DEBUG log of it going wrong, e.g.pressing a button on a device that does not get seen in openhab.

1 Like

That depends entirely on the binding. Z-wave for example, will not become a problem for years to come. The devices are following a certain specification, as does the usb-stick, and the openHAB binding. None of these will suddenly start working in a different way. There could be problems adding new devices that follow a newer version of spec, but your existing devices won’t change. With bindings getting data from a web api, it’s a different story. Here the api provider might decide to change or discontinue the service at any time. If it’s an official api meant for integration with other system, there’s mostly a notice about it well before, but if it’s “unofficial” (like the unifi-binding where it’s built by reverse engineering the unifi web UI) it might just suddenly stop working. As long as there’s an active developer of the binding, it will probably be updated rather quickly, however. I’m not familiar with the e-key binding, so can’t say where it fits on this scale.

Edit: WRT the unifi binding, the issue only started after an upgrade of the unifi controller, if you were to stay on the old version, things would continue to work. And in the latest OH version, the binding have been updated to work with either version, no need for any manual installation.

I updated the openhab to last release with all bindings. Used the Unifi binding, but still dont work :frowning:

Is this the issue you are experiencing?

Otherwise you need to be more specific about the problem, “doesn’t work” isn’t much to go on if you want someone to help you.

1 Like

I think they are rs485 and work fully locally? If so they should be fine just read this post of what not to buy.

Also on these locks in general (don’t know if the ekey suffers from it) you should be aware of this issue.

You could always get a broken system working again by adding a Shelly that uses a relay in it to trip the system or even get a cheap setup connected to openhab in this way.

If you post on this forum asking for help you can usually get a few different ideas on how to achieve a result.

Hi,

I can only advise you to follow Ockham’s razor (aka the KISS principle): keep it simple and stupid.

Sadly, smart home is not. We are talking about distributed systems, which by nature have emergent properties and therefore complexity. The matter at hand is engineering and there is no way around that.

In engineering we make plans and a plan is a plan, is a plan, is a plan…meaning a plan that cannot be modified is a bad plan. Thus, we don’t start planning with a solution in mind (like the products you described), but with the definition of the requirements that have to be met by the system we want to employ.

But enough lecturing: You can either outsource the engineering (as suggested by other posts) or do it yourself. There are no other options. If you decide for the latter, then cooking (putting encapsulated software from unrelated sources together in a pot and going trial and error) is not enough. You will end up facing deep research and software development tasks (e.g. writing HabApp programs with BeautifulSoup scrapers for third party products maintenance HTML pages or even your own OH plugins in Java).

If you feel uncomfortable about these prospects, I strongly suggest rethinking your investment of time and money into smart home. Sorry. :frowning:

3 Likes

We’ve got an EKEY system. The relay is in the control unit and not in the finger print scanner. The scanner sends finger-print data to the control unit and the control unit switches the relay.
This problem does not affect EKEY systems.

An issue like that must be an issue with the network or how the devices are configured. If you explain more about your network and how it is all configured.