Adventures in automating unchangeable apartment lights
For the last year or so, all of my lamps have used Hue bulbs, which means I can use my phone (via HomeKit) or Alexa to turn them on or off, change their brightness, and so forth. However, my apartment has some overhead lights in the kitchen area that are not easily replaceable with anything standard. Though I did try:
Living in an apartment, I also can’t replace my light switches with any of those fancy electronic IoT-ish switches, so I just let the problem be.
I finally tired of having three lights that didn’t respond, so I set out to solve the problem My requirements were the ability to control my lights via both Alexa and HomeKit, like the rest of my lights.
As far as I can tell, there is exactly one product on the market that is compatible with the my lights: Switchmate. It completely avoids the problem of replacing lights, switches, or indeed anything at all by just physically actuating the existing light switch. It is, by far, the easiest thing to install:
Unfortunately, beyond being compatible with my lights, it solves none of my problems. It isn’t compatible with Alexa, and it isn’t compatible with HomeKit. It promises voice control, but what that really means is that you can tap a microphone button in the app and then speak to your phone. This isn’t really very useful. In fact, as advertised, this product is pretty useless — though it’d be pretty neat if it was the only approximation home automation I had. What it does offer by virtue of having a mobile app, though, was opportunity. They communicate with their mobile apps via Bluetooth LE, and we can emulate that and thereby control them. Conveniently, people have already done this.
So I ordered the parts I would need and set out to make it work:
Three Switchmate BLE switches (two of them the slim/”bright” versions, because the older ones won’t fit side by side on two-gang switches)
One Raspberry Pi 3 model B+ — though I’m pretty sure the Pi Zero W would’ve worked as well, it didn’t have same-day shipping, and I am impatient.
A micro-SD card to put in the Pi
And… that was it. Total cost around $140, but it could’ve been closer to $100 if I were more patient.
Once I received them, I upgraded their firmware to the latest version using the mobile app, snapped them over the relevant switches, and got to making the promised integration happen.
On the software side, I installed the latest Raspbian on the Raspberry Pi, then grabbed a handy Python switchmate tool someone had written (which as far as I can tell is the only up-to-date implementation) to see if it would talk to my switches — and it did! I could experience the joy of turning my kitchen lights on and off from the command line.
Excellent! So now I’m exactly where I was with the phone app, except everything is slightly more inconvenient. But I have my proof of concept, and I can get to work on integration.
For this, I turned to a wonderful project called Homebridge, which lets you add arbitrary devices to Apple’s HomeKit and basically do whatever you like in response to whatever devices you choose to present. There are actually multiple homebridge-switchmate type plugins… but they’re all outdated and won’t necessarily do anything on recent hardware. I instead used homebridge-cmdswitch2 to expose command invocations as HomeKit switches. I simply had it invoke the previous python switchmate tool with the appropriate arguments whenever I needed to throw the switch. This was fine, except that I it needed root permissions. Being lazy, and in flagrant violation of anything ever resembling good practice, I just ran homebridge as root, and everything was good.
This worked! Sometimes. Except when it didn’t. And then it would just stop working entirely no matter how much you tried. In the end, I ended up writing a (terrible, terrible) script that retried several times, and reset the bluetooth stack before each attempt. Apparently the Pi’s integrated BLE does not play nice. For those interested, the script I wrote is over here.
With these retries, the HomeKit integration became reliable, and so I could proceed to the final task: Alexa integration. Conveniently, this has also already been solved by a plugin called homebridge-alexa, which publishes your Homebridge devices for Alexa’s consumption. After setting that up, it worked!
The initial fade-in is the Hue lamps turning up, followed by the three binary switches being thrown. It’s certainly slower, but it beats them being uncontrollable. And you get very satisfying whirring and clicking noises!
Many of you have been patiently waiting since we announced our upcoming demo shortly after BronyCon 2016. Well, we’re pleased to tell you that it’s finally here! You can download the Stalliongrad (Solar Empire) at the link below!
There are a few known bugs still in there, but this is the last demo we are releasing on the old engine and figuring out those bugs for an outdated version of the game would be redundant. This demo should be playable on both PC and Mac, and another one may be on it’s way later this year!
We also want to thank anyone who went to our Nightmare Nights Dallas panel. There were a number of confusions and complications, including no announcement on here, but everyone who went was awesome to talk to! Also, if you are attending Ponyville Ciderfest, there will be another panel there on Saturday at noon. Stop on by for info about the game, as well as a Q&A!
Inspired by a conversation on the /r/mylittlepony Discord, I realised that everyone needs a half-decent pony plushie. And they aren’t very expensive!
So, if you:
Currently own no pony plushies at all, and can’t afford to buy one.
Are located in the US (for shipping reasons)
Are one of the first five people to ask
Send me (privately) your shipping address
Then I will send you a 4DE plush of your choice from the following set:
Twilight Sparkle
Rainbow Dash
Applejack
Fluttershy
Rarity
(Pinkie Pie is not available. Twilight Sparkle may or may not have wings and they may be open or closed. If you have a preference, you can specify, but I make no promises.)
Here’s a handy picture of what they all look like:
Finally, while I will try to ship out a plush to the five claimants, this could fall through for any reason.
To request a plush, email me at [email protected] with the subject “Pony Plush” and assert that you don’t have a plush and can’t afford one.
Apple released a new operating system! Hooray! I decided it might be worth upgrading to it. So let’s run the installer and see what happens…
Oops! It kernel panicked in CoreStorage as soon as it rebooted to begin the install. And then again when I rebooted it. And again in safe mode. Okay, I guess we’re going to have to boot internet recovery to poke at this thing with Disk Utility…
Disk Utility can’t repair this disk. Back up as many of your files as possible, reformat the disk, and restore your backed-up files.
Oh dear. Good thing I have current backups! Disk Utility is, of course, also incapable of actually reformatting the disk too, because it’s a CoreStorage logical volume across two physical drives (i.e. a “Fusion Drive”), which the UI is apparently incapable of handling. Or was in OS X 10.9, the version of recovery that this computer apparently boots into. So I destroy and recreate the logical volume group manually using diskutil cs, and Disk Utility is now happy with it, so let’s restore that backup!
An error occurred while adding a recovery system to the destination disk.
No? Well I guess we’re not restoring that backup. I did reboot the computer, and this happened:
I have no idea what is going on here. I gave it a password that seemed plausible and it did start to boot, but it never finished booting and I’m not entirely sure what it was booting from. My best guess is the backup disk itself.
Okay, so, this time I just run a fresh install of OS X 10.9 Mavericks, and that works!
Now that I have a clean install, restoring a backup does work…
…and it’s only going to take about six hours.
Skipping forward to the following day, it’s done! Hooray! And it seems to have everything on it. So we’re finished, hooray! The originally planned upgrade is nowhere to be seen, but I’ll be happy to have a working computer at all at this point.
Except… the computer wouldn’t. even try to boot off of it. The disk was good, the contents were intact, it was suitably blessed, and the computer absolutely would not concede it even existed.Â
Okay. Fine. I use my laptop to make a bootable USB drive containing Sierra, intending to use it to do a clean install. I plug it into my desktop, boot it, and…
It gets halfway through the progress bar and stops. At this point I’m beginning to feel rather like this xkcd, with the original computer and multiple now-misbehaving computers hooked together.
Some more testing indicated that the USB drive was dud, because of course it was. After going shopping for a new one, I created an install image and it actually worked:
Those are some hilariously optimistic minutes, by the way; each of them took five to ten minutes to pass. It never backtracked and increased its estimate, though.
Finally, once it boots successfully, I ask it to “transfer my information” from my backup:
Another six hours pass.
The following day, again: it’s done! it works! my computer finally actually boots.
Finally. So that only took several days. Thanks, Apple!
I don’t have very many interests, but the set I do have are pretty eclectic. So taking a detour from the topic of recent posts on this blog, let’s talk about Second Life for the first time in years! Here is a (silent, 47-second) teaser of what never shipped:
What happened? Well, ultimately, nothing. But there is a longer story…
Way back in 2012, I still had (some) involvement in Second Life, the virtual world nobody has ever managed to describe. Second Life provides some pretty powerful scripting abilities, which let you create more or less anything. What it does not provide, however, is any way to build a sane UI. This leads to stuff like this:
This is produced by the llDialog call; that and llTextBox (which shoves a text box in your face) are the only built-in options for a UI. A popular workaround is to create complex prim-based UIs that actually exist in 3D space (and are then attached to the camera and so appear 2D), by manipulating objects and textures. This has its own limitations — they are complicated to build, expensive to render, and the results are often vastly inferior to the native UI.
Since I worked on the (now-defunct) Exodus Viewer project, I thought I could do better — so I did!
As a proof of concept, I built a bunch of LSL functions in the vein of llDialog:
UICreateFloater
UICreateButton
UICreateText
UICreateInput
UICreatePanel
UICreateSlider
UICreateSwatch
UISetText
With these, you could create something much nicer:
The code to generate that can be found over here. It’s rather more complex than a single llDialog call, but it is also way simpler than constructing a prim UI and tends to give better results. Those familiar with Second Life Viewer development may notice that it bears some similarity to XUI — this was basically a layer on top of that. Those not familiar with LSL development may think that this is a particularly disgusting bit of API design. That would be a correct opinion, but LSL is a language in which the only structured data type is an immutable list of any type except lists (so it has both no data useful structures and no usefully structured data). This is a pretty damning language constraint.
I proposed this to some LSL and viewer developers, and people were generally in favour. Unfortunately, there was a catch: section 2 k) of the Policy on Third Party Viewers:
k. You must not provide any feature that alters the shared experience of the virtual world in any way not provided by or accessible to users of the latest released Linden Lab viewer.
There are a whole bunch of features that violate this but get away with it for Historical Reasons™, but I didn’t have those on my side and so I trundled off to Linden Lab to see what I could do about this. After meeting Oz in person a couple of times to discuss it — a benefit of living in the Boston area —we formulated a proposal for Linden Lab’s review board. The concept was simplified to passing a definition of your UI into a single function, llFormDialog, which you could call again to update your UI. This design was a motivator to actually have JSON support in LSL, which did happen and I choose to believe was somehow related.
The concept was suitably attacked by the review board (I still have their comments!), and then… that was about it. The idea ended up forgotten, 2 k) prevented it being implemented by anyone other than Linden Lab, and people continue to build dialog and prim UI to this day. A disappointing end to the tale, but what can you do?
For those who are interested, my code survives:
The complete LSL script shown in the above demo video, complete with definitions of the helpers, response handling, and fallback for incompatible viewers.
The diff against Exodus that implemented this feature, for those who appreciate C++. While the demo is actually running in a modified official viewer, I couldn’t find that code.
After this project fizzled out, and section 2 k)’s general restrictions on innovation, I lost my interest in SL viewer development. Although not related to this project, similar restrictions burned out the rest of the Exodus viewer team, and that project is now effectively defunct. I still get occasional emails lambasting me for my supposedly-deliberate murder of that project, to remind me of my failings, though.
This post inspired by finding the official LL proposal sitting around in my documents.
We had so much fun livestreaming the game earlier this week, we’re doing another one! Better yet, we’re actually scheduling this one, and it won’t be at ridiculous hours of the evening!
Catch us at picarto.tv/GremlinGrenade or picarto.tv/SilfoeArts at 12pm CST (or 10am PST, or 1pm EST… etc). The stream will be going for an undetermined amount of time (basically until all of us have about had it and can’t so much as stay awake anymore).
As previously mentioned, and as was also blindingly obvious on Twitter, I spent the weekend over in Baltimore at BronyCon! And now that it’s over, I shall ramble a bit. Quite a lot, in fact, so I’m gonna bury this wall of text, pictures and videos below the fold.
This is actually the second time I have attended BronyCon — I went on a last-minute whim last year. After lurking in the pony fandom for years, that was my first con, and it was one of the best experiences of my life. Since then I’ve also floated around at the substantially-more-conveniently-located BABSCon and Everfree Northwest. Behold my wimpy but growing badge collection:
This time around, I was on two panels: Shattered Kingdom, the pony game I work on; and the Pony Programming Panel, which isn’t actually called that but I like the alliteration. Let’s go through this whole affair day-by-day:
Wednesday (day -1)
I had a whole bunch of actual work to do:
I did pack, but that talk was only half done, and I didn’t get a chance to actually practice my own demo. I also did not sleep at any point.
Thursday (day 0)
Time to leave for my 6am flight! Whoopee! I eventually fell asleep for about an hour and a half on the first leg, to Atlanta. This was the only sleep I had that night. Between the flight, layovers, and the three-hour timezone change we eventually checked into the hotel and picked up my badge at 7pm. I spent some time practicing my demo and figured out how to actually play, so I could avoid a repeat of the EFNW panel where I got the main character killed. Twice. After that I just headed to bed to get my last vaguely decent night’s sleep of the weekend.
My programming talk remained unfinished.
Friday (day 1)
The con begins! Woo! Ate breakfast and turned up for the 10am Opening Ceremonies, which were opened by some song and dance, followed by some more song and dance, followed by introductions and administrivia.
After that I floated around the vendor hall, where I ran into Gremlin Grenade (almost literally; he came out of nowhere with a hug), said hi to @silfoearts, and perused the aisles. Then there was lightning music, courtesy ElectricalEnginerd!
In the evening I spent some time at BronyPalooza, where I saw the Wasteland Wailers (who conveniently had lyrics on-screen) and Tarby, until I had to leave to save my ears and ran into @seventhelement, thereby completing the set of @alicorngames team members.
I also went to Match Game BronyCon, where contestants and show staff try to produce the same word to fill in the blank compete to see how closely they can skirt the line of “family-friendly”. Or, at least, they did right up until Ashleigh Ball came up with “dildo”. Oops.
I returned to BronyPalooza around midnight to see Odyssey Eurobeat’s set and ran into Dexanth (who I had previously met at EFNW), who had similar plans and so we danced together. Once Odyssey was done we left to save our ears and chatted until 2:15, then headed back to sleep.
Through the day I did not touch that pony programming talk.
Saturday (day 2)
Somehow got out of bed, had breakfast, and met up with the rest of the Pony Programming Panel: Victor, Cloud Hop, Chalcedon, SavanaPope and Alex. After discussing the panel, we dispersed and I wandered the vendor hall. I talked a bit with Mrs. Paper Pony, but didn’t buy anything because my walls are suitably full already. I picked up an adorable Sunset Shimmer plush from Plushy Puppy Studio, too:
(All their stuff was ridiculously adorable, but I’ve wanted a Sunset plush for ages…)
Saturday also featured the Elements of Harmony panel, where the voice actors for the entire Mane 6, among others, came together. Here, have a picture!
Okay, okay, that’s the only picture I took. This whole thing was hilarious: they acted out an MLP fan fiction written by one of the actors, Tabitha St. Germain, in character. It involved cupcakes, stone frog-ponies, Luna’s chipped tooth, a dentist, and dreams. It was reminiscent of a similar event at Everfree Northwest of several members of the MLP cast performing The Princess Bride in a collection of randomly assorted voices ranging from Fluttershy to Donald Trump.
I then collected my massive Twilight Sparkle plush from EquinePalette:
Here pictured in front of me getting a drink, the BronyCon mascots and Fluffle Puff stacked on top. It was popular; a number of people asked to take photos of it just sitting there. I dragged it up to Hooves Line is it Anyway?, where ACRacebest and friends performed improv comedy.
After lodging it safely in a hotel room, I got together with the rest of the Alicorn Games team and we grabbed dinner at Five Guys and talked Shattered Kingdom ahead of our panel. After dinner I headed back to put together a slide for voting on our name competition and to make sure I could still play the game, then headed down to the Hall of the Stars with Twilight in tow to host the panel. Book horse is, after all, best panelist:
The panel was a success: I didn’t die, the game didn’t crash, we had decent attendance (especially given the time), people asked good questions, and we filled the whole time slot and kept answering questions outside.
This is also where I second met Mynder (the first was at DarkFlame’s booth), who was particularly enamoured with Twilight and is seen in most pictures of her:
(Hi Mynder!)
Then we all headed back to Grem and Silfoe’s room and hung out with many people, including AssasinMonkey, @darkflame7, Keni (she quite liked the Sunset plush), and many more — alas, I fear if I tried to list them exhaustively I’d only make a fool of myself. Shenanigans ensued:
That’s Sunset-on-Twilight-on-Silfoe-on-Twilight, Hoof Beatz-on-Mane Event-on-Twilight, all balanced on Mynder who graciously prevented the whole thing from toppling over. Over on her side is Eclipse, hiding under Twilight is Fluffle Puff, and AssasinMonkey is laying off in the background.
Eventually everyone headed to an art jam or drifted off to bed, leaving me alone in a hotel room that wasn’t mine to actually get something productive done. I stuck around until after people started returning, and took my leave to sleep shortly thereafter.
I actually did some work on that talk on Saturday! But it still wasn’t done, and time was running out.
Sunday (day 3: the end)
I woke up, had breakfast, wandered the Vendor Hall, bought some scrolls from DarkFlame, and attended “[Exclamation]! Writer Mad Libs!”, where almost everything somehow came out lewd and body pillows were the noun of choice. I then headed up to my room and finally actually finished off that talk. At 14:00 I headed out to the Hall of the Stars to get set up for the Pony Programming Panel, which is of course the point that we realise we still haven’t figured out how to deal with six different lightning talks and one AV hookup. Ultimately, we had to plug in a different computer between each presentation, and we all had issues at the start of our bits, which wasn’t terribly smooth.
Still, the panel went well, we had good questions, and saw some pretty decent attendance:
It also lead to this Let’s Play, which is pretty neat. After the panel, I headed up to Mane Event’s Hall for the final scheduled event, the Closing Ceremonies. It was, as one might expect, completely insane:
And that’s before they even started. Once it was started we were treated to a goodbye from the guests, an emotional goodbye from the departing con chairs, and a reprise of the song from the opening ceremonies — which I think was far more impactful this time around. Ultimately, we were asked to swear to “pay it forward” — with our hands raised and everything.
After that I poked around the convention centre, snapped some boring photos, and headed back to my room to take care of some chores. After dinner I joined  another art jam in the Hilton lobby, where I once again met up with almost everyone I’d met at BronyCon, among many others:
(that is an awful photo, but it’s also the only one I took)
Alas, since I am in no way an artist, I have no beautiful art to show off as a result of this. However, I did eventually bring down the giant Twilight again, which was as popular as ever:
As time wore on I said and hugged my goodbyes, until I eventually retired myself at, I believe, about 5:30am. Nobody wants to sleep on Sunday, because sleeping means the con is over. :(
Monday (day 4: the return)
I slept in! But I still only got about five hours of sleep. After shipping Giant Twilight home via UPS (in two boxes taped together — she doesn’t fit in one!), I packed everything away and headed to the airport. While there I met an unnamed brony and we chatted about the con (I think it was his first!), then spotted @couchcrusader (who I’d previously met at the Shattered Kingdom panel and Sunday night art jam) and we gestured across the waiting lounge at each other.
At the end of the first leg, in Atlanta, I happened to run into Cole Daigneault, aka Hoof Beatz, who said hi. That was pretty much the end of the ponies; I didn’t encounter anyone on the rest of the trip back, and after getting home I just made my way to bed as quickly as possible.
The rest of the week
I was sick and worked from home. Con crud sucks. The end.
So, in summary: I met a bunch of people, had the time of my life, managed to get through sitting on two panels without a panic attack (given how utterly terrified I am of people, this is an accomplishment), and expanded my collection of ponies.
It was awesome! I hope to meet everyone again next year (or sooner!). Looking forward to next year!
We’ve got yet another great let’s play of the Hearth’s Warming demo by DM-PON3000! This one is just under an hour long, but it’s a great video and we really appreciate it!
This is a great let’s play of last year’s Shattered Kingdom demo from someone who learned about it from my talk as part of the Pony Programming Panel! Be sure to appreciate the voice acting of all the characters. ;)
Hey everyone! Sorry about the very slow update, we’ve all crawled into our little development holes as we got ready for our upcoming BronyCon panel! And in that regards, we have two very important announcements:
First of all, for anyone looking forward to the panel, we will be presenting on Saturday at 10:30 pm. Sorry it’s so late, but if you’re there we promise to show you a good time!
For anyone attending the con, though, we have one other very special event…
You see, this guy has been a planned character for the game for a long time, a strategist that joins the player’s army when going down the New Lunar Republic path. Why doesn’t he have a monthly character feature, any previous showings or any other mention here on the blog? Because he doesn’t have a name! Quite frankly, we’re not the best at coming up with names, and anything we could think of didn’t seem just right. So, we’re going to do something special for him: we’re going to let you guys name him. At BronyCon, we will have strips and a hat for people to submit name ideas (sending an ask with a suggestion on here will also be okay), located at Silfoe and AssasinMonkey’s booth at the vendor hall, and, before the panel, we will pick our three favorites. Then, during the panel, we will have you, the fans, vote on your favorite of those, and that will be his name! It’s the least we can do to let our fans have a hoof in shaping the game’s future, and making sure it’s the best experience possible.
For anyone at the convention, we look forward to seeing you! And to anyone who won’t be there, we’ll miss you, and look forward to a recording of the panel!
Before we get started, full disclosure: I write code at Pebble; we also make smartwatches. If you’re reading this you probably already knew that. Despite this, everything I say here is my own opinion and does not reflect that of Pebble Technology, and so on and so forth. My main watch/phone combination is Pebble on iOS, so I will compare to that.
I am using an LG G Watch, so my impressions are based on that. The Samsung watch should be similar, with the exception of its behaviour in dark rooms (to be discussed). Also, I am not a habitual Android user; that said, for the purpose of this test I am using an Android device (an HTC One m8) exclusively.
Here is a pair of watches:
I couldn’t figure out any way to get Wear to give me 24-hour time. It has been pointed out that it just mirrors the phone’s time setting, which makes sense.
So, with that out of the way:
Initial Setup
This is pretty simple, and much like Pebble’s setup. Turn on the device, pair it over Bluetooth, and pick it from a list:
It’s not a completely smooth process — for instance, I have no idea why it threw this up at me:
(What do “OK” and “Cancel” do in this context? Good question!)
The watch then installed a firmware update, much like the Pebble does on first run, and rebooted a couple of times. Nothing very exciting.
User Experience
The main screen of the device is the watchface. It shows the time, and part of a notification:
There are effectively two completely distinct parts of the Wear UI. The main view is the card/notification display, which is a vertical list of cards, each of which roughly corresponds to a notification. You can’t tell how many cards there are, or if there are more cards above or below your current one. You can, however, see if there are any from the watchface screen.
The second view is the voice input view — from here you can either speak some command, or scroll down to access the main menu. I, and everyone I tried demoing this to, had little luck getting the voice commands to behave as expected; it understood what we said… then searched Google. This is also what happened on stage at I/O, so I think they probably have some work to do here. In lieu of getting that to work, here’s a picture of some Google Search results that I didn’t want:
You can tap those to open them in a browser on your phone.
The menu system is somewhat painful to navigate: lots of swiping and scrolling, and you can only select the middle item on-screen. It also pauses music playback while showing the menu! This is not good.
At the very bottom is the app list, from which you can launch any installed apps:
Note that if you swipe back from most of these screens, you will be thrown back to the watchface screen, and therefore have to tediously repeat the navigation sequence to get out. But this isn’t always true; consistency is not a strong point for Wear.
There is also the “dimmed” low-power mode, which the watch drops back to from most states after being left for a few seconds
This mode is a serious problem for the user experience. When entering this mode, the watch:
Dims the display
Switches to black and white
Disables the “ok google” listener
Closes whatever you were looking at and returns to the watchface
That last one is incredibly frustrating; there is often no way to get back to your old state other than repeating the same tedious sequence of steps that got you to where you were before.
You can get out of this mode by performing an exaggerated wrist-raising gesture (you must exaggerate if you want it to work), or by tapping it once. It’s pretty much useless in this low-power mode, so expect to do that a lot.
More broadly, because Wear relies almost entirely on gestures and single tap targets, all navigation is pretty tedious. Instead of clicking a button to go down (as you might on the Pebble), you get to swipe the same number of times. Because multiple tap targets are a problem on the tiny screen, there is rarely more than one button, and never more than two. As such, navigating the Pebble UI is generally much quicker than navigating the Wear UI. The whole thing is exacerbated by often being unable to backtrack, and its tendency to get tired of waiting and throw you back to the beginning.
Notifications
So, first thing about notifications: they actually work, immediately, out of the box. Pebble on iOS matches this experience; Pebble on Android… doesn’t get close. You can approximate this functionality with Pebble on Android using a plethora of third-party apps (for instance, YaNC), but it’s not easy or user-friendly. They also sync properly with notifications on the phone. Score one for Google.
The basic notification scheme is pretty simple – you get a vertical list of cards, each of which represents “a notification” – approximately speaking. In the basic case, it looks like this:
There are notifications both above and below that one; unfortunately, there’s no way to tell other than trying.
Some apps produce more interesting notifications – for instance, Skype notifications come with a background picture showing the sender.
This doesn’t come from any special Skype Android Wear support; it’s simply the image it attached to the notification.
Things get interesting when apps actually do have Wear support. For instance, GMail notifications start out as a single screen, which allows “quickly” flicking through it:
But then you can tap it to view the entire email, regardless of length. Pebble cannot match this.
And then you can swipe to the right to actually do things with the email, like archive it:
Or even use speech recognition to reply (if it understands you acceptably; your mileage may vary):
Notice, by the way, that the “Archive” button used the entire screen. You have to swipe for each button. There’s a lot of swiping in Wear. You can also see how these buttons would be problematic if it thinks you tapped instead of swiped.
Another good example of neat drill-downs into notifications comes from Hangouts, which shows an individual message in its card (much like Pebble does):
But you can then swipe right to get context (and reply, and so forth):
This sort of integration is not impossible on the Pebble – but, for the most part, it doesn’t exist.
That said, not all apps get this right. For instance, all HipChat notifications are inexplicably truncated to one line. I have no idea why.
Twitter notifications are okay, as long as you only have one. Once you get a second, you just get one line per notification, which you cannot expand or interact with:
As a final UI complaint, it’s impossible to tell what an interaction is going to do. Some of them will perform an action; some will trigger dictation; some will just open a screen on the phone. For instance, Twitter (sometimes) shows as “send tweet” action. You might expect dictation, but it actually just opens a tweet prompt on your phone. You can tell after you tap it, but not before.
Overall then, the notification experience with Android Wear is, within the constraints of the device, generally superior to Pebble on Android out of the box (and on par with or slightly better than third-party apps). The interactions also help it beat out Pebble on iOS. That said, the UI is painful, there’s no indication of how many you have, and you can’t access old notifications. There is a lot of room for improvement here, but it’s certainly the best aspect of the device right now.
Music controls
I like music control, so this gets its own section.
Pebble considers music control to be a key feature that gets its own entry in the app menu. By default it’s at the top, so a double tap from the watchface will launch it. On iOS, the Pebble music app will always control whatever the active music app is and always show correct information for it. You can skip back and forth and change the volume:
You can get to this and start playback at any time. On Android the situation is somewhat less pleasant — not all apps actually report playback information, but it generally works okay — and, as with notifications, third party apps like Music Boss can help smooth the rough edges.
Under Android Wear, music control is effectively a notification (this is inherited from Android), and appears as a card in the notification stack:
From this card you can play/pause and skip back and forth (there is no volume control). You also get album art, which is a nice touch. As with much of the rest of Wear, there is a lot of swiping around; the “next” and “previous” buttons each get their own one-button screen:
Of course, you can’t tell what you’re skipping to from these screens except by album art changes (which are slow); you’d have to swipe back to see the title card. This is a pretty common Wear/Pebble distinction: Pebble gives you three buttons (plus back), and often you can use those to perform some action with one press. Wear tends to require multiple swipes/taps to do anything. It’s less efficient.
Also problematically, you cannot control the music if this card is not present — and this card isn’t shown until music is playing. The upshot is that you cannot start music playing from the watch. This makes me sad. :(
Apps
Pebble has often been criticised for the clunkiness in accessing apps. This is how you access apps in Wear:
Tap or gesture to get out of low-power mode
Tap to get the voice input screen; this will pause any music
Swipe down to get to the menu; music is still paused
Swipe all the way to the bottom of the menu
Tap to enter the app menu; this will unpause your music.
Swipe until the desired app is in the centre of the screen
Tap it
Bonus: when you exit the app (by swiping it away), you will be dumped back at the watchface. If you want to look at another app, you must repeat the entire sequence. I think you’re supposed to be able to just say “start [app]” after step 2, but we had no luck ever getting this to work (and it requires speaking at your watch).
The apps themselves are serviceable. Sometimes they will spawn cards in the notification stack; sometimes they will not. Sometimes they won’t even though I expect them to, which feels like a bug.
Note also that “apps” are distinct from built-in services, which include a stopwatch (without laps) and silent alarms. These services are easier to access than apps, and the voice activation is more reliable there.
Pebble’s app experience may be poor, but I think this is worse.
Miscellaneous
Battery life: Pebble lasts a week (or, more conservatively, generally at least four days). This lasts a day, maybe. In practice I have experienced less than a day. Get used to this:
Display: All Wear devices have nice, colourful displays. Unfortunately, this goes hand-in-hand with truly abysmal outdoor visibility. Wear, meet California:
(Yes, that display is on.)
Conversely, being non-reflective and always-on, they must emit light. This watch always casts a noticeable, distracting glow in dark rooms, even in dimmed mode. The OLED watches probably partially mitigate this by throwing off less light.
App Discovery: There is a button in the Android Wear app that takes you to a Play Store view with a bunch of apps (~35, I think). It needs to be clearer how these actually interact with Wear. Pebble has a similar view into the iOS App Store that lists hundreds of compatible apps, as well as the actual Pebble Appstore with thousands of watchapps. It’s early days for Wear, though.
Google Now: It shows Now cards. In my case, this mostly means it periodically tells me that it’s sunny and that it would take me fifteen minutes to drive home/to work, which would be nice if I owned a car. I don’t. If Now is actually valuable to you, you will appreciate this more than me. For me, it’s this:
Summary
Wear is an interesting take on smartwatches. It’s not terrible, but it’s not great either. The battery life is unacceptable (I should never have my watch threatening to turn off mid-afternoon…), the display is illegible outdoors, and the UI is very clunky. When apps have explicit support, and that support is done well, the individual notification experience is very good (though it’s cumulatively still not great). And, of course, you need an Android 4.3+ device.
It’s a good attempt, but while it’s certainly flashier than Pebble, I don’t think it’s generally better than Pebble.
I have finally more or less completed actually moving in to my new place in Mountain View, California (so chosen for its proximity to Palo Alto and its comparatively lower prices).
It has now been almost two years since my last blog post. At the time I was in the middle of a year off from MIT for mental health (and academic) reasons, instead taking graduate classes at Boston University. Also, on a completely unrelated note, I backed Pebble’s kickstarter on the last possible day.
A lot’s happened since then.
At the end of 2012 I returned to MIT to resume my studies, primarily in irrelevant fields of little interest to me. At least I was passing this time around. Around this time I also joined the Second Life Exodus Viewer Project as a developer.
In early 2013, while pursuing further questionably relevant studies about American conspiracies I finally actually received my much-delayed Pebble. At the end of the same week the “proof-of-concept SDK” was released, and I spent my 6.042 class fiddling with it rather than learning something-or-other about graph theory. By the end of the day I had released the first Pebble stopwatch, which was featured in Kickstarter updates 36 and 37. At the same time I took ownership of the Exodus project.
In April I launched CloudPebble – by far the easiest way to get into Pebble development. It saw frequent updates. On the back of CloudPebble, Pebble invited me to try out the upcoming two-way SDK. Unfortunately, that SDK provided no allowance for communicating with the outside world, which seemed to me to be possibly the most important feature. I built httpebble as a generic solution, which launched alongside the two-way SDK, and was highlighted in Kickstarter updates 39 and 41.
I then switched gears completely and spent my summer holiday rebuilding the Java tools used for MIT’s 6.004 as web apps, generally making them much easier to use in the process.
The next semester I met Pebble’s Eric Migicovsky and Thomas Sarlandie while they were at MIT for hackMIT, a conversation in which we arranged for Pebble to buy CloudPebble, and an internship for Summer 2014, as well as (again) expressing interest in hiring me outright. Also during this semester I completed 6.UAP, my nominal “final project” at MIT… with a year and a half still to go. Very final. Pebble’s SDK 2.0 launched and CloudPebble was re-launched as a Pebble-supported project in tandem. The source code was released shortly thereafter.
After a rather long meandering, and poorly-written post, we reach the present. This semester featured 3.5 writing classes, one maths class, and a project with workload equal to one class. All of these were mandatory, and reached a total of 66 hours/week – which was almost certainly to be an understimate. Generally speaking, this time would be spent learning things I either already knew (how do you make a hashtable?) or didn’t really want to know (what is the impact of DKP on groups in MMOs?). Furthermore, my flatmate since late 2011 moved out, leaving me in an apartment on my own.
Given how much I obviously appreciated MIT, why was I still here? Well, mostly for the piece of paper. But that piece of paper seems like an increasingly bad deal, in terms of both time and money. So changed tack. I emailed Eric asking about employment at Pebble; three days later I had signed paperwork and withdrawn from MIT. In two weeks I will have moved to Palo Alto and finished my first week at Pebble.
