Benutzer Datenverwaltung auf Basis von OpenLDAP 2.4

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

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

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

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

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

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 ${gpuTemp} | sed -e "s/'C//"`
get_date_time=$(date "+%Y-%m-%d_%H:%M:%S")
echo "${get_date_time} cpuTemp: ${cpuTemp1}.${cpuTempM}" >> $cpugpu_logfile
echo "${get_date_time} gpuTemp: ${gpuTemp}" >> $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

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

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)

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+

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

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

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!

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

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