Tamapotchi on Heroku
Tamapotchi note #12
In my previous note I wrote about the restart of Tamapotchi with new hardware, the Particle Photon. I created a very basic temperature monitor with it, using only IFTTT and Google Sheets. In this note I will tell you how it evolved into a much more advanced prototype.
(If you are not interested in technical details, skip to the images and wait for my next note. Less tech, promise :-)
Sure this basic temperature monitor was only a sketch, but it gave me a lot of new ideas of what Tamapotchi could be. I wanted Tamapotchi to have a memory to enable it to detect patterns and trends in sensor readings. So I started looking for database services that I could use. I ended up with Clusterpoint, mostly because it was free, had documentation I actually understood and had good web interface. Later in the process I found out they also provide speedy, friendly and accurate support when I needed it.
Clusterpoint has a REST API that I was aiming to use. My first thought was to call it directly from the Photon, but that didn’t work out. I needed to make https calls from the Photon which, so I learned, means there is an exchange of certificates between client and server. Because of the Photon’s limited capacities this proved to be virtually impossible.
Luckily Particle had apparently seen this one coming and introduces the concept of ‘webhooks’. A webhook is defined in the Particle service and will listen to any values that are being published from the Photon. When a value is published, the webhook will pick it up and POST it to a specified url. In my case, the Clusterpoint REST endpoint. Now every minute the Photon would publish a new sensor reading that was to be picked up by the webhook and stored in the Clusterpoint database.
I needed two more basic components in my setup: a dashboard and a “brain”. The dashboard would show information when the user needs it, but the brain is the vital part of Tamapotchi. It is the process that is always running in the background and analyses incoming and historic data. It can make decisions and take actions based on what it finds in that data. For example, it could send the user a message when it’s getting too cold for the plant.
I chose to use NodeJS on Heroku for both the dashboard and background process. Heroku has a free tier with some nasty limitations, but also great documentation and tooling. It was easy to setup a workflow that somewhat resembled the ‘real thing’ I see my tech colleagues doing. Git, developing and testing on localhost, running stuff on Heroku when done. Not bad for a designer I think.
The background process is another NodeJS app with a process running in an infinite loop. And really, it’s just a simple setInterval that keeps it running. It gets it’s data from the Clusterpoint database, processes it and decides what to do.
It could decide the data is showing that conditions are alarming for the plant Tamapotchi is monitoring. If so, it will send a warning message by email to the owner (in this case: me). It will do so when the plant is in a spot that is too dark (or bright), when it is too cold (or hot) or when the soil is too dry (or wet). At a later stage I am planning to replace the warning emails by app notifications. But I’ll need an app first.
When data is showing everyting is fine, it could still be time to send the daily or weekly digest email. The daily report shows the minimum, maximum and average values of that day, compared to ‘an ordinary day’. The weekly report is a bit more fancy: it shows the whole week in retrospect, with a heatmap for temperature and light, and a line chart for moisture levels. Currently I only have the heatmap implemented, but the others will follow shortly.
Embedding charts into an email is a lot more complicated as it sounds. I’m a big fan of D3js when creating charts in a browser environment. It gives a lot of freedom for visual design and interaction, more than any other framework I know. But the charts I’m talking about here should appear in a mail client, not in a browser. D3 will not work in a mail client, but the SVG it produces can be rendered. So I needed a way to create the SVG in NodeJS and embed it in the mail body. D3 heavily relies on the DOM, and NodeJS (being a server-side creature) doesn’t have one.
Luckily, I was not the first to encounter this problem. It turned out I needed to include 2 extra modules in my application: D3 (obviously) and JSDOM. The latter (as the name implies) provides a virtual DOM for D3 to do it’s magic. Once the modules were included, I could just use the regular D3 stuff like I would do when inside a browser. I created separate modules for creating the charts, mainly because I wanted to be able to test them separately; I didn’t want to send an email every time I needed to check after a change.
Well, that’s about it for now. Next time I’ll tell you about that funny little creature that you might already have spotted in the picture above. And how the 3D model is getting along. Later.
If you like to see and hear more about Tamapotchi, be sure to attend my talk at DevCon16, April 19th 2016, 16:30 Cinema 7!