IoT mit ESP8266 und DHT22

Ziel des Projekts sollte es sein günstige IoT Sensoren zu erstellen und in FHEM einzubinden. Hierzu habe ich folgendes Szenario erstellt:

  1. Entwicklerboard (ESP8266)
  2. angeschlossener Temperatur und Luftfeuchte Sensor (DHT22)
  3. Connect via WLAN
  4. Ermittlung der Ablesezeit von einem NTP Server
  5. Erstellen eines JSON Strings
  6. Publish auf MQTT Server (Mosquitto)
  7. Verwenden des DeepSleep Modus beim ESP8266 um Strom zu sparen (für Batteriebetrieb)
  8. FHEM liest die Daten vom MQTT Server und visualisiert diese.

Mosquitto einrichten

Zunächst habe ich den MQTT Server eingerichtet. Ich habe mich hier für Mosquitto entschieden. Das Ganze läuft als Docker Container.

Da die IoT Devices in einem eigenen WLAN Netz befinden, musste die Firewall auf den MQTT Server freigegeben werden.

Zusätzlich wurde eine Benutzerauthentisierung eingerichtet.

das Mosquitto aclfile.conf sieht wie folgt aus:

# this only affects clients with username admin
user admin
topic read $SYS/#
topic readwrite #

# This only affects clients with username esp8266
user esp8266
topic write /environmental_sensors/#

# this affects all clients
pattern write $SYS/broker/connection/%c/stat

Mit mosquitto_passwd kann man dann die Passwörter in die Passwortdatei speichern. Nach einem Reload des Mosquitto (kill -hup) akzeptiert der MQTT Broker die Schreibrequests der IoT Devices auf allen Topics die mit „/environmental_sensors/“ anfangen.

FHEM

Um FHEM an den MQTT anzubinden benötigt man folgende Konfigurationen:

#MQTT - https://haus-automatisierung.com/hardware/fhem/2017/02/13/fhem-tutorial-reihe-part-26-esp8266-arduino-mqtt-temperatur-an-fhem.html
define Mosquitto MQTT mqttServer:1883

# wandelt JSON Strings aus dem reading "data" im Device "mqtt01".
define Jason2Readings01 expandJSON mqtt01:data.*

# Erstellen Device "mqtt01" zum lesen aus dem MQTT Server
define mqtt01 MQTT_DEVICE
attr mqtt01 IODev Mosquitto
attr mqtt01 icon temp_temperature
attr mqtt01 room IoT
attr mqtt01 stateFormat Temperatur: temperature°C<br>Luftfeuchtigkeit: humidity%
attr mqtt01 subscribeReading_data /environmental_sensors/iotLocation

# Logging der Daten aus den readings "temperature" und "humidity"
define FileLog_mqtt01 FileLog /var/log/fhem/mqtt01-%Y-%m.log mqtt01:(temperature|humidity).*
attr FileLog_mqtt01 logtype esp8266-dht22:Plot,text

# Define GPlot zur Visualisierung
define wl_mqtt01 SVG FileLog_diningRoomServerRack:esp8266-dht22:CURRENT
attr wl_mqtt01 label "Klima IoT Device 01"
attr wl_mqtt01 room IoT
attr wl_mqtt01 title "Klima IoT Device 01

Die passende gplot Datei esp8266-dht22.gplot sieht dann so aus:

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
set y2tics
set yrange [0:99]
set y2range [10:50]
set title '<L1>'
set grid xtics y2tics

set y2label "Temperatur in C"
set ylabel "Luftfeuchtigkeit in %"

#FileLog 4:temperature:0:
#FileLog 4:humidity:0:

plot \
  "< awk '/temperature/{print $1, $4}' <IN>"\
     using 1:2 axes x1y2 title 'Temperatur' with lines lw 2,\
  "< awk '/humidity/ {print $1, $4+0}' <IN>"\
     using 1:2 axes x1y1 title 'Luftfeuchtigkeit' with lines\ 

ESP8266

Nun zur eigentlichen Entwicklung des ESP8266. Ich verwende aktuell die Arduino IDE für das Flashen. Hier sind ein paar zusätzliche Bibliotheken zu installieren:

Da ich mit dem DeepSleep Modus des ESP8266 arbeite, ist der Quellcode nur in der standard Funktion „void setup()“ enthalten. Die Funktion „void loop()“ bleibt in dem Fall leer.

Der Kopfbereich des Programms sieht dann so aus:

/* ESP8266 + WiFi connection, DHT22 Humidity and Temperature Node reading
 * and send to MQTT Broker
 */

#include <PubSubClient.h> // @see: "https://pubsubclient.knolleary.net/api.html"
#include <ESP8266WiFi.h>  // @see: "https://arduino-esp8266.readthedocs.io/en/latest/esp8266wifi/readme.html"
#include <DHT.h>
#include <ArduinoJson.h>  // @see: "https://arduinojson.org/"
#include <NTPClient.h>    // @see: "https://diyprojects.io/esp8266-web-server-part-3-recover-time-time-server-ntp/#.W876FvZCSUk"
#include <WiFiUdp.h>
#include <ctime>          // to parse epoch into ISO 8601 Zulu Time String

// initialize the clients
WiFiClient espClient;
PubSubClient client(espClient);
#define DHTTYPE DHT22 // DHT11 or DHT22
#define DHTPIN  2
DHT dht(DHTPIN, DHTTYPE, 11);
WiFiUDP ntpUDP;
NTPClient timeClient(ntpUDP, "ntpServerName", 0, 60000); // 

// The MQTT server connection parameters
const char* mqtt_server = "mqttServerName";
const int mqtt_port = 1883;
const char mqttUser[] = "esp8266"; // MQTT broker user
const char mqttPass[] = "myIoTPasswordForMQTT"; // MQTT broker password
String clientName = ""; // MQTT client name
// The MQTT topics to publish messages to
String topicPrefix = "/environmental_sensors/";
String topicLocation = "iotLocation";
String topic = topicPrefix + topicLocation;

