Manifest für Entwickler intelligenter Systeme: 15 Prinzipien

Wir machen Sie auf einen Artikel von Vladislav Zaitsev ( vvzvlad ) aufmerksam, einem eingeladenen Gast unseres Blogs. Vladislav beschäftigt sich seit langem mit dem Thema „Smart Homes“. Zusammenfassend fasst er die folgenden Grundprinzipien für den Entwurf solcher Systeme zusammen.

Heute möchte ich mit Ihnen über Smart Homes im Besonderen und IoT-Geräte im Allgemeinen sprechen. Dies wird jedoch kein gewöhnlicher Artikel sein: Es werden keine Drüsen, Links zu Herstellern, Codeteile und Repositories auf dem Github vorhanden sein. Heute werden wir etwas Höheres diskutieren - die Prinzipien, nach denen „intelligente“ Systeme organisiert sind.



Wenn Sie den Artikel weiter lesen, stimmen Sie zu, dass Sie mit dem folgenden Haftungsausschluss zufrieden sind.

---

Ein Smart Home ist ein System, das einen Teil der täglichen Sorgen einer Person übernimmt. Ab hier folgt das erste und grundlegendste Prinzip:

1. Ein Smart Home sollte das Leben immer einfacher machen.

Ein Smart Home ist ein System fürs Leben, kein Spielzeug für Geeks. Jedes System, das schwieriger zu bedienen ist als herkömmliche Switches, ist kein Smart Home.

Jedes neue Produkt sollte auf Übereinstimmung mit diesem Prinzip getestet werden. Wenn es das Leben nicht einfacher macht und Sie nicht verstehen, wie Sie es einfacher machen können, gehört es nicht in ein intelligentes Zuhause. Sie können versuchen, es sich als Lernsystem vorzustellen.

---

Das zweitwichtigste Prinzip betrifft die Interaktion des Benutzers mit dem System:

2. Eine gute Benutzererfahrung ist wichtiger als Funktionalität.

Wertlos ist ein cooles Werkzeug, das nicht normal verwendet werden kann. Bequeme und zuverlässige Geräte mit eingeschränkter Funktionalität sind für "alle Gelegenheiten" eher erfolgreich als anspruchsvolle Produkte.

2.1. Praktische Schnittstellen sind besser als Anpassbarkeit.

Sie verstehen nicht, wie Sie eine Reihe von Funktionen und eine einfache Benutzeroberfläche speichern können? Sie schieben alle Funktionen hintereinander in der Hoffnung, dass der Benutzer herausfindet, was er braucht? Raus aus dem Beruf!
Sie verstehen nicht, wie Sie Komfort und eine Reihe von Einstellungen kombinieren können? Spenden Sie die Einstellungen. Jede Funktionalität ist cooler als ein normaler Switch, aber eine übermäßige Komplexität zwingt den Benutzer leicht dazu, zum Switch zurückzukehren.

Gleiches gilt für die Arbeitsqualität. Ein Knopf, der das Licht einfach einschaltet, ist besser als ein Schieberegler zur Helligkeitsanpassung, der manchmal Störungen verursacht:

2.2. Die Qualität der implementierten Funktionen ist wichtiger als ihre Quantität.

Ein wenig zuverlässige, aber bewährte Funktionalität ist besser als viel, aber es funktioniert irgendwie.
Einer der Mechanismen, die durch die Evolution in der menschlichen Psyche fixiert werden, ist eine aktivere Reaktion auf negative Reize. Negative Faktoren sind wichtiger als positive: Das Überspringen der Annäherung eines gefährlichen Raubtiers ist viel schlimmer, als eine köstliche Frucht auf einem Baum nicht zu bemerken und nicht zu essen. Wenn Ihr System keine Funktionen hat, ist es nicht beängstigend, es ist nur das Fehlen eines positiven Anreizes. Aber die bestehende Funktion, aber sie funktioniert schlecht, ist ein negativer Anreiz: Sie wird leichter und länger in Erinnerung behalten.

