openHAB and local control

  • Platform information:
    • Hardware: Intel Q6600/8GB/Multiple TB
    • OS: Windows 10
    • Java Runtime Environment: latest 1.8.0_191-b12
    • openHAB version: 2.4
  • Issue of the topic: requesting guidance for having primary functionality be local control of devices in the home

I have been using X-10 devices in my home for many years. Now, I am looking at updating some things and taking advantage of features that will integrate with cloud services. However, after investing money and time into setting up SmartThings and a Philips Hue bridge and getting my current X-10 devices to work and suffering from a Samsung SmartThings outage and delays in lights coming on or off, I am looking into alternatives that will provide reliable local control and still allow access to advanced capabilities that do rely on the cloud, such as IFTTT, Google Assistant, etc.

I am currently in the window of time where I could take everything back that I have spent in the last few weeks on the Philips Hue and SmartThings hubs, bridges, sensors, light bulbs, etc, if needed.

I would like to know, though, if I can use the Philips Hue bridge to provide local control of the Philips Hue Zigbee devices and other Zigbee devices, such as motion detectors and buttons from Samsung SmartThings. Currently, I do not have any Z-Wave devices, but would look at those for possibly replacing X-10 devices in the future.

With my current devices all being Philips Hue light bulbs and motion sensors, Samsung SmartThings motion sensors and buttons, and X-10 devices, can I do all of this with local control and openHAB and do it reliably? If so, I will continue down this path of learning openHAB and will likely take back the SmartThings hub.

1 Like

Based on the docs for the Hue binding it only supports Hue lighting devices. I don’t think you can use the Hue Bridge as a generic Zigbee coordinator.

The generic Zigbee binding does support some SmartThings devices. https://www.openhab.org/addons/bindings/zigbee/#devices The Zigbee binding is not as mature as many bindings in OH yet so just because the devices is not listed in that table doesn’t mean that it wont work. But the Zigbee binding does require a USB coordinator. The table at the top of that link lists the requirements for the coordinator.

Note that it appears you can control Hue without a Hue Hub through the Zigbee binding. I have a Zigbee coordinator but no devices yet so I can’t tell you how well it works.

Zwave is very mature and capable and is one of the more used bindings. Like with Zigbee, you will need a USB controller to communicate with them.

If you have a Cm11a controller, there is an X10 binding that will let you control those devices as well. There is an older binding that will work with Mochad as well.

I think the answer is yes but I can’t say definitively so. I don’t have any experience with any of these bindings or devices. You will probably need to buy some more devices (controllers/coordinators/USB dongles) to connect your computer to the technology to be controlled.

It can be done reliably but it will be a significant amount of work. I don’t want to scare you away, but OH is not a commercial system with 24 hour helpdesk support. It’s a framework upon which you build your own bespoke home automation system and a community of volunteers. So it is going to take some work and trial and error on your part and possibly some help from the community to get going. If that doesn’t scare you I think you can become very successful with OH and likely be very happy with the result.

For example my OH has:

  • Zwave: mostly switches and outlets with some smoke/CO detectors and door locks
  • DIY sensors and actuators built on RPis and ESP8266s communicating using MQTT
  • Sonoff relays also controlled using MQTT
  • Nest thermostat and doorbell
  • Google Assistant integration
  • Custom Rules to control lighting, alerting, and other home behaviors based on events like presence of cell phones on the network (proxy for presence detection), time of day, sun position, weather, etc.

Good luck!

The hue bridge also supports switches and outlets.
There are many compatible devices that are not ligtning devices.
Here´s a list of some compatible devices.

The Bridge does but does the openHAB Hue Binding? https://www.openhab.org/addons/bindings/hue/

The Hue binding supports all seven types of lighting devices defined for ZigBee LightLink (see page 24, table 2. These are:

Device type ZigBee Device ID Thing type
On/Off Light 0x0000 0000
On/Off Plug-in Unit 0x0010 0010
Dimmable Light 0x0100 0100
Dimmable Plug-in Unit 0x0110 0110
Colour Light 0x0200 0200
Extended Colour Light 0x0210 0210
Colour Temperature Light 0x0220 0220

I don’t see motion sensors listed and the rest seem to indicate that it only supports lighting. Just because the Hue Bridge supports it doesn’t necessarily mean the binding does.

If the binding does support other devices then the docs need to be updated to indicate that.

Why?
The On/Off Plugin Unit is listed and can be used for everything as long as it‘s not to powerful (see the specs).
I‘m using two of the innr plugs, one for a heating unit and one to restart my modem if the internet connection drops.

There is some serious development going on with the Hue binding by @cweitkamp as can be seen here

The type of a specific device can be found). Hue Motion sensors, Hue Dimmer Switches, and many OSRAM lights and switches are supported in 2.4.0 release. They are documented a little later in the binding doc :grin::

