Tag Archives: philips

Privacy expectations and the connected home

Post Syndicated from Matthew Garrett original https://mjg59.dreamwidth.org/50229.html

Traditionally, devices that were tied to logins tended to indicate that in some way – turn on someone’s xbox and it’ll show you their account name, run Netflix and it’ll ask which profile you want to use. The increasing prevalence of smart devices in the home changes that, in ways that may not be immediately obvious to the majority of people. You can configure a Philips Hue with wall-mounted dimmers, meaning that someone unfamiliar with the system may not recognise that it’s a smart lighting system at all. Without any actively malicious intent, you end up with a situation where the account holder is able to infer whether someone is home without that person necessarily having any idea that that’s possible. A visitor who uses an Amazon Echo is not necessarily going to know that it’s tied to somebody’s Amazon account, and even if they do they may not know that the log (and recorded audio!) of all interactions is available to the account holder. And someone grabbing an egg out of your fridge is almost certainly not going to think that your smart egg tray will trigger an immediate notification on the account owner’s phone that they need to buy new eggs.

Things get even more complicated when there’s multiple account support. Google Home supports multiple users on a single device, using voice recognition to determine which queries should be associated with which account. But the account that was used to initially configure the device remains as the fallback, with unrecognised voices ended up being logged to it. If a voice is misidentified, the query may end up being logged to an unexpected account.

There’s some interesting questions about consent and expectations of privacy here. If someone sets up a smart device in their home then at some point they’ll agree to the manufacturer’s privacy policy. But if someone else makes use of the system (by pressing a lightswitch, making a spoken query or, uh, picking up an egg), have they consented? Who has the social obligation to explain to them that the information they’re producing may be stored elsewhere and visible to someone else? If I use an Echo in a hotel room, who has access to the Amazon account it’s associated with? How do you explain to a teenager that there’s a chance that when they asked their Home for contact details for an abortion clinic, it ended up in their parent’s activity log? Who’s going to be the first person divorced for claiming that they were vegan but having been the only person home when an egg was taken out of the fridge?

To be clear, I’m not arguing against the design choices involved in the implementation of these devices. In many cases it’s hard to see how the desired functionality could be implemented without this sort of issue arising. But we’re gradually shifting to a place where the data we generate is not only available to corporations who probably don’t care about us as individuals, it’s also becoming available to people who own the more private spaces we inhabit. We have social norms against bugging our houseguests, but we have no social norms that require us to explain to them that there’ll be a record of every light that they turn on or off. This feels like it’s going to end badly.

(Thanks to Nikki Everett for conversations that inspired this post)

(Disclaimer: while I work for Google, I am not involved in any of the products or teams described in this post and my opinions are my own rather than those of my employer’s)

comment count unavailable comments

AWS IoT Update – Better Value with New Pricing Model

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/aws-iot-update-better-value-with-new-pricing-model/

Our customers are using AWS IoT to make their connected devices more intelligent. These devices collect & measure data in the field (below the ground, in the air, in the water, on factory floors and in hospital rooms) and use AWS IoT as their gateway to the AWS Cloud. Once connected to the cloud, customers can write device data to Amazon Simple Storage Service (S3) and Amazon DynamoDB, process data using Amazon Kinesis and AWS Lambda functions, initiate Amazon Simple Notification Service (SNS) push notifications, and much more.

New Pricing Model (20-40% Reduction)
Today we are making a change to the AWS IoT pricing model that will make it an even better value for you. Most customers will see a price reduction of 20-40%, with some receiving a significantly larger discount depending on their workload.

The original model was based on a charge for the number of messages that were sent to or from the service. This all-inclusive model was a good starting point, but also meant that some customers were effectively paying for parts of AWS IoT that they did not actually use. For example, some customers have devices that ping AWS IoT very frequently, with sparse rule sets that fire infrequently. Our new model is more fine-grained, with independent charges for each component (all prices are for devices that connect to the US East (Northern Virginia) Region):

Connectivity – Metered in 1 minute increments and based on the total time your devices are connected to AWS IoT. Priced at $0.08 per million minutes of connection (equivalent to $0.042 per device per year for 24/7 connectivity). Your devices can send keep-alive pings at 30 second to 20 minute intervals at no additional cost.

Messaging – Metered by the number of messages transmitted between your devices and AWS IoT. Pricing starts at $1 per million messages, with volume pricing falling as low as $0.70 per million. You may send and receive messages up to 128 kilobytes in size. Messages are metered in 5 kilobyte increments (up from 512 bytes previously). For example, an 8 kilobyte message is metered as two messages.

Rules Engine – Metered for each time a rule is triggered, and for the number of actions executed within a rule, with a minimum of one action per rule. Priced at $0.15 per million rules-triggered and $0.15 per million actions-executed. Rules that process a message in excess of 5 kilobytes are metered at the next multiple of the 5 kilobyte size. For example, a rule that processes an 8 kilobyte message is metered as two rules.