2.3. Die Implementierung des Systems sollte die übliche Arbeitsgeschwindigkeit nicht verringern.

Verzögerungen sind nicht akzeptabel, da sie die Benutzererfahrung beeinträchtigen. Dies ist auch ein negativer Anreiz. Wenn eine Person keine Verzögerung ² zwischen dem Klicken eines herkömmlichen Schalters und der Aufnahme von Licht bemerkt, sollte sie dies in Ihrem System nicht bemerken.

Modernes Eisen arbeitet mit sehr hoher Geschwindigkeit. Es ist kein Problem, auf Mikrocontrollern Frequenzen von mehreren zehn Megahertz und mindestens zehn Kilobit pro Sekunde zu erreichen, selbst über Funk. Wenn Sie unter diesen Bedingungen kein System erstellen können, spürt der Benutzer keine Verzögerungen im Betrieb. Verlassen Sie den Beruf!

2.4. Das System sollte die bereits gebildeten Gewohnheiten des Benutzers nicht brechen.

Ihr System ist nur ein kleines Stück menschlichen Lebens. Die Lebenszeit einer Person übersteigt die Lebensdauer des Systems bestenfalls um ein paar Mal und im schlimmsten Fall um eine Größenordnung. Ihr System wird so bleiben, wie es will, und das menschliche Leben wird weitergehen. Und in diesem Leben hat sich ein Mensch Gewohnheiten in Bezug auf die bevorzugte Helligkeit des Lichts, die Position der Schalter und die Art und Weise gebildet, wie es für ihn bequem ist, das Licht einzuschalten und das Klima zu Hause zu kontrollieren.

Sie können diese Gewohnheiten nicht mit Gewalt ändern. Es ist möglich anzubieten. Zu erzwingen - es ist unmöglich.
Sie können dem Benutzer nicht sagen, "jetzt schalten Sie das Licht des Telefons ein - es ist stilvoll, modisch, jugendlich." Dies ist eine Verletzung dieses und mehrerer anderer Grundsätze.

Was tun?

2.5. Das System sollte neue Erfahrungen bringen und nicht versuchen, die alten zu ersetzen.

Wenn Sie der Meinung sind, dass Ihre Art der Systemverwaltung zu Hause besser ist als die alte, bieten Sie sie dem Benutzer an. Wenn es wirklich bequemer ist, wählt er eine neue aus (ja, verschiedene Methoden passen zu verschiedenen Menschen). Sie können (und sollten) ihm nur eine Wahl geben.

---

Ein wichtiger Platz in einem Smart Home ist die Logik der Arbeit. Was bestimmt, nach welchen Regeln dieses Smart Home funktioniert? Und das folgende wichtige Prinzip ist genau das Richtige:

3. Der Benutzer kann in der ihm zugänglichen Logik nicht eingeschränkt werden.

Wenn der Benutzer den Wasserkocher ³ einschalten möchte, wenn die Temperatur im Raum steigt, geben Sie ihm die Möglichkeit, dies zu tun. Eine Situation sollte ausgeschlossen werden, wenn es keine physischen oder Software-Einschränkungen gibt, um eine bestimmte Aktion auszuführen, diese jedoch nicht verfügbar ist, da der Entwickler dachte, "niemand wird dies jemals brauchen".

3.1. So einfach wie möglich: Das Schreiben von Logik sollte keine besonderen Kenntnisse über das Systemgerät erfordern

Wenn Sie Geräte unterschiedlicher Versionen mit unterschiedlichen Protokollen haben, stellen Sie sicher, dass der Benutzer nur in wirklich notwendigen Fällen davon Kenntnis hat, wenn Sie nicht darauf verzichten können. Wenn Sie den Benutzer vor dem Erwerb von Spezialwissen bewahren können, wenn auch auf Kosten der Entwickler, tun Sie dies. Der Entwickler wird zwei Tage und tausend Benutzer pro Stunde verbringen. Achtundvierzig Stunden gegen tausend? Die Antwort liegt auf der Hand.

