As you say, most often we will be using a slider for control a dimmer. And it will work just fine in many situations, depending of the dimmer though. There are different kinds of dimmers. Some works great with sliders.
But what if you need to control a dimmer which requires a push-button function (press-hold-release). This is where things get complicated. I havnt figured, how to deal with this? Searching the community, I can´t find anyone dealing with this in some way, which makes me think, this is an impossible feature of openhab.
Could you give an example of when you would need that as compared to a plain dimmer?
Also, do I understand correctly that your complaint is that the UI doesn’t give you the press and hold or do you mean if you have a switch that is capable of doing it you don’t know how to represent that within OH?
Lots of dimmers, rollershutters etc is beeing controled by pushbuttons.
But in general. Anything which is controled by a switch/contact with a spring, (a pushbutton).
I know, it would require some specific I/O interface between openhab and the actual device itself (ie dimme, rollershutter etc). And this is exactly what IHC is. But I suspect other I/O interfaces/devices would have the exact same needs.
Actually both.
I cant figure how it´s possible to create or program a pushbutton/switch with the real human sense of touch in openhab. It sure can be due to my lack of knowledge. But I have searched for it, and the best I can find, is a pushbutton rule which set a fixed time for the switch going OFF. This is, in my opnion, not a pushbutton. It´s a timer- switch started by a human, but ended by openhab.
I hope this makes a bit sense. I find it rather difficult to explain.
Correct but the model for OH is that a new binding is written for each type of hardware eg. Chris has done a great job writing binding for z-wave and zigbee. I personally use the z-wave binding for all my shutters and many of my lights. These provide the interface to the hardware but when you control the level of the lights, shutters, etc you use the sliders in the OH UIs and the switches connected to the devices on your wall which then report their status back to OH through the binding.
The IHC is just another type of hardware and would require you or someone else to write a binding to get the best user experience. Otherwise you would need to use one of the hardware technologies supported by OH already. But it isn’t true that OH can’t do it, just that OH has no support for IHC.
For your physical device I have covered it above.
For you to be able to get a push/hold/release interface rather than using a simple slider as is available in the existing web or app based UIs, you would probably need to design and build your own UI.
Personally I don’t think that it would be possible in any interface other than the physical one to get a good user experience from this in the way you describe and that is not limited to OH.
Once you try to implement such an interface you will hit problems with network latency, message handling within whatever binding/plugin you use for the device on the server end. Time for rules to be interpreted and action and simple contention with any other devices running through the system. And if you have a system that grows to any size these will become worse. It is next to impossible to get an instantaneous response from something that is not directly connected physically to your controller.
What you have said makes sense and you did a really good job of explaining.
A summary of what I have just said in a long winded way above would be that OH can do what you want, to a point, but it requires HW that will give you the push-button on your wall, a binding for OH to integrate with the HW and the acceptance that a push button control is not practical for an interface through web/app/tablet/smartphone etc. which I would assume is why after years of building OH the developers have the slider interface in the UI.
This isn’t something OH, or any core system can do. This information comes from the hardware. Only the hardware (ie the switch) is able to differentiate this information, and pass it to the core system.
Take a switch for example - if that switch just provides ON/OFF, or PRESS information, it is not possible to do what you are suggesting. The switch must provide DOWN and UP information so that the core system can process this as you suggest.
If you use a switch that provides this function, then of course OH can use it. You would need a rules, but it is no great problem to use this information. This is a feature that ZWave switches can provide through the SCENE class - you just need to get the right switch if this is what you want to do…
IHC internally support short and long presses (etc), but push buttons are boolean values in IHC SOAP interface which IHC binding use. Boolean have only two states; true or false.
In IHC version 2 binding I have implemented short and long press emulation in the binding. Binding measures time between boolean value changes and send trigger signal accordingly.
Accuracy is not perfect in millisecond resolution level, but should be fine for short and long press detection.
You should be able to handle push buttons in different ways:
- Create functional blocks in the IHC side which separate short, long press or double press (or any other functionality) to own variables, which are then monitored via IHC binding.
- Use openHAB rules. Start timer (e.g. 100ms) when push button changes from OFF to ON. When timer expires, check if push button state is still ON. If yes then send new command to item (e.g. INCRESE) and start timer again. If push button state is OFF, then do nothing (cancel timer).
- Use IHC v2 binding trigger functionality.
I think you misunderstand.
There is already an openhab binding which is working just fine for IHC. It does parse on whatever information beeing send from or to the IHC controller. ie… When I push the psycical pushbutton, openhab receive ON just fine. And then I release the button, openhab receive OFF just fine.
The problem is, I cant define a “real” pushbutton from within openhab. I can use a rule and a fixed timing for openhab sending the OFF signal to the IHC controller. Or make use of an standard switch, which requires two “clicks”, one for ON and one for OFF.
Doing so, IHC will received the ON/OFF just fine and can control the wired (DIN rail) dimmers.
But in a principal matter, this is not a pushbutton in either case, cause either its a fixed timing and not my human touch, or its a two function operation, (1.clik = ON. 2.click = OFF).
I fail to understand how come this has anything to do with the UI, except the UI would have to be able to understand, when the button is pushed and release, and the time inbetween.
The catch may be, just as you pointed…
I agree, it may turn out beeing a very bad user experience. Specially if the user cant set the threshold for the pushbutton and ramping time for the device to be controled.
There´ll probably always be somekind of a short delay, from the time the user push the button, untill the UI sense the touch, and returning the actual ON onto the controller (openhab) for openhab to send the ON futhur on, while the UI still continues to either hold the ON signal, or wait until its receives an OFF signal.
This may be the reason for this beeing impossible. At least this is what you and most others tells me. specially when the UI is a touchscreen kind of UI.
But what about wireless switches then?
I dont get it!
I fail to understand why the switches cant provide the most simple information (ON/OFF) to the core system, and then the core system make use of this in whatever way.
Or I simply dont understand what you say. This is the most simple act of communication (regardless of the interface, wired or wireless).
Why do you explicit need it to be UP/DOWN rather than ON/OFF?
In a principal matter, it doesnt matter. ON/OFF or UP/DOWN. What matters is for openhab/core system to distinguish between:
- When switch is pressed (contact closed).
- And something else than 1. when the switch is released (contact open).
Add a spring to the switch, gives a third situation:
- switch pressed and hold (contact closed for X-time)
Then the core system, (openhab), can make use of this in whatever way it want to… (ie 1. = Start brigthen until 2… (If receives a new 1. within x-seconds/ms/whatever, start dimming).
This rule/principal is a typical way of dealing with wired dimmers, which is operated but ON/OFF signals/puls, controled from a pushbutton.
Using scenes or sliders, the device has to be able to make use of these informations. A dimmer which is controlled from a puls, can´t make use of scenes or sliders. You cant parse on a decimal number. They´ll need a puls (ON/OFF). And the timing (threshold, ramp time, ie how it behaves when receiving ON/OFF etc) is set within the dimmer or should be controlled from the core system, that is, only if the core system got a clear definition for the device…
I´m a bit worried here .
Am I the only one who have ever seen and work with wired dimmers, and know how they´re controlled? It´s not just IHC. There are many of those bastards out there 
Ahh, thanks Pauli…
Will the above rule work in IHC binding 1 as well?
(I do have the version 2 installed, but have not had time to test it yet).
Call it what you like - you need to know if it is PRESSED or RELEASED. Somehow, you need to know if the user is holding the button down - ON/OFF doesn’t provide that information. If it was a toggle switch, then maybe this can be inferred, but most switches provide FUNCTIONAL STATE - ON or OFF, and not the state of the button.
Without knowing the state of the button itself, I believe you can not do what you are suggesting.
Agreed, but what I’m saying is that most switches don’t provide this information. If you have a switch that provides this, then you can do what you are suggesting - no problem.
If you have a wired switch, then you have direct access to the hardware. Most wireless switches don’t provide this - they provide the functional state as there is a microprocessor inside that provides an abstraction of the hardware state.
I´ll take you word on it, Chris… I think it´s odd though.
Yes.
Apologies Kim,
I missed that the binding exists. My answers were based on it not already existing, which is why I was saying it would be necessary to have a binding.
Given that I agree that Pauli’s response is the correct one.
No worries John… I wouldn´t suspect anyone to even think of IHC systems, unless they had the system.
About Pauli´s respons… It may be the correct way regarding the IHC system… But I still believe the definition of a switch should take placed inside the core system, (openhab), which would make it alot easier dealing with it. If it was, there would be not reason to create a rule, just to know, when a switch is off, no matter if it´s a physical or logical switch. But thats just my opinion.
Now I´m going to try Pauli´s suggestion for the rule for a push button. The check to see if the button is still on, is what I seem to have been missing totally, which is why I only got it to work using a fixed time setting. I think it´s going to work… Now I´ll go troubble someone else in a new thread regarding this rule 
I just remembered having a Philips Hue Dimmer Switch laying around (Zigbee that is).
I added it to my system (once again. * note at the bottom), to show, controlling a dimmer through openhab from this wireless zigbee switch is possible.
Unfortunaltly this is in no way a real push button, but it can send ON and OFF signal by the use of the I/O buttons.
Using a simple rule, and by the use of this Philips Hue Dimmer switch, I can control my IHC dimmers. However, because this Philips Hue Dimmer switch is working as a two button switch, I need to make use of both buttons like this:
To start brigthen or dimm, I push the (I) button.
Dimmer Switch send ON to openhab.
Openhab send ON to my IHC dimmer.
IHC dimmer starts brigthen/dimming.
When reach the light level I want, I push the (O) button.
Dimmer Switch send OFF to openhab.
Openhab send OFF to my IHC dimmer.
IHC dimmer stops brigthen/dimming.
Now this is rather obvious, since this switch is sending ON/OFF using the two buttons. Exactly the same can be done from within openhab UI´s using a standard switch.
But its quite a lot of pushing buttons, which makes it abit annoying, specially if light level havn´t reach the wanted level in the first go. Then I have to start over in both “directions”.
But it works, and it´s actually working pretty fast and smoothly too.
(Please note, the reason why it´s running smoothly, partly got to do with this going through the IHC system. The Philips Hue dimmer switch was mapped to the same resource as a wired IHC switch (push button). This way the IHC controller can´t see if it´s an outside switch or an inside switch.
When the Hue Dimmer switch sends ON to the IHC controller, it´s actually the same as if I pushed and hold the IHC push button. When Hue Dimmer switch sends OFF, its the same as me releasing the push button.
The actual dimmers in this test was a IHC DIN rail Dimmer model UNI400 IHC/SA, (which requires 24volt DC to be controlled). And a UNI250 (1-module) wireless dimmer as well. Both worked the same.).
Chris say no Z-Wave switches works that way. Thats weird and very surprising, in my opnion, cause:
A switch can be either a ON/OFF thing or a OPEN/CLOSE thing. It really cant be anything else. If companies behind z-wave and Zigbee switches is making switches behaving otherweise, I´ll say they´re messing around with the principal 
The least they could do is to make sure their switches can send ON/OFF or Open/Close. Then they´re free to add whatever fancy options they like.
Fortunatly, for wired switch buttons, there can´t be anything messing with the principal. It can be either open/close or ON/OFF. So to make sure - Always use wired switch buttons 
I did try controlling my z-wave FGD212 dimmer as well. No go, since this dimmer require a slider (decimal number behaviour). But the FGD212 can be hard wired to an potential-free contact (push button). Using a I/O system and a potential-free contact on a relay, there would be nothing wrong in controlling the Fibraro Z-wave dimmer from the Zigbee Philips Hue Dimmer Switch, or any other “correct” switch, wired or wireless going through openhab.
Enough testing for today!
- Note regarding the Philips Hue Dimmer Switch, I can not recommend using this in a Zigbee setup yet. For some reason, which is still unknown to me, after some time, (a coupple of hours) when not beeing used, it will no longer communicate with my coordinator (Zigbee). While writing this message, the damn thing stopped working again. Search the Zigbee binding thread for more information about other Zigbee stuff as well.
No - I didn’t say that. I said that there ARE ZWave switches that can provide these features.
Some other ZWave switches may provide this through Toggle switches (I know some Fibaro switches provide this.
What I was saying is that most electronic switches have a microcontroller, and may not provide you the information directly from the hardware, so it’s not a given that you can do what you want.
I can’t keep repeating this, but you need to know if the switch is held down or not.
I don’t seem to be able to explain this, so I will leave this conversation - sorry.
Sorry Chris…
I got the impression that this was common for z-wave switches.
Ok, there has been a lot of discussion, but my question is not really answered, let me restate and rephrase it based on the discussion:
I would like to remote-control openhab things through openhab. In particular it would be nice to have a hardware remote with a set of buttons that I can associate with certain presets in openhab (e.g. through scripts that react to the button events). Having a true hardware dimmer that can send its values to openhab would also be nice, but is not a must have. If this remote works via ZigBee, that would be nice, but it can also work via wlan.
Any hints would be much appreciated 
A cheap tablet running HABpanel comes to mind
There are a ton of wall switches, touch plates etc with Zigbee technologic… Try do a search for “zigbee wall switch” on Google, choose show as pictures.
The question is wether these switches/touch plates will do what you want them to using Openhab. I think it depence on the actual switch.
I tried with an Philips Hue Dimmer Switch. It works fine for ON/OFF, (* note ) using two buttons. Dimming using one button is a problem. And I believe, a fuction like a push-hold-release button will be a problem as well. But as other has mentioned, it may be part of the device it self. I personally dont think so, regarding Zigbee, but I could be wrong as I´ve only tried the Philips Dimmer Switch.
- note - there is a problem somewhere which is causing Zigbee communication to stop working on my system. But I believe this will be solved as soon we have had an sniffer connected, (or at least find the reason).
The Zigbee binding has to support the device as well, I think.
Yes, this is why I am asking specifically for solutions that work with Openhab the way I described. I am aware that there are tons of switches of all sorts, but I would wouldn’t want to blindy buy some.
As I mentioned in the original post, I do not want to use a tablet for this purpose. I already have a tablet in place, but a tablet is not a switch.