I’m planning a complete new home automation system. After doing a lot of research, OpenHab seems to be my preferred platform. Please excuse if this post may not be at the right place. I could not find a “general” or better fitted forum - admins please move the thread if inappropriate.
Every room in my place will get a wall mounted main control panel, mostly used for lighting, temperature control and such.
Now OpenHab offers a variety of interface solutions like habPanel. It seems to be nice and easy to build and configure for touch screens.
My most basic questions are:
How REALTIME can I control dimming lights with touch panel sliders?
Will this be hardware (server / client) related or at all possible / impossible with OpenHab?
The question might sound strange for some. But to me, near real time response is important for buttons / sliders when controlling / dimming lights.
WHILE I move a slider, I want immediate response / change.
Most demo videos I found so far show LED lights changing through habPanel and such. On all of them, the change is done as soon as the button / slider is released - Not what I need.
Some additional background for my planned setup:
Server will run in a decent performance linux VM, no raspi
Panel clients are hard wired 1gbase-T, no wifi
any recommendations / experiences? Is OpenHab for me or not?
Well it’s as instant as can be. Yes you need to release the slider because that’s how browser frontends work to detect input, and any packet based system needs some sort of trigger information when to transmit a new command packet.
To expect that sort of instant (or rather “continuous”) update capability from a packet based system IS strange.
If you want to have that, you need to hardwire the (physical) input to the output. Or accept compromises such as the need to release or smallish delays.
Note that’s no openHAB limitation. It’s the same e.g. inside Hue or Tadfri, and it will be like that with ANY packet based lighting system, no matter if wired or wireless and if packets are on IP, WiFi, ZigBee, ZWave or KNX level.
Then again, it’s a rather academic question as in practice it’s usually working reasonably well or won’t apply
as it’s a corner case anyway - real home automation is not about interactive lights dimming or color switching from a smartphone or panel.
That is just for the show, you won’t be wanting to use that any more after a couple of months of showing to your friends and/or you will move onto use pre-stored scenes or rules to auto-dim/auto-color lights based on environment information (light-level, time of day, presence etc).
The topic is not really about automation in the meaning of logic - I understand that. My goal is to use OpenHab as central “controller” - not just for the “automation” part. I want the ability to easily create screens and use the automation logic behind.
What I don’t really understand is your explanation about package based systems. Take DMX as an example - it is also package based and real time. Of course, by the meaning of “real time” I always talk about felt response. 100ms is fine for my purpose, 1s is not.
I just wonder what the limiting factor on “felt real time” response is. Server performance? Networking? Or panel client performance (which I can’t imagine)?
It however seems that I just have to give it a try and take a deep dive into OpenHab and it’s Front- and Backends.
the input side device waits to transmit its packet until it receives a trigger. That trigger could be to release the slider in the Web UI. Some HW devices have timer based triggers builtin so they send a packet within say 100ms of a value change. But there always is a delay before the first packet is sent (except in special cases where the protocol uses START/STOP packages, but HW dimmer and panel input devices usually don’t do that).
transmission delay (depends on network(s))
gateway and general processing delay (if you have different technologies on input and output sides, OH needs to work as a gateway, i.e. to convert those packets in addition to general processing)
Now 2) and 3) cannot be avoided, but most of the time they’re not critical.
Most of the time it’s due to 1) it’s about the trigger point, i.e. how long does it take the input device to send its first packet after you pressed the button.
If you use a browser as your input device, that’ll be no sooner than on slider release.
There are ways to get a slider to send change events
I don’t use my UIs to control the house (Only a light or two) and sometimes to override the heating
So I won’t delve into the changes in code, but it looks like it’s possible to create a slider in HABpanel that would send updates to OH on input rather than on change. Now, as HABPanel use the HTTP API you may end up flooding the API with requests but a least it looks like it’s possible.
I am sure that some js/htlm wiz can come up with something
All right - If OH is not surprisingly slow, I don’t see problems here
That’s my thought too. As I understand, HapPanel is JS based. It will probably be possible to implement a small hack / hook, maybe with some timed filter function to not send every mm moved. Should not be too difficult
Interesting question: Are there benchmarks on OH’s HTTP API? Did someone already do that? I would be interesting to see / compare the handling capabilities of a OH server. Could this be done using a simple GET query and (for example) apaches AB?
Of course there are, half of today’s web works that way.
But the basic OH UIs do not use JS, plugins or similar techniques…
And yes, of course you can build your own UI to use the API.
Bottom line though is that’s impossible to change for you as a user, or it’s a lot of work and not worth the effort because there’s so little demand for it. If there had been a substantial number of users to ask for that, probably some UI developer might have added that in the past.
UIs are no development focus just like home automation doesn’t mean to switch your lights with your smartphone.
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
9
Hi
I think I know where you’re coming from
If you’re after instantaneous responses, step by step, then an interface that monitors your inputs ms by ms is the only way forward.
But who wants to hang a half Hog or MagicQ desk on the wall(s)…
Ummmmmm
Now I think about it…
Some MagicQ outboards around the place would be Uber cool
Hmmm, it seems that at least HabPanel (the one I favor so far) is build on JS libs (AngularJS / Bootstrap). That’s easy to patch.
I wanted to take a look at Classic UI but I can’t even find the code in the OH repo
It will take some time to dig into all this. Especially Java / Eclipse. Not my thing yet. But I will get used to it. And yes, to be honest, being Java based was my biggest concern with OH.
I don’t think thats needed. A bit event-driven JS will do that probably without overkilling an HTTP based API.
No, I’m not a light guy . But having some pretty, fast, virtual faders seems like a must to me.
But I think thats going OT here in the HW Forum. I will setup a decent fast server anyway and then just see what HW I need for my panel clients to run smoothly.
It’s in the Eclipse Smarthome Repo. It really isn’t maintained anymore. BasicUI would be a better choice to look at if you wanted to.
As for what you are looking for trying, you will want to avoid running any Rules based on these dimming events. You will likely overwhelm the Rules processing threads with an event rate that fast.
. But having some pretty, fast, virtual faders seems like a must to me.