Q1: Which AI tools?

Out of 16 respondents, 14 students (88%) indicated using AI tools during the course; only 2 did not. Most (13 students, 81%) used chatbots. Additionally, 3 used IDE extensions such as GitHub Copilot and 1 used an AI-powered IDE like Cursor. (They could select multiple options.)

No one reported using a coding agent. This is probably due to their recency: Claude Code was released only in February 2025 (and is paid) and Gemini CLI in June (for free); while students worked on their projects between March and June 2025.

We can conclude AI is commonplace, especially chatbots. Newer tools like coding agents are still unpopular. It’ll be interesting to see how this evolves in the next few years.

Q2: For which tasks?

Students reported using AI tools for a variety of tasks:

• 9 students (56%) asked ChatGPT questions during exercise sessions. I also observed this in class. This is honestly a bizarre experience as a teacher: students use ChatGPT even though I’m right there. Some students seem to prefer asking their questions to a chatbot over a human being (fear of being judged?). Overall, my experience is that AI chatbots are remarkably effective at spotting and explaining mistakes, and can be very conducive to the learning process.
• 6 students (38%) used AI to code during the exercises. I saw several students with GitHub Copilot enabled in their IDE. This is something we’ll have to figure out: if the goal of an exercise is to practice, should you use a tool that gives you the answer immediately? Students may simply have the Copilot extension enabled by default in their VSCode, so we’ll need to explicitly ask them to disable it.
• 8 students (50%) used AI for questions during their work on programming projects, 3 (19%) used it for coding projects, and 4 (25%) for writing reports. My view on this is nuanced: using AI as a companion for brainstorming, debugging, or gaining a deeper understanding can be very educational. However, delegating core parts of the projects to AI means you are no longer learning. Similarly, using AI to improve or spell-check reports is fine, but of course students should remain in control of and responsible for what they write.
• Finally, a surprising 10 students (62%) asked chatbots to further explain concepts from theory lectures. This seems like an excellent use of AI, although I wonder how high the risk of hallucinations is. (And, it makes me wonder what I should improve!)

In an open question on their experience with AI, many students said it gave them a productivity boost, e.g. for debugging, generating test code and data, writing repetitive code. They were also well aware of its limitations: hallucinations, inconsistencies, and a need to guide the AI. Some mentioned that it had replaced Google or Stack Overflow for them. They indicated it helped them to understand some topics better, but they also emphasized that it remains important to understand and master the material yourself.

Q3: Payment

4 students (25%) said they paid for AI tools. This is concerning: we don’t want a situation where students who can afford (better) AI tools end up getting a better education or higher grades. This is certainly something to pay attention to in the future.

Policy on AI use

Last year, we didn’t yet have a specific policy on the use of AI tools; only our standard policy on plagiarism and an oral defense that checks students’ work and understanding. AI tools were in a gray zone. Next year, we’ll introduce a clear policy, but this will be a tricky balancing act. Student opinions varied widely (paraphrased):
“It should be prohibited, otherwise we don’t learn.”
“It should be allowed only for reports, not for code.”
“It should be allowed, because in the workplace it will also be there.”
“It’s impossible to detect, so there’s no point in prohibiting it anyway.”

Remarks and disclaimers

Out of 43 students registered for the course, only 16 completed the survey. In my experience, it’s usually the more ‘motivated’ students who fill in surveys, which skews results. In the open questions, many provided long and thoughtful answers, suggesting that this topic is on their minds as well. The survey was labelled as anonymous to encorage honest answers. Finally, this is an elective Master’s course, with students who already know how to program well. For a first-year Bachelor course, my policy would be different than for an advanced course in the Master.

💬 Comment on this post on LinkedIn

• Unexpected laziness of for
• Unexpected laziness combined with multithreading
• Unexpected behavior of pmap with lazy sequences
• Propagation of nil
• nil and '() sometimes act the same, sometimes differently
• contains? vs. .contains
• first/rest, last/butlast, peek/pop on list vs. vector
• Unexpected conversion to other sequence type
• 60 second wait before program ends (shutdown-agents)
• def is global (for ex-Schemers)
• General conclusions

Note that although some of these are mentioned pretty clearly in the documentation, that doesn’t make them less of a gotcha for newcomers.

