Aaron Parecki has been playing around with sensors in his home. He lists the three principles he applies to how his home automation is set up:

  • Manual override: Everything automated has to still have the ability to be controlled manually
  • Keep it at home: No “cloud” services unless absolutely necessary (e.g. push notifications to a phone)
  • Open: Avoid vendor lock-in, use open source and open protocols where possible

These are three principles that make sense in more contexts, where the second principle “keep it at home” I relate to the “useful on its own, more useful when connected to other instances” element that is important to me in thinking about smart homes.

Rather impressive is that Aaron is dropping technology that has been acquired by silos, and breaks those principles after he started using it, and not just uses them to inform buying decisions.

Silo-imprisonment and closed tools result in a smart home that isn’t smart for you, but smart for the vendors. Like how Smart City TM visions were about dull boring security focused panopticons keeping people in check. Not the vibrant community where ideas, people, capital, goods and artisanship recombine into a total so much more than the sum of its parts, where smart technology aids those serendipitous recombinations.

A smart home to me is one that is not just a dwelling but a productive actor (a “MakerHousehold“), for the people that live in it, for its immediate neighbourhood and for the city it is in. This was what I was interested in when shaping the ‘Smart Stuff That Matters‘ unconference last year.

Aaron got me thinking about potential sensors in our home again. Also because data gathering is the starting point for finding points of action. AI for the rest of us I think needs to be based on self collected data around the house / person, mixed with public data for context.

Liked a post by Aaron PareckiAaron Parecki

Over the past few weekends I’ve been overhauling my home automation systems. At the core, as I decide what to buy and how to configure it, there are three primary principles

Hotel keys
Hotel keys, photo by Susanne Nilsson, license CC BY-SA

Everybody hates the keycard, says the NYT, and talks about using your phone instead. There are a few reasons why using your phone as a hotel key is not something I do, or would do.

One reason is provided by the hotels promoting this themselves:

And, since the keys are downloaded electronically through a hotel app, the host has a presence on the guests’ phones, and can offer other exclusive services, like promotions and a chat feature.

Presence on my phone, that sounds rather ominous. Let me count the hotel apps I currently allow on my phone…. 0.

Unless there’s an opt-in for each single additional ‘service’ as part of a hotel’s ‘presence’ on my phone, it is in breach of the GDPR wherever I travel. Do hotel chains really want to expose up to 4% of their annual turnover to liability risks?

The ones I’ve encountered worked through bluetooth. That opens up a wide range of potential vulnerabilities. I never have bluetooth switched on (nor wifi when not in active use, for that matter), and there are very good reasons for that. There might be other bluetooth devices nearby pretending to be my hotel door to get access to my phone, or piggyback on my room door’s communication. A plastic card and a room door never have that issue. NFC based ones have less of these issues, but still bring their own issues.

A vulnerability in a hotel’s mobile app now also becomes a vulnerability for your hotel key as well as for your phone. It also means a phone will contain data traces of any hotel you may have used it as a key. That is a privacy risk in itself, not only to yourself, but potentially as well to people you have encountered. (E.g. investigative journalists would be risking the anonymity and privacy of their sources that way.)

Another reason is, also when I travel alone I have 2 plastic key cards. I keep them in different places, so I have a back-up if one of them gets out of my hands. Having just my phone is a single point of failure risk. Phones get left in hotel bars. Phones slip out of pockets in taxi back seats. Phone batteries die.

That is the third reason, that phone batteries die, especially on intensive work days abroad. Already that is sometimes problematic for mobile boarding passes for e.g. a second leg of a trip after a long haul flight (such as last month on a trip to Canada), or an evening flight home.
When staying in a hotel, after a long day, I sometimes need to leave a phone to charge in my room (sometimes the room safe has a convenient power outlet), while I go have a coffee in the lobby. This month during holidays I left my phone charging during dinner in a hotel in Rouen, as well as in an apartment on the Normandy coast, while we headed out for a walk on the beach.
So when I read in the article “What is also great is that I don’t find myself forgetting my key in the room as I always have my phone with me“, I take that to mean “you can’t leave your room when your phone needs charging” and “you can’t return to your room if your phone battery died”.

Phones and hotel keys all have their vulnerabilities. Putting a key card on your phone doesn’t remove the existing vulnerabilities of existing key card systems, but transfers and adds them to the vulnerabilities of your phone, while also combining and increasing the potential negative consequences of one of those vulnerabilities becoming actualised.

Read Everybody Hates the Key Card. Will Your Phone Replace It? (nytimes.com)

Technology that allows hotel guests to use their phones as room keys is expanding, taking aim at those environmentally unfriendly plastic cards.

Since shortly after we moved in we have a temperature and humidity sensor in our garden.

This week’s heat wave is breaking records across Europe including here in the Netherlands. So I’ve kept an eye on the temperature in our garden. Our sensor is part of a city wide network of sensors, which includes two sensors nearby. Of the three sensors, ours indicates the lowest temperature at 36.8 (at 16:45), the other two hover just under 40 and at 41.8 respectively. Such differences are caused by the surroundings of the sensor. That ours is the lowest is because it’s placed in a very green garden, while the others are out on the street. In our completely paved and bricked up courtyard the temperature is 42.1 in the shade, due to the radiation heat of sun and stones. Goes to show that greenery in a city is key in lowering temperatures.

Three sensors in our neighbourhood, ours is in the middle, showing the lowest temperature. Note that the color scale is relative, for these 3 sensors running from 36.6 to 41.8.

In the past days since our return from France the temperature has been steadily rising, as per the graph below (which currently ends at the peak of 36.8 at 16:45). Staying inside is the best option, although the also increasingly higher lowest temperatures (from 15 to above 20) mean that the nights are slowly becoming more uncomfortable as the outside temperature will stay above the in house temperature during most or all of the night.

UPDATE as of 26/7 June noon, here you can see how the night minimum jumped 5 degrees in 24 hours, bringing it above the in house temperature for the entire night, except a brief moment around 6 am. At noon the maximum for the day before is already nearly reached.

The way to make this graph yourself is

  • Go to meetjestad.net/data, where you can select various data types and time frames. Our sensor is number 51, and I selected a time frame starting at July 19th at midnight. This allows me to download the data as CSV.
  • The data in that download is Tab separated, not comma,when you select a comma to be used as decimal point.
  • The file contains columns for the sensor number and its latitude and longitude, that are not needed as this is data for just one sensor. Likewise, empty columns for measurement values for which my sensor kit doesn’t contain sensors, such as particulate matter, can be removed. Finally the columns for battery level and humidity are also not needed on this occasion.
  • With the remaining columns, time and temperature it is easy to build the graph. In this case I replaced the timestamps with sequential numbers, as I intend to make a sparkline graph with it later.

Some links I thought worth reading the past few days

Some links I thought worth reading the past few days

Some links I thought worth reading the past few days