Software erlebbar machen, ohne eine Zeile Code zu schreiben

Das Projekt war gescheitert. Eigentlich war alles nach Plan verlaufen. Nach der Spezifikation der Anforderungen war ein umfangreiches Konzept erstellt worden. Auf knapp dreihundert Seiten, wurde bis ins kleinste Detail spezifiziert, wie sich die Software zu verhalten hatte. Sowohl das Projektteam als auch der Kunde waren sich einig, dass genau so das Produkt umgesetzt werden sollte. Die Software war gemäß der Spezifikation implementiert und getestet worden. Also sollte das Projekt erfolgreich sein, oder? Leider nein! Das Ergebnis war nicht das, was sich der Kunde vorgestellt hatte. Die Endkunden beschwerten sich, dass die Software ihnen nicht bei ihren Problemen half und zudem schwer zu bedienen war. Neuentwicklung? Viel zu teuer! Also blieb die Software, wie sie war und alle Beteiligten waren unzufrieden. Wenn man doch nur in die Zukunft schauen könnte, um schon vor der Implementierung zu wissen, ob ein Projekt erfolgreich sein wird …

Eine Kristallkugel haben wir auch nicht, aber diese ist auch nicht notwendig. Mit geeigneten Prozessen und Methoden kann dem geschilderten Problem entgegengewirkt werden.
Dazu sind zwei Voraussetzungen nötig:

  1. Das Konzept sollte so früh wie möglich erlebbar gemacht werden
  2. Schon vor der Implementierung sollte das Konzept getestet und iterativ weiterentwickelt werden

 

Lebendige Objekte statt tote Dokumente

 

Umfangreichere Spezifikationen garantieren keinen Projekterfolg. Sie werden selten von allen Beteiligten gelesen – und wenn doch, werden sie von jedem anders verstanden. Außerdem schleichen sich schnell Inkonsistenzen ein, die aufgrund des Dokumentenumfangs kaum bemerkt werden können. Zusammenfassend gesagt, dienen umfangreiche Dokumente mehr der Absicherung als der Kommunikation. Jedoch ist ein frühzeitiges gemeinsames Bild vom Produkt essentiell für den Projekterfolg.

Hier stellen Prototypen ein besseres Medium dar, um eine Produktidee oder ein Konzept zu kommunizieren. Prototypen helfen, die Software schon erfahrbar machen, bevor die erste Zeile Code geschrieben wurde. Dabei muss es sich weder um programmierte Prototypen handeln, noch müssen die entstandenen Entwürfe pixelgenau ausgestaltet sein. Entscheidend ist, dass  der Prototyp das kommuniziert und erlebbar macht, was gerade im Projektteam oder mit den Endnutzern besprochen wird.

Wissen statt raten

Jede Idee ist, so gut sie auch klingen mag, am Anfang eine Hypothese. Ohne eine Überprüfung ist eine Hypothese kaum etwas wert. Um sicher zu stellen, dass eine Produktidee erfolgreich sein kann, muss diese getestet werden. Mit Prototypen kann eine Idee getestet werden, ohne dass das eigentliche Produkt fertig entwickelt werden muss. Da die Erstellung eines Prototypen nur einen Bruchteil der späteren Entwicklungskosten ausmacht, können kostengünstig mehrere Iterationszyklen mit dem Prototyp vollzogen werden, bevor das eigentliche Produkt entwickelt wird.

 

Fehler so früh wie möglich machen!

 

Auf den ersten Blick scheint es so, dass die  Erstellung von Prototypen unnötige zusätzliche Kosten für Projekt verursacht. Jedoch ist dies nur eine sehr kurzsichtige Betrachtungsweise. Auf den gesamten Projektverlauf gesehen, sparen Prototypen mehr Geld ein, als sie kosten.

Je weiter ein IT-Projekt fortgeschritten ist, desto teurer wird es, Fehler zu beseitigen oder Änderungen am Produkt vorzunehmen.  Fehler per se lassen sich nicht vermeiden, doch teure Fehler können vermieden werden. So kostet die gleiche Änderung im Prototyp einige Minuten, jedoch in der Entwicklung mehrere Stunden bis Tage.

Fazit

Der Einsatz von Prototypen spart langfristig Geld und sichert den Projekterfolg. Er bietet folgende Vorteile:

  • Besseres Feedback
    Das Produkt ist in einem sehr frühen Stadium erfahrbar. Da das Abstraktionsniveau zum Verständnis bei einem Prototypen sehr gering ist, kann frühzeitig von allen Projektbeteiligten Feedback eingeholt werden.
  • Validiertes Konzept vor der Entwicklung
    Schon vor der ersten Zeile Code konnten Sie oder Ihre Endkunden einen Eindruck vom Endprodukt erhalten. Bereits in der Konzeptionsphase kann der Prototyp mit  Nutzern getestet werden.
  • Gemeinsames Verständnis des Produktes von Anfang an
    Damit das Projekt erfolgreich wird, ist es von essentieller Bedeutung, dass alle Projektbeteiligten das gleiche Bild vom Produkt im Kopf haben.

 

 

 

Modbus über MQTT – wie geht das?

Modbus über MQTT – wie geht das?

Im Zeitalter der Digitalisierung und im Rahmen von Industrie 4.0 Anwendungen kommt zwangsläufig die Frage auf, wie bestehende Anlagen zukunftsfähig gemacht werden können. Die Grundlage hierfür sind die am Markt gängigen Systeme für die Vernetzung und den Informationsaustausch von Industrie-Steuerungen und angeschlossenen Sensoren und Aktoren.

Dieser Artikel beschäftigt sich mit der Möglichkeit, vorhandene Systeme zu vernetzen, um Industrie 4.0 Anwendungen überhaupt erst zu ermöglichen. Ganz konkret soll es in diesem Artikel um das Thema „Modbus“ und dessen Vernetzung gehen.

Modbus ist eines von mehreren gängigen Kommunikationsprotokollen für industrielle Anlagen und in der Automationstechnik. Modbus hält zusammen mit der TCP Variante immerhin einen Anteil von 11% am Gesamtmarkt der industriellen Netzwerke.

Quelle: http://www.elektroniknet.de/markt-technik/automation/feldbusse-und-ethernet-im-zeitalter-von-industrie-4-0-128660.html

