Is It Smart? – Google Home

Hello BIMfans,
Welcome to ‘Is It Smart?’, the blog series where I have a look at the smart technology installed within Ty Crempog to explore the power of BIM Level 2, PropTech, and the Internet of Things (IOT).  This week, I take a look at my Google Home.

What is it?

Pro Tip:  Do not watch any ‘How to’ videos while you have it plugged in, otherwise your video will set it off!

The Google Home is a hands-free smart (Wi-Fi) enabled speaker powered by the Google Assistant.  I currently have it installed in 002: Living Room as it is the most frequently occupied room in my home.  It has a built-in speaker and microphone which will listen out for the trigger phrase “OK Google” and then attempt to execute any command it hears.

 How does it work?

Once you have registered any service or device from Google‘s range of Compatible Partners, all you have to do is speak; It’s as easy as that!

So have I have gotten my Google Home to:

  • Provide me with a weather update;
  • Challenge guests to a trivia quiz;
  • Traffic updates;
  • Instant fight debate arbitrator;
  • Play music through my Spotify account;
  • Control my Nest Thermostat; and
  • Control my Philips Hue bulbs.

For example, have a look at this short video on how I can use my Google Home to control the Philips Hue in my living room.

 How Did I Model it?

My Google Home family can be downloaded from here.

Under the Industry Foundation Class (IFC) Schema, a smart speaker isn’t included (who’d have guessed?), so I did what I always do in a situation like this; asked Twitter.

As you can see, at the time I produced this object, the preferred type was CommunicationAppliance.  This makes sense as while it does include a speaker (Making it AudioVisual) it’s main role is to communicate with other devices on my behalf.  So, using an electrical equipment family, I created two revolve solids and a void extrusion to create its unique shape.  Due to the low level of graphical detail used the object file is only around 400KB.  The file was named following the BS8541-1 naming convention to:


Using the requirements set out within my Data Requirements, I populated this Communication Appliance object with the information needed to manage my Google Home.  Within this object, I have captured information such as: Installation information, bar code, serial number, replacement cost and warranty information.  Note:  Much like my Nest Thermostat, my Google Home is one of the few items I manage within its warranty period.

When used in collaboration with my IFC Export mapping text file, my Google Home is populating all of the relevant COBie fields I require; fantastic.

Is it Smart?

Google Home ticks many of the right boxes to be considered smart.

  • Data In:  With a Wi-Fi connection and a passive listening system, Google Home has a consistent method it can collect data.  In addition, through the mobile app it can control other devices and apply nicknames; which apply to the voice commands.
  • Data Out:  Using the power of the internet, Google Home can provide me almost any information.  It also remembers each command it is given to help it improve its functionality, so I have a record of what has been asked.
  • Connectivity:  The real power of Google Home is in its ability to connect with other devices.  So far I have it connected to my BBC, IFTT, and Spotify services as well as my Nest Thermostat, and Philips Hue bulbs.  Meaning that I can create customizable commands, set alarms, and even add events to my calendar using just two magic words; “Ok Google“.

The Potential

Much like my other smart products, there is no method to automate taking information from my information model into my Google Home.  For example, I have had to manually add the component names of my products as Nicknames (without special characters) so that each product can be controlled by its unique reference.

If only this process could be automated, then my smart products could use a lot of the good information I have collected to make them even smarter.

GoogleHome UI
While these names might not roll off the tongue, but at least the information is consistent between my Google Home, graphical model, and Non-graphical information.

The Verdict


Is It Smart? The answer is Yes, with an Impressive IQ of 120!

Since it was first announced, I knew I wanted to have a Google Home, and I am glad to say that it has not disappointed.  While fairly simple in function, it has had a positive impact on my home.

And there you have it.  This week my Google Home proved to be quite smart.  Tune in next time where we take a look at my Philips Hue installation and ask one simple question; Is It Smart?


Is It Smart? – Amazon Dash

