The Raspberry Pi Powered Speaking Doorbell – Part 2: Kodi Camera Overlay

In Part 1, we looked at building a simple input circuit to electrically isolate and protect our Raspberry Pi from damage when connecting it to our doorbell switch. Next, we’ll look at displaying a camera overlay directly in Kodi / XBMC and triggering the display from a Python script.

IP cameras have become really cheap and easy to come by, giving us many options to integrate video into our home automation systems. The front door is a great place to install a camera!

ip

The Digital Lifestyle has a very good write up on how to install and configure an add-on to display the camera overlay (especially if you have more than one camera) directly in Kodi itself.

We can then use some Python code to trigger the add-on using Kodi’s API.

Prerequisites: In Kodi, make sure “Allow control of Kodi via HTTP” is set to ON in Settings -> Services -> Webserver.

I wrote a small XBMC / Kodi client to make it easier to make calls to the API. Here is the method for triggering an add-on:

    def execute_addon(self, addon_id):
        payload = self._get_payload("Addons.ExecuteAddon",
{'addonid': addon_id})
        self._do_post_request(payload)

And here is the code for instantiating the client and executing the add-on:


xbmc_client = xbmc.XbmcClient(host, port)
xbmc_client.execute_addon("script.frontdoorcam")

On line 1, we instantiate the XBMC client by specifying the host and port. The port is configured in Kodi’s Settings -> Services -> Webserver -> Port.

The only parameter we are passing to the execute_addon method is the ID of the add-on we wish to run. Set it to the add-on ID that you specified in the addon.xml file.

That’s it. Next, we’ll look at how to build a text to speech server using Tornado.

The SOLID Principles of OO Design and Object Calisthenics

Chances are, if you are using test driven development, or regularly dabble with OOP design, you have implemented one or more of the SOLID principles, possibly without even knowing it. The SOLID principles are by no means a new concept, but it’s gaining traction within the PHP community. If you have a look at the Zend Framework v2.0 or Symfony 2 projects, you will see many of the principles applied.

The SOLID principles are:

  • S – Single Responsibility Principle
  • O – Open/Closed Principle
  • L – Liskov Substitution Principle
  • I – Interface Segregation Principle
  • D – Dependency Inversion Principle

I’ve found a strong correlation between the SOLID principles and a practice called Object Calisthenics, an idea from Jeff Bay detailed in the book, The ThoughtWorks Anthology. Some of the rules in Object Calisthenics compliment the SOLID principles very well, I will refer to the rules when this is the case. In short, without going in too much detail, here are the 9 rules of Object Calisthenics:

  1. Use only one level of indentation per method
  2. Don’t use the else keyword
  3. Wrap all primitives and strings
  4. Use only one dot per line
  5. Don’t abbreviate
  6. Keep all entities small
  7. Don’t use any classes with more than two instance variables
  8. Use first-class collections
  9. Don’t use any getters/setters/properties

The SOLID principles focus on Dependency Management. I’m sure as developers, we’ve all been victims of projects with poor dependency management – changing code in one part of the system breaks code in another part; Re-using code is difficult or impossible; Classes and methods are huge and often it’s hard to tell what they’re supposed to be doing. The SOLID principles are ways to reduce the likelihood of this of happening. Unlike design patterns which guide you to a solution, the SOLID principles can be used as a guide to prevent problems.

In this article, I will cover the first of the SOLID principles, the Single Responsibility Principle – “A class should have one, and only one, reason to change”. This is basically the same as “cohesion”, or writing classes with “high cohesion”. So, why is this important? If a class has more than one responsibility, there is more than one reason for it to change. This leads to very volatile classes which of course could affect any other classes that depend on it. See also Object Calisthenics, rules 6 and 7.

It is often easy to spot classes that fail this principle as they often contain words like “Manager”, or “Handler”. When implementing SRP, classes become more specific and focussed and the class names reflect the single responsibility of the class, e.g. EmployeePayrolCalculator.

So how do you go about refactoring your code to implement this principle? Begin by implementing the principle in your methods – refactor your methods to 5-7 lines, one block of indentation and a single responsibility per method (see rule 1 and 2 of Object Calisthenics). Once you have refactored your methods, ask yourself how many reasons does your class have to change? If the database schema changes, does it affect your class? And if the business rules change? How about a user interface change? If you establish more than one reason for change, refactor the class into two or more classes until you are happy that all your classes only have one responsibility.

In the next article – The Open Closed Principle.

ZendCon 2011 – Introducing Zend Developer Cloud, Zend Studio 9 and Zend Framework 2

ZendCon kicked off on 17 October in Santa Clara, California. The surprise of the conference was the announcement of the launch of Zend Developer Cloud during Zend’s CEO Andi Gutmans’ opening keynote speech.

Zend Developer Cloud is a free, cloud based environment for developing and deploying PHP applications. It has tools to quickly set up PHP application stacks, including Zend Framework, Joomla, Drupal and WordPress. It includes a code tracing tool and debugging features. Once the application is ready, it can be deployed to any cloud provider supporting the “Zend Application Fabric”, including Amazon and Rackspace. Zend Developer Cloud also supports the ability to take snapshots of instances at any given time that can be shared with other developers. This could be useful for developer collaboration. It is currently available as a “technology preview release”, you can request an early access key here.

The keynote also featured a live demonstration and one of the tools featured during the demonstration was the new Zend Studio 9 beta. It features tight integration with the Zend Developer Cloud, allowing developers to deploy to the cloud instances from within the IDE. Other noteworthy features include Git and Github support build into the IDE which should make a lot of developers very happy. Emphasis was also placed on how the new IDE can be configured to only include modules that developers need, cutting down a lot of the bulk that is a common complaint with Eclipse IDEs.

During the week before the conference, the beta 1 release of Zend Framework was announced. ZendCon 2011 had several talks detailing the internal workings of the new framework. One of the major changes includes extensive use of dependency injection throughout to make it truly extensible. Most of the framework was rewritten to ensure consistency throughout and to harness the full capabilities of PHP 5.3. The architecture was also simplified greatly by introducing event driven programming to the framework. To find out more about ZF2, have a look at the community wiki. Take note that the API will change while still in Beta.