Roundup of the Best Workplace Trends Blogs

Blogs are a great way to keep up with the fast changing developments in workspaces.

Blogs are a great way to keep up with the fast changing developments in workspaces. From sensors and software to IoT to real estate, here is a round-up of are some of our current favorite blogs:

Workplace Insight Workplace Insight is a great source of news and information about the design and management of workplaces. Mark Eltringham and his team offer interesting insights into workplace design and management issues.

Memoori Memoori provides thought provoking information and insights on smart buildings.

Dwell Magazine We love this stylish and innovative Magazine, the Workplace & Office section is a special favorite.

Here are a couple of favorite IoT and Smart Building blogs that keep us informed on the latest technology and innovation trends too;

Have a blog you think we should include? Let us know, we’d love to check it out!

The Good Sensor

“What sensors shall I use to understand my space usage?”

On a daily basis our customers and community ask us to recommend a sensor provider to buy from, you should ping me on if you want us to recommend your sensor. Often the requirement is vague, “I need an air quality sensor to put on my street for $100?” or “What sensors shall I use to understand my space usage?”. My process of assessment has grown more refined over time because if the sensors we recommend are unsuitable or unusable our company’s reputation is also on the line by association.

So we have come up with our own unscientific way to rate the quality of a sensor that should be applied simply. Most large scale sensor rollout projects of 1K or more often have these requirements as well. It’s possible that sensor providers that don’t rate highly using our criteria produce good sensors but getting the below right takes iteration and discipline in design and the likelihood is that the provider will a higher chance of being able to deliver.

Battery life If a sensor is battery powered, the typical expected life of battery should be clearly stated. Buyers will often want some explanation of what typical means for your sensor i.e. if it’s a PIR sensor have you calculated battery life based on being triggered once a day? The last thing your customers wants to do is invest in a lot of sensors, plus the cost of installation in order to find out that the battery life is only % of what they expected as it will still cost them a lot of money to rip them out and return them.

Bonus point for sensors that publish their battery status as standard so that the sensor owners can have some warning before changing.


Sensors should tell people whether they are still alive or not periodically. Depending on your battery and connectivity constraints, this can vary, the important thing is that the buyer should not find out a bunch of devices are not working because they haven’t been heard from in days or weeks. Top tip; Heartbeats every 10-60 minutes when possible is sufficient, anymore and it ceases to be informative.

Installation and maintenance procedure

In non consumer environments, the people installing and maintaining sensors are often not the technical design firms or manufacturers. Does your device clearly tell people how to install it, do you have helper applications so that they don’t have to configure firmware? We are working on some solutions for this but more on this later; hint it’s all about enabling people to install sensors efficiently and a non technical installer being able to walk away knowing that the device has joined the network correctly. Does your sensor come with mounting and fittings?

Do people have to unscrew the casing to change batteries? Have you tested this with people and verified it?

 Data Quality

Quality in my definition means, is the data from your sensor easily understandable for someone that doesn’t know your domain. The reality is that often manufacturers pass on the analogue value of the particular sensor and that is too low of an abstraction for most people trying to read it. Battery voltage is a good example, during its life an AA battery will go from 1.5v to about 0.8v, but it follows a curve specific to the device and the battery. Understanding how this maps to a percentage or days of life is often complex. If it’s not possible to do much conversions or processing on your sensor or gateway, perhaps a handy explainer when people buy your device making them understand what the data means.


Please state clear terms for warranties and return procedures to protect your consumers. Consumer protection should naturally apply.

Finally developing high quality hardware is hard, I am always amazed at the skill and dedication it takes when hardware designers and engineers take an idea and get it to manufacturing stage. We try to manage the community’s expectations on sensors they should buy vs the attitude of ‘just throw around cheap sensors’. It would be better in terms of environmental sustainability and user experience to get into the habit of doing more with less sensor density. For more on this, see Dr Boris Adryan’s excellent blog post

I have purposefully not mentioned security in this post as security assessments come with a lot of complexity, will aim to write up on this sometime soon.

Many Thanks to Toby Jaffey for editing.

Path to Smart Buildings

Space planner or architect? We have broken down the steps to get you to your desired end goal maximising efficiency and cost within buildings

Whether you are a building manager planning efficient space usage or an architect looking to design state-of-the-art buildings, we have broken down the steps to get you to your desired end goal. IoT planning should start with the business needs, of course, and quickly moves from the component layer all the way up to the application layer. We need to figure out what core data should be gathered and ways to effectively leverage that data. These IoT solutions require an end-to-end or device-to-cloud view.