// DeepSleep time in us
long deepSleepTime = 6e8; // 60e6 is 60 Seconds 9e8 is 15 Minutes

Danach folgen ein paar Helfer Funktionen.

/**
 * macToStr - converts a MAC address to a String
 * @param mac: uint8_t* MAC address
 * @return: String the MAC address as String
 */
String macToStr(const uint8_t* mac)
  {
  String result;
  for (int i = 0; i < 6; ++i)
    {
    result += String(mac[i], 16);
    if (i < 5)
      result += ':';
    }
  return result;
  }

/**
 * floatToStr - converts a float to a String
 * @param f: float, the float to convert
 * @param p: int, the precission (number of decimals)
 * @return: String, a string representation of the float
 */
char *floatToStr(float f, int p)
  {
  char * pBuff;                         // use to remember which part of the buffer to use for dtostrf
  const int iSize = 10;                 // number of buffers, one for each float before wrapping around
  static char sBuff[iSize][20];         // space for 20 characters including NULL terminator for each float
  static int iCount = 0;                // keep a tab of next place in sBuff to use
  pBuff = sBuff[iCount];                // use this buffer
  if (iCount >= iSize - 1)              // check for wrap
    {
    iCount = 0;                         // if wrapping start again and reset
    }
  else
    {
    iCount++;                           // advance the counter
    }
  return dtostrf(f, 0, p, pBuff);       // call the library function
  }

Danach kommen die Funktionen für den Verbindungsaufbau und die Datenverarbeitung.

WLAN Verbindungsaufbau:

/**
 * setup_wifi - connects to a WiFi network
 * and log the IP address and MAC of the Device
 */
void setup_wifi()
  {
  const char* ssid = "iot-wlan";
  const char* password = "iotWLANpassword";
  const String clientNamePrefix = "esp8266-";

  delay(10);
  // We start by connecting to a WiFi network
  Serial.println();
  Serial.print("Connecting to ");
  Serial.println(ssid);

  // WiFi only as client
  WiFi.mode(WIFI_STA);
  // Authenticate to WiFi network
  WiFi.begin(ssid, password);

  while (WiFi.status() != WL_CONNECTED)
    {
    delay(500);
    Serial.print(".");
    }

  Serial.println("");
  Serial.println("WiFi connected");

  // get the MAC address of the device
  uint8_t mac[6];
  WiFi.macAddress(mac);

  // log MAC address and IP address
  Serial.print("MAC address: ");
  Serial.println(macToStr(mac));
  Serial.print("IP address: ");
  Serial.println(WiFi.localIP());

  // append MAC Address to clientName to connect to MQTT
  clientName = clientNamePrefix;
  clientName += macToStr(mac);
  }

MQTT Verbindungsaufbau

/**
 * setup_mqtt - connects to MQTT broker and subscribe to the topic
 */
void setup_mqtt(String clientName)
  {
  client.setServer(mqtt_server, mqtt_port);
  Serial.print("Connect to MQTT Broker ");
  Serial.println(mqtt_server);
  if (!client.connect((char*) clientName.c_str(), mqttUser, mqttPass))
    {
    Serial.print("failed, RC=");
    Serial.println(client.state());
    }

  // Loop until we're reconnected
  Serial.print(".");
  while (!client.connected())
    {
    delay(500);
    Serial.print(".");
    }

  Serial.println("");
  Serial.println("MQTT connected");

  // process incoming MQTT messages and maintain MQTT server connection
  client.loop();
  }

Ermitteln des Aktuellen Datums und Uhrzeit per NTP

/**
 * read_ntp - connects to ntp server, make an update and return epoch
 * @return: unsigned long, time in seconds since Jan. 1, 1970 (unix time) 
 */
unsigned long read_ntp()
  {
  // Start NTP client
  Serial.println("Start NTP Client.");
  timeClient.begin();

  // get time
  Serial.println("Get NTP datetime");
  timeClient.update();
  unsigned long epoch = timeClient.getEpochTime();

  // Stop NTP client
  Serial.println("Stop NTP Client.");
  timeClient.end();

  return(epoch);
  }

Auslesen des DHT22 Sensors

/**
 * read_dht - read the DHT22 sensor values and return results
 * @return: String, the mqtt payload of the readings
 */
String read_dht()
  {
  String payload;
  float t, h;

  Serial.println("Try to read from DHT sensor!");
  h = dht.readHumidity();
  t = dht.readTemperature();
  // Check if any reads failed and exit early (to try again).
  while (isnan(h) || isnan(t))
    {
    Serial.println("Failed to read from DHT sensor!");
    Serial.println("Try again in 5 seconds");
    // Wait 5 seconds before retrying
    delay(5000);
    h = dht.readHumidity();
    t = dht.readTemperature();
    }

  Serial.println("DHT Sensor readings:");
  Serial.print(t);
  Serial.println("°C");
  Serial.print(h);
  Serial.println("%");

  // adjust readings
  //h = h * 1.23;
  //t = t * 1.1;

  // convert float to String with precission of 1
  String tPayload = floatToStr(t, 1);
  String hPayload = floatToStr(h, 1);

  // get NTP Time
  unsigned long epoch = read_ntp();
  Serial.print("Zeit von NTP: ");
  Serial.println(epoch);
  // convert to datetime String
  char timestamp[64] = {0};
  const time_t epochTime = epoch;
  strftime(timestamp, sizeof(timestamp), "%Y-%m-%dT%H:%M:%SZ", localtime(&epochTime));
  Serial.println(timestamp);

  // create a JSON object
  StaticJsonBuffer<200> jsonBuffer; // Buffer calculation see "https://arduinojson.org/v5/assistant/"
  JsonObject& root = jsonBuffer.createObject();
  root["datetime"] = timestamp;
  root["location"] = topicLocation;
  root["temperature"] = tPayload;
  root["humidity"] = hPayload;
  // generate json string for MQTT publishing
  root.printTo(payload);
  Serial.println(payload);

  return(payload);
  }

