Server läuft weiterhin aber FEIG SSL Bug weiterhin offen

Veröffentlicht am von
Antworten

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

Veröffentlicht am von
Antworten

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

Veröffentlicht am von
Antworten

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

Veröffentlicht am von
Antworten

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

Veröffentlicht am von
Antworten

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

Veröffentlicht am von
Antworten

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

Veröffentlicht am von
Antworten

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

 

Benutzer Datenverwaltung auf Basis von OpenLDAP 2.4

Veröffentlicht am von
Antworten

Seit dem Wochenende tüftle ich an der „Users DB“. Zwischenzeitlich habe ich mich dazu entschlossen hierfür einen LDAP Server einzurichten, denn die meißten Zugriffe sind lesender Natur. Des weiteren kommt mir die die objektorientierte Ablage der Daten entgegen. Was noch dafür spricht, ich kannte mich mit LDAP vor einiger Zeit noch recht gut damit aus und da hier das ein oder andere hängen blieb geht es sicherlich recht schnell. 🙂

LDAP Schema Definitionen

Leider gibt es kein LDAP Schema für RFID Tags (im speziellen die verwendete DESFire EV1), daher habe ich nun selber eines entwickelt was die bisher meißte Zeit in anspruch nahm. Zum glück hatte ich vor einigen Jahren eine eigene OID bei IANA beantragt (siehe: Cybcon Industries) und habe nun für die Michael Oberdorf IT-Consulting (unter diesem Label wird das System  entwickelt) eine eigene unter Nummer definiert.

Zunächst habe ich das RFID DESFire Schema und das Schema für das System zusammen definiert, aber da das DESFire Schema sehr umfangreich wurde, habe ich dieses nun getrennt. Die verwendeten OID Räume sind wie folgt definiert:

1.3.6.1.4.1     15432     3     -     Namensraum von Michael Oberdorf IT-Consulting
1.3.6.1.4.1     15432     3     1     OITC RFID Tag representation (DESFire EV1 specific):
                                      Attribute: 1.3.6.1.4.1.15432.3.1.1.n
                                      Objektklasse: 1.3.6.1.4.1.15432.3.1.2.n
1.3.6.1.4.1     15432     3     2     OITC Access Control System:
                                      Attribute: 1.3.6.1.4.1.15432.3.2.1.n
                                      Objektklasse: 1.3.6.1.4.1.15432.3.2.2.n

Der aktuelle Stand ist hier zu finden:

OpenLDAP Installation und Konfiguration

Hier war ich faul und habe die Debian Luxus Methode gewählt. Ist ja auch nicht ganz so zickig wie ein OpenBSD. 🙂

apt-get install ldap-client ldap-server ldap-utils libldap-2.4-2 libsasl2-modules libsasl2-modules-otp libsasl2-modules-ldap libsasl2-modules-gssapi-heimdal

Danach findet sich ein standard OpenLDAP auf dem System:

  • Konfiguration: /etc/ldap
  • OpenLDAP Backend Module: /usr/lib/ldap
  • OpenLDAP Datenbank: /var/lib/ldap
  • OpenLDAP schreibt sein Log im Standard via LOCAL4 ins Syslog: /var/log/syslog

Vorteil dieser Methode:

  • Das configuration Backend (cn=config) wird bereits angelegt
  • Das Root Objekt existiert
  • Man kann sich nach der Installation sofort auf die Datenbank verbinden

Nachteil dieser Methode:

  • Es fehlt die Datei „/etc/ldap/slapd.conf“
  • der Zugriff auf „cn=config“ ist nicht möglich da die Berechtigung fehlt (geht nur über einen schmutzigen Workaround)
  • Schema- und Konfigurationsänderungen sind recht mühselig (das ist wohl aber ein persönliches Empfinden)

Daher bin ich nun so vorgegangen dass ich das Konfigurations Backen auf Basis der aktuell eingestellten Werte in eine Standard slapd.conf Datei übertragen habe. Diese Datei wurde dann um das neu erstellte Schema erweitert. In dieser Datei sind zudem eine vernünftige Berechtigungsstruktur hinzugekommen, die notwendige Indizierung der Attribute (hier war im Standard tatsächlich nur die objectClass indiziert), das montoring Backend wurde konfiguration sowie die ein oder anderen Tuningparameter für die DBs hinterlegt.
Um das Ganze abzurunden, habe ich auch für die Sleepycat DB ein wenig die Konfiguration optimiert. Diese DB_CONFIG Datei muss im übrigen im Datenbankverzeichnis abgelegt werden. darin habe ich unter anderem das Transaktions Logging aktiviert.