A Phased implementation approach works best.

We have found that the most successful IoT projects follow a phased implementation approach: Design Phase, Proof of Concept, Pilot, and Deployment. The design phase asks questions such as which sensors, who will be installing and maintaining the sensors. For Proof of Concept, a lab evaluation should include hooking up 5-8 sensors all the way through a gateway to data collection in the cloud. This will give enough real data to verify that the queries and the analytics are feasible. The Pilot Phase ensures that the sensors work at scale and that the gateway configuration has been made easy for the deployment specialists. A pilot phase should be about 40 sensors depending on the density of the sensors. At this point, you can scale up to the number of sensors and the bandwidth required for full deployment.

OpenSensors’ Deployments

We have built hardware, installation and network provider partnerships and relationships to help customers get rollouts live efficiently. Either roll out your own network or we will put you in touch with your local sensor installation specialist to take care of the install and maintenance. We are working with customers and the community to understand what is required at each level for your IoT solution and can ease development and integration issues.

Getting to Grips With IoT Network Technologies

There are many different ways to connect your sensors to the web, but how to know which are best for your project?

How sensors communicate with the internet is a fundamental consideration when conceiving of a connected project. There are many different ways to connect your sensors to the web, but how to know which are best for your project?

Having just spent the better part of a week researching these new network technologies, this brief guide outlines the key aspects to focus on for an optimal IoT deployment:

Advanced radio technology

  • Deep indoor performance – networks utilising sub-GHz ISM (industrial-scientific-medical) frequency bands such as LoRaWAN, NWave and Sigfox are able to penetrate the core of large structures and even subsurface deployments.
  • Location aware networking – a variety of networks are able to track remote sensors even without the use of embedded GPS modules. Supporting sensors moving between hubs – with advanced handoff procedures and innovative network topologies mobile sensors can move around an area and remain in contact with core infrastructure without disrupting data transmission. Intelligent node handoff is also crucial for reducing packet loss, if the connection to one hub is hampered by passing through particularly chatty radiowaves, the node can switch to a better placed hub to relay it’s crucial payload.
  • Interference resistance – the capability of a network to cleave through radio traffic and interference that would ordinarily risk data loss.

Low energy profiling

  • Device modes – LoRaWAN is a great case and point with three classes of edge node: the first, Class A, allows a brief downlink window after each uplink upload i.e after having sent a message, the sensor listens in for new instructions; a Class A node appoints a scheduled downlink slot, the device checks in at a certain point; and the last, Class C type nodes, listen for downlink messages from LoRaWAN hubs at all times. The latter burns considerably more power.
  • Asynchronous communication – this enables sensors to communicate data in dribs and drabs where possible, services do not need to wait for eachother thereby reducing power consumption.
  • Adaptive data rates (ADR) – depending on the quality of signal and attenuation, modern networks are able to dynamically allocate data rate depending on interference, distance to hub etc. This delivers real scalability benefits, frees up space on the radio spectrum (spectrum optimisation) and improves overall network reliability.


  • Authentication – maintains data integrity by ensuring the sensor which is publishing that mission critical data really is that sensor and not an impostor node. Ensures information privacy.
  • End to end encryption (E2E) – prevents tampering and maintains system integrity.
  • Integrated security – good network security avoids potential breaches and doesn’t place the onus on costly, heavily encrypted message payloads.
  • Secure management of security keys – either written remotely on the initial install or embedded at manufacture, security keys are fundamental to system security. ZigBee’s recent security issue shows how not to manage security keys, by sending them unencrypted over-the-air to devices on an initial install.
  • Receipt acknowledgement – ensures mission critical data is confirmed received by network or device.

Advanced network design

  • Full bidirectional comms – enables over the air (OTA) updates, enabling operators to push new firmware or system updates to thousands of remotely deployed sparse sensors at the push of a button. This is critical to a dynamic and responsive network. As with device modes mentioned previously, bidirectionality allows deployed devices to function as actuators and take action (close a gate, set off a fire alarm etc) rather than just one-way sensors publishing to a server.
  • Embedded scalability and consistent QoS – as load increases on a network so too does the capacity of the network. This takes the form of adaptive data rates, prevention of packet loss by interference and channel-blocking, the ability to deploy over-the-air updates and ensuring the capability to add nodes, hubs and maintain existing assets without impacting on overall network service, perhaps through automatic adaptation.

