Einfach mal zwischen durch ein Proof-Of-Life des Shopware Plugin für Cashless-Payment und irgendwann geht es mit dem Shopware Plugin und dem Ganzen auch ganz sicher weiter!
Die RFID-Reader liegen zur Weiterentwicklung bereit.
So langsam wird aus dem Prototypen ein fertiges Plugin, dass für den Einsatz in der realen Welt genutzt werden kann. Aber wofür kann man selbst ein Cashless Payment System, also ein System wo man nicht direkt mit Geld bezahlt sondern mit einem vorhanden oder später auszugleichenden Guthaben bezahlen kann, nutzen. Für wenn ist es interessant?
Events (Wegwerfkarten aus Pappe + 13,56 kHz RFID-Tag): Wer events organisiert kennt sicher schon Verzehrkarten und ähnliche Systeme. Man kauft sich am Eingang beim Bezahlen des Eintritts eine Karte für den Erwerb von Getränken. Jedes mal wenn man etwas Kauft wird der Preis vom vorhanden Guthaben abgezogen. Wenn man dann kein Guthaben mehr hat bekommt man nichts mehr und muss neu aufladen. Wer das Event verlässt und nicht alles ausgegeben hat, lässt das Guthaben verfallen.
Der Vorteil mit so einem System ist, dass die Mitarbeiter an der Bar nicht rechnen oder mit Bargeld rumhantieren müssen. Es kommt zu weniger Fehlern und es geht alles etwas schneller. Das Bargeld wird an zentraler Stelle behalten und es gibt keine Wechselgeldprobleme.
Wenn es um einzelne Events geht, wäre es sehr aufwendig und teuer für jedes Event ausreichend (also lieber immer zu viele) RFID-Karten bedrucken zu lassen. Hier gibt es als einfache Lösung RFID-Tags.
Also einfache Aufkleber, die auf eine Papier-Karte geklebt werden können. Man lässt sich also nur einfache Karten drucken und klebt die Tags beim Kauf rauf. Spart viele Kosten und die Karten und Tags halten einen Tag ohne Probleme durch.
RFID-Tags zum Aufkleben
Eine einfache Papier-Karte *...
... jetzt mit RFID-Tag kompatibel zu unserem System
Unser Cashless Payment System in Stichworten:
- keine lokalen Server da alles in der Cloud laufen kann
- kostengünstiges Mieten oder selber bauen von Kassen-Terminals
- erspart das Handtieren mit Bargeld und EC-Karten an den POS's
- Prepaid- und Nachträglich-Bezahlen Verfahren werden unterstützt
- Bedienung rein über Touchscreen (aber auch Maus und Tastatur wenn es vorzieht)
- Unterstützt 13,56kHz/125mHz RFID Technik und Barcodes (Code128/ QR) mit den jeweiligen USB-Readern
- Bon-Druck auf Thermo-, Tintenstrahl- oder Laserdrucker
- Unterschiedliche Kundengruppen mit entsprechenden Auswertungen von Verkäufen
- eine einfache Bestandsführung und automatische Sperrung von Produkten ohne Bestand
- Vereinfachte Bedienung durch Topseller und selbst gestaltbarer Seiten
- Professionelles und bewertes Shopware-System als Kern unserer Anwendung
Ein simpler und günstiger Bon-Drucker kann sehr einfach als normaler Windows Drucker verwendet werden. Er druckt eben nur den von ihm abgedeckten Bereich der Seite. Aber mit dem CSS3 Print-Profile kann alles super anpassen.
So sieht eine Shopware-Bestellung ausgedruckt aus (die Versandkosten sind dort nicht aufgeführt, da es normal nicht vorkommt, dass in so einem Fall welche angerechnet werden würden.. vor Ort).
Demnächst kommt hier ein Blog-Artikel der das System und Anwendungsfälle genauer beleuchten wird und Lösungen für Event, Discos, Restaurants und Hotels beschreibt.
Für mein POS-Projekt hatte ich 2 verschiedene RFID-USB-Reader. Einen direkt aus China und einen über Amazon bestellt. Der von Amazon hat den Vorteil, dass er verschiedene Ausgabe-Modi kann.
Der einfache Reader aus China gab von Anfang an direkt die Nummer mit Enter aus.
Der Reader von Amazon war zu Anfang so eingestellt das die Nummer ohne Enter ausgegeben wird. Aber es war eine Karte dabei um die Ausgabe zu konfigurieren.
Das ist auch sehr einfach. Wie man wohl schon direkt vermutet, hält man die Karte über das Lesegerät und es schaltet in den nächsten Modus.
Der Index des aktiven Modus wird ausgeben und man kann direkt mit einer normalen RFID-Karte testen.
Ich habe am Ende den Modus 0e verwendet. Da es der Code ist, der auch auf der Karte steht und mit Enter ausgegeben wird (also wie vorher nur mit Enter).
So langsam wird aus dem Prototypen, ein echtes und brauchbares Produkt. Auch wenn der Realworld-Test heute leider ausgefallen ist, hat das Plugin wichtige neue Funktionen bekommen:
- Direktes Anlegen eines Kunden beim ersten Login-Versuch (dann muss man bei 4000 Karten nicht 4000 Kunden anlegen sondern, kann direkt loslegen)
- Vorgegebene Freitext-Felder, dadurch muss man weniger konfigurieren und weniger Fehlerquellen
Zusätzlich:
- viele Fixes
- Drucken von Kassenbons ist zu 50% fertig. Ein Thermodrucker zum testen ist bestellt.. und hilft vielleicht bei der Kassenschubladen-Problematik
- 13,6mHz Tags zum Aufkleben und ein passendes Lesegerät sind auch bestellt... damit kann man einfache Eintrittskarten zu Bezahlkarten machen
Es geht also alles in schnellen Schritten voran und ich hoffe, dass es dann schon bald als Cloud-Service für alle verfügbar sein wird.
Nächstes Jahr werde ich wirklich mal das Adventskalender-Projekt nach vorne bringen. Mit Shopware Emotion-Element und so. Erstmal stehen jetzt für Ende diesen und Anfang nächsten Jahres folgende Dinge auf meiner Todo-Liste:
- Shopware-Plugin: Warnung bei unnatürlichen Preisänderungen
- Shopware-Plugin: Globale Smarty-Variablen für Kundendaten
- Shopware-Plugin: XML-Order Export für ERP-Integration
Dann kommt noch die Planung/Konzeptionierung für ein Projekt mit RFID Technik in Kombination mit vielleicht Shopware.
Und auch SMS2X soll noch mal verbessert werden, so dass es vielleicht mal zum Einsatz kommen kann.
Auch Zeitmessung ab von RFID wird mich wohl noch mal beschäftigen.
Am 24.6. war es wieder so weit und das Bremer Oldtimer-Rennen stand wieder für mich vor der Tür. Wie im Jahr davor sollte meine Aufgabe sein, die Zeitmessungen (jeden Falls einen Teil davon) durch zu führen und am Ende die Gewinner benennen zu können. Klingt erst einmal ganz einfach aber für diese Sache, die an sich voll automatisch laufen sollte, ist immer viel mehr zu tun als man so denken würde.
Dafür muss man das Grund-Setup kennen und verstehen. Bei dem Rennen nehmen 170 Autos teil. Jedes dieser Autos wird mit einem aktiven RFID-Tag ausgestattet der den Tag über die Kennung des Autos aussendet. Die Veranstaltung besteht genau genommen aus 3 Rennen. Da es natürlich unfair wäre, bei Autos von 1920 bis 1970 auf Minimalzeit pro Strecke zu fahren, wird immer auf eine Richtzeit gefahren. Der Fahrer, der am dichtesten an der Zeit dran ist gewinnt. Also kann der zweit etwas langsamer als die Zeit sein und der 3. etwas schneller. Es nur um die absolute Differenz.
Am Anfang und am Ende jeder Strecke steht dabei ein RFID-Reader, der alle Autos erfasst, die vorbei fahren.
RFID sendet aber bei einem aktiven Tag mehr als die Sekunde sein Signal und die Reader decken mit ihren Antennen einen größeren Bereich ab. Es funktioniert also grundlegend anders z.B. eine Lichtschranke. Man bekommt also eine Menge an Messwerten, die vom Auto gesendet werden, während es vorbei fährt. Daraus wird nach dem relativ einfachen Prinzip von Zuerst-Gesehen und Zuletzt-Gesehen der Mittelwert berechnet.
Dabei kann an sich schon genug schief laufen. Gerade wenn man kleine und kurze Strecken hat. Wenn das Auto schon soweit beim Start an den Reader heran fährt und schon Messwerte erfasst werden, aber das Auto noch nicht losfährt. Dann wird die Zeit in der das Auto steht, mit Pech mit in die Zeitberechnung mit hinein gerechnet.
Aber auch die Chips und Sender der Tags sind nicht immer zuverlässig. Auch wenn sie 100 mal die Sekunde senden sollen, kann man nicht immer sicher sein, dass es keine Einbrüche in dieser Frequenz gibt. Autos aus Metall können außerdem sehr gut Abschirmen und so die Sendeleistung stark beeinflussen. Bautechnische Probleme wie schlechte oder defekte Schalter zum Ein- und Ausschalten kommen noch dazu.
Diesmal hatten wir im Vorwege das Problem, dass allein durch die Bewegungen der Tags in der Kiste sich einige einschalteten und anfingen zu senden und so Tags empfangen wurden, die gar nicht zum Rennen gehörten.
Durch einen guten Aufbau und ein wenig mehr Programm-Logik kann man fast alle Probleme unter Kontrolle bringen. Aus der Menge der Messpunkte werden konkrete Werte errechnet. Mehrfachmessungen eines Autos werden entfernt und fehlende Messungen werden herausgesucht. Das benötigt etwas mehr Rechenleistung, weswegen die Messstationen mit etwas Leistungsfähigeren Notebooks ausgestatteten sein müssen.
Damit kommen wir erst einmal wieder zurück an den Anfang. Die Vorbereitung und was diesmal alles zu tun war.
Vorbereitung:
Nachdem im letzten Jahr mehr oder weniger spontan Notebooks mit dem Mess-Client ausgestattet wurden und es zu vielen Problemen kam:
- Fehlende Runtime-Umgebungen
- andere Server-Anwendungen die Ports blockierten
- Notebooks auf denen schon so viel installiert war, dass sie langsam waren
- Akkus die nicht mehr lange durch hielten und deswegen immer Strom nötig war (den es nicht immer gibt)
Ich fing also schon 2 Monate vorher an, das Problem in Angriff zu nehmen. Ich entschied mich die Hardware diesmal komplett selbst zu stellen und somit etwas mehr Sicherheit zu haben. Das Alienware sollte diesmal nicht benutzt werden, da es schwer ist und man es nicht mal schnell zur Seite nehmen kann, wenn es regnet. Außerdem ist es einfach nicht dafür gedacht, über den Akku zu laufen.. jedenfalls nicht langer als 15min.
Da ich für Notfälle aber eine Entwicklungsumgebung haben wollte, damit ein Fehler nicht ein Rennen versauen kann oder die Auswertung unmöglich macht, entschied ich mich mein Surface mit zunehmen. Es ist relativ Wetter-beständig und der Akku hält sehr lange. Die Rechenleistung ist nicht wirklich groß, aber ausreichend.
Damit waren meine eigenen Notebook Vorräte aber erschöpft und extra welche Kaufen würde sich nicht lohnen. Also kam ich auf die Idee meine Kontakte als Mitarbeiter bei Notebooks Wie Neu zu nutzen. Ich konnte mir 2 Lenovo Thinkpad T410 leihen. Mit i5, 4GB RAM waren die mehr als schnell genug und Thinkpads sind auch stabil genug, so das ich mir wegen Regen nicht zu viel Sorgen machen musste. LAN und USB Anschlüsse waren auch vorhanden. Der Akku hielt mehr als genug und am Ende waren die Akkus nicht mal halbleer, obwohl die Thinkpads ca. 2h damit beschäftigt werden durchgehend Daten abzurufen und in eine MySQL-Datebank zu schreiben.
Nur eine Sache störte mich etwas.. das war Windows 7. Egal was viele im Internet so schreiben.. bei der Bedienung ist Windows 10 sehr viel schneller und intuitiver als Windows 7. Aber da alles wie Java 1.8 und MySQL laufen, ist es nicht so schlimm, weil die Client-Software sowie so rein über die CLI bedient wird. Eine GUI Version existiert, ist aber noch auf eine Verbindung zum Server angewiesen, was da nicht gegeben war. Ein portabler UMTS-WLN-Router wäre eine gute Lösung gewesen, aber die Idee kam mir zu spät und ich wollte ja gerne den Server bei Problemen schnell ändern und fixen können. Was mit einer lokalen Instanz, die man direkt in der IDE hat, natürlich sehr viel schneller und einfacher geht als mit einem System das auf einem Server im Internet läuft.
Vielleicht bin ich nächstes Jahr mal mutiger. Es hätte auch noch andere Vorteile für die Veranstalter.. aber dazu später mehr.
Die Liste der Teilnehmer konnte ich am Abend vorher importieren und dabei noch 2 kleine Fixes einbauen. Deswegen wollte ich die Liste gerne schon vorher haben.
170 Autos. 170 importierte Rennteilnehmer am Ende. Alles perfekt.
Ich hatte also 4 Notebooks (das Alienware war als Fallback dann doch dabei), Reader, Netzwerk-Kabel und einen Switch. Was man aber immer dabei haben sollte, ist auch Essen und Trinken. Wasser und Energiedrink. Eines für den Durst und das andere für Energie. IBUs für Notfälle und natürlich das Smartphone für Navigation und Informationsbeschaffung. Beim Essen kann man sich ruhig abends vorher was kochen, denn gutes Essen macht es einen sehr viel einfacher, wenn man morgen um 4:15 aufstehen muss und dann noch kein Frühstück hatte.
Immerhin war das Wetter gut und nicht so verregnet wie im letzten Jahr... jeden Falls am Anfang
Der Tag:
Um 4:45 war ich in Stockeldorf bei "die Halle" wo die Switch GmbH ihren Sitz hat. Die Mitarbeiter wuselten durch die Gegend und packen alles in den VW Bus was man so brauchte. Dann wurde ein Karton mit Tags hochgehalten und gefragt, ob die auch mit sollen. "Nein, das sind die, die nicht funktionierten und ausgewechselt wurden".
Klingt erst einmal nicht so schlimm, aber wenn man bei 170 Teilnehmern 30 Tags für jeweils drei Rennen austauschen muss.. also 90 Einträge per Hand bearbeiten, dann klingt es nicht mehr gut. Am Ende wurden also diese Ausgetauschten alle geöffnet und Batterien getauscht. Am Ende waren es pro Rennen nur jeweils ca. 6 Tags, die per Hand übergetragen werden mussten.
Hier fiel mir auch auf, dass die Tags dieses Jahr gefühlt sehr viel Fehleranfälliger waren. Beim Testen wurden noch 4 ausgetauscht, weil sie nicht vom Reader erkannt wurden. Die Schalter schalteten in den Karton bei jeder kleinen Bewegung wie sie wollten.
Und dann kam der Regen. Viel Regen. Alles wurde unter die offene Heckklappe des VW-Bus gestellt und das Surface wechselte erst einmal in eine Plastiktüte.
Es war zum Glück nicht wirklich kalt. Nur sehr sehr nass. Wer glaubt das Regen und die Nässe nur immer von oben kommt, irrt sich. Tropfen fallen auf Tische und spritzen dann in alle Richtungen. Am Ende ist doch alles nass.
Aber es gab auch positives zu berichten. Weniger Tags streuten in den Messbereich und die Erkennung war dieses mal sehr viel besser. Das andere Team meldete sich schon kurze Zeit später und meldete, dass alles laufen würde. Ich bin immer sehr unruhig wenn ich bei so etwas nicht in der Nähe sein kann, um möglicherweise auftretende Fehler zu beheben. Ich kenne das System zu 100% und einfach unerfahrene Benutzer damit los zu schicken.. dazu gehört sehr viel Vertrauen in die eigene Software dazu.
Am Ende war alles super. Alles hatte beim ersten Rennen funktioniert und das Thinkpad konnte zeigen was es konnte. Beim Surface braucht ich so 15min mit Client in der IDE um die Daten zu übertragen. Dabei liest der Client und schreibt der Server auch in die selbe Datenbank, was auch nochmal bremst. Das Thinkpad brauchte gerade mal 4-5 Minuten. Schnelle CPU, schnelles Lesen von der Festlatte. Das Schreiben in die DB auf dem Surface war dann auch sehr entspannt, weil nebenbei nicht so viel gelesen oder gerechnet werden musste. Also Server und Entwickler-Rechner hat sich das Surface mehr als bewährt. Das selbe gilt auch für die Thinkpads als Messstationen-Clients.
Das 2. Rennen war dann die kritische Phase, die dann aber auf Grund der stabilen Bauweise der Reader und viel Nachrechnen und eliminieren von Fehlmessungen, am Ende doch gut ging. Wir hatten kaum Zeit zum Aufbauen, ein Reader lief an einem Diesel-Generator und 50m Lan-Kabel. Die ersten Autos wurden manuell gemessen mit der eingebauten App vom Time-System, während wir nebenbei den zweiten Reader aufbauten, der dann am Alienware lief. Sturm, Regen und noch mehr Regen. Wir saßen im Bus und nur die Kabel zu den Readern im Regen gingen nach draußen. Ich wüsste zwischendurch nicht ob der Reader am Start noch lebte und Daten sendete. 1,5h später war der Regen vorbei und man ordnete sich und guckte mal wieder auf die Terminal-Ausgaben auf dem Surface. Alles lief super. Es fuhr gerade das letzte Auto vor und der Reader meldete den Tag also ob vorher nicht gewesen wäre. Sein Netzteil hing so im Regen und ein Teil des Kabel lag vorher schon blank. Aber kein Aussetzer bei der Datenerfassung. Ich war wirklich stolz auf den kleinen tapferen Reader.
Das Netzwerk-Kabel wurde auch nebenbei als Streckenbegrenzung verwendet. Von der Planung her eine Katastrophe, aber mit den Fallback-Lösungen konnte man alles retten.
Danach ging es zur Test-Strecke von Mercedes und das 2. Thinkpad übernahm das Rennen dort. 1. Rennen war in 20min fertig. Ich hab bevor Korrektur-Funktionen über die Daten liefen immer lieber noch einmal die Daten gesichert. Berechnen lief schnell.
Das 2. Rennen brauchte mehr Zeit. über eine Stunde, da ich viel bei den Korrektur-Funktionen nacharbeiten musste, die Fehlmessungen eliminierten und ich lieber 3 mal die Liste der gefahrenen Autos durch ging, um sicher zu sein, dass wirklich kein Auto übersehen oder nicht gemessen wurde.
Das 3. Rennen ging dann wieder sehr schnell und es gab keine Überraschungen.
Bestes Frauen-Team musste dann per Hand berechnet werden. Waren aber nur sehr wenige Teams, deswegen ging es. Der Gesamtsieger war aufwendiger, weil man über die gesamten drei rennen Rechnen musste, zum Glück sind es doch immer die selben Fehler die vorne liegen. Damit war es ausreichend die 9 Sieger der 3 Rennen zu nehmen und für diese die Werte der 3 Rennen auszuwerten. Kontrolle bei den 4. und 5. Plätzen zeigten gleich, dass von dort keine Konkurrenz mehr kam.
Auch fiel dabei auf, dass man kein großes Kopf-an-Kopf-Rennen hier hatte. Die ersten Plätze waren immer sehr eindeutig, eher am Ende des ersten Drittels konzentrierten sich die Zeiten auf eine geringe Zeitspanne.
Das Fazit:
Das Event lief sehr viel besser als das letzte Jahr und die Zeiten für die Auswertungen war sehr viel geringer. Die automatischen Analysen und Korrekturen von Fehlmessungen hat viel gebraucht und sehr viel besser und zuverlässiger funktioniert, als es per Hand war.
Trotzdem hätte ich gerne eine andere Lösung für das nächste mal. Die Tag an sich sind eine Fehlerquelle für sich und diese würde ich gerne eliminieren. Eine Lösung wäre eine Kamera gestützte Erfassungsmethode mit QR-Codes. Wie Lichtschranken, gibt es da aber Probleme bei parallel fahrenden Autos. Deswegen müsste man ein Gestell haben, um die Kameras von oben auf die Start- und Ziellinie gucken zu lassen. Dann muss man die Autos erkennen, da man so wirklich von vorderen Punkt des Autos messen kann und nicht nur die Position des RFID-Tags (was viele Teilnehmern nicht klar war, sich aber natürlich auf die Messungen auswirkt).
So ein System ist sicher zu bauen, aber braucht seine Zeit. Am Ende hätte man aber sicher gute Ergebnisse mit Beweisfoto.
Auch sollte alles so aufbaubar sein, dass die Technik die Autos nie verlassen muss. Mehr Schutz vor Regen und man kann schneller aufbauen, wenn nur noch Kabel verlegt werden müssen.
Ein großer Traum wäre es, es wirklich als Cloud-Anwendung laufen zu lassen, so dass die Clients direkt vor Ort über einen WLAN-UMTS-Router ihre Daten direkt an den Server schicken können. Vielleicht sogar kurz nach dem sie gemessen wurden. Damit hätte man auch die Möglichkeit eine Echtzeit Anzeige zu realisieren.
Manchmal hat man das Problem, dass man vor Ort keinen Strom hat. Notebooks lösen das Problem. Doof nur wenn man auch zusätzliche Geräte wie RFID-Reader oder Netzwerk-Switches mit versorgen muss. Ich werde Samstag mal ein Akku-Pack testen. Eigenlicht ist es für mobile Blitzanlagen gedacht, aber mit etwas Glück funktioniert es auch für andere Geräte.
Zeitmessungen bei Rennen müssen nicht immer mit RFID gemacht werden. Man kann auch ganz einfach einen PC, ein Tablet oder ein Smartphone pro Messstation nehmen und eine Person muss nur auf die Teilnehmer-Nummer klicken/drücken, um eine Messung zu speichern.
Für die meisten Rennen im Amateurbereich ist die Genauigkeit mehr als ausreichend. Also ein vollständiger Ersatz für Stoppuhren oder andere Smartphone-Apps, die man sonst für Kontrollmessungen verwenden würde.
Und alles natürlich dann in Echtzeit auf dem Server.
Blog-entries by search-pattern/Tags:
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?