Hello BIMfans,
Welcome to ‘Is It Smart’, a blog series where I have a look at the smart technology installed within Ty Crempog as I explore the power of BIM level 2PropTech, and the Internet of Things (IOT).  This week, I take a look at my Amazon Dash Buttons.

What is it?


The Amazon Dash Button is a Wi-Fi enabled device, linked to specific products on Amazon.  When you are starting to run low of a product, you simply press the button and an order will be placed and delivered using the details you have provided.

How Does it Work?


Using an Amazon account, you register the Amazon Dash Button as a device (like you would a Kindle).  Once the device is registered, you are able to select a product from the shortlist Amazon supports for your branded button (ie I can’t get my Andrex Button to deliver Velvet or Cushelle).

Once all of this has been completed, pressing the button sends a command over WI-FI to place an order for that product; it’s as simple as that.  The button also has a fail-safe that stops someone from pressing it multiple times by as default only allowing a single active order.

How Did I Model it?

My Amazon Dash Button can be downloaded from here.

Under the Industry Foundation Class (IFC) Schema, there is no obvious IFC Type, so I did what I always do in a situation such as this; ask Twitter.

Following the voting, the majority of people thought that it should be a Communication Appliance.  However, I have overruled this verdict and used  SwitchingDevice_MomentarySwitch (Sorry!).  I did this as my Amazon Dash Buttons have no ‘position’ and simply trigger an action to occur; making them switches.

Similar to my Nest Thermostat I used a face based generic model to create my object, but this time I have modelled the object as a solid oval.  Due to the low level of graphical detail used the object file is only around 296KB.  The file was named following the BS8541-1 naming convention to:


Using the requirements set out within my Data Requirements, I populated this object with the data needed to manage my Amazon Dash Buttons.  Capturing information such as: Installation data, serial number, replacement cost, and warranty information.

Is it Smart?

The Amazon Dash Button, unfortunately, doesn’t really tick the right boxes to be considered smart.

  • Data in: Without any sensors, the data input method on the Amazon Dash Button is the button itself which means that the ONLY way to active it is by physically pressing the button.  Also annoyingly, the buttons settings can only be edited through the mobile app, and these settings are rather limited.  For example, there is no way to rename my buttons despite being able to name other devices on my account.

    Why, why can’t I rename these buttons?
  • Data out:  There is also little data available from the device.  Aside from the default order history held on an Amazon account, no other information is available apart from a confirmation email received after the button is pressed.
  • Connectivity: Due to the proprietary nature of the service, it is no surprise that it offers little connectivity.  These buttons are basically physical Do Buttons, but without any connectivity to other applications.  Of course, that hasn’t stopped some people from thinking of Amazon Dash Button Hacks.

The Potential

Think of all the fun it would be to trigger amazon deliveries if they spoke to each other…

Currently, this use of these buttons is very limited.  If Amazon had opened up the button’s so that it could connect with IFTTT, then it would blow their potential wide open allowing for activation through triggers as well as physical presses.  This would also have the benefit of allowing recipes to store a log of when the buttons where pressed, which could then be used for settings future budgets as there would be a record of how often the buttons are pressed (or triggered).

The Verdict


Is it Smart?  The answer is no, with an IQ of only 70.

The Amazon Dash Buttons sounded pretty interesting when they were first released, however, after fitting a couple into my home I am disappointed at how little information I get out and put into them.  Compared to other smart home products, it seems odd how isolated the Amazon Dash Buttons are especially when you consider how connected something like Amazon Echo is.   The biggest disappointment is how I am forced to select only a few products from a pick-list.  This meant that only bulk orders could be selected which came as quite a surprise when they arrived.

45 loo rolls are more than enough!  No-one press the button for another six months!

And there you have it, This week my Amazon Dash Buttons didn’t prove very smart.  Tune in next time when I consider my Google Home and ask one simple question; Is It Smart?

Is It Smart? – Nest Thermostat

