Back2Work goes IoT — Technical details on how we implement our digital tracer

As we have explained in our article Back2Work goes IoT - Digital tracing of chains of infection , we have looked into the possibilities of tracing chains of infection to make a partial return to the offices possible. As we do not use classic time and attendance recording, we wanted an easy to use solution — that is not a time recording system.

The Back2Work-App, which is provided by SYCOR GmbH as open-source, forms a good basis for us. In order to keep the hurdle of the CheckIn as low as possible and also to pursue pragmatic solutions when changing floors, we have developed an even simpler solution to record the presence in a certain area, e.g. a floor, with little effort. As with most systems on the market, our tokens for door opening have an additional 125 kHz RFID chip that provides a unique ID. We have developed a scanner that reads this identifier and checks the assigned user in the Back2Work app.

The scanning process results in a CheckIn on the respective floor. Scanning on another floor automatically performs a CheckOut on the original floor and a Checkin at the new location. Scanning again on the floor where you are already checked in updates a LastSeen timestamp. So we can deliberately do without a CheckOut. The users are checked out in the evening on a batch basis.

We would like to show how such a simple IoT setup can be set up. We provide the necessary source code on GitHub. It is obvious that this simple setup does not necessarily meet the requirements for a rollout on a large campus. We are happy to support the implementation of more complex scenarios.

Basic setup and shopping list

The RFID scanner is implemented by an Olimex ESP32 board with a connected RFID reader. A LED indicates the status of the device, the power supply is implemented via PoE.

The device waits for the chip to be scanned. The readout unique ID and the ID of the scanner (we use the MAC address as ID) are transferred via REST web service call to a Microsoft PowerAutomate job, which then maps the actual check-in logic.

For the scanner are required:

• Olimex ESP32-PoE-ISO
• RFID scanner (e.g. RFID Reader ID-12LA (125 kHz))
• If necessary, a suitable Breakout Board (here: SparkFun RFID Reader Breakout)
• RGB LED (here: SparkFun COM-11120)
• Housing (3D printing)

The hardware costs per device are about 60€.

The cabling is implemented as follows:

Arduino Firmware

We use the ESP32 Arduino framework on the Olimex board. Three essential functionalities are implemented in the firmware. After the network connection is established, we check for over-the-air updates. The LED and the RFID reader are initialized and in the loop, the system waits for the scanning of an RFID chip. The scanning is confirmed by LED signaling and a JSON with the read unique ID of the chip, the Mac address of the board, and the current timestamp is sent to the HTTP address of the PowerAutomate job.

The 12 bytes of the unique ID are read with ESPSerial2.read(). The reader encapsulates the ID in 0x02 (Start of Text) and 0x03 (End of Text) and concludes with 0x0D 0x0A (Carriage Return + Line Feed (\r\n)).

The ESP32 has two cores, therefore the standby LED animation is executed as a task on the second core for simplicity.

CheckIn User

The logic of the CheckIn is shown in the following PowerAutomate Flow. Just like the PowerApp, PowerAutomate is a LowCode tool, which makes it easy to adapt the process logic without extensive programming knowledge.

Please note that the PowerAutomate version included in Office365 has an API limit of 2000 API calls per user per day. If this limit is exceeded, a separate PowerApps plan must be purchased, or the code is converted to a LogicApp, which is billed per API call via the Azure subscription.

The logic is easy to set up and looks as follows:

The app is triggered by a web service call (URL is generated the first time it is saved). A JSON file with the following schema is expected as payload:

The RFID ID is converted into a mail address via the SharePoint list btw_token. In the btw_token list, the mapping of unique token ID to the user’s mail address is converted.

The Mac address of the scanner is converted to the SpaceId via the SharePoint list btw_space:

It is checked whether the user has already checked in. The e-mail address is used for identification:

The SharePoint list btw_locationTrack is updated depending on the initial situation. It is checked whether an active CheckIn exists. If this is not the case, the user is checked in by creating an entry in the SharePoint list btw_locationTrack. If the user is already checked in in the same “space”, only the LastSeen timestamp is updated. If it is a new location where the user scans his token, a checkout (setting the timestamp in the CheckOut field) and a new CheckIn with the new space ID is performed:

Automatic CheckOut & Housekeeping

There is another simple flow that checks out all users and deletes the records that are older than 60 days. This flow is started every evening:

UserMapping

Ideally, the linking of unique IDs and e-mail addresses already exists in a system, so that this data can simply be transferred to the btw_token list.

We have implemented the setup for the mapping so that there is a scanner and a thermal printer at a central location. When the RFID chip is scanned, a QR code and the unique ID of the chip is printed out. The QR code leads to a completed Google Forms form, which the logged-in user confirms. Google Forms writes the mapping to a Google Sheet, which in turn calls a PowerAutomate web service to update the SharePoint list. Here you can surely find an individual solution for each specific setup.