And I don’t know of any ZWave device to provide that “timing” transmission ability as scene numbers, nor that I know of any other applicable protocol to provide that.
It’s just distinctions between single-double-triple clicks or short-long-press. So a smooth, interactive dimming experience would require quite a series of packets to contain (in- or decreasing) brightness values, each of which would need to be processed inside OH before it can get forwarded on the ZigBee side.
That may turn out to work well, or, as I believe, it will rather not.
At least it depends on OH system load and two times the timely availability of radio transmission slots (rather than just once if we stay inside ZigBee).
No - it doesn’t need to provide timing information.
No - there are other commands START and STOP as well. So a device can send a START command, and a rule could interpret this as it likes until it receives a STOP command. There is no need to send lots of commands at this point (it may require lots of commands elsewhere though, but this isn’t that abnormal).
… if we use START/STOP instead - agree.
Yes ok. But these are sensitive to timing then which might still work fine as long as we stay inside ZWave but may get unpredictably worse when we need to traverse a protocol gateway, and that’s my point in this thread.
I don’t think it will be too bad - of course if the stop gets delayed a little, then it will increase (or decrease) more than expected and the user will have to go the other way for a second to compensate. It’s not dependant on timing of many commands though. I have used this and it does work ok in OH.
First of all…
Lets keep it on a functional matter… I have no idea if this is a binding issue or openhab/Eclips issue. I mainly focus on the function (press-and-release) is possible in other systems, wether it´s IHC or Philips Hue. And then wonder how come it´s not possible in openhab.
I honestly doubt its a hardware issue.
I can not provide a log from the Philips Hue bridge 
When I added the Philips Hue Dimmer Switch to the Zigbee network, I had no other options than ON/OFF. Pushing the brigthen (top button) or dimming (bottom button) and keep the press result in an ON/OFF in the tail log of openhab.
Doing the same when the switch is connected to the Philips Hue bridge, it will result in brigthen/dimming the light.
Question is:
How come this isn´t working when using the switch in openhab (Zigbee)? (Or if it works, then how??).
I’m not really sure what the issue is that you’re referring to? 
If you had a sniffer, you could 
What exactly isn’t working?
Long/short press on one of the buttons to control dimmers (sliders in openhab).
As mentioned above. I seek the function to be able to use this switch the same way it´s functioning when connected to the philips hue bridge - ie dimm/brigten any dimmable light/dimmer through openhab.
But also as mentioned, it requires that openhab can somehow get an value from the switch (based on the time between the press and release) to be able to controle a slider, which then will controle another dimmer or dimmable-bulb, or even any other items, based on a number value.
I can´t see how this is possible, when openhab don´t undertand press-and-release/short/long press etc.
If you know how to, then please tell me. I have searched for such an option since I started openhab, since this is the way my wired IHC dimmers can be made to work. And I believe this is the feature Chris (the thread starter) is seaking as well - a wireless switch which dimming/brigthen bulbs, when he push and hold the press on the switch. Just like Philips Hue Dimmer Switch is working, when it´s connected to the Philips Hue bridge.
EDIT: Just to make it clear. This is the switch i´m referering to.
https://www2.meethue.com/en-gb/p/hue-dimmer-switch/8718696743157
When connected either directly to one dimmable hue bulb or connected to the bridge, it can dimm or brigthen the light.
This function is not possible when the dimmer switch is connected to openhab through the zigbee binding. Or at least I could not find this function.
Sorry - I didn’t realise that this was specifically related to a ZigBee question since the initial question you asked me was relating to ZWave and some other bindings. I don’t support this in the ZigBee binding at the moment.
I thought this was an general “impossible feature” in openhab, mainly due to the IHC binding doesn´t support this as well. (these are the only systems I know of using long-press for dimmers). I havn´t tried any Z-wave switches yet, but if you can point me in a direction, I´m interessted in buying one for testing.
The original thread starter seek any wireless switch which support this function, as far as I understood his request.
There are many wireless switches available, and if you use the same technology (eg if you have ZigBee bulbs, then use ZigBee switches, if you use ZWave bulbs then use ZWave switches) this it is not too hard. With ZWave, just set up an association, and ZigBee is fundamentally the same, but Ive not added the ability to configure this in ZigBee yet (its called binding in ZigBee terminology).
For ZigBee, some nice switches come from Ubisys,
If you use different technology, then you have to deal with the issues mentioned above with rules etc - it should work fine in most cases though.
In z-wave the dimmer switch works through associations to the z-wave dimmer, but not through openhab. Is that correct understood?
Like this one:
Correct.
Is there any specific reason why it doesnt go through openhab? (except openhab cant handle it, I guess… but why). It kinda makes the smart part of openhab a bit obsolete, and not very smart, in my opinion.
It may sound odd, but beeing able to control switches (push-buttons that is) in a intelligent way, opens up alot of very smart oppotunities.
In IHC push-buttons can be programmed to do almost anything. The IHC controller can sense wether its a short press, long press, mutiple press, time-press, (ie holding the press for 1 second - do something. Holding for 2, 3, 4 or whatever seconds - do something else. The push-buttons itself is just a “stupid” non- intelligent push-button, which sends a signal whenever the button is pushed. All the magic goes on in the controller programming.
I fail to understand how come this isn´t possible in openhab, or at least I havn´t figured it out.
Push-buttons should be standard defined just as well as switches, contacts, dimmers etc. If they were, z-waves switches could be used to dimm zigbee dimmers, or any other dimmer, and the other way around.
In a principal manner, there is not really anything in the IHC controller which openhab shouldn´t be able to do as well, without having to to make rules, codes, scripts etc for it. Comparing to IHC, openhab IS a controller just as well. And it can become alot more powerfull.
Because it is better as it is direct and avoids any issues with system reliability. If you want it to go through OH, you can of course program that as well.
Not very smart? Really? This is quite a powerful feature of ZWave (and also ZigBee has the same functionality). You always have the option of programming the commands to go to the controller if you want to use rules, but direct associations adds a lot of potential power.
If you don’t like the concept, then don’t use it
I don’t know IHC so can’t comment on what it does. As I mentioned earlier though, there are also ZWave switches that do this.
I understand that, but these issues should openhab be able to handle without any hassel, if a 12 year old controller can do it.
It´s not very smart, as it makes the idea behind openhab obsolete.
I do not mind it´s an option. But I fear, in the particular matter, it could be one of the reasons why openhab cant handle push buttons. And again, using direct associasions, you cant use a z-wave switch to controle a zigbee dimmer or visa versa.
I dont mind the concept. But I don´t see why it shouldnt become any better.
Ignore IHC, it was just meant as an example from another system. The fuctions mentioned was my point of view, not the particular system (IHC).
Direct associated or through openhab?
openHAB CAN handle it. Associations are a feature of the protocol so that the system will continue to work if the controller is not working. If you don’t want to use it, you don’t need to. It’s up to you.
No - it provides additional options. Again, if you want to run everything through OH, then it is up to you.
I have no idea what you are referring to. It has nothing to do with OH handling pushbuttons. OH can certainly handle pushputtons without problem.
I think you’re getting off track! It’s a feature, like many others, that you can use or not.
Yes - both. I don’t think you really understand things well here. Sorry if I’ve not explained very well.
Okay, I thought you meant the feature only worked direct associated.
If it works both ways, there is no problem…
But…
I fail to understand how to define a push-button in openhab then - ie a push-button which is able to sense the press, time and release, wether its a psycical push-button or a virtual push-button from sitemap/openhab app.
The closest I have seen is a rule for a push-button, using a fixed time (press and release, simulation ON/OFF). But using this for dimmers, is not really usefull.
As said, push-button is not standard defined items like switches, contacts, dimmer etc. I wonder why.
Hi Kim,
I think the issue of the push button breaks down into two levels of the discussion. Physical and logical.
The IHC system if I understand correctly is a physical or hardware system that starts sending a signal when you press a button and then sends a stop signal when you finish (or it just stops transmitting the press signal).
This is pretty easy to handle in OH at one level in that you can detect a start and stop from a switch and put logic in place to react. I do this with a Xiaomi mini switch which reports short-press for press and release long-press and long-press release. Although I haven’t tried to use it to control a dimmer as lag times etc would probably make it a real pain to get the levels right.
It is much harder, if at all possible to do the same through OH at a purely logical/software level as I haven’t seen interfaces on the UI’s that would be able to report a press and hold type logic (I could be wrong, I haven’t tried everything that OH is capable of 
). So from this perspective I think you are right and OH can’t handle that.
I think Chris’s point is that if a device can report to OH a state of long-press and release then OH can handle it and act according to the logic you then provide.
Hi John…
You´re right about this beeing physical and logical.
I have given my previous messages a few thoughts, and I´m sorry I was a bit too harsh on OH regarding the ability to understand pushbuttons. Ofcouse OH can understand pushbuttons just fine.
The problem lies in the logical part when it comes to controlling an dimmer item, wether or not its from a pushbutton or anything else.
To break it down to a small logical explanation, which hopefully explain where I see the missing feature of openhab:
Physical devices:
A pushbutton connected to openhab.
A dimmer defined device connected to openhab, (any dimmer defined item)
Logical programming. For single button control - One way to control a dimmer item by the use of a pushbutton.
- Short pushbutton press (ON…(short time in ms)…OFF)
Turn ON the dimmer (100% or any fixed value set by the user, as this value could be use to set a scene). If dimmer state is ON, turn it OFF. - Long pushbutton press (predefined longer time in ms) (ON…(minimum ms longer time HOLD)… until OFF or value reached minimum/maximum.
Start dimming process at a predefined time, (ramping time). If dimmer is ON, start dimming process from that possition/value either up or down (dimm/brigthen).
Step 1 is just a simple ON/OFF send.command(value/ON/OFF).
Step 2 is the missing part, (which I cant seem to find a way to handle).
I believe this or something simular should be a standard feature (operation) of any Smart Home System, wether or not it´s a pushbutton, contact or anything else, the same way it´s possible to make use of send.command(number, value ON/OFF etc), using a rule in openhab.
Like a send.startdimmingprocess or something simular, with an option to set the defined “ramping time” in time value of ms (I hope ramping is the correct english word for controlling the time it takes the dimmer going from 0-100).
Whats needed is openhab to understand the difference between a short press is a long press. This could be somehow predfined for the specific function (Dimming function).
Second openhab needs to be able to control the time it takes to dimm/brigthen the dimmer. This should be a user-predefined value, as this may be different for each individual. Someone like to dimm/brighten fast, others want it to go slower.
Both requirements could be static set though. But it makes it more flexible leaving it open for user to decide, at least for the ramping time.
A feature like this, one can make use of the dimmer function in other operations as well, like volume control or anything else which can make use of a dimming function.
If this really is a missing feature of openhab/eclipse, It surely makes me wonder why. It cant possible be due to hardware issues, since its a peace of cake for an 12 year old controller (the IHC controller). There has to be some logical explanation for this.
If it´s my lack of knowledge and experience with openhab, then I´m very sorry for taking up you time. But I have search for this function, and I can´t seem to find a solution.
I think the thing here is more about the implementation.
In OH, for the type of thing you are describing the slider is generally used, which maps to the Dimmer type item.
The type of ramping (and yes that is a perfectly good word to use for this) is not handled natively in software.
In some z-wave dimmers there are parameters for the speed at which the brightness changes.
And there a quite a few examples of ramping up and down lights to simulate wakeup times in the morning like sunrise or down in the evening for sunset, etc. I think the real issue you are experiencing is that the standard UIs that are effectively addons to OH are mainly web-based and do not really lend themselves to provide signals like the hardware based solution you were used to, thus the use of the sliders and then the individual hardware (light bulbs, dimmer switches, etc) respond to the commands sent to them from OH.
There would be nothing to stop you, for example, writing a rule and using a proxy Dimmer item to set the level you want to change to and then control how fast it increases the value to an actual item that controls the light bulb. You would just have to set your own increments (based on what the bulb can handle) and speed (by introducing delays between each command sent).
Personally, I have always been happy with the default sliders and haven’t spent much time on anything like you have described, but my system is fairly large so I haven’t had the inclination to look at thing that weren’t necessary for my setup.