Archiv der Kategorie: Access Control System

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.

 

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

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.

Initialisierung von Karten (2nd try)

Veröffentlicht am von
Antworten

Im Moment bin ich an der Erstellung des „Card Management Systems“.
Das Thema mit der DESFire Kommunikation hat mich nun wieder eingeholt. Daher habe ich wieder angefangen nach den DESfire spezifischen APDUs zu suchen.

Um an die NXP Dokumentation „MIFARE DESFire – Implementation hints and examples,document number: 094532″ heranzukommen, habe ich nun auch einen Account im NXP Docstore beantragt. Mal sehen ob die sich melden, denn zu meinem eröffneten Ticket bei NXP.xom gab es in den letzten 3 Monaten keine Reaktion (selbst nach Rückfrage).

Den logischen Ablauf stelle ich mir wie folgt vor:

  1. RFID tag formatieren
  2. PICC Applikation formatieren
  3. Keys ablegen
  4. Kommunikation mit RFID tag verschlüsseln
  5. PICC Applikation konfigurieren (z.B. Random UID)
  6. Applikation anlegen und Konfigurieren
  7. Kommunikation Applikation mit Keys sichern
  8. File anlegen
  9. Kommunikation File mit Keys sichern
  10. Initiale Daten in File schreiben

Kaufsoftware oder selber machen

Die Frage stellt sich mir auch wieder. Es gibt einiges an Kaufsoftware mit der man die Karten konfigurieren kann. [1][2] Allerdings sind diese relativ teuer. Der ChipMan kostet (mit DESFire Funktionalität) immerhin 798 Euro (Stand November 2014). Die Vollversion sogar 1598 Euro. Nichts desto trotz frage ich derzeit auch die Preise für BadgeMaker an.

Parallel hierzu versuche ich natürlich mit der Feig SDK weiter zu kommen. Leider ist das SDK nicht wirklich gut Dokumentiert. Hauptinformationsquelle ist das Tutorial Dokument das allerdings nicht vollständig ist.
Am Montag habe ich den tagHandler für MIFARE DESfire entdeckt, mal sehen ob ich hier weiter komme. Ich habe gemerkt das mit dem Protokoll wissen (APDUs) das Feig SDK etwas besser zu durchschauen ist. Daher auch der erneute Versuch an die MIFARE Doku zu kommen. Meine Internet-Recherche hat allerdings wieder ein paar interessante Quellen aufgetan (siehe [3] bis [6]).
Wenn ich nicht weiterkomme muss ich wohl wieder mal den technischen Support der Feig bemühen mir zu helfen.

Links:

[1] MP-Sys – ChipMan: http://www.mpsys.de/
[2] ScreenCheck BV – BadgeMaker (mit Encode add-on) http://en.badgemaker.info/
[3] Ridrix’s Blog – APDU commands: https://ridrix.wordpress.com/tag/mifare-desfire/
[4] NXP – MIFARE DESFire as Type 4 Tag: http://www.nxp.com/documents/application_note/AN11004.pdf
[5] Jérémie Laval’s page – A Philips Datasheet: http://neteril.org/files/M075031_desfire.pdf
[6] SmartCard Networking Forum – DESFIRE Specification: http://www.scnf.org.uk/smartstore/LASSeO%20docs/DESFIRE%20Specification%20V1%200.pdf

Gehäuse fertig, Open Collector vs Rellais und PiUSV+

Veröffentlicht am von
1

Gehäuse

Also nun ist es am Wochenende doch noch fertig geworden. Blau-Metallic lackiert sieht es schon recht schick aus.

20150912_11204020150912_12090420150912_120914

PiFace Digital 2

Nach dem Zusammenbauen habe ich den OpenCollector Ausgang nochmals geprüft, dabei ist mir aufgefallen dass der Ausgang auf Masse gezogen wird wenn der Server aus ist. Das ist nun doch etwas ungünstig, denn bei einem Server Ausfall würde ja dann die Türe aufgehen. Daher bin ich nun doch kurzfristig umgestiegen auf das Relais.
Da der Traffo genug Power hat (10 Ampére) konnte ich das PiFace Digital 2 auch direkt mit Strom versorgen.

PI USV+

Leider ist mir noch etwas aufgefallen für das ich derzeit noch keine Lösung habe. Der Akku der für die Notfall-Stromversorgung da sein sollte funktioniert nicht wie gewünscht. Die PI USV+ hat 4 Status LEDs. Aber das Bild das ich hier sehe gibt es in der Doku nicht.