Wie schläfst du, John ist ein Serienprogrammierer?

3.2. Geräte mit den gleichen Funktionen müssen gleichermaßen gesteuert werden.

Der Benutzer muss nicht wissen, dass das Wasserventil von einigen Befehlen und der Wasserhahn von anderen gesteuert wird. Wenn beide das Wasser in der Leitung steuern, müssen beide dieselbe Benutzeroberfläche haben: „offenes Wasser“ und „geschlossenes Wasser“.

---

Wir alle leben in der physischen Welt. Der menschliche Körper und das Gehirn sind so geformt, dass sie mit physischen Objekten interagieren. Daher das Prinzip:

4. Physische Steuergeräte sind besser als virtuelle.

Alle, selbst die besten Anwendungen auf dem Telefon mit virtuellen Steuertasten, verlieren an der richtigen Stelle den üblichen physischen Schalter.

Eine andere Sache ist, dass sich der Schalter an der richtigen Stelle befinden muss . Daher eine weitere wichtige Regel:

5. Radio ist besser als Kabel.

Kabelgebundene Systeme sind zuverlässig, aber nur über Funk können Sie einen neuen Schalter oder ein neues Relais für die Lampe installieren, ohne sie erneut reparieren zu müssen. Und Transfer, wenn Sie vom vorherigen Ort gelangweilt sind. Dieses Prinzip hat jedoch seine Ausnahmen:

5.1. Schlechtes Radio ist schlimmer als Kabel.

Bei einem guten Radio können Sie nicht darüber nachdenken, wie weit die Geräte von der zentralen Steuerung entfernt sein sollten. Ein gutes Funkgerät sind die Mesh-Netzwerkprotokolle : ZigBee, Z-Wave, 6LoWPAN und so weiter.

Alle anderen Optionen sind schlechtes Radio. Wi-Fi ist ein schlechtes Radio. Selbstgemachte Protokolle einzelner Unternehmen (sie sind unter dem Namen "433 MHz" selbst erstellt, obwohl sie auf anderen Frequenzen liegen können und sich stark voneinander unterscheiden können) - schlechtes Radio.

Wi-Fi ist schlecht, weil es unmöglich ist, vollwertige "schlafende" Geräte auf seiner Basis herzustellen, und es schwierig ist, eine automatische Konfiguration sowie Kompatibilitätsprobleme mit anderen Wi-Fi-Geräten im Haus durchzuführen. Einfache hausgemachte Protokolle sind schlecht, da sie häufig keine Zustellungskontrolle, Verschlüsselung oder verfügbaren Spezifikationen enthalten. Keiner von beiden verfügt über ein Mesh-Routing, was häufig zu Problemen wie "Aber ich kann keinen Schalter in diese Ecke stellen - zu weit vom Sender entfernt" führt.

---

Es ist unmöglich, ein System mit absoluter Zuverlässigkeit und ohne Wartungsbedarf herzustellen. Geräte fallen aus, im Netzwerk treten Spannungsspitzen auf, Wasser fließt aus der Wohnung des Nachbarn, Batterien entladen sich, Plastikrisse, das Kind gießt Suppe auf die Lampe und so weiter. Aber:

6. Reparatur, Aktualisierung, Wartung und Diagnose sollten einfach sein.

Im B2B ist alles klar: Es gibt einen Benutzer, einen Entwickler und einen Bediener - eine Person oder Organisation, die weiß, wie das System funktioniert und auf professioneller Ebene damit arbeiten kann. Niemand benötigt Buchhalterkenntnisse in Programmierung unter 1C, dies ist eine besondere Person. Und niemand verlangt von einer Person, die ein Büro mietet, dass sie versteht, wie die Belüftung darin funktioniert - seine Aufgabe ist es zu sagen: „In unserem Büro ist es stickig.“

Eine kompetente Entscheidung zum Kauf eines Systems basiert auf der Berechnung der Gesamtbetriebskosten, die sich aus der Summe des Systempreises und den Betriebskosten zusammensetzt.
In den Systemen, die eine Person zu Hause verwendet, ist alles komplizierter. Dort sind Bediener und Benutzer ein und dieselbe Person und verfügen zudem häufig nicht über die erforderlichen Kenntnisse über das System. Leider sind dies die Grenzen des Verbrauchermarktes. Daher die folgenden Prinzipien:

6.1. Das Gerät sollte entweder funktionieren oder nicht. Es gibt kein drittes.

Die Wahrscheinlichkeit von Arbeit, Teilarbeit und fehlerhafter Arbeit ist nicht zulässig. Sie sollten keine Situationen zulassen, in denen Ihr Gerät jedes zweite Mal funktioniert oder nicht einmal von zehn. Wenn Sie der Meinung sind, dass Ihr Gerät nicht richtig funktioniert, sollten Sie es vollständig ausschalten - aus Sicherheitsgründen und um eine positive Benutzererfahrung zu gewährleisten. Das Ersetzen des Geräts ist unangenehm, aber es ist besser, den Benutzer zum Ersetzen zu zwingen, als sich eine Meinung über das System zu bilden, die „einmal funktioniert“. Das System muss sich in einem genau definierten Zustand befinden: Wenn es ausfällt, funktioniert es nicht. Wenn es nicht ausfällt, funktioniert es.

Wenn Sie fest davon überzeugt sind, dass eine Verschlechterung der Funktionalität akzeptabel ist, sollten Sie den Benutzer dennoch mit einer klaren Meldung warnen: „Es wurde ein Fehler des zweiten Dimmerkanals festgestellt. Der Dimmer muss ausgetauscht werden. Den ersten Dimmerkanal weiter benutzen? Ja Nein"

6.2. Das Ersetzen eines defekten Geräts sollte einfach sein.

Das System muss modular aufgebaut sein. Wenn der Benutzer den Sensor kaputt macht, muss er nur den Sensor austauschen. Sie können nicht verlangen, das Relais mit dem Bedienfeld zu wechseln, da es in der Produktionsphase daran angebracht ist.

Sie können nicht einmal sagen, dass nur unser Spezialist einen neuen Sensor installieren kann, da es mit der Entwicklung Ihres Systems offensichtlich nicht genügend Spezialisten für Millionen möglicher Benutzer gibt, was bedeutet, dass irgendwann Probleme auftreten. Natürlich wird der Benutzer das Gerät nicht selbst reparieren, aber im Falle eines Ausfalls sollte er in der Lage sein, es zu ersetzen.

6.3. Nachrichten löschen.

Wenn etwas schief gelaufen ist, sollte der Benutzer darüber Bescheid wissen und wissen, was genau schief gelaufen ist.
Es ist unmöglich, dem Benutzer "Fehler Nr. 45" mitzuteilen, was bedeutet, dass nur der Mitarbeiter des technischen Supports diese Meldung versteht. Er muss sagen: „Das Gerät reagiert nicht. Versuchen Sie, es neu zu starten, erneut zu binden oder den Dienst zu kontaktieren. Fehler # 45. "

Es ist unmöglich zu erkennen, dass das Gerät nicht reagiert (wenn Sie die Möglichkeit dazu haben), und den Benutzer nicht darüber zu informieren. Es ist nicht sehr angenehm, eine Nachricht über Probleme zu erhalten, aber es ist viel unangenehmer zu verstehen, dass das Gerät seit einer Woche nicht mehr funktioniert, genau in dem Moment, in dem Sie es dringend benötigt haben.

6.4. Mangel an unnötigen Informationen in Nachrichten.

Gleichzeitig müssen Sie jedoch keine Debug-Dumps und mehrzeiligen Protokolle auf dem Benutzer sichern. Informationen werden entweder vom Benutzer wie im vorherigen Absatz benötigt, weil sie Informationen darüber enthalten, was genau schief gelaufen ist, oder sie werden nicht benötigt, wenn diese zusätzlichen Informationen nicht klar sind, weil sie nicht an ihn gerichtet sind.

Dem Benutzer müssen nicht hundert Nachrichten desselben Typs angezeigt werden: "Die Verbindung zum Gerät wurde unterbrochen", "Die Kommunikation mit dem Gerät wurde wiederhergestellt". Entscheiden Sie sich schließlich: Entweder handelt es sich um ein kritisches Problem, und Sie müssen es auf die richtige Weise melden - „Instabile Kommunikation mit dem Gerät“ - oder, da es sich als wiederhergestellt herausstellte, sind dies keine wichtigen Informationen und müssen nicht angezeigt werden ⁴ .

6.5. Für die Wartung sind keine besonderen Kenntnisse und Geräte erforderlich.

Geben Sie dem Benutzer die Möglichkeit, die Firmware zu aktualisieren. Lassen Sie sie einfach durch Drücken einiger Tasten aktualisieren. Dies erfolgt entweder über die Standardschnittstelle (USB / BT / Wi-Fi) oder wird in der Benutzerdokumentation zum Aktualisieren der Firmware mit dem SPI-Programmierer im Allgemeinen nicht erwähnt.

Sie können nicht verlangen, dass der Benutzer Bitmasken für eine Gerätekonfiguration berechnet, wenn diese Konfiguration bei normaler Verwendung erforderlich ist.

6.6. Das System sollte keine laufende Wartung erfordern.

Wenn einmal im Monat eine Verbindung zur Exekutiveinheit hergestellt wird und der Benutzer zum Kronleuchter klettern und ihn erneut binden muss, ist dies ein schlechtes System. Wenn der Schalter alle zwei Monate die Batterien wechseln muss, ist dies ein schlechtes System. Selbst die durchschnittliche Wartungszeit von sechs Monaten für jedes Gerät ist schlecht: Bei zwanzig Geräten im Haus muss der Benutzer durchschnittlich alle neun Tage einige Maßnahmen ergreifen.

6.7. Das System muss aktualisiert oder erweitert werden können.

Die Kosten für die Erweiterung des Systems sollten linear steigen. Ein neuer Block sollte die Kosten eines neuen Blocks kosten.

Es sollte keine Situation geben, in der Sie einen neuen Controller kaufen müssen, um einen neuen Sensor hinzuzufügen, da der alte nicht mehr als sechs Sensoren unterstützt ⁵ .

Es sollte keine Situation geben, in der eine neue Sensor-Firmware nur mit einer neuen Version der Steuereinheit funktionieren kann.

Solche Einschränkungen wirken sich positiv auf den Gewinn aus und zwingen Benutzer zum Kauf neuer Geräte. Dies ist jedoch der Weg zur Hölle. Wenn Sie aufgrund solcher Tricks das Vertrauen der Benutzer verlieren, verlieren Sie viel mehr, als Sie verdienen könnten.

7. Autarkie: Externe Netzwerke sind eine Option, keine Notwendigkeit.

Ein System, in dem Teams nur einen externen Server durchlaufen, ist ein schlechtes System. Sie können so oft Sie möchten mit praktischen Schnittstellen, trendigen Anwendungen und coolen neuronalen Netzen angeben, aber es spielt keine Rolle, ob der Benutzer die Möglichkeit verloren hat, das Licht in der Toilette zusammen mit dem Internet-Drop einzuschalten. Entwickler, finden Sie ein solches System wirklich gut?
Aber im Ernst, ich verstehe nicht wirklich, warum dieser Artikel nicht selbstverständlich ist. Indem Sie das System an einen externen Server binden, schaffen Sie einen Fehlerpunkt mit der Zuverlässigkeit eines normalen Servers, aber gleichzeitig für alle Ihre Benutzer. Externe Services sind cool. Sie ermöglichen es Ihnen, die Funktionalität zu erweitern, sollten jedoch nicht die einzige Option für die Betriebsverwaltung sein. Ein zusätzlicher Steuerkanal, Backup-Speicher, Datenanalyse - so viele wie Sie möchten.

8. Zentralisierung: Das Fehlen eines zentralen Hubs schränkt die verfügbare Logik ein.

Beeilen Sie sich jedoch nicht auf das andere Extrem - versuchen Sie, das System dezentral und damit absolut zuverlässig zu machen.

Ein dezentrales System ist, wenn der Schalter an der Glühbirne „Einschalten“ anzeigt und der Temperatursensor die Heizung einschaltet, wenn die Temperatur sinkt. Ein verteiltes System verliert zentralisiert, einfach weil ein solches System nur im Rahmen des einfachsten Paradigmas der Geräteinteraktion existiert - „das Gerät steuert ein anderes Gerät“. Mit zunehmender Komplexität des Systems wirft ein solches System mehr Fragen als Antworten auf. Wenn es mehrere Temperatursensoren gibt, sollte die Heizung dann Befehle von allen annehmen? Oder sollte er selbst die Sensoren abfragen? Und wenn Sie eine Entscheidung über die Aufnahme basierend auf dem Trend treffen müssen, wo werden die Archivdaten gespeichert? An jeder Heizung? Ist es nicht mutig? Auf jedem Gerät? Und mit jeder Anfrage den Verkehr steigern? Und wo speichern und wie die Logik ändern? Und wenn Logik externe Elemente enthält? Und wie speichert man Logik auf "dummen" Geräten? Und wie kann ich es aktualisieren?

All diese Probleme verschwinden, wenn Sie sich versöhnen und die Notwendigkeit eines zentralen Hubs als Interaktionspunkt zwischen Daten und Speicherorten für die Benutzerlogik erkennen. Lassen Sie alle Geräte „dumm“ sein, Daten senden und Befehle empfangen können, und die Aufgabe, Archivdaten zu speichern, diese Daten zu verarbeiten, Entscheidungen zu treffen und mit externen Diensten zu interagieren, liegt bei der sehr zentralen Steuerung.

Die Dezentralisierung kann übrigens beibehalten werden, wenn auch teilweise: Nichts hindert Sie daran, einen Befehl direkt zu senden, da es einen ausfallsicheren Modus gibt, wenn keine Antwort vom Hub vorliegt. Es wird keine Logik geben, aber es wird möglich sein, das Licht einzuschalten.

---

9. Das System sollte keine potenziell gefährlichen Aktionen ohne Bestätigung oder Benachrichtigung des Benutzers ausführen.

Solange wir nicht in einer Welt leben, in der der Programmierer für den durch sein Programm verursachten Schaden verantwortlich ist ( hier zu diesem Thema gut geschrieben), werden die Programme viele Fehler enthalten. Sie werden in der Software eines Smart Home sein. Die einzige Möglichkeit, bei der diese Fehler nicht zu katastrophalen Folgen führen, ist die Einschränkung der unabhängigen Aktionen des Systems. Potenziell gefährliche Handlungen sollten zumindest mit dem Wissen des Benutzers und vorzugsweise mit seiner Bestätigung durchgeführt werden. Sie können das Licht automatisch einschalten: Ein Fehler im Programm führt dazu, dass der Benutzer nachts aufwacht oder am Ende des Monats eine Rechnung über weitere hundert Rubel erhält. Unangenehm, aber kaum gefährlich. Zum Beispiel ist es unmöglich, Wasser automatisch einzuschalten, wenn keine Mechanismen garantiert sind, um es während einer Flut auszuschalten. Aber schalten Sie das Wasser aus - Sie können, weil dies keine gefährliche Handlung ist.

Dieses Prinzip besagt nicht, dass die automatische Steuerung aller Heizungen, Kessel, Öfen, Wasserkocher und dergleichen unbedingt verboten werden muss. Es geht vielmehr darum, dass, wenn Sie bereits ein potenziell gefährliches Gerät mit Programmsteuerung herstellen, sicherstellen, dass seine Gefahr nicht die Benutzerebene erreicht: Der gesteuerte Wasserkocher sollte über "Eisen" -Kreise verfügen, die ihn bei Überhitzung ausschalten. Das Bad, das von selbst gefüllt ist, muss über Flutungssensoren verfügen. Das Bügeleisen sollte sich ausschalten können, aber erst wieder einschalten, wenn Sie den "Bügeleisen" -Knopf drücken, und so weiter.

10. Das System sollte in der Lage sein, sich selbst zu kontrollieren und selbst zu diagnostizieren.

Ein echter Entwickler intelligenter Systeme sollte ein wenig paranoid sein. Sie können dem Internet nicht vertrauen, es kann verschwinden. Sie können dem Code nicht vertrauen, da er möglicherweise Fehler enthält. Vielleicht kann man zumindest der Hardware vertrauen? Nein. Sie können Ihrer Hardware nicht vertrauen. Das Relais kann stecken bleiben, Triacs öffnen sich spontan, Sicherungen gehen durch. Schließlich kann der Benutzer den Kilowattkessel an eine 100-Watt-Steckdose anschließen. Benötigen Sie Sensoren Spannung, Strom, Temperatur. Liegt die Temperatur außerhalb des Bereichs? Schalten Sie alles aus, senden Sie eine Warnung. Der Strom ist darüber hinausgegangen - schalten Sie ihn aus. Sie haben das Relais ausgeschaltet, aber liegt am Ausgang noch Spannung an? Hinweis. Eingeschaltet, aber keine Spannung? Beachten Sie!

11. Das System muss manuell gesteuert werden können.

Und trotz all dieser paranoiden Dinge wird es immer noch eine Situation geben, in der die Kontrollen fehlgeschlagen sind und etwas kaputt gegangen ist.Schalten Sie den Raum, den Router und den zentralen Hub ein. Und der Benutzer möchte das Licht in der Toilette einschalten. Was ist die Schlussfolgerung?

Es sollte immer eine Schaltfläche vorhanden sein, mit der "Sonnenuntergang die Sonne manuell einstellen" kann. Welches kann das Licht SOFORT ein- oder ausschalten. Da sie morgen einen neuen Hub bringen, können Sie etwas später einen Schalter kaufen und an diesem Abend das Licht im Raum ausschalten, um ruhig zu schlafen.

12. Entwickler und Hacker sind genauso wichtig wie normale Benutzer.

Normale Benutzer machen Sie zu Kassierern und Hackern ⁶ - kommen mit neuen Funktionen. Der Hersteller kann und sollte nicht alle Szenarien für die Verwendung des Systems entwickeln, da er offensichtlich nicht in allen Bereichen über Kenntnisse verfügt und die Auswirkungen der Entwicklung solcher Bereiche nicht bewerten kann. Es ist möglich, dass sich Ihre kontrollierte Steckdose als wahnsinnig bequem herausstellt, um den Thermostat des Mondscheins noch zu steuern, da sich in der Lösungsbibliothek ein PID-Regler befindet und jetzt alle Mondschneider Ihre Systeme massenhaft kaufen. Ein Beispiel ist etwas erfunden, aber die Hauptbotschaft ist, dass es sich auf Kosten einiger Anstrengungen lohnt, eine komfortable Umgebung für Hacker zu schaffen, da diese Ihrem System eine treibende Kraft verleihen.

13. Offenheit: Das System muss über eine API für die Integration mit anderen Systemen verfügen.

Sie können mit Ihren Geräten nicht alle Bedürfnisse Ihrer Kunden abdecken. Es wird immer Geräte geben, die Sie nicht haben, andere Hersteller jedoch. Oder Sie haben es, aber andere Hersteller sind besser. Oder Sie sind der Hersteller, dessen Einheit die beste ist. Eine offene und gut dokumentierte API ist erforderlich, um Ihr System mit anderen zu verbinden. Wenn Sie keine API haben, verweigern Sie Benutzern die Erstellung heterogener Systeme. Selbst Unternehmen, die sich am meisten für proprietäre Hard- und Software einsetzen, können sich das nicht leisten.

14. Dokumentation: Dokumentation ist ebenso wichtiger Bestandteil des Systems wie Code und Hardware.

Unabhängig davon, welche coole Hardware Sie haben und welche coole Software Sie schreiben, spielt es keine Rolle, ob der Benutzer nicht herausfindet, wie Sie Ihr System starten und wie Sie damit arbeiten. Eine gute Dokumentation ist eine Dokumentation, bei der der Benutzer nicht einmal daran denkt, den Support zu kontaktieren oder die mentalen Fähigkeiten des Entwicklers negativ zu bewerten. Das Schreiben einer solchen Dokumentation ist fast unmöglich, aber wir müssen uns darum bemühen.

Und schließlich das letzte Prinzip (aber in Bezug auf die Bedeutung weit vom letzten entfernt):

15. Autarkie und Selbstverträglichkeit: Das System sollte weiter funktionieren, auch wenn das Unternehmen nicht mehr funktioniert

Eine Person lebt 70-90 Jahre, das System in ihrem Haus ist (bestenfalls) 5-10 Jahre alt und Unternehmen sind oft kleiner. Du solltest kein System machen, die Fähigkeit zu arbeiten, mit der du mit ins Grab ziehst. Schade um die Benutzer. Entwerfen Sie das System so, dass es möglich ist, damit zu arbeiten, auch wenn das Unternehmen und die Entwickler längst in Vergessenheit geraten sind.

Kommt die Bindung eines neuen Geräts vor, wenn ein Token vom Server des Entwicklers empfangen wird? Klicken Sie auf die Schaltfläche "Empfangstoken überspringen". Müssen Sie beim ersten Einschalten des Systems die Firmware von der Site aus aktualisieren? Stellen Sie sicher, dass die Standard-Firmware überflutet wird, wenn die Site nicht verfügbar ist. Usw.

---

In diesem Artikel habe ich versucht, alle Erfahrungen mit der Verwendung, dem Arbeiten und dem Entwerfen solcher Systeme zu beschreiben, die in 15 Grundprinzipien zusammengefasst sind. Einige von ihnen scheinen weit hergeholt zu sein, andere mögen kontrovers sein (und das ist normal), und einige mögen banal sein (und das ist auch normal).

Wenn Sie jedoch an mindestens einen von ihnen denken, bedeutet dies, dass der Artikel nicht umsonst geschrieben wurde.

Fußnoten und Kommentare

1. Wenn ich "Verwenden" sage, meine ich nicht den Konfigurationsprozess, sondern den Prozess der normalen Interaktion mit dem System.
2. Bitte beachten Sie, dass ich nicht sage, dass die Verzögerung gleich sein sollte, sondern dass der Benutzer dies nicht bemerken sollte. Die Praxis zeigt, dass eine Person keine Verzögerung von bis zu etwa 300 ms bemerkt.
3. Vielleicht ist er in Zentralasien aufgewachsen und glaubt, dass heißes grüner Tee das beste Mittel gegen Hitze ist.
4. Wenn ich sage, dass keine Informationen angezeigt werden müssen, bedeutet dies natürlich, dass Sie dem Benutzer nicht jedes Mal eine Nachricht darüber senden sollten. Es sollte auf Anfrage des Benutzers angezeigt werden - durch Klicken auf die Schaltflächen "Protokolle anzeigen" oder "Debugging-Informationen anzeigen". Benutzer sollten nicht als Idioten betrachtet werden, aber ihre Zeit muss respektiert werden.
5. Natürlich ist es unmöglich, ein System zu entwerfen, das unendlich viele Geräte unterstützt. Es wird immer Einschränkungen geben, aber die Aufgabe des Entwicklers ist es sicherzustellen, dass sie in 99% der Fälle keine Rolle spielen. Eine Begrenzung auf sechs Sensoren ist nicht akzeptabel. Einhundertzweihundert Geräte in einem Netzwerk sind für die meisten Benutzer von Smart Homes ausreichend.
6. Ich spreche von Hackern im ursprünglichen Sinne des Wortes gemäß RFC1983 und nicht von Hackern.