I was also looking into systems for home automation to control lights etc. using some commercial bus system like KNX. But all these systems are boring, expensive, inflexible and absolutely not the kind of system I was willing to invest a few thousand euros in. They advertise all that stuff as programmable and ultra flexible. But you need some expensive software and special adapters to reprogram your house. To save light configuration and recall them by a button you need some light-configuration-controller-hardware (at about 200 Euro) and a guy to program it. Non of the classical home automation systems can be controlled with an iPad.

So I decided to build something for my apartment by myself. In this first post of many I will show you my basic ideas and later I’m planning to publish hardware schematic and software source code for single modules and maybe for the whole thing.

The goal

• Control every light in every room of my apartment
  • some will just turn on / off
  • some are dimmable
• Controlled by the regular light switches
• A “Turn everything off” switch at the main door
• Connected to my local network (e.g. webservice)
• My personal application on an iPad

optional (or later on):

• Control the motor for the projection screen
• Control light by timers
• Send infrared signals to the stereo and the tv set
• Connected to the phone line (e.g. turn off the music when the phone rings)
• Receive data from wireless sensors
• Add a sensor to the washing machine and remind me when it’s finished
• much more

The basic concept

To control all this I will use some central microcontroller in my apartment. I decided to give the Microsoft Micro Framework a try. Since I’m already a .Net guy it should be pretty easy (and cool) to program my home in C#. I will use the FEZ Cobra board. A 72 MHz ARM device with 12 MB RAM. It is probably already too powerful for my usage but who cares. It comes with USB-Ports where you can connect keyboards, joysticks or cameras. It has a build in Ethernet port, a SD-Card slot a lot of I/O Ports and everything else you need. One could also connect a TFT touch screen. With this guy I have all the connectability I need and enough power to implement all crazy ideas in software.

In the walls I will get push buttons instead of regular on/off switches and a single cable will be used for each of this button to a central place where my project resists. This way the Cobra board can receive signals from all buttons.

To control the lights the cables will be put to these place too. Here I will use relais or dimmers controlled by the Cobra board. For some lights I will try RGB LEDs with DMX controllers (I will later explain what that exactly is).

A little bit more in detail

The key to all this is my custom wiring with a lot of more cables in the walls then usually. Since the apartment will be newly build I can get this wiring without big problems.

My push buttons will be powered only by 12V or 24V DC not 240V AC (the normal power in Europe). This way it is much easier to connect it to the Cobra board.

For controlling dimmers I will use dimmers with a control input of 0 to 10V. Again: it’s much easier to buy some working and proofed dimmers for the 240V high voltage and my DIY projects only controls it by a 10V signal. The same for switches: the Cobra board will drive some relais with 12V DC and the relais will switch the 240V AC line.

Maybe I will use for dimmers and other light controlling stuff the digital DMX512 protocol. This is used on stages to control all the light effects and seems pretty simple to implement on the hardware and software side.

For most of these functions I will create small hardware modules and connect them to the Cobra board. This way the completion of the whole project is much easier. Some of these modules will be connected to the I/O ports of the Cobra directly and some will use a I2C-Bus.

Some modules first

To get stared I created hardware prototypes for the first modules of the system. These modules can be used for the purpose I’m planning or for something totally different (at the end these are only input and output port controlled by a microcontroller). I will show you the different modules in upcoming posts. Once finished the major parts I believe I will extend the whole system step by step. But let’s start with:

• I2C voltage converter
  • since the Cobra board uses 3,3V but all other modules will use 5V I need a simple voltage converter
• I2C input module for push buttons
  • using optocouplers and an I2C-I/O-chip
• I2C digital output modules
  • with an I2C-I/O-chip again and some drivers to power relais
• I2C analog outputs
  • to create the control voltage for 0-10V dimmers.
• DMX512 output

Within the next weeks I will start to write a post to each of these modules with detailed hardware and software explanations.

1) When trying to copy the given source code you’ll mention that all the classes are unknown to Visual Studio, because all a lot of references are missing. So far I have no clue about the R#-class-architecture. So I started .NET Reflector, open ALL the .dlls in the R#/bin-folder into Reflector and use the search to find the .dlls to reference in my project.

2) When you have your first R#-plugin ready you want to test it. To do so you have to copy the dll containing your plugin in the R#-plugin folder. You may want to do this in a post-build event like this:


copy $(TargetPath) "C:\Program Files (x86)\JetBrains\ReSharper\v5.1\Bin\PlugIns\WobTest"


When you build your project with this post-build event it fails. This doesn’t work for two reasons. First: Win 7 denies access to that folder. Second: after another start of Visual Studio R# has loaded the plugin so you can’t copy a newer version over it.

My solution to this is a .cmd that starts Visual Studio without R# (devenv /safemode). I run this .cmd as administrator.

