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.
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 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:
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.
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.
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.
joah… that boils down to “We always did it this way … we never did it that way … what if everyone wants that?”
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 think quite the opposite
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…
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.