Hier die OpenLDAP Konfiguration:

Die Daten für die Datenbank kann man im LDIF format vorbereiten.
Die Datenbank wird dann wie folgt initialisiert:

/etc/init.d/slapd stop
slapadd -f /etc/ldap/slapd.conf -l /etc/ldap/dit.ldif
chown -R openldap:openldap /var/lib/ldap/slapd-001

Wer möchte, kann dann das Konfigurationsbackend wieder wie folgt anlegen:

rm -rf /etc/ldap/slapd.d/*
slaptest -f /etc/ldap/slapd.conf -F /etc/ldap/slapd.d
chown -R openldap:openldap /etc/ldap/slapd.d

ich hab mir das gespart.
Am Ende den Server dann wieder starten:

/etc/init.d/slapd start

Nun muss sich noch herausstellen ob die Verbindung (vorallem der Verbindungsaufbau) schnell genug ist für die Benutzervalidierung. Aber hierzu muss ich das ACS noch um die LDAP Funktionalität erweitern. eine passende Java Lib habe ich mir jedenfalls noch nicht herausgesucht.

 

BinTec RS353jw

Veröffentlicht am von
Antworten

Also gestern hatte ich wieder eine Überraschung erlebt. Ich war am Mittwoch Nachmittag auf der Suche nach einem günstigen Angebot für eine BinTec RS353jw und bin bei Klarsicht-IT fündig geworden. Nach einigem hin und her (man kann das Produkt dort nur als Gewerbetreibender bestellen) hat die Bestellung dann doch geklappt.

Erstaunlicherweise war die Firewall dann am Folgetag bereits bei mir im Haus. Das nenn ich mal spitzen Logistik!

Zum Einrichten der Firewall bin ich leider noch nicht gekommen. Plane ich aber für die nächsten Tage.

RFID TAG Initialisierung (3rd try) und Entwicklungsstand

Veröffentlicht am von
Antworten

2015-09-23-Architektur-SchaubildEs ist vollbracht 🙂

Vor ein paar Minuten hat mein Zugangs-Kontrollsystem eine vollständig Initialisierte Karte, mit Hilfe des rollenbasierten Zugriffsschutzes, validiert und mir den Zugang gewährt!

Nach einigen Tagen Dokus im Internet suchen/lesen/verstehen, nach einigen Tagen reverse Engineering bin ich nun doch zu einem ersten Beta gekommen.

Auf meiner ToDo Liste sind nun folgende Dinge:

  • Aufräumarbeiten im SourceCode um mehrfach genutzte Methoden in eine bzw. mehrere HelperKlasse(n) auszulagern.
  • Die Klasse ConfigFile erweitern um Methoden um gleich den passenden Datentyp zurück zu bekommen (String, Boolean, Integer, Byte).
  • Den Status des Türschlosses übermitteln auf den Server und entsprechend behandeln (Signal wenn Authorisiert, die Türe aber verriegelt ist).
  • Eine vernünftige Abbruchbedingung implementieren
  • Fixen des Bugs im „Card Management System“ zum Schlüsseltausch des PICC MasterKey (Default ist DES, ich will aber AES und die JavaSDK gibt das m.e. im Moment nicht her obwohl es via ChipMan funktioniert. Sollte also irgendwie gehen). Hier warte ich noch auf eine Lösung vom Technischen Support bei der Feig.
  • Das SDK und die zugehörigen Bibliotheken auf dem Raspberry installieren
  • Das Java Programm auf den Raspberry portieren und mit der PiFaceDigital 2 Klasse testen (und damit die Haustüre öffnen).
  • Ach ja und danach:
    • Firewall kaufen und einrichten
    • 2ten RFID Reader kaufen und einrichten (zur Karten Initialisierung)
    • RFID Tags kaufen, personalisieren und verteilen

NXP DocStore – Account Request rejected

Veröffentlicht am von
Antworten

Gestern Nachmittag kam die erste Absage für den Zugang zum NXP DocStore (Mail, siehe unten).

Ich werde da mal an den Support schreiben, obwohl ich so langsam Zweifel habe ob mir die Doku noch etwas bringt. Denn ich bin kurz davor eine lauffähige Beta Version des Zugangskontrollsystems fertigzustellen.

Und wenn ich eine NDA unterschreibe, darf ich ja keine Details mehr veröffentlichen 😉

 

 

  DocStore
Dear Michael,

Your registration at NXP DocStore cannot be executed. The account will not be activated due to the rejection reason shown below:

we can´t approve registrations without valid NDA. If you feel you receive this message in error, please contact NXP by using the support email address mentioned below.

Kind regards,
The NXP DocStore Team
NOTE: This mail has been generated by the DocStore system, please do not reply directly to this mail, as it is not monitored. In case of questions or problems please contact DocStore Support.

BadgeMaker

Veröffentlicht am von
Antworten

Das Angebot zum BadgeMaker kam an.

Der Vertriebspartner in der Region ist wohl:

PP high tech e.K.
Goldenbühlstrasse 12
78048 Villingen-Schwenningen

www.pphightech.com

Und hier die Brutto Preise:

  • BadgeMaker Pro (alle add-ons drinnen) kostet: 1.069,81 Euro
  • BadgeMaker Base (+ encoding add-on) kostet: 1.035,30 Euro

Übersteigt leider ein wenig das Budget. Werde wohl daher selber programmieren müssen (bin da auch schon etwas weiter gekommen).

CPU und GPU Temperatur Statistiken vom Server auf FHEM darstellen

Veröffentlicht am von
5

Bereits vor einer Weile habe ich auf „The Linux Terminal“ folgenden Artikel gefunden: http://www.thelinuxterminal.com/raspberry-pi-b-cpu-gpu-temperature-monitor-bash-script-source-code/

Zwischenzeitlich habe ich das Beispielskript etwas angepasst:

#!/bin/bash
#Raspberry Pi Temperature Monitor
#Built by Zeus-www.thelinuxterminal.com
#For more info, drop a mail: office@thelinuxterminal.com
# http://www.thelinuxterminal.com/raspberry-pi-b-cpu-gpu-temperature-monitor-bash-script-source-code/
cpugpu_logfile="/var/log/`hostname`_cpugpuTemp-$(date "+%Y-%m").log"
get_date=$(date +%d/%m/%y)
get_time=$(date +%H:%M)
cpuTemp0=$(cat /sys/class/thermal/thermal_zone0/temp | cut -d '=' -f2)
cpuTemp1=$(($cpuTemp0/1000))
cpuTemp2=$(($cpuTemp0/100))
cpuTempM=$((cpuTemp2 % $cpuTemp1))
gpuTemp=$(/opt/vc/bin/vcgencmd measure_temp | cut -d '=' -f2)
gpuTemp=`echo NULL | sed -e "s/'C//"`
get_date_time=$(date "+%Y-%m-%d_%H:%M:%S")
echo "NULL cpuTemp: NULL.NULL" >> $cpugpu_logfile
echo "NULL gpuTemp: NULL" >> $cpugpu_logfile

Das script wird nun via Crontab aufgerufen und schreibt die Daten in die Datei.

Mir rsync hole ich das geschriebene Logfile von meinem FHEM Server ab und kann es nun mit folgender gplot Datei den Temperaturverlauf grafisch darstellen.

############################
# Display the measured temp of CPU and GPU
# Corresponding FileLog definition:
# Example Log
#2015-09-18_09:09:44 cpuTemp: 43.3
#2015-09-18_09:09:44 gpuTemp: 43.3
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 ytics
#set yrange [:60]
#set y2range [30:50]
set title '<L1>'
set grid xtics ytics
set y2label "Temperatur in °C"
set ylabel "Temperatur in °C"
#FileLog 3:cpuTemp:0:
#FileLog 3:gpuTemp:0:
plot \
  "< awk '/cpuTemp/{print $1, $3}' <IN>"\
     using 1:2 axes x1y1 title 'CPU Temperatur' with lines lw 1,\
  "< awk '/gpuTemp/{print $1, $3}' <IN>"\
     using 1:2 axes x1y1 title 'GPU Temperatur' with lines lw 1

Das Ergebnis:

cpu_gpu_temperatur

Ziel ist es nun herauszufinden wie sich der Server bei geschlossenen Gehäuse verhält und ob ich noch Kühlkörper für den Raspberry besorgen und/oder einen Lüfter in das Gehäuse einbauen muss.

PiUSV+ Tests

Veröffentlicht am von
1

Heute früh, vor der Arbeit, hatte ich ein wenig Zeit 2 bis 3 Tests mit der PiUSV+ durchzuführen.

  1. Das PiFace Digital 2 abgedockt (aufgrund eines Forumeintrags)
    Ergbnis: hat keine Auswirkung ob das PiFace Digital 2 dran ist oder nicht
  2. Den Akku an den alternativen Stromanschluß angeschlossen bei ausgeschalter Stromversorgung (ja ich weiß, da müssen mindesten 5 Volt anliegen)
    Ergebnis: Server hat kurz geleuchtet, Raspberry oder PiUSV+ hat gepfiffen und dann ging der Server wieder aus. (Idee: Evtl. reichts für nen shut down
  3. Den Akku an den alternativen Stromanschluß angeschlossen bei eingeschalter Stromversorgung und dann den Strom abschalten.
    Ergebnis: Im Log tauchte ein Status Wechsel auf (Batterie wird jetzt geladen), danach war der Raspberry tot. Die PiUSV+ auch.

Nachdem nach Versuch 3 die PiUSV+ dunkel bleib, selbst nachdem der Strom wieder da war. Batterie abgeklemmt un die PiUSV+ auch vom Raspberry genommen um zu sehen ob ich die PiUSV+ oder auch gleich der Raspberry bei dem Versuch vernichtet habe. 🙂

Nach einem sauberen Stromschlag hab ich noch das Kabel vom Stecker gezogen.
Achja, wie war neulich der Kommentar von einem Freund:

Wie hat mein alter „Praktische Fachkunde“-Lehrer früher immer gewarnt: Stromschläge können auch Stunden später noch Herzkammerflimmern auslösen. Dann gehst Du abends ins Bett und denkst, es ist ja nichts passiert. Und am nächsten Morgen wachst Du auf und bist tot.

Also habe ich mir die 5 Sicherheitsregeln mir wieder ins Gedächtnis gerufen (wie mussten die im Schlaf herunterbeten können) die ich hier gerne mit der Welt teile:

  1. Spannungs freischalten
  2. Gegen Wiedereinschalten sichern
  3. Spannungsfreiheit feststellen
  4. Erden und Kurzschließen
  5. Benachbarte, unter Spannung stehende Teile abdecken oder abschranken

OK, nach diesem kleinen Exkurs in „Wie mache ich es nicht!“ und „Wie mache ich es besser!“ nun weiter im Kontext.

Glücklicherweise bootete der Raspberry sauber (ohne jegliche aufgesteckte Komponenten). Danach wieder heruntergefahren und mit der PiUSV+ nochmals getestet und siehe da, auch die scheint hartnäckig zu sein. 🙂

Nun habe ich doch wieder alles zusammengebaut und bin so weit wie vorher. (Relais lässt sich auch noch schalten, also ist am SPI Bus auch alles OK).

Ich werde nun noch etwas auf einen Kommentar von CW2 bei Facebook warten. Und nächste Woche mir wohl einen anderen Akku kaufen.
Im PiUSV Forum gab es da nämlich einenThread: „Battery spec for the PiUPS+„. Hier verweist CW2 in einer E-Mail wohl auf folgende Beispiel Batterie:

PiUSV+ – Umfrage von CW2

Veröffentlicht am von
Antworten

Bereits am 28. Juli 2015 erreichte mich eine Umfrage von CW2 bezüglich meiner gekauften PiUSV+.

Sehr geehrte/r Pi USV+ Nutzer/in,

Sie sind einer der allerersten der unsere Pi USV+ für den Raspberry Pi bereits bekommen hat. Da wir als Hersteller stets bemüht sind, unsere Produkte zu optimieren und zu verbessern, wären wir Ihnen für eine Rückmeldung zu Ihren persönlichen Erfahrungen sehr dankbar.

Besonders wichtig wären für uns folgende Themen:
1. Ist Ihr Pi USV+ bei Ihnen im Einsatz?
2. Wenn ja, wofür wird er verwendet bzw. welches Gerät steuern Sie über den Raspberry Pi ?
3. Welche Erfahrungen haben sie mit dem Handling der Pi USV+ gemacht?
4. Gab es technische Probleme oder Fehler beim Betrieb?
5. Welche Verbesserungen würden Sie bei der Pi USV+ empfehlen?

Wir freuen uns auf Ihr Feedback und bedanken uns im Voraus für Ihre Bemühungen.

Ihr Feedback können Sie uns per E-Mail mitteilen oder senden uns Ihre Rufnummer und Ihre dortige Erreichbarkeit. Wir werden Sie dann innerhalb von 24 Stunden kontaktieren und offene Fragen mit Ihnen klären.

Mit freundlichen Grüßen
Ihr Pi USV+ Team

 

Nun habe ich heute geantwortet und folgendes geschrieben:

Hallo,
hier ein paar Infos von meiner Seite:
zu 1. Ist Ihr Pi USV+ bei Ihnen im Einsatz?
Ja und nein, ich habe die PI USV+ eingebaut und für den Raspberry PI (B+) mit den Erweiterungen auch ein eigenes Gehäuse gebaut.
zu 2. Wenn ja, wofür wird er verwendet bzw. welches Gerät steuern Sie über den Raspberry Pi ?
Der Raspberry PI ist Teil eines eigen entwickelten RFID basierten Zugangskontrollsystem. Jedenfalls ist das der Plan. Aktuell
bin ich noch an der Entwicklung der Software. Dies kann man auf meinem Blog verfolgen: https://blogger.cybcon.de/
zu 3. Welche Erfahrungen haben sie mit dem Handling der Pi USV+ gemacht?
Das Handling der PI USV+ ist gut. Die Bohrlöcher in der Platine sind ein wenig zu klein für eine M3 Schraube, ich musste hier etwas nacharbeiten.
Der Ein/Aus-Schalter war mir anfangs nicht aufgefallen, aber nach Studium Ihrer Dokumentation war es dann klar.
zu 4. Gab es technische Probleme oder Fehler beim Betrieb?
Leider habe ich noch Probleme mit dem verwendeten Akku der von der USV irgendwie nicht akzeptiert oder erkannt wird.
Hier habe ich auch einen Post auf Facebook hinterlassen.
Leider kam noch kein Feedback, daher kann ich noch keine Details berichten und auch die PI USV+ noch nicht 100% in Betrieb nehmen.
zu 5. Welche Verbesserungen würden Sie bei der Pi USV+ empfehlen?
Ja, folgende Vorschläge hätte ich:
– die Bohrlöcher der Platine sollten so groß sein dass eine M3 Schraube hindurch passt
– die Bezeichnung der Plus- und Minuspole auf der Platine für den Anschluß der Batterie bzw. der zusätzlichen Stromquelle
  ist nich „sofort“ erkennbar was ggf. einen Handlingfehler geben könnte wenn man sich den Schaltplan nicht vorher genau
  ansieht. Evtl. könnte man hier Farbig kennzeichnen.
– die Anschlüsse mit den Klemmen sind zwar einfach aber ich fände einen kleinen Schraubanschluß besser bedienbar. Das wäre vor allem
  beim Entfernen der Kabel von Vorteil.
– Die Auswahl des Akku hat mir und macht mir noch immer Kopfzerbrechen. Mit den Angaben in der Doku hat man es schwer. Es wäre hilfreich wenn
  man ein paar Akkutypen als Beispiele finden könnte wo man weis das es damit funktioniert.
  Mit meiner Auswahl „Panasonic NCR18650B Lithium Ionen Akku“ scheint es jedenfalls nicht zu tun obwohl ich denke das er genau in die angegbene Spec passt.
  Im Moment bin ich hier etwas ratlos und wäre um Beantwortung meiner Anfrage auf Facebook dankbar.
Noch etwas zum Bestellvorgang:
– die Kommunikation mit den Kunden könnte besser sein
  ich persönlich bin da ja eher entspannt aber es gab doch die ein oder anderen
  „unentspannte“ Personen im Forum und auf Facebook. Evtl. sollte man etwas an der
   Aussenwirkung und dem PR arbeiten.
– Ich hatte Ursprünglich 2 PI USVs bestellt aber vor Auslieferung eine davon wieder storniert.
  Ich hatte hier dann an unterschiedlichen Tagen auch beide bekommen aber eine wieder
  persönlich bei Euch eingeworfen (das war am Tag der CSD Parade).
  Ich warte leider seither auf die Rückbuchung der doppelt bezahlten PI USV+ und wär dankbar
  wenn sich dem jemand annehmen könnte, denn auf Anfragen bekomme ich kein Feedback.
Für Rückfragen stehe ich Ihnen gerne zur Verfügung.