Wenn man Software entwickelt, die die Discovergy API nutzt, dann wäre es sehr hilfreich vorab zu wissen welche Zählertypen (Feld: ‚type‘ im /meters Endpoint) bislang verbaut wurden und welche Feldnamen diese Zähler zur Verfügung stellen (Endpunkt /field_names).
Die meisten Entwickler haben meist nur einen Zähler im Zugriff zum Testen. Wenn man dann Software entwickelt, wird das meist schon Fehler produzieren, die darauf basieren, dass man sich auf das Vorhandensein und die Benamung von Feldern verlässt, die es aber bei anderen Zählertypen so nicht gibt.
Aktuelles Beispiel: die OpenEMS Integration läuft bei meinem Zähler (EMH) vor den Poller, weil es z.B. das Feld „power1“ nicht gibt. Idealerweise verlinkt man entsprechende Tabellen in die API Dokumentation oder aber stellt Entwicklern Testzugänge zur Verfügung, unter denen man alle bislang verbauten Zähler abfragen kann (das wäre natürlich ein Traum).
Das Problem ist etwas komplexer. Ein Feldnamen hat immer die selbe Bedeutung, d.h. in eine Software kann man nicht einfach den Wert eines Feldnamen auf einen anderen mappen.
Aktuell sind etwa 40 verschiedene Arten von Zählern verbaut, die meist unterschiedliche Bedeutungen haben.Die API sieht daher vor, dass immer das angeboten wird, was von der Zähler (Hardware) geliefert wird und daher die Software sehr fein auf die unterschiedlichen Anwendungsszenarien zurechtgeschnitten werden kann.
Was die Verlinkung angeht in der Dokumentation der API, nehme ich diesen Vorschlag gerne auf - ich bin mir nur nicht sicher, ob es jemals eine wirklich vollständige Liste sein wird und ob es eine Art von Dokumentation gibt, die auch die Verwendung (zum Beispiel bei Messung der Blindleistung, oder bei den unterschiedlichen Wärmemengenzählungen, die ohne detalierte Hintergründe zum jeweiligen Zähler auskommt).
Komplett nachvollziehbar. Das macht nur die Entwicklung von Software, die die Discovergy API nutzt, sehr schwer, weil niemand weiss welche Werte unter welchem Namen die API dann wirklich liefert.
Gibt es kein semantisches Modell, unter der man Bereitstellung von Informationen besser abrufbar machen kann? Ich dachte da an die Verschlüsselung mit OBIS-Kennzahlen.
Alternativ wäre ein Testfeld mit zumindest den 5 bis 10 meistverbauten Zählerntypen toll, wo man sich als Entwickler mit einem Zugang auf die API verbinden und learning by doing seine Software anpassen kann.
Das semantische Modell ist zum Teil gegeben, da bei Wärme/Gas Zähler auch eine OBIS Gruppe existiert. Jedoch zeigt die Praxis (Mails zum Beispiel an api@disovergy.com), dass OBIS Codes eher für Verwirrung sorgt als für Klarheit.
Die Sache mit dem Testfeld haben wir tatsächlich bereits implementiert. Wer sich zum Beispiel an die api@discovergy.com Mail wendet und eine bestimmte Auswahl an Zähler benötigt, der bekommt sein eigenes Testfeld eingerichtet (Hintergrund: Das API Limit, dass es keine parallele Abrufe von einem Account geben darf, macht einen „Demo Account“ eigentlich nicht nutzbar).
Hinsichtlich der Dokumentation gehen wir etwas den 80/20 Ansatz, so ist das Feld „energy“ bei allen Stromzählern vorhanden, auch wenn RLM Zähler dieses als 1.8.0 (Wirkleistung Bezug) kennen.