I'll never understand why companies make such customer hostile decisions. I can't see any upside to this and I can't imagine what the discussion looked like when implementing this decision. My (admittedly cynical) guess is that it was one part "We're fielding a lot of support questions on products that aren't ours and our malfunctioning" and two parts "Our customers will be more motivated to buy Philips Hue products since they're already invested in the existing system".
The first argument is out the door because now they'll just get a lot of support questions around many more products that don't work. The second might happen for existing customers, but I'm now going to avoid this product as a future customer because compatibility is a feature, and for me, and I'd think anyone who is looking to purchase a tool that manages lighting/small electrics around the home, compatibility is easily the #1 or #2 feature. If there were a choice between a lightswitch that worked with a wide array of lightbulbs, and one that worked with only one company's bulbs, guess which one I'm buying?
Boss: We introduced Hue back in 2012 w/ a plan to lose money the first 3 years developing the hub, subsidizing partners, and getting our product out in the market. Tell me we're seeing a positive ROI now.
Hue PM: Hue is profitable, but only marginally so. Our strategy of making up the initial investment on $60 per bulb hardware is being undermined by cheap 3rd party lighting fixtures. Plus we're incurring costs responding to all of these non-hue connectivity and reliability issues.
Boss: We control a large enough market share now and most of the market is already heavily invested in our ecosystem. Cut off hub connectivity for these 3rd party products. People should not be using non-Hue approved hardware with our software. We're a for-profit company, not a government or a charity.
Hue PM: That won't go over well with the early adopters and the tech community.
Boss: I've already run the cost/benefit analysis. The tech community might be mad for a little while, but we've got our sights set on industrial and commercial contracts now that we've proved Hue's viability in the consumer market. Do it.
That doesn't seem like a fair view of the analysis.
If the real value was in the hub, and these other lights were getting a free ride on it, then the opportunity would be to charge more for the hub.
What is far more likely to be the case is that the support costs around problems caused by random third party components messing with the Zigbee network were exceeding the value of providing that support, particularly when you factor in that the customers they really wanted to grow wouldn't be using anything other than Hue's.
So, while blocking out 3rd party devices decreases the perceived value of the hub, the drop in perceived value is far exceeded by the drop in support costs. Easy win.
It's still hostile, but to a distinct use case, rather than their entire customer base.
It's a total dick move on Philips's part to "update" incompatibility into existing products that people already own and have spend money and effort to integrate. These people bought product with the expectation of compatibility, now they're out their investment because of Philips's selfish business decision.
Even they have elevated support costs, Philips's made their bed by offering compatibility in the first place for many years. If they want to remove it, they really should introduce a new model ("Introducing Hue 2.0: Now with less bulb compatibility!") and leave the existing customers unaffected.
> It's a total dick move on Philips's part to "update" incompatibility into existing products that people already own
Last year, Shimano (the bikes-and-fishing people) released a firmware update for their electronic shifting system which prevents 2012 (10-speed) parts from working with 2014 (11-speed) gear mechanisms. Literally, if you upgraded your bike from 10 speeds to 11, it worked when the hardware was released, but not after you installed the (irreversible) firmware update. This is with everything coming from a single brand!
> I'd be surprised if they didn't recharge it by pedaling. ;)
I'd be surprised if they did. A dynamo adds a noticeable load on the bike, and the people buying this are already optimising for small improvements. Adding a dynamo to power it would probably be a net negative for performance.
A dynamo doesn't actually add that much load to the bike, but they're heavy and invasive, the exact opposite of what an electronic shifting system aims to be.
I run a dynamo generator for lights on my bike. The datasheet says it steals about 7 watts of power. I'm a relatively weak cyclist, but I can put out 230W continuously for an hour. The dynamo doesn't matter unless you're racing.
That said I still have good-old-classic 10 speed mechanical shifting. It works so well I don't see the need to add another computer-based gadget to my life.
> They should generate power from the motion of the shift levers.
How much power would that really generate? You can't make them too stiff, since part of the reason people like electronic shifting is that it's easy to do when your hands are numb from cold.
Actually no--the Shimano and Campagnolo systems (the first two to market, and the only ones anyone really has yet except some pros) are wired. Look up "Shimano Di2." The battery lasts about 1000 miles before it needs to be recharged, and it can be charged via USB.
To be fair, it's the same as top of the range sports cars having automatic transmissions(like Bugatti Veyron). Top of the range automatics are just faster than any human could possibly be, so they are a natural choice at that level. From what I understand, all professional cyclists use electronic shifters because they are more precise and faster - one click always means one gear, while with a manual sometimes you can miss a gear or jump two at once.
Don't get me wrong, there is definitely such a thing as firmware crippleware, but being strict about compatibility with other devices isn't necessarily such a case, particularly in this case where random devices are disproportionately likely to cause all kinds of mischief.
In general, being more compatible increases the value of a device. When it doesn't, you've got some bad market forces at play.
I'm sure page 67 of the Philips Hue T&C states in 3-point font that Philips Hue is only compatible with itself and they reserve the right to pull the plug on third-party product compatibility at any time.
On the face of it, why do they do more than that? Just use the warranty to recommend certain bulbs and let the hobbyists run riot knowing the company doesn't back them up for this stuff. But at least it still can work.
I would think so, but then again, I also thought the class action suit against Sony's removal of OtherOS on the PS3 would have been a slam dunk. This is no different: the removal of a popular feature well after purchase.
That's basically saying that you can't expect anyone to profitably provide support for a device that anchors an "open" system. There will always be bad actors who screw up the network for everyone else (especially when you're talking about a wireless network), and "civilian" (meaning non-tech-savvy) customers will usually call the network hub manufacturer for support, because that is where they will see the problem, regardless of where the problem actually originates.
Put another way, if your analysis is correct, it presents a fundamental weakness in any standardized architecture that relies on a central managing device, which could prevent the development of a robust ecosystem with many vendors.
There will always be bad actors. Often you design a system to handle them in ways that minimize support costs.
Consider the case of 802.11 or USB or ZigBee. In general, most of the value of providing a device that works with any of those is a function of how well it works with any other device. The support costs are also a function of how well the device interoperates with other devices.
That pretty much kills the value of making a device that only works with a manufacturers own devices, and provides strong incentives to work with as many as possible as well as possible.
> What is far more likely to be the case is that the support costs around problems caused by random third party components messing with the Zigbee network were exceeding the value of providing that support
I'm amazed at the level of belief in Philips' honest motives after such a move. They just saw a large market of 3rd party bulbs emerging and saw potential profits for themselves, that's the most likely explanation with the available information. If anyone has financial details to back up claims of "need" for such a move by Philips, please provide them.
Philips has been investigated and fined for antitrust violations repeatedly. They don't really deserve benefits of doubt regarding predatory/unfair business practices without need at this point.
While this may happen in other instances, Zigbee Light Link products like these are 100% targeted at consumer markets. If commercial/industrial applications are doing a ZigBee controlled building, they're doing it with ZigBee Building Automation. (alternately, EnOcean, Enlighted, etc. which also target commercial markets with wireless lighting controls)
It's conceivable that they could carry the Hue brand into other markets, but the existing Hue Bridge that just lost compatibility is definitely not that product.
I should also point out that Philips owns Color Kinetics, the biggest player in commercial RGB LED lighting. It's very much not a market they need to break into.
Much to the rest of the industry's chagrin, CK holds a couple of fundamental patents on colored lighting by mixing red, green, and blue. Not that color mixing or PWM were new in 1997, but I guess they smushed together enough ideas that the patent office thought it was novel.
As far as I know, they do have some competitors (Lumenpulse comes to mind) but aren't under any significant threats in that market because every competitor pays them royalties anyway.
Not shown: the part where the Hue consumer product line takes a nose dive, resulting in an organizational shuffling, the loss of some jobs, and general agony and frustration on the part of everybody in the division except for the Boss, who moves on to another position because he/she was able to demonstrate how they squeezed profit out of the product.
Also not shown: when the current hub technology is discontinued and replaced with something newer and better and incompatible and you need to replace all the lights in your house unless you want to stick forever with the old hub. Ops, new lights and other stuff that talks with the hub won't work with the old one so you hope you'll never need anything new anymore. Probably not something somebody in this kind of things does.
FYI: it uses the ZigBee standard, so it is likely that it will always be compatible with some third-party hubs and lights. I also expect that newer iterations of the standard will have backwards compatibility.
That makes this choice of Philips worse: they implement a standard, but then choose to ignore devices based on (probably) identifiers (and probably introducing incompatibilities). It's toxic to the whole ecosystem.
I think that some of their marketing material stated that they were ZigBee-compatible. So, I guess I can now (theoretically) sue them as a customer.
Fine strategy until the universal controller app arrives.
After that, the same Boss would hope they should allowed their app to control third party bulbs, since that way at least they would have a brand presence, and by that way that would have allowed them to sell their bulbs better than others.
This is why I am betting on Amazon for the long win; the Echo is continually expanding to be able to control any device that connects to the internet, and Amazon isn't trying to push their own brand of bulbs (yet). They seem to be building themselves as the point of contact for humans to set off [whatever automated thing some other company sells].
Yet is the thing. See Amazon's discontinuation of Chromecast and Apple TV sales for a clear example of how Amazon will gladly leverage their ecosystem in an anticompetitive manner.
It's funny how in today's corporations it is in manager's best interest to make decisions that are profitable short-term but bad for the company long-term - the manager will be there for a reward, but long gone by the time consequences come.
Indeed. I own Hue bulbs, and the only reason I've bought more, after my initial purchase, is because they have an API that let other systems control my lights.
Currently, I'm using home assistant (https://home-assistant.io/) for controlling the lights, and if I ever buy other lights, they'd be controlled from there as well.
What should be interesting now is to wait and see if they lock down the API as well...
1. The costs they're incurring supporting non-hue compatibility might very well increase. Lighting is something people think they universally understand -- if it doesn't work when they expect it to, they call. In the rest of the "lighting world", people expect the lamp won't have problems working with whatever switch they plug it into. I still hear people confused about CFLs that don't work with their dimmers.
2. The large enough part of the market that they control might be large when that market is limited to "extremely early adopters of this kind of brand-new technology". The market will grow in many stages over the next few years and this is way to early to start giving people another reason to avoid your products.
I'm usually an early adopter of technologies like this, however, I've held off because there were only a handful of implementations out there and the use cases for them was still a "that'd be neat, but not worth the money". I've recently become very interested and will be buying something in the next 6-months, though this is making me reconsider that now.
I know I'm a future customer of this segment of technology -- not just lighting but upgrading my existing home automation system -- and I'm starting with lighting. I'm not, yet, a customer because I haven't found a good mix of "good product", "good interoperability", yet. So they've gained lock-in of all of their early adopters -- a very short-term investment[1] -- and caused the second wave of (in this case, also) early adopters to look elsewhere. They're nowhere close to the market that even high-end, non-smart bulbs command and they won't see much of it this way. People complain today about having to buy special bulbs for their dimmer switches; this is a whole other level -- you can't even use the lamp you just bought. No way someone like my dad is going to be a customer.
I can see how this might improve sales in the very short-term. It also might not. It will increase support calls. It will hurt their ability to get future customers and might even delay the next wave of adoption as people wait for fear of buying something that will become obsolete. These are all the things I'm thinking about as a person who really wants this technology, has the money to buy it, but doesn't have the money to do it twice. And I can live without it for a bit longer.
[1] Short-term because the people who are buying these for the most part have a lot of disposable income or a very small deployment, so switching to something else isn't necessarily as much of a lock-in as they'd like. And this product in particular, the primary consumer is tech folks -- they'll hack together the interoperability eventually, defeating the purpose.
Having been involved in a couple of these discussions, I'd say it is more like "Shouldn't we control this? Are other people doing stuff with our products that we don't control? That's bad isn't it? Let's stop them."
I.e. it's more about paranoid control than actual reasons.
I have heard similar discussions, mostly around support. Which is to say when a third party bulb doesn't work, who gets the support call? When you compute the cost and margin of a consumer device you have to include the cost of support as a burden on overall profit margin. If support costs eliminate profit margin then you start losing money and that sucks. What is worse, if you raise your prices to cover the support cost, the 3rd party bulbs look that much better and that just increases your cost. Sort of a catch 22
Actually, earlier today I wrote some MCU code to control my HUE lights, and I figured "hey, why not build a controller to make my christmas lights controlled by the HUE hub". Guess this news answers that.
Seen together with the Phillips Hue bulbs I have being noisy as hell, hue just became a lot less interesting.
I hope there will be an open source system and manufacturers whose bulbs can easily be integrated. Hopefully some that don't make a lot of noise.
I've got Phillips Hue bulbs, multiple zigbee GE bulbs that work (well until I update) with hue, multiple z wave switches, a nest. I've been able to control all of it using OpenHab running on a raspberry pi that us a z-stick zwave radio attached. OpenHab is hard to get running but immensely powerful. Especially with the Astro binding, you could for example determine when the sun is shining through a window and close the blinds for each window as direct sun starts shining through it. OpenHab 2 is in development and is supposed to be a lot more user friendly.
I'll never understand why companies make such customer hostile decisions.
I think it's because Apple more or less proved that the walled garden approach can be wildly successful and everyone is trying to copy them. Seems however that they are the only ones to have success with it.
This is probably the point where it all goes wrong. Like the game of deaf phone, by the time the idea reached the mind of students, it's twisted into an abomination, having lost the entire essence in-transit.
I was writing that on mobile so it was inconvenient to double-check if I got the name right (that's what we call this game in Polish anyway - "głuchy telefon", which literally means "deaf phone"). I see how this is fitting though :).
"Our customers will be more motivated to buy Philips Hue products since they're already invested in the existing system".
We all need to put our support behind the most open of the open source lighting control/home automation options! Then the open options will be the most compatible options. If we do it right, then proprietary bulbs will just work with themselves, and the marketplace will punish them.
I completely agree. And I'm surprised that any department within the company saw this as a good idea. It was an obviously bad long-term idea, which makes me wonder if they think of this product as a business they plan to be in for the long term or if this is just something they're toying with and trying to squeeze a few more bucks out of before they abandon it.
The most basic feature of a "General Lighting" product, besides providing light, is interoperability. They have an opportunity to push general lighting into the next generation and reap the benefits of the long-term experience they have with the early-adopter market.
Instead, they've decided to put their product into the category of "Novelty Lighting". Meanwhile, should a competitor come along offering an open solution (there's probably one already?) that gains traction, Philips will lose, and they'll probably dump the product line well before they've lost, fulfilling the only guarantee a lock-in can fulfill: obsolescence.
And even if they walk this back, the damage is done. They've shown they are willing to break customer's existing installations via a software update and will do so without more than an FAQ to explain it. They basically pushed a software update with the result of turning the lights off on their customers.
It's disappointing more than anything. Someone out there will do better.
On one hand, having to use Apple's proprietary Lightning connector sucks.
On the other, having Apple be heavy handed with iOS App Store submissions means I have a higher confidence with my iOS Apps behaving compared to those I install on my Android Device.
The Lightning connector being proprietary does suck, but it's far and away the best mobile device connector I've used. It's small, easy to connect, and disconnects fairly easily on tug. USB-C is pretty nice, but for similar feature set you have a much larger connector.
Lightning and USB-C aren't really comparable because USB-C supports USB 3.1 while Lightning is limited to USB 2 speeds for everything, including video out. Which means that Apple have to compress the video out and stick an entire ARM SoC in their very expensive AV adapter to decompress it, and this degrades the picture quality. By comparison, USB-C can carry uncompressed HD video, power, and a fast USB 3 data link at the same time using (at least in theory) cheap, mostly-passive adapters.
The latest iPad Pro IIRC has some sort of post-2 chip (I just don't remember if it's 3 or 3.1), it's just not being used yet. The connector itself has 16 total pins available, and the plug has 8. Since the Type C connector is 18 pins with 2 being orientation detection and 4 being ground, it's still possible to have the Lightning connector itself support 3.1 by actually using both sides at the same time instead of just one at a time; although those extra 2 pins would be handy.
So in terms of the connector itself, they're still pretty comparable, it's just that Apple for whatever reason didn't want to add support for it.
Edit: Cleared up some things that were actually untrue after researching it a bit more.
From what I understand you still need Xcode to sign the package with your developer key to either load it onto a device to test or to send it off to the app store. Though that might not be the case anymore as I haven't looked in a long time.
Had anyone ever tried to challenge this in a court?
Some jurisdictions have customer protection laws that say it's illegal to require purchase of some goods (or services) as a condition for purchase of other goods (or services). Don't know English legal terms for this, sorry.
>I'll never understand why companies make such customer hostile decisions. I can't see any upside to this and I can't imagine what the discussion looked like when implementing this decision.
Can't see any upside? How about more control and money for Philips, and few people would even care?
> I'll never understand why companies make such customer hostile decisions.
Really? It's pretty easy to understand.
There's very little to lose and a whole lot to gain.
Sure, you'll piss off a few people who read Hacker News but most buyers will just shrug and keep buying the only One True Brand, thereby making them millions and granting them a monopoly.
If the plan doesn't work, you can still backtrack and open up to third parties.
But there's really no downside to trying to force yourself into a monopoly, which is why Phillips, and before them Keurig, Apple and countless other brands, have tried and will try again.
I imagine that not wanting to be sued for fires, electrocutions, and other ills caused by malfunctioning poor quality electrical devices controlled by Philips controllers could factor into it.
> The first argument is out the door because now they'll just get a lot of support questions around many more products that don't work.
I'm not so sure about that - I've owned Hue products for a while now and until this moment never knew that they supported any other lightbulbs. I'm guessing most of their other customers didn't either - this was sold to mainstream consumers, not HA geeks.
>>> I'll never understand why companies make such customer hostile decisions.
Or, if you look it at from a different angle, it's a user friendly decision. Maybe there were enough people saying hey this $NO_NAME_CHINESE_MANUFACTURER bulb doesn't work therefore Philips sucks. Can it contribute to introducing a monopoly? Sure. But it's a luxury good so I don't have much problem with that. If Philips controls what is compatible and what is not, it can ensure to a greater degree that customers experience is satisfactory.
I understand the general BigBadCorporation vs Open Standards sentiment over HN but, really, it's sometimes for the better.
At the moment Phillips refers to traditional-style bulbs as Hue and less traditional lights such as the Bloom lamps and LED LightStrips as "Friends of Hue".
There certainly is an interesting question if they would start adding third party vendors to the "Friends of Hue" list, but right now its still a first-party designation for Phillips, so far as I've seen.
> I'll never understand why companies make such customer hostile decisions.
Because they can. John Doe will think "oh, I just need to shell out some money to get it working again", or "oh, the system needed an upgrade anyway".
The mobile bonanza (well, that one company who gets majority of revenue from hardware) in last couple of years perverted the word "upgrade" from "a software upgrade, which adds new features and ads value to existing purchased product", to "needing to buy a new device to keep on going with existing performance". I'm happy to see this hasn't spread to the desktop PC. Yet.
> that one company who gets majority of revenue from hardware
I hope you are not referring to Apple, because compared to other companies , iPhones and iPads are the one who can run current software on older devices with almost no issues. Samsung and other android manufacturers on the other hand have not supported older devices at all until recently (and even now not as good as Apple does). My first gen iPad still runs perfectly fine
I have a first-gen iPad, and it most certainly does not run "perfectly fine". Most apps aren't released for those old versions, some even seem to get removed automatically.
I think the Android world is worse, mind you - but old iOS devices are still left to rot. My 2.5 year old Google TV box being abandoned by Google (can't even log into the app store) was infuriating.
>I have a first-gen iPad, and it most certainly does not run "perfectly fine". Most apps aren't released for those old versions, some even seem to get removed automatically.
Well, 5 years time in the mobile/tablet space is like 20 years time in the PC space. Consider the changes in capabilities, cpu and gpu power, etc.
In that sense, it makes sense that most NEW apps are not released for the older versions -- how many apps are released for Windows 98 today?
Sure, it's "only been 5 years" but then again that's related to the technology space. E.g. most would accept that a 20 old year PC/OS wouldn't get much support, but that would sound too soon in other industries, where even a 50 year product can still be supported.
Besides, as you say, this is much better than the Android situation -- since most devices are sold with an OLDER than the latest version, and most vendors don't care to provide updates for older devices.
Looks over at my first gen iPad stuck back on iOS 5...
It still works fine, but it's hardly because Apple are doing me any favours (past building a good product back in 2010, and "supporting it" with OS updates until 2013...)
iOS 5 smooth 60 FPS responsive interface, compared to 9 stutter fest. What added value does the iOS 9 bring to the table then ? The content in Facebook, Instagram, Youtube etc. is all the same.
I have an iPad 2 which I updated to the latest iOS knowing it will decrease performance. Why? I wanted Apple Music and iCloud drive. And performance is still acceptable.
I have a less-than-a-year old iPhone 6+ that runs like a legless alligator ever since I upgraded to iOS 9. Your first gen iPad isn't supported by iOS 9 and there are a lot of apps that don't support it either.
But backward compatibility does not preclude Apple from being an upgrade company. Apple may not have invented the hardware upgrade cycle, but they've mastered it. That's what their keynotes and media interactions are all focused on. Their employees go out of their way to check if you have an "upgrade" available. I've had a phone that has never been in contract and they even offer to use that line to give me a "free" upgrade to my main line. I could go on... But the point is, the upgrade cycle is what Apple is all about.
Something must be wrong with it then. My 5s runs great on most recent release. It's axtually better than when I bought it. How many devices get better as they age?
iOS 9 introduced stutters in scrolling performance compared to iOS 8. If you're not sensitive enough to 60fps, you don't notice it. But that silky 60fps animations were the reason why iOS was praised in the first place.
It's that, but there's a lot more. It's simply very, very slow and seems poor at managing memory. It's difficult to describe, but things that used to respond very quickly (like scrolling between pages on the home screen) are slower than just "sluggish". And often apps don't behave well if I have more than a couple of them open. But it's not all the time, it's just frequent.
Then there is the problem where it doesn't rotate properly. And my first instinct would be to blame the hardware, but in the case of Messenger, it rotates some parts of the screen and not others. But the parts that don't rotate are unresponsive. So I'll sometimes find myself in a situation where I've typed a text, and the message is rotated, but the text box and send button are not, and pressing the send button does nothing until I manage to get the entire thing to rotate by moving it from landscape to portrait and back a few times.
It's also possible there is some cruft I've carried over from previous version (I've upgrade a few times) so I'm going to try a 'fresh' install where I lose all my data and have to redo everything by hand and see if it fixes the problems. But the only problem I had prior to installing iOS 9 was my music not transfering properly, and AFAICT, that is an iTunes problem relating to duplicate tracks that I haven't had time to resolve yet.
If it's not the cruft, I guess I take it back and get a "new" one; maybe a problem with the RAM?
It's not that I'm not sensitive to that, it isn't there on my phone. Well, with one exception and that's an app that I wrote so I suspect the problem may be the implementation.
Well, test it on iOS 8 if you can, because I've noticed that all apps with Listview (don't know how it's called on iOS) stutter when scrolling. Not flick scroll, but when you keep the finger on the screen and swipe and down. For instance Twitter app, Settings app (in Cellular data particularly).
So true. Google even turned off the DNS for the activation servers for their Android 2.1 devices (at least for the HTC Wildfire) so I could no longer log in with Google to get into the phone and do anything at all. Contrast this to my first generation iPhone which still works despite being several years older...
Don't forget Sony. They are pretty reliable about updating their Z-series.
Full disclosure: have a Z3, mostly for this and because it was waterproof. The screen is now partially detached in the top after less than one year of use which annoys me but I hope to get it resolved under warranty.
Yep. I have an iPhone 4S that still works great. Granted, iOS 9 is a bit slow, but that's to be expected. It's much better than my 4-year-old PC, which can barely handle today's games, for instance.
>The mobile bonanza (well, that one company who gets majority of revenue from hardware) in last couple of years perverted the word "upgrade" from "a software upgrade, which adds new features and ads value to existing purchased product", to "needing to buy a new device to keep on going with existing performance". I'm happy to see this hasn't spread to the desktop PC. Yet.
I can't tell if you are joking, honestly. If you remember the '80s and the '90s and the early to mid aughts, there was a joke about how "what Intel gives, Microsoft takes away" - the idea was that every few years, you needed to buy a new and dramatically faster PC to do exactly the same sorts of things you would do before. This PC would be massively faster than the last one you bought, and it would probably cost a little bit less. Microsoft would come up with a new version of windows or office that you needed to upgrade to if you wanted to be able to open documents from other people in the office, and that new version would require a new and much more powerful computer. Especially by the '90s, a lot of times these software upgrades felt really pointless, like your stuff was getting slower, but you didn't get any better features.
Around the time that everyone quit writing PC software and focused on the mobile bonanza, as you put it, this seemed to stop. Old PCs are just fine for workstations. but, of course, now the upgrade treadmill is on mobile.
You can't convince me that worsening the experience on a device in 30 minutes (time for OTA update to finish) is to be expected. Example: iOS 9 update.
Although I don't agree with many practices MS does lately, I'll admit that they're doing a good job with Windows performance being better and/or at least not worse.
> You can't convince me that worsening the experience on a device in 30 minutes (time for OTA update to finish) is to be expected. Example: iOS 9 update.
I can tell you that in the late '90s and early aughts, well, they weren't OTA updates; you actually paid for physical disks, but yes, worsening the experience was completely expected. that's why you bought a new computer at the same time.
No, you upgraded your PC with larger storage, or more RAM.
Or if you were a mindless consumer, which my original post is stating, you "upgraded" (bought) to a new PC. And this mentality came over from mobile and is already pioneered on desktop as well (that one company who solders RAM and hard drives now).
Speaking of MS, I don't remember if in the last 10 years I had to buy a new GPU or replace whole PC because the Windows update would bring the whole OS to its knees with slower click response and stuttery animations. From Windows 7 onwards the performance is actually more optimized and faster (disregarding UI design choices).
When the CPU clock speed increases 3-5x in 3 years, upgrading storage or memory is not going to cover that gap. If I recall, my upgrade cycle was something like 1994: 40MHz 486, 1997: 200MHz Pentium, 2001?: 1.xGHz?
1) Their lights/bridge are by far the most reliable IoT product I've used. A 9/10 where other products (Wink, GE, Lutron) are at best 3/10.
2) While 3rd party bulbs were sort of supported, it wasn't advertised. I've never seen it described as a interoperable Zigbee Light Link device.
3) My attempts at getting a GE bulb working were inconsistent, and even when it did work the brightness range and responsiveness were worse than the hue bulbs. I had constant disconnections where I had to re-add the bulb as well. I imagine many people blamed philips when in fact the problem was with the cheap 15.00 bulb. This is probably the reason for discontinuing unofficial support.
I don't like the fact that there's not a thriving range of interoperable, cheap, and high quality zigbee light link devices out there. I'm happy the Philips is focused on delivering a product that actually works, however. All of my other home automation purchases have ended with many wasted hours and eventual returns.
If people blamed Phillips for this, then there is quite easy solution. Allow people to activate the 3rd party access, but do it Android way. Hide the option from plain sight, force users to read quick warning message about 3rd party bulbs can affect or damage system. This way only people that did their homework will be able to reactivate it.
People will blindly follow a tutorial online that tells them how to activate this option, and continue to contact Philips for support. I've worked on products that have these unsupported/advanced modes, and customer queries on them are constant and time-consuming, even to simply dismiss (and, of course, those customers then go on to leave bad reviews, et cetera).
The Chromebook method (to disable write protect) requires you to open the device and remove a specific screw, it's beyond just blindly following instructions.
I've been using the Wink hub with a variety of different z-wave light switches, electrical outlets, plug adapters, and even a thermostat for the last 6 months. I DEFINITELY feel like the Wink hub is the weak link. It needs resetting frequently enough that I don't really trust that I'll be able to turn on my heat remotely when coming back from vacation, so my neighbor is usually on notice for manual backup (let himself in, turn on the heat).
Just today I was reading about the SmartThings Hub (Samsung) and the Casa Verde Vera Lite- It really seems like the Hub is where the polish needs applying in HA. I can link the Wink to my Echo and control things very easily, adding new things is relatively easy, but jeez that Wink hub is finicky.
It's realistic in that the RT to an Internet service isn't where it seems to break down. It breaks down at the hub that spazzes out and goes into limp mode (which as far as I can tell is simply a flashing status indicator of different colors) and won't respond to commands. Sure, it can cause lag and sometimes there is a full second or two difference from command to action, but it's usually snappy enough that the light on z-wave control turns off barely slower than the light directly toggled by the switch. That being said, if there was a hub that required the Internet service just to perform the away from home/mobile functions but let all the scheduled timers, scenes, robots, etc. perform without Internet, I would happily jump ship. OpenHAB is a PITA and the shortcuts in iOS that you get with Wink/IFTTT and the Amazon Echo integration would all have to be hand rolled. While I've already written some of my own Alexa Apps, I don't want to go back to OpenHAB for all the rest.
This problem isn't unique to Philips Hue, and I'm not sure Philips is necessarily a bad actor here. They are, after all, just acting in their best interest (and contrary to common belief, companies are self-interested; the customer's interests are important only so much as they serve the company's interests - for better or for worse).
Perhaps the problem is more related to the ZigBee standard, or more specifically, what ZigBee doesn't cover. As I understand it, the fact that Hue products conform to the ZigBee standard only applies to the protocol between the hub and lights; it says nothing about communication between control interfaces and the hub.
With that in mind, I feel that anyone who expected to use the Hue hub for controlling anything other than Hue lights had incorrect expectations. I certainly don't remember seeing Philips advertising any kind of third-party interoperability with the product.
Of course, it would be awesome for consumers if Philips did make that guarantee of interoperability, but from a business standpoint, once you start going down that road, you effectively have to support everyone else's products (whether or not they conform to the spec), and any failing of another product then reflects poorly on Philips' brand - even if they aren't the ones at fault.
So maybe if we put more pressure on these companies to adopt a common home automation control standard (not Apple's, not Google's, but something vendor-neutral), then we might start to see home automation interoperability in a consumer-friendly way.
> and contrary to common belief, companies are self-interested; the customer's interests are important only so much as they serve the company's interests - for better or for worse
The idea used to be that companies served the consumer interest, and then billed some money in exchange.
When was it that companies become some self sustaining beings, with their own interest to be served? (Yeah, surely when they discovered they could take their clients as hostage. The question was rhetorical.)
I don't know if that idea was ever true. Maybe it worked back in the times when customers and sellers knew each other personally, but that must have been way before we first invented cities. The idea is certainly being taught to kids though, and it's also used to argue that the market can solve everything in a nice way.
Companies (or similar things) are probably doing this since they exist. But people used to expect them to behave and even reasonably recently (like the end of the XX century) people (normal people, even on government) used to display outrage when companies made defective products to push their bottom-line.
Nowadays that seems to be the expected behavior. But in a second thought, that looks like one of those cyclic features in society, that get worse only until people react, then get better until people get complacent.
That was true at least as far back as the 1790's when James Wilson described a corporation as "a person in a political capacity created by the law, to endure in perpetual succession."
To "endure in perpetual succession," companies by definition must operate under a fundamental premise of self-interest.
To be fair, did Philips ever list that as a feature when you bought it?
I purchased a few Hue products myself, but never once expected it to be an open platform or even compatible with non-Hue products (even if I wish that were the case).
>Unrelated to the 'Friends of Hue' program, the changes we made in 1.11 to our implementation of scenes exposed a compatibility issue with a limited number of 3rd party lights which stop them properly responding to scenes created in the Philips Hue app.
>Philips will not fix this issue as it relates to the implementation of standard ZigBee scenes functionality in the light and would expect this software to be changed in the light as part of 'Friends of Hue' certification process. This is an example of precisely the reason we have taken these steps.
TL;DR: Only "Friends of Hue" lights are guaranteed to be compatible.
Yes, as of the changes they just made and disabled all third party lights. Prior to this update there was no 'Friends of Hue' program and third party lights worked. It's a bit disingenuous to act like this was an established program that people knew about prior to intentionally breaking systems that were previously working.
Having had the pleasure of developing ZigBee stuff (NDA, so cannot name specifics), I can understand Philips' position of blocking 3rd party stuff.
Zigbee is nasty enough to develop for even if you HAVE all the relevant docs and everything, without adding stuff developed by others into the mix. The only thing why this crap ended upon users is because it's less power hungry than WiFi will be and has a bigger range than Bluetooth.
Are there grounds for a lawsuit when a manufacturer pushes out an update to a product that intentionally degrades its feature set like this? This is no longer the same product that these users bought, it's effectively damaged by the update.
Generally, the agreements you agreed to allow them to do this.
Those agreements tend to be held valid (despite what folks want to happen ;p)
If someone you bought it from made implied warranties around this, you may be able to sue them (They often cannot disclaim implied warranties in consumer transactions)
Today I don't have time and I think it might one day be a good thing to be able to say: "you seriously thought anyone read and agreed to that thing? bwa bwa bwa hahahaha".
I think this part of law is ripe for some serious updates; some updates that will hurt a few established law firms but help everybody else, users, companies and lawyers currently boring them selves almost to death over standard contracts.
I'd hope in the future we'll have baseline contracts (around here this is already partially implemented in a few areas) protecting both users and producer, but seeing UK trying to implement restrictions on photography I'm not to optimistic.
No, technically the third-party manufacturers were in violation of the Digital Millennium Copyright Act, a federal offense with penalties up to five years in prison. From Philips' perspective, refusing to cooperate with those criminally infringing their IP is a feature, not a bug.
2. Even if the protocol were closed, and Philips put some DRM on it to lock out 3rd parties from reverse engineering the protocol to make compatible bulbs, the third parties still wouldn't be in violation of the DMCA, even if they had to include small copy/pasted bits of the Philips code that are necessary for interoperability. This was the holding in the Lexmark case back in 2004.
I call BS. This is using the Zigbee standard which Phillips doesn't own. They added a proprietary layer after the fact, which blocked non-Phillips products.
Unless you care to share evidence of a DMCA violation, this sounds like you are just making this up as you go.
Given that the protocol is a standard by the Zigbee Alliance (Light Link), I doubt that implementing it causes a DMCA violation. Unless you are claiming all companies making compliant products stole Philips code to do so?
Me too. Hue gear is absurdly expensive, but I was sold right up until this. To make matters worse, it looks like the apps I wanted to use the bulbs with (sleep as android, f.lux) only work with the Phillips hub. I hope the developers of those apps use this as an opportunity to learn about the dangers of vendor lock-in. This is just the FTDI debacle all over again.
If only there was other bridge hardware that could communicate in a more open manner. Unfortunately, Hue is one of the only companies that even OFFERS an SDK—most other systems are completely closed down.
I didn't research smart bulbs at all before walking into best buy and purchasing a pair of LIFX 1000 color bulbs using the light intensity as the only metric between brand selection. Getting home, I realized that LIFX doesn't really plug and play with the other technologies. Their cloud service is not very reliable, and so it was a very bad experience upon arrival.
Then I discovered the lightsd package, which is a service daemon that runs on anything with python. It exposes a json api on the network that any client can easily send programming commands to your lights. You can tag each bulb, so you can target any subset you can come up with. I made my own ruby client in a single night, and I barely code. Lightsd turned the LIFX bulbs from an obvious store return into something I am willing to keep. Barely.
Didn't Keurig just get valued at $shitton BN? If anything, this case teaches us that being customer-hostile and abusive pays off. Which is sort of obvious if you think about how the market works, but people still act surprised.
This is odd, but not catastrophic. If I understand right, Zigbee is open, so what's to stop the bulbs working with a third-party controller hub? Say, a Raspberry Pi with a Zigbee interface?
It's the other way around. People want to use their non-Hue lights with the Hue bridge, which is no longer possible. Now it means having to buy another bridge that supports both.
Yes, you can do this. And for the most part you can control your lights from your own software. I was looking at the protocol using a HackRF One to see how easy or hard it would be to build a replacement hub controller. I don't know if there are any patent issues however, that would be something that you couldn't really code around.
It's an open standard, which Philips hypocritically helped write, so there shouldn't be any patent issues other than the normal ones. You can even get it online from http://www.zigbee.org/zigbee-for-developers/applicationstand... . It's clickwrapped, but rather extant.
I love the battery-less Hue Tap switches, but the Hue hub's REST API doesn't let me subscribe to button presses. My plan is to make my own controller software and take the Hue hub out of the system.
Unfortunately, the manufacturer of the RaspBee neglected to document how to talk to the stock firmware. When I asked support, they suggested running their (closed-source) software on my Pi and then using its REST API, which doesn't support subscribing to events either.
The RaspBee does support loading custom firmware, so my next step might be writing some.
I've ranted about this and the IoT and how we've came to it.
IoT is awesome, and super, as long as you don't buy products that require to beg for your data from some website API.
What makes more sense?
Local device ->Internet ->Someone else's server(cloud) ->API ->Your cell/computer
-or-
Local Device ->Local controller
I extensively use Node-Red and Apache NiFi both. Node-Red is built on Node.js and is a graphical flowchart programming in the browser. It makes chaining together complex interactions easy and also makes many things no-code at all.
I use Node-Red for my home automation. It's open source, it works, and just makes sense.
Now, what should you use for the light bulbs? Unfortunately not Phillips Hue. This however opens up the market for others to come in and snipe business away. And that's a good thing. And whatever takes away the power of "other peoples' servers" cloud-crap, the better. It's just used as a way to control and extract more money.
Hue's hub works both ways, locally Smartphone -> Hub over WiFi (via a shared LAN connection, the Hub isn't it's own WAP), or remotely Smartphone -> Hue.com -> Hub over the internet. The remote mode has profoundly more lag, but also means you can turn on your lights from anywhere. The connection from Hub to the bulbs is always Zigbee. Unless/until Zigbee is built into smartphones this seems like a nearly ideal set up.
Zigbee isn't hard to implement within a Node-Red network. You can use an Arduino-Zigbee bridge to talk on that network, and then control the lights however you wish. In that case, it opens up using all the lights you choose from the cheaper_than_phillips category.
I also use Node-red on a Raspberry Pi. It's slim and as small as a base station. I also have Bluetooth, wifi, and nRF24L01+ boards on it, talking all those protocols. No reason for Zigbee, but it would be doable for $15 (I assume the price).
I've found the "from anywhere", at least for Node-Red is to use a static IP. If you dont have that, a dynamic one will work. If that doesn't work, a ToR hidden service works well.
My control over my hardware is always advantageous over control by a 3rd party entity.
If you are building your own Zigbee bridge you could use Phillips and Cheaper than Phillips lights all together. The change here is that Phillips has declared that the Hue bridge is not intended to be a generic Zigbee bridge and is focused on Hue (and friends) lights.
When I read this statement[1] from Philips, that third party that is assigned will continue to work and only commissioning is blocked, then the reason for that seems to be as simple as the Master Key for commissioning got released[2].
So, Philips just started to issue a new Master key that now has to be implemented in all those third party devices. But Philips will issue that Master key probably only under very strict NDA with selling your first child and such things.
Can you dump Hue and use Wink? Wink can supposedly control both GE and Phillips bulbs.[1] GE uses Wink as their main control system, and GE is big enough to argue with Phillips.
This is the Philips controller software (app) that is refusing to talk to or control 3rd party light bulbs.
I don't really see this as being a problem. It's not the nicest thing, perhaps, but neither is 3rd party companies building bulbs (presumably by ripping off the design and protocol of Philip's bulbs), and then relying on Philips to build the software so they can actually be used. In other words, Philips is refusing to build software, for free, to control their competitors' and/or counterfeit products.
Do the Philips bulbs (still?) work without the Philips Hue software/app? If so, non-issue: you just have to use 3rd party software to control everything. If not, well, that's why you shouldn't buy into closed, walled-garden products.
I wouldn't describe 3rd parties as "ripping off the design and protocol" when bulb <-> hub communication is done using the ZigBee Light Link protocol. Philips didn't develop that.
And no, lights from other manufacturers (I have several from GE) no longer work via the Hue app or any of the 3rd party alternatives. I made the mistake of accepting Hue's "update your bridge" prompt already, not realizing it would break them. Until I saw this headline I assumed it was a matter of unpair/repair to get the working again, but it looks like no luck. They're no longer in my list of paired bulbs, and (I'll try when I get home) it doesn't sound like they can be paired anymore.
GE isn't even selling these saying "get our cheaper bulbs and use them with Hue," they're marketed as being compatible with the Wink hub. But since it all works over the same open standard, you can use them on whichever base you like.
This is like Apple saying "Laptops from other brands are no longer supported on Airport wireless networks so that we can ensure devices are fully compatible." It's a huge dick move on Philips's part.
"This is like Apple saying "Laptops from other brands are no longer supported on Airport wireless networks so that we can ensure devices are fully compatible." It's a huge dick move on Philips's part."
"If the lights are not deleted, nor the bridge reset they will continue to function under no guarantees from Philips that future updates may not expose new bugs and compatibility issues."
and
"We want Philips Hue to be open but also offer a great experience for our customers. To that end, last week, we launched the 'Friends of Hue' program where we will certify and test 3rd party products to guarantee a consistent and long term interoperable experience also for these products."
AKA We want third party manufacturers to pay for a sticker to use our product because we have market dominance.
and
"These changes do not affect Philips commitment towards an open system and ZigBee Light Link as the best standard for residential lighting control. Our lights continue to be fully standards compatible with differentiated features built on top of the standard and exposed via our bridge."
> This is like Apple saying "Laptops from other brands are no longer supported on Airport wireless networks so that we can ensure devices are fully compatible."
Didn't Apple do that with Bluetooth once? I recall reading that at least one iteration of iPhones could not send files via Bluetooth to non-Apple devices.
They still do it. For some Bluetooth device classes, you must get your device signed by Apple and use certain chips. One product I worked on had a dual Bluetooth and BLE stack - Bluetooth for Android, and BLE to circumvent the Apple limitations (BLE devices don't need to be signed).
The slippery slope of "intellectual property" is so steep that even building interface-compatible products is now considered ripping something off. We've come a long way from the age of IBM compatibles and the PC revolution.
On the other hand you could argue that while the pc revolution fueled on DOS licensing and IBM compatible BIOS was a a massive leap for the economy overall, it wasnt the best move for IBM in either the short nor the long term. Now they do the no-scales business of services and consulting...
IBM made several pretty serious mistakes that lead to Microsoft's dominance on software licensing. But even on the hardware side they could have seen huge success but instead wasted time and mindshare creating the failed Microchannel architecture in order to regain control over the PC platform.
to clarify: I meant economies of scale. In services they are much much lover then in software licensing (example: microsoft in the 80ties and 90ies) or integrated products (example: apple now)
I don't see how you can say that this is both "not a problem" and "why you shouldn't buy into closed, walled-garden products." Best I can tell, the thing Philips did here that people are objecting to is turning Philips Hue into a walled garden where before it was not. So if this is an example of why you shouldn't buy into closed, walled-garden products, then it sounds like this product's owners have a legitimate problem with what Philips did here.
I unfortunately don't know the entire history here, but it really comes down to what was purchased.
If Philips sold the Philips Hue hub as a generic controller for all Zigbee lights, then yeah, I'd agree: they essentially did a bait-and-switch after purchase, and this is totally wrong. Like class-action lawsuit wrong.
If they sold it as a controller for Philips bulbs without mentioning Zigbee interoperability, then it's customer-hostile, to be sure, but not necessarily wrong, in my eyes.
The bulbs don't work without a hub. [Edit: doesn't have to be a Philips hub, but you still have to buy a new hub.] And Philips was really playing up interoperability and compatibility, so it's hard to look at that as a rip-off. Also it's not just "free software" - you have to pay $200 for the starter kit that includes the hub and 3 bulbs.
>>In other words, Philips is refusing to build software, for free, to control their competitors' and/or counterfeit products.
Not sure how this works. There are start ups out there who will do anything to get people to download and use their apps. Here you have several hundreds of thousands of users willing to download and use your app for free. Why chase them away?
I think it was Bill Gates who said something to the order that if people were using Pirated operating systems, he would prefer they pirate Windows so that he could convert them to paying users someday.
It looks like this was an update to the software in the Hue bridge? So people who THOUGHT they were buying a zigbee-based bridge now find that many zigbee products can no longer be paired with it.
We are building some related home control products and have forgone radio level integrations instead favoring integrating with anyone over http, providing an open api, and shortly after launch an sdk. Radio integrations in theory are fine but in practice it's a matter of picking sides, allowing third party devices to dictate your access to the Internet and interop, for a few features, offline (local http should be an option with any hub, nest etc but isnt) and lower latency operation as probably the biggest features. Not controlling your own products' access to the Internet is a scary proposition not to mention range/interference issues with 2.4ghz if you don't have aa critical mass. Building IoTs right now is as much an alignment excercise as a technical one and while it's a bummer that they have chosen to remove/prevent compatibility, consumers aren't really choosing subscription models for devices and cloud backed services hence the economics of customer acquisition, support, margins etc aren't realities that can be wished away.
I'm not convinced this was a hostile decision by Philips. It would be reasonable for the company to want to advance their own technology which would often entail a changing interface. If the third-party products are implementing an older interface, how is that the fault of Philips? The moral thing to do would be to standardise and publicise the interface...perhaps this is the situation already...?
Creating a new compatible hub now sounds like an ideal Kickstarter project, no?
Also, I can't help but wonder if UL issues may have influenced the decision too...just look at the current hoverboard fire issues with cheap Chinese manufacturing and I can at least speculate that they might be.
Or just wait for Google to release Weave and Brillo. Those are both open platforms for communicating with IoT devices. Which is the exact opposite strategy as Apple's, who is SO CLOSED DOWN you actually need to buy a physical chip from Apple and incorporate it into your hardware for your hardware to be controlled by Siri.
The Pi Zero might be able to do some additional interesting things through with that computing power, including transmitting information over those LEDs at imperceptible modulation frequencies and such. Perhaps it could even be a Ethernet-over-Power to Li-Fi bridge, with some additional circuitry. No Wi-Fi sucks though. And putting Wi-Fi into a Pi Zero requires a micro-USB to USB dongle and then another USB Wi-Fi dongle, thus the Pi Zero as big as a Pi after that cable and dongle mess. If it had on-board Wi-Fi it would be ten times more useful.
I've seen some cool mods where someone took a USB hub or a wifi dongle out of its case and soldered the pins directly to the USB pins on the Pi itself. That gets around a lot of the mess.
I'd gladly pay another $2-3 extra for someone to do that for me with some automated manufacturing process, and sell me "Pi Zero with Wi-Fi" boards. Soldering mini-USB can be a bear, let alone doing it 10+ times to get a room full of mini-robots or drones or something else to do interesting things. The true value in a cheap computer is really that I can buy a huge number of them at a reasonable price. But a huge number of mini-PCs is terrible if you have to mod each board. If I only needed one, I'd be okay paying $100 for it.
Even better if it's a "Pi Zero with USB Hub and Wi-Fi" for, say, $15, so that I can actually add something else useful besides Wi-Fi, such as a camera or sensor or something else. Sure, there are GPIO pins, but there are a lot of super-useful things out there that come in USB.
I use an Arduino Yun for a lot of basic tasks such as having a sensor report values over Wi-Fi, or putting a couple servos on Wi-Fi with as little work as possible, but the price is steep at $60+ and not much computing power.
I understand that in order to pair with Zigbee devices, you need the Zigbee Light Link master key which is only given to licensed manufacturers of ZLL-based products. I also understand that said key leaked a while back and is all over the internet.
Have u had success coding for this? I bought one and it is on my shelf .. Didn't find any high level language bindings. The docs didn't seem friendly. Would love it to hear cases of success.
I have been consistently disappointed by Philips Hue ever since I purchased the $200 starter kit a year and a half ago.
Numerous iOS app updates have rendered the system useless (lack of basic QA), slow to adopt HomeKit and price gouging for it (they want users to buy an entirely new Hub for $60).
Here is the amazon product page for the hue starter pack with the reviews listed -- most recent first. Even if you haven't purchased this yet you can let everyone know these new reviews rolling in about the product are helpful:
I first saw the Hue lightbulbs on SyFy with the 12 Monkeys show. It syncs up lighting to your show. I knew I didn't need that and it would be trouble later on. Now I know the devices lock out third party bulbs.
No need to redefine anything. DRM works as advertised (lame pun intended) - it manages rights to a product or service. The thing is, the default assumption that "I bought it = I own it" is often no longer the case. Most people just didn't notice. DRM makes it painfully obvious that you don't have the rights you thought you had.
I would strongly recommend that any home automation device you buy has a direct method that it can be interfaced with and programmed in a local way. If a device is only programmable by a web API, rule it out.
You may also wish to consider looking for devices which are based on a switch, rather than a bulb. Controllable bulbs do not play nice with the state of physical light switches, and in the case of multi-bulb fixtures, bulb solutions may be excessively expensive. Meanwhile, a smart switch plays nice with physical users and can control as many bulbs as you want.
I never understood the desire to control lights without using a wall switch. I say this having had X10 and later Insteon installations in 3 different houses over the past 10 years.
Even today, I have the ability to control nearly all the lights on the main floor of my house with an app on my phone. I actually use this feature maybe once or twice a year, being generous. Even if my phone is on me and already unlocked (due to being in my house), I have to pull it out, swipe the screen, launch an app, wait for it to load, then find the lights I want and click to turn on. Or I can press the switch on the wall next to me.
Or, even better, a timer/motion sensor has already turned on the light for me and I don't even have to think about it. This is what real home automation is all about.
It's not so much a desire as a work-around for the fact that smart bulbs need a trickle of power 24-7 so they can respond to external messages from timers/sensors/etc. The wall switch has to stay on, so you need to kludge up some other way to control it.
These kludges are slowly getting better: maybe you can get a menu bar app so you can control your lights from the computer, maybe your phone/tablet light app can stick some buttons in an Android widget or in the iOS notifications pulldown, there are even people trying to make switches that you can stick over the normal switches and hit to trigger light changes without having to hire/be an electrician who can replace the switches.
It's a widget in your notifications bar and your lock screen with buttons for remote control. Also has a smartwatch app. I use it all the time and it's so much faster than the official Hue app.
I use the LIFX bulbs myself (such better greens and blues!); their iOS app has a notification widget. And a watch UI as well.
And I wrote a little app that lives in my Mac's menu bar and lets me pick from the scenes I set up in the official app, too, someday I should actually package it up properly. (https://github.com/egypturnash/weatherlight)
I certainly use remote activation when I'm not home, for instance, I have cameras so I can check on my pets, and I turn on the lights so I can see better when it's dark. (They're infrared cams, but that's questionably useful sometimes.)
But yeah, 90% of the time, if I am turning on a light, I'm hitting the physical switch. So a bulb that is ignorant of my switch's position isn't a lot of use to me. Because if I want to turn that bulb on... my switch is probably already off. And the bulb can't work if the physical switch is off.
I bought some bulbs to create a light alarm -- automatic wake up by slowing increasing the light in the room (and nice soft coloring too). I actually use the wall switch to turn them off an on the rest of the time.
I might get some more bulbs (mi.light) if I start finding more uses but for now it seems pretty niche.
> Or, even better, a timer/motion sensor has already turned on the light for me and I don't even have to think about it. This is what real home automation is all about.
And doesn't involve a wall switch.
Of course, a fully integrated system with switch/dimmer modules in the electrical system is nice, but not really an option in many situations (e.g. renters). Control purely by a phone is certainly not ideal, but is a simplest useable solution you can build on, with additional hardware, apps for special functions, ...
All electrical work in the unit has to be done by someone legally qualified to do so (I'm not) and it is not worth getting a bill for a "proper" electrician to fix it for. Also only work for one lamp per room (that already has a light switch) and doesn't do any fancy new color-control features. Everything else needs additional modules and wireless controls anyways, so why do it differently for this one case?
Exchanging batteries in additional lightswitches seems stupid, but doesn't happen THAT often. You can add them if you want them, others make do with the phone and maybe NFC tags or other tricks.
Sure, if I owned the place or would be staying here for many years it might be worth it, but not yet.
I kinda wanna know how many people actually get asked to show proof the electrical work of shutting off the power, unscrewing wires from a light switch, and screwing them back onto a new light switch, was done by a licensed professional. I get you probably don't want someone running new wiring around a place who doesn't know what they're doing, but changing out light switches isn't substantially more difficult than changing a light bulb.
I really depends on the situation (Here it certainly would be noticed and questioned), but that really wasn't the main point I wanted to make. I was more going after your argument that true home automation isn't flipping switches: a principle I very much agree with, and in my experience various wireless systems make setting that up relatively easy. Because it is linked to a computer for more complex features, and you can move stuff around within seconds. Just because some of these systems come as only a bridge and a smartphone app doesn't mean that's how people actually use it, as far as I can see. But many start with just a fancy colorful lamp as an effect, which works fine with just the app, and then comes integrating it with the TV, and the alarm, and ...
These basic sets require very low effort to get started, and THEN people are interested.
I hope I got my point across better now, it's kinda late here.
In case of renting an apartment, you risk getting in trouble with your landlord. Given how hostile landlord-tenant relationships can be, non-invasive solutions may be desirable to some.
I've installed my Nest in 3 separate apartments, installed a fan in another, rewired an outlet so only one outlet was switched, and replaced multiple outlets with zwave outlets and no maintenance guys or landlords have said anything.
Any recommendations for your favorite smart switch?
I installed a few INSTEONS in my house and got bit badly when they just stopped communicating. The most frustrating thing is that there's no diagnostic tool, so I can't tell if the switches are broken or if their signals are getting sent but aren't understood by intended recipients.
Next time I get deeply into home automation, I'll make sure to use a kit that includes tools for sensing wifi signal and diagnosing bad connections.
I am using INSTEON myself. The bite there is that they :are: proprietary, though the PLM is openly programmable (I'm writing my own INSTEON controller) and not reliant on a web API of any kind. They can't disable functionality on me. I haven't had a bad experience :yet:, but I'd jump on a good open protocol with the same type of functionality. (RF/powerline dual-band is a huge perk, IMHO, and I prefer the non-use of Wi-Fi/Bluetooth.)
If the important part of the bulbs to you is the remote control (and not the color changing part), any generic ZigBee Light Link or Z-Wave light bulb paired with a home automation hub (like Wink or SmartThings) will work fine.
The Wink hub (at least the current generation), is permanently rootable thanks to a flash-ROM uboot glitching trick. I have one but haven't bothered to root it yet. My goal is to use it for ZigBee wardriving. :)
I have one and it has been widely unreliable from day one.
It does not default to on when you use the light switch, so you always have to use the app to interact with it.
Half the time, the app fails to detect it. The rest of the time, it can take random amounts of time for it to respond.
It also likes to randomly light up red in the middle of the night or to flicker very rapidly (absolutely unbearable).
I have just removed it and replaced with a dumb light.
Bulb detection used to be a big frustration for me as well, but they've 100% resolved my issues with it in the latest firmware update (now a few months old). I'd previously had issues with detection after power-on since WiFi would take ages to connect, but now its down to a pretty impressive 5-6 seconds from cold start and is far more reliable.
Random color changes or flickering sounds like a defective bulb, I'm sure they'd replace it for you if you contacted them.
maybe they have corrected it in an ulterior hardware/software revision, I have the Kickstarter version and judging from the comments at that time it was at least a widespread issue.
I am not really willing to throw more money their way though.
I have LIFX bulbs and do not experience this issue at all. In fact, if I've turned the bulb off via software, I can flick the physical switch off, then on and the bulb comes on. Their app is amazing and they are constantly adding new features and have a great api to boot.
I've been looking into this but haven't committed to buying anything yet.
Insteon doesn't seem well enough documented for third party controller implementations to me, although there are third party controllers available.
Z-Wave (distinctively different from Zigbee) are the main contender for me right now. They seem to have the most interoperability but it is still a closed protocol in that documentation isn't freely available. But access higher up in the stack does seem easier. It looks like I'll be able to act as a controller, rather than being forced to talk to one.
I like Insteon's dual signaling and bridging capability (between radio and signaling through the mains) but it has very limited security and it looks tricky for me to put a controller together myself (which as a developer is my test for openness).
X10 (supported by Insteon devices) has no security and is quite limited, so I don't want to invest in that now.
Zwave works great. Ppl harp on it because it's not 'open' - yet there is an open source interface library, products from dozens of vendors interoperate great, there are many choices in software to drive it (open source and commercial with more features). Meanwhile the 'open' alternatives like zigbee don't interoperate at all (in practise), and that is if you can buy products that use it at all; and now there is this hue debacle. I never got what people like about hue at all; is it that they are just screw in and don't need further setup? Home automation is so much more than turning the lights on and off with your phone. That's trivial. It was clear from the start that hue would be very narrow in application. (I'll admit though that using lights to follow what's on the tv is cool, and not available in any other system I know of)
INSTEON documentation is actually somewhat decent. But fragmented. There's some great third party software, there's some great third party hardware. The thing that excited me into building my own INSTEON controller, is that you can directly control a light with about 20 lines of VB .NET code: http://madreporite.com/insteon/plm_basics.html
Since I've been so unhappy with home automation software I've found, not doing exactly what I want, I've started building my own in VB .NET. The basics, plus what I specifically want it to do.
X10 is outright terrible. It was designed before nearly as much signal interference existed on powerline, so now you need tons of phase couplers and filters to get a good signal. INSTEON's mesh network (and dual-band powerline/RF) jumps signal issues far better. INSTEON's newer devices also drop support for X10, FYI.
> INSTEON documentation is actually somewhat decent. But fragmented.
Any help, please? For example, let's say that I want to buy a USB interface (for a controller), a motion sensor, and a light switch (eg. a micro dimmer). I want to plug the USB interface into a modern Linux distribution and speak to it to read motion and the switch and control the light (and configure the switch to operate the light directly without the controller).
Where do I find documentation on:
* What drivers I'll need for the USB interface to get to something I can talk to from userspace, whether this is Free Software, whether I'll need external drivers or not and where I might get these.
* The protocol to speak to the USB interface from userspace.
* The protocol to speak to each of the devices over the interface.
I've spent hours looking, and I only feel that I have half the answers. For example the dimmer is documented at http://www.insteon.com/developer/#devdocs but the motion sensor is not. And I still have no idea about the USB end.
I haven't tried to run the USB interface off of Linux, but I know they're supported pretty commonly, Mister House is a popular open source project that supports INSTEON on Linux. INSTEON PLMs like the 2413U are basically straight up USB-to-serial adapters, I think they might be supported directly in the Linux kernel, but I'm not positive.
The madreporite.com site I provided above has some decent documentation on device IDs and commands for a lot of devices. And as you can see from the link I provided, communication with the devices is generally pretty simple, 8 or 21 bytes sent over a serial connection, that can be written in a few lines of code. Receiving is a bit more complicated, but he provides sample code for that as well.
In my code development, I've definitely found some fun cases. i2cs (newer protocol) devices require a checksum, and they respond a bit differently in some cases. So for instance, my code that does a Product Data Request to get the model info for a device isn't working for i2cs devices right now. I'm still working on that, probably tonight.
I'd think something like Mister House would probably do the sort of simple case you need without figuring out all of the INSTEON protocol.
> I'd think something like Mister House would probably do the sort of simple case you need without figuring out all of the INSTEON protocol.
I'm a developer and I want to hook all kinds of things together. I don't need a GUI but would like full programmatic access. The case I have in mind would start off as a few lines of Python, probably using asyncio or something which is really powerful for this kind of thing. I'd prefer to just write a few lines against an API than have to use a framework, deal with maintaining a larger software deployment, etc.
Well, as I said before, I doubt you'll find many devices easier to control than like 20 lines of Visual Basic (probably less in more concise languages).
But you are right that there are holes in their documentation. The code I'm using does a good job showing unknown commands though, so it's pretty easy to fill in what's missing. I think IoT has a lot worse devices, documentation wise.
That page is helpful, but it looks to me that it is mainly from a group of hackers who have reverse engineered things. I'm appreciative of that and would find it really useful had I inherited an existing system. But I don't particularly want to buy into a new system that relies on reverse engineering rather than normative documentation. If I'm going to be spending money and have the luxury of choosing the system to use, I'd prefer a system that is better than that.
The worthwhile note there is everything regarding the "PLC" rather than the PLM is too old to work with modern devices. The 2414 is basically not supported by anything anymore. And that page is eight years old, so it's likely missing any content on most of the newer INSTEON devices and protocols.
LIFX. $60/bulb, just like the Hues, but they connect via wi-fi so there's no hub needed. Better blues and greens than the Hues, as well.
I've tried them and the Hues. I gave the Hues away to my ex. I've got eight LIFX bulbs in my apartment, and would happily buy more if I was in a bigger place that needed more lighting.
Same here, I love mine as well. As a plus, the company seems to be pretty open-source friendly, and they've published official APIs and full protocol documentation over the last few months.
Another vote for Z-Wave. As others have said, the lack of being "open" means that stuff actually interoperates. I'm using a Razberry with an older Raspberry Pi as the controller, and Linear brand in-wall dimmers and lamp modules, plus a motorized drapery system from Somfy.
The software that comes with the Razberry acts as a basic controller, but I wrote my own web front-end that talks to their controller over local http. It's all very customizable, and has been very reliable. (I don't know if there are Z-Wave colored lights, though, mine just dim.)
Domoticz and OpenZWave are actually way more powerful than Razberry, and I'd highly recommend investigating that so that you don't need to keep updating your own controller. Domoticz also has a pretty good scripting (lua) support built-in, so you can automate stuff in a really simple way.
I'm just using razberry as an api to send z-wave commands and occasionally get status updates. I'm writing all my own logic and scripting and stuff in my web front-end (using coffeescript on node). I'm sure I'm duplicating effort, and of course no one will ever reuse my code, but now that I've wrapped the basics of the razberry api, it's easier for me to just code more logic than to learn someone else's framework.
(I'm also integrating a handful of devices I built myself from esp8266's, that communicate over basic http over wifi. I wonder if those could be integrated into one of those frameworks easily?)
I just bought some Milight compatible bulbs, hub, and remote. It's less advanced and plug-and-play as the Philips system but hacker friendly. I'm currently coding up my own light wake-up alarm system (which is the reason I bought it).
Am I only one who doesn't see a problem here? Sure it would be nice if company X allowed me to use cheaper Chinese knock-offs with their product, but to me, they are well within their rights to decide: "hey, we don't want competitors to benefit from our product(s)"
In essense Phillips put money into R&D and marketing and if you are to believe the linked article into making smart lightbulbs mainstream. That shit is not cheap so why would they give money for their competitors? This move forces others to build their own base system and what not, which is fair.
I am sure you can find open{source|hardware} alternative if you don't wish to support Phillips anymore.
You might be the only one. What if you bought a car, and after you bought it, the manufacturer of the car announced that they have remotely flashed the car's computer and now you can only drive to work, and if you want to drive anywhere else you have to buy 'tickets' for $5 per trip, or the car will refuse to run.
The point is that when you buy a thing, it is yours. When you own a thing, you are within your rights to do whatever you want with it, so long is it is legal. If makers of things can retroactively impose restrictions on the thing's use, then you have no rights whatsoever and anything that you own is yours to use only so long as whoever manufactured it feels like your use is maximizing it's profits.
Your car metaphor is completely off. It's not like Philips updated your lights to only light up in specific location.
But cars are a good example, say your automatic shifter breaks. There are no real third party options, you've pretty much got to buy a new one from the manufacturer or by used one. You can still do all normal car things with it you just can't use third party pieces. Same with the lights, they still work, they shine light and do everything that they did before now you JUST can't use third party bulbs with the system.
If you want to go with other shitty analogies say you made a game, something like an MMO that has monthly fees. You sank a lot of money developing the game, the box price isn't high because you know you'll make your money from the monthly fees. You also use money from the monthly fees to improve the game, fix bugs, add content. Now your subscription model is a little strange, it works by players entering a code on your website. They buy it from your online store, get it in their email and use it to get play time. Now let's imagine that your security isn't absolute and some third party figures out how your keycode generator works and they start selling codes for half the price. Now your paying subscriber count is shrinking. What do you do? Do you A) fix the problem which results into many users losing money since they already bought several months worth of play time from this company? or B) leave the system as it is because openness or something like that?
> to me, they are well within their rights to decide: "hey, we don't want competitors to benefit from our product(s)"
I'd say: the products cease to be theirs when a someone buys them, and the consumer is the one who benefits from being able to choose competitor's products.
Toyota did a lot of work designing my car, but they don't get a monopoly on selling me carpet mats. It's my car and I'll put what I want in there.
> I am sure you can find open{source|hardware} alternative if you don't wish to support Phillips anymore.
True, but if you bought something expecting interoperability and it was "upgraded" to be closed, you'd have a right to be upset.
You can be upset all you want, but unless it was adverticed as "easily expandable" or whatever then your upset-itness doesn't matter.
I don't know what you are going on about carpets, but to relate it to topic: You are well within your rights to choose the actual lamp in which you use the bulbs.
I don't get why people use such bad examples/metaphores in this topic. Car just is nothing like a light bulb. Another shitty, but little better example would be a gaming consoles. You can't just make a game for new consoles and sell it in stores without going through Microsoft or Sony. Are they within their rights to restrict who can make what kind of games for their consoles? Are they entitled to profit off of each game sold? After all they "just" made the consoles, we buy them, shouldn't we get to choose which games we play and how we obtain them?
> You can't just make a game for new consoles and sell it in stores without going through Microsoft or Sony. Are they within their rights to restrict who can make what kind of games for their consoles?
I think they're well within their rights to say "nobody can brand something as Microsoft or Sony except us", because that protects consumers.
I don't think they should be able to keep you from using the game system that you bought in whatever way you want. That includes reverse engineering it to design games for it or buying such games from someone else. They shouldn't have to guarantee that such games will work, but they shouldn't be able to keep you from trying, either.
Companies are way too quick to disregard consumer rights. You can't decide what to plug into the system we made. You can't decide what coffee pods to use with the coffeemaker we made. You can't decide what bread to cook in the toaster we made.
You know what? Yes I can, because I bought it and it's mine.
I've been using neopixels to great success in combination with particle.io chips. They have cloud events and you can send whatever data to them. I'm sending a payload like `{ "color":"blue" }` and then all listening LEDs change. Plus they are individually addressable and are reusable for other projects. It's not the same level of brightness I'm guessing.
Adafruit has a 24 neopixel ring with a particle slot. It's like $45 for everything for one. No hub.
In slightly related news, the open source project, Home Assistant, that this blog post references, is an excellent open source "hub" for controlling the smart things.
I always wondered about smart bulbs... How much, per year, do they cost to run idle? Since they appear to use wireless to operate, so there must be at least the draw for that.
I have three neighbors, all of whom are non-technical, that use Hue lights in their home. I asked them if they used any other "smart bulbs" with their Hue bridge. The universal reply, averaged out to a representative quote:
"I didn't even think that was a thing, I only use Hue bulbs with the Hue bridge."
Damn. I just bought my first Hues a week ago - a little spendy but worth every penny to have a super easy install into my living room lamps and be able to be controlling my lights from a ruby script in 5 minutes. Hopefully, someone will release a crack sometime soon.
Official Reason: "The lamp that cannot be added may be a lamp from another brand. Philips does not test and cannot guarantee the behavior of all bulbs from other brands connected to the Philips Hue system. To guarantee the quality of consumer experience only Philips Hue and Friends of Hue lamps can be added using the the Philips Hue [Hub]." [1]
Real Reason: We invested money into our hub and building out our partnerships w/ Zigbee and "Friends of Hue" partners. We need to make up that money on hardware ($60 per bulb [2]) that 3rd parties could manufacture and sell for a fraction of the price. Why would we let 3rd party hardware companies leech off our investment?
Do you have evidence of the "Real Reason" scenario as opposed to the Occam's Razor scenario that (a) Philips really can't guarantee the protocol works with any lights they don't explicitly test against and (b) the reason some manufacturers can slide in at a fraction of the price is that they're cutting necessary corners in either hardware or protocol compliance? ;)
I think most users would see open connectivity protocols as a feature, and being unable to connect whatever lighting fixture they wanted to the Hue hub as a deterioration of their "consumer experience".
Connect some dodgy 3rd party lamp that is non-compliant, or worse, infects your system w/ malware and breaks your products? That's a bad consumer experience you've brought upon yourself, knowing full-well the risks. If anything, it'll make you an ever more loyal Philips Hue customer once you shell out another $200 for another starter pack and never touch the untested 3rd party stuff again.
I'd be very surprised if this was anything other than the classic case of - build a very nice garden, then wall it off, or else go broke.
I'd refrain from making assumptions until more is known.
Another hypothetical possibility is that there is some corner case of the open standard that nobody realized was ambiguous until Philips changed an implementation detail that broke (non-compliant) third-party devices, and they're now stuck in the rock / hard-place situation of deciding whether to roll back their change and remove whatever functionality or fix just got added or to apply pressure to third parties to be more compliant with the standard.
(That's the charitable interpretation that assumes their software quality process is solid enough that they can even know such nuances and subtleties as "What change did we make that broke third-party devices that aren't physically in our testing bullpen?")
Thanks for the charitable interpretation. It certainly is possible, IIRC the first Hue bridge was on the cutting edge of ZigBee and it is possible to imagine that it didn't quite get the standard exactly correct.
Whatever the reason, this is an interesting hiccup in the Internet of Things.
The first argument is out the door because now they'll just get a lot of support questions around many more products that don't work. The second might happen for existing customers, but I'm now going to avoid this product as a future customer because compatibility is a feature, and for me, and I'd think anyone who is looking to purchase a tool that manages lighting/small electrics around the home, compatibility is easily the #1 or #2 feature. If there were a choice between a lightswitch that worked with a wide array of lightbulbs, and one that worked with only one company's bulbs, guess which one I'm buying?