Die Funktion void setup()

/**
 * setup - the main function after booting the microcontroller
 */
void setup()
  {
  // initialize serial console with 115200 bauts
  Serial.begin(115200);
  Serial.setTimeout(2000);
  // Wait for serial to initialize.
  while(!Serial) { }

  // connect to WiFi network
  setup_wifi();

  // connect to MQTT Broker
  setup_mqtt(clientName);

  // read DHT22 temperature and humidity
  String payload = read_dht();
  Serial.println("MQTT message payload to send to topic.");
  Serial.print("Payload: ");
  Serial.println(payload);

  // send payload to topic
  bool topicRetained = true;
  if (client.publish((char*) topic.c_str(), (char*) payload.c_str(), topicRetained))
    {
    Serial.print("published environmental data to topic ");
    Serial.println(topic);
    }
  else
    {
    Serial.print("FAILED to publish environmental data to topic ");
    Serial.println(topic);
    Serial.print("MQTT state: RC=");
    Serial.println(client.state());
    }

  // Wait 20 seconds before proceeding
  Serial.println("Waiting for 5 seconds");
  for (int i = 0; i < 5; ++i)
    {
    Serial.print(".");
    client.loop(); // process incoming MQTT messages and maintain MQTT server connection
    delay(1000); // 1 Second
    }
  Serial.println();

  // disconnecting from MQTT broker
  Serial.println("Disconnecting from MQTT Broker.");
  client.disconnect();

  // Wait 20 seconds before proceeding
  Serial.println("Waiting for 5 seconds");
  for (int i = 0; i < 5; ++i)
    {
    Serial.print(".");
    client.loop(); // process incoming MQTT messages and maintain MQTT server connection
    delay(1000); // 1 Second
    }
  Serial.println();

  // close WiFi connection
  Serial.println("Closing WiFi connection");
  espClient.stop();

  // going into deep sleep
  Serial.println("Going into deep sleep.");
  ESP.deepSleep(deepSleepTime);
  }


/**
 * loop - the ESP loop while the microcontroller is running
 */
void loop()
  {
  }

Ergebnis

Nachdem alles sauber aufgesetzt ist purzeln dann munter im MQTT Topic die Nachrichten rein:

MQTT.fx

Und werden im FHEM dargestellt:

FHEM

Die Ausgabe an der seriellen Console der Arduino IDE sieht so aus:

Arduino IDE

Und so sieht das Board aus (noch nicht zugeschnitten und das passende Gehäuse fehlt auch noch):

 

MQTT mit Eclipse Mosquitto

Zwischenzeitlich läuft das Zugangssystem stabil. In der Zwischenzeit sind einige Umstellungen erfolgt:

  • Umstellung auf Maven für die Java Builds
  • Veröffentlichung einiger OpenSource Artefakte auf Maven Central
  • Installation eines neuen Docker Hosts
  • Installation eines Eclipse Mosquitto MQTT Servers (als Docker Container)

Den MQTT Server hatte ich ursprünglich für die geplante IoT Infrastruktur (mit ESP8266 und ESP32 basierten Sensoren – hier werde ich auch berichten sobald die ersten Sensoren in Betrieb gehen) installiert. Ich habe diesen auf einem alten Raspberry Pi 1 Model A aufgesetzt als Docker Container.

Für das User Management System hatte ich bereits länger geplant einen Access Monitor geplant. Dieser sollte die letzten Zutritte visuell darstellen. Also wer hat wann zuletzt einen Zugang angefragt und wie war der Status dazu. Hier soll unter anderem auch ein Bild des Benutzers kommen angezeigt werden das aus dem LDAP Server geladen wird.

Ich hatte lange überlegt wie man einen solchen Monitor implementieren könnte. Vorallem wie dieser die Daten übermittelt bekommt.

Mit MQTT ist die Sache nun relativ einfach. Das Zugangskontrollsystem muss nur den Status eines Zutritts in einen Topic des MQTT Servers Publishen. Der Zutrittsmonitor subscribed auf diesen Topic und erhält so alle notwendigen Informationen zur Visualisierung.

Für den Publish der Nachricht aus dem Zugangskontrollsystem verwende ich nun den Eclipse Paho Java Client. Die Bibliothek war unkompliziert zu integrieren.
Der Zutritts Monitor ist eine Webanwendung. Für den subscripe verwende ich aktuell Eclipse Paho JavaScript Client. Dieser war etwas Tricky, denn das Beispiel auf der Seite hat bei mir nicht funktioniert.

Folgender JavaScript Sourcecode führte dann zum Erfolg:

<head>
<script> // configuration var mqtt; var reconnectTimeout=2000; var host="myMQTTServer"; var port=9001; var clientId="oitc-acs-monitor"; var topic="/oitc-acs" // called when the client connects function onConnect() { // Once a connection has been made, make a subscription and send a message. console.log("Successfully connected to " + host + ":" + port); console.log("Subscribing to topic " + topic); mqtt.subscribe(topic); } // called when a message arrives function onMessageArrived(message) { // console.log(message.payloadString); obj = JSON.parse(message.payloadString); console.log(obj); } function MQTTconnect() { console.log("Try to open connection to " + host + ":" + port); mqtt = new Paho.MQTT.Client(host,port,clientId); mqtt.onMessageArrived = onMessageArrived; // Valid properties are: timeout userName password willMessage // keepAliveInterval cleanSession useSSL // invocationContext onSuccess onFailure // hosts ports mqttVersion mqttVersionExplicit // uris var options = { timeout: 3, userName: "acsMonitorUser", password: "myUsersPass", keepAliveInterval: 60, useSSL: true, onSuccess: onConnect, mqttVersion: 3, }; mqtt.connect(options); } </script> </head> <body>
<script>
MQTTconnect(); </script>
</body>