In der Doku (Kapitel 2.1, Seite 7) steht folgendes:

  • LED1 (Rot): Betrieb über Akku
  • LED2 (Gelb): Status Anzeige des Akkus. LED Blinkt: Akku wird geladen, LED leuchtet dauerhaft: Akku ist voll
  • LED3 (Grün): Status Anzeige PiUSV+. LED Blinkt: USV funktioniert ordnungsgemäß
  • LED4 (Grün): Betrieb über Primäreingang

Nun zeigt sich bei mir folgendes Bild:

  • LED1: blinkt schnell
  • LED2: ist aus
  • LED3: blinkt langsam
  • LED4: leuchtet dauerhaft

Das sehe ich, ob ich nun einen Akku dran habe oder nicht. Als Akku verwende ich derzeit einen Panasonic NCR18650B Lithium-Ionen Akku (3400mAh).

Gemäß PiUSV+ Doku (Kapitel 2.2, Seite 7) muss der Akku folgende Spezifikationen aufweisen:

  • Technologie: Lithium Ionen (LiIon) oder Lithium Polymer (LiPo)
  • Zellen: 1
  • Kapazität: min. 300mAh
  • Spannung: +3.7V
  • Entladestrom: min. 3A
  • Ladespannung: +4.2V
  • Ladestrom: 100mA

sollte demnach passen. Aufgeladen ist der Akku auch. Keine Ahnung was da jetzt los ist. Das Gehäuse lasse ich aber bis zur Lösung wohl offen.

Hab auch mal bei de PiUSV Facebook Seite nachgefragt (Link zum Post).

Links

 

Gehäuse „fast“ fertig

Veröffentlicht am von
Antworten

20150911_132828

Das Servergehäuse wär quasi „fast“ fertig. Ich möchte es jetzt noch lackieren damit es gut aussieht. Aber funktional wäre es schon einmal.

Im Moment bin ich mir auch noch nicht sicher ob ich noch einen Lüfter einplanen muss. Das überlasse ich der Temparatur Auswertung. 20150911_131817

Die Anschlüsse und Kabel sind zwischenzeitlich auch alle verlötet oder gekrimpt. Sobald das Gehäuse dann so aussieht wie gewünscht, geht es an das zusammenschrauben.

Wie geht’s weiter

Veröffentlicht am von
Antworten

Hier nur ein sc2015-09-10-Architektur-Schaubildhneller Bericht zum Stand der Dinge.

Den aktuellen Stand seht Ihr hier rechts auf dem bekannten Schaubild.
Folgende 2 Dinge sind als nächstes geplant:

  1. Die Fertigstellung des neuen Gehäuses für den Raspberry Server mit den ganzen Erweiterungen und notwendigen Anschlüssen.
  2. Die Entwicklung des Card-Management-Systems zur Initialisierung der Karten. (Application + File + Encryption)

Mr. Chekov – Energie!

Veröffentlicht am von
Antworten

7 Stunden habe ich gebraucht um unseren Sicherungskasten neu zu verdrahten.
Hauptausschlaggebend war, dass wir nur einen FI Schalter für das gesamte Haus hatten.
Das habe ich nun aufgelöst und 3 FI Schalter eingebaut. Hier konnte ich dann schön die Funktionen der Stromkreise verteilen.
Wir haben jetzt:

  • einen FI Schalter für alle Feuchträume und den Garten
  • einen FI Schalter für Anlagen und Geräte die nicht Ausfallen sollten (bei denen die Gefahr eines Fehlstroms qusi null ist)
  • einen FI Schalter für die restlichen Räume

Des weiteren habe ich den Traffo für den Motor der Haustüre eingebaut und einen zusätzliche Stromanschluß nebst Sicherung für die Server im Haushalt eingerichtet.

Leider ist mir das 10mm² Kabel gestern ausgegangen, darum musste ich etwas „pfuschen“ damit wir abends wieder Strom hatten. Das werde ich heute Abend wohl noch gerade ziehen müssen.

Das biegen der Radien für die Leitungen im Kasten war gar nicht so einfach, vor allem wenn der Teilweise bestückt ist. Ganz schlimm war das neu verlegen der Zuleitungen. Der Elektriker hat hier damals eine massive 10mm² Leitung verlegt und keine flexible. Nicht ganz einfach eine Kupferstange zu biegen. Hat dann aber doch geklappt.