Device Shadow & Registry Updates – Metered on the number of operations to access or modify Device Shadow or Registry data, priced at $1.25 per million operations. Device Shadow and Registry operations are metered in 1 kilobyte increments of the Device Shadow or Registry record size. For example, an update to a 1.5 kilobyte Shadow record is metered as two operations.

The AWS Free Tier now offers a generous allocation of connection minutes, messages, triggered rules, rules actions, Shadow, and Registry usage, enough to operate a fleet of up to 50 devices. The new prices will take effect on January 1, 2018 with no effort on your part. At that time, the updated prices will be published on the AWS IoT Pricing page.

AWS IoT at re:Invent
We have an entire IoT track at this year’s AWS re:Invent. Here is a sampling:

We also have customer-led sessions from Philips, Panasonic, Enel, and Salesforce.


Gladys Project: a Raspberry Pi home assistant

Post Syndicated from Alex Bate original https://www.raspberrypi.org/blog/gladys-project-home-assistant/

If, like me, you’re a pretty poor time-keeper with the uncanny ability to never get up when your alarm goes off and yet still somehow make it to work just in time — a little dishevelled, brushing your teeth in the office bathroom — then you too need Gladys.

Raspberry Pi home assistant

Over the last year, we’ve seen off-the-shelf home assistants make their way onto the Raspberry Pi. With the likes of Amazon Alexa, Google Home, and Siri, it’s becoming ever easier to tell the air around you to “Turn off the bathroom light” or “Resume my audiobook”, and it happens without you lifting a finger. It’s quite wonderful. And alongside these big names are several home-brew variants, such as Jarvis and Jasper, which were developed to run on a Pi in order to perform home automation tasks.

So do we need another such service? Sure! And here’s why…

A Romantic Mode with your Home Assistant Gladys !

A simple romantic mode in Gladys ! See https://gladysproject.com for more informations about the project 🙂 Devices used : – A 5$ Xiaomi Switch Button – A Raspberry Pi 3 with Gladys on it – Connected lights ( Works with Philips Hue, Milight lamp, etc..

Gladys Project

According to the Gladys creators’ website, Gladys Project is ‘an open-source program which runs on your Raspberry Pi. It communicates with all your devices and checks your calendar to help you in your everyday life’.

Gladys does the basic day-to-day life maintenance tasks that I need handled in order to exist without my mum there to remind me to wake up in time for work. And, as you can see from the video above, it also plays some mean George Michael.

A screenshot of a mobile phone showing the Gladys app - Gladys Project home assistant

Gladys can help run your day from start to finish, taking into consideration road conditions and travel time to ensure you’re never late, regardless of external influences. It takes you 30 minutes to get ready and another 30 minutes to drive to work for 9.00? OK, but today there’s a queue on the motorway, and now your drive time is looking to be closer to an hour. Thankfully, Gladys has woken you up a half hour earlier, so you’re still on time. Isn’t that nice of her? And while you’re showering and mourning those precious stolen minutes of sleep, she’s opening the blinds and brewing coffee for you. Thanks, mum!

A screenshot of the Gladys hub on the Raspberry Pi - Gladys Project home assistant

Set the parameters of your home(s) using the dedicated hub.

Detecting your return home at the end of the day, Gladys runs your pre-set evening routine. Then, once you place your phone on an NFC tag to indicate bedtime, she turns off the lights and, if your nighttime preferences dictate it, starts the whale music playlist, sending you into a deep, stressless slumber.

A screenshot of Etcher showing the install process of the Gladys image - Gladys Project home assistant

Gladys comes as a pre-built Raspbian image, ready to be cloned to an SD card.

Gladys is free to download from the Gladys Project website and is compatible with smart devices such as Philips Hue lightbulbs, WeMo Insight Switches, and the ever tricky to control without the official app Sonos speakers!

Automate and chill

Which tasks and devices in your home do you control with a home assistant? Do you love sensor-controlled lighting which helps you save on electricity? How about working your way through an audiobook as you do your housework, requesting a pause every time you turn on the vacuum cleaner?

Share your experiences with us in the comments below, and if you’ve built a home assistant for Raspberry Pi, or use an existing setup to run your household, share that too.

And, as ever, if you want to keep up to date with Raspberry Pi projects from across the globe, be sure to follow us on social media, sign up to our weekly newsletter, the Raspberry Pi Weekly, and check out The MagPi, the official magazine of the Raspberry Pi community, available in stores or as a free PDF download.

The post Gladys Project: a Raspberry Pi home assistant appeared first on Raspberry Pi.

A Raspberry Pi Halloween projects spectacular

Post Syndicated from Janina Ander original https://www.raspberrypi.org/blog/halloween-projects-2017/

