Archiv der Kategorie: Server

FEIG OBID Firmware Version 2.8.131

Veröffentlicht am von
Antworten

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.

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

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

 

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.

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

 

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

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.

Der Listener, das unbekannte Wesen und andere Fortschritte

Veröffentlicht am von
Antworten

Zum Stand der Dinge.

Hier seht Ihr den aktuellen Fortschritt des Projekts.

2015-07-17-Architektur-SchaubildFür das Logging von Informationen habe ich mich für den defacto Standard Log4J entschieden.  Bislang gebe ich nur auf STD OUT statt in eine Datei, aber das ist (soweit ich gesehen habe) nur noch eine Konfigurationssache.

Den Bereich der extern ausgelagerten Konfiguration (Kasten: „Config“) habe ich ebenfalls gelöst. Ursprünglich hatte ich mir zunächst die Crunchify Lösung aus dem Internet angesehen mich dann aber doch nach einigem hin und her für eine eigene Lösung entschieden. Diese habe ich in dem Artikel Konfigurationsdateien beschrieben.

Mit der OBID Listener Komponente habe ich nun angefangen mit der Entwicklung. Leider stieß ich relativ schnell auf komische Efffekte. Hier habe ich auch schon eine Supportanfrage gestellt bin aber guter Dinge das mir da die FEIG ELECTRONIC GmbH auf die Sprünge helfen kann.

Die Türe mit dem PiFace Digital 2 öffnen

Veröffentlicht am von
Antworten

Meine Recherche war erfolgreich und ich konnte eine kleine Java Klasse erstellen mit der ich den OpenCollector Ausgang (OUT PIN 0) für 500 Millisekunden öffnen (also auf GND ziehen) kann.

Ursprünglich wollte ich mit der Klasse com.pi4j.device.piface.PiFace arbeiten, leider kommt aber Java nach Ausführung nicht wieder zurück.

Ein strace hat ergeben, dass Java auf die Beendigung eines Prozesses wartet. Die angegebene PID im strace war aber nicht mehr im system vorhanden, damit würde die Classe sich wohl nicht wieder beenden. Daher bin ich umgestiegen auf die etwas weiter unten liegende com.pi4j.io.gpio Klassen.

Und hier das Ergebnis:

// Importing Libraries
import com.pi4j.gpio.extension.piface.PiFaceGpioProvider;
import com.pi4j.gpio.extension.piface.PiFacePin;
import com.pi4j.io.gpio.GpioController;
import com.pi4j.io.gpio.GpioFactory;
import com.pi4j.io.gpio.GpioPinDigitalOutput;
import com.pi4j.io.spi.SpiChannel;
import java.io.IOException;

/**
 * 
 * @author Michael Oberdorf
 * @version 0.100
 * Description:
 *   PiFaceOut is the class to control the PiFace Digital 2 Output Ports
 *   The Class uses the Pi4J GPIO interface instead of the device.piface class because
 *   the finalizing is defect there.
 *   The GpioController can be shutdown 
 *
 */
public class PiFaceOut {
    public static void main(String args[]) throws InterruptedException, IOException {
        // create gpio controller
        final GpioController gpio = GpioFactory.getInstance();

        // Trigger the Out PIN 00 for 500 milliseconds to open the entrance door
        openDoor(gpio, 500);

        // shut down the interface to clean up native heap from WiringPi
        gpio.shutdown();
    }
    
    /**
     * 
     * private method to trigger the digital output pin 0 to open the entrance door
     * @param gpio (GpioController)
     * @param time (int)
     * @throws IOException
     * @throws InterruptedException
     *
     */
    private static void openDoor(GpioController gpio, int time) throws IOException, InterruptedException {
        // create custom PiFace GPIO provider
        final PiFaceGpioProvider gpioProvider = new PiFaceGpioProvider(PiFaceGpioProvider.DEFAULT_ADDRESS, SpiChannel.CS0);

        // provision gpio output pins and make sure they are all LOW at startup
        GpioPinDigitalOutput myOutputs[] = {
                gpio.provisionDigitalOutputPin(gpioProvider, PiFacePin.OUTPUT_00)
        };

        // pull digital out pin to GND (OpenCollector)
        gpio.setState(true, myOutputs);
        // sleep for a while
        Thread.sleep(time);
        // close the digital out pin
        gpio.setState(false, myOutputs); 
    }
}

Raspberry PI B+

Veröffentlicht am von
Antworten
Der neue (alte) Raspberry PI B+ ist nun da und für den Anderen habe ich auch schon einen Abnehmer gefunden.
Das PIFace Digital 2 habe ich dieses mal gleich aufgesteckt, von der PI USV habe ich leider noch nichts gehört.
Das Raspbian Image ist ja das selbe, daher konnte ich ohne Downloads gleich wieder starten den Server zu konfigurieren.
Die Libraries der Feig GmbH waren auch schnell in /usr/lib  untergebracht inklusive der Symlinks. Der erste Test war auch erfolgreich. Die Libraries liesen sich mit Java initialisieren.
Apropos Java, hier muss ich gleich noch schauen ob es da auch was für das PiFace gibt.
URLs die ich zu dem Thema gefunden habe:
Das klingt schon mal interessant und muss ich mir demnächst mal noch näher ansehen.