There are also a number of legal, cost, market and power focused aspects worth considering that I shall not cover here. But, critically, it’s worth mentioning that the majority of these technologies operate on ISM (industrial – scientific – medical) frequency bands, and as a result are unlicensed. These bands are regulated and there are rules, however anyone operating on these bands can do so without purchasing a license. Notably, you don’t have sole ownership of a slice of the spectrum, you don’t get exclusive access. Therefore, with a variety of other vendors blasting away across the radio waves, these technologies encounter significantly more interference than the licensed spectrum. However, the new networks, LoRa, Sigfox, NWave etc are based on protocols and technologies designed to better sort through this noisy environment, grab a channel and send a message.

Understanding that the airwaves are a chaotic mess underlines the importance placed on features such as adaptive data rates, node handoff and power saving methods such as asynchronous communication. Wired networks do not have to consider such things. But for most it’s not just a case of who shouts loudest wins. The majority of wireless protocols ‘play nice’ opting for a polite “listen, then talk” approach, waiting for a free slot in the airwaves before sending their message.

Some protocols such as Sigfox forego such niceties and adopt a shout loud, shout longer approach, broadcasting without listening. A typical LoRaWAN payload takes a fraction of a second to transmit, Sigfox by comparison sends messages 3-4 seconds in length. However, if you just broadcast without listening, Sigfox must therefore operate with severe cycle duty limitations, which translate into a limited number of messages sent per device per day and severe data rate limitations.

These choices also translate into varying costs, and critically, into battery life limitations and gains, the crux of any remote deployment.

See this link for a matrix of the major technologies currently vying for network domination.

What Is LoRaWAN?

Confused about why it’s better than Zigbee? Let us help…

What is LoRaWAN and why is it “better” than Zigbee?

Even long-time IoT enthusiasts struggle with the wealth of technologies that are on offer these days. One of the most confusing phenomena for someone who isn’t a RF engineer is the scale and range of LoRaWAN. If you’ve been in the game for a while, you may have used a ZigBee radio module for wireless data transmission in your own projects. ZigBee-compliant modules had become a gold standard for many industrial applications in the 2000s, featuring >10m range (it was said to be 100m, but that was hardly ever achieved), up to hundreds of kbit/second transfer rate (depending on the model and radio band used) and message encryption by default. Over most cheap proprietary RFM22 transceivers, ZigBee also offered an industry standard following the IEEE 802.15.4 specification for mesh networking. This allowed ZigBee devices to forward messages from one to another, extending the effective range of the network. Despite their rich features, ZigBee devices are limited in range and limiting when it comes to their power consumption and the potential use in IoT application. And this is where LoRaWAN comes into play: It’s a Low-Power Wide Area Network (LPWAN) standard promising a reach of tens of kilometres for line-of-sight connections and aiming to provide battery lives of up to ten years. How can this work?

First, let’s contrast short-range radio standards like the ZigBee with the LPWAN standards like LoRaWAN. RFM22, ZigBee and LPWAN all use radio frequencies in the ultra high frequency (UHF) range. Following the ITU 9 classification, these are devices that use a carrier frequency of 300 MHz to 3 GHz. That is, the radio waves have a peak-to-peak distance of 10-100 cm — a tiny proportion of the electromagnetic spectrum. Here, we find television broadcasts, mobile phone communication, 2.4 GHz WiFi, Bluetooth, and various proprietary radio standards. We all know that television broadcasting transmitters have a significant range, but clearly that’s because they can pack some punch behind the signal. There must be another reason that LoRaWAN does better than the other radio standards. The carrier frequency itself can therefore not explain the range of LPWAN standards.

There is all sorts of hardware trickery that can be applied to radio signals. Rather than allowing those electromagnetic waves orientate randomly on their way to the receiver, various polarisation strategies can increase range. A circular-polarised wave that drills itself forward can often more easily penetrate obstacles, whereas linear-polarised signals stay in one plane when progressing towards the receiver, concentrating the signal rather than dispersing it in different directions of the beam. However, these methods require effort and preparation on both the sender and receiver side, and wouldn’t really lend themselves to IoT field deployment…

