Comments (16)
I like scenario 2 that avoids the potential long delay.
My setup and usage:
I have one tap switch and 7 or so dimmer philips dimmer switches.
Personally i use a combination of apps. Homekit apple home app, Philips hue app, iconnecthue and iHue. Wife likes iHue. To set colors/temp though i use philips hue app or the other apps that work with philips hue api's directly (iconnecthue,ihue). I also use the ability to change scenes of the tap and dimmer switches.
from homebridge-hue.
After being woke up last night to a room with lights blazing, I vote for scenario 1. I'm only using HomeKit for my lights as well.
from homebridge-hue.
I assume that was due to a power outage? I'm afraid scenario 1 will be of limited use here.
Unless you have a no-break installation for the server running homebridge (and for the Hue bridge), it would take some time (minutes?) after power has been restored before homebridge is running again. Also homebridge-hue will have lost it's memory, including the previous light state. Even with dynamic platform accessories (issue #4), the accessory context would only be persisted when homebridge exits cleanly. I don't know if persisting the context on every change is feasible or supported by the homebridge api.
I'm not sure what light state the Hue bridge reports just after it has started, but I doubt it will show reachable
as false
. Depending on the number of lights connected to your bridge, it might take some minutes before the bridge will have polled the lights and report the power-on state.
Considering the above, I think the best way to cope with a power outage is simply to force all lights off on startup of the Hue bridge. On startup, the bridge initialises all CLIPGenericStatus sensors to 0
and sets the Daylight sensor when it connects to the meethue portal. This can be used to create a startup rule on the Hue bridge:
- Create a CLIPGenericStatus sensor
Boot Time
, say/sensors/2
, to store whether the startup rule has been fired. I use a status rather than a flag, to prevent it being exposed as switch to HomeKit as it shouldn't be updated manually. If you expose the status to HomeKit, itsLast Updated
characteristic will show the time the bridge booted. - Create the startup rule to set the status and turn off the lights when the Daylight sensor changes and the status hadn't been set.
{
"name": "Boot Time",
"conditions": [
{
"address": "/sensors/1/state/lastupdated",
"operator": "dx"
},
{
"address": "/sensors/2/state/status",
"operator": "eq",
"value": "0"
}
],
"actions": [
{
"address": "/sensors/2/state",
"method": "PUT",
"body": { "status": 1 }
},
{
"address": "/groups/0/action",
"method": "PUT",
"body": { "on": false }
}
]
}
from homebridge-hue.
from homebridge-hue.
Scenario 2 seems like it is a) faster, and b) more flexible for different use cases. The only drawback, and it seems like a big one, is that it requires a lot more work to setup. At the very least, it would need some thorough step-by-step walkthroughs and documentation (btw, happy to help with those!).
On a personal note, I never realized until last night how big of an issue this could be. My lights came on after a split-second power outage (Scenario 1 wouldn’t have worked in this case), and Siri on my Apple Watch was still offline due to the router coming back online, so I had to fumble around for my phone and manually turn the lights off. (As a side note, I’m looking into a UPS device to keep my router/hue hub/etc. powered on in this scenario) Meanwhile, all of the lights still would have been power cycled, so Scenario 2 seems like it would be very helpful!
from homebridge-hue.
Scenario 2 seems like it is a) faster, and b) more flexible for different use cases. The only drawback, and it seems like a big one, is that it requires a lot more work to setup.
Indeed. Scenario 1 has a lousy user experience, and 2 is very, very cumbersome and has some technical challenges: The solution of storing a scene with every change might wear the lights, as they store scenes in non-volatile memory, which has a limited number of write cycles. Furthermore, I still haven't been able to get rid completely of the occasional "ghost" effect, when light states haven't been updated properly (due to longer transition times?) when storing the heartbeat scene, causing the lights to flash or blink when subsequently recalling the heartbeat scene. I've actually kept the heartbeat timer on my Hue bridge disabled lately...
Maybe the best alternative of reacting to a power failure is to force the lights off as soon as possible after power has been restored. I think the Hue bridge Boot Time rule described above will take about a minute (for the Hue bridge to startup, connect to the Internet and set the Daylight sensor based on your location). That might be good enough when being away from home, but way too long when sleeping. And it won't work with deCONZ... Scenario 2 would be quicker though, as the heartbeat kicks in before the Hue bridge connects to the Internet. After a short power failure you would like the lights to be restored to the previous state, but after a longer failure, you would probably want them turned off.
At the very least, it would need some thorough step-by-step walkthroughs and documentation (btw, happy to help with those!).
I almost finished sanitising my scripts of (re-)creating my Hue bridge rules. I'll post them to my ph.sh repository when done.
Siri on my Apple Watch was still offline due to the router coming back online, so I had to fumble around for my phone and manually turn the lights off.
One of the many advantages of deCONZ over the Hue bridge is, that is let's you to pair the Hue dimmer switch (or any other switch like the Ikea Trådfri remote) simultaneously with the deCONZ gateway and with a group. That means that the switch still works when the gateway is down, albeit at limited functionality (like when the dimmer is used standalone, without a bridge). Instead of reaching for your phone, you could reach for the switch.
I’m looking into a UPS device to keep my router/hue hub/etc. powered on in this scenario)
That sounds like a great idea, but keep in mind that the lights won't be powered anyways. The main benefit of course would be that homebridge continues running and could react when power comes back on. Still, homebridge would need a signal that power is back on, other than looking at light power-on or reachable
state. In scenario 2, homebridge-hue or the Hue bridge would simply continue to recall the heartbeat scene every 5 seconds, so that could still be a shorter reaction time.
When running homebridge on a Raspberry Pi (the same running deCONZ anyways), the cheapest UPS-like solution (~ $20) would be a power bank that supports pass-through charging, in combination with some software that monitors the ethernet port to detect power failure/restoration, as described here. The easiest integration would be to restart homebridge when power is restored, and have homebridge-hue force-power-off the lights on startup (configurable though config.json, of course).
Bloody Amazon won't ship the mentioned power banks to the Netherlands, though. I did successfully run my Raspberry Pi with RaspBee board powered by a 2A Urban Revolt power bank (moving it next to my lights for touch linking), but that power bank doesn't support pass-through charging.
from homebridge-hue.
I have a completely new solution, which might be combined with either above or with something else. I run my lighting on UPS. Led bulbs are so low in power that UPS is an easy option. However, this does leave some issues. Whilst it is easy to move a complete lighting circuit to UPS, this is not easy with table lamps etc which are just connected to a convenient outlet. It does not resolve the eventual battery depletion of the UPS but perhaps additional batteries would. There are some accessories such as ceiling fans which are best defaulted off?
from homebridge-hue.
Interesting approach. However, here in the Netherlands, lighting and power outlets typically share circuits. The outlets are wired from the central lighting point on the ceiling.
I finally got a pass-thru powerbank, which seems to be able to power my Raspberry running deCONZ and homebridge for at least 20 hours. Checking for the ethernet link status (with no UPS on the network switch) seems reliable enough to detect a power outage and subsequent restore.
I haven’t tried any automation yet, but I guess I would be keeping a CLIP flag or status with the current power situation (normal, failure, just restored), and start broadcasting off to group 0 as soon as power has been restored for a minute or so. I need to check if deCONZ actually issues a broadcast for group 0 - some lights and plugs don’t support groups. Alternatively, I could create a resourcelink (cf. the blacklist) with resources to turn off on power restore.
deCONZ does have a Daylight sensor now, and it can be used for Boot Time, just as the Daylight sensor on the Hue bridge. The rules above work, but I find I’m restarting deCONZ way more often than experiencing power outages. I’m actually using a flag now, instead of a status. By setting swversion
to 0, and manufacturername
to homebridge-hue
, the flag will be exposed read-only to HomeKit.
from homebridge-hue.
One advantage of involving a UPS might be that it is very good at detecting a power fail and there is a NUT plugin for Homebridge that can provide status data to Homekit. However, you need a good use case to buy a UPS and unRaid/Plex is mine!
On a side note I'm very interested in your experience of deCONZ as I decided that it was probably the best solution to integrate some Fibaro modules (shutter controls) as the latest Fibaro kit is Bluetooth and the range would possibly be an issue. The older kit is reasonably priced but requires a bridge from Z-Wave and Homebridge!
from homebridge-hue.
On a side note I'm very interested in your experience of deCONZ as I decided that it was probably the best solution to integrate some Fibaro modules (shutter controls) as the latest Fibaro kit is Bluetooth and the range would possibly be an issue. The older kit is reasonably priced but requires a bridge from Z-Wave and Homebridge!
I have no experience with Z-Wave. deCONZ speaks ZigBee, not Z-Wave. There's various ZigBee-based shutter controls, but we haven't integrated any of them in deCONZ yet.
In my experience, Bluetooth (even BTLE) isn't the right protocol for home automation, it's simply not responsive enough. I have some Elgato devices (Eve Energy, Eve Door) that natively support HomeKit over BTLE. I haven't run into any range issues (they're close enough to my AppleTV), but it takes at least two seconds before the door sensor reports that the door has been opened. The ZigBee-based Xiaomi door sensor works immediately (and is five times less expensive). Similarly, when instructed to turn on, the Eve Energy takes 2 to 7 seconds to react. With the inclusion of fakegato-history in homebridge-hue, ZigBee based plugs are almost as functionally rich, and react immediately.
from homebridge-hue.
I haven’t tried any automation yet, but I guess I would be keeping a CLIP flag or status with the current power situation (normal, failure, just restored), and start broadcasting off to group 0 as soon as power has been restored for a minute or so
Using the Raspberry Pi UPS solution, I created an initial automation to power off the lights automatically after power has been restored.
- Make sure you've installed homebridge-hue (or homebridge-hue-utils) and that you've created a username for
ph
; - After installing
upsd
, add the following line to/usr/lib/upsd/power_back
. The script runs asroot
, hence thesu - pi
:su - pi -c "ph put /sensors/100/state '{\"flag\": true}'"
- Create a series of rules, using the script from
ph.sh
:$ . ph_rules.sh $ ph_rules_power 100
- Make sure, your Raspberry's WiFi is enabled, and run
journalctl -afn 1000 -u upsd
to monitor theupsd
daemon and unplug and reconnect the ethernet cable:$ journalctl -afn 1000 -u upsd May 09 12:13:11 pi2 upsd[417]: There is a power outage right now. May 09 12:13:11 pi2 upsd[417]: The estimated current battery charge level is 100 %. May 09 12:13:11 pi2 upsd[417]: There are 18:00:00 hours remaining before the battery will be empty. May 09 12:13:11 pi2 upsd[417]: If the battery should actually run empty, appropiate action will be taken. May 09 12:13:17 pi2 upsd[417]: The power outage is over now. It could be successfully bridged over by using the battery. May 09 12:13:17 pi2 upsd[417]: The outage lasted for 00:00:06 hours. May 09 12:13:17 pi2 upsd[417]: The estimated battery charge level decreased from 100 to 99 % during the outage. May 09 12:13:17 pi2 upsd[417]: The system could have run for 17:59:53 more hours before the battery would have been empty. May 09 12:13:17 pi2 su[30340]: Successful su for pi by root May 09 12:13:17 pi2 su[30340]: + ??? root:pi May 09 12:13:17 pi2 su[30340]: pam_unix(su:session): session opened for user pi by (uid=0)
- Check that the rules have fired:
$ ph get /rules "241": { "actions": [ { "address": "/groups/0/action", "body": { "on": false }, "method": "PUT" } ], "conditions": [ { "address": "/sensors/100/state/flag", "operator": "eq", "value": "true" }, { "address": "/sensors/100/state/lastupdated", "operator": "dx" } ], "created": "2018-05-09T10:09:47", "lasttriggered": "2018-05-09T12:13:19", "name": "Power 1/5", "periodic": 0, "status": "enabled", "timestriggered": 2 }, "242": { "actions": [ { "address": "/groups/0/action", "body": { "on": false }, "method": "PUT" } ], "conditions": [ { "address": "/sensors/100/state/flag", "operator": "eq", "value": "true" }, { "address": "/sensors/100/state/lastupdated", "operator": "ddx", "value": "PT00:00:02" } ], "created": "2018-05-09T10:09:47", "lasttriggered": "2018-05-09T12:13:21", "name": "Power 2/5", "periodic": 0, "status": "enabled", "timestriggered": 3 }, "243": { "actions": [ { "address": "/groups/0/action", "body": { "on": false }, "method": "PUT" } ], "conditions": [ { "address": "/sensors/100/state/flag", "operator": "eq", "value": "true" }, { "address": "/sensors/100/state/lastupdated", "operator": "ddx", "value": "PT00:00:04" } ], "created": "2018-05-09T10:09:47", "lasttriggered": "2018-05-09T12:13:23", "name": "Power 3/5", "periodic": 0, "status": "enabled", "timestriggered": 3 }, "244": { "actions": [ { "address": "/groups/0/action", "body": { "on": false }, "method": "PUT" } ], "conditions": [ { "address": "/sensors/100/state/flag", "operator": "eq", "value": "true" }, { "address": "/sensors/100/state/lastupdated", "operator": "ddx", "value": "PT00:00:06" } ], "created": "2018-05-09T10:09:48", "lasttriggered": "2018-05-09T12:13:25", "name": "Power 4/5", "periodic": 0, "status": "enabled", "timestriggered": 3 }, "245": { "actions": [ { "address": "/groups/0/action", "body": { "on": false }, "method": "PUT" }, { "address": "/sensors/100/state", "body": { "flag": false }, "method": "PUT" } ], "conditions": [ { "address": "/sensors/100/state/flag", "operator": "eq", "value": "true" }, { "address": "/sensors/100/state/lastupdated", "operator": "ddx", "value": "PT00:00:08" } ], "created": "2018-05-09T10:09:48", "lasttriggered": "2018-05-09T12:13:27", "name": "Power 5/5", "periodic": 0, "status": "enabled", "timestriggered": 3 }
- When testing with the network cable, you can actually observe from HomeKit that the flag turns on for some 10 seconds and then turns off again. Of course, on a real power outage, your WiFi will fail as well.
from homebridge-hue.
My Bad, too many things in my life. As you point out Z-Wave is for Fibaro and Zigbee is of course Hue. On the Zigbee front I search for reasonably priced wall switches and an interface (waiting for the new Philips partner products and an advance in the number of supported switches) whilst Z-Wave does seem to cover a lot of other stuff including the old Fibaro range. Totally agree about BLE, just tried a Koogeek door/window sensor and immediatley realised I need a Homehub to interface it!
Had two power outages the other night and providing the network infrastructure is on UPS a Siri 'all light off' works well. I have three Hue bridges operating which is a management problem. How would that scenario impact your solutions?
from homebridge-hue.
Hi, what about that? https://www.reddit.com/r/Hue/comments/9btzb6/hue_announces_poweron_behavior_hue_lights_will/
from homebridge-hue.
That's good news! Power-on to the previous settings, apparently through a firmware upgrade of the bulbs. I'll need to move all my Hue lights from deCONZ to the Hue bridge for the upgrade and then back again...
Nothing yet on the Hue developers forum, though. From the video (https://youtu.be/e6fkmQHZWpE) it looks like there will be a setting to choose between the current default power on behaviour or power on to the previous settings. We'll have to change deCONZ to provide this setting through their API as well, and maybe change homebridge-hue to expose this setting to HomeKit.
from homebridge-hue.
Philips say: Hey David, the new ‘power on’ option will be rolled out towards the end of the year. Since we will enable this feature on all the official Hue lamps that we have ever released, the roll out procedure takes some time. We will keep you posted when the feature is available.
from homebridge-hue.
The new firmware for the Hue bulbs is available here in the Netherlands. See dresden-elektronik/deconz-rest-plugin#1014.
As far as I can tell, at ZigBee level you can specify the power-on settings for state.on
, state.bri
, state.ct
, and state.xy
, either to a predefined value, or to the previous value (from before the light was powered off). Although I haven't seen any documentation, the power-on settings for on
and bri
seem standard: my IKEA Trådfri bulbs and ubisys D1 dimmer have implemented them as well. The current (previous) firmware for the Hue lights already supports the power-on setting for ct
.
I'm not sure if I need to expose these through homebridge-hue - you probably want to set them only once (of course, after playing with the settings initially). I think it might be sufficient to document how to do this using ph
, once deCONZ supports this. This already works for the Hue bridge.
from homebridge-hue.
Related Issues (20)
- $ (sudo) npm install -g homebridge-hue
- 0.13.67 version mismatch HOT 5
- Add artificially delay before turning off a scene switch HOT 2
- Homebridge flooded with logs? HOT 4
- Intermittent toggling between states of certain lights HOT 12
- error:0A00010B HOT 1
- Unable to update to version 0.13.68 HOT 3
- Reset Timeout parameter throws error HOT 1
- Log level settings HOT 3
- Hue Bridge: warning: not using recommended Hue bridge api version 1.60.0 HOT 8
- 2nd Hue Bridge needs manual pressing of button HOT 13
- Hue Zones to Homekit? HOT 3
- Trying to add an outlet HOT 7
- Unable to setup - Unauthorized HOT 2
- Hue Dimmer Switch don't show in new home architecture HOT 2
- No devices showing up at all HOT 6
- Many devices not reachable since today HOT 7
- HUE Wall-Switch Module new Revision RDM004 not working HOT 2
- Expose more precise Hue bridge daylight sensor status HOT 1
- Hue light group shows as Off even if some of the lights are On HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from homebridge-hue.