Unexpected laziness of for

Clojure’s laziness often results in unexpected code for beginners. For instance, what does the following code do?

(defn second [lst]
  (println "Elements:")
  (for [element lst]
    (println "*" element))
  (nth lst 1))

(println (second [1 2 3]))

We define a function second, which takes a list and returns the second element (position 1). While debugging, we use for to loop through the list and print its elements. If you’ve never programmed in Clojure before, you probably think this program prints the following:

Elements:
* 1
* 2
* 3
2

That’s incorrect! This program actually prints:

Elements:
2

This code snippet is confusing Clojure’s for with a for loop as you can find it in a traditional language. In Clojure, for returns a list with the results of its body, and is evaluated lazily. You can consider the for loop above syntactic sugar for (map (fn [element] (prinln "*" element)) lst), which is also evaluated lazily. To get the desired behavior, you should use doseq:

(defn second [lst]
  (println "Elements:")
  (doseq [element lst]
    (println "*" element))
  (nth lst 1))

(println (second [1 2 3]))

This code snippet will print the expected output. doseq is similar to for, but is evaluated strictly (= not lazily).

However, another important difference between doseq and for is that doseq returns nil. If you want to force evaluation of for, map, or another construct that generates a lazy sequence, you can surround it with doall.

Some examples:

(defn print-and-increment [i]
  (print i)
  (+ i 1))

(def a (map print-and-increment [1 2 3]))
; prints nothing - map is lazy
(println (last a))
; prints 1234 ⚠️
; the first 123 is the 'delayed' lazy code from inside the function,
; 4 is the value of (last a) (= 3 + 1).

(def b
  (for [i [1 2 3]]
    (print-and-increment i)))
; prints nothing - for is lazy
(println (last b))
; prints 1234 - same as 'map' above

(def c
  (doseq [i [1 2 3]]
    (print-and-increment i)))
; prints 123 - doseq is evaluated immediately
(println c)
; prints nil - doseq returns nil

(def d
  (doall (for [i [1 2 3]]
    (print-and-increment i))))
; prints 123 - doall forces evaluation of lazy sequence returned by for
(println (last d))
; prints 4 - the value of (last d).

Take-away: remember that for is lazy. Use doseq or doall to trigger strict evaluation.

Relevant documentation: for, doseq, doall

Unexpected laziness combined with multithreading

This is an extension of the problem above: laziness when combined with multithreading. For example, imagine we want to sum a large list in parallel. We might write:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
; Sum list, e.g. (sum [1 2 3]) = 1+2+3 = 6
(defn sum [lst]
  (reduce + lst))

(def large-list (range 10000))
; Divide large-list into 4 partitions of 2500 items:
; '((0 .. 2499) (2500 .. 4999) (5000 .. 7499) (7500 .. 9999))
(def partitions (partition-all 2500 large-list))
; Create 4 futures, in each future sum the partition: (⚠️ this is incorrect)
(def futures (map (fn [partition] (future (sum partition))) partitions))
; Wait until 4 futures have completed and get their results:
(def results (map deref futures))
; Sum 4 partial sums into one big sum:
(def result (sum results))

This code is incorrect! It will not actually execute the futures in parallel. The problem is again that map is lazy, and so on line 10, the futures are not actually created when that line is executed. The maps on both lines 10 and 12 are lazy. It is only on line 14, when reducing the final list, that each element of the the results (lazy) list is computed, needing the corresponding element in the futures list. Because reduce uses the elements in sequence, they are computed sequentially…

Here, the solution is to wrap the map on line 10 in doall:

(def futures (doall (map (fn [partition] (future (sum partiton))) partitions)))

This forces the computation of the futures to start at that point.

Take-away: when doing parallel computations on lists, check whether you aren’t using lazy operations.

Unexpected behavior of pmap with lazy sequences

pmap implements a parallel map. According to the documentation, pmap is “semi-lazy”: it evaluates lazily, but “tries to stay ahead of the consumption”. However, depending on whether its input is a lazy sequence or not, and whether it is “chunked”, its behavior will be different. Moreover, some types you might expect to be lazy are not (or only “partially”), in particular range. This is all quite complicated and confusing. Take a look at the following examples:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
(println (range 100))                ; => (0 1 .. 99)
(println (take 100 (iterate inc 0))) ; => (0 1 .. 99)
; Both look the same

