Ich hab diese Dinger programmiert. Das geht. Deine Annahme ist falsch.
Die nicht trägt weil sie die Zukunft nicht abbilden kann (weil unbekannt)
Kleines Beispiel: hättest du das vor einem Jahr definiert hättest du §14a und die einzelnen Module nicht abbilden können weil sie zu dem Zeitpunkt nicht bekannt waren
Ja. Deswegen ist Json auch ein generisches Format für Daten. Das ist analog zu Buchstaben.
Ihr redet hier über ein Json Schema. Auch wenn das nicht so bezeichnet wird. Und Schemas sind spezifisch
Das Schema besteht im wesentlichen aus Wörtern, Zahlen und Formeln. Das ist aus meiner Sicht ausreichend generisch für alles, was der Mensch berechnen kann.
Wenn man eine neue Schnittstelle einrichtet, schaut man sich die Beschreibung an, macht ein mapping und testet dann anhand von Beispielen, ob die Ergebnisse stimmen. Die Idee ist, die Beschreibung und die Testfälle auch im JSON Format mit den Daten mitzugeben, so das der Computer einen großen Teil des Einrichtungsaufwand übernehmen kann.
Im "Header" werden zum Beispiel die Einheiten mit einem Link auf die wikipedia Beschreibung mitgegeben. Wenn dann eine neue Einheit hinzu kommt, kann der Computer eine für Menschen gut lesbare Meldung ausgeben und in der Regel gerade einen Lösungsvorschlag anbieten.
Wenn zum Beispiel der Preis in Rappen pro kWh übermittelt wird, kann der Computer selbständig den Wechselkurs nachschlagen und ohne menschliche Intervention den Preis in Umrechnen.
Mikro-CPU ... Das geht
Ja, ich denke auch, das inzwischen auch "kleine" Computer das etwas erweiterte JSON ohne wesentlichen Zeitverlust verarbeiten können. Und die Header Informationen müssen ja nicht jedes mal, übermittelt werden, sondern nur am Anfang der Übertragung.
Der schaltenden Steckdose sind die Beschreibungen und das drumrum vollkommen egal. Die kennt kein 14a, die hat nur 1 Relais.
Stell dir vor, du hast 3kB RAM, 2kB EPROM, 16kB ROM. 8051 code 16MHz. Kostet 7 cent, der Preis machts zu einem brauchbarn Kandidaten: HT66F2372
Der kann noch paar LED und 1 kleines 2stelliges numerisches LCD und 2-3 knöpfe. Dami wählt man aus, wie viele Stunden der Boiler an ist oder der Tiefkühler aus.
Damit sowas um 5€ im Laden liegt, darfs 2,50 in der Herstellung kosten. Das ist dann das killer device für fixe Stromtarife.
Der beabsichtigte Nebeneffekt ist, daß die Verteilnetze entlastett werden können, wenn man z.B alle 15 Minuten eine Kommunikation aufbaut. Da hieße aber, auf Versorgerseite müssen nennenswerte Datenmengen ins Netz geschaufelt werden, wenn z.B. in jedem Haushalt durchschnittlich 3 von den dingern hängen.
Jou das ist billig. Frag damit mal die API ab.
Wobei du hast ja bei deinem Design Wifi vergessen. Also Hardware. Und dann brauchst du einen Netzwerk Stack in Software. Bring den mal auf diesen Chip 
Und eine Möglichkeit das irgendwie zu konfigurieren.
Ohne das alles kommst du gar nicht an deine API ran.
Ich bin hier raus. Ohne böse klingen zu wollen würde ich dir raten sowas mal selbst zu bauen. Das hilft das nötige Verständnis zu entwickeln was da alles dran hängt.
?? Ich erinnere mich an einen tcp stack der ca. 4k gross war. nur leider find ich den nicht wieder, es gibt einfach zu viel "Kunde web51" 
Die Tuya dinger gibts schon für 2.80 im laden. Die ZigBee ansteuerung per WiFi über tasmota hub ist recht einfach. Tasmota kann gescripted werden und könnte auch dynamische stromtarife abfragen.
Zeig! Beim Chinesen knapp 10€ und hier noch nie im Geschäft gesehn.
Und du kannst das lokal steuern und eigene soft draufspielen?
Ne JSON-API finde ich hier schon das geeignete Mittel. Vor allem weil es ermöglicht, Schnittstellen abwärtskompatibel zu verwalten. Wenn neue Informationen eingefügt werden sollen, kann man das tun. Ein sauber programmierter Mapper in veralteter Software ignoriert die dann einfach.
Natürlich bringt so ein Format ein gewisses Overhead mit sich. Aber es hat schon einen Grund, warum so gut wie jede API auf JSON oder XML setzt (letzteres hat noch mehr Overhead). Solange da jetzt nicht dutzende Kilobytes an Daten pro Request durch die Leitung gehen, sehe ich da keinen Grund auf Binärformat zu setzen, wo man alte APIs sehr lange unterstützen müsste. Das Ganze muss ja bundeseinheitlich funktionieren und ich will den WR nicht nach 10 Jahren wegschmeißen weil Format nicht mehr unterstützt und Hersteller pleite/kein Bock auf Patch/Weiterentwicklung.
Meinst du mich? Hier, must aber zigbee nehmen, ist einfacher als wifi. Bei wifi brauchts keinen hub, musst aber PC mit python haben und tuya dev account und das auch verstehen.
Dazu noch den hub, hab gleich den mit tasmota gekauft, kannst aber den $9 nehmen und selber flashen
Dann kannst du "permit join" und die sensoren / aktuatoren verbinden:
Und dann mit "berry scripting" oder "tasmota rules" die geräte abfragen / steuern.
Kannst auch PIR, radar, dimmer, schalter und sowas anhängen.
Das hier (roter kreis) ist tasmota rule für PIR sensor:
Und ja, das läuft alles auf dem esp32 vom hub. Wenn du etwas wartest kannst du auch eine esp32-C6 oder esp32-H2 kaufen, die können zigbee ohne externen radio, da läuft dann (bald) tasmota-hub direkt auf dem entwicklungsboard.
Mit den Specs wirst du dir schwertun.
Du musst ja eine Verbindung mit dem Server aufbauen, die Response parsen (wenn die >2kB ist, bekommst du hier schon RAM-Probleme). Und dann kommt noch ein Algorithmus dazu, der jetzt schaut welche Stunden die günstigen sind.
Dann hast du das Problem, das die Steckdosen für Haushaltsgeräte gerne mal schlecht erreichbar sind. Um bei mir an die Waschmaschine zu kommen muss ich den Schrank vorziehen - die Streckdose ist dahinter. Und sonderlich benutzerfreudlich ist so ein Interface mit 2-3 Knöpfen auch nicht.
Das sollte schon über ein Webinterface gehen.
Vermutlich macht es darum mehr Sinn, die API in Heimautomationen einzubinden (wie @anon38.S mit Zigbee). Dann reicht auch eine "dumme" Steckdose, die lediglich auf ein Steuersignal reagiert.
Für ein standalone System braucht es dann vermutlich eher was in der ESP32-Klasse. Aber auch die sind nicht allzu teuer (unter 5€ - in der Masse vermutlich nochmals weniger).
#include <HTTPClient.h>
HTTPClient http;
http.begin(client, getstr)
#include <ArduinoJson.h>
StaticJsonDocument<2000> doc;
deserializeJson(doc, payload);
Das ist das problem bei json, Unglaubliche resourcenverschwendung.
Beim shelly3EM muss man eine halben roman abholen um an 3 power werte zu kommen.
OK. also noch mal.
@anon38.S diese Geschäfte gibts in meinem Dorf nicht.
Die Zwischenstecker müssen billig sein und sich in 1 Jahr auszahlen und von jedem dummie einzurichten sein.
Jetzt hats 2 Möglichkeiten:
Warum willst du denn sowas?
Das macht man über Phone oder PC. Die ZBBox hat einen webserver drin über den man alles steuert. Das geht alles über http.
Die $14 box kimmt übrigens voll CO2 kompensiert, da achte ich drauf 
naja es soll halt dummiegeeignet sein.
also telefon suchen brille suchen aufm telefon den browser starten das gerät aufrufen (und google findet das nicht mal!)... da fliegt des graffl in mull bevor die waschmaschine strom hat
Wenn ich dynamischen stromtarif hätte würde ich das automatisieren.
Um das gings ja eigentlich. Vergessen?
dann musst du bis 1 uhr morgens warten, dass du die tür der wama aufkriegst