Hier ein paar vorher/nachher Bilder:

Vorher:

20150906_112419

Nachher:

20150906_142815

Vorher:

20150906_112353

Nachher:

20150906_170559

Vorher:

20150906_112347

Nachher:

20150907_174528

Und meine Frau hat natürlich hinterher gleich fleissig die Löcher gestopft:

20150906_193030 20150906_194543

Ich dremel mir mal ein Servergehäuse

Veröffentlicht am von
1

Heute habe ich mich an das Servergehäuse gewagt und angefangen erste Löcher in das ding zu bohren. Der Erste Versuch mit der Trennscheibe auf dem Dremel ging leider schief. Da fehlt mir wohl die Übung und hab mich dabei verderemelt. Nun ja, es wird wohl ein wirklich sehr „individuelles“ Gehäuse werden.

Die vielen tollen Teile die ich bei Reichelt bestellt habe werde ich wohl in einem anderen Projekt einsetzen (sobald mir etwas eingefallen ist). Jedenfalls bekomme ich die Ganzen Delock Keystones gar nicht alle unter und was mich am meißten ärgert, der Ein-/Ausschalter mit dem Kaltgerätestecker ist ebenfalls zu groß. Da muss ich mir wohl was Neues einfallen lassen.

Ich werde dafür den Raspberry so einbauen dass ich zumindest an die Netzwerk und USB Schnittstellen komme. das kommt aber wohl erst morgen (oder an einem der nächsten Tage). Den HDMI werde ich mir wohl abschminken müssen.

20150904_172631 20150904_172636 20150904_172652

Kabel Verlegearbeiten

Veröffentlicht am von
Antworten

Nun war einen Monat Ruhe hier im Blog. Die Entwicklung am Zugangskontrollsystem ging trotzdem weiter.

  1. Programmierung:
    Das Auslesen der Kartendaten funktioniert zwischenzeitlich. Bislang nur die Karten ID. Der nächste Schritt ist nun die RFID Chips zu initialisieren damit diese vom System erkannt werden. Dann wird das Programm um die Applikationsdaten des chips ergänzt.
  2. Server:
    Da das gekaufte Hutschienengehäuse mit PI USV und I/O Board zu klein wurde werde ich nun ein eigenes Gehäuse entwickeln. Die Bestandteile sind heute angekommen. Werde bei Zeiten mal ein Foto davon machen.
  3. Strom für die Türe und verlegen der benötigten Datenleitungen:
    Das habe ich heute mit meiner Frau gemacht. Sie liebt es mit der HILTI große Löcher in Betonwände zu bohren.
    Die Kabel sind nun verlegt, sobald ich etwas Zeit habe werde ich die Leitungen auf     Funktion prüfen damit da nix schief geht.
    Dann mache ich mich an die Umgestaltung des Sicherungskasten.

Anbei noch ein paar Bilder von den heutigen Arbeiten.

20150826_11214420150826_11212420150826_12045220150826_11571620150826_112155

Bug in der API entdeckt

Veröffentlicht am von
Antworten

Nun bin ich doch tatsächlich auf einen Bug in der JavaSDK und den darin enthaltenen nativen Bibilotheken gestoßen.

Bei der Arbeit an der Listener Komponente des Servers kann ich über die JDK eine Listener Instanz erstellen, diese macht einen TCP IP Port auf dem Server auf und wartet auf Notify Requests mit dem RFID Leser.

Den Listener kann man öffnen, allerdings nur mit Plaintext Kommun ikation. Soabld man die Verbindung mit dem Key verschlüsselt bekommt man eine Exception.

Der Support der FEIG ELEKTRONIK GmbH war aber gleich dabei den Fehler zu suchen. War wohl nicht ganz einfach, aber hey – gestern war der Fix für Windows im Postfach (Neue JAR und neue DLLs) und heute kam der Fix für den Raspberry.

Und was soll ich sagen: „ES FUNKTIONERT“.

Was leider noch offen ist, ist ein sauberer Deamonize modus. Der Listener wird als Asynchroner Task im Hintergrund geladen. Und kommt nach Initialisierung im Hauptprogramm wieder an. Das beendet sich dann auch sauber.
Um das Hauptprogramm offen zu halten habe ich eine while(true) schleife mit nem sleep eingebaut. Finde ich etwas unschön aber immerhin kann ich mir die Notifikationen ansehen und die Tabelle mit den Daten auslesen.