Wenn die Seite lädt, verbindet sich die Webanwendung mit dem MQTT websocket und subscribed den topic. Da die Nachrichten „retained“ vom Zugangskontrollsystem gesendet werden, wird auf jeden Fall der letzte Zugriff im JavaScript consolen Log angezeigt. Bei weiteren Zugängen erscheinen diese ebenfalls im Log.

Die nächsten Schritte sind nun die Anzeige auf der HTML Seite. Ich werde hier mit jQuery arbeiten um mir das Leben etwas einfacher zu machen. Einen ersten Prototypen habe ich bereits am Laufen. Die nächste Herausforderung ist nun, das Bild der Person noch aus dem LDAP Server zu laden. Ich werde berichten, sobald ich hier wieder ein Stück weiter gekommen bin.

Abschließend noch das aktuelle Architektur Schaubild:

FEIG Firmware v2.9.0

Seit dem letzten Firmware Update lief nun der Leser eine lange Zeit ohne Abbrüche. Das Prolem scheint wohl gelöst zu sein. Leider hatte mit der Firmware allerdings die Signalisierung der LEDs und des Buzzers am Leser nicht mehr funktioniert.

Nachdem nun einiges an Zeit vergangen ist hatte ich nochmals bei der FEIG nachgefragt ob der Fehler zwischenzeitlich erkannt und behoben wurde.

Prompt erhielt ich schon eine neue Firmware v2.9.0. Nach einspielen der Firmware scheint nun die Ansteuerung der LEDs und Buzzer wieder zu funktionieren. Ob diese Firmware auch stabil läuft wird die Zeit zeigen. Bisher gab es allerdings keine Ausfälle zu verzeichnen.

FEIG OBID Firmware Version 2.8.131

Nachdem nach dem letzten Firmware Update die KeepAlive Abbrüche nicht weggegangen sind habe ich dies der FEIG gemeldet. Da wohl ein anderer Kunde ein ähnliches Problem hat, hat die FEIG für diesen kunden den Netzwerk Stack in der Firmware optimiert. Die FEIG hat mir den Release Candidate für den Leser zum Test zur Verfügung gestellt.

Das Flashen des Lesers mit dem RC ging, wie beim letzten mal, ohne Probleme und das Zugangskontrollsystem hat automatisch die Verbindung zum Leser wieder hergestellt.

Mal sehen ob sich das Problem damit löst, ansonsten muss ich wohl Netzwerk Traces mitlaufen lassen um das Problem genauer zu Untersuchen.

FEIG OBID Firmware Version 2.8.0

Seit Nutzung des Lesers OBID ID CPR.50.10 der Firma FEIG ELECTRONIC GmbH habe ich mit Verbindungsabbrüchen in der Kommunikation des Lesers mit dem Server zu kämpfen. Das Ganze zeigt sich wie folgt:

Im „Notifymode“ kann der Leser KeepAlive Requests an den Server senden. Dies habe ich auf eine recht knappe Zeit (5 Sekunden) eingestellt. In unregelmäßgien Abständen hat der Leser jedoch, ohne erfindlichen Grund, diese KeepAlive Requests eingestellt. Nach einigem Experimentieren habe ich hierfür einen Workaround gefunden.  Im Falle eines ausbleibens der Requests sende ich einen CPU Reset an den Leser. Dies hat meist geholfen.

Leider hat sich das Ganze nach Einschalten der Verschlüsselten Verbindung verschärft. Zum einen kommen die Verbindungsabbrüche nun häufiger und das Senden des CPU Reset hat auch nicht mehr geholfen. Als Alternative könnte ich nun einen System Reset schicken der den gesamten Leser bootet. Habe ich aber nicht weiter implementiert.

Ich tippe hier auf einen Memory Leak im Leser und habe den Bug der Firma FEIG gemeldet. Scheinbar hat noch ein weiterer Kunde diesen Fehler im System und konnte diesen mit dem Firmware Update auf Version 2.8.0 beheben. Der Leser an der Türe hat beim mir die Firmware Version 2.6.0.

Ich erhielt also die aktuelle Firmware und das OBID Firmware Update Tool. In der Beschreibung fand ich allerdings den Hinweis dass die Konfiguration des Lesers beim Flashen zurückgesetzt werden kann. das wollte ich aber auf jeden Fall verhindern. Der Leser ist nämlich fest in der Außenwand verbaut und die Netzwerkkonfiguration mit der Firewall dazwischen ist recht aufwändig umzubauen. Daher bat ich um Klärung in welchen Fällen der Leser die Konfiguration beim Flashen verliert.

Vor einer woche habe ich dann die Antwort vom technischen Support erhalten dass bei einem Update von 2.6.0 nach 2.8.0 die Konfiguration nicht zurückgesetzt wird. Daher habe ich mich heute an den Update gewagt.

Zunächst mit dem Leser an meinem Schreibtisch (bisher Firmware Version 2.7.0).

Das OBID Firmware Update Tool lies sich einfach installieren (Archiv entpacken) und starten. Nach eingabe von IP Adresse und Port findet ws auch sofort den Leser und fragt nach dem Passwort zur Authentisierung. Nachdem man dieses eingegeben hat, kann man die XML Datei mit der neuen Firmware wählen und das Flashen kann beginnen.

Zunächst wird der Bootloader auf Version 1.0.0 gebracht (512 Blöcke) und danach autmatisch die Leser Firmware (2048 Blöcke). Beides ging reibungslos. Nach jedem Flash Vorgang wird der Leser automatisch gebootet (also insgesamt 2 mal).
Am Ende kommt ein Beep und eine Ready Meldung.

