Previous blog posts for this project:
- IoT Alarm Clock - Part 1
- IoT Alarm Clock - Part 2
- IoT Alarm Clock - Part 3
- IoT Alarm Clock - Part 4 (this post)
I've been working hard the past few weeks in order to finalise both software and hardware for my IoT Alarm Clock.
This is the final post for this project, or at least this first prototype, where I elaborate on the software and the final parts of the build.
Here it is, the final look of the alarm clock.
I printed a bracket able to hold the LED matrix so that it remains correctly positioned, but is still removable. Then came the front panel for which I printed a frame with rounded edges to which I attached some spare speaker cloth I had laying around.
I chose the speaker front panel for following reasons:
- it softens the light produced by the LED matrix, making it easier to read (and easier on the eyes at night!)
- the integrated microphones of the Wolfson audio card remain "accessible" for voice control purposes
- I think it looks good
I had some difficulties getting Jasper to work with the Wolfson audio card. I created a question in the community and recently got some very useful answers. Thanks guys!
You can find the thread here:
The web interface has been finalised. It offers different pages, each with their own functionality:
- Overview: Chosen train information and to what time the alarm is set
- Trains: Search criteria for the train connection
- Alarms: Configured alarms
- Sounds: Configured sounds available for alarms, supporting files and internet radio streams
All data such as train information and train stations is retrieved dynamically via the iRail API for Belgian public transportation.
Some pages require to be visualised in landscape mode due to long text (url/path):
Having a web interface with all information needed is nice, but how do you know which ip address to use ? You could configure a fixed IP address, but even nicer would be to access the GUI via a name. This is made possible with the avahi daemon.
pi@alarmclock ~ $ sudo apt-get install avahi-daemon pi@alarmclock ~ $ sudo insserv avahi-daemon pi@alarmclock ~ $ sudo nano /etc/avahi/services/multiple.service
<?xml version="1.0" standalone='no'?> <!DOCTYPE service-group SYSTEM "avahi-service.dtd"> <service-group> <name replace-wildcards="yes">%h</name> <service> <type>_device-info._tcp</type> <port>0</port> <txt-record>model=RackMac</txt-record> </service> <service> <type>_ssh._tcp</type> <port>22</port> </service> </service-group>
pi@alarmclock ~ $ sudo /etc/init.d/avahi-daemon restart
The pi is now accessible via alarmclock.local:
Fredericks-MacBook-Air:~ fvan1$ ping alarmclock.local PING alarmclock.local (192.168.0.178): 56 data bytes 64 bytes from 192.168.0.178: icmp_seq=0 ttl=64 time=37.015 ms 64 bytes from 192.168.0.178: icmp_seq=1 ttl=64 time=59.842 ms
So is the web interface:
Here's a video of Jasper telling me the time. I extended the "Time.py" script to also print the time on the LED matrix.
Here's Jasper telling me to what time the alarm is set:
And finally, Jasper telling me when my train leaves:
Rather than use voice control, you can also press the button sat the top of the alarm clock, which will then display the same output as when using voice control.
What follows are some examples of the alarm clock calculating the alarm time, after determining which train to take.
To go from Lokeren to Callenelle, the clock picked the train leaving at 05:22, and decides to set the alarm fro 04:52, taking into account 30 minute to get prepared and go to the station.
When performing the same query on the railways website, we see there are multiple options, but the clock picked the most appropriate one.
A second example, still from Lokeren, but this time to Brussels Central:
This second example illustrates the fact that the application will select the train that allows to sleep as long as possible, while still arriving on time.
One of the trains arrives exactly at the desired arrival time, but leaves earlier. The application therefore decided to pick a train that arrives a little bit earlier than desired, but allows to sleep longer than the one arriving exactly on time.
As stated earlier, this is the final post for this first prototype. It doesn't mean that this project is over!
There are a lot of improvements which can be implemented in order to create version 2.0.
Some ideas for a next version:
- improve voice control: ensure better recognition of questions and extend range of supported questions
- expand the transport options: current implementation supports train, but it could be expanded to include bus, car, subway, etc ...
Thank you element14 for giving me the chance to create this build!