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.
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.
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 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 :
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.
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.
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.