Device type ZigBee Device ID Thing type
Light Sensor 0x0106 0106
Occupancy Sensor 0x0107 0107
Temperature Sensor 0x0302 0302
Non-Colour Controller 0x0820 0820
Non-Colour Scene Controller 0x0830 0830

And Hue Tap switches and IKEA TRADFI switches are in 2.5.0-SNAPSHOT. Also hue-profiles are under construction/in alpha test phase. And more is planned according to Christophe…

The way the docs read implies only Hue Lighting is supported.

But I’m happy to hear that isn’t the case. It sounds like work is going on to improve support for other devices and the docs as well. Thanks @noppes123 for chiming in!

Do you know if the SmartThings devices OP mentions are among those supported or being added?

Understandable, it is a little out of order ATM. I will help @cweitkamp, if he’s ok with that, to improve the docs a little.

SmartThings comes with their own Samsung Hub. The integration between Hue and SmartThings can happen on the ‘network level’, bridge-to-hub so to speak. Hue devices have used the Zigbee LightLink protocol since 2012, but last year it has been extended to also support the upwards compatible Zigbee 3.0 protocol which makes it compatible with a wide range of devices and adds new capabilities.

As far as I know, there is no specific Samsung SmartThings binding, only a Zigbee binding. But be warned: the degree of success with SmartThings devices seems to vary according to different posts here in the community. As I have no SmartThings devices, I can only help you so far…

@richard.w For now, I would suggest you use Hue stuff via the Hue bridge connected to OH and SmartThings using the Zigbee binding. Then in OH you can do all the magical and smart things. :grinning:

1 Like

Yes, very much appreciated.

@richard.w Regarding the topic, you maybe want to have a look into the deCONZ binding too.

Thanks, everyone, for the responses. After more continued testing with what I have, I believe I am going to stick with the Philips Hue bridge and compatible devices, openHAB with no Zigbee/Zwave dongles for now, and my X10 devices as these all provide local control. I may take back my SmartThings hub or I may just use it for things that I do not need to depend on to operate quickly and use the convenient features. Anything needing a fast response (local control) will be through Philips Hue and openHAB and X10, with openHAB being the central brain / control center.

Not that I’m arguing against your decision, I’m sure you made a good one, but this sentence seems to be a non sequitur. openHAB with USB dongles also give you local control. It’s like saying I want to choose limes instead of lemons because limes are sour.

Note the use of “for now” in my paragraph. I already have devices with which I am going to continue my testing. I have many X10 light switches already installed in my house, and they are working well. I can get more X10 switches inexpensively. I don’t need any dongles with openHAB for now as openHAB with the Philips Hue bridge give me local control over the Philips Hue bulbs I have and their motion detectors and remotes also provide local control with openHAB and openHAB connected devices. If I should need something outside of Philips Hue that is not wifi, such as other Zigbee or Zwave light switches or outlets, then I will look at adding those things via openHAB and will then obtain the necessary dongle(s).

One thing I need to learn and is going to take some time is how to create some rules for openHAB that will work as nicely as the Philips Hue automation in their app. I have created one that works well for one hallway area, except that I have realized that Philips Hue motion detectors stay on when sensing motion - they don’t toggle back and forth between OFF/ON so I have to figure out how to account for this in my rules.

My comment isn’t consenting the decision. it’s just the stated reason (local control) isn’t a differentiator.

they probably receive repeated ONs as they detect motion so with the expire binding or a timer with a rule you can set up an Item to remain on from the first motion to a certain amount of time after the last movement. See Design Pattern: Motion Sensor Timer

The Philips Hue motion sensors do toggle ON for motion and then OFF again fairly quickly if there is no motion. However, if they continue to sense motion, they seem to stay in the ON state. Therefore, I have to come up with a way to account for a continued ON state, as well as the condition where it does toggle to the OFF state if someone leaves the room or is still for a bit and then motion is detected again turning the state back to ON. I will be spending more time in the community section related to rules, for sure. :slight_smile:

OK, perhaps the rule needs to be a bit more complex. You can kick off the motion detected switch on a changed from OFF to ON. But then set the timer on a changed from ON to OFF so that the motion detected switch remains ON for the given amount of time after the OFF is received.

Of course, this only needs to be done if the Hue motion sensor cannot be configured to have the timing you desire in the first place. If it can’t it’s far better to configure this in the device.

I’m a strong proponent of allowing devices themselves to be smart and let OH control them and use them instead of centralizing ALL the smarts in one place.

Thanks. I think I figured it out. It was a simple adjustment. I believe this rule will do what I need now so that it will not turn off prematurely. What do you think?

var Timer LaundryTimer = null
val int timeoutMinutes = 5 // choose an appropriate value

rule "Motion sensed in Laundry"
when
	Item hue_0107_001788774895_10_presence changed from OFF to ON
then
	hue_0100_001788774895_16_brightness.sendCommand(100)
	Stairs.sendCommand(ON)
	LaundryTimer = null // added this line
end

rule "No motion sensed in Laundry"
when
	Item hue_0107_001788774895_10_presence changed from ON to OFF
then
    if(LaundryTimer === null)
	{
		LaundryTimer = createTimer(now.plusMinutes(timeoutMinutes), [|
        hue_0100_001788774895_16_brightness.sendCommand(OFF)
		Stairs.sendCommand(OFF)
        LaundryTimer = null])
    }
    else {
        LaundryTimer.reschedule(now.plusMinutes(timeoutMinutes))
    }
end

It’s easier to read if you How to use code fences. But it looks like a reasonable approach except for one small thing. In your first Rule, you should first cancel the timer before setting it to null. Without canceling it the timer still exists in the background and will still trigger.

Oh, thanks. I was just doing some testing and noticing that the lights were still turning off at odd times based on when the motion should have been triggered. I will try that and will look at the “fences” info.

Okay. I modified my first rule to cancel the timer and have removed the “if,then,else” section from rule two since it really was no longer needed as my timer would always be getting cancelled and reset to “null” or completing and reset to “null” based on the actions specified during a motion detector state change.

var Timer LaundryTimer = null
val int timeoutMinutes = 5 // choose an appropriate value

rule "Motion sensed in Laundry"
when
	Item hue_0107_001788774895_10_presence changed from OFF to ON
then
	hue_0100_001788774895_16_brightness.sendCommand(100)
	Stairs.sendCommand(ON)
	LaundryTimer.cancel // added this line 2019-01-15
	LaundryTimer = null // added this line 2019-01-15
end

rule "No motion sensed in Laundry"
when
	Item hue_0107_001788774895_10_presence changed from ON to OFF
then
	LaundryTimer = createTimer(now.plusMinutes(timeoutMinutes), [|
    hue_0100_001788774895_16_brightness.sendCommand(OFF)
	Stairs.sendCommand(OFF)
    LaundryTimer = null])
end

I’m not going to say there is anything wrong with the code above. However, it is a good example to talk about the sorts of timing problems that could arise with Rules like this. Again, I’m pretty sure you will never see a problem like this. I just want to bring it up so you and future readers of this thread start to think about how Rules interact.

OK, now consider the case where the motion sensor has run amok and publishes a bunch of ON/OFF updates all within milliseconds of each other. You can and likely will end up with both Rules running at the same time with your ON Rule cancelling a Timer that the OFF Rule just created. I’m not sure we can predict how these Rules will behave in that edge case.

Another edge case is what happens if the sensor turns ON and never OFF? The light and Stairs will remain ON forever. That’s probably not a real problem as that will be a pretty good sign that something went wrong.

But, as I’m 99% positive these are not real problems you would face I won’t try to come up with solutions for these two problems. It isn’t worth the effort. My main point is to get people thinking about this sort of thing when they write Rules, especially when they start to see weird behavior or problems like their Rules stop running.

Now let’s assume we are seeing really weird behavior. How would we diagnose that it is one of the two mentioned above? The first place to look is events.log. Check what changes and commands the relevant Items are undergoing. If you see a ton of “hue_0107_001788774895_10_presence changed to ON” and “hue_0107_001788774895_10_presence changed to OFF” within milliseconds of each other you know you are experiencing the first problem. If you see a “hue_0107_001788774895_10_presence changed to ON” without an “hue_0107_001788774895_10_presence changed to OFF” after the expected amount of time you know you are experiencing the second problem. If everything looks as expected in events.log, then you know that there is some logic error in your Rules.