Introduction: IDC2018IOT: Meeting Room Snitcher

THE PROBLEM

As we know, the trend of co-working spaces has been accelerating over the past few years, along with cutting-edge technology defining the choice of the specific co-working space that fits for your needs.

One of the main features offered is shared meeting rooms offered to the co-working space members', which is managed by a (usually) simple calendar platform.

A problem reoccurs as people schedule tends to be dynamic.

One might book a room thinking he might need it and wouldn't want to miss the time slot.

Even if one wouldn't use that time slot eventually, he won’t bother to notify and cancel it for the sake of others, as, unfortunately, that’s human nature.

HOW DO WE SOLVE IT?

Using IoT technology - checking sound and movement in a designated meeting room, we are checking, every certain time interval, whether a room is booked and actually occupied or not:

1. If it is not booked, do nothing.

2. If it is booked, check if there are any movement or sound detected;

> If there is, do nothing.

> If nothing was detected, send a warning message (via email) to the user who booked the room that asks if the room is still in use. unless the user will declare he is still using the room, the room status will be changed to “Available”.

* Here, we integrated our project with Google Calendar in order to generalize it as much as possible.

Step 1: Hardware and Protocols Needed

1. We used NOSEMCU so we could update things dynamically using the WIFI connection.

2. Microphone sensor that will "read" the noise in the room.

3. PIR sensor that will check if there is any movement.

For software and server use, besides the code in Arduino, we used Google Script and Zapier to support our system online. You can see the flow in the added picture (and PDF).

We used Zapier to connect apps and automate our workflows (like IFTTT) and we used Google Script to help us communicate with the Google Calendar. The script we wrote is producing the event creator's email so we could send it threw Zapier and checks if the user asked to hold the room (by saving some info in Google Sheets) before deleting the event.

Attachments

Step 2: Connect the Microphone and the PIR Sensor

We wanted to check the average values the microphone posts to the NODEMCU when people are talking (clearly, in every room had different background noises). We did some testing and realized that the average noise level is the room we worked in is somewhere above 50.

The PIR sensor only gives HIGH or LOW values so we only checked the level of sensitivity that is the most accurate to the room we checked. This guide was pretty helpful.

OUR CONNECTIONS:

Microphone - like in the picture
PIR sensor: GND > GND, OUT > D7, VCC > VN (5V)

Step 3: Create the Workflow in Zapier

In order to know whether the room is actually empty or still in use (and the users are on a break for example), we would like to create a flow that assures it, right after the NodeMCU fires a Webhook to Zapier which notify that the room is empty:

(1) TRIGGER - CATCH HOOK
Zapier catches the Webhook (that will be sent by the NODEMCU)

(2) ACTION - GET
Zapier sends another Webhook to get the event data;
> It calls (runs) a GoogleScript - 
GetCurrentEmailEventID (explanation in the following step), to get the current event data - event name, event ID, user email.

(3) FILTER - ONLY CONTINUE IF

Continue to the next step only if there is an event (any event) currently happening on the calendar (ROOM IS BUSY), otherwise, stops as the room is vacant.

(4) ACTION - GMAIL
Zapier sends an e-mail, through Gmail, to the user who booked the room (got this information in step 2)

(5) ACTION - DELAY FOR
Let the user time to reply to the email.
- If the user clicks on the link: call (run) the GoogleScript - 
ApproveCurrentEvent
(Hence The room is removed from the 'Rooms to delete' list, and the room is still marked as occupied.)

(6) ACTION - GET
After 5 minutes, Zapier calls (runs) GoogleScript - 
DeleteCurrentEvent
- If the user didn't click on the link

> Checks if the room ID is in the list 'Rooms to delete'

> it just removes the event.

Step 4: Google Scripts

As we integrated the whole system, GoogleScripts was the trivial choice of an IDE, Thus, we used relevant Google Libraries. Would change according to the Room Booking Platform.

(1) GetCurrentEmailEventID

Runs by a Webhook call.

Using a certain offset in order to eliminate possible miss-cancelation, getting the current event data.

(2) ApproveCurrentEvent

Runs by a user click.

In case of a user's approval that the room is still in use, deletes the event ID out of the 'Rooms to delete'. We used a Google sheet, any other form of a list could be relevant here.

(3) 
DeleteCurrentEvent

Runs by a Webhook call.

Searches for the relevant event ID in the list (Google sheet) and deletes that event from the calender.

Attachments

Step 5: Connect the Flow With the Arduino Code

The attached code connects to the sensors we checked a few steps ago to the online system (Google calendar in our case). It checks if the room is busy and then if it is not, it sends an HTTP request (a Webhook) that starts the deleting event request on Zapier.

Attachments

Step 6: Review, Conclusions and Future Scaling

The main challenge we had to deal with is cover all the edge cases when deciding to free a meeting room. We then had to create a state machine considering every possible case, such that an error will not occur and the room will be set as available only when it should.

For example, if the room is booked for some group that is currently not there (that is on a break, for example), but still needs it, NODEMCU will detect that the room is free > PROBLEM.

Then, our solution was to email the user who booked the room (which wasn't simple to figure out) a messege which provides the option to keep holding the room.

If the user did not reply in a given time (we set it to be 5 minutes, but it can be changed easily), we delete the event from the calendar (and free the room).

That way, we eventually succeeded to handle all possible scenarios and create a working system.


OUR SYSTEM LIMITATIONS:

1. The used sensors have to be very accurate & sensitive.

2. The room size is limited to the sensor's radius/range.

3. We will have to rely on the user responsiveness.

4. Our system is built using several platforms (Google calendar, Gmail, Zapier etc.) and will have to use their service to perform.

5. Scaling this service for multiple rooms (instead of duplication the whole system) will require an additional handling with room ID.

6. The system is only automatic and there isn't a manual option for canceling a room booking.


FUTURE DEVELOPMENTS:

We would definitely scale up the system in two ways:

1. Ability to work with any other calendar platforms (so any co-working spaces company could use it).

2. Ability to handle multiple rooms, floors, and sites.

We believe that this kind of scale will take 2-3 months to generalize, test and to add multiple rooms (floors etc.) feature.

In addition, using an unlimited amount of money and resources we would use better sensors with a larger range, along with customizing them to the designated room – considering range, radius, amount of sensors etc. A step that would make each system installing longer, obviously.