Hello BIMfans,
Welcome to ‘Is It Smart?‘, a blog series where I have a look at the smart technology within installed Ty Crempog as I explore the power of BIM Level 2 and the Internet of Things (IoT).   This week, I take a look at my Nest Thermostat.

What is it?


The Nest Thermostat is an electronic, programmable, Wi-Fi enabled thermostat that learns from real-time use to optimize heating.  I currently have it installed in 002: Living Room as it is the most frequently occupied room in my home.  It has a series of built-in sensors that measure temperature as well humidity, motion, and ambient light.

How Does it Work?

The UI is incredibly simple to use.  Also, you can customize the location, so my Nest is now in 002: Living Room to match my information model

When installed, the Nest Thermostat is connected over Wi-Fi to the boiler via an additional device called Heat Link which bypasses the boiler controls.

Quite simply, the big number in the middle is the programmed temperature (19) and the gauge shows the current temperature (21).  When the current temperature drops below the programmed temperature the heat link is activated; telling the boiler to run on full.  Once the programmed temperature is reached, a signal is sent to the heat link to deactivate the boiler and the cycle repeats indefinitely.

How Did I Model it?

My Nest Thermostat family can be downloaded from here.

Under the Industry Foundation Class (IFC) Schema, a thermostat isn’t included (it doesn’t appear until IFC4) so I have had to resort to IfcSensorType.  So, using a face based generic model I created a hollow cylinder and two inserts to represent the thermostat.  Due to the low level of graphical detail used the object file is only around 316KB.  The file was named following the BS8541-1 naming convention to:


Note:  Strangely, IfcUnitaryControlElement is included within BS8541-1, but not in the IFC2x3TC1 schema.  So for consistency, I haven’t used it.

Using the requirements set out within my Data Requirements, I populated this object with the data needed to manage my thermostat.  Capturing information such as: Installation information, bar code, serial number, replacement cost and warranty information.  NOTE, my thermostat is one of the few items I manage within its warranty period.

When used in collaboration with my IFC Export mapping text file, my thermostat is populating all of the relevant COBie fields I require; fantastic.

Is it Smart?

The Nest Thermostat ticks many of the right boxes to be considered smart.

  • Data In:  With a number of sensors, a Wi-Fi connection, and both physical and digital interfaces methods there is a wealth of ways that it can collect data.  As a result, the thermostat learns about the space, proving an estimated amount of time needed to take effect based on past data.  In addition, Nest stores a heating programme for your home and maintains an activity log.
As you can see, the fiancee decided to put the heating on before bed last week which I only discovered when writing this blog post.  Cold!? It’s September!
  • Data Out:  Each month, Nest also provides owners with a report detailing how long the heating has been on as well as an update about the performance of my devices.  If you want more sophisticated data out of your nest, the API can be accessed here.
2 hours of heating in June!? I wonder who did that…
  • Connectivity:  The ease that the Nest Thermostat can connect to other devices is a real strength.  Other products included within the ‘Works with Nest‘ category are able to access information from the Nest Thermostat.  For example, as a security feature, my Philips Hue bulbs will intermittently switch on/off in the evenings if my thermostat is set to ‘Away’.  In addition, as discussed in a previous post, through the use of IFTTT my thermostat can trigger (and be triggered) by other events.  Currently when my thermostat is set to ‘Home’, I receive a welcome home message in addition to any tweets from @TyCrempog when it is too hot or too cold.
As clever as this is, there is nothing more worrying then seeing this message on your Twitter feed when you are away on business and the fiancee is in work. #BlameTheRabbit?

The Potential

Imagine the data I could give my thermostat when my COBie files are full.

Currently, there is no method to automate the exchange of information to my Nest Thermostat from my information model; but this doesn’t have to be the case.  For example, within my Architectural model, there is a lot of good information that the Nest Thermostat could take advantage of including: Facility Name, Space Name, Area, & Volume and perhaps even external object thermal transmittance.

