Remote Debugging mit Visual Studio 2010 in Domainumgebung

Szenario:

Eine zu debuggenden .NET Anwendung auf einer bestehenden virtuellen Maschine (Windows 7), welche kein Teil einer Domäne ist und einen Computer innerhalb einer Domäne mit Visual Studio 2012.Im speziellen geht es hier um managed Code Debugging.

Einrichtung der Remote Umgebung:

Auf der Remoten Seite müssen einige Dinge im Vorfeld eingerichtet werden:

  1. Erstellen eines neuen Benutzerkontos mit dem gleichen Benutzernamen und Benutzerpasswort, wie der Dämonenaccount.
  2. Neuen Account der Gruppe Administratoren zuweisen.
  3. Mit den neuen Account anmelden.
  4. Remote Debugger (32-bit/64-bit Variante) von Visual Studio kopieren (z.Bsp. aus „c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\“).
  5. Remote Debugger („msvsmon.exe“) ausführen, evtl. Firewall Einstellungen vornehmen.
Remote Debugger 2012
Remote Debugger 2012

Einrichtung der Lokalen Umgebung:

  1. Erstellen eines lokalen neuen Benutzerkontos mit dem gleichen Benutzernamen und Benutzerpasswort, wie der Dämonenaccount!
  2. Neuen Account der Gruppe Administratoren zuweisen.
  3. Nicht mit dem neuen einloggen.

FHEM – Heimautomatisierung – S300TH Temperatur- und Feuchtigkeitsensor

Für die Temperatur- und Feuchtigkeitsmessung gibt es in FHEM eine gute Integration des kostengünstigen S300TH Sensors von ELV.

S300TH Plot
S300TH Plot

Der Sensor wird per autocreate erkannt und es wird alles nötige angelegt. Wie oben zusehen, gehört der Plot auch dazu. Ich habe lediglich noch den Taupunkt (dewpoint) hinzugefügt. Dies geht ganz einfach mittels dem Helper-Modul „dewpoint“. Nachfolgendes „define“ in der „fhem.cfg“ fügt jedem (.*) Temperatursensor den Taupunkt zum STATE des Devices hinzu.

define dew_state dewpoint dewpoint .* T H D

Aus „T: 23.4 H: 54.3“ wird somit „T: 21.6 H: 50.1 D: 10.8“, welchen ich dann mit Hilfe des Ploteditors ins Plot eingefügt habe.

Aus

S300TH State
S300TH State

wird

S300TH State mit Taupunkt
S300TH State mit Taupunkt

FHEM Heimautomatisierung – FS20 S8M Sendemodul und Reedkontakt

Das erste FS20 Modul hab eich mit FHEM in betrieb genommen. Da es das Erste war, habe ich alles in Werkseinstellung gelassen. Somit habe ich einen generierten Hauscode, den ich dann für die nächsten Geräte verwenden werde. In FHEM wurde das Modul mit Hilfe der autocreate Funktion automatisch angelegt. Dazu habe ich lediglich die Taster nach der Reihe kurz gedrückt. Da ich es als 4 Kanal verwende, reichte jede zweite aus. 🙂

Die Reichweite innerhalb des Hauses ist ganz okay. Der CUL ist noch im Wohnzimmer und konnte das Sendemodul aus dem Dachgeschoss, wenn auch mit gefühlten 10 % Verlust,  empfangen.

Ziel war es ja, die Fenster und Türen zu überwachen. Dafür habe ich Alarmkontakte gekauft, die im Ruhezustand geschlossen sind.

Problem:
Dauersignal bei geschlossen Kontakt am FS20 blockiert alle anderen Kanäle, sowie das SRD-Band (1 % Regel). Das FS20 S8M verhindert das senden für 60 Minuten. Im FHEM würde dies bis dahin das Dimmen auslösen und die Log’s voll schreiben. Also nicht praktikabel.

FHEM Heimautomatisierung – Installation CUL und FHEM – COM-Port Problem

Die Installation unter Windows 7 war nicht ganz so einfach. Den CUL erkennen und flashen funktionierte nach längeren „probieren“ endlich, jedoch machte das ActivePerl Probleme. Ich hatte mich an das HowTo von der Wiki Seite (wie im letzten Artikel verlinkt) gehalten. Dort wird das ActivePerl 64 bit verwendet und das Modul „Win32SerialPort-0.22“ zur Ansteuerung des SerialPorts an den der CUL verbunden ist. Nachdem ich alles wie beschrieben gemacht hatte, entpackte ich das FHEM Package und startete FHEM via Commandline. Zum Test des autocreates, drückte ich eine Taste des Sendemoduls FS20 S8M, jedoch tat sich nichts. Sowas hatte ich schon vermutet 🙂

Ein Blick ins Log verriet mir dann doch, das der CUL nicht benutzt wird, da der COM-Port (in meinem Falle 3) nicht initialisiert wurden war.

Log Auszug:

2013.03.08 22:23:39 3: Opening CUL device com3
2013.03.08 22:23:39 3: Setting CUL baudrate to 9600
2013.03.08 22:23:39 3: CUL device opened
2013.03.08 22:23:39 1: Cannot init com3, ignoring it

FHEM – Heimautomatisierung – Es geht los

Wie im letzten Artikel kurz angesprochen, kann FHEM mit dem FS20 System von ELV arbeiten. Natürlich gibt es weitere Hardwarekomponenten als Alternative, welche auch von FHEM unterstützt werden. Welche das sind, ist auf der Hardwareseite von FHEM.de zu lesen.

