I've just built something very similar to this last weekend -- For around $43/sensor (Raspberry Pi Model B, DigiSpark, and 1-Wire Temperature Sensor) I made 20 of these for my home, farm, and hackerspace for temperature logging. I did this because we're getting another 'polar vortex' next week and the cows don't like it if it's colder than 20 degrees out.
This allows me to measure the temperature inside, outside, and get the relative humidity (not nearly as accurate as the $20 honeywell sensor that they're using, but, it's close enough for my needs). I then built a simple website using mrtg (for temperature trending) and a ruby script that checks the temperatures versus what the set points are and mounted the raspberry pi's in various locations around my places.
My "Controller" nodes are a beagleboard with a 4 or 8 channel relay board attached that allow me to turn on or off the individual controls on the furnace. It works well with my two stage heat pump and fan at my home, but, I need some work to get it 100% at the hackerspace and at the farm.
I mainly did this because I needed something that allowed me to cover more rooms than the Nest (and I'm adding duct dampers and fans to my heating system, so I can selectively heat and cool more rooms to better temperatures).
When you get a chance, would you be kind to write a "how to" blog post about how to build and wire one yourself, so others without any clue about how to do this can have a shot at learning and doing it themselves?
The biggest thing that I had against using the Pi's GPIO pins were that they're really unforgiving, and only ran on 3.3v. My One-Wire sensor (http://datasheets.maximintegrated.com/en/ds/DS18B20.pdf) Needed 5 Volts, and that's something that the DigiSpark gave me with no issues. I literally soldered pins 1 and 3 to the +5 and Ground pins on the back of the digispark, pin 2 to the I/O5 on the digispark, and ran a 4.7K resistor across the front from +5 to Pin 5 for my pull up resistor -- stupid easy to do and a squirt of epoxy made everything electrically tight.
I'd rather I it didn't auto-play and let me choose whether I want a page to swamp my bandwidth and CPU. Even over an 8Mb/s ADSL connection on a quad core Xeon workstation with 12GB or RAM and fairly decent video card this page is one of the worst behaved I've encountered in a while.
Sadly I won't be reading any of the content because even after five minutes it's killing my browser. To the spark.io blogging team, please don't assume unlimited wads of broadband. Let the reader decide whether they want to play your videos, and you know, I can only watch one video at a time on that page, so why start them all playing at once? This is no better etiquette than CNN or MSNBC or an adware farm where they start playing videos at you upon arrival. It's very rude.
Bluekitten is just the 100th or so reincarnation of recoiledsnake, which is as far as we can tell a Microsoft astroturfing campaign. Lately their sockpuppets are often female, to give people the impression we're banning women when we ban them.
You can easily embed MediaCrush videos on your site. I'm one of the devs on MediaCrush, I can answer questions if need be. It brings in webm, mp4, and ogv, but we've fine tuned the encoding more than most people would think to, and we have the video player UI in place if don't want to autoplay.
I'm running Windows 8.1 on an i5 with Chrome and didn't notice any slowdown (nor fan speedup, or any of the usual issues sudden resource drains tend to cause) at all either. Looking at task manager shows Chrome is only using 13% of the CPU while I'm actively viewing that page.
I'm sure YMMV depending upon OS, browser, underlying installed codecs handling the video (and their associated gpu acceleration or lack thereof), etc.
I'd have to agree. It's not the bandwidth that was the issue though. All those videos loading and playing at once crushed my poor browser (Waterfox 24) until I was able to slowly pause them one by one. This does, however, work mostly smooth on my version of Chrome (32).
It wouldn't have the same effect without auto-play. This is essentially a smarter GIF. Looks like the CPU suffers from all the videos playing simultaneously, maybe pausing videos as soon as they go off-screen could solve that (while browsers don't get to optimize this).
Same with Safari 7 on my MacBook Pro. Worked a treat, was a super cool concept. I'm surprised to see all the complaints with Chrome, I always took that browser to have the best support for this kind of stuff.
A different video card, codec chain, and on and on, can yield a very experience. Being an early adopter of many Harry Potter-esque moving pictures can yield nice content, but it will invariably cause client issues.
As I mentioned in another post, it works fine in Chrome 34 on the same hardware that it struggles dramatically with in Chrome 32. Both of them have hardware decoding enabled, and so on. The Chrome 32 instance has no problems at all playing video anywhere else.
Indeed, on that same line, the videos don't load at all on Chrome on the Nexus 5. The N5 of course supports h264, and has no problem on any other site that I've ever discovered. Maybe their server is now overloaded (EDIT: Okay they're using S3....going to be an ugly bandwidth bill from that...and it's fully responsive), but it also doesn't load on the iPad 3rd generation running iOS 7. Again just black boxes.
EDIT: I wonder if it's because they're (s3) setting the content type to octet-stream, rather than video/mp4. Some clients seem to be going on alternate decode paths or are refusing to display it because of that.
In my experience Safari is generally much smoother and uses less power than Chrome on OSX. Chrome frequently makes my MBP uncomfortably hot on websites that Safari doesn't break a sweat on (like Flash videos on Youtube, although Chrome's built-in Flash could be causing problems). It's unfortunate.
h264 videos are generally significantly smaller than comparable resolution animated GIFs, not to mention being much better quality: It is a very good thing that the era of animated GIFs is drawing to a close, and the pace with which MP4 is supplanting animated GIFs is quickly accelerating.
Having said that, an h264 source can have magnitudes more complexity for playback, and generally the greater the compression the higher the playback complexity. Having five or so high profile multi-MB decorative videos autoplaying on a page is excessive.
They shouldn't use autoplay. They shouldn't even initialize until scrolled into view. They shouldn't all play at once. Their bandwidth usage is going to be enormous from this HNing, a single page impression pushing 15MB+ (EDIT: I hadn't really delved into it at the time given the display issues, however I grossly underestimated when I said 15MB).
Worked well technically on i7/win7/laptop(32GB)/firefox. I didn't like the effect though: jittery, repetitive, distracting. A tripod would have gone a LONG way here as well as only using in focus images. as only using It was like channel surfing. I said, "ooh ahh" to myself, but didn't hold the channel there for long even though I love the concept.
FWIW it runs fine on Chrome Canary (currently 34). CPU/GPU is still excessive for videos that people might not even want to see, but the videos all run smoothly and the browser remains responsive. Not sure what the Chrome difference is for that.
Different person, but the videos do not load in either the iPad (iOS7) or Nexus 7 (Android 4.4) for me. As mentioned in another post, the content-type being returned is wrong for video/mp4, at least from the S3 servers I am hitting. Perhaps this varies and is correct for some, but it seems to be the reason for so many varied experiences -- some clients just ignore it, others seem to choose render paths based upon it, and others refuse the content because of it.
Wood is basically more expensive than plastic for mass-manufactured items. The basic raw material is more expensive. You can't source a large volume of aesthetically-identical pieces, so its harder to produce identical items. You can't injection mold wood, so higher manufacturing costs.
There are "manufactured" woods which address many of these issues, but they also tend not to be deemed as beautiful / strong as the real thing.
I'm only involved in manufacturing as a hobby for my custom keyboard projects. But my bet would be that it's about injection molding .
Once you got the molds machined you can mass produce plastic parts extremely cheaply. Need more plastic parts? Get a few more molds made. It scales pretty well because one mold can produce multiple parts at once and the injection molding presses itself are relatively inexpensive and pretty much fully automated.
Wood while being great for prototyping doesn't scale that well in mass production. You would machine it using CNC routers and if you need more produced you need new expensive CNC routers which can only produce one part at a time. Also the CNC routers I know you have to baby sit.
Again: That's only from my limited experience with limited runs (a few thousand pieces at most). Maybe someone who knows more about real mass production can elaborate a little more on this.
I believe its the reason that injection molding plastics is so popular versus doing metal and wood. Wood and metal most of the time require a subtractive(sp?) manufacturing process that requires a lot of raw material, assembly steps, and waste. Injection molding and 3D printing is additive that is automated and simplifies the process with minimal waste.
You can't beat polymers for consistency, finishing, handling, tooling, durability, etc. For each friction point with wood, you could create dynamic systems to alleviate the pain or you could just start with materials designed for scale.
One of the good things about wood is you don't have to worry about it sticking around for 1000+ years. The problem with plastics is most of it can't be recycled. Not the way we think of recycling.
Aluminum cans are melted down and turned back into aluminum cans. Polymers are ground up and injection molded into lower grade polymers. Once too many polymer chains get broken the grade is too low to be usable.
Careful polymer selection can work around that. PLA can be digested back into starch by an enzyme or composted at high temperature. There are plastics that can be cleanly incinerated or ground up and embedded in concrete mixes as insulation. You can chemically depolymerize a number of plastics and end up with much more manageable products. The real problem is getting all that stuff out of the world at large and into a processing plant.
> The real problem is getting all that stuff out of the world at large and into a processing plant.
The problem with plastics is its cheap acquisition costs and expensive disposal costs. One of the good things about living in a developed country is we sorta manage the disposal costs well. In developing countries they don't manage plastic disposal at all. In all my travels one of the overriding themes I've seen is plastic on the sides of road, in rivers, on the beach.
When I removed the wooden door from a house we didn't need to call the city to send a special truck to dispose of it. We chopped it into pieces and used it for bbq. Then we mixed the ashes into the compost. Disposal was $0.
While plastic is cheap in the short term I think there are a lot of long term costs that get ignored.
(Those processes mostly just mean that it all comes down to whether you want to put energy into something. Whether they are economical today doesn't factor into the usefulness in eliminating mountains of plastic.)
Sorry, I should have elaborated. Flammability popped into my mind because of the need to list the flammability ratings of the materials in a design when going through regulatory testing and certification (UL, CE, etc).
This makes me happy. I have a house with electric heat and eight thermostats pushing Nest costs into unreasonable territory. I'd love to be able to remotely set all my thermostats to 55 degrees or get certain zones to react based on events fired from my phone, (e.g. coming, leaving, charging with screen off aka sleeping, pending alarm)
Unfortunately, with my electric heat the thermostats sit inline with the heater's power source so I need devices that can safely handle 120v.
One problem with the Nest is that if your thermostat is in a poor location (more of a problem with central heating), the motion sensor won't see you. With the ones I suggested above, you can programmatically link those to ~$40 motion sensors installed in the correct locations that will actually work.
I have one of those; it works pretty well. Before the Insteon was released I had a X10 thermostat which was somewhat cheaper. I worked around the "X10 is only 95% reliable" problem by having misterhouse set the temp every 5 minutes or whatever it was.
The financial payback time is unfortunately infinite but it was interesting.
One advantage of programming an insteon thermostat is its just plain old off the shelf technology to all end users including repair guys, although how its temp is set is magic and done by computer.
Most of the software work is already done by the misterhouse system, its not like you have to write your own insteon drivers or write your own sensor drivers or whatever. Misterhouse's support for Insteon has varied a bit over the decades. Last time I had to mess with anything it was a little fuzzy. I would imagine things have advanced considerably in the last half decade or so. I do not currently have misterhouse controlling the insteon thermostat mostly out of lazyness, I'll eventually re-enable it.
Not large at all. One thermostat per room. With electric heat you have to put a thermostat in line between the circuit breakers and the heating element (radiant panels in my case). Centralizing the house on a single thermostat, like you would with forced air, would actually be incredibly difficult. It would also lose the benefit of fine control; one of the few positives of electric heat.
Worth pointing out (and you touch on this above) that this is not a function of electric heat but a function specifically of the type of electric heat (radiant in this case). I have electric heat by way of a ducted electric heat pump which is not zoned and thus centralized. Zoned ducted and non-ducted electric heat pumps both offer localized control over heating.
Replacing an existing item in your house with something for 10x the cost is not something you want to be doing too often as a homeowner. The benefits have to be quite significant. I've got a simple programmable digital thermostat that works fine. If I come home earlier than normal, I just bump up the heat manually. Calling ahead with my phone wouldn't add all that much value for me. If it was $50, I'd think about it. $250? No chance.
I mean, I just don't get why people are so angry that someone would possibly want to spend some extra money to have a cool thermostat. If it was a cool video card for $249 that just lets them play games, no one would blink an eye. But because it's for a house, but for a part of the house that is supposed to be utilitarian, it's a sin.
Electric heat means they have electric baseboards in each room, making individual control logical and obvious, so eight rooms really isn't outside of the ordinary. Compare that to central HVAC where there's one furnace and at most you have electric dampers restricting flow to an area of the house (though few houses have even that).
Not only that, but basic, programmable load bearing thermostats are relatively expensive compared to the typical control line alternatives. However, even with basic programmable thermostats (>=$75 a piece), I saw my electrical bill drop considerably vs. a 30 year old mechanical thermostat in an apartment I lived in the past 4 years.
We've moved since then and took the thermostats with us. I still have two if you want to buy some slightly used aube programmables (nothing with wifi, but better than nothing).
I have the exact same situation but I have spoken to Nest Customer Service and other "smart" thermostat CS and all have told me that they will not work with the wiring for electric heaters commonly controlled by a single dedicated mechanical thermostat. I was out of luck so if you find an working "smart" thermostat I would love to get one.
One thing I found about hardware is that the prototype is only 10% of the effort. Sourcing components for mass production, government regulatory hurdles, and then that damn enclosure are 90% when everything goes right.
I can build all kinds of things with my arduino and all of those awesome little one-off function boards you can snag on ebay from china theses days. I can't build 10000 of any of them.
I'm trying to understand if you can self-host the server-side piece of this. I've wanted to have a networked thermostat for a while, but all the ones I found connect to the vendor's server, which is silly. I'd like to be able to point the device at my own server so I have full control.
EDIT: Yep, the Common Questions section of their website says that they'll be releasing an open source version of their Cloud. Awesome.
Even better than not sending your usage information offsite: not having the system stop working when spark.io goes out of business (or is purchased, or goes to version 3, or...) and stops their servers.
I think this is great but there are lessons here from desktop Linux, Facebook clones, etc, which is that retail is hard.
In order to ship a widely used operating system, you need a support infrastructure, consumer research, drivers for lots of hardware, warranties, marketing, payroll, operations, accountants, regulatory compliance. The product is almost the easiest part.
I imagine that Nest understands all this. Putting a piece of hardware in someone’s house – one that’s connected to a furnace or which claims to protect against fire – means a lot of liabilities, broadly defined.
I’d love to see an open source version get to that level of maturity and support. It does happen but it takes a lot of people.
(Tangent, but when I started at Stack, a lot of people said they could (and did) build a clone in a weekend. Sure, as an approximation of the technical product. But that ain’t the ‘retail’ product, which is actually comprised of community, goodwill, SEO, quality control, and a lot of other things.)
There is a project called GNU remotecontrol that I just discovered that could be used for this purpose. It's important that you can be in control of your thermostat data instead of handing it over to Google/Nest/some other malicious vendor.
It still seems like a really bad idea to rely on a third-party to control your heating. They might not have any malicious intents, but they could just shut down the service one day and your thermostat won't be worth much anymore. Not to mention the security implications of running your thermostat on some remote server that you don't control.
Going from a few examples that obviously cause harm, beyond dispute, I can immediately think of several that do not lend themselves to quantification.
(I hesitate to list them, lest I incur low-brow "Do you really think what google is doing is that bad?!?" comments (hint: harm, while not necessary quantifiable, is not all made equal), but if you really can't think of any examples I can list a few.)
Thermostats turn your heat/AC/fan on and off by connecting and disconnecting an electric circuit. Older analog thermostats did this mechanically; newer ones do it with electronic switches. That circuit has some small amount of current running through it to signal to the heating unit whether it's connected or not.
The control circuitry in the heating unit is sensitive to a range of voltage values. It has to be, because V=IR, and there's no way to know exactly how much wire (and thus R) will be strung through your house. The Nest can thus pull some current off the wire to charge its battery but keep the signal strong enough to flip the heater on and off.
My house has a new electronic "zone box", which, because it's all semiconductors, only needs to run a very small amount of current through the wires. That's not enough for the Nest to charge. Fortunately, the standard home heating wiring includes a "common" wire, with a low amount of constant voltage suitable for devices like the Nest.
"At Spark, we’re making it easier to bring connected
devices to market with the Spark Core, our Wi-Fi
development kit, and the Spark Cloud, our cloud service for
I found SparkCore on github and the C++ communication lib for Core to communicate with SparkCloud , but I did not find SparkCloud itself on Github. Is that component going to open-source as well?
It would be nice if you had the option to host your own cloud service. You could protect your business model at least partially by using an open source license that requires people to change the name if they decide to fork it and productize it, such as the Artistic License v2.
I have built a similar system, and expanding it to more devices (think: devices other than thermostats). However, I use my own custom messaging/web server for communicating with the device from anywhere in the world. Think controlling your (ex: toaster) in NYC from LA without configuring any networks, vpn, ports,...aka Nest-like. Combined with some machine learning and machine "thinking", its pretty powerful.
The Spark Thermostat is great minus the fact that you need their web api for communicating with it. But for a 1-day build, how can anyone disappointed! Great job Spark team.
In regards to my own devices, I am definitely going to have to take a look at Spark now. Cool hardware.
Are there any specifics on how the underlying Spark platform handles security? On their product page it says that Spark Cloud "creates a secure environment without forcing your web browser and the Core to speak the same language, which would be taxing on a low-power, low-cost microcontroller." Which isn't reassuring.
They don't provide any specifics in the docs either, only this:
"Security is hard. It’s especially hard on an embedded system, because encryption is resource intensive. But it’s also important, because you don’t want anyone turning on and off your lights, or worse, locking and unlocking your front doors.We hand-picked a set of rock-solid security protocols that are secure and efficient, so they work great on an embedded system. They’re baked into the Spark Protocol, which is open source and ready to be extended to other products."
I get that encryption may be difficult on embedded systems, but I would also argue that if a small embedded system can't handle strong encryption then it's not ready to connect devices to the web. I can't find any links to source code - anyone know what sort of encryption they use?
The nest cannot be always on because it is not provided with enough power. It has to use the power it has to charge an internal battery so they it can work at all. Always on would not have sufficient power.
Totally agree. I've been tinkering with my own project to do this. I wanted the recirc fan under programmable control as well to try and mix the house air once in a while and distribute the temperature a little better.
Nobody has ever offered this in a thermostat with the possible exception of the RadioThermostat CT30/3M50, which has a JSON API and lets you manually control the relays.
??? My 30 dollar third-world built brazilian crappy on-off thermostat has manual fan on and off. It can be programmed to turn on automatically when over/under a given temperature and also to not run for more than a predefined ammount of minutes.
As I understand it any temperature control designed for big refrigerators or freezers has this features. Some even allow you to pre-configure fan cycles (i.e. on for x minutes, off for y, repeat) and turn the cycle on or off depending on temperature or compressor state.
How does the thermostat control temperature? Am I crazy, I feel like I'm missing a section on how this device connects to the central air, Ac, heater, fan or something that can affect temperature. Under hardware: "relays to control the furnace and the fan." But I don't see details on the relay.
You just wire the relays to the control wires coming out of the wall. You can turn your furnace on and off by just touching these wires together. It will depend on how your system is wired there can be a lot of variations. Of course making sure your product works with all those variations is one of the hard parts that they didn't address.
If you're interested in building IoT, wearables, and externals, I'm getting an expo + hackathon together called Hackendo (http://hackendo.techendo.co) for April. I would really love the community's support in helping make this awesome, so anyone with experience in this area or feedback on how I should run the event, please reach out.
I gotta say -- the use of video in this blog post is outstanding. Best use case of HTML5 Video I've yet come across, frankly. Sorry, I'm supposed to comment on the actual comment...haha. Just saying I love the format. :)
I've now extended the idea into a fully working DIY DJ Controller. My first big electronics project... I've been planning to open-source the build documents for quite a while now. : http://www.youtube.com/watch?v=BFhLQzisx90
This is pretty cool. For some time I've been interested in building a Nest clone. I like the concept of Nest however it doesn't work for me because my wife's work schedule can't be predicted with machine learning and therefore I think Nest would actually end up being less efficient for us. She keeps her work schedule in a calendar though so my plan was to have the thermostat use her work calendar to optimize our heating/cooling plan. This project looks like it could be a good starting point.
this is great but with these devices and 'the internet of things', the most important part is not the devices but the data. And with this, instead of Google getting all the data, Spark is getting the data, and the data is where the money is. And once they get more data and learn to use it, they will become a more valuable company and eventually might get acquired.
I think for something to truly be open-source and beneficial for everyone, everything about it must be open, including the data. The data from all the connected devices globally could be stored on an open database that anyone can access and use. Its one thing to 'learn' with the limited data that one device might generate, but for a machine to 'learn to learn' it should be able to study ALL the data that might be useful.
This kind of organization could lead to a type of opensource corporation where anyone can be an 'employee'. Employment and compensation could be based off a public list of contributions to the project. To each according to his contribution.
This idea could be applied to anything that's used in public and generates data. Autonomous cars, home automation, drones, (NSA data, slightly more complicated but still could be open sourced). But as long as we're tricking ourselves into thinking we need 'money' to survive, the organization or company with the most of it wins.
Once you add networking, Arduinos don't really have much cost benefit over a full-fledged Linux SOC board. An Uno plus an Ethernet shield ends up being nearly the cost of a Raspberry Pi, which is several times more powerful.
I built out my XMPP-controlled office thermostat on a BeagleBone Black, which costs a bit more than the Pi but has way more pins, including analog inputs, which are pretty important for temperature sensors. Plus using a Linux machine meant being able to choose your language instead of being stuck with C, so I took the chance to learn some Erlang: http://technomancy.us/171
That's a great idea. Another way of doing this is to use Google map. Google map already knows your location for their collection of traffic data , they could cross reference this to when they car leaves a parking location. The emptying of the car park is notified to Google map. Trouble is the data is only available to Google.
>we built our own approximation of the Nest Learning Thermostat in one day — and we’ve open sourced everything. In this process, we’ve come to respect the incredible technical challenges that Nest has solved while also coming to understand how much the game has changed since they first started.
I missed the technical challenges - this seems trivial, and exactly how easy that I would imagine it to be. The only challenge that I see is figuring that people would want a thermostat controlled by a phone app.
Since that's been figured out, I'm going to be very surprised if within 2 years 10 vendors don't have $50 versions sold at Wal-Mart, and there aren't 2-3 different open source software stacks competing to support a few of them.
I remember when the iPod was still crazy expensive and people were abandoning their much cheaper Rios in droves.
Btw, I've purchased a few cheap home devices. For example, a few smart light switches. I've ended up switching back because they made my life more complicated and difficult, the opposite of the intended effect.
The iPod is an example of a prettily designed product that felt good in your hand, but that clearly made working with music "more complicated and difficult." At the time, it was clearly the worst of breed when it came to listening to music. Still is, in my opinion, but my perception is more than a few generations behind.
I think that the lesson from iPod example would be: Marketing matters.
Judging the quality of a tool by its price is the reason that Monster can sell $5 cables for $50.
edit: I'd be happy to hear of any improvement that iPods made to mp3 players other than making them into expensive status symbols that refuse to play anything but a proprietary vendor format that all music has to be lossily converted to by a buggy, slow, invasive application (at the dawn of iPods, not whatever condition iTunes or iPods are in currently.)
> The iPod is an example of a prettily designed product that felt good in your hand, but that clearly made working with music "more complicated and difficult."
Interesting, because the first iPods I bought for my wife and I were specifically to address the fact that everything else on the market that I tried at the time was a pain in the ass to use. I found the first-gen iPod Nanos in conjunction with iTunes to be the opposite of "more complicated and difficult". "Worst of breed"? I can name a half dozen examples that were far worse than anything Apple has ever produced. Obviously YMMV.
> I think that the lesson from iPod example would be: Marketing matters.
I often read the "it's all marketing" screeds as "a lot of people like this thing, and I don't. I am bothered by this fact. Therefore the only reason the sheep buy them is marketing." Could be that the sheep truly find that it's a way to trim their wool that suits them better.
Doesn't have anything to do with "sheep." It has to do with availability and expertise. People aren't aware of every product that can fulfill their wants (availability), and sometimes don't even have a want until they have already been exposed to a particular product. They also frequently don't have the expertise to effectively differentiate the products that they are aware of.
It works the same whether the product is good or terrible.
>I often read the "it's all marketing" screeds as "a lot of people like this thing, and I don't. I am bothered by this fact. Therefore the only reason the sheep buy them is marketing." Could be that the sheep truly find that it's a way to trim their wool that suits them better.
This is more a screed than anything I've said. I don't care if you use an iPod.
>"Worst of breed"? I can name a half dozen examples that were far worse than anything Apple has ever produced.
You're right - it was a bit of an exaggeration. Microsoft's "PlaysForSure" cert was nearly as bad, and all of Sony's lines were garbage (IMO.) What I mean to say is that there was never a point when you couldn't find a $50 player that offered a far better UX than an iPod.
You're either trolling or not old enough to remember what the portable player scene was like in 2001. Burned CDs on portable cd walkmans were the norm. Minidisc was high tech. 2/4GB of onboard memory + expansion slot was typical. "Anti-skip protection" was still a feature worth mentioning.
The iPod's storage capacity was massive in comparison to nearly everything else. The firewire connection made uploading huge amounts of music crazy-fast in comparison to the old USB connections other players were using. Look at digital players of the same vintage -- stupid complicated interfaces & displays -- the clickwheel was a revolution in UX. So much so that it remains, largely unchanged, on all but touchscreen ipods.
Thanks for the expansion. I took your comment as another "iPod sucks, blah, blah, all marketing" type. Obviously the problem lies in my knee-jerk reactions. :-)
> You're right - it was a bit of an exaggeration. Microsoft's "PlaysForSure" cert was nearly as bad, and all of Sony's lines were garbage (IMO.)
Aaaand, you hit on the top two candidates for "Why Did mikestew Buy an iPod?" MSFT's offering was broken from the start, and later yanked (buh-bye, music!), and the company that brought you the original Walkman obviously lost their magic. But of the $50 players, I never found one worth keeping. Maybe I just never learned about them, hence making your point of "marketing matters". :-)
It definitely was NOT the worst of the breed. I had a couple of different pre-ipod mp3 players, including the original 32MB Rio, and the iPod was excellent. The major thing was the cool design, simple use, and their huge storage capability at the time. The thing that sucked was always iTunes, and the price. Everything else about it was fantastic, including the sound quality.
Yes, their marketing was brilliant, but it won't cause people to buy things they don't want in perpetuity. Eventually, even the most brilliantly marketed product will fail if customers don't want it.
>The thing that sucked was always iTunes, and the price.
Those things can't be separated from the product though, which required iTunes and was expensive. Replacing the firmware on an iPod makes it perfectly fine. The reasons that the iPod was worse than many of its competitors weren't due to incompetence, they were by design.
>Yes, their marketing was brilliant
I'm not even saying that their marketing was brilliant, just pervasive. When the iPod came out, a large portion of the population wouldn't have even known and/or experienced that your music could be easily put on a tiny device at all. Their first exposure to the concept would have been an iPod ad, or seeing someone with one.
I always assumed that the reason that iTunes was a necessity and mp3 file transfers were so slow was that the files were being converted during transit. I may be wrong. If I am wrong, though, that would make the necessity of iTunes purely anti-consumer.
The tricky bit is the learning; the first few weeks or so with it I was adjusting it all the time, now I don't need to do that, it knows I prefer to go to bed warm and wake up cool and just sets the right temperature.
I thought the phone app would be gimmicky, but it's nice to be able to get off the plane and un-autoaway the thing so by the time you get home it's comfortable.
My problem is that I don't really have patterns. Sometimes work from home, sometimes don't. Do a lot of traveling. Hours vary quite a bit. The only thing that would tempt me about Nest other than general coolness is that I could remotely turn down heat when traveling if I forgot before leaving. But that's not worth $250.
Totally agree with you. The down side is not only machine learning may not meet my satisfaction, it may make me annoyed. My current thermostat works pretty well for me if I need adjust not too frequently everyday. A scheduled plan should be good enough if we really want to improve this kind of devices.
The second problem is that it's lacking of systematic design. Think about we are going to have some many "Intenet of the things" in our home or office, we have to download some man apps, each of them needs cloud services which usually not free. This is how they make money after the hardware sales.
I wouldn't imagine that the learning would be tricky for someone with familiarity with machine learning in general. There are more people who are familiar with machine learning than people who work for Nest.
I always thought the main technical challenge would be the machine learning, which I imagine was made more accurate by relying on data from groups of people rather than just the one household. Although for thermostats, I really would rather it just learn from me alone anyway.
To the extent that this is a popular idea, it wouldn't be a big deal for someone to come up with a commercial 'final logic module' that sat between the user interface and the furnace. It could do a sanity check on the requested operation before carrying it out.
(Sure, it would have to have most of the functionality of a thermostat, but so what.)
I think that this is a really cool project. But I think that the problem here is still fundamentally the same as the one faced by the nest.
The thesis of spark.io is "you can trust us with your data" not you have control of your data.
The spark is built on a cloud connected platform. even if you can see and control outputs from your board you still exist as part of their ecosystem. Which is basically the functional equivalent of using the dropbox api to build something instead of google drive.
I won't be excited about home automation until someone goes the way of an open protocol for these types of devices that doesn't require a centralized pass through.
Because if history has been any kind of teacher, it shows us that spark.io will probably get sucked up by google or somebody in the near future.
First I would say that nest certainly has a good user base. Keep in mind 3.2 Billion is just what google was willing to pay for the company this is in no way a metric for the success of the product. Liberal estimates give the company a potential revenue of 111 million a year based the amount of units they claim to produce, but this is a maximum sales number. Also the argument that most users don't care about this issue has been clearly shown to be incorrect. http://torrentfreak.com/bittorrent-sync-hits-1-million-users...
Spark is still like nest a company, and THEIR argument is that their product is great because of the control it gives you over making your own solution. I am not saying that nest isn't a valid product for the market I am simply saying that sparks thesis isn't really valid because they claim to put the user fully in control when really they are still the gatekeepers.
Why would you want an open source Nest? Is there a market demand for something which is uglier, harder to use, takes more time to install, and works worse? Do you also build your own toasters or automobiles?
I buy connected devices so that I can, well, connect them -- I have a server running that does things like change the temperature on my Nest based on a different brand motion sensor in a different room, or based on voice input on my phone.
In that dashboard of mine, you see devices from 6 different companies that I've integrated. 3 of them required reverse engineering some kind of website for remote control, even though all that website does is pass on a command from my home network back to my home network.
This would break if the website goes down, the website rate limits me, the website blocks my IP, or the website owner decides to sue me under CFAA because their TOS probably didn't authorize remote control outside of their official apps. Nest is one of those websites. There's no official public API.
I consider alternatives where I could just talk to the device directly a selling point, and it has nothing to do with privacy. I don't care about Google having my temperature history at all.