Welcome to ‘Is It Smart?’, the blog series where I have a look at the smart technology installed within Ty Crempogto 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?
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!
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 myNest Thermostat, myGoogle Homeis one of the few items I manage within its warranty period.
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“.
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.
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?
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 myAndrex Buttonto 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.
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 ThermostatI 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-1naming 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 Buttonis 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.
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.
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).
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.
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?
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?
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?
Under the Industry Foundation Class (IFC) Schema, a thermostat isn’t included (it doesn’t appear untilIFC4) 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.
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.
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.
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 @TyCrempogwhen it is too hot or too cold.
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 Thermostatcould take advantage of including: Facility Name, Space Name, Area, & Volume and perhaps even external object thermal transmittance.
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 Thermostathas 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?
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!
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 PlanspecifiedBS 8541 standards:
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.
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.
Levels of Detail Provided
Coarse, Medium, and Fine
Coarse, Medium, and Fine
Coarse, Medium, and Fine
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?
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.
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.
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.
This means that once again the NBLboiler leads with its impressive use of CamelCase, with BIM Store second, and BIM Object third.
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.
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 ontwitter, or commenting below.
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
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:
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:
Phew, Monay's blog is written; so let's have a quick poll. What Level of Model Detail should I make my Rabbit Cage?
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.
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.
Brief: 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?