Modbus ist ein relativ einfaches Master/Slave-Protokoll (https://de.wikipedia.org/wiki/Modbus), welches über verschiedene Leitungswege übertragen werden kann.
Die Frage, wie bestehende Modbus-Systeme mit einer Remote-Überwachung ausgestattet werden können, bzw. wie sich in solchen Systemen eine Predictive-Maintenance-Lösung aufbauen lässt, begegnet uns in Projekten immer häufiger.

Grund genug, hier ein paar grundlegende Gedanken zu diesem Thema zu Papier zu bringen.
Für die Übertragung der Daten in eine Cloud-Lösung á la Azure oder IBM Watson braucht es ein modernes Protokoll, welches auch dafür gemacht ist, mit geringem Ballast relevante Daten zu übermitteln. Ein in diesem Umfeld bewährtes Protokoll ist das MQTT Protokoll, welches wir in früheren Beiträgen schon ausführlich beschrieben haben, siehe:

Das MQTT Protokoll & Hintergründe (Teil 1)

Das MQTT Protokoll & Praxis (Teil 2)

Die Frage die sich nun stellt, ist: Wie kommen die Daten aus einem Modbus in MQTT? Eine kurze Internetrecherche bringt hier einige Ansätze, wie den von Oliver Wagner (https://github.com/owagner/modbus2mqtt) zum Vorschein. Allerdings ist diese Lösung genau wie viele andere für den Einsatz in bestehenden Installation ungeeignet. Der Grund liegt einfach in der Konzeption, denn die meisten gehen davon aus dass Sie ein Modbus Master sind und dann die Daten in MQTT übersetzen.

Das würde allerdings bedeuten, dass die MQTT Implementierung z.B. auf der bestehenden SPS erfolgen müsste, was in der Praxis nicht realisierbar ist.
Der Weg für bestehende Anlagen kann nur über einen Modbus Slave erfolgen. Einen solchen Slave könnte man relativ leicht auf einem Gateway implementieren. Dieses Gateway kann als normaler Busteilnehmer am Modbus arbeiten, ohne den Betrieb zu beeinflussen und alle Daten, die über den Bus laufen, mithören.
Eingriffsmöglichkeiten gibt es in dieser Konstellation zwar keine, aber das ist bei bestehenden Anlagen auch nicht wirklich gewollt.
Sollte man auch Steuerungsmöglichkeiten benötigen, könnte das Gateway als Busteilnehmer Register setzen, welche dann von der SPS in entsprechende Befehle für die anderen Busteilnehmer umgesetzt werden müssen.

Wie man einen solches Gateway aufbaut und welche Komponenten (Software/Hardware) zum Einsatz kommen können, wird der nächste Artikel beleuchten.

Vertrieb 4.0 – Digitalisierung in Vertrieb und Marketing (Teil 4): Warum ist die Digitalisierung so schwer?

Immer wieder hören wir bei Kundengesprächen und in Workshops zum Thema Vertrieb 4.0, dass die Digitalisierung im Unternehmen allgemein und im Vertrieb im Besonderen nur schwer voranzubringen ist. Und dann folgt die Frage, warum das wohl so ist?

Darauf gibt es eine einfache Antwort: Wird das Thema Digitalisierung und die daraus resultierenden Analysen bestehender Prozesse einmal näher betrachtet, so werden vielfach fundmentale Versäumnisse der vergangenen Jahre gnadenlos offenbart. Und davor hat man Angst, das will man sich so nicht eingestehen.

Beispiel: Daten

In nahezu jedem mittelständischen Unternehmen sind die größten Versäumnisse im Bereich der (Produkt-)Daten zu identifizieren. Weder die Hersteller, noch Distributoren, Großhändler oder gar der Einzelhandel hatten bislang interne Prozesse mit Anforderungen an Datenqualität, -aktualität und -umfang, wie dies für digitale Vertriebsmodelle unabdingbar ist.

Bislang ist der Verkaufsprozess durch das Verwalten der Kundenbeziehungen mit manuellen Prozessen, individuellen Absprachen, chaotischem Know-how-Management und hierarchischen Kontrollmechanismen geprägt.

In der Folge war es in den letzten Jahrzehnten ausreichend, die eigenen Produktangebote mit wenigen Bezeichnungen, Nummern und Preisen zu identifizieren, um so die Aufträge, Rechnungen und Lieferscheine zu erstellen. Dann noch ein „schön gestalteter Katalog“ – neuerdings auch als PDF – und damit waren die Daten für alle Prozesse rund um den Verkauf abgedeckt.

Nur leider ist ein Katalog im PDF-Format KEIN digitales Verkaufsinstrument.

Der Hunger nach Daten im digitalen Zeitalter ist immens und die Anforderungen der Nutzer dieser Daten sind so vielfältig wie noch nie zuvor. Der Verkäufer von heute kann nur mit strukturierten Daten in höchster Granularität kombiniert mit benutzerfreundlichen Filtermöglichkeiten über das gesamte Sortiment und den dazugehörigen personalisierten Produktketten noch erfolgreich sein.

Zudem sind gerade bei komplexen, erklärungsbedürftigen Produkten die Anforderungen an die Visualisierung mithilfe von Bildern, Videos, Konstruktions-Zeichnungen, Konfiguratoren und vielem mehr permanent am Steigen. Der Treiber für diesen Vertrieb 4.0 ist die Erwartung der Kunden, dass der Verkäufer die passenden Produktinformationen immer und vollständig im Zugriff hat.

Und nicht zu vergessen sind Dritte, die heute praktisch jede Kaufentscheidung mitbeeinflussen. Dazu gehören Suchmaschinen, Preisvergleichsportale, soziale Medien und mehr, die ebenfalls hohe Ansprüche an Datenqualität und -verfügbarkeit formulieren. Wer hier seine Daten nicht in Top-Qualität einspielen kann, verliert in der digitalisierten Welt an Relevanz, Sichtbarkeit, Frequenz und damit an wirtschaftlicher Bedeutung.

Beispiel: Vertriebsprozesse

Was für die (Produkt-)Daten gilt, gilt im gleichen Maße für auch die Prozesse rund um den Vertrieb. Durch die Digitalisierung werden deren Ineffizienzen gnadenlos sichtbar und mögliche Nutzen-Potentiale werden quasi auf dem Silbertablett serviert.
Aufwandstreiber, wie bspw. händisch gewährte Sonderrabatte, die aufwändig manuell verrechnet werden oder abweichende Verpackungsgrößen, die den Logistiker regelmäßig zum Zähneknirschen bringen, müssen plötzlich thematisiert werden. Diese Probleme jetzt zu lösen ist aber unabdingbar, um in Zukunft noch am Markt erfolgreich mitspielen zu können.

Ja, es kostet Geld und auch zusätzliche Ressourcen. Zudem ist es jetzt nicht in Heller und Pfennig zu berechnen, wann und wie sich diese Investitionen in digitale Prozesse rentieren.

Aber nur die Digitalisierung bringt den gnadenlosen Durchgriff auf alle Daten- und Prozessebenen im Unternehmen. Nur mit Digitalisierung schafft man die Grundlagen, um die Messgrößen definieren und überwachen zu können, mit denen ein Unternehmen seine zukünftigen Fortschritte übergreifend in Vertrieb, Marketing und Logistik bewerten kann.

Fazit

Machen Sie die Digitalisierung zur Chefsache! Verhaltensmuster und Werte, die über Jahre Gültigkeit hatten, haben sich vielfach überlebt und werden oft zu Makulatur. Das Unternehmen muss neue Spielregeln entwickeln und erproben. Dabei geht es weniger um Kontrolle, sondern vielmehr darum, einen Rahmen abzustecken, innerhalb dessen sich alle Abteilungen frei bewegen können, um ihre Aufgabenfelder in die digitale Zukunft zu führen.

Hier ist oftmals nur ein wenig Mut von dem Entscheider gefordert, seinen Mitarbeitern zu vertrauen, um die Digitalisierung mit ersten Projekten anzustoßen und schrittweise umzusetzen.


Blog-Reihe „Vertrieb 4.0 – Digitalisierung und Vernetzung der Prozesse in Vertrieb und Marketing“

Einleitung

Teil 1: Definition 

Teil 2: Die 5 wichtigsten Herausforderungen für den Vertrieb

Teil 3: Digitale Vertriebs-Systeme in der „Perfektionismus-Falle“

Teil 4: Warum ist die Digitalisierung so schwer?

Begeisterung statt Frust

Wie Software Mitarbeiterzufriedenheit und Produktivität erhöhen kann

Larissa Fischer ist Innendienstmitarbeiterin im Kundendienst. Nach jedem Gespräch trägt sie die Informationen zum Kunden in das Kundenmanagementsystem ein. Sie erhält keine Rückmeldung, ob diese Einträge den Kollegen im Außendienst helfen und vollständig genug sind. Mit der Zeit trägt Sie nur noch das Nötigste ein. Sie ist sich nicht sicher, ob ihre Arbeit wirklich einen Sinn ergibt und fühlt sich nicht wertgeschätzt.

Gleiche Person, andere Software:

Larissa Fischer erhält einen Kundenanruf wegen einer Reklamation. Sie trägt die Informationen zum Anruf in das CRM ein. Am Nachmittag bekommt Sie über das System eine Rückmeldung von Matthias Stein, einem der Außendienstmitarbeiter. Ihm hat die Information zum Kunden sehr geholfen und er bedankt sich, bei ihr. Sie ist zufrieden und fühlt sich bestätigt, dass sie mit ihrer Arbeit einen wichtigen Beitrag zum Firmenerfolg leistet. Mit der Zeit kann Sie durch die Rückmeldungen des Außendienstes immer bessere Einträge erstellen, da sie ein sehr gutes Verständnis hat, welche Informationen für die Kollegen von Relevanz sind.

Konzept Feedback zu CRM-Einträgen

Konzept Feedback zu CRM-Einträgen

Kann also Software beitragen Mitarbeiter zufriedener und produktiver zu machen?
Ja – mit den richtigen Methoden und Werkzeugen!

Mehr als nur Usability
Bisher wurde bei der Softwareentwicklung vor allem darauf geachtet, dass die Nutzung der Software für den Nutzer nicht frustrierend ist, also eine gute Usability besteht. Dies ist allerdings lediglich ein Hygienefaktor, dessen Erfüllung zwar dafür sorgt, dass der Nutzer keine negativen Emotionen hat, es jedoch nicht schafft, positive Emotionen zu schaffen oder den Anwender bei seiner Arbeit zu motivieren. Das Schaffen positiver Erlebnisse bei der Benutzung von Software ist die Aufgabe des User Experience Designs. Dazu werden Erkenntnisse aus der Positiven Psychologie herangezogen, welche sich damit beschäftigt, wie das menschliche Wohlbefinden gesteigert werden kann.
Während bei Software für den Freizeitbereich User Experience bereits eine wichtige Rolle spielt, wurde User Experience im Businesskontext bisher noch stiefmütterlich behandelt. Dabei ist das Wohlbefinden der Mitarbeiter nicht nur etwas für Philanthropen. Positive Erlebnisse und Emotionen auf der Arbeit haben auch für das Unternehmen einen wirtschaftlichen Vorteil.
Positive User Experience: Ein Gewinn für Mitarbeiter und Betrieb
Studien aus der Positiven Psychologie zeigen, dass positive Emotionen mehr positive Konsequenzen nach sich ziehen, als einfach nur das aktuelle Wohlbefinden. So erweitern positive Emotionen das wahrgenommene Handlungs-Repertoire. Ein Mensch mit positiven Emotionen ist also flexibler in seinem Denken und Handeln. Gerade in der heutigen Zeit, in der es auf die Innovationsfähigkeit der Firmen ankommt, ist dieses flexible Mindset essentiell. Oder mit anderen Worten: ein gestresster und ängstlicher Mitarbeiter wird keine Innovationen hervorbringen.
Daneben führt eine höhere Zufriedenheit der Mitarbeiter zu einer höheren Produktivität. Ein weiterer Vorteil positiver Emotionen bei der Arbeit ist, dass diese die Widerstandfähigkeit der Mitarbeiter erhöht, welche für eine bessere Gesundheit sorgt.

Emotionen bei der Nutzung methodisch geschaffen
Nun stellt sich die Frage, wie positive Erlebnisse mittels Software geschaffen werden können. Mit dieser Aufgabenstellung hat SIC! innerhalb des Forschungsprojektes Design4Xperience in den letzten drei Jahren intensiv beschäftigt. Zusammen mit unseren Partnern aus der Forschung haben wir neue Methoden und Werkzeuge entwickelt, um die User Experience innerhalb von betrieblicher Software zu optimieren.

Eines dieser Werkzeuge sind die Erlebniskategorien. Diese beschreiben typische Erlebnis-Situationen, in welchen positive Emotionen auftreten. Um diese Situationen zu ermitteln, wurden im Rahmen einer Studie Personen zu positiven Erlebnissen während ihrer Arbeit befragt. Die ermittelten Erlebnisse wurden in 17 Erlebniskategorien eingeteilt.
Erlebniskategorien

Zusätzlich wurde untersucht, welche Randbedingungen erfüllt sein müssen, damit ein Erlebnis positive Emotionen nach sich zieht. Im vorangegangenen Beispiel hat die Innendienstmitarbeiterin eine positive Rückmeldung zu ihrer Arbeit und Wertschätzung erfahren. Dies führte bei ihr zu einem positiven Erlebnis. Die angewendeten Erlebniskategorien sind hier „Feedback erhalten“ und „Wertschätzung“. Durch intelligente Konzeption der Software können diese Erlebniskategorien in die Software integriert werden, dieses wiederum führt zu positiven Erlebnissen bei der Interaktion mit der Software. Zusätzlich können wünschenswerte Verhaltensweisen auf diese Art gefördert werden. War vorher in unserem Beispiel die Kommunikation zwischen Außen- und Innendienst quasi nicht existent, wurde diese mit der neuen Lösung ermöglicht und bestärkt.

Fazit
Durch geschickte Konzeption der Software wird es ermöglicht bestimmte Erlebnisse während der Softwarenutzung zu haben, durch welche positive Emotionen ausgelöst werden. Durch eine positive User Experience werden die Mitarbeiter motiviert und die Akzeptanz für die Software steigt. Zusätzlich können wünschenswerte Verhaltensweisen bestärkt werden.

Sie möchten mehr zum Thema Erlebniskategorien und UX Design erfahren?
Wir beraten Sie gerne!

Swift – Die eine Programmiersprache für „alles“ ?! – Teil2

Die Evolution von Swift – the next level

Teil1

Es ist gut ein Jahr vergangen (Dezember 2015) seit Swift als Open-Source Programmiersprache das Licht der Welt(-Öffentlichkeit) erblickt hat. So finde ich, dass es mal wieder an der Zeit ist zu schauen, welche Evolution und Resultate diese recht junge Programmiersprache mittlerweile nach meiner ersten Bewertung und Prognose vom April 2016 in der Open-Source Entwickler Community gefunden hat. Um eine Sache vorweg zu nehmen: Mit Swift werden bereits produktive (Web-)Portal-Projekte umgesetzt (wie beispielsweise die Webseite des dänischen Triathlon-Events Ironman; Github-Source). So hat sich Swift tatsächlich in so kurzer Zeit von einer reinen Apple-Plattform Sprache (iOS, macOS, tvOS, watchOS) zu einem Linux-freundlichen Backend/Webframework-tauglichen Gesamtsystem entwickelt. Die aktuelle Version Swift3 genießt zudem große Kompatibilität im Segment der „kleinen ARM-Architektur Computer“ wie beispielsweise dem Raspberry Pi3 und dem dafür verfügbaren Ubuntu 16.04 als Betriebssystem; ergo die Software der Internet-Of-Things (IoT) kann ab jetzt tatsächlich ebenfalls mit dieser hochmodernen und performanten Programmiersprache entwickelt werden.

Weiterlesen

Azure IoT in der Praxis – Teil 1 Systemaufbau

Azure IoT in der Praxis – Teil 1 Systemaufbau

Einleitung

Das Internet der Dinge, kurz „IoT“ ist derzeit in aller Munde. Hier übertreffen sich die „Experten“ mit Ihren Ideen und Visionen einer rosigen Zukunft. Wenn es aber um konkrete, praktische Umsetzungen geht, wenn beispielsweise die Frage beantwortet werden soll wie ein IoT Szenario in der Praxis tatsächlich gestaltet werden kann, dann wird es vertiefenden Informationen schnell sehr dünn.
Mit dieser mehrteiligen Artikelserie „Azure IoT in der Praxis“ wollen wir deshalb Abhilfe schaffen. Hier werden wir die verschiedenen Aspekte bei der Realisierung einer praxistauglichen IoT-Lösung anschaulich darstellen und beschreiben.
In diesem ersten Artikel erläutern wir einen industrietauglichen Systemaufbau und die dabei verwendeten Hard- und Software Komponenten. In den weiteren Artikeln werden wir dann einige spezielle Aspekte technisch vertiefen – beispielhaft seien hier die Themen „Datensicherheit“ oder „Alarmierung bei Störfällen“ genannt.


Wenn Sie keinen dieser Beiträge auf diesem Blog versäumen wollen, so empfehlen wir Ihnen, sich in die Mailingliste einzutragen. Sie erhalten dann eine kurze Nachricht, sobald der nächste Artikel zum Thema IoT erschienen ist. Es erfolgt keine Weitergabe der Email-Adresse an Dritte und Sie werden von uns auch keine Werbeemails bekommen. Das versprechen wir Ihnen.


Zielsetzung des IoT-Showcase

Das Team von SIC! Software hat das erste IoT Projekt mit Mobile Anbindung bereits im Jahre 2013/14 realisiert. Seitdem wächst die Zahl der erfolgreich umgesetzten Projekte ständig und damit natürlich auch der Wunsch vieler Unternehmen, mehr über diese Projekte zu erfahren und zu sehen, wie solche Lösungen erfolgreich umgesetzt werden können.
Dabei handelt es sich in nahezu allen Fällen um neuartige Konzepte und Ideen, mit denen bestehende Systeme für das digitale Zeitalter erweitert und fit gemacht werden sollen. Daher wollen unserer Kunden verständlicherweise nichts über ihre neuen Ideen veröffentlichen.
Wir haben uns daher entschlossen, einen eigenen, realitätsnahen IoT-Showcase zu schaffen, der eine durchgängige Technologiekette zeigt, wie sie von SIC! geliefert werden kann.
Dieser Showcase zeigt ein praxisnahes Beispiel von der Embedded Plattform bis hin zur Auswertung der Daten in der Cloud. Es wurde unter Verwendung von Standard-Hardware von STMicroelectronics für das IoT-System, sowie den Cloud-komponenten Microsoft Azure IoT und Microsoft PowerBI umgesetzt. Wir haben uns hier beispielhaft für die Microsoft Azure-Architektur entschieden, da dies derzeit die von unseren Kunden favorisierte IoT-Plattform ist.
Ein denkbarer Anwendungsfall einer solchen Lösung ist beispielsweise ein „Predictive Maintenance“-Szenario, bei dem der möglicherweise drohende Ausfall eines Motors erkannt wird.
Die physikalische Grundlage der Erkennung sind ungewöhnliche Schwingungsmuster, die darauf schließen lassen, dass eventuell ein Schaden am Motor vorliegt.

Auswahl der IoT-Embedded Plattform

Es gibt am Markt eine nahezu unüberschaubare Anzahl von Embedded-Plattformen für solche Anwendungen. Wir haben uns in diesem Fall für eine Evaluationshardware von STMicroelectronics entschieden. Basis ist eine auf dem STM32 Prozessor basierende Hardware (http://www.st.com/en/evaluation-tools/nucleo-f401re.html). Entscheidendes Auswahlkriterium war hier der Umstand, dass hier die für unsere Anwendung nötigen Hardwareerweiterungen für Motorsteuerung, WLAN Modul und Accelerometer-Sensorik als aufsteckbare Nucleo-Komponenten für das STM Evaluationsboard gibt.

BILD

Tiefergehende technische Details findet der interessierte Leser unter den nachfolgenden Links:
Motorsteuerung:
http://www.st.com/content/st_com/en/products/ecosystems/stm32-open-development-environment/stm32-nucleo-expansion-boards/stm32-ode-move-actuate-hw/x-nucleo-ihm11m1.html
WLAN -Modul:
http://www.st.com/content/st_com/en/products/ecosystems/stm32-open-development-environment/stm32-nucleo-expansion-boards/stm32-ode-connect-hw/x-nucleo-idw01m1.html
Accelerometer:
http://www.st.com/content/st_com/en/products/mems-and-sensors/accelerometers/lis3dh.html

Messverfahren und Sensorik

Das Messobjekt ist ein kleiner Drehstrom-Elektromotor mit 15W Leistung, der vom STM32 Board gesteuert, einen kleinen Propeller antreibt. Dieser ist schwingend gelagert montiert. Unter dem Motor ist der Accelerometer-Sensor am Motorträger montiert, mit welchem die Schwingungen des Motors gemessen werden.

Die fehlerhaften Schwingungen im Betrieb werden simuliert, indem am Propeller ein Klebeband angebracht und somit eine Unwucht erzeugt wird.

Signal Theorie und Motor Vibration

Spannend war die Frage, ob es mit dem Accelerometer möglich ist, die feinen Abweichungen der Schwingungsmuster sicher zu detektieren. Die üblichen Accelerometer haben einen Messbereich von +/- 2g mit einer Auflösung von 16 Bit. Das bedeutet, ein Bit entspricht 0,5mg.
Wenn man die technische Dokumentation studiert, stellt man aber fest, dass die tatsächliche, sicher zu detektierende Auflösung eher im Bereich von 1mg aufwärts liegt. (Siehe http://www.st.com/resource/en/datasheet/lis3dh.pdf). Dies sollte aber für diese Anwendung ausreichend sein.
Der kleine Drehstrommotor in unserem Prototyp läuft mit einer Drehzahl von 1500 U/Min, also 25 U/s. Es soll eine mögliche Exzentrizität gemessen und erkannt werden. Dazu gehen wir davon aus, daß jede Vibration eine Sinuswelle produziert. Zur Vereinfachung nehmen wir ferner an, dass die Drehzahl des Motors die niedrigste Frequenz produzieren wird, also rund 25Hz. Um die Sinuswelle sicher zu erkennen, muss mindestens mit der doppelten Frequenz gemessen werden, also 50Hz. In unserer Beispiellösung messen wir mit einer Abtastrate von 400 Hz. Das sollte also auch für deutlich höhere Drehzahlen des Motors noch ausreichend sein.
Für die Errechnung der Vibration gibt es mehrere Möglichkeiten. Wir haben uns hier für die Varianz als einfachste Möglichkeit entschieden (https://de.wikipedia.org/wiki/Stichprobenvarianz). Entscheidend für die Messung ist die Definition des Zeitabschnittes für eine einzelne Messung. In unserem Fall nehmen wir 512 Samples, was bei der Frequenz von 400 Hz eine Aufzeichnungsdauer von 1,2s die Daten zum Analysieren liefert.
Das ermittelte Ergebnis ist ein Messwert, welcher die Abweichung von einem Mittelwert zeigt und damit das Maß der Vibration. Steigt dieser Wert, steigt die Vibration.

Azure IoT Cloud Anbindung Embedded

Nach der Auswahl der Hardware für die Messung und Kommunikation beschrieben wurde, folgt nun der interessante Teil – die Software zur Datenerfassung und Auswertung.
Für die Integration in die Azure Cloud stellt ST eine Referenz-Implementierung für sein Evaluationsboard zur Verfügung, auf die wir weiter aufgebaut haben (http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32-ode-function-pack-sw/fp-cld-azure1.html).

Quelle: http://www.st.com/content/ccc/fragment/product_related/rpn_information/board_photo/group0/f3/24/5d/c0/08/39/4c/af/FP-CLD-AZURE1%20image/files/fp-cld-azure1.jpg/_jcr_content/translations/en.fp-cld-azure1.jpg

Das reine IoT SDK von Microsoft, welches im ST-Beispielcode enthalten ist, kann unter dem nachfolgenden Link eingesehen werden (https://github.com/azure/azure-IoT-sdk-c).
Und da der Code ein Multi-Threading verwendet, ist natürlich auch ein entsprechendes Betriebssystem auf der STM32 Plattform erforderlich. Wir setzen hier aus das vielfach bewährte FreeRTOS, das auch von ST für den IoT-Einsatz empfohlen wird.

Microsoft Azure IoT Hub

Der eingesetzte Cloud-Service wird aus den entsprechenden Komponenten auf der Microsoft Azure Seite zusammengestellt. Als zentraler Knotenpunkt wird der ein Azure IoT Hub eingesetzt. Dieser dient dazu, die Daten aller IoT-Geräte entgegenzunehmen und für die weitere Auswertung den nachfolgenden Diensten zur Verfügung zu stellen.
Das Aufsetzen des IoT Hub ist unkompliziert, da dieser einfach im Azure Portal angelegt werden kann. Für diesen Showcase haben einen kostenfreien Demo- Hub eingesetzt, der bis zu 8000 Meldungen pro Tag verarbeiten kann.

Dort werden die Zugangsdaten erzeugt, welche man benötigt, um die IoT-Geräte zu Authentifizieren, damit diesen dann mit dem Hub kommunizieren können.
Anmerkung: Das Thema Sicherheit in IoT Anwendungen werden wir in Kürze in einem weiteren Artikel auf diesem Blog behandeln.

Die Darstellung der Daten im IoT Hub ist allerdings noch relativ unspektakulär. Man sieht zwar, dass Daten fließen und wie viele Geräte aktiv sind, aber für eine sinnvolle Auswertung ist dies noch nicht ausreichend.

Microsoft Azure Power BI

Um nun die gemessenen Vibrationen zu überwachen und Abweichungen erkennen zu können, werden die erfassten Messdaten mit dem Microsoft Power BI visualisiert.
Zu diesem Zweck bietet Microsoft Azure den Dienst „Stream Analytics“ an. Stream Analytics dient – wie der Name schon sagt – dazu, Datenströme zu transportieren und zu analysieren. Dabei werden der Stream Analytics Auftrag und der IoT-Hub am selben Azure-Standort gehostet, um zusätzliche Hosting-Kosten zu vermeiden.

Als Eingabequelle wird der angelegte IoT Hub ausgewählt, als Datenausgabe ein PowerBI Konto.

Damit fließen die erfassten Messdaten vom IoT-Gerät über den Azure IoT Hub und den Stream Analytics Dienst in das Microsoft PowerBI.
Dort wird ein Dashboard zu Visualisierung angelegt, auf dem in einem Liniendiagramm die Werte unserer IoT-Plattform dargestellt werden. Dieses Streamingdataset lässt sich jetzt mit allen von PowerBI zur Verfügung gestellten Mitteln auswerten.

Auswertung und Erkennung

Nachfolgende Masken zeigen, wie unser Algorithmus zur Schwingungserkennung funktioniert.
Im folgenden Diagramm sieht man deutlich den Sprung im Diagramm „Schwingung“ genau in dem Moment, wo der Motor gestoppt das Klebeband befestigt wird.

Beginnt sich der Motor mit angebrachtem Klebeband wieder zu drehen, so erhalten wir einen deutlich höheren Schwingungswert. Dies ist am höheren Schwingungsniveau zu erkennen.
In der Praxis, zum Beispiel bei einem langsam eintretenden Lagerschaden, würde dieser Schwingungs-Messwert wohl eher langsam ansteigen und nicht so schlagartig wie bei unserem Eingriff mit dem Klebeband. In diesem Falle wäre auch optisch am langfristigen Verlauf nicht viel zu bemerken, weshalb hier eine geeignete Logik zum Auswertung der Messwerte und zur Alarmierung vorzusehen ist.
Wie man auf Basis dieser Daten ein entsprechende Erkennung und Alarmierung implementiert, wird Inhalt eines nachfolgenden, vertiefenden Blogartikels sein.


Wie hat Ihnen dieser Artikel gefallen? Gerne lesen wir Ihre Kommentare.
Wenn Sie keinen dieser Beiträge auf diesem Blog versäumen wollen, so empfehlen wir Ihnen, sich in die Mailingliste einzutragen. Sie erhalten dann eine kurze Nachricht, sobald der nächste Artikel zum Thema IoT erschienen ist. Es erfolgt keine Weitergabe der Email-Adresse an Dritte und Sie werden von uns auch keine Werbeemails bekommen. Das versprechen wir Ihnen.


 

Innovationsentwicklung mit User Story Mapping

In unseren Kundenprojekten wird von unseren UX Design Spezialisten regelmäßig ein sehr hilfreiches und nützliches Tool eingesetzt: Das „User Story Mapping“. Hierbei handelt es sich um eine von Jeff Patton entwickelte Methode, mit der im Rahmen von agiler Produktentwicklung eine stimmige User Experience geschaffen wird. So lässt sich der Erfolg für die auf diese Weise realisierten digitalen Produkte maximieren.

Beim User Story Mapping wird der Arbeitsfluss des Users, also des Produktnutzers, in einzelne „User Stories“ unterteilt und mit Hilfe von Klebezetteln auf einer Wand in Form einer Art Karte („Map“) visualisiert. Die Flexibilität der Klebezettel ermöglicht eine schnelle und einfache Optimierung der Prozesse bzw. des Produktes durch Umsortieren, Aufteilen, Ergänzen, Erweitern, Vertiefen, usw. An einer User Story Mapping Session nehmen idealerweise alle am Produkt Beteiligten – vom Auftraggeber über den Designer bis zum Entwickler – teil und erarbeiten einen Konsens. Durch das bessere gemeinsame Gesamtverständnis vom Produkt, seinen Eigenschaften und seiner Anwendung wird die Gefahr reduziert, sich in unwichtigen Details zu verzetteln oder das Produkt an den Bedürfnissen des Produktnutzers vorbei zu entwickeln.

Mit User Story Mapping wird ein Produkt mit genau jenen Features entwickelt, die für den Anwender wirklich nützlich und dabei auch noch realisierbar und bezahlbar sind. Dabei können mehrere aufeinanderfolgende Release-Stufen festgelegt werden – angefangen vom „Minimum Viable Product (MVP)“ über Zwischenversionen bis zur finalen Version mit dem kompletten Feature-Set. Die in der ersten Session erstellte User Story Map bildet gleichzeitig eine Basis für das Projektmanagement. Im Verlauf des Projekts kann und soll die Story Map im Rahmen einer agilen Produktentwicklung in weiteren Sessions anhand von User Feedback, Tests und Erfahrungen dann permanent weiter optimiert werden.

Entsprechend einem vielfach von unseren Kunden geäußerten Wunsch nach einer kompakten Übersicht und Kurzanleitung zum User Story Mapping haben unsere Grafiker eine Infografik mit dem Titel „Innovationsentwicklung mit User Story Mapping“ erstellt, die wir hiermit gerne allen an der Methode Interessierten zur Verfügung stellen. zur Infografik

vorschau-infografik-user-story-mapping

MQTT Protokoll – Anwendungsbeispiele

Viele Leser unseres Blogs haben uns nach dem Studium unseres Grundlagenartikels zum MQTT-Protokoll nach Anwendungsbeispielen gefragt. Diesem Wunsch wollen wir gerne entsprechen und präsentieren Ihnen nachfolgend eine kleine Sammlung einiger interessanter Projekte, bei denen das MQTT-Protokoll zum Einsatz kommt.

Wir bei SIC! Software setzen das MQTT Protokoll im Bereich von Embedded Projekten sehr häufig ein, da dieses Protokoll einfach zu handhaben ist und sich dank breiter Unterstützung zum DeFacto-Standard im Bereich von Internet of Things (IoT) und Industrie 4.0 entwickelt hat.

Wie z.B. beim Forschungsprojekt IMPROVE, bei dem das MQTT Protokoll dazu eingesetzt wird, um Echtzeitdaten vom Fahrzeug zu übertragen.
http://www.sic-sales.de/forschungsprojekte/improve-automotive/

 

Da unsere Kundenprojekte der Vertraulichkeit unterliegen, listet die nachfolgende Sammlung beispielhaft öffentlich zugängliche Projekte mit MQTT-Support auf.

 

Beispiel 1: Übermittlung von Temperatursensor-Daten

Implementierung von MQTT auf dem  ESP8266 WIFI Funkmodul mit einer „einfachen“ publish / subscribe Routine.

http://www.s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/113-mqtt-basic-esp8266-mqtt-example

Beispiel 2: Übertragung des Haustürklingel-Signals

Installation des Moskito MQTT Broker auf einem Raspberry Pi. Ein ESP8266 nimmt das Klingelsignal an der Haustür auf und sendet es drahtlos an Fhem via MQTT.

http://blog.wenzlaff.de/?p=6487

Beispiel 3: Temperatur-Überwachung (Englisch)

Eine Musterhafte Lösung zur Überwachung von Temperaturen mit dem ESP8266 WIFI Funkmodul und der Anbindung an einen MQTT-Broker-Dienst unter Ubuntu:

http://www.instructables.com/id/Remote-Temperature-Monitoring-Using-MQTT-and-ESP82/

Beispiel 4: Basis-Plattform für Home-Automation (Englisch)

Implementierung eines MQTT-Stacks auf einem ATMEL  ATmega328p

http://blog.atx.name/building-avr-board-with-mqtt-support-for-iot/

Beispiel 5: Steuerung einer LED-Beleuchtung (Englisch)

Steuerung einer LED-Beleuchtung mit einem WS2812 LED Controller über das MQTT-Protokoll.

http://www.instructables.com/id/ESP8266-Led-Strip-MQTT-Control-Lights-WS2812/?ALLSTEPS

Beispiel 6: Regelung der CPU-Kühlung eines Raspberry Pi (Englisch)

Regelung der CPU-Kühlung eines Raspberry Pi über einen mit dem MQTT-Protokoll konfigurierbaren PID Regler:

http://www.instructables.com/id/PID-Control-for-CPU-Temperature-of-Raspberry-Pi/

Beispiel 7: Steuerung eines LCD-Displays (Englisch)

Applikationsbeispiel zur Steuerung eines LCD-Displays am INTEL Edison über das MQTT-Protokoll:

http://www.instructables.com/id/MQTT-what-is-this/

Weitergehende Grundlagen und Informationen zur MQTT-Standardisierung sind auf der Webseite http://mqtt.org/ beschrieben.

IoT Protokolle – MQTT vs. AMQP

Das „Internet of Things“ – kurz „IoT“ – ist im Moment das große Thema in der Industrie und Softwarebranche. Nachdem wir schon in einem etwas älteren Blockartikel das Thema MQTT aufbereitet und analysiert haben, ist es Zeit, sich einem zweiten wichtigen Protokoll im Umfeld von IoT anzunehmen. In diesem Artikel werden wir die beiden Protokolle vergleichen und mögliche Unterschiede bei den Einsatzszenarien beschreiben.

Wer heute ein IoT-Projekt umsetzen möchte, muss sich vor allem Gedanken darum machen, wie er die auszutauschenden Daten möglichst effizient und standardisiert übertragen kann. Zu diesem Zweck gibt es verschiedenste Protokollstandards, die entwickelt wurden, damit Plattform und Technologie übergreifend miteinander kommunizieren können.

Speziell im IoT Umfeld erfüllen die entwickelten Protokolle vor allem noch die Aufgabe möglichst mit wenigen Ressourcen auszukommen.

Was ist also AMQP und was kann es leisten?

AMQP steht für Advanced Message Queuing Protocol und wurde durch ein Konsortium von großen Unternehmen aus verschiedenen Branchen – u.a. VMware, Microsoft und Cisco – entwickelt. Bereits in 2010 gab es den ersten Draft des Protokolls.

Im Kern handelt es sich um ein asynchrones Protokoll zur Nachrichtenübertragung. Die bisher beste Erklärung zur Idee hinter AMQP findet man auf der Seite von RabbitMQ (https://www.rabbitmq.com/tutorials/amqp-concepts.html).

AMQP funktioniert demnach nach folgendem Prinzip:
Nachrichten werden an sogenannte Börsen (Exchanges) übertragen (vergleichbar mit einem Postamt). Die Börsen verteilen dann Nachrichtenkopien in Warteschlangen (Queue) basierend auf Regeln, sogenannten Bindings.

Die Nachrichten werden dann vom Empfänger direkt abgeholt, wenn er das möchte. Alternativ kann der Empfänger die Nachrichten auch bei einer Warteschlange abonnieren und bekommt diese dann direkt zugestellt.

Wenn die Nachrichten publiziert werden, kann der Herausgeber der Nachricht diese noch mit Attributen (Meta-Daten) versehen. Diese Metadaten können vom Empfänger beliebig genutzt werden.

Nachrichten bleiben so lange in den Warteschlangen, bis der Empfänger bestätigt hat, die Nachricht auch wirklich empfangen zu haben. Damit ist auch bei schlechtem Netz und Abbrüchen bei der Verbindung sichergestellt, dass die Nachricht den Empfänger erreicht.

Wenn eine Nachricht nicht zugestellt werden kann, erhält der Sender eine entsprechende Nachricht.
Die Umsetzung der Börse und der Warteschlange erfolgt innerhalb des sogenannten Brokers. Ein Broker ist z.B. der freie Server von RabbitMQ.

Die Börse ist dafür zuständig, die Nachrichten in eine oder mehrere Warteschlangen zu übertragen. Die Regeln dafür leiten sich aus den vordefinierten Austauschformaten (exchange types) und den Bindings ab.

Es gibt vier solche Austauschformate:

  • Direct –> Stellt eine feste Verbindung zwischen einer Börse und einer Warteschlange dar. Wenn eine Nachricht mit einem entsprechenden Schlüssel ankommt, wird diese gleich an die verknüpfte Warteschlange zugestellt.
  • Fanout –> Wird für sogenannte Broadcast Nachrichten verwendet. Die Nachricht wird von der Börse an alle angeschlossenen Warteschlangen zugestellt
  • Topic –> Wird für Publish/Subscribe Szenarien verwendet. Die Nachrichten werden an eine oder mehrere Warteschlangen ausgeliefert, abhängig vom Binding Key. Folgendes Bild von RedHat veranschaulicht das sehr schön.

    https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/2/html-single/Messaging_Programming_Reference/index.html
  • Headers –> Die Zustellung der Nachricht zur Warteschlange erfolgt hier über den Nachrichten-Header und nicht den Routing Key. Es ist vergleichbar mit dem Direct Routing – nur mit etwas mehr Möglichkeiten zur Regelerstellung.

Neben den Austauschformaten gibt es eine Reihe von Attributen für die Nachrichten. Die wichtigsten sind:

  • Name
  • Durability (gibt an, ob die Börse einen Neustart des Broker übersteht)
  • Auto-delete (Börse wird gelöscht, wenn keine Warteschlange diese benötigt)

AMQP vs. MQTT im Vergleich

Der größte Unterschied der beiden Protokolle besteht in den Möglichkeiten für die Nachrichtenzustellung. Während MQTT ausschließlich auf Publish/Subscribe basiert, lassen sich mit AMQP auch andere Zustellungsformen realisieren.

Außerdem ist der Unterschied bei der Implementierung nicht zu unterschätzen. MQTT ist mit seinen 5 Methoden relativ schnell und einfach umzusetzen, während AMQP schon einen vergleichsweise großen Umfang mit sich bringt. Das betrifft sowohl die Definition des eigenen Protokoll wie auch die Implementierung und Test.

Die kleinste Paketgröße bei AMQP ist mit 60 Byte auch nicht zu vernachlässigen. MQTT begnügt sich im besten Fall mit 2 Byte. Das beeinflusst insbesondere bei einer großen Zahl von Geräten und Nachrichten den aufzuwendenden Aufwand erheblich. Dazu kommen größer Laufzeiten der Pakete die je nach Anwendungsfall auch kritisch zu betrachten sind.

Es gilt also abzuwägen, ob der Funktionsumfang von AMQP im jeweiligen Anwendungsfall wirklich benötigt wird oder nicht. Wenn man mit dem Publish/Subscribe Model von MQTT auskommen kann, hat man in jedem Fall eine einfacher umzusetzende und auch ressourcenschonende Lösung.

Der Amazon Dash-Button Rev. 2 – Überraschung für Hacker und Bastler

Der Amazon Dash Button ist im Moment in aller Munde. Es gibt sehr viele Blogbeiträge und Diskussionen, was man mit diesem Teil alles anstellen kann und was es für den Handel und den Verbraucher bedeutet.

Wir wollen uns in diesem Artikel etwas genauer mit den Innereien des Button beschäftigen, um zu bewerten, was alles an Potential in diesem kleinen Stück Hardware steckt.

Es gibt im Netz einige sehr schöne Teardown-Beiträge, die wir natürlich auch studiert haben. Einer davon ist dieser. Auch hier gibt es eine sehr schöne Beschreibung der Komponenten.
In großer Erwartung haben wir also gleich begonnen, unsere neu erhaltenen Buttons zu öffnen. Der Button ist nicht ohne weiteres zu öffnen, da das Gehäuse verschweißt ist. Am einfachsten erschien es uns, den Button an den bestehenden Nähten mit einem Cutter-Messer aufzuschneiden. Ist dieser erstmal offen, müssen noch drei Torx T5 Schrauben gelöst werden und schon hält man die Platine in den Händen.

img_0457

Nach dem Öffnen kam dann gleich die erste Überraschung zum Vorschein. Die verbaute Hardware sah anders aus, als auf den bisherigen Teardown-Beschreibungen. Anscheinend hat Amazon mit den in Europa gelieferten Buttons das Hardware-Design komplett geändert. Es findet sich jetzt auch ein „Rev02“ Aufdruck auf der Platine.

img_0445

Es hat sich viel verändert am Hardware-Design. Amazon hat hier deutlich versucht, die Kosten zu reduzieren. Erstes Indiz dafür ist die normale AAA-Batterie anstelle der bisherigen Lithium Batterie in den alten Buttons. Wie lange diese wirklich hält, wird sich erst noch zeigen müssen.

Der Prozessor wurde auf einen Atmel ATSAMG55J19A-MU umgestellt. Davor kam ein STM32F205 zum Einsatz. Dazu kommt ein Atmel ATWINC1500B Wifi Chip. Der „alte“ Button wurde von einem Broadcom Chipset befeuert. Am erstaunlichsten ist, dass es auch einen Bluetooth LE Chip gibt. Hier kommt ein Cypress CYBL10563-68FNXI zum Einsatz. Der Blueooth Chip wird ja bei der heutigen Anwendung des Button nur für die Konfiguration gebraucht. Hier sind wir gespannt, ob Amazon damit zukünftig noch mehr macht.

img_0441 img_0434

Die spannende Frage lautet nun, ob es gelingt den Button mit einer alternativen Software auszustatten, um ihn auch für andere Zwecke einzusetzen. Dafür haben wir die sieben Pads auf der Platine neben dem Prozessor verkabelt und mit dem JTAG Debugger verbunden.

img_1231

Gleich darauf folgt die Ernüchterung …
Das System meldet, dass der Chip gelockt ist. Amazon hat scheinbar aus den vielen Hacking-Versuchen mit dem alten Dash-Button seine Lehren gezogen und den neuen entsprechend abgesichert. Damit ist es leider nicht möglich, den Chip neu zu beschreiben oder die Firmware auszulesen.

Eine weitere Recherche im Netz brachte noch diesen spannenden Artikel zum Vorschein: http://key-basher.blogspot.de/2016/09/amazon-dash-button-version-2.html.

Er beschreibt, was wir auch schon gefunden hatten – allerdings noch eine Idee mehr. Leider stellte sich heraus, dass der Reset-Pin des Chips mit dem Masse-Pad unter dem Chip verbunden ist. Damit müsste man, um den Chip zu löschen, selbigen auslöten. Danach muss die Masseverbindung durchtrennt werden und der Chip muss wieder eingelötet werden.

Mit dieser Erkenntnis scheint es erst einmal nicht möglich, den Button mit vertretbarem Aufwand mit neuer Funktionalität zu versehen. Wir werden das weiter beobachten.