I know this question has been asked many times but in every topic I found, the actual question was not answered:
I am looking for wireless remote switches or dimmers to control some devices that are attached directly through the ZigBee binding (e.g. bulbs, but no other gateways like Hue involved).
These switches/dimmers don’t have to be Zigbee, but they should be wireless and I would like to control how they interact with my items.
I know I can use a Tablet and HABPanel, but that is not what I want, I want simpler switches/dimmers as well because not everyone wants to use a tablet for this purpose.
Huh? As in your setup OH will do the conversion of the abstract ‘ON’ command into ZigBee, you can use ANY switch of ANY OH-supported technology on the input side. That’s why noone “answered” that question. Should be obvious, no?
SOnOff, ZWave devices and Amazon Dash buttons come to mind, just to name a few.
Thanks, indeed I found some Z-Wave switch devices and I’m willing to invest in a Z-Wave stick if required to do this. I just wasn’t sure if this would work because in Zigbee, it doesn’t (pretty much all the dimmers and switches for Zigbee have to be paired directly with the lights or you need e.g. a Hue gateway). So I assume there will be Z-wave dimmers that I can attach to the Dimmer Items in OpenHAB for example?
Sure there are, see e.g. Fibaro FGD-212.
BUT: don’t misunderstand. Dimming works with direct attached lights only, be it that they’re either electrically connected or be it you use radio to associate the input device to the light.
Cross-technology press-and-hold dimming will NOT work. So e.g. with that FGD-212, you can attach one switch (two even, actually) and a light and press-and-holding the switch will dim that light, but that would work purely electrically without OH being involved.
But you cannot use either of those 2 switches to dim a ZigBee light.
On the abstract logic representation, it’s INPUT SWITCHES meaning they can only be ON or OFF. Same for color lighting. You can’t set a color with ON-OFF input devices only. You should get a ZigBee remote if you want to dim/color control your ZigBee lights.
But this is what I need. And from a technology standpoint, there shouldn’t be anything stopping us from doing that, right? I want the ability to have e.g. a dimmer device that interacts with an OH dimmer item.
And this is what I read in some other posts too and what led me to saying that the question is not answered: A zigbee remote does not work like I describe. A zigbee remote typically interacts directly with the light, or through gateways like Hue. I want to control e.g. OH dimmer items with this device though.
No. It will not work for a number of reasons, RF and processing delays being one of them. Even if if did work at all, you would NEVER be satisfied with the result. You will NOT get that smooth press-and-hold-and-see-lights-brighten experience you expect. It will be choppy and delayed. Neither Zigbee nor ZWave nor any other tech works with START and STOP packets/events. They can only transmit discrete values. That effectively why this approach will NOT work.
No you don’t want to do that.
If what you wanted is interactive dimming control then you would need to use a ZigBee remote.
You want to
a) be able to use a remote or fixed device to touch to directly dim the light. For that to work, it has to be a Zigbee device, so as you say you need that functionality, get one or change lighting technology.
That would change brightness/color without involving OH, but if you have properly setup your devices
then that dimming action will also change the OH OUTPUT dimmer items that you have mapped to your ZigBee lights because the light device will send a status update to the ZigBee stick in your OH server.
If that does not work without a gateway, well then your problem is that you expect the products you bought and architecture you deliberately chose to provide functions that it does not and can not.
The only remedy would (probably, I don’t know your products) be to get a gateway. Yeah I know it’s hard to admit it’s because one misunderstood that because you thought you were clever and save on those gateway costs. But that’s how it is.
b) use GUI or automation rules to control the light
That you can do, effectively manipulating the OUTPUT dimmer items by dragging sliders in the GUI or by sending commands them.
c) have yet another INPUT dimmer-type device (non-ZigBee), to be represented by some INPUT dimmer type item. You would then link those two dimmer items by creating a rule to perform “if INPUT item changed to X then set OUTPUT item to X”, but as explained at the beginning, you can’t have START-STOP but just messages/events with a discrete value X. You can generate multiple messages with different Xs in quick succession, but as I said it effectively will not work as the dimming experience will be choppy and delayed.
I don’t see how what I request is so different from using HABPanel (which I mentioned in the original post). In fact I am using that right now, and yes, there are delays (which is to be expected), but that is fine. I just would like an additional switch so I don’t have to use the tablet for very simple things.
It is very interesting that you seem to know what I want to do and what not. In particular, a ZigBee remote is exactly not what I want to use. First of all, many ZigBee remotes do not work while the Bulb is part of OpenHAB Zigbee network. Second, I do have multiple bulbs that need to be controlled at once (they belong together), but they are separate Zigbee devices. Most remotes simply cannot do that.
And again you are simply wrong. I am not “saving” on gateway costs, in fact I have tested several gateways. Probably the most important factor why I don’t want to use them is that they are not open source, proprietary and controlled by the manufacturer. Things like what happened to the Hue Gateway when Phillips decided to lock out all non-Hue bulbs is a good example why building automation on top of these black boxes is a bad idea.
There is absolutely no reason why you would not be able to rebuild the Gateway functionalities with OpenHAB and that is in fact why the Zigbee bindings exist in the first place. There is also no reason (technological or otherwise) why the gateway should be able to provide a better (more fluent) experience here compared to using OpenHAB directly. The only limitation is what the Zigbee Bindings in OpenHAB currently support and can do.
I said that because it comes at the inevitable cost of delay and usually choppiness, too, at least once you make extensive use of it, and I still don’t believe that’s what you want because that is no satisfying user experience. I’ve seen several people expect that and be disappointed they don’t get it in the end. And part of that disappointment is because they have to admit to themselves that they underestimated the complexity and one could have known that beforehand.
Well, I still see no contradiction here - you would still want a ZigBee remote if it was capable of controlling all of your devices/use cases, wouldn’t you ?
Now since you can’t find any commercial product you want the OH ZigBee binding to stand in as that remote or gateway.
Using OH GUI in fact means you already use a ZigBee remote. It’s the most effective, delay-minimizing approach to have an input side dimmer and no protocol conversion or other processing to get that input out on the ZigBee side so that’s why it works for you albeit you’re already seeing delays.
Plus you don’t want to use an UI. But a HW switch on the input side will always require protocol translation and additional processing, and no matter what combination you come up with, that’ll aggravate what you’re seeing already in terms of delays.
That’s where I disagree and sorry but while desirable, I feel that’s a little bit naive to expect that to happen.
ZigBee binding is still experimental, there’s still a long way to go. ZigBee as a protocol is so open (or to put it from an implementor’s pov, so badly undefined in a number of use cases) that there are and will keep being many corner cases where particular implementations of devices, controllers and gateways will not properly work with each other.
Whenever you want to use a non-Zigbee HW input device there will be the need for protocol translation and postprocessing in a gateway, be it OH or some commercial one. I’d call that setup to be broken by design. I don’t think that’ll ever work satisfactorily unless maybe with a small, very specific combo of devices if you’re lucky.
What I’m using myself is Philips Living Colors. That’s the Hue predecessor, “somewhat” ZigBee already but rather proprietary, but the system came with a remote to allow for smooth dimming. It wouldn’t work directly with the ZigBee binding so I also got a Hue gateway to connect them to OH.
I’ve got ZWave based lights in the room as well. These I synchronize to the Living Colors using OH rules to trigger on changes to light color when informed about by the Hue gateway.
As explained and to be expected there’s delays due to protocol translation, but at least I have a smooth dimming experience/“sensitive” color selection on the ‘master’ Living Colors bulb. Note non-delay dimming is even more important with color lighting as that’s effectively three dimmers in one go, oh and you’ll be having a hard time looking for color input-only devices, too.
Just trying to help. I still think you’ll be way better off getting a physical ZigBee remote to directly control at least the ‘master bulb’, others to follow via OH rules then.
As far as I know, it does not exsist.
The main problem is, to my knowledge, openhab can not handle “press and hold” through the binding, neither Z-Wave or Zigbee, not even the IHC binding is able to do this, even though it´s a standard operation in IHC.
What you could do is to use a wired switch and the FGD212 Markus also mention. Then you can let the FGD212 be the “master” to control the other bulbs wireless through openHab.
Its not a fancy setup, and its not wireless, but it will work.
Makus, this is not correct. IHC works the way Chris want to, using wireless technology. But it´s a closed radio system. And I agree with Chris, there is no technical reason why it shouldn´t work with openhab and somekind of wireless dimmer/switch as well.
This is just a question of updating the device database. @chris might be able to do this if someone can provide the needed information for the device. Then you´ll be able to connect the zigbee switch to openhab, and use it´s functions to control whatever you like, which is connected to openhab as well. I have a Philips Hue dimming switch connected (via the Zigbee binding). And it worked (for some days though). But only for on/off, not press-and-hold.
I still believe there is a limitation in openhab/bindings with press-and-hold function, which I fear is not possible (for some reason I cant figure myself).
Ever since I started with openhab, I have searched for a press-and-hold solution myself due to this beeing standard in the IHC system, which I have in our house as well. I have several dimmers which uses press-and-hold, but I can´t use the feature together with openhab.
And I agree with you, I cant see any reason why it shouldn´t work.
Perhaps @chris cant explain what technical reason there may be the cause. He´s working on both z-wave and the zigbee binding.
Ok, I shouldn’t have written “or any other tech” as what I meant to say was “any other tech I know to be applicable here”. Not knowing IHC, does it really use START/STOP on press-and-hold ?
I have a ZWave remote and that mentioned Living Colors remote, both to provide a smooth dimming experience on press-and-hold, too, but that they do just inside their respective systems. And AFAIK they don’t use START-STOP.
And yes, in theory - as I wrote at the end of that post - you can simulate or replace START/STOP by sending multiple packets of differing discrete values, but that’s inflating processing workload, and doing so through a protocol gateway is just a bad workaround bound to create new or aggravate existing problems.
So while that might work in theory and maybe even to some extent in practice, it is not generally applicable-recommendable and the ‘ZigBee remote’ is a better solution for this use case.
IHC can do:
Short press. (time defined in its own program, in general, no limits).
Long press. (time defined in its own program, in general, no limits).
Multiple presses (no limitation, again it´s defined in it´s own program).
Mixed short/long/Multiple presses.
Press-and-hold.
Start/Stop, I´m not really sure what this is suppose to do? I assume, if it can do press-and-hold, there would have to be start/stop as well. (otherweise it makes no sense).
In general, there are no limitation in IHC as far as functions goes. IHC´s main limitations is mainly around devices. LK/Schneider have not done much to provide new devices to their IHC system in decades. This is my main reason why I combine IHC with openHab.
Ofcouse the program (IHC´s own program) can become too complexed with lots of timers etc running at the same time, so it will hit the limitation of its resources, (CPU and RAM), but there are plenty of resources available to do even huge and highly complexed programs, including highly advanced alarm systems, huge heating systems etc.
But the Zigbee remote/switch (wireless) solution will not work either, if press-and-hold is not supported, which to my knowledge is the main cause, no matter which protocol/binding we´re discussing.
Send one packet on press and one on release, eventually to also include a ‘change speed’ or ‘timeframe’ value so the receiver knows independent of the timing of packets to arrive how long to apply fading.
Given IHC makes a distinction between ‘short’ and ‘long’ presses, I don’t think it really does what I mean by START-STOP. In that case it would allow for variable-length presses. Anyway, that isn’t the point.
Point with START-STOP is that you need to transmit and process a lot less packets.
ZigBee as well as ZWave and Living Colors remotes (and possibly IHC, too ?) send multiple packets.
That’s ok as long as those packets remain within that system as they need not be proxied/reprocessed through a protocol gateway. If say there’s packets arriving saying “65%” and “70%” in succession, the receiving device might interpolate and do a fading from 65 to 70% instead of doing a jump. Now while that’s not impossible to work when the originating side protocol is a different one, it will likely not be working as good as that since timing will be a lot different and rather unpredictable.
Also, a vendor cannot and therefore will not do end-to-end testing and optimizing.
@mstormi
A short principial diagram for IHC, (devices).
Page 2 is in english: http://www1.lk.dk/katalog/vejledning/019D872421_01.pdf
It doesn´t show its actualy programming, but notice the wireless devices. They´re able to do anything.
Wired devices goes directly to the modules, which basicly is just I/O (there are wired dimmers as well, not showen in the diagram). Modules wires dirctly to the main controller.
IHC uses 868mHz frequency, crypted radio signal.
How is works behind the scene, I´m not quite sure. I believe the main controller “listen” for triggering in some mili seconds, and from this detamin if it´s a short or long press (or press-and-hold), cause I´m able to set the time in ms for my dimmers etc. This is, to my understanding, the same as start/stop. Since IHC also can distinguish between multiple presses, I believe it´s due to the same reason, (timing and counting between press and release).
I believe Openhab should be able to do the same for any wireless devices as well. I dont see any reason not to.
I also believe this is the exact same principal Philips Hue dimmer switch is using with the Philips Hue devices or bridge. But I guess @chris might be the best to answer this. Perhaps @pauli_anttila can explain as well, since he´s the man behind the IHC binding for openhab.
The first IHC wireless controller came in 2006. It cant possible be a hardware resource issue today in openhab (hardware limitation). I simply refuse to believe this!
No it’s (for the most part) not due to additional delays caused by in-mesh forwarding but rather due to processing delays when OH needs to translate ZWave (or whatever input side protocol) to output-side ZigBee, eventually even including the need to use rules to trigger. Lots of overhead with unpredictable impact on timing. THAT’s why it won’t work (or not work well).
I have not been able to find the exact hardware specification of the IHC controller. But as mentioned, the first wireless IHC controller came on market in 2006. Rumors say it´s running somekind of Linux kernel.
If a 12 year old hardware device can do stuff like this, 2018 hardware devices should be able to do exact the same, without any hassle at all. Even the Rpi.
Again, I think we need @chris and @pauli_anttila to comment on this matter, since they both working on the bindings for the devices. Maybe it´s a limitation in Eclipse Smarthome.
I am not 100% sure what you are wanting comment on as the question looks a little vague. However, I can provide some insite one what I think you’re after…
In ZWave, there is the ability to send scenes with different states - this is a certain number of “clicks”, or press and release. So, this means that you are not restricted by any data volume issue (not that this should normally be an issue anyway - ZWave and ZigBee at least are relatively fast networks). There will be some timing issues as @mstormi points out - ie there will be some latency between pressing or releasing the button, and the message getting to its end recipient if it needs to go through different bindings, rules, etc. This might not be particularly long delay though, but it will depend on a number of issues (broadly speaking, the “loading” of the system at the time).
Feel free to ask specific questions and I can try and expand on the above if it doesn’t cover your query…
These are programmed inside the z-wave dimmers, right? (at least the FGD212 I´ve got has some kind of scenes available, but I see no reason to use these when it´s connecting to a system like openhab).
But what about switches?
Will the binding recognise a long press and release and openhab beeing able to “convert” this timing into a value used for a slider or something simular?
When I added the Philips Hue dimming switch to the Zigbee network, I was only able to do ON/OFF.
When the dimmer switch is connected to the Philips Hue Bridge, it´s possible to use long press for dimming/brigten bulbs… How come this feature is not possible in openhab/Zigbee binding?
This is what I understand Chris (the thread starter) ask for. As well as I have been searching for, for my IHC system. I can´t see how it´s possible in openhab, and I can´t find the cause/reason for this feature missing.
No - the binding has no way to recognise this by itself - only if the switch sends the scenes (or some other commands) as I mentioned previously.
Please provide a log showing this as I’m not sure what it is sending as I’m not aware of commands other than the level set, and on/off type commands. There might be other clusters that provide such functionality, or other commands, but I’m not immediately aware of them (there are thousands of commands in ZigBee - I don’t pretend to know all of them ).
It might simply be sending period level commands - there are a lot of different commands, although I’m not familiar with a start/stop type of system in ZigBee as I explained in ZWave
).