Nach update auf Android Marshmallow, kein Zugriff auf SD Karte via Windows

Nachdem Update von Android Lollipop auf Marshmallow funktioniert der Zugriff auf die SD-Karte von Windows aus nicht mehr. Die SD-Karte hatte keine Inhalte, obwohl der Speicherplatz unter Windows was anderes zeigte.

Geholfen hat nur die Daten der Medienspeicher-App zu löschen und einen Reboot auszuführen. Dadurch wird alles wieder neu indiziert und der Inhalt von der SD-Karte ist wieder unter Windows sichtbar.

Diese App ist unter Einstellungen -> Apps zufinden. Jedoch vorher noch über das Drei Punkte Menü „Systemprozesse anzeigen“ auswählen, damit die Medienspeicher-App angezeigt wird. Antippen und auf dann Speicher tippen. Danach Daten löschen wählen und bestätigen. Reboot durchführen und danach wieder mit dem PC verbinden. Der Inhalt sollte wieder sichtbar sein. Je nach Größe und Belegung der SD-Karte, kann das einige Minuten dauern.

GigaBlue HD Quad – Bootet nicht mehr

Der Titel klingt schlimmer als es wirklich war – Zum Glück. Folgendes ist passiert: Die GigaBlue funktionierte bis dato nahezu 100 %. Aber nachdem diese Ihren alten Platz räumen musste, hat sie plötzlich am Neuem das Booten verweigert. Sie blieb beim Bootscreen einfach stehen und das GigaBlue Symbol drehte sich fleißig. Nach mehrmaligen an und ausschalten, Kabelkontrolle, minimal Verkabelung (nur Netzanschluss) hatte ich fast aufgegeben. Ein was war trotzdem anders und zwar der LAN Anschluss. Am neuen Platz hatte ich noch kein Netzwerk liegen. Also langes LAN Kabel geholt und angeschlossen und siehe da, in Sekunden hat die Box gebootet. Ursache sind wohl die eingerichteten Shares. Wie ich gehört habe, soll die Box nach ca. 15 min im Bootscreen dann doch normal booten. Solang hatte ich nicht gewartet. 🙂

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.

.NET – Debugging optimized managed code / Disable JIT Optimization

Builds von managed Code, speziell Release Builds, werden schon zur Compile-Zeit geringfühig optimiert. Intern des Binaries wird zusätzlich ein Flag gesetzt, um die (Just-In-Time) Optimierung zur Laufzeit zu aktivieren. Demzufolge wird der Code unmittelbar vor Ausführung optimiert (geJITed).

Um so einen Code sinnvoll zu debuggen, benötigt man lediglich ein INI file, um die JIT Optimierung abzuschalten.

Schritte:

  1. Anwendungen schließen, welche den optimierten Code benutzen.
  2. Ein neues Textfile erstellen, welches den gleichen Namen besitzt, aber die neue Extension .ini (Bsp.: MyBinaryCode.dll -> MyBinaryCode.ini).
  3. Mit folgenden Inhalt füllen:

    [.NET Framework Debugging Control]
    GenerateTrackingInfo=1
    AllowOptimize=0

  4. Parallel zum binary (exe/dll) legen.
  5. Nicht optimierten Code debuggen.

Weitere Informationen findest Du bei MSDN.

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…)