The secret sauce of LPWAN is the modulation of the signal. Modulation describes how information is encoded in a signal. From radio broadcasting stations you may remember ‘AM’ or ‘FM’, amplitude or frequency modulation. That’s how the carrier signal is changed in order to express certain sounds. AM/FM are analog modulation techniques and digital modulation interprets changes like phase shifts in the signal as binary toggle. LPWAN standards are using a third set of methods, spectrum modulation, all of which get away with very low, noisy input signals. So as the key function of LPWAN chipsets is the demodulation and interpretation of very faint signals, one could think of a LoRaWAN radio as a pimped ZigBee module. That’s crazy, isn’t it? To understand a little more in detail how one of the LPWAN standards works, in the following we are going to focus on LoRaWAN as it is really ‘the network of the people’ and because The Things Network -a world-wide movement of idealists who install and run LoRaWAN gateways- supports our idea of open data.

LoRaWAN uses a modulation method called Chirp Spread Spectrum (CSS). Spread spectrum methods contrast narrow band radio as ‘they do not put all of their eggs into the same basket’. Consider a radio station that transmits its frequency-modulated programme with high power at one particular frequency, e.g. 89.9 MHz (the carrier is 89.9 MHz with modulations of about 50 kHz to encode the music). If you get to receive that signal, that’s good, but if there is a concurrent station sending their programme over the same frequency, your favourite station may get jammed. With spread spectrum, the message gets sent over a wide frequency range, but even if that signal is just above background noise, it is difficult to deliberately or accidentally destroy the message in its entirety. The ‘chirp’ refers to a particular technique that continuously increases or decreases the frequency while a particular payload is being sent.

The enormous sensitivity and therefore reach of LoRaWAN end devices and gateways has a price: throughput. While the effective range of LoRaWAN is significantly higher than ZigBee, the transmitted data rate of 0.25 to 12.5 kbit/s (depending on the local frequency standard and so-called spreading factor) is a minute fraction of it – but, hey, your connected dishwasher doesn’t have to watch Netflix, and a payload of 11-242 bytes (again, depending on your local frequency standard etc) is ample for occasional status updates. Here is where the so-called spreading factor comes into play. If your signal-to-noise ratio is great (close proximity, no concurrent signals, etc), you can send your ‘chirp’ within a small frequency range. If you need to compensate for a bad signal-to-noise ratio, it’s better to stretch that ‘chirp’ over a larger range of frequencies. However, that requires smaller payloads per ‘chirp’ and a drop in data rate.

Power consumption, reach and throughput are all linked. To burst out a narrow transmission consumes more power than to emit a spread signal. Hence, LoRaWAN implements an adaptable data rate that can take into account the signal-to-noise ratio as well as the power status of a device.

The Path to Smart Buildings

The need for good, informed design within buildings

Google ‘principles of good architectural design’ and you’ll get links to technology, to buildings and all manner of other services. But it’s hard to find principles of design for the tech services that facilitate smart buildings. Let’s remind ourselves what a smart building is with the help of sustainable tech forum; ‘The simple answer is that there’s automation involved somehow that makes managing and operating buildings more efficient’. So the need is well documented but we want to bridge to the ‘practice of designing and constructing buildings’, after all that’s what architecture is about.

OpenSensors hosted its first Smart Building Exchange (SBeX) event in September, and we are grateful to the panelists and attendees who made it such a success. Our goal was to bridge the gap between widely documented features of smart buildings and the tech that underpins it. Through our workshops we decomposed tenant needs and identified services to support them using the value proposition canvas. We borrow from lean product design principles since building operators need to rapidly innovate using processes inherited from startups. Mapping the pains and gains of users to the features and products of the tech stack revealed a common theme, data infrastructure. Data is the new commodity that new services will be built upon, some will be open and others private, but data will be the currency of the next generation smart building.

Take integrated facilities management (IFM) where data serves the desire to deliver better UX at a lower cost with fewer outages. IFM has pivoted from a set of siloed software services to a set of application services overlaid upon a horizontal data infrastructure. For example:

  • Data science services will develop to identify ‘rogue’ devices operating outside expected patterns, they will identify assets that need inspection or replacement and schedule maintenance works using time and cost optimisation routines.
  • Digital concierge services will use personal devices, location based technology and corporate data (calendar and HR data) to optimise both user experience and spacial allocation.