Der Start des Zugangskontrollsystems ging danach ohne weitere Modifikationen.

TOP!

Nun muss sich zeigen ob die Verbindungsabbrüche mit der neuen Firmware Version auch wirklich behoben sind. Ansonsten muss ich wohl wieder einen Call aufmachen.

Neues Feig Java SDK 4.8.0

Kuze Info am Rande.

Es gibt ein neues Java SDK von der Firma FEIG Electronic GmbH. Heruntergeladen ist es. Leider ist das SDK nicht kompatibel mit v4.7. Daher musste ich ein paar Anpassungen am Listener vornehmen. Ob das SDK tut wie es soll und ob der SSL Bug damit behoben wurde werde ich die kommenden Tage mal testen.

Ich werde berichten 🙂

Aktuell sieht die Architektur so aus. Mal sehen ob die 2 gelben Verbindungen bald grün werden.

Ergo Open

Ich möchte diesen Blog nutzen, um nicht nur über das Zugangskontrollsystem zu berichten.

Heute möchte ich meinen Lesern (sofern es welche gibt) ein anderes Projekt von mir vorstellen. Es nennt sich „ergo open“ und ist ein berufbezogenes soziales Netzwerk für Ergotherapeuten.

Angefangen hat alles mit einer Freundin die sich 2009 im Raum Freiburg als Ergotherapeutin selbständig gemacht hat (http://www.ergotherapie-langhoff.de/). Als kleines Startup Unternehmen ist das Budget recht klein aber die Arbeit war da und bald brauchte Sie Unterstützung. Damals beschwerte Sie sich darüber, dass das Schalten einer Stellenanzeige so teuer sei und Sie sich den Zeitpunkt gut überlegen müsse.

Ich fragte ein wenig nach und habe herausgefunden dass es (neben den gängigen Jobbörsen) wohl auch Ergotherapie spezifische Portale gab, die aber durchaus tief in die Tasche greifen. Wir haben damals ein wenig darüber philosophiert ob ein freies Portal der Branche helfen könnte. Bei diesen Gedanken blieb es allerdings da ich weder die Zeit noch die Muse hatte mich hier weiter darum zu kümmern.

Anfang 2015, in meinem damaligen Projekt war es mal wieder richtig zäh und ich brauchte unbedingt etwas was mich wieder etwas motivierte, keimte der Gedanke an dieses Portal wieder auf. Aber wie stemmt man solch ein Projekt alleine?
Ich habe mich dazu entschlossen 2 Freunde zu fragen ob diese evtl. daran mitarbeiten wollten und so trafen wir uns zu einem KickOff und ich stellte das Projekt vor, die Kernfunktionen und das Finanzierungskonzept und alle waren begeistert.
Vor allem auch von der Möglichkeit bei der Arbeit einiges zu lernen.

Kernziele im ersten Schritt sind:

  • Skallierbares Framework
  • Kostenfreie Profile für Ergotherapeuten
  • Kostenfreie Profile für Ergotherapiepraxen
  • Kostenfreier Stellenmarkt für Ergotherapeuten

sobald dies etabliert ist und es eine gewisse Nachfrage gibt, ist weiter geplant:

  • Profile für Hersteller von Hilfsmitteln mit der Möglichkeit Hilfsmittel zu präsentieren
  • Ein Forum für den Informationsaustausch
  • Eine Wissensdatenbank mit Beschreibungen und Videos
  • Ein Nachrichtensystem

Nachdem wir uns für den Namen „ergo open“ entschieden haben resservierte ich Mitte März 2015 die Domain und wir fingen an mit der konzeptionellen Arbeit.

Es gab viele Bereiche abzudecken, und wir teilten diese Bereiche zwischen uns auf.
Richard übernahm den Bereich Backend und Patrick die Frontendentwicklung und ich den ganzen Rest dazwischen, Marketing und Rechtliches.
Der Sourcecode wird über einen privaten SVN Server verwaltet, es gibt einen eigenen Entwicklungsserver bei dem der Sourcecode automatisch ausgecheckt wird für Tests.

Da die Arbeit an ergo open neben unserer eigentlichen Arbeit stattfindet, geht die Entwicklung leider nur sehr langsam voran. Wir haben jedoch schon ein paar Dinge erreicht.

  • Aufgrund der guten konzeptionellen Vorarbeit haben wir ein sehr modulares und skallierbares Architekturmodell entworfen.
  • Das Datenbank ERM Modell ist für den aktuellen Funktionsumfang fertiggestellt und installiert.
  • Das Basisframework existiert zwischenzeitlich und nun geht es daran die Applikationen (Inhalte) zu entwickeln
  • Im Entwicklungsbereich kann man sich bereits einloggen (User+PW, Facebook oder Google Login)
  • Datenschutzrichtlinie und AGBs sind ebenfalls fertig

Leider ist im letzten halben Jahr aus Zeitgründen nichts mehr passiert. Aktuell offene Punkte sind:

  • Das Frontend Design und die Auswahl des JavaScript Frameworks
  • Die Benutzerregistrierung und die Benutzerprofilverwaltung

Danach geht die Entwicklung der eigentlichen Inhalte los:

  • Erstellung von Seiten für Ergotherapie Praxen
  • Stellenmarkt

Falls Euch die Idee gefällt und Ihr uns unterstützen möchtet, könnt Ihr über PayPal oder Flattr eine kleine Spende machen (für die laufenden Kosten). Alles ab 50Ct ist willkommen.

Spenden mit Flattr

Server läuft weiterhin aber FEIG SSL Bug weiterhin offen

Am 8. August 2016 habe ich die Version 2 des Zugangskontrollsystems live genommen. Bisher ist nicht viel passiert. Das System läuft ohne murren vor sich hin und verrichtet seinen Dienst ohne Störungen.

Gelegentlich hört der Leser auf KeepAlive Requests zu senden, aber das war schon von anfang an so. Der Workaround mit dem CPU reset funktioniert prima.

Leider ist noch immer die Sache mit der verschlüsselten Kommunikation offen.
Nachdem einige Zeit ins Land gegangen war hatte ich hierzu Anfang der Woche nochmals bei der Firma FEIG nachgefragt wie denn der Stand der Fehlerbehebung sei. Hierauf kam erfreulicherweise die Meldung dass es ein neues JavaSDK (v4.7.0) gibt, bei dem der Fehler auf Linux wohl behoben wurde.
Heute Abend habe ich dann die neue Version installiert und getestet. Aber leider habe ich noch immer das selbe Problem. Nach aktivierung des Crypto Mode kann ich zwar dem Leser Befehle senden aber sobald ich den Listener initialisiere erhalte ich eine Java Exception:

de.feig.FedmException: StartAsyncTask

Dies habe ich eben gemeldet. Mal sehen was passiert.

Zugangskontrollsystem Version 2 ist live

Das Zugangskontrollsystem auf neuer x86 Plattform ist nun seit heute Nachmittag am werkeln. Die Einrichtung des LESv2 war einfach, ebenfalls die Directory Server Migration auf den Server (da ja jetzt mehr Power zur Verfügung steht).

Allerdings war es dann doch nicht ganz so einfach das System zum Laufen zu bewegen. hier gab es 2 Problemchen:

  1. Der SSL connection Bug bei den FEIG Treibern für den RFID Leser scheint in allen Unix Varianten zu existieren und ist wohl nicht nur ein Raspberry Problem. Komisch dass es unter Windows so problemlos funktioniert. Ich habe wie üblich den Technischen Support darüber informiert und hoffe bald eine Antwort zu bekommen. Ich hake nächste Woche mal nach sollte sich bis dahin niemand rühren. Denn jetzt sehe ich keinen Grund mehr für die verzögerte Fehlerbehebung, denn ein Ubuntu sollte bei FEIG ja wohl installierbar sein.
  2. Das System ist seit ca. 1 Woche aufgesetzt, die Software lief hoch und schnurrte, die RFID Chips werden sauber erkannt und an die Authentication Engine weitergegeben. Leider starb genau bei der Initialisierung der LDAP Anbindung der Thread ohne weitere Fehlermeldung. Erst hute kam ich auf die Idee das Dingens mal im Vordergrund Laufen zu lassen und siehe da, eine ClassNotFound Exception. komisch ist nur dass alle JAR Files im Klassenpfad vorhanden sind.
    Das Problem lies sich lösen durch eine nach namen sortierte Übergabe der Java Klassen. Warum genau das geholfen hat ist mir allerdings noch nicht ganz klar.

Ich werde das System nun (ohne Watchdog) schnurren lassen und schauen wie sich das system in Punkto Stabilität verhält.

Was mir bei der Implementation ebenfalls aufgefallen ist, das USB Relaisboard konnte ich bisher nur als root ansprechen. Ich werde hier wohl noch etwas forschen müssen um das udev rule.d Dingens im Detail zu verstehen. Ziel sollte es sein, dass der Server nicht unter Root läuft.

Wenn alles sauber läuft mache ich mich an die Konzeption der beiden Ethernet Schnittstellen. Die 1te wird das Verwaltungsnetz sein und die 2te das Leser Netz. Hier sind dann wohl noch ein paar Firewallregeln auf dem Server angebracht um die Netzte gegenseitig abzuschotten. Wer möchte schon User im eigenen Netz haben die vor der Türe stehen.

Ich werde hier dann wieder berichten sollte ich etwas interessantes zu Berichten wissen.

 

20160801_224023

Zugangskontrollsystem Version 2

Auslöser

Das System lief sauber durch, der Watchdog den ich entwicklet hatte, hat auch seine Arbeit getan. Als wir in Urlaub gingen hatten wir unseren Nachbarn ebenfalls Transponder gegeben. Das System funktionierte bis 3 Tage vor unserer Rückkehr aus den USA.

Seitdem verliert der Server die Verbindung zum Leser. Was auch immer geschah oder wie auch immer es geschah konnte ich bislang nicht ermitteln. Auch lässt sich der Javaprozess nicht mehr starten ohne dass der Prozess sich gleich wieder beendet.

Nun all das hat mich nun bewogen darüber nachzudenken die Plattform zu wechseln.

Plattformwechsel für Version 2

Der proof of concept aus Version 1 war durchaus erfolgreich. Allerdings bin ich mit der Lösung auf dem Raspberry 1 nicht so ganz zufrieden. Folgende Gründe sprechen für einen Plattformwechsel:

  • Die Firma FEIG ELECTRONIC GmbH unterstützt aktuell nur den Raspberry 1 (ARMv6) alle Bemühungen, die ARMv7 Treiber auf dem Raspberry 2 zum Laufen zu bringen, scheiterten bislang.
  • Die Raspberry Treiber (ARMv6) haben bis heute keine Möglichkeit verschlüsselt mit dem Leser zu kommunizieren. Der Bug wurde bereits 2015 gemeldet. Bislang gibt es hier allerdings keine Lösung.
  • Der Raspberry 1 hat leider nur 512 MB Ram, dies hat von Anfang an zu Engpässen geführt.
  • Es gibt beim Raspberry bekannte Probleme mit längeren Laufzeiten, wenn das Betriebssystem auf einer SD-Karte liegt. Das ist zwar schick, aber SD-Karten sind ja für häufige Schreibzyklen nicht ausgelegt.
  • Um Filesystemcrashes bei Stromausfall vorzubeugen kommt die PiUSV zum einsatz. Die Firma CW2 hat allerdings Konkurs angemeldet was bedeutet man müsste sich hier nach einer Alternative umsehen.
  • Das Gehäuse für den Server ist custom made. Ein professionelles, maßgeschneidertes Gehäuse erstellen zu lassen ist relativ teuer (im Vergleich zu den restlichen Komponenten)
  • Die bislang verwendeten Komponenten (PiUSV und PiFaceDigital2) sind sehr Raspberry spezifisch.

Das scheinbar größte Problem für mich war eine vernünftige Alternative für das Relayboard (PiFace) zu finden. Es sollte möglichst Betriebssystem unabhängig sein und mit Java ansteuerbar sein.

Nach einigen recherchen wurde ich bei der Bulgarischen Firma Denkovi Assembly Electronics LTD fündig. Ich entschied mich für das Produkt: USB Four(4) Relay Output Module,Board for Home Automation v2 und orderte dies.
Der Versandt ging zügig und problemlos. Die mitgelieferten Tools funktionierten problemlos unter Windows. Allerdings gab es aktuell keine Beispiele für Java. Ich kontaktierte die Firma und bekam 2 Tage später ein Beispielpaket für Java, welches ich zerlegte und die für mich interessanten Bestandteile herauslöste.
Aktuell habe ich nun eine eigene Java Bibliothek erstellt, mit der ich das Relayboard steuern kann.

Nun brauche ich noch einen neuen Server, der folgende Eigenschaften haben sollte:

  • Passiv gekühlt
  • Klein und stromsparend
  • x86 Technologie (um ein „normales“ Linux darauf laufen zu lassen)
  • richtige Festplatte
  • 2 Ethernet Schnittstellen (um das Lesernetz und das Administrationsnetz zu trennen)
  • mind. 2 USB Ports besser 4
  • passendes Gehäuse

Ich habe mich für den „Low Energy Server v2“ (LESv2) der Firma Thomas-Krenn.AG entschieden. Den Server werde ich noch diese Woche bestellen.

Ich werde über die Entwicklung weiter in diesem Blog berichten.

Bericht zum Betrieb des Zugangskontrollsystems

Nun ist der Prototyp bereits eine Weile in Betrieb. Er macht seine Sache ganz gut bis auf ein paar Kleinigkeiten.

Zum Beispiel wächst die Serverload im Laufe der Wochen an. Man merkt dies auch am Leser selbst wenn der Zeitpunkt von Einlesen der Karte und Verarbeitung auf dem Server wieder über eine Sekunde benötigt. In diesem Fall hilft es, den Prozess einfach durchzustarten.

Im Januar hatte ich einen Servercrash der das Filesystem der SD Karte quasi komplett zerstörte. Seit dem Wiederaufsetzen gab es jedoch keine weiteren Störungen. Leider konnte ich nicht herausfinden wie es dazu kam. In dem Zuge habe ich mir jedoch überlegt einen Teil der Systemschreibzugriffe zu minimieren und auf eine RamDisk auszulagern. Hierzu bin ich allerdings noch nicht gekommen.

Ein Interesanten Phänomen hatte ich im April. Hier ist der Serverprozess abgestürzt (vermutlich das Loadproblem von oben). Der Absturz ist genau dann ausgelöst worden als ein Zugangsversuch vorgenommen wurde. Der Leser wollte die Daten an den Serverprozess zur weiteren Verarbeitung übermitteln. Der Serverprozess hat dies allerdings nicht mehr quitiert und ist gestorben. Nach dem Neustart Abends hat sich dann die Türe geöffnet, da die Transponderdaten noch im Speicher des Lesers hingen. Da es sich hier um eine echte Sicherheitslücke handelt habe ich nun einen CPU Reset des Lesers eingebaut bei der Initialisierung des Serverprozesses. dieser CU reset hilft auch prima bei den gelegentlich auftretenden Verbindungsproblemen vom Leser zum Server. Seit tausch von „Signalisierung triggern“ zu CPU reset triggern hat der Leser die Verbindung gehalten.

Tja und dann gibt es noch die ganzen offenen Punkte aus dem vorherigen Artikel von November. Hier gibt es nicht viel zu Berichten außer dass das mit der RandomUID nicht funktionieren wird.

Ré­su­mé

Das Ding schnurrt vor sich hin und tut seinen Dienst. Mein Sohn und meine Frau finden es toll. Größere Schwierigkeiten (außer dem Filesystem Crash im Januar) gab es bislang nicht. Um einen Absturz des Serverprozesses abzufangen habe ich nun einen Watchdog geschrieben der den Prozess automatisch versucht neu zu starten. Auch das Loadproblem versuche ich nun mit einem Housekeeping Script in den Griff zu bekommen (automatisierter restart des Serverprozesses).

Leider ist der Server (der alte Raspberry) etwas schwach auf der Brust. Daher habe ich bereits über einen Plattformwechsel nachgedacht.

Komerzialisieren

Sollte ich die Lösung vertreiben wollen (wie und in welcher Form ist noch nicht klar) wird es 3 Änderungen geben. Statt dem Raspberry wird ein x86 zum Einsatz kommen (mit 2 Ethernet Schnittstellen für Leser Netz und Management Netz) und statt dem Relaisboard werde ich das externe Relais des Feig Lesers nutzen das es optional zu kaufen gibt. Auf die mini USV werde ich in diesem Design verzichten, da ja keine SD Karte mehr zum Einsatz kommt.
Dieses Redisign wird dann mehr Luft nach oben haben und zusätzlich etwas Balast abwerfen. Es wird hoffentlich auch etwas robuster sein. Aber bis es soweit ist, wird wohl auch noch etwas Zeit ins Land gehen.

Aktueller Stand der Implementation

Heute möchte ich mal wieder über den aktuellen Stand der Implementation berichten.

Allgemein:

2015-11-27-Architektur-Schaubild

  • Die Konfigurationsdatei auf dem Server wurde auf das nötigste reduziert.
  • Der workaround mit dem Benutzerrepository als Propertiesdatei wurde mit dem neuen OpenLDAP Backend abgelöst.
  • Die Initialisierung der Karten schreibt automatisch in das LDAP Backend
  • Die Generierung eines random secret per Transponder Chipkarte findet nun automatisiert bei jeder Initialisierung neu statt und landet ordnungsgemäß im LDAP Backend.
  • Die Methode zur Ermittlung der Karteninhalte wurde zentralisiert.
  • Mails werden nun in einem Hintergrund Thread versendet um die Zeit beim Verbindungsaufbau zum Mailserver nicht im Authentisierungsprozess mit dabei zu haben.
  • Die Authentisierung als extra background thread zu integrieren habe ich wieder zurückgenommen. Der Leser liest einfach die Karten im Feld zu schnell aus und da kam es zu mehrfach Authentisierung.
  • Monitor integriert um Verbindungsabbrüche vom Leser zu erkennen um ggf. Aktionen einzuleiten.
  • Serverüberwachung in die FHEM Console integriert (CPU / Load / Speicher / Prozesse / Swap)

Offene Punkte:

  • Der Call bei der FEIG bezüglich der fehlenden SSL Implementierung in den Raspberry Treibern ist noch offen. Hier warte ich auf ein neues Release das bislang nicht angekündigt wurde.
  • Call bei der FEIG eröffnet bzgl. der RandomUID Option der DESFire Karten. Die reale UID wird wohl bei der Authentifizierung nicht ausgelesen und übermittelt.
  • Monitoring Thread erkennt aktuell potentielle Verbindungsabbrüche zwischen Leser und Server. Er schickt daraufhin einen Notifizierungsrequest um den Leser wieder aufzuwecken. Das ist aktuell nur ein Versuch um hinter das Problem zu kommen.
    Evtl. muss ich hier auch noch einen Call bei der FEIG aufmachen.
  • LDAP Kommunikation mit SSL verschlüsseln
  • Ordentlicher Stop-Mechanismus für den Serverprozess
  • Planung und Entwicklung eines grafischen Frontends um die Daten (Benutzer, Transponder, Zugangspunkte, Rollen und Regeln) zu verwalten. Hier bin ich noch am Überlegen ob ich für die Verwaltung einen WebService entwickle oder eine Android App. Ersteres wäre generisch und letzteres stylisch und hip. 🙂

Der erste Monat Testzeitraum

Vor ca. 1 Monat habe ich das Zugangskontrollsystem in Betrieb genommen. Seit dem gab es die ein oder anderen Problemchen.

  1. Der Server schmiert mit einem OutOfMemory ab
  2. Bei Notifikation per Mail (kann man bei Rollen hinterlegen) kann es zu Verzögerungen von bis zu 30 Sekunden kommen.
  3. Der Leser hört auf, KeepAlive requests zu senden

Das erste Problem war relativ schnell gelöst. Schuld war hier die Temparaturmessung des Raspberry. Bei, Auslesen von /proc gibt es hier manchmal einen deadlock. Ich hoffe dass dies bei dem ein oder anderen OS Update behoben wird. Vorläufig habe ich die Temparaturmessung aber deaktiviert.

Das zweite Problem hoffe ich nun so zu lösen, indem ich meine Klasse hierzu mit „Runnable“ ausstatte und die Klasse zur Laufzeit initialisiere und dann im Hintergrund die Mail versenden lasse. Warum nicht multi threading nutzen wenn es die Plattform hergibt.

Das dritte Problem bin ich nur am Rande angegangen. Hier muss ich erst noch ein paar Informationen sammeln. Hierzu habe ich meinen Monitor Thread umgebaut und berechne nun die Zeit, die zum letzten KeepAlive vergangen ist. Wenn hier ein Schwellwert überschritten wird, sende ich einen Befehl an den Leser. Ich möchte versuchen Ihn darüer zu bewegen wieder KeepAlive Requests zu senden.

In dem Zuge habe ich nun auch die LDAP Anbindung eingebaut und die Authentication Klasse ebenfalls als Hintergrundthread implementiert. Dadurch kommt der Notify Thread schneller zurück und kann dadurch schneller neu getriggert werden.

Die Optimierungen und Bugfixes habe ich zwischenzeitlich alle im Programm, jedoch steht der Test noch aus. Ich hoffe dies morgen durchführen zu können. Aktuell sitz ich nämlich in Katzenelbogen in einem Café fest und warte auf meine Frau. 🙂

Der erste Zugriff beim ACS Prototyp

Der Kartenleser wurde letztes Wochenende an der Fassade vor der Haustüre montiert. Der Umbau des Netzwerks erwies sich leider als nicht als so einfach (Stichwort 1&1 VoIP Telefonie mit Telefonen in einem privaten Netzwerksegment).

Nach dem Umplanen der Netzwerkumgebung und dem erneuten Aufsetzen der Firewall konnte ich heute den ersten erfolgreichen Zugriff auf das entwickelte System inklusive Türöffnung verzeichnen (siehe Log):

1st_access

Offene Punkte sind:

  • Logfile mit UTF-8 encoding
  • PoE Injektor besorgen für zusätzlichen RFID Leser (der kam heute an)
  • RFID Medien bestellen (Schlüsselanhänger und Armbänder)
  • RandomUID Option bei Karteninitialisierung aktivieren
  • Kommunikationsproblem zwischen Server und Leser lösen das nur auf dem Raspberry auftritt (Call bei Feig ist bereits offen)
  • Batterie für PiUSV
  • OpenLDAP Anbindung realisieren