(defn one-second [i]
  (Thread/sleep 1000)
  i)

(defn pmap-range []
  (let [x (pmap one-second (range 100))]
    (reduce + x)))

(defn pmap-lazy []
  (let [x (pmap one-second (take 100 (iterate inc 0)))]
    (reduce + x)))

(defn pmap-forced-lazy []
  (let [x (pmap one-second (doall (take 100 (iterate inc 0))))]
    (reduce + x)))

(defn pmap-vec-lazy []
  (let [x (pmap one-second (vec (take 100 (iterate inc 0))))]
    (reduce + x)))

; On a 4-core machine:
(time (pmap-range))       ; Elapsed time: 4036.040718 msecs
(time (pmap-lazy))        ; Elapsed time: 15108.031248 msecs ⚠️
(time (pmap-forced-lazy)) ; Elapsed time: 15063.460062 msecs ⚠️
(time (pmap-vec-lazy))    ; Elapsed time: 4017.902369 msecs

(println (type (range 100)))                      ; => clojure.lang.LongRange
(println (type (take 100 (iterate inc 0))))       ; => clojure.lang.LazySeq
(println (type (vec (take 100 (iterate inc 0))))) ; => clojure.lang.PersistentVector

Evaluating pmap on a range divides the range in 4 partitions that are evaluated in parallel (on this 4-core machine). However, when evaluating on the lazy sequence created with iterate, new elements are only created as needed, and therefore pmap is essentially sequential. Wrapping the lazy sequence in doall does not solve this issue! Converting it to a vector using vec first does.

Take-away: pmap can have unexpected behavior on lazy sequences. Moreover, it is often difficult to predict what the underlying type is of a sequence in Clojure. It is usually better to manually implement your own parallel map that does exactly what you want it to do.

Relevant documentation: pmap

Propagation of nil