Come with us on a journey to discover the 2017 Raspberry Pi Halloween projects that caught our eye, raised our hair, or sent us screaming into the night.

A clip of someone being pulled towards a trap door by hands reaching up from it - Raspberry Pi Halloween projects

Happy Halloween

Whether you’re easily scared or practically unshakeable, you can celebrate Halloween with Pi projects of any level of creepiness.

Even makers of a delicate constitution will enjoy making this Code Club Ghostbusters game, or building an interactive board game using Halloween lights with this MagPi tutorial by Mike Cook. And how about a wearable, cheerily LED-enhanced pumpkin created with the help of this CoderDojo resource? Cute, no?

Felt pumpkin with blinking LED smiley face - Raspberry Pi Halloween projects

Speaking of wearables, Derek Woodroffe’s be-tentacled hat may writhe disconcertingly, but at least it won’t reach out for you. Although, you could make it do that, if you were a terrible person.

Slightly queasy Halloween

Your decorations don’t have to be terrifying: this carved Pumpkin Pi and the Poplawskis’ Halloween decorations are controlled remotely via the web, but they’re more likely to give you happy goosebumps than cold sweats.

A clip of blinking Halloween decorations covering a house - Raspberry Pi Halloween projects

The Snake Eyes Bonnet pumpkin and the monster-face projection controlled by Pis that we showed you in our Halloween Twitter round-up look fairly friendly. Even the 3D-printed jack-o’-lantern by wermy, creator of mintyPi, is kind of adorable, if you ignore the teeth. And who knows, that AlexaPi-powered talking skull that’s staring at you could be an affable fellow who just fancies a chat, right? Right?

Horror-struck Halloween

OK, fine. You’re after something properly frightening. How about the haunted magic mirror by Kapitein Haak, or this one, with added Philips Hue effects, by Ben Eagan. As if your face first thing in the morning wasn’t shocking enough.

Haunted magic mirror demonstration - Raspberry Pi Halloween projects

If you find those rigid-faced, bow-lipped, plastic dolls more sinister than sweet – and you’re right to do so: they’re horrible – you won’t like this evil toy. Possessed by an unquiet shade, it’s straight out of my nightmares.

Earlier this month we covered Adafruit’s haunted portrait how-to. This build by Dominick Marino takes that concept to new, terrifying, heights.

Haunted portrait project demo - Raspberry Pi Halloween projects

Why not add some motion-triggered ghost projections to your Halloween setup? They’ll go nicely with the face-tracking, self-winding, hair-raising jack-in-the-box you can make thanks to Sean Hodgins’ YouTube tutorial.

And then, last of all, there’s this.

The Saw franchise's Billy the puppet on a tricycle - Raspberry Pi Halloween projects


This recreation of Billy the Puppet from the Saw franchise is Pi-powered, it’s mobile, and it talks. You can remotely control it, and I am not even remotely OK with it. That being said, if you’re keen to have one of your own, be my guest. Just follow the guide on Instructables. It’s your funeral.

Make your Halloween

It’s been a great year for scary Raspberry Pi makes, and we hope you have a blast using your Pi to get into the Halloween spirit.

And speaking of spirits, Matt Reed of RedPepper has created a Pi-based ghost detector! It uses Google’s Speech Neural Network AI to listen for voices in the ether, and it’s live-streaming tonight. Perfect for watching while you’re waiting for the trick-or-treaters to show up.

The post A Raspberry Pi Halloween projects spectacular appeared first on Raspberry Pi.

Bluetooth LED bulbs

Post Syndicated from Matthew Garrett original https://mjg59.dreamwidth.org/43722.html

The best known smart bulb setups (such as the Philips Hue and the Belkin Wemo) are based on Zigbee, a low-energy, low-bandwidth protocol that operates on various unlicensed radio bands. The problem with Zigbee is that basically no home routers or mobile devices have a Zigbee radio, so to communicate with them you need an additional device (usually called a hub or bridge) that can speak Zigbee and also hook up to your existing home network. Requests are sent to the hub (either directly if you’re on the same network, or via some external control server if you’re on a different network) and it sends appropriate Zigbee commands to the bulbs.

But requiring an additional device adds some expense. People have attempted to solve this in a couple of ways. The first is building direct network connectivity into the bulbs, in the form of adding an 802.11 controller. Go through some sort of setup process[1], the bulb joins your network and you can communicate with it happily. Unfortunately adding wifi costs more than adding Zigbee, both in terms of money and power – wifi bulbs consume noticeably more power when “off” than Zigbee ones.

There’s a middle ground. There’s a large number of bulbs available from Amazon advertising themselves as Bluetooth, which is true but slightly misleading. They’re actually implementing Bluetooth Low Energy, which is part of the Bluetooth 4.0 spec. Implementing this requires both OS and hardware support, so older systems are unable to communicate. Android 4.3 devices tend to have all the necessary features, and modern desktop Linux is also fine as long as you have a Bluetooth 4.0 controller.

