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?
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.
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.
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.
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!
You can read a little about that here: http://fitwerx.com/converting-shimano-ultegra-6770-di2-to-11...
...unless they ran a wire up the the controls to carry power :)
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.
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.
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.
In general, being more compatible increases the value of a device. When it doesn't, you've got some bad market forces at play.
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.
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.
Light Link - "Smart, easy-to-use lighting control designed for consumers." http://www.zigbee.org/zigbee-for-developers/applicationstand...
Building Automation - "Innovative, efficient and money-saving workplaces." http://www.zigbee.org/zigbee-for-developers/applicationstand...
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.
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.
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.
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.
If the company looks at the employee like a tissue to be used and thrown, why is it so surprising to receive the same treatment back.
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 -- 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.
 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.
I.e. it's more about paranoid control than actual reasons.
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.
They're somewhat dim as well. Not exactly a quality product.
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.
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 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.
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.
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.
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.
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?
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.
android auto does not work on the z3 compacts at all because of their decision to remove the USB charge mode from the phones.
Also: anything else they have disabled?
See difference between iOS 8 and 9, who introduced stuttering in two and one year old devices.
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.
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.
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.
I am telling you it's the same idea.
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).
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.
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.
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.
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.
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.
Can't see any upside? How about more control and money for Philips, and few people would even care?
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'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.
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.
Curious what the process is to be listed as Friends of Hue (or w/e).
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.
Build an ecosystem around Hue (Apple app store).
Have help pages but don't do any support (Apple app store).
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.
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).
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.
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.
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.)
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.
To "endure in perpetual succession," companies by definition must operate under a fundamental premise of self-interest.
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).
Edit: Found a post about this block from Philips:
TL;DR: Only "Friends of Hue" lights are guaranteed to be compatible.
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.
Philips Hue Hub (4.5/5 stars currently):
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.
1. The protocol is open. It's not Philips' IP.
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.
Unless you care to share evidence of a DMCA violation, this sounds like you are just making this up as you go.
Do these idiot companies not learn anything from backlashes against Keurig and others?
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.
Wonder if this is still relevant?
That thread suggests it's possible to have Hue bulbs join third-party ZigBee networks.
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.
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
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.
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.
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.
I don't use the Hue app myself, I call the API from my automation system. Works well.
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.
Standard here: http://www.zigbee.org/?wpdmdl=2132 [pdf warning]
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.
For an example of the now-useless bulbs I have: http://www.homedepot.com/p/GE-Link-60W-Equivalent-Soft-White...
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.
And in their faq about this (http://www.developers.meethue.com/documentation/friends-hue-...) they have the nerve to say things like:
"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."
"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.
"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."
AKA Embrace, extend, extinguish.
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.
It's 2015 and still the only way to share files from your iPhone is to plug it in.
You won't be able to SSH into a server/box/machine, from a server/box/machine not built by the same manufacturer.
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.
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.
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.
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.
This one works with Raspberry Pi 1 and 2 (not zero)
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.
Digital *Restrictions* Management
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.
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.
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.
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)
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 might get some more bulbs (mi.light) if I start finding more uses but for now it seems pretty niche.
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, ...
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.
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.
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.
DerbyCon presentation by Crypt0s: https://www.youtube.com/watch?v=Bl4PdLQW-8I
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.
Random color changes or flickering sounds like a defective bulb, I'm sure they'd replace it for you if you contacted them.
I am not really willing to throw more money their way though.
They're much less expensive than Hue, support IFTTT integration, and seem to be much more open in spirit than Philips' offering.
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.
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.
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.
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.
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.
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.
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.
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.)
(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?)