IP/Ethernet to Z-WAVE gateways

Hi there,
is there a way to let openHAB communicate with z-wave items
thru an IP-Z gateway like DELOCK 78007 or Planet HAC-1000 (or …) ?

(I read a couple of posts here… and, no, I dont want to install a RPI with USB-over-IP).
I have openHAB running dockerized on QNAP, the latter being sheltered in
the basement in a perfect Faraday case :-D.

Reason is I am using shellys mostly, but want to extend the network by
some Fibaro smoke and water detectors.

BR,S

No, AFAIK the binding needs to access the controller locally and cannot address Z/IP gateways.
There’s nothing wrong with using a USB-over-IP approach, so why not.
Better even: move off the NAS and to a dedicated system to minimize dependencies as recommended in the docs. You wouldn’t have this problem if you had started with this recommendation.

You can connect two or now openhab instances with eventbus, see MQTT 2.5 Event Bus

Right, but as both instances need to work for the whole system to work it’s just complicating the system design and creating new dependencies that’s why I would not recommended that either.

You can use a vera edge or vera plus coupled with the MIOS binding. The vera will act as a standalone zwave controller and it communicates with OH via local tcpip.

Aside from the cost of the extra hardware, there are a couple of problems with this approach to be aware of:

  1. The MIOS binding is great, but it’s an OH V1 binding. This means it will be phased out soon with the move to OH V3. You COULD stay on OH V2, but this may not be workable for you, depending on your situation.
  2. The functionality of your zwave devices will be limited to what vera supports, so it’s a good idea to check compatibility before committing to this option.

Why not? I tried a lot of different options for USB-IP-Connectivity and the RPIs with ser2net are a pretty stable and cheap solution. Especially with the more recent versions of Z-Wave binding which supports a direct connection to virtual COM ports via RFC2217 protocol.
If you do not feel at ease with Linux based devices you can also use windows computers with Hub4COM software to do the same thing and connect to them.
So your QNAP NAS can remain where it is and you use one of the devices with an USB stick.

1 Like

zwave2mqtt might be an option rather than sharing a usb stick acros the network…but then you would lose the native openhab zwave binding controlling the zwave network.

Try contacting the companies that manufacture these items for support on how to control them through openHAB.

You could allways put a rpi in and share the usb port to docker on your qnap.

The OpenHAB binding does not support Z/IP.

I’m still learning and thanks for all your comments.

Now, after trying to understand these, I would conclude that what we need is
(now trying to use openHAB terminology)
another(!) binding using a Z-Wave bridge(!) over IP.

For HUE, there seems to exist such a bridge.
So, why not for Z-Wave?
The zipgateway should offer the API for that bridge (see http://118.24.72.133/index.html)

Where am I wrong?

(Maybe some mod may move this thread to the Development branch. It seems for me that I want to discuss this with them. Might want to join them ;-p )

Technically speaking your understanding is correct, but you’re IMHO wrong in stating that “we” need this. You’re actually the first to ask who is unwilling to use the available solution. Others just went down that route and are fine.
To answer your question, that’s why the functionality doesn’t exist.

We’ll happily take a PR for a new binding to accomplish that, though.

If you want to get in touch with our ZWave binding developer I suggest you open a feature discussion issue over at https://github.com/openhab/org.openhab.binding.zwave .

joah… that boils down to “We always did it this way … we never did it that way … what if everyone wants that?” :smiley:
Replacing “we need” by “I want” doesn’t change the problem that this RPi-USB-solution in my eyes just is a work-around, unnecessarily wrapping low-level protocols in higher ones.
Fact is, these questions rise quite often here in the forum. The guys then accept the work-around, move to another protocol (zigbee e.a.) or to another software.

I’ll have a look at both code and docs :slight_smile:

No it doesn’t. It’s a working solution not a workaround, no need to change it.

Feel free to implement and submit your “right” solution back to the community but stop commenting disrespectfully, please.

1 Like

I think quite the opposite :wink:
Having a dedicated IP-to-something gateway/bridge (e.g. via REST for HUE) for each technology I’m trying to integrate feels as a work-around for not being able talking directly the protocol via dedicated binding.
The native integration in openHAB is usually better IMHO.

Personally, I tried to get rid of my zoo of bridges/gateways.

openHAB has bindings for all my technologies used here and is the gateway to them.

I have openHAB … being sheltered in
the basement in a perfect Faraday case :-D.

Yes. Same here.

All the other helping writers here already pointed out the common solutions. No need for me to re-iterate…

EDIT: I opted for the ser2net+socat approach too:

Just one final hint:
Think of a second or a third or a forth … technology you like to hook up in the future. Would’nt it be good to have a single gateway supporting all of them instead of having a growing zoo of bridges behind the curtain?

That’s how I did it currently with Zigbee, ZWave, RFXCom and Bluetooth/BlueGiga. I like it…

1 Like

That is true with the caveat that sometimes the OH server is not physically located in the best area for the technology RF signal.

Sorry for being unclear…

I have openHAB … being sheltered in
the basement in a perfect Faraday case :-D.

Yes. Same here.

This was meant to tell, that I needed to have my radio devices connected to the openHAB via a remote connection too.

I’ve amended my former post accordingly…

1 Like

I have my USB stick connected to a USB extension cable to get the stick away from the server & rack running OH. I strapped the stick to rising network cables.

The problem with QNAP is that either you find a USB3 stick or probably a USB2 one will not work. In my case (OH 2.5.10 running in QNAP) I’ve decided to buy a RPi4B (2G RAM is enough) to run OpenWRT, MQTT broker, and other bridges if necessary (zigbee and/or zwave).

OpenWRT (and suitable switches/AP’s) allowed me to implement vlans to isolate IoT (and other critical) devices, which is a major plus, and the Pi4B has plenty of capacity to run OpenWRT and various bridges / brokers at the same time.

The problem with QNAP in the first place is that it is not dedicated to openHAB as recommended. Reduce software complexity and eliminate interdependencies for sake of a stable home automation experience.

USB3 is backward compatible of the vendors follow the standards.