So can we identify a tech architecture to support this pivot from monolithic apps? Data services facilitated by a central messaging backbone allows the complexity of building services to be broken down and tackled one service at a time, lowering the risk failure and allowing agile iterations at a reduced cost. Take the pillars of data driven applications for IFM as identified by our workshop group; predictive/reactive alerting and tactical/strategic reporting, how might we go about servicing these needs? Consider how the path to smart buildings outlined below could help build an IFM product.

  • Build the value proposition founded on a clear vision of what your users want.
  • Identify the data that will drive your smart building product including open data
  • Identify the sensors needed to gather your data, they could be mobile devices or occupancy sensors
  • Identify connectivity from the sensor to your data infrastructure, this might be radio to IP connected gateways or directly onto the local network via POE (power over ethernet)
  • Structure your message payloads and commit to schemas to deliver repeatable processes for message parsing and routing within your building
  • Configure your events turning your data into information using rules based platforms for IoT such as node red
  • Build widgets and data services that can be bound together for dashboarding. By identifying common user needs across the enterprise we can operate a leaner system stack
  • Build user portals and dashboards using your common data services and components
  • Validate tenant user experience through surveys and modelling tenant behaviour using occupancy devices
  • Iterate to improve using data gathered throughout the building to deliver better products and experiences

OpenSensors has firmly backed Open Source and Open Data as the best way to yield value from the Internet of Things choosing to collaborate with the tech community to enable facilities managers to build higher order systems focused on their domain expertise. Please contact should you have a need for a smart building workshop or are ready to build your next generation smart building product.

European Parliament Approves eCall Technology

The Internet of Things threatens to revolutionise everyday life

European Parliament approves eCall connected car platform

The Internet of Things threatens to revolutionise everyday life, embedding and imbuing everyday objects and the world around us with sensors, software and electronics. Through machine-to-machine communication, automation and advanced analytics, we are able to understand and scrutinise our environment and the processes which surround us in ways never conceived. From high level analysis allowing automated condition monitoring of critical engine parts, giving engineers the tools to reduce costly operational downtime to embedding real-time sensors in bridges to predict stresses and flooding. Beyond the Cloud, the Internet of Things brings the internet to the everyday, and there are clear use cases for such technologies in the realm of road safety.

This is where eCall comes in. eCall is a European Commission initiative coming into force on 31 March 2018, making mandatory the deployment of internet-connected sensors into cars that enable emergency services to be immediately contacted and requested automatically after a serious road incident within the European Union. EC VP for Digital, Neelie Kroes, argues “EU-wide eCall is a big step forward for road safety. When you need emergency support it’s much better to be connected than to be alone.” eCall will drastically cut European emergency service response times, even in cases where passengers are unable to speak through injury, by sending a Minimum Set of Data (MSD), including the exact location of the crash site.

The deployment of eCall is one of most ambitious EU-wide programs since the 2007 enlargement, rolling out implementation of the eCall platform to some 230 million cars and 33 million trucks in the European Union. Implementation of eCall at a European level (including Norway, Switzerland etc) however benefits consumers and industry through reducing costs due to economies of scale, reducing the installation cost to as little as €100. The basic pan-European eCall service will be free at the point of use for equipped vehicles. It is likely that the eCall technology platform (i.e., positioning, processing and communication modules) will be exploited commercially too, for stolen vehicle tracking, dynamic insurance schemes, eTolling and emerging forms of vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) road safety systems. eCall will be based upon a standardised platform, one system for the entirety of Europe, aimed at enabling both car and telecoms industries a quick roll out and to avoid crippling OEM versioning and patching issues.

In terms of privacy, the basic eCall system has been given the green light by the European Commission on the express condition that firm data protection safeguards are in place and that the sensor-equipped vehicles will not push data to external servers except in the case of a crash, or by the actions of the driver, in order to contact the PSAP (Public Safety Answering Point) and will lie dormant until that point. The data transmitted to the emergency services, described as MSD, Minimum Set of Data, are those strictly needed by the emergency services to handle the emergency situation. While in normal operation mode the system is not registered to any telecoms network and no mediating parties have access to the MSD that is transmitted to the PSAPs.

Today the European Parliament’s Internal Market and Consumer Protection Committee MEPs voted on and approved eCall pushing forward a life-saving Internet of Things technology that will significantly improve European road safety. The UK Government however, has not followed suit, whilst welcoming the implementation in other member states, feels that “it is not cost-effective … given the increasing responsiveness of our road network, we feel that smart motorways do the same thing,” remarked Minister Perry on behalf of the Department of Transport. Whilst it can be argued that ‘Smart Motorways’ are far from a worthy substitute to connected cars & V2V/V2I systems, the UK’s criticism belies a certain caution with regards to green-lighting large and costly IT projects. Only time will tell whether the UK Govt’s decision has left those drivers not on Britain’s Smart Motorways in the lurch.