PI USV ist an Bord

Veröffentlicht am von
Antworten

Heute kam die PI USV+ an.

Aufgesteckt, eingesteckt und … alles blieb dunkel.

Ja – ich weis – Doku lesen hilft. Es gibt nen Ein/Aus Schalter an dem Ding (den versuch ich morgen).

Aber ich hab mir auch so helfen können. Einfach die Stromversorgung beim PI direkt rein und booten. Das funktionierte (klar, warum auch nicht).

Nach dem Einrichten und starten des Dienstes passierte dann etwas unerwartetes. Der Raspberry is runtergefahren. OK – also neu booten.

Ich kam bis zum Login, da war er auch schon wieder unten. Arrrrrgh

*mitflacherhandaufstirnklatsch*

Klar, is ja auch kein Strom an der USV.

Habe dann beschlossen doch mal früh ins Bett zu gehen. Und es morgen mal mit dem zwischenzeitlich in der Doku entdeckten Schalter zu versuchen.

*lol*

Das PI USV+ Dilemma

Veröffentlicht am von
Antworten

Wie ich schon berichtet habe, spendiere ich dem Server (Raspberry B+) eine USV um diverse Filesystem crashs zu vermeiden. Ist ja wohl ein bekanntes Problem.

Hier habe ich mich für die PI USV+ entschieden, die von der Firma CW2. GmbH & Co. KG aus Stuttgart angeboten wird.

Am 08.06.2015 habe ich gleich 2 davon bestellt. Die Auslieferung war (gemäß Homepage) für den 30.06.2015 geplant. Das Geld habe ich dann online am 09.06.2015 angewiesen und warte seitdem auf Lieferung oder Feedback.

Am 23.06.2015 habe ich dann eine der beiden PI USVs wieder storniert, da ich nur noch eine davon einsetzen kann und hatte gefragt ob sie mir bitte das Geld entsprechend zurück überweisen könnten. Leider habe ich hier weder den Betrag zurück überwiesen bekommen noch kam bei mir eine Antwort an. Selbst nicht als ich bei CW2 am 26.6. nochmals angefragt hatte diesbezüglich.

Im firmeneigenen Kundenforum gibt es auch nur Anfragen von anderen Bestellern ohne eine Antwort von CW2. Habe ich nach dem Auftritt auf Facebook gesucht und gefunden.
Und hier auch gleich mal einen Kommentar auf deren Pinnwand hinterlassen.
Hier ist die Reichweite vermutlich größer als in irgend einem Forum (bei dem man sich vorher anmelden und freigeschaltet werden muss).

Hier gab es dann tatsächlich auch folgende Antwort:

Guten Morgen Zusammen, Ich kann gut verstehen dass hier große Frustration herrscht – ihr seit nicht alleine, wir haben mit unzähligen Verschiebungen zu Kämpfen gehabt. Bis zuletzt wurde uns von unserem Lieferanten kein endgültiger Lieferzeitpunkt genannt. Aus diesem Grund haben wir noch nicht an alle Kunden kommuniziert. Ein weiteres nicht eingehaltenes Liferversprechen konnten wir uns nicht leisten. Gestern haben wir nun endlich die Lieferfreigabe erhalten und können deswegen heute die versprochenen Bestätigungen verschicken. Viele Grüße, PiUSV+ Team

Zwisschenzeitlich steht auf der Homepage statt dem 30.06.2015 als voraussichtliches Lieferdatum nur noch: „Auslieferung nach Lagerverfügbarkeit„.

Da ich mit der Entwicklung des Zugangs-Kontroll-Systems noch (leider) ein Weilchen vom goLive weg bin, warte ich eben auf Antwort und werde evtl. nochmals eine Mail verfassen damit nicht in lauter Hektik (HeadlessChickenMode) doch 2 USVs zu mir geschickt werden.

Ich will mit meinem eintrag hier im Blog die Firma CW2 nicht schlecht machen, die Produkte kenn ich ja noch nicht 🙂
Aber die Kommunikation zu den Kunden ist nicht gut geregelt. Hier könnte der Vertrieb sich evtl. besser aufstellen. Vor allem einem Endkunden entgegen.

So, ich mach jetzt Mittagessen für meinen Kleinen, der kommt demnächst aus dem Kindi.