059 iPhreaks Show - Device-Connected Apps with Carl Brown

Download MP3

The panelists discuss device-connected apps with Carl Brown.


BEN: And since I'm moving, I have my travel mic with me and for some stupid reason I packed the stand and the pop filter, but not the mic, so I'm holding it in my hand; I hope it doesn’t – I hope I can hold it for an hour. CHUCK: [Laughs] I'm not laughing at you; I'm laughing at you. BEN: Yeah. [Laughs] JAIM: Can you put it on video? We all wanna watch. BEN: Well, sure, why not? There you go. How’s that? JAIM: I like it. [inaudible] crooner, or Frank Sinatra. BEN: [Singing] Start spreading the news –. [Laughter] [Would you like to join the conversation with the iPhreaks and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at iphreaksshow.com/forum] CHUCK: Hey everybody and welcome to episode 59 of the iPhreaks Show. This week on our panel we have Ben Scheirman. BEN: A severed foot is the ultimate stocking stuffer. [Laughter] CHUCK: Jaim Zuber. JAIM: Hello, from Minneapolis. CHUCK: Andrew Madsen. ANDREW: Hi, from Salt Lake City. CHUCK: Pete Hodgson. PETE: Hello, from the West Coast. CHUCK: I'm Charles Max Wood from DevChat.tv, and this week we have a special guest, and that is Carl Brown. CARL: Hello, from Austin, Texas. CHUCK: You wanna introduce yourself really quickly, Carl? CARL: Sure. I'm an iOS dev, mostly contract stuff. The first app I shipped was the calorie tracker for LiveStrong.com, so I've been doing a lot of health stuff. The last few months I've been working on an app for a wearables company in town. They’ve got a watch that they're in the process of building that counts reps and sets at the gym. I did a presentation last September on apps that talk to devices, which is what we’re going to talk about today. CHUCK: Very nice. When you say apps that talk to devices, we’re talking Bluetooth? CARL: Not necessarily, but lately that’s become the standard. I guess a year ago, I was working on a device that had a Wi-Fi server built into it and we talk to it that way. Things like the AR Parrot drone, which is this quadcopter that the app talks to that uses Wi-Fi, but Bluetooth Low Energy has become more and more popular lately. ANDREW: I have a little experience with this, and it seems like in the olden days really, unless you wanted to join Apple’s Made For iPhone program, which is not really necessarily an easy thing to do, Wi-Fi was really the only option. Is that right? CARL: Right, and [inaudible] Bluetooth Low Energy is that you don’t necessarily have to have the whole Made For iPhone program. You don’t have to go through all – I mean, if you want the Made for iPhone sticker on it you do – but you can build a device and you can talk to it, or you can take a device off the shelf like a Sphero or an AR Parrot drone, and you can –. Well, the AR Parrot drone doesn’t do Bluetooth, but you could take a Sphero and you can write your own app for it and put that in the store, which is really cool, and you don’t have to go through the Made For iPhone program at all if you don’t want to. BEN: So if you're a Raspberry Pi Tinkerer, then you really don’t have anything stopping you from talking to that. CARL: Right, which is a very nice thing compared to the way Bluetooth used to happen. CHUCK: So what are all the ways? I mean, there's Wi-Fi and Bluetooth that we’ve talked about; you can plug stuff into the Lightning adapter, I guess. CARL: Right, and the old 30-pin adapter, but both of those require licensing and going through the Made For iPhone program. There's some stuff like Square that’s going through the headphone jack, the little credit card reader thing? CHUCK: Yup. CARL: Those are pretty much the ways. CHUCK: Yeah, I always was wondering what my credit card sounds like on Square. PETE: [Inaudible] where they played it back. The guy that was the lead engineer on the swiper did a whole talk about how it works; it was really, really interesting. ANDREW: Yeah, I was really surprised when they made the cha-ching! sound. [Laughter] But fundamentally, the stripe on the credit card is not really any different than a cassette tape, the audio tape. CARL: Yeah, it’s just 1’s and 0’s - it’s a fairly standard format. I did a startup ten years ago that did debit cards, so it’s a fairly standard format. It’s actually fairly low bandwidth; there aren’t pretty many digits on it at all. PETE: I saw a cool, little product the other day that was a light meter that uses – that plugs into the headphone jack. CARL: Hm. Haven't seen that one. PETE: Yeah, called Lumo, I think. L-U-M-O. CHUCK: So what kinds of things, or what kinds of applications do people have for devices? CARL: Recently, last week at WWDC, they were talking about HealthKit a lot. There were a lot of things like Bluetooth chest straps; there was some Bluetooth blood pressure monitors where you could basically take data, get that into your phone, and then eventually on iOS 8 you'll be able to get that to providers and hospitals and do all kinds of neat stuff with it. There's also, like I said, the Sphero, which is a little – if you haven't seen it – it’s a little remote-controlled ball that drives around and uses Bluetooth, and it’s a lot of fun. You can actually use it as an input device too; there are some apps that use it as a controller, which is kinda cool. There are some games that do use that; there's a thing called DICE+, which are actually like physical, six-sided dice that you roll, and then the Bluetooth will actually tell the iPad or the iPhone what you rolled, and so you can add that as a physical component to the game that you're writing. PETE: That is a really cool idea. CHUCK: I know, why didn’t I think of that? PETE: Yeah. CARL: And the really nice thing about writing apps that talk to devices is you segmented your market, so as an indie app developer who’s trying to get noticed in the App Store, one of the things that you can do is you can write an app that supports one of these devices knowing that at the point that someone actually buys one of those, like a Bluetooth heart strap, the first thing they're going to do is say, “Okay, let me go search the App Store for apps that support this heart strap I just bought.” Now, instead of having to compete with all of the apps from the App Store, you're only having to complete with a very narrow set, and you know that the market that you're competing for is not every iPhone developer, or every iPhone user in the world, but ones that had enough spare cash and cared enough about their health to buy that specific heart strap, which is kind of useful for knowing what you can charge for your app. BEN: Yeah, that's definitely interesting. The average price part for that is much higher than your typical game. CARL: It seems that the users will support a higher-priced one for that, if you really care about your health and you're willing to pay more for these kinds of apps. BEN: Do you wanna get into some specifics about how you communicate using, say, Bluetooth to a device? CARL: Sure. There are a number of standard Bluetooth profiles – they're GATT is how they're referred to. The heart rate monitor is one of them; there's a battery one that lets you basically see from a particular device what the battery usage is; there's a blood pressure one; there are a number that are standard, Bluetooth-industry, here-are-the-standard protocols. There's another set of stuff that Apple does for notifications, so if you have a Pebble or – I have a Fossil meta watch – if you have one of those, then basically it can send push notifications directly to the watch. In theory, you could send it to anything else that use that same protocol, so you could send it to the dashboard of your car or that kind of stuff if you wanted to be able to see notifications there. That’s an Apple kind of thing that’s part of core Bluetooth. And then also part of core Bluetooth is a thing where you can basically define your own characteristics. You can define your own attributes, and you can define your own data protocol and packets between a device and a phone, and so that’s what we’re doing in the wearables where all this basically –. The company I'm working with, we’re sending accelerometer data, and so we’re having to make up our own protocol between the watch and the phone to be able to move data back and forth, and that's all, from a developer’s standpoint, inside the core Bluetooth protocols. PETE: The way I understand it with Bluetooth Low Energy is it’s not like – with Bluetooth, it felt like it was more like a two-way stream of stuff, but with Bluetooth Low Energy the model is more of that you're setting values somewhere and then the thing that’s listening to you kinda notices that the values changed. Is that right? CARL: Yes. The normal – I don’t know if normal’s the word – but the way that we usually do it is there's a – and I'm going to mess up a class name – basically a peripheral didUpdateValueForCharacteristic. Basically, I register for a callback and say, ‘okay, anytime this particular characteristic on the watch changes, then I want this block to run, this notification to run’ and that I get this callback from core Bluetooth that says, ‘hey there's a new value for this heart rate thing’ or ‘there's a new value for this accelerometer thing’ and then I have my code right there that does whatever it is that I introduced [inaudible], send it off to a web server, or whatever happens from there. CHUCK: Or make the numbers lower so that I don’t feel so unhealthy. CARL: [Chuckles] That’s in the presentation layer. [Laughter] PETE: You mentioned accelerometer data, as you know that’s – presumably that, in theory, can be changing super fast. How many of these characteristic change events can you get in a second, or how frequently can you –? CARL: You can run 60Hz, which is basically the frame rate. You might be able to run a little faster than that, but if you get too much faster than that – you can go a little bit faster than it, I think, but if you get too much faster than that, then you'll start to back up because you're literally not going to be able to move the data between the watch and the phone as fast as you can collect it, and then it’ll basically just start queuing up and queuing up. In my experience, if you send in 20-byte packets, which is the default, you can run about 60Hz. That’s about as fast as you can get – 60 packets/second. PETE: Gotcha. Is there more [inaudible], the more things are changing, or is it a constant? CARL: The more packets you send, the more battery drain there is. It’s important, though – there's a session on low energy in WWDC last week – it’s very important that to the extent that you can, you send as much data as you can altogether and then stop, so let the phone go back to sleep. If you're waking up once a second and sending something and then you went back to sleep and waking up, the connection [inaudible] in going back to sleep as the watch. The phone basically never gets a chance to go to sleep and so it never gets the chance to turn the battery off – or not off, but to reduce the battery usage. That will really drain the phone quickly over time, but if you basically say, ‘okay, I'm going to queue up everything that I need to send and then I'm going to send it all in one burst so the phone only has to pay attention for that short period of time, that’s pretty good for battery on the phone and on the watch, because it’s expensive when you're talking about tiny, little batteries. CHUCK: So you just aggregate the data to a certain degree on the watch and then send it all at once. CARL: Right. PETE: In the Apple [inaudible] big fans of doing that in other places, right, like only waking up to the network every now and then to poll for new GPS locations or something like that. CARL: Right. Powering on the radio is always more expensive, and from what I understand, powering on the cell radio is actually really expensive, so the time is really important if you're doing a bunch of bandwidths or doing a bunch of server stuff, talking over 3G or LTE or that kind of stuff – you really wanna batch those and then wait. The cool thing is the new NSDownload [inaudible], you can just basically say, ‘okay, so here are my tasks. Here’s how often you need to happen’ and then it’ll kind of queue them so that when all the different – this is on iOS 7 – but when all of the different things on the phone are ready, it’ll light it up, turn all of the apps that need to send something on, but all of them sending and then turning back off. That saves a lot of battery life. JAIM: If you have a device that has custom data, how would you specify in your application what the data is? Is it like NSDictionary? Is it C-struct? How does it happen? CARL: It actually comes across as an NSdata bytes. You get from the valueDidUpdateForCharacteristic, you get an NSData structure, and in that structure there's bytes, and those bytes are in network by order. Basically, you have to do this god-help-us – you have to go actually down to C and you actually have to parse out all the stupid, little integers or strings or whatever it is that you got, turn that into something you can actually use in objective-C or Swift maybe, and then you can take that and then you can run with it from there. But when you actually get it off the wire, it’s in raw bytes. ANDREW: In some sense it seems like that’s what you want though, right? If you're doing something completely custom, you wanna be able to send any data that you could come up with? CARL: Including the firmware development head on, which is not something that I do all the time, but I talked to the firmware guys at the companies I'm working with – putting the firmware development head on, I would certainly not want to in a [inaudible] watch with 50k of memory or something. I would not want to try to parse something out of an NSObjectStructure; that would be just a waste. And I wouldn’t wanna send [inaudible] across the network, because it’s not of any value once you get on the embedded C device that doesn’t have objective-C. Here are exactly the bytes that we need to send, saves the most bandwidth, and it makes less work for the people on the other side that have to decode it, because they have a much harder job than we do, because we’ve got a lot more high-level structures and libraries to use. ANDREW: And then you base-64 encode the NSString and then wrap it in a SOAP envelope, right? [Laughter] CARL: Nooo. And then you divide it up into a hundred different packets to handle the overhead and then you send them one at a time. [Laughter] ANDREW: WSLowEnergy. BEN: Oh, God. This probably exists. JAIM: So it sounds like, in this case, what you're talking about, if you create a different version of your protocol of the data, or if any of the types change, then you have to manage the versions, is that correct? CARL: Correct. There's a standard Bluetooth protocol for software version and hardware version, as well as like a device type so you can ask, ‘hey, are you a watch? What brand are you? What serial number are you? What model number are you?’ but there's also software version and hardware version and firmware version of the actual device itself. As part of the process, when the phone is connecting to the watch, or the Sphero or the whatever, you say, ‘okay, what firmware version do you have? Okay, for that firmware version, I know what protocol you’ve got.’ In the event that you’ve got more than one protocol, you have to switch back and forth between them, and that wiggle device, which has a much harder time from a programming standpoint, only has to worry about its protocol, and then the phone can say, ‘okay, for this particular firmware version, this is the protocol. I need to use it for this particular firmware version, I need to use this one over here.’ JAIM: Ahah, very nice. I did this type of work very early on in the ‘90s, doing embedded work. We create a structure and then we add something, and we didn’t do any things like making the structures bigger than they had to be in case we needed it in the future, and that’s probably not the right way, but this is a little smarter way of doing it. CARL: Well, I still end up with some of my protocols and I have three zeros on the end of the packet that are reserved for future use just in case I end up needing them at some point. JAIM: Okay. PETE: Yeah, I was going to say I always remember that from C programming; there's the five things you need, and then a chunk in the middle that’s like reserved for future use, and then a chunk at the end that’s like, ‘private, don’t touch.’ Used for some internal thing, don’t worry your pretty, little head about that [chuckles]. CARL: Well, I spent some time a long time ago when I was in college as a network admin/debugger-type/fighting CISCO router stuff, so I spent a lot of time looking at sniffers and TTPIP protocol headers, and so I kind of took my key from that and said, “If those guys have managed to build that protocol and we’re still running at I don’t know how many decades later, then probably they had some idea, and so maybe it wouldn’t be a bad idea to put a bit field in there that I could throw stuff in.” Actually a lot of the core Bluetooth protocols have something like that. In the heart rate monitor, for example, there's a 16-bit version of the heart rate, and there's an 8-bit version, and there's a bit field that tells you whether the next set of bytes are going to be a one-byte or a two-byte thing, just in case for somebody who has a heart rate more than 256. [Laughter] CHUCK: When you're talking back to the device, do you talk back in the same way? Do you use a similar protocol? PETE: Yeah, that’s a good question, because it’s this whole central versus peripheral thing. CARL: Right. A lot of times, what you do, you're not sending a lot of data, right? Usually, a data is pretty much going one way – it’s going from the device to the phone – and so in the phone, instead of saying, ‘hey, I'm going to subscribe this thing’ you basically just say, ‘I want to write this particular characteristic.’ When you write it, the watch gets one particular value that says, ‘hey, there's a value for this,’ and it doesn’t have to be the subscription at all and that kind of stuff. Typically what ends up happening is on the phone side you're subscribing to a characteristic that the watch just repeats over and over, and on the watch side, you're just waiting for a value to get written to you. PETE: But then the model is fundamentally, it’s not like peer-to-peer, like ‘I send you stuff, you send me stuff’ – there's these two distinct roles, right? The peripheral, which is like the watch of a device, and its publishing characteristics, and then there's the central, which is like the phone in this case, for us, normally, in that – generally, it doesn’t serve our characteristics. Is that right? I'm very half-understanding this stuff, so I'm sorry if I'm asking you stupid –. CARL: That’s a fair approximation. PETE: Okay. CARL: There's the central that the phone normally uses. As a general rule in the Bluetooth world, it’s all implemented in a firmware thing, in a chip and that kind of stuff. The interesting thing in – there's actually a really good – it’s called the BTLE Central Peripheral Transfer Sample Code from Apple, and you actually have to have two devices, but you basically put your iPod touch, you make it transmit, and you have your iPhone, and you make it receive. You can actually watch the protocol as it moves from one to the other and you can see the reading and the writing on both sides; it’s actually been really, really helpful. PETE: Cool. So if you wanted full-on 2-way communication as my peer-to-peer, rather than client-server style, communication between, say, two phones, is Bluetooth Low Energy just not – are you going to be fighting against the model if you're trying to use Bluetooth low energy? CARL: You probably could. I mean, my guess is if you're trying to do full-blown, two-way stuff, you're probably going to run into at least, my guess is, you're probably going to run into bandwidth limitations before you run into much else. Bluetooth Low Energy is a fairly low bandwidth kind of thing; it’s really not designed for lots of back and forth, and so what it might be better to do is go into the Bluetooth 2.0, which is the full-blown peering thing like you're used to with Bluetooth headsets and that kind of stuff. And then you can actually get a stream both ways, and you can have lots of back and forth, so it kinda depends on what you're trying to do. There is some 2-way stuff in Bluetooth LE but it’s really not designed for that; it’s really designed for ‘I'm talking to a peripheral, the peripheral has some stuff for me, I'm going to go grab it or occasionally I'm going to tell the peripheral something.’ ANDREW: So with Bluetooth 2.0 – on iOS at least – you have to be in the Made For iPhone program? Is that still true? That used to be true, but I hadn’t really heard lately if they changed things. CARL: I'm not a lawyer – and I don’t play one on TV – but I'm pretty sure that at some point, I've paired a headset with my phone that didn’t have the Made For iPhone seal on it, given the number of headsets that I've gone through over the years. ANDREW: Well, sure, yeah, I'm not talking about a headset, which I think is just a standard thing for phones, but I'm saying if you want to develop your own peripheral on your own app that did custom non-audio profile [inaudible] just custom data, I think that still requires Made For iPhone. CARL: As I remember, I don’t do Bluetooth too, very much, anymore, but as I remember there's a standard serial protocol that you can move stuff back and forth between, and I don’t know that you would have to have Made For iPhone for that, but I haven't looked at the requirements lately. PETE: I was looking into this the other day for some ridiculous side project that I don’t even wanna explain, and I think there is – Bluetooth Low Energy has these standard characteristic sets; in Bluetooth there's these standard protocols, and one of them is essentially just a serial port and it just has a standard way of bridging between what looks like a serial port to software and what's actually on the wire is whatever magical Bluetooth packets need to be done. ANDREW: Yeah, actually, fun fact on OSX – if your Mac has Bluetooth, which they all do now, of course, the Bluetooth hardware shows up as a serial port. If you fire up an app that just knows how to do a serial, it will see those Bluetooth ports and it can’t tell that they are anything other than a regular serial port [crosstalk] CHUCK: Well, that’s interesting. ANDREW: That’s on the Mac, where we can do anything. [inaudible] PETE: Earlier on, you were saying that there are certain classes of devices that have kind of like a standard Bluetooth working group – whatever it’s called – assigned protocols like heart rate monitors, or temperature gauge or whatever. In the past, when I hear about that kind of stuff I'm always a bit suspicious if they’ll actually be able to interact with each other correctly. If I write software for one heart monitor that'll actually – it’s supposed to be all the same but it turns out that with this manufacturer’s heart rate monitor, they encoded it in beats per second and this manufacturer, they misinterpreted the standard into a different way. Have you heard of cases where people still have to have software that only works with certain brands, implementations, whatever? CARL: No. I guess the good thing is those protocols are relatively simple. What happens a lot is a lot of those protocols have a bunch of optional things. For example with the heart rate monitor, there's an optional thing where you can say, ‘I'm attached to the wrist’ or ‘I'm attached to the ankle’ or ‘I'm attached to the chest’ or ‘I'm attached to the ear’ or whatever; and there are optional protocols that say, ‘hey, this is my current battery life’ and that kind of stuff. A lot of the manufacturers don’t implement the optional parts of the protocol, but if you just want a raw, ‘here’s a heartbeats per minute’ number off of this device, there are basically two ways to do it. You can get the 8-bit number and you can get the 16-bit number, and you can look at this particular bit in the header and it'll tell you which one of those you're going to pull. That is a fairly simple kind of thing, and then it can get more complicated after there from a manufacturer’s standpoint, but if all you want is the simple thing – I haven't run into one yet that didn’t behave for me. PETE: Gotcha. I guess the only thing I can see happening is you write your app using like a swanky, fancy-pants heart rate monitor that implements all the optional stuff, and then you never tested it on the cheap-o heart rate monitor that doesn’t implement the thing that you're expecting and then you have some stupid bug where you're looking for a value that doesn’t exist or something. CARL: Yeah, or you end up with a giant piece of the UI that’s got a big zero there for battery life or something. PETE: Yeah. CARL: Because the device doesn’t support it and you didn’t think to conditionally check to see if you need to put that piece of UI there or not. PETE: Right. And all the app reviews just say, ‘Sucks. Zero for battery life. Zero stars for you.” CARL: Right. CHUCK: So you were talking a little bit about like the HealthKit and stuff. Is that actually a new library in iOS? I haven't had a lot of time to spend paying attention to WWDC yet. CARL: HealthKit is a new framework in iOS 8 and it lets you take a number of – or will, in September, or whenever they release it – it lets you take a number of different standard Bluetooth protocols, or GATTs, that correspond to health data like heart rate monitor, blood pressure, blood glucose for diabetic meters that have Bluetooth LE in them, and then it lets you take that and put it into this HealthKit in a standard way. The other thing that’s kinda cool is from there, another app can – assuming that you give it permission – get access to that data. For example, if you had a diet app that was basically tracking – you were typing in the food that you eat, well that diet app could now also get information to the number of calories that you burn with your Fitbit, and so you wouldn’t have to input that information twice, so it’s kind of a hub for the way that all of the different apps that you might have on your phone that deal with health data can talk to each other and share things in a well-defined protocol. CHUCK: That’s really, really interesting. I'm diabetic, so I'm really curious about where this can go and how it can help me with my particular issue. CARL: Well they had folks – they were talking to people there from the Mayo Clinic, they had some other records-based things and doctor stuff and they're talking about potentially having the whole thing set up so that your glucose monitor or your insulin pump can talk to your phone, your phone can talk to the internet, or your insulin pump can talk to [inaudible] talks to HealthKit, which can then talk to an app that also talks to HealthKit that can dump that directly to your doctor’s office, and they can monitor things and all that kind of stuff. There are privacy implications of that and Apple seems to be reading very carefully about that. It’s an interesting world especially for those of us – I'm not diabetic, but I'm asthmatic and there isn’t really a corresponding Bluetooth LE thing for that, but I can imagine [inaudible] Respirometer or something that would be the same kind of thing, which would be cool. BEN: Yeah, my take on it was that there were two uses for it. One, you can have devices that stuff data into it, but you can also have specialized apps that take the data and render it in new and useful ways, and one of those might be to communicate with your doctor’s office, another might just be to help you discover patterns that help you live your life better or whatever. CARL: Right. BEN: Sleep was one of the ones that I found to be interesting, because each data point in HealthKit is not just one number, right? It’s like a timestamp plus one value or set of values, so for the sleep one it’s what time did I go to bed, what time did I actually fall asleep, what time did I wake up and what time did I actually get up, and so it’s a quadruplet of data that you can graph. Once you have the data in there, any number of apps can use that data in interesting ways. CARL: And then there's a meta data dictionary you can stick on that too, that if apps agree on what they're going to put in that meta data, there's a whole other sharing service that can happen from there. BEN: Interesting. I was browsing around in the iOS 8 simulator you can play around with HealthKit or Health.app, and there's a setting in there – I probably shouldn’t giggle because it’s not funny – but there was one I saw that was ‘number of times fallen’ so you can imagine just a little counter –. It would be very sort of inconvenient to go through Health.app to enter in data – it seems like that’s just sort of a way to let you see it and enter it in initially until apps will start creating specialized interfaces, or better yet, having meters that would interact with the real world. CARL: Right. It very much seems to be a – we know that there are all these devices that exist, and so we’re basically trying to make a way for all of them to talk together and for the user to not have to have an app for every one of them. And then once you go past that, the next thing that they announce, which is kind of a similar thing is HomeKit, where you can write apps that can talk to your thermostat, your garage door, your lights in your house, your curtains – if you got that kind of thing – all in a very prescribed kind of way. You can make zones and all that kind of stuff. That’s a whole another set of apps that you can write that can talk to peripherals that can really interact with the real world; although in that particular program, I think we’re going to have to wait. I don’t know how many exists right now, but we’re going to have to wait for the HomeKit enabled light bulbs and all that kind of stuff to start showing up on the market. BEN: Yeah, I'm sure there’ll be some sort of adapters of certain companies like SmartThings will be all over it, because they have sort of a competing ecosystem of products and that would probably only serve to help them to have some type of integration with HomeKit, because it’s certainly piquing interest around here among non-techy friends. PETE: [inaudible] interesting, this kind of competing efforts to own the [inaudible]. If I'm going to play buzzword bingo, the internet of things, like the gap in-between the internet of things, I wanna be the person that enables your fridge to talk to your grocery store or whatever. Did they make with the HomeKit announcements – was it just about iOS or did they also talk about plugging into Apple TV or OSX? BEN: I don’t think they made any specific announcements about that, but we were discussing it internally because we have a product that will fit into this quite well. It’s called the Refrigerator to the Grocery Store –. [Chuckling] Just kidding. Anyway, we’re just wondering of all of the sensors and triggers and actions that you could take from HomeKit devices, do you have to be home to do them? PETE: Right. BEN: Because presumably you wouldn’t have to be in the same Wi-Fi network for you to interact with them, but if they're connected to iCloud in some way – like for instance in Apple TV that pretty much everybody who’s interested in this stuff could afford, if not already own multiple versions of it – it seems like Apple TV is sort of a unique place to provide that hub, whereas SmartThings or Philips Hue, they all have hubs that allow it to talk to the network. All of these devices talk to the network, so if there's something like that, then there's gotta be some sort of persistent device in the home and Apple TV seems like the perfect things to do it. Or an AirPort Extreme, which a lot of people have as well. PETE: Yeah, a lot of the things that I see around this, quite a few of them talk about the home entertainment center or something like that being the obvious place to stick the integration where the light bulb can talk to the – I don’t know – not the thermostat maybe, but your light switches talking to the light bulb makes sense that you would just wire them directly as it were, and they're probably manufactured by the same people. But if you want the lights to brighten – I don’t know – when you're cat comes through the door and you want your cat flap is using a different manufacturer, then you need a single place where all this stuff comes together and then goes out, and it seems like an entertainment center or something like that is an obvious place. That’s a startup idea that someone is very welcome to take, by the way, the internet-enabled cat. CHUCK: [Laughs] I think it’s interesting though that you were talking about it. I mean, a lot of the home automation stuff, you just – it’s a peripheral that you just control through your Wi-Fi, but the idea of controlling it through the internet through a device that talks to everything else, I think that’s really, really interesting. Effectively, then, your peripheral connector is the internet. ANDREW: Yeah, and I wanted to ask about that. That gets into actually a different paradigm than we’ve talked about, which is you don’t actually communicate locally; you're communicating over the internet with a connected device, and I think that’s getting pretty important. Do you know anything about that? CARL: I haven't dug into that particular thing. As I remember in the presentation, they were talking about – if nothing else – as you drive up to the house, your garage door opener would open your garage door by itself and it would turn the house on and all that kind of stuff. I remember something about thermostat changing based on where you physically are, like a geo-location kind of stuff, so that might be actually when you leave the house, or it might be knowing, “Oh okay, he’s staying at the office late” kind of thing. I'm not exactly sure how that works; I haven't dug into that much, how that works when you're not physically in the house. ANDREW: I have a Nest. I think the way it’s advertised, people think it probably does this, but it actually does not use your phone remotely to figure out if you're home. It just has internal sensors that detect you walking around in front of it, and if you don’t walk around in front of it for so long, then it assumes you must have left the house. But I think I saw just yesterday –. PETE: That wouldn’t work for cats, because they lie still for long periods of time. ANDREW: Yeah, right, well they mentioned somewhere in the manual that if you have cats [crosstalk]. I saw that Honeywell announced a new thermostat that’s sort of a competitor to the Nest maybe just yesterday that does use an iOS or Android app, and I think they're using geo-fencing APIs to actually detect you're coming home and you're 10 minutes away so they’ll turn the heat on for you so that the house is warm by the time you get there – that kind of thing. I think there's a lot of possibility around that, but we’re just starting to see it happen. CARL: And if it’s not set up to happen now, then it will by the time we get to iOS 9 or iOS 10 or something. It’s pretty much inevitable at this point, I think. PETE: Now I'm distracted looking at the Honeywell thermostat; it just sounds like such a [inaudible] product, I kinda imagined it like a regular, cheesy, plastic thermostat with like a round – or something, I don’t know. CARL: Another set of products is home security cameras. There are apps – these are outside of HomeKit and I don’t know exactly how they would work with HomeKit but they're basically apps you can get where you set up your webcams in your house and then you have your app and it talks to I guess a web server either in your house or somewhere else, and you can see the streams from the cameras in your house on your phone. Actually some of the security companies in town – I think the cable company, Time Warner, here where I live I Austin, has that kind of service where you can basically get an app on your phone that can see the various cameras that you got in your house, so it’s converging fairly quickly. ANDREW: Yeah, so the Drop Cam, I think, is the biggest of those. There are a bunch of companies making those kind of cameras that – they seem really cool. CHUCK: So are there any other gizmos? I wanna go back a little bit to the Spheros and the quadcopters and stuff like that, which are kind of interesting peripherals. Are there any tricks to those? Do they just come with an app that works and can you write your own apps? I know you can for the Sphero to some degree, but –. CARL: A lot of them have basically developed a program. Like the dice I was talking about – the physical dice – they have a developer program you sign up. It’s single-digit hundred dollars kind of thing, maybe less now, and then you basically get the SDK from them; you use that to talk to their device. I assume that encapsulates whatever protocol they use to go from the dice to the phone, and then you write your app using their libraries inside your app, and then you publish it, and you'd have a ‘use this with your Dice’ kind of thing. You send them a link to your app; they feature it on their site, and so it’s also a nice kind of marketing thing for you, for people that already have those things that are looking for an app for it. That seems to be kind of – I don’t know that everybody’s doing it that way, but when you’ve got products like that, some of them actually – like the AR Parrot Drone, the Wi-Fi quadcopter – they open source their library that lets you talk to their quadcopter, but a lot of them have a developer program that you sign up for and you get the SDK that way, and you can use that to write, I presume, whatever apps you want. CHUCK: Yeah. The other question that I have is, I've heard about apps where, like a Scrabble game, for example. You have an iPad, then you have a bunch of iPhones or iPod touches or whatever around them, and so you can see your tiles on your phone, and then you can see the board on the iPad. I'm a little curious – do you know much about an iPhone as a peripheral? CARL: There are a couple of ways you can do that. There's this multi-peer connectivity thing, and there's a multi-peer chat sample app that you can get from Apple that will let you play with that. You can basically create a mesh network – not necessarily mesh, but a topology where you hook apps together and then you can transfer data back and forth that you could build a board that way. It’s actually a cool technology because you could actually get to the point where you got a group of people that are playing, and each one is in the range of at least one other person, but the two people on the ends can’t actually see each other, but the packets get relayed all the way through all the other phones. You could do it that way. You could do some kind of a Wi-Fi client-server thing if everybody was on the same Wi-Fi network using Bonjour and the standard Apple networking protocols. I'm sure you can come up with some other things. Kind of random, my daughter actually has a little Furby – one of the newer ones – and it, I have discovered, actually uses a really high-pitched sound you can barely hear to talk to the iPad app that talks to it. CHUCK: How weird. CARL: The app actually listens on the microphone, and the Furby actually uses a really, really high-pitched thing to talk to it so that it can tell that it’s hungry, or that it’s being petted or whatever, which is kind of interesting. So there are all kinds of different little tricks that people come up with for –. BEN: I've seen that as well where it’s like outside the range of human hearing, so none of us care. Maybe dogs get annoyed by it, but –. CHUCK: I was going to say, “Do you have a dog?” CARL: Nah, I've got two cats and they don’t seem to mind, but I don’t know about a dog. BEN: It’s pretty accurate too; I was pretty surprised. I saw a demo of an app at Cocoa Conf and it basically would – it was something around music and I can't remember what it was. Basically they would communicate with people around you with similar interests, and so it was transmitting your interests and music to other people who have the app. They were sort of in prototype mode, but the biggest drawback is that you had to leave the app running, and you have that little red recording thing pulsating all the time, which consumed like a huge nonstarter. But it was definitely an interesting proof of concept; I was surprised that it worked. CHUCK: Interesting. Alright, well I know we have a hard stop here in about 10 minutes for one of our panelists, so let’s go ahead and do the picks. Jaim, do you wanna start us with picks? JAIM: Sure. I've got this trouble, this problem every day. I don’t know if I want Tikka Masala or if I want a sandwich. Pete, I know you have this problem every day, too. PETE: I do. JAIM: He’s emailing me, he’s like, “Jaim, what should I do?” I'm like, “Pete, just make a choice.” But you don’t have to choose anymore, because you don’t have to choose between Tikka Masala and a sandwich – you can have a Naanwich, which is Tikka Masala or whatever [inaudible] Naan, it’s frozen at the frozen section. It’s actually really good, so I'm a big fan. So I'm going to make my pick as Naanwich. CHUCK: Ooh. [Crosstalk] PETE: Looks good. BEN: It does sound good. It’s lunchtime too. CHUCK: I know, terrible. Alright, Andrew, what are your picks? ANDREW: I've got a few picks today. The first one is along the lines of what we’ve talked about. There's a company called Redpark that makes Lighting 2 Serial Cables, and you can use these without being in the Made For iPhone program; they’ve got the certification for this device. You cannot use it in an app that you put on the App Store, but this can still be really useful because using RS2-32 or serial is really still the easiest way, especially on the hardware side, to just get up and running, to talk. The serial’s super simple, a lot easier than trying to set up your own Bluetooth stack or whatever, so even just during prototyping phase, this can be really useful. They’ve got several different versions for both Lighting and 30-pin connector, and they have an SDK that you use to make communicating with them quite easily. Second pick is along those lines; I actually have an objective-C library that’s open source called ORSSerialPort. This is for the Mac, not iOS, but again when you're doing hardware development prototyping it’s nice sometimes to be able to write an app, just a quick app that will talk over the serial to your hardware. This is basically an objective-C wrapper for all the low-level C posits and IO Kit functions for doing serial communications, so it makes all that a lot easier. Lastly is a little product called the Electric Imp. It looks like an SD card, but it’s not actually an SD card; it just has the same form factor, and it’s got built-in Wi-Fi, and then they’ve done all the backend for you, so you basically can make a device that takes one of these imps that plugs in. It’s got a micro controller in it, and Wi-Fi, and it’s even got – they’ve already done all of the setup stuff, so if you wanna make it so your iOS app can set the whole thing up and connect it to Wi-Fi, that’s all super easy. They have the whole backend running on the web, so when you connect the thing to the internet, you just get a rest endpoint that represents that device, and it’s super, super easy to communicate with over the internet. These things are pretty cool and you can buy a developer kit for them quite cheaply. I can’t really remember how much they are now, but less than 50 bucks. That’s the Electric Imp, and those are my picks. CHUCK: Awesome. Ben, what are your picks? BEN: Let’s see. I was in San Francisco recently, so I went to mostly the usual spots, and I also found Pete’s previous pick – 21st Amendment Brew Free or Die – which was delicious. What else did I do? I went to a place called Mikkeller Bar, and they had quite an impressive beer selection. I like Imperial Stouts, and I had probably eight or nine of them. [inaudible] was upward of 20% alcohol that morning. Yeah, and that was already a rough morning for me, so I skipped that one and went for a more middle-of-the-road beer, but it was good. Definitely a good place to check out – Mikkeller Bar. I've been playing a new game from Mika Mobile called Battleheart Legacy. If you like Diablo-style RPGs, action RPGs, you're going to love this game. It’s five bucks; it’s a universal app, and I probably have 10 hours playtime already in this game, so it’s totally worth the $5. That’s a really, really good game, so I will post the link to those in the show notes. And I got to hang out with Jaim, so I’ll pick Jaim. JAIM: Thank you. Aww, so nice. Yeah, where’s Pete? Pete was just kinda tweeting at us, always saying, “You should hang out in the [inaudible], corporate sellouts.” [Chuckling] I didn’t see Pete; I got to meet Ben though, so that was a good time. PETE: Yeah, I was bummed I didn’t get to meet you guys. I was in 500 hours of meetings and then I was in Atlanta for a company thing. So yeah, next year. CHUCK: Nice. What are your picks, Pete? PETE: This is an oldie and one that we’ve already picked, a bunch of people have picked before, but I'm going to pick it now – Reactive Cocoa. I've been playing with this; had a long flight to Atlanta and back from Atlanta, so I was messing around with Reactive Cocoa. It’s really cool; I really like the paradigm, the functional reactive paradigm, even though apparently the guy that invented the term thinks that things like Reactive Cocoa aren’t actually functionally reactive, but whatever. So yeah, if you haven't played with it, yet another [inaudible] to play with it. My second pick is really silly – it’s called count.io. It’s a cloud-based counting service. It’s kind of – that’s it, that’s what it does. I can’t decide whether it’s useful or just totally ridiculous; it’s probably webscale, and it might be useful if you’ve got a connected device and you wanna count something. I don’t know; you don’t have to build a backend, it’s counting as a service. My last pick is – yeah, really. BEN: It sounds like the definition of a micro service. [Laughter] Maybe we need another one that does adding two numbers together as a service. PETE: Yeah, like floating point math or something, I don’t know. My last pick is a beer. It’s Stone Go To IPA. Stone do lots of big, heavy beers, lots of big IPAs. This is a session IPA that still tastes like an IPA, so it’s probably – I don’t know – 4% or 5% alcohol. 4.5% alcohol, but 65 IBUs, guys. 65 – that’s pretty high considering the alcohol. It’s a good session beer; it tastes a lot like hops, but you can have more than a couple. More than that 20% style, anyway. And that’s my picks. CHUCK: Very cool. I've got a couple of books that I've read lately; one of them is called The Miracle Morning by Hal Elrod. I heard about it on EntrepreneurOnFire; he actually interviewed Hal. The idea is that you get up early – everybody groan – and you go through a couple of different things to start off your day. I did it on Monday and then I wound up losing most of the day to a tension headache and I just wasn’t feeling well at all last night, and then earlier this morning. I didn’t do it this morning, but I'm going to get back on it tomorrow, but it really did feel good until my headache came on. Just being up and going through that stuff and really starting the day of right. I'm going to really highly recommend it; I really like it so far, and I’ll probably report in after a few weeks and let folks know how it’s still going. The other one is the Steve Jobs biography. I forget who the author is, but anyway –. BEN: Walter Isaacson. ANDREW: Walter Isaacson. CHUCK: Yup, that’s the one! Anyway, I'm enjoying that as well. It’s just interesting to see how all this stuff came about, and just kind of the personality and the story behind Steve Jobs and Apple. Anyway, those are my picks. Carl, what are your picks? CARL: There's a TI – they call it a sensor tag. It’s a little, $25, Bluetooth LE sensor that comes with the code that you can use to run it on iOS that has an accelerometer and a temperature sensor and a bunch of stuff in it, and it’s a really handy, little thing if you wanna play with Bluetooth and sensors and peripherals and that kind of stuff. It’s almost indestructible – you can throw it and bounce it off a wall. And then I have a couple of books – Halting State by Charles Stross, which is a near-future, science fiction thing in which everybody walks around with glasses that talk to their phones all the time, which is kind of an interesting thing of where the peripheral stuff might be going in the future. And then a book called All You Need Is Kill by Hiroshi Sakurazaka, assuming I got that anywhere close to right, which is the novel that the new Tom Cruise Edge of Tomorrow movie is based on. I have read the novel and have seen the movie and I actually like the novel better, so I'm going to recommend it. And one piece of software that, surprisingly, I haven't seen in your picks yet but I use all the time is called Caffeine. [Inaudible] thing that sits in the menu bar in your Mac that prevents your Mac from going to sleep. BEN: Yes. CARL: I use it a lot for things like conference calls, when I'm presenting at a conference, that kind of stuff. It probably gets used for me every other day, if nothing else. I’ll [inaudible] all those in the show notes. BEN: I use that all the time. It’s got permanent space in my menu bar for that reason. PETE: Yeah, me too. BEN: Another thing that – I think Mac OSX’s pretty good about not putting your machine to sleep when it’s actually doing something, but when I do pile up loads in the terminal, it doesn’t seem to have that same protection, so the machine will just go to sleep while that’s happening. Maybe it’s just the screen, maybe I'm just being paranoid, but I always keep the screen on to make sure I don’t interrupt a large – perhaps a screencast upload that I happen to do every week. Anyway. PETE: Fun fact: there is actually a caffeine command line app that [inaudible]. BEN: Indeed, yeah. I guess not by the same people, right? It’s an Apple, open source utility, right? PETE: Yup. But you can write a little script that will wrap your activity in that caffeine thing and it will keep the computer open as long as that process [crosstalk] BEN: I knew about this; I just never plugged the two ideas together. PETE: All to make your life, Ben, all to make your life. BEN: That’s what you're here for. [Chuckling] CHUCK: Alright, well, let’s go ahead and wrap up the show. Thanks for coming, Carl. Really appreciate you taking the time. CARL: Thanks for having me, I appreciate it. [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.] [Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more]

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.