A little bit of self promotion here, but you could play around with Net::Clacks, which is a real time messaging library i wrote. It has some basic examples of a chat client. You could build a little home automation project around it.

I would suggest trying something like this:

• A central clacks server that handles the messaging.
• An Arduino with a few buttons to act as "mission control". A Perl script that takes the button presses via Serial and sends NOTIFY messages via clacks. This way, you'll learn how to use Device::SerialPort to talk to a microcontroller.
• A couple of cheap "smart power outlet" thingies flashed with the open source Tasmota firmware. A Perl script that takes the NOTIFY messages and sets the state of the power outlets. It should also read their current state and STORE that state in Net::Clacks. This will give you the opportunity to learn basic control of stuff via Web Apis.
• A simple command line tool that RETRIEVES the current state of all power outlets from Net::Clacks and also lets you power on/off those devices.
• A more complex "command line GUI" using Curses::UI to do the same.
• Add a temperature/humidity sensor to the Arduino and make sure to update the Perl script to regularly power temperature and humidity to Clacks.
• Add a new "automation" service that reacts to temperature and/or humidity, decide if, say, a humidifier needs to be on and send that signal via Clacks to one of the existing Tasmota power outlets.
• Write a new clients that logs all kinds of states (tasmota on/off, temperature, humidity) to a database using DBI every minute. And learn during this the basics of using a database like PostgreSQL.
• Write a script that reads the last 24 hours worth of data from the database and generates a temperature and/or humidity graph. GD::Graph should come in handy for that, although you could also use Gnuplot to generate ASCII art graphs for command line use.
• Add Mail::Sendmail to your "automation" script to send warnings mails of temperature or humidity falls outside some limits you set.

At first, it may sound complex, but in the end you will have a handful of somewhat small scripts that work together through a messaging system. Each script does very little by itself and should be easy enough to understand, yet you should be able to accomplish quite complex tasks when you combine them.

I don't know about you, but i myself feel a certain satisfaction when i write programs that not only do stuff on screen but interact with something in the physical world. For this years Linuxdays in Graz i made a robot that handed out lollipops to children (and adults!) when they pressed a big red "Emergency Stop" button: "Giving out free lollipops the engineering way" (YouTube)