Das FS20 System ist ein günstiges und auch vielseitiges System, für das ich mich für den Anfang entschieben habe. Dazu habe ich erstmal eine FS20 Komponente und das Kernstück, den CUL, gekauft. Es kann losgehen …

Hardware:
FS20 S8M – Sendemodul fertig montiert
CC1101-USB-Lite 868MHz (CUL) – meine Konfiguration:

  • Abschirmung – keine
  • Antenne – RPA-SMA 868MHz +3dBi 5 cm
  • Gehäuse – durchsichtig

ein Alarmkontakt als Ruhekontakt
ein PC für FHEM (alternativ gibt es was für Fritzbox, NAS …)

Software:
FHEM
Installations HowTo für Windows 7 (inkl.CUL Firmware, Windows Treiber und Perl)

Ziel:
Türen und Fenster zu überwachen

FHEM – Heimautomatisierung – Der Anfang

Heimautomatisierung war schon länger ein Thema, aber die Umsetzung stand noch nicht fest. Ursprünglich wollte ich das ganze im Sebstbau mit Tinkerforge realisieren, jedoch würde dies langfristig teurer werden. Ich hatte bis dato auch nichts vergleichbares und billigeres gefunden, was mein Vrohaben entsprechen würde. Denn durch die Stapelbauweise müßten immer wieder Inseln aufgebaut werden, woran die verschiedensten Bricklets (Temperatur, I/O, …) gekoppelt wären (Kabellänge vom Stapel bis zum Bricklet ca. 2 m). Somit würde für eine „Überwachung“ von Tür- und Fensternkontakten, mindestens pro Hausseite und Etage ein Stapel benötigt. Bei 3 Stockwerken sind das immerhin 6 Stapel mit einem Masterbrick und einer Extension zur Vernetzung (WLAN oder RS 485). Einen Prototypen für Tinkerforge habe ich schon fertig, es fehlt nur noch die Hardware. Und dann …

Durch einen Bekannten bin ich zum Podcast „Smart Home – Wenn das Haus „intelligent“ wird“ und zum gleichnamigen Artikel vom 21.02.2013 des BR2 gekommen. Dort wurde über Heimautomatisierung gesprochen und eben um ein FHEM Projekt.

Tinkerforge – Heimautomatisierung – Erster Prototyp

Mit dem Bauskastensystem von Tinkerforge möchte ich in Richtung Heimautomatisierung gehen. Mein erstes Projekt soll ein einfaches Alarmsystem werden, welches über Tür- und Fensterkontakte die Aussenhaut überwacht.

Hardwareseitig:
Es werden diverse Reedkontakte benötigt, sowie Masterbricks und IO Bricklets. Über die genaue Anzahl der Tinkerforge-Komponenten werde ich etwas später entscheiden, da ich vorerst ein Prototyp entwickeln möchte.  Dazu würde ein Masterbrick und ein IO 16 Bricklet zum Testen reichen.

Softwareseitig:
Ich habe mich für die C# Bindings entschieden und damit den Prototypen entwickelt. Die Oberfläche ist funktionell gehalten.

Prototyp mit BrickSpotter und Alarmsystem
Prototyp mit BrickSpotter und Alarmsystem

Funktionsumfang:

  • Spotter zum erkennen der Bricks und Bricklets (wichtig auch wenn während des Betriebs Bricks ausfallen)
  • Eine Sollliste (mandatory Bricks/Bricklets)
  • Diverse Checkboxen für die entsprechenden Kontakte (welche überwacht werden sollen), dahinter visuelle Anzeige über den Zustand (offen oder geschlossen)
  • Alarmsystem Aktivierung
  • Konfiguration: was soll passieren, wenn Alarm eintritt (Wo, Email, visuell, akustik, Log…)

Tinkerforge – Mikrocontrollerbausteine (Bricks) zum stapeln und programmieren

Kürzlich habe ich auf Golem.de einen interessanten Artikel gelesen, welcher mich in der Tat mal wieder geflasht hat. Elektronik zum Stapeln beschreibt eine neue Open-Source-Hardware Plattform, welche sich einfach programmieren läßt und eine Mischung aus Arduino und Lego Mindstorm ist.

Two stacks, with wireless extensions and external DC motor, Rotary Bricklet and battery
Two stacks, with wireless extensions and external DC motor, Rotary Bricklet and battery (Bild: Tinkerforge)

Tinkerforge bietet verschiedenste Bricks (Bausteine) an, welche sich untereinander sehr gut kombinieren lassen. So lassen sich Stapel von Bricks bauen, die unterschiedliche Einsatzgebiete abdecken, wie Servo Brick und DC brick. Oder wie oben im Bild zu sehen, ein Master Brick mit einer Chibi Extension. Weiterhin gibt es noch die Bricklets, die die Bricks in ihren Funktionen noch erweitern. Beispiele sind, Entfernungsmesser, Feuchtigkeitssensor, Dämmerungswächter, I/O Lets und viele mehr. Zudem lassen sich Bricks (Brickstapel) durch sogenannte Master Extensions untereinander verbinden. Entweder per Funk (Chibi Extension) oder per Kabel (RS485 Extension). Das System arbeitet bis dato nicht autark, sodass immer ein PC für die für das Steuerprogramm notwendig ist. Aber was nicht ist, kann ja noch werden. Seit Dezember 2011 gibt es diese Bricks zu kaufen und es tut sich noch einiges an dem Produktportfolio. Zum Beispiel ein WLAN Master Brick sollen noch folgen.