In Clojure, many functions still work even when passed nil. For example, (map inc nil) returns (), just like (map inc '()) would; and (reduce + 0 nil) returns 0. However, this means that errors can often propagate quite far before an actual error is triggered. Many proponents of Clojure consider this a feature. However, in my experience this often obscures errors. It can also make it hard to find the root cause of a problem, requiring you to trace back through many function calls to find out where the nil originated.

Take-away: try to detect nil early.

nil and '() sometimes act the same, sometimes differently

There are some cases where nil and () act differently, as shown in the table below. In particular, nil is falsy while () is truthy. This is particularly annoying when combined with the problem above: when nil is used as input for map, an empty list is returned, and when using that empty list in next computations, things may not react as expected.

Take-away: try to detect nil early, so you can return '() when that is expected.

contains? vs. .contains

(contains? collection key) checks whether key is present in collection. For maps and sets, this works as expected, however, for vectors or lists the result is probably not what you expect:

; Checking for KEY
(contains? {:a 1 :b 2} :a) ; = true  - on maps: as expected
(contains? {:a 1 :b 2} :c) ; = false

(contains? [:a :b :c] :a)  ; = false - on vector: unexpected ⚠️
(contains? [:a :b :c] 1)   ; = true

(contains? '(:a :b :c) :a) ; error   - on list ⚠️
(contains? '(:a :b :c) 1)
; Execution error (IllegalArgumentException).
; contains? not supported on type: clojure.lang.PersistentList

(contains? #{:a :b :c} :a) ; = true  - on set: as expected
; #{:a :b :c} defines a set containing the elements :a, :b, and :c

What is happening here is that contains? checks for the presence of a key, not a value, and for vectors and lists this corresponds to the index, not the value. In other words, contains? does not search through the collection to check whether the value is present, but does a check whether the key exists (usually in O(1)). If (contains? collection key) returns true, that means (get collection key) will succeed.

If you want to check whether a vector or list contains a value, you can instead use the Java .contains method, which is defined on vectors, lists, and sets (but not maps, where you should first use vals!):

; Checking for VALUE
(.contains {:a 1 :b 2} :a) ; error   - on map ⚠️
; Execution error (IllegalArgumentException).
; No matching method contains found taking 1 args for class clojure.lang.PersistentArrayMap
(.contains (vals {:a 1 :b 2}) :a) ; = false - using vals to check for value
(.contains (vals {:a 1 :b 2}) 1)  ; = true

(.contains [:a :b :c] :a)  ; = true  - on vector: as expected
(.contains [:a :b :c] 1)   ; = false

(.contains '(:a :b :c) :a) ; = true  - on list: as expected
(.contains '(:a :b :c) 1)  ; = false

(.contains #{:a :b :c} :a) ; = true  - on set: as expected

Take-away: use the examples above to choose the appropriate function.

Relevant documentation: contains?

first/rest, last/butlast, peek/pop on list vs. vector

Some functions on collections have different behavior on lists vs. vectors, as shown in the table below. There is a logical reason behind these, but this may not be immediately obvious. In particular, peek “efficiently” retrieves an element from a sequence, which means returning the first element for a linked list but the last element on a vector.

On vectors, peek is a lot more efficient than last, even though they return the same value.

(def large-vector (vec (range 10000)))
(time (peek large-vector)) ; 9999 - Elapsed time: 0.046609 msecs
(time (last large-vector)) ; 9999 - Elapsed time: 12.9485 msecs

However, peek is not defined on some sequence types:

(peek (concat [1 2] [3 4]))
; ⚠️ error: class clojure.lang.LazySeq cannot be cast to class clojure.lang.IPersistentStack

Take-away: for some operations, you need to know whether you’re working on a list or a vector. Check the table above to see what each operation does. If necessary, convert the collection’s type:

; List->vector
(println (vec '(1 2 3)))       ; => [1 2 3]
; Vector->list - note the use of `apply`
(println (apply list [1 2 3])) ; => (1 2 3)

Relevant documentation: first, rest, last, butlast, peek, pop, vec, list

Unexpected conversion to other sequence type

Some operations on sequences convert their results to another sequence type, which can be unexpected, especially combined with the different behaviors shown above. For example, next and rest return a “chunked seq”, which does not have a peek function:

(peek (rest [1 2 3]))
; ⚠️ error: class clojure.lang.PersistentVector$ChunkedSeq cannot be cast to class clojure.lang.IPersistentStack
(type (rest [1 2 3])) ; = clojure.lang.PersistentVector$ChunkedSeq

In particular, concat is lazy and returns a LazySeq which is only realized when its result is needed. This can lead to unexpected bad performance when a vector is inadvertently converted to a lazy sequence:

(def large-vector (vec (range 10000)))
(time (nth large-vector 5000))
; "Elapsed time: 0.031142 msecs"
; nth on vector is O(1)

(def concatted (concat large-vector large-vector))
(time (nth concatted 5000))
; ⚠️ "Elapsed time: 3.446098 msecs"
; nth on lazy seq requires the sequence to be calculated before retrieving the element

(def concatted-vector (vec concatted))
; converting the lazy seq to a vector takes several msec
(time (nth concatted-vector 5000))
; "Elapsed time: 0.023805 msecs"
; but afterwards, nth is again O(1)

Worse, this can lead to a stack overflow when a lot of lists a first concatenated before they are used:

(type (concat [1 2] [3 4])) ; = clojure.lang.LazySeq

(repeat 5 '(0 1))
; = ((0 1) (0 1) (0 1) (0 1) (0 1))
(reduce concat (repeat 5 '(0 1)))
; = (0 1 0 1 0 1 0 1 0 1)
(reduce concat (repeat 5000 '(0 1)))
; ⚠️ error: StackOverflowError
; This error occurs because the LazySeq is built up as a tree of its components;
; here the tree is 5000 levels deep.

Take-away: unfortunately, for some operations you need to know their return type. If you encounter bad performance in unexpected places, check the types of the involved data structures for laziness. Again, use vec or list to convert to the desired type.

Relevant documentation: next, rest, concat, vec, list

60 second wait before program ends (shutdown-agents)

When using futures (or features that use futures behind the scenes like agents or pmap), a program will keep running for 60 seconds at the end. You need to call (shutdown-agents) to force a shutdown of the thread pool immediately. For example:

$ time clj --eval "(time 1)"
"Elapsed time: 0.014664 msecs"
1

clj --eval "(time 1)"  1.81s user 0.16s system 185% cpu 1.062 total

$ time clj --eval "(time (future 1))"
"Elapsed time: 7.38667 msecs"
#object[clojure.core$future_call$reify__8544 0x72bca894 {:status :ready, :val 1}]

clj --eval "(time (future 1))"  1.96s user 0.20s system 3% cpu 1:01.10 total

$ time clj --eval "(time (do (future 1) (shutdown-agents)))"
"Elapsed time: 3.066247 msecs"

clj --eval "(time (do (future 1) (shutdown-agents)))"  1.82s user 0.15s system 187% cpu 1.047 total

Here, we measure the total time to execute a Clojure program using (time ...) within our program, and using the shell command time. The relevant time is shown before total: the program that just returns 1 takes 1 second to execute, the one that creates a future takes one minute and one second. This is because the cached thread pool used for futures keeps running for one minute before shutting down automatically. By calling (shutdown-agents) at the end of our program, we avoid this one minute wait.

Relevant documentation: shutdown-agents

def is global (for ex-Schemers)

If you’ve programmed in Scheme before, you’re probably used to using define for local variables. However, that doesn’t work as expected in Clojure. For example:

(defn f [parameter]
  (def x parameter)
  (fn [] x))

(def one (f 1))
(println (one)) ; => 1
(def two (f 2))
(println (one)) ; => 2

In this example, the second call to f overwrote the global variable x. In Clojure, def always defines a global variable, unlike in Scheme where define defines a local variable. In Clojure, you should always use let for local variables.

General conclusions

Most of these problems have two root causes:

1. Clojure’s extreme dynamicity. This leads to ‘secret’ conversions between (seq) types, and faulty nil results being propagated because nil often passes as a seq. Note that this is not just the fact that Clojure is dynamically typed, but rather the automatic and careless conversions between types (e.g. Python avoids these issues).
2. Clojure’s laziness. This often leads to things happening at unexpected times. It is also not always clear which sequence types are lazy. Haskell, another lazy language, partially avoids this by explicitly typing all IO operations with the IO monad, so that at least for those its often more obvious what happens.¹ In my opinion, it is a mistake to mix laziness with a dynamically typed language (Haskell avoids that), and to mix laziness with multithreading (this applies to Haskell too). In a lazy language it is difficult to write multithreaded code, or even just single-threaded but efficient code.

Background: measuring CO₂ levels in house

First off, some background information on indoor CO₂ levels. (Note: this is about CO₂ = carbon dioxide, not CO = carbon monoxide.¹)

CO₂ levels are measured in ppm or “parts per million”: out of a million molecules in the air, how many are CO₂ molecules? Currently, CO₂ levels in the atmosphere are about 420 ppm, with slight seasonal variations. An interesting side note is that, before the Industrial Revolution, atmospheric CO₂ levels were around 280 ppm, but we’re not here to talk about climate change.

Indoors, CO₂ levels can vary from 420 ppm (the atmospheric level is the minimum you can reach, when you have your windows open), to 1500–2000 ppm in closed rooms, and even higher in crowded rooms such as class rooms or meeting rooms. The largest contributor to this is the CO₂ humans and large pets exhale. (A large dog exhales about half the CO₂ a human exhales.)

Elevated CO₂ levels can lead to several health problems, such as headaches and drowsiness. Recommendations vary, with the United States goverment currently limiting exposure to 5000 ppm for an eight-hour period, but other studies showing possible negative effects starting at 1000 ppm. (A level of 40,000 ppm is considered “immediately dangerous to life and health”, but you’re unlikely to encounter that.) If two people sleep a whole night in a closed bedroom, it’s possible to get to levels of 2000 ppm. Especially in modern, well-insulated homes and in schools and offices where many people gather, it is therefore important to have sufficient ventilation to keep CO₂ levels below these limits.

I got interested in measuring CO₂ at home to better configure my ventilation unit. This machine sucks in fresh air from outside and blows “used” air out (and at the same time has a heat exchanger that warms the incoming air using the outgoing air). Its air flow rate can be configured from 0 to 100%. Higher rates use more electricity and therefore cost more, but of course its rate should be high enough to keep CO₂ levels below safe limits.

Why the MH-Z19B sensor?

You can find many CO₂ sensors online. There are roughly two kinds: those that measure VOC and those that actually detect CO₂ molecules. The first kind detect Volatile Organic Compounds (VOCs): organic compounds that we exhale together with CO₂ and can therefore be used as a proxy to estimate the CO₂ in the air. However, results of such sensors often have quite large errors, as shown for instance in this video: a tumble dryer produces dust that contains VOCs, but does not produce CO₂. A VOC sensor will therefore incorrectly report high CO₂ levels when a tumble dryer is on. The usually cited advantage of VOC sensors is that they’re cheaper. The second kind of sensors measure CO₂ directly, but are often said to be more expensive. However, the MH-Z19B sensor is a cheap sensor of the second kind, so that’s why I chose to use that one.

The MH-Z19B sensor measures CO₂ using the non-dispersive infrared (NDIR) principle. It has an infrared lamp, of which the light is directed through two chambers. The first chamber is open to the air we want to measure; the second contains a reference gas, typically nitrogen. At the end is a detector. The gases in each chamber absorb certain wavelengths, and by comparing the results of the two chambers for the wavelengths absorbed by CO₂, we can calculate the CO₂ concentration in the air.

The MH-Z19B sensor has a reported accuracy of about 100ppm and a measuring range from 0 to 5000ppm. Its results should also be independent from the humidity. You can find the MH-Z19B sensor on AliExpress or European electronics websites (didn’t check others) for about $15 or €15.

Connecting the MH-Z19B sensor to a Raspberry Pi

It is easy to connect the MH-Z19B sensor to a Raspberry Pi, as shown below. (Figure from here.)

This table shows which pins to connect: (for Pi models with 40 pins, that is all models since 1B+ up to at least 4B, check here)

I found two versions of the MH-Z19B sensor online: one with just “holes” at the end and one with pins soldiered on already. I bought the ones with pins, so that I could use female-to-female jump wires to connect the sensor with the Pi.

Configuring UART on Pi

The Raspberry Pi communicates with the sensor over its UART (universal asynchronous receiver-transmitter) interface: a device for asynchronous serial communication. You need to enable this by following some tricky steps, as in this guide or in the Raspberry Pi documentation. I’ve copied the instructions for the Pi 3 below, assuming you’re using Raspbian.

Disable Linux serial console

By default the serial port is assigned to the Linux console, allowing you to execute commands in a console over the serial port (using a service called getty). We want to disable as we want to use this port for the MH-Z19B sensor instead, do this as follows:

1. Start raspi-config on the command line: sudo raspi-config
2. Select “5 Interfacing Options”.
3. Select “P6 Serial”.
4. For the question “Would you like a login shell to be accessible over serial?” choose No.
5. For the question “Would you like the serial port hardware to be enabled?” choose Yes.

Raspbian also comes with a GUI to configure these options.

Furthermore, execute the command sudo systemctl disable serial-getty@ttyS0.service to disable the getty service from starting on boot.

Enable UART in /boot/config.txt

At the bottom of /boot/config.txt, add the following line:

enable_uart=1

Reboot the Pi after these changes. The serial port is now available at /dev/serial0 (RPi 3 as well as older versions).

Reading CO₂ levels using Python

Now that we’ve connected the sensor to the Pi, we can start reading its measurements. You can find the full code on my GitHub. It’s a refactored and simplified of an existing library for my use case. I’m using Python 3.

Reading measurements

We are using the pyserial library to connect to the device. Its path is /dev/serial0. The following code will read the current measurements:

import serial

DEVICE_PATH = "/dev/serial0"
TIMEZONE = pytz.timezone("Europe/Brussels")

def current_time():
    now = datetime.datetime.now().astimezone(TIMEZONE)
    return now.strftime("%Y-%m-%dT%H:%M:%S%z")

def connect():
    return serial.Serial(DEVICE_PATH, baudrate=9600, timeout=3.0)

def read_all():
    with connect() as ser:
        ser.write(b"\xff\x01\x86\x00\x00\x00\x00\x00\x79")
        r = ser.read(9)

        if len(r) == 9 and r[0] == 0xff and r[1] == 0x86:
            return {"time": current_time(),
                    "co2": r[2]*256 + r[3],
                    "temperature": r[4] - 40,
                    "TT": r[4], # raw temperature
                    "SS": r[5], # status?
                    "Uh": r[6], # ticks in calibration cycle?
                    "Ul": r[7]} # number of performed calibrations?
        else:
            raise Exception("got unexpected answer %s" % r)

Here, the connect function connects to the device, returning an interface to the device. We then write nine bytes to the device: FF 01 86 00 00 00 00 00 79, which is the command to read the CO₂ concentration you’ll find in the MH-Z19B documentation. It’ll return nine bytes, which we’ll number 0 up to 8. What bytes 4 to 7 represent is not mentioned in the documentation, but people have tried to figure this out.

• Bytes 0 and 1 are FF 86, which we check in the if condition to make sure we got the expected reply.
• The CO₂ concentration is byte 2*256 + byte 3. For instance, if 02 20 (in hexadecimal) is returned, this corresponds to 2 and 32 in decimal numbers, and so the concentration is 2*256 + 32 = 544 ppm.
• Byte 4 is probably the temperature in Celsius + 40. In my experience, this is often a few degrees above the actual room temperature.
• Byte 5 represents a status, and is always 0 in my case.
• Byte 6 counts ticks up to a new calibration. This counts from 0 to 142, incrementing every 10 minutes. Therefore, after 1440 minutes = 24 hours, it resets. Calibration of the sensor happens every 24 hours, at the moment this counter resests.
• Byte 7 counts the number of calibrations that have occurred, up to a maximum of 6.

The function read_all() therefore returns, for example:

{"time": "2020-08-23T15:36:24+0200", "co2": 448, "temperature": 29, "TT": 69, "SS": 0, "Uh": 7, "Ul": 6}

There’s an easy and fun way to test whether the sensor works: pour out a can of Coca Cola, beer, or other carbonated beverage, and hold the sensor above the glass. It should immediately measure CO₂ levels of several 1000s ppm.

Calibration

The sensor must be calibrated. It’ll consider the “ambient environment” level to be 400 ppm, and calculates its levels relative to that. There are three ways to calibrate the sensor (see sensor documentation):

1. By connecting two pins when the ambient CO₂ level is 400 ppm.
2. By sending the command FF 01 87 00 00 00 00 00 78 when the ambient CO₂ level is 400 ppm.
3. “Self-calibration”: every 24 hours, the sensor will calibrate by considering the lowest measured level to be 400 ppm. You can enable this with the command FF 01 79 A0 00 00 00 00 E6, although it should be enabled by default.

I use the self-calibration because it is the easiest, as it does not require you to figure out when your sensor is in an environment with a CO₂ level of 400 or 440ppm. Note though that on its first use, you may have to have the sensor powered on for at least 24 hours before it’ll give accurate results. Using my script, you can enable automatic baseline calibration with python3 mh-z19.py --abc_on.

More

You can find the full script shown in this post in this GitHub project. Run sudo python3 mh-z19.py to output the time and CO₂ level to the terminal. Run sudo python3 mh-z19.py --all to also output the undocumented parameters. You need to run the script as root using sudo to be able to use the serial connection.

There’s one more feature I haven’t mentioned: you can set the sensor’s detection range to vary from 0 to 2000, 5000, or 10000 ppm. According to the documentation, this setting should not influence the sensor’s accuracy.

Automatically running this script and writing results to file

When my Python script runs without any parameters, it performs the measurement and writes its output as JSON to the terminal. As a final step, let’s run this script continuously and write its results to a file. I created a shell script mh-z19.sh, containing:

while true; do sudo python3 mh-z19.py --all | tee -a mh-z19.log; sleep 2m; done

This’ll run the script, and use tee to print its result to both the terminal and a log file. Every 2 minutes, a new measurement is added.

We’ve now succeeded in measuring the CO₂ in house and writing the results to a file. You can use this data to plot and examine the CO₂ levels over time, for instance using Matplotlib or Excel. You can also import the data into Home Assistant using the file integration, but that’s for another time.