This kind of information could potentially improve the Nest Thermostat‘s ability to predict and control the temperature of my home if there was a way to import it.

The verdict


Is It Smart? The answer is Yes, with an Impressive IQ of 130!

Since we had planned to buy our first home, the Nest Thermostat had always been on my shopping list and may very well have been the first purchase I made.  I’m glad to say it has not disappointed.

Since programming in a compromised heating schedule, I have barely had to touch the Thermostat control for the past 12 months.  While fairly simple in function, the Nest Thermostat has a lot of data being considered in the background, coupled with an impressive list of connectable products and regular reporting, it was always going to do well.

And there you have it, This week my Nest Thermostat has proved to be quite smart.  Tune in next time when I consider my Amazon Dash and ask one simple question; Is It Smart?

Object Library Wars

Hello BIMfans,
After managing to produce my Architectural floor plan drawing last week, this week I have started to look at my Mechanical graphical model.

Around my home, there are several different heating products I need to register and capture within my information model.  So, I thought I would try something different and attempt to use some manufacturer’s objects instead of producing my own. Unfortunately finding suitable objects has proved rather difficult, however, I did manage to find a few boilers on the portals of each of the three most popular online object libraries: National Building Library (NBL), BIM Store, and BIM Object.  So I thought I would compare each of them to decide which I would use.

Let the Object Library Wars Commence!

A long time ago, in a graphical model far, far away….

The Rules:

I went onto the portal for each of these online object libraries and searched for the term ‘Boiler’ and selected the closest object available to compare against the requirements within my BIM Execution Plan. These objects were judged by the following categories based on the appropriate BIM Execution Plan specified BS 8541 standards:

Object Name:

BS 8541-1 specifies how to name objects.  The name should include three fields separated by an _underscore, written using CamelCase:

  • Source (The library it was taken from or the manufacturer of the object);
  • Type (Appropriate IfcType as included in the appendix of BS 8541-1);
  • Subtype (Additional details NOT covered in the object’s attributes).

For an object name to be compliant I would expect to see something similar to:


So, what names have been used?  Shown below are the boiler names as they were downloaded.  As you can see each object included a source, however, none of them used the IFC Type or its predefined subtype or product/model name.  In addition, both the BIM Store and BIM Object boilers include hyphens which are not permitted.

The NBL boiler is the closest with three fields and CamelCasing, followed by BIM Store which began with the source, and finally, BIM Object last which began with a bespoke category.

Source File Name Rank
NBL nbl_GasFiredCondensingBoilers_TopFlueSpigotConnector 1st
BIM Store Worcester-GB162-Gas_Fired_Condensing_Boiler_Single-14 2nd
BIM Object HVAC_Heaters_Baxi_Luna-Duo-tec-MP-plus 3rd

Note:  I am aware that each of these libraries has their own object standard.  However, my EIR didn’t request these. So my BIM Execution Plan needs to comply with the national standards.

Level of Detail:

BS 8541-2 specifies the need to be able to visually represent an object with three levels of detail:  Coarse, Medium, and Fine.  These levels of detail allow an object to show only relevant elements as required.  For example, the detail needed in an assembly drawing would not need to be visible in a general arrangement.  I’m pleased to report that each of these objects did incorporate these levels of detail; resulting in a three-way tie.

Source Levels of Detail Provided Rank
NBL Coarse, Medium, and Fine 1st
BIM Store Coarse, Medium, and Fine 1st
BIM Object Coarse, Medium, and Fine 1st
Here is the same Boiler at Coarse, Medium, and Fine detail.

Shape and Measure:

BS 8541-3 specifies that product objects (those that represent an actual product) are required to have a coordinating level of detail.  This means that the product should be visibly recognizable.  However, it also warns about the dangers of excessive geometric detail, which can be seen in these objects. Here are two examples:

  • Company logo.  Shown here is the Worcester logo included in the BIM Store Boiler. Why? The logo itself is only 25mm high and is only legible at quite low scales. What value does having this logo included bring to this object?

    As you can see at 1:1 the logo appears fine but becomes unreadable from 1:20
  • Complex elements.  Many of these families utilize nested objects (objects within objects, think Terry Pratchett and turtles).  Some of these nested objects are quite complicated for what are essentially graphical placeholders.  For example, take the flue basket also shown below from the same BIM Store boiler which uses a horrendous amount of rules to show that it is perforated.

    While only being 100mm tall, this flue basket has over 50 (yes, 50!) references to produce the 10x10mm perforations shown.

As you can see below, these additional complexities have negatively affected the file sizes.  With NBL again coming out best with the smallest file size by far for their generic boiler.

Source File Size Rank
NBL 440KB 1st
BIM Store 1396KB 2nd
BIM Object 2344KB 3rd

NOTE:  The file size for the flue basket is 668KB, so this nested object alone takes up more memory than the whole of the NBL Boiler.

Level of Information:

BS 8541-4 specifies that product objects, as defined earlier, should have both specification and assessment attributes.  In addition, these attributes should be named in CamelCase and indicate the data type expected.  Of the three boilers, only the NBL boiler followed BS 8541-4 fully by using CamelCase throughout its attributes.  BIM Store are a close second, follow this convention only for attributes required to achieve BS 1192-4. While the BIM Object boiler does not include BS 1192-4 attributes or use CamelCase.

Spaces, spaces everywhere!

This means that once again the NBL boiler leads with its impressive use of CamelCase, with BIM Store second, and BIM Object third.

Source Level of Information Rank
NBL CamelCase for all attributes 1st
BIM Store CamelCase only for COBie attributes 2nd
BIM Object CamelCase not used 3rd

The Conclusion:

The winner, consistently ranking first in each category is the National Building Library!

However to be frank none of these objects are ideal.  For future product objects, it will be much easier for me to create my own.  This is due to the limitations I have listed above as well as the fact that these objects cannot be easily configured to suit my needs. For example, for the Classification information to exchange into COBie I require it to be written into a field called ‘ClassificationForObjects’.  However, this property doesn’t exist in any of the three boiler objects.  In addition, there are a number of attributes I don’t need that will have to be deleted such as the reference to other classification systems, as well as modifications to the geometry to lower the file size.

Mech Model
It has been heavily modified, but you can see the winning NBL boiler in my Mechanical Model.

And there you have it, after comparing three different boilers I have now begun to make the necessary changes to create my final boiler object.  This means that subject to ensuring that the correct product information is attached and the inclusion of a few extraction fans, I have now populated my mechanical model; therefore Plain Language Question PLQ2.4 is well underway!

Note:  This model does not have any pipework connecting my heating system together, and nor will it.  The majority of my pipework is not accessible, and as such, I have decided that I will not guess where they are located.  Pipework, therefore, has been excluded from the model until such time as its precise location can be determined.

Model Generation:
2.1 What existing information is available?
2.2 Is there sufficient information to produce a BEP?
2.3 What is the layout of the house?
2.4 What assets are contained within?
2.5 What asset information can be linked to the graphical model?

Now that I have a pretty strong Architectural & Mechanical model, it’s time to look at some electrical objects…

Note:  If you have any comments or opinions regarding Object Library Wars, please let me know either on twitter, or commenting below.

PLQ1.5 – Level of Definition

Hello BIMfans,

After completing my schedule of required Standards last week, I am only one Plain Language Question away from being ready to produce my Employer’s Information Requirements.  So let’s tackle PLQ1.5 and discuss Level of Definition.

Now in a slightly different format to usual, this week I will be tackling Level of Definition with an example; before that let’s define Level of Definition.  Using the  BRE Terminology tool, Level of Definition is:

Collective term used for and including ‘level of model detail’ and the ‘level of information detail’ – PAS1192-2

Ok, now to understand what ‘level of model detail’ and ‘level of information detail’ are, I will refer to work done by NBS with their BIM toolkit; where there is an article that defines both these terms.  In short:

LOD (Level of Model Detail):  Is the numerical value related to the amount of graphical detail included within an object related to the digital Plan of Work (dPoW) stages. Objects start conceptually (LOD2), develop to generic representations (LOD3), then developed further to match the geometry of the specified element/product (LOD4), and finally developed to include supporting detail for construction and installation (LOD5).

LOI (Level of Information Detail):  Is a non-graphical equivalent of the process described above. Objects start with an outline description (LOI2), then develop to include performance criteria (LOI3), then developed further to include information on the specified element/product (LOI4), then developed to include information on any associated (child) products (LOI5), and finally developed to include installation and maintenance information (LOI6).

The simplest to determine is what Level of Information I need.  As I stated when I looked at my Model Purposes and Data Requirements, I will be using my information model to undertake ‘Maintenance and Repair’ & ‘Replacements’.  Therefore I will need installation and maintenance information; requiring Level of Information Detail (LOI) 6. Level of Model detail, on the other hand, is a bit more complex; have a look at this example.

In my home I have an indoor Rabbit called Crempog (Welsh for pancake), he’s a dwarf-harlequin rabbit and spends his day roaming the house (eating EVERYTHING) and at night he stay’s in this cage:

“Daddy, I don’t give you permission to use my image”. “Silly Crempog, rabbits can’t speak”

As his cage is fairly expensive and takes up a lot of space I will want to capture its information, but I was unsure how much model detail I really need?  So, as usual, I asked Twitter:

With Twitter unsure, I decided to take matters into my own hands and produce a few objects.  Shown here are three different objects that I have created for Crempog’s cage. Each has the same Level of Information Detail, but a different Level of Model Detail.

 Cage2  Cage3  Cage4
LOD: 2 LOD: 3 LOD:  4/5
Time Taken: 1 minute Time Taken:  5 minutes Time Taken:  20 minutes
File Size:  280kb File Size:  340kb File Size:  1104kb

Note:  As there is no Level of Model Detail definition for Animal Housing (Pr_40_30_04, in Uniclass 2015), an assumption was made by comparing pre-defined LOD4’s from Structural Decking where voids are included; and Expansions joints where elements under 10mm are included as justification for modeling the cage bars.  

As you can see by increasing the level of graphical detail it takes longer to produce the objects and the file’s get larger too.  Meaning that any detail above what is required can be seen as overproduction (a waste of effort!); it is important to consider how the cage’s object will be used and seen (remember, visualization was not identified as a Model Purpose).

Typically, models are produced to a scale of around 1:50; a balance between performance, resource, and use; matching the coordination view outlined within BS 8541-3.  Objects within graphical models are normally used to create other deliverables such as drawings.  If you want to create a detailed view (for example, a roof abutment detail) it is much more resource and memory efficient to overlay details over generic model elements instead of modelling every tile, batten, and brick.

For my house, the rabbit cage would only appear on a floor plan drawing, which I expect to be at 1:50 to fit both the ground and first floors on a single A3 sheet.  At 1:50 the cage would have bars at 0.06mm spaced at around 0.5mm.  Plot lines go as fine as 0.18mm meaning my cage would basically look like one big black blob.

And there you have it. By working through an example I have decided that I need my Level of Information to be at LOI6 so that operation and maintenance information is captured to suit my Model Purposes, and I need my Level of Model Detail to be no more detailed than LOD3 to ensure that I only model what I need to show.

This means that I have now answered another Plain Language Question; PLQ1.5 Complete!

1.1 Have the modle purposes been defined?
1.2 Are there any specific data requirements to achieve these purposes?
1.3 What format shall the information be delivered in?
1.4 What standards will be followed?
1.5 What level of accuracy/detail/development is required?
1.6 Is there sufficient information to produce an EIR?

Now that I know my required Level of Definition, I need to establish if I have enough information to create my Employer’s Information Requirements to satisfy PLQ1.5…