Bluetooth is intended as a low power communications protocol. Bluetooth Low Energy (or BLE) is even lower than that, running in a similar power range to Zigbee. Most semi-modern phones can speak it, so it seems like a pretty good choice. Obviously you lose the ability to access the device remotely, but given the track record on this sort of thing that’s arguably a benefit. There’s a couple of other downsides – the range is worse than Zigbee (but probably still acceptable for any reasonably sized house or apartment), and only one device can be connected to a given BLE server at any one time. That means that if you have the control app open while you’re near a bulb, nobody else can control that bulb until you disconnect.

The quality of the bulbs varies a great deal. Some of them are pure RGB bulbs and incapable of producing a convincing white at a reasonable intensity[2]. Some have additional white LEDs but don’t support running them at the same time as the colour LEDs, so you have the choice between colour or a fixed (and usually more intense) white. Some allow running the white LEDs at the same time as the RGB ones, which means you can vary the colour temperature of the “white” output.

But while the quality of the bulbs varies, the quality of the apps doesn’t really. They’re typically all dreadful, competing on features like changing bulb colour in time to music rather than on providing a pleasant user experience. And the whole “Only one person can control the lights at a time” thing doesn’t really work so well if you actually live with anyone else. I was dissatisfied.

I’d met Mike Ryan at Kiwicon a couple of years back after watching him demonstrate hacking a BLE skateboard. He offered a couple of good hints for reverse engineering these devices, the first being that Android already does almost everything you need. Hidden in the developer settings is an option marked “Enable Bluetooth HCI snoop log”. Turn that on and all Bluetooth traffic (including BLE) is dumped into /sdcard/btsnoop_hci.log. Turn that on, start the app, make some changes, retrieve the file and check it out using Wireshark. Easy.

Conveniently, BLE is very straightforward when it comes to network protocol. The only thing you have is GATT, the Generic Attribute Protocol. Using this you can read and write multiple characteristics. Each packet is limited to a maximum of 20 bytes. Most implementations use a single characteristic for light control, so it’s then just a matter of staring at the dumped packets until something jumps out at you. A pretty typical implementation is something like:


where r, g and b are each just a single byte representing the corresponding red, green or blue intensity. 0x56 presumably indicates a “Set the light to these values” command, 0xaa indicates end of command and 0xf0 indicates that it’s a request to set the colour LEDs. Sending 0x0f instead results in the previous byte (0x00 in this example) being interpreted as the intensity of the white LEDs. Unfortunately the bulb I tested that speaks this protocol didn’t allow you to drive the white LEDs at the same time as anything else – setting the selection byte to 0xff didn’t result in both sets of intensities being interpreted at once. Boo.

You can test this out fairly easily using the gatttool app. Run hcitool lescan to look for the device (remember that it won’t show up if anything else is connected to it at the time), then do gatttool -b deviceid -I to get an interactive shell. Type connect to initiate a connection, and once connected send commands by doing char-write-cmd handle value using the handle obtained from your hci dump.

I did this successfully for various bulbs, but annoyingly hit a problem with one from Tikteck. The leading byte of each packet was clearly a counter, but the rest of the packet appeared to be garbage. For reasons best known to themselves, they’ve implemented application-level encryption on top of BLE. This was a shame, because they were easily the best of the bulbs I’d used – the white LEDs work in conjunction with the colour ones once you’re sufficiently close to white, giving you good intensity and letting you modify the colour temperature. That gave me incentive, but figuring out the protocol took quite some time. Earlier this week, I finally cracked it. I’ve put a Python implementation on Github. The idea is to tie it into Ulfire running on a central machine with a Bluetooth controller, making it possible for me to control the lights from multiple different apps simultaneously and also integrating with my Echo.

I’d write something about the encryption, but I honestly don’t know. Large parts of this make no sense to me whatsoever. I haven’t even had any gin in the past two weeks. If anybody can explain how anything that’s being done there makes any sense at all[3] that would be appreciated.

[1] typically via the bulb pretending to be an access point, but also these days through a terrifying hack involving spewing UDP multicast packets of varying lengths in order to broadcast the password to associated but unauthenticated devices and good god the future is terrifying

[2] For a given power input, blue LEDs produce more light than other colours. To get white with RGB LEDs you either need to have more red and green LEDs than blue ones (which costs more), or you need to reduce the intensity of the blue ones (which means your headline intensity is lower). Neither is appealing, so most of these bulbs will just give you a blue “white” if you ask for full red, green and blue

[3] Especially the bit where we calculate something from the username and password and then encrypt that using some random numbers as the key, then send 50% of the random numbers and 50% of the encrypted output to the device, because I can’t even

comment count unavailable comments