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.

1 Like

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:

4 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.

Thanks. Just tell me what data i need to provide and i post it.
The openhab is running on a Intel NUC with 8GB ram on Debian. I use an AEOTEC Z-Stick Gen5+ and an AEOTEC Range extender 7.
Behind this i have 15x QUBINO Flush Shatter, 17x FIBARO Double Switch 2, 3x QUBINO Flush 2 Relays, 1x FIBARO Wall Plug, 1x FIBARO Carbon Monoxide Sensor and 1x Danalock V3 z-wave Lock.

To be sure what the issue is you should build a zniffer. It is very easy and will pinpoint the issue in minutes rather than days or weeks. If you want to fix this it will save a lot of time and frustration as without it you are guessing.

If you want to try guessing.

First thing make sure the pole after setting is disable on all devices. I have never found a case where it adds value but there might be some edge cases where it helps.

Next reduce polling on all devices as all of your devices support association. I set all mine to the largest setting and would turn off altogether if binding supported. When your network is fixed you will not need to poll and trying to fix a bad network by polling will make the network worse.

For reliable zwave you need to get the traffic down. Zwave is a low energy and to achieve this it is low throughput by design. The more recent standards now limit the number of times a device is polled or sends reports but the larger your network the fewer times devices can report or be polled without causing issues.

In your list there are a few devices that might spam and create too high traffic.

First I would look at all of the FIBARO double. Some of the older firmware has issues for example when you try to disable reporting you get more messages. These can be terrible spammers and flood the network with power/energy reports.

Unless you are using energy change to trigger a rule and need regular reports set the min time between reports to maximum value 120 (51 and 55).

The rest of the parameters are down to what you need from each device but I disable all power reports based on change value 0 (50 and 54) but this does not work on some older firmware. If you want to use this or are on old firmware set it very high and I would suggest start at 100 as you are working blind if you have no zniffer.

Set parameter 60 to 0 so reports are only sent when load switched on.

Set 58 and 59 as high as possible or disable.

Even if you disable reports you will get reports each time the switch is toggled so kWh will be updated. All you will not have in your total kWh is a bit of kWh to a few for a period.

1 Like