Now at least I can debug my plugins by starting another instance of Visual Studio (not in safemode!)

This solution is not cool, because developing R#-plugin without using R# in the development-process sucks…. any ideas?

a better solution…

Some minutes after I published this post, Benjamin pointed me to this page. Forget about my lines to 2). You don’t need a silly .cmd run as administrator not a post-build event. All you need to do is to start your debugging Visual Studio the the command line option /ReSharper.Plugin followed by the path to your plugin-dll.

/ReSharper.Plugin "R:\sandbox\ReSharperPlugInTest\PublicGoesVirtual\PublicGoesVirtual\bin\Debug\PublicGoesVirtual.dll"

But suddenly I cannot access the website any more. Internet Explorer just said “Loading…” forever but nothing happened.

If the same happened to you try to switch Internet Explorer into Compatibility View and it may work again (it did on my machine).

I discovered during debugging a lot of debug messages in Visual Studio output window like:

'Application.vshost.exe' (Managed (v4.0.30319)): Loaded 'm0dayvr5'
'Application.vshost.exe' (Managed (v4.0.30319)): Loaded 'oxxqw1rq'
'Application.vshost.exe' (Managed (v4.0.30319)): Loaded 'dgh3mgtl'
'Application.vshost.exe' (Managed (v4.0.30319)): Loaded '00sdpqlv'
'Application.vshost.exe' (Managed (v4.0.30319)): Loaded 'yokpozj4'

Then I remembered that the XmlSerializer creates dynamic assemblies during runtime and loaded them into the AppDomain (and never unloads these assemblies since you cannot unload from an AppDoamin). In the MSDN article I found a solution that explains this behavior:

Dynamically Generated Assemblies

To increase performance, the XML serialization infrastructure dynamically generates assemblies to serialize and deserialize specified types. The infrastructure finds and reuses those assemblies. This behavior occurs only when using the following constructors:

XmlSerializer.XmlSerializer(Type)

XmlSerializer.XmlSerializer(Type, String)

If you use any of the other constructors, multiple versions of the same assembly are generated and never unloaded, which results in a memory leak and poor performance. The easiest solution is to use one of the previously mentioned two constructors. Otherwise, you must cache the assemblies in a Hashtable, as shown in the following example.

Of course you can use any other data structure to do the caching. But you have to do it on your own if you do not use the two mentioned constructors. I’ve got no idea why Microsoft builds caching into the code for some constructors and not for others, but that’s the way it is.

Some performance measurements

I didn’t build a great benchmark, but at least I got a few numbers. Serializing multiple files without caching takes on my machine about 140ms in debug mode and 130ms in release mode. Each time. With caching only the first file takes this 140 / 130ms and every additional file took about 8ms (debug) or 6ms (release).

That’s a speedup of about 17x to 20x!

And you do not produce memory leaks!

A new option was added to expand the tree of tags at startup.

See http://phototagstudio.irgendwie.net/

I’m not sure what append, maybe it happed on a project I imported from an older Visual Studio version. But for this project the property I needed so much was just missing.

If the same happens to you, you can edit the DslPackage.csproj and add the following line:

<ProjectTypeGuids>{82b43b9b-a64c-4715-b499-d71e9ca2bd60};     {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

It worked on my machine and I got this property back.

I created a setup and changed the prerequisites from Client Profile to the Full Framework. When testing this on a virgin machine the setup told me that I need to install the .NET 4.0 framework (that’s right) but then it directs me to the download of the Client Profile only.

To fix this, you have to change the InstallUrl of the .NET Framework Launch Condition:

• right-click on the setup project in solution explorer and choose View –> Launch Conditions
• here you will find a Launch Condition for the .NET Framework
• select this Launch Condition and open the Properties Window
• there you will find the InstallUrl property

For the full .net 4.0 Framework change this URL to http://go.microsoft.com/fwlink/?LinkId=186913

For the Client Profile of the .net 4.0 Framework the URL can stay as it is: http://go.microsoft.com/fwlink/?LinkId=131000

First of all I have to explain to everybody what I’m talking about:

With Visual Studio 2010 Microsoft introduced a new way to deploy extensions to Visual Studio. Instead of creating a setup.exe that copies files, writes to the registry and calls devenv.exe with the /setup option one only needs such a VSIX file that does all that is necessary to install an extension.

When working with the T4 (Template Transformation Toolkit) system one creates tt files with some kind of script that is used to generate source code within a user’s Visual Studio project. The Microsoft DSL Tools do the same: every DSL project contains a number of tt files that will generate all the code. If you take a look at such a file, you will only see two lines:

<#@ Dsl processor="DslDirectiveProcessor" requires="fileName='..\DslDefinition.dsl'" #>
<#@ include file="Dsl\Diagram.tt" #>

The magic happens with the include command. The real template code sits in the included file and not within every single project. When installing the DSL Tools extension to Visual Studio all these include files get installed somewhere where they can be found by the tt engine.

For my own DSL Languages I would like do the same: the user projects should only contain such two line tt files and include the rest of the template from other files.

How to deploy tt template files?

The following steps will show you how to deploy additional files with you DSL extension.

I will start from a newly created Domain-Specific Language Designer project. Such a project contains a Dsl and a DslPackage project where the DslPackage project creates besides of the DslPackage.dll a vsix file to install the designer onto another machine.

Our goal will be to add some tt files to the vsix and make them includable on the installed machine.

1. Add a folder to the DslPackage project and name it TextTemplates (or any other name)
2. Add the tt files to this folder.
   • In the properties windows clear the “Custom Tool” property; otherwise Visual Studio will try to execute these templates within the DslPackage project.
   • set “Build Action” to “Content”
   • set “Include in VSIX” to “True”
3. Add a file called Additional.pkgdef to the DslPackage project with the following content and
   • set “Build Action” to “Content”
   • set “Include in VSIX” to “True”
     

     [$RootKey$\TextTemplating\IncludeFolders] [$RootKey$\TextTemplating\IncludeFolders\.tt] "IncludeMyDsl"="$PackageFolder$\TextTemplates"

     Replace “IncludeMyDsl” by a unique name for your DSL but make sure it starts with the word “Include”.

4. Edit the source.extension.tt in the DslPackage project and add the following line within the Content tag:

   <VsPackage>Additional.pkgdef</VsPackage>

With these changes the tt files from the TextTemplates folder get packaged into the vsix file and will be accessible using the <include> tag on the machine where this extension is installed.

Returns the Assembly of the method that invoked the currently executing method.

In our project we had an assembly with a lot of helper methods. On of these gets resources from the calling assembly. In various places of our code we called this method to get icons or other resources. This method used exactly this GetCallingAssembly() method to figure out what assembly to look for resources.

That worked pretty good in debug mode but exceptions were thrown in release mode. We could not understand what is going on. It became even worse: when we build a release version and tried to debug that version (using Visual Studio Debugger) in worked again. It looked like a heisenbug.

It took us some time to figure out what is also written in MSDN:

If the method that calls the GetCallingAssembly method is expanded inline by the compiler (that is, if the compiler inserts the function body into the emitted Microsoft intermediate language (MSIL), rather than emitting a function call), then the assembly returned by the GetCallingAssembly method is the assembly containing the inline code. This might be different from the assembly that contains the original method. To ensure that a method that calls the GetCallingAssembly method is not inlined by the compiler, you can apply the MethodImplAttribute attribute with MethodImplOptions.NoInlining.

The JIT compiler moves code around to optimize for performance. Small methods (up to about 56 Byte IL-Code if I remember it right) can be inlined where the method call was before. But the compiler does this only in release, not in debug mode. Also when attaching the debugger to our release build the JIT compiler stopped inlining to enable debugging and our bug was gone.

After understanding this, the fix is easy. Just don’t allow the compiler to inline that particular method that calls Assembly.GetCallingAssembly(). Then the method stays in the assembly where the source code is written and everything will be fine.

[MethodImplAttribute(MethodImplOptions.NoInlining)]
public void SomeFunction(int i)
{
    // ...
    var a = Assembly.GetCallingAssembly();
    // ...
}

This attribute does the trick and I recommend to use it on all methods that call GetCallingAssembly() and can be called form another assembly and need the real calling assembly.

public int MyProperty
{
    get { return (int)GetValue(MyPropertyProperty); }
    set { SetValue(MyPropertyProperty, value); }
}
public static readonly DependencyProperty MyPropertyProperty =
    DependencyProperty.Register("MyProperty",
                        typeof(int),
                        typeof(MainWindow),
                        new UIPropertyMetadata(0,
                            MyPropertyvalueChangeCallback));

private static void MyPropertyvalueChangeCallback
                        (DependencyObject d,
                         DependencyPropertyChangedEventArgs e)
{
}

But how to add such a event handler to an already existing Dependency Property or somewhere else then in the defining class? E.g. to an property of a WPF-Control that was not build by you. Take a standard WPF-TextBox; both the Text and the FontSize properties are Dependency Properties but the TextBox-class only provides a change event for the Text-property. Nevertheless you can get a change event for any Dependency Property:

DependencyPropertyDescriptor dpd =
    DependencyPropertyDescriptor.FromProperty
        (Control.FontSizeProperty, typeof (TextBox));
dpd.AddValueChanged(someTextBox, SomeTextBoxFontSizeChanged);

Every time the FontSizeProperty on the instance someTextBox changes the given method is called. It’s that easy and you can implement this code everywhere not only within the class that defines the property.