Wie ermöglichen wir das Zusammenspiel zwischen allen F&E-Geräten, ohne Konfiguration oder Server (N:N dezentralisiert)? Das war die Frage, die Alex mir Anfang September stellte. Und meine Antwort war das F&E-JSON-Framework. Es ist ein sehr einfaches Protokoll, das darauf ausgelegt ist, sofort Spaß zu ermöglichen.

Es funktioniert heute für unsere Anwendungsfälle, aber wir müssen sicherstellen, dass es auch für die Geräte unserer Community funktioniert. Jetzt ist also Ihre Chance für Input! Helfen Sie mir, dieses Framework so zu gestalten, dass es auch Ihren Bedürfnissen entspricht.

Vorschlag

Das F&E-Kommunikationsprotokoll ist eine Reihe von Benutzererfahrungen und Standards zur Aufrechterhaltung dieser Erfahrungen.

Diese Regeln müssen für alle F&E-integrierten Geräte und Apps gelten.

Erfahrungen

1. Wenn ein Benutzer 2 bis 20 F&E-Geräte/Apps in physischer Nähe einschaltet, müssen alle sofort ohne Konfiguration etwas Spaßiges tun.
2. Wenn eine Wi-Fi-Verbindung aktiviert ist, muss das Gerät auch von der F&E-App aus überall auf der Welt steuerbar sein.

Standards

1. Kompatible Geräte müssen EspNow-fähig sein.
2. Wi-Fi ist streng optional.
3. Alle Geräte kommunizieren ständig über EspNow.
4. Alle Geräte können gleichzeitig über einen privaten Websocket kommunizieren, der dem Profil des Benutzers zugeordnet ist.
5. Jedes Gerät sendet (auf Kanal ff:ff:ff:ff:ff:ff) seinen eigenen Status mit F&E-JSON.
6. Jedes Gerät lauscht auf alle Sendungen.
7. Listener-Funktionen dürfen niemals eine andere Sendung auslösen. (Beispiel: Ich habe "failure" erhalten, also sende ich "failure", also senden sie "failure", also ich...)
8. Jedes Gerät steuert jedoch seinen eigenen Status und kann diese generischen Sendungen ignorieren oder darauf reagieren.
9. Broadcast-Ereignisse müssen zwischen 4-30 Mal pro Sekunde auftreten.
10. Die Listener-Funktion muss bei jeder Schleife aufgerufen werden.

F&E-JSON

Diese Struktur befindet sich in Entwicklung.
Aber hier sind die Regeln, die sie bisher regeln:

1. Alle Datenpakete haben die gleiche Struktur. - Frühes Beispiel unten.
2. Ereignisnamen sind standardisiert und identisch auf allen Geräten: "start", "data", "fail", "succeed" usw.
3. Alle im Datenpaket enthaltenen Werte sind dreidimensionale Vektoren, skaliert auf Ganzzahlen von 0 bis 100.
4. Alle Datenpakete müssen den Gerätetyp aus einem gemeinsamen, universellen Enum enthalten - "DTT", "OSSM" usw.
5. Alle Datenpakete müssen die MAC-Adresse oder einen anderen eindeutigen Identifikator für das Gerät enthalten.
6. Die Daten müssen den aktuellen "Modus" für die Kommunikation enthalten. Derzeit kann dies "play" oder "control" sein.
7. Wenn "control" definiert ist, muss ein einzelnes Ziel per ID angegeben werden. Wenn mehrere erforderlich sind, sind mehrere Nachrichten erforderlich.

Beispiele

// Beispiel-Broadcast von einem DTT an alle nahegelegenen Geräte.
{
  "id": "40:CD:E7:90:F4:0C",
  "device": "DTT",
  "mode": "play",
  "target": "",
  "event": "data",
  "value": [23, 0, 0],
  "position": [0, 0, 100],
  "velocity": [0, 0, 0]
},

// Beispiel-Broadcast von einem webbasierten Controller an ein bestimmtes Gerät.
{
  "id": "19:53:E0:4D:6A:8B",
  "device": "WEB",
  "mode": "control",
  "target": "04:E7:68:F8:85:8B",
  "event": "data",
  "value": [0, 100, 50],
  "position": [0, 0, 0],
  "velocity": [0, 0, 0]
}

Was denken Sie?

Jedes Gerät, das diese Protokolle befolgt, wird offiziell als F&E-kompatibel betrachtet. Aber, noch wichtiger, diese Designs sind hackbar! Das bedeutet, dass jedes kreative Projekt, das diese Kommunikationsregeln verwendet, mit unseren Geräten integriert oder diese steuern kann (keine Sorge, wir haben Sicherheit für webbasierte Controller installiert).

Aber, funktioniert es für Sie? Werden Sie Ihre Geräte integrieren können?

Klicken Sie hier, um mir eine E-Mail zu senden! Ich möchte Ihre Meinung hören. AJ@ResearchAndDesire.com

Hinweise:

Wir erwägen auch:

• das ButtPlug.io-Framework https://buttplug-spec.docs.buttplug.io/docs/dev-guide/intro/introduction
• xToys