Rest API für Devices

Hallo,

laut Dokumentation besteht nur die Möglichkeit, Geräte mit M-Bus, Modbus oder Onewire mit Edge zu verbinden. Die allermeisten schaltbaren Steckdosen nutzen aber die Rest API über http.

Gibt es die Möglichkeit in OpenEMS auch eine Rest API zu nutzen? Falls nein, ist das grundsätzlich möglich?

Viele Grüße
Christian

Hallo,

aktuell nicht, wir selbst arbeiten gerade daran mittels Rest, 2 OpenEms geräte zu verbinden.

Allerdings ist “Die Rest-Api” nicht eindeutig, da dies jeder Hersteller selbst definieren kann. Kannst du dies genauer definieren?
Im Prinzip ist es openSource und die Community würde sich freuen, wenn eine Rest-Api integriert wird. Und grundsätzlich möglich ist quasi, alles, was man programmiert.

Schönen Gruß

Paul

Hallo,

das ist ja eine ziemlich gute Nachricht. Ich hatte befürchtet, dass die Rest-Api evtl. zu langsam ist.
Konkret dachte ich an eine Implementation einer Smart-Steckdose Edimax SP2101W nach der angehängten Schnittstellendefinition https://github.com/camueller/SmartApplianceEnabler/blob/master/doc/EdimaxSP2101W_DE.md
und einer Ladestation von go-e https://go-e.co/app/api.pdf.

Eigentlich sollte ein REST Schnittstelle allgemein gültig sein, aber so genau habe ich die verschiedenen Geräte noch nicht im Detail betrachtet und habe Wikipedia vertraut https://de.wikipedia.org/wiki/Representational_State_Transfer
Ich dachte mittelfristig an eine Bride-Definition, sodass alle vorhandenen Natures (z.B. I/O, Meter, EVCS) genutzt werden können.

Aller Anfang ist schwer, in Java hatte ich bisher nicht programmiert sondern im ähnlichen C#.
Habt ihr vielleicht ein paar Code-Zeilen für den Start? Würde mir sehr weiterhelfen.

Viele Grüße
Christian

@Christian: es sind bisher ein paar wenige Geräte über REST-Schnittstellen angebunden. Es sind einfach deshalb so wenige, weil das HTTP-Protokolle in dem Bereich (noch) nicht so verbreitet sind. Wie Paul schon angedeutet hat, ist es schwierig, REST so zu vereinheitlichen, dass eine Bridge sinnvoll wäre; deshalb wurde das bisher immer individuell implementiert. Beispiele:

@p.wimmer: Den Ansatz finde ich interessant. Ich denke auch darüber nach, wie wir “OpenEMS Edge” mehrstufig über mehrere Level machen können. Ich würde sowas eher wieder über Websockets lösen um den Overhead zum Verbindungsaufbau einzusparen. Wenn man sowas ordentlich designet, könnte es langfristig OpenEMS Backend komplett ersetzen. Kannst du vielleicht euren Ansatz mal hier ins Forum stellen (als neuen “Proposal”-Thread), damit wir verschiedene Ideen und Use-Cases sammeln können?

Gruß,
Stefan

Hallo Stefan,

vielen Dank für die Links, das hilft mir ziemlich weiter.

Zur Sache mit der Rest-Bridge wäre auch eine 80% Lösung hilfreich, viele kleine und günstige Hausautomatisierungen haben hat leider keinen Modbus oder M-Bus. Die einzige schaltbare Steckdose mit Leistungsmessung und Modbus die ich gefunden habe, kostet mehr wie 100€ im Vergleich zu der SP2101W mit knapp 40€.

Vielleicht nochmal zurück zu meiner eigentlichen Intention, für alle die das auch interessant finden. Ich möchte die Energie der Photovoltaikanlage bestmöglichst ausnutzen und nur das Elektrofahrzeug solange laden, wie es die aktuelle Energiezustand (PV-Anlage + Speicher) zulässt mit Randbedingung einer notwendigen Mindestreichweite (normalerweise bis zu meiner Arbeitsstelle).
Natürlich könnte ich auch die Keba Ladestation verwenden, die bereits unterstützt wird, aber das wäre ja langweilig :wink:. Außerdem ist die Ladestation von e-go 400€ günstiger, was die Sache ja auch wieder finanziell interessant macht.
Die Steckdose möchte ich nutzen, um im Sommer die überschüssige Energie (und nur die!) in eine Klimaanlage zu stecken.

Gruß
Christian

Hallo Christian,

Prinzipiell sehen beide Apis nicht sehr schwierig aus. Ist eben ein bisschen Arbeit hierfür einen eigenen Controller zu bauen.

Allgemeingültig ist bei diesen beiden Beispielen schon nicht einfach :wink:
Der eine hat ein XML Format, der andere Json.

Kurze Anmerkung zu “nicht schnell genug”. Ladesäulen bzw. E-Autos mögen es nicht, schneller als alle 45 Sekunden gesteuert zu werden. Auch haben die Autos eine gewisse Tolleranzzeit um zu reagieren (Sekundenbereich). Also ist meiner Meinung nach ein schnelleres Regeln als knapp 1 Minute bei Autos nicht zielführend. Bei Klimaanlagen, Wärmepumpen und Kühlschränken ist dies noch “krasser”. Hier sitzt im Hintergrund ein Hydraulisches System. Hoch und runterregeln (Temperatur) ist wenig problematisch. Allerdings das “harte” wegschalten des Stroms sollte vermieden werden und die Laufzeiten sollten über 15 Minuten sein (Zahl bauchgefühl, aber gerne bei Herstellern nachfragen und hier die Erfahrung teilen).
Schönen Gruß

Paul

Hallo Paul,

berechtigter Hinweis zu den Schaltzeiten der Geräte. Ich komme aus einem Bereich mit hohen Schaltzeiten im µs-Bereich, diese sind für Ladesäulen und Pumpensysteme natürlich absolut ungeeignet. Meine Frage zielte eher in Richtung der Kommunikation zwischen Server und den Devices und nicht dass ich die Devices so schnell schalten wollte.

Die Umsetzung der API war für mich doch viel schwerer wie gedacht, denn die Steckdose brauchte ein individuelles Passwort welches man nur bei der ersten Installation auslesen kann und zudem eine Digest Authentifizierung, welches nur mit dem Modul Jetty möglich war.

Nun gut, immerhin die Schnittstelle funktioniert grundsätzlich was dem Status auslesen betrifft. Ich kann die Steckdose als Output anlegen und im Channel den Status (on/off) anzeigen lassen und auch die Variable ActivePower ist auswählbar.
Leider tut sich beim Setzen eines anderen Wertes leider gar nichts. Es wird zwar erfolgreich angezeigt, aber der Befehl zum Umschalten wird nicht getriggert.

Ich vermute, dass der Wert nicht richtig in der Funktion executeWrite ankommt, writeValue wird nicht gesetzt.

private void executeWrite(BooleanWriteChannel channel, int index) throws OpenemsNamedException {
Boolean readValue = channel.value().get();
Optional writeValue = channel.getNextWriteValueAndReset();
if (!writeValue.isPresent()) {
// no write value
return;
}
if (Objects.equals(readValue, writeValue.get())) {
// read value = write value
return;
}

  this.edimax2101W_V2_api.setRelayTurn(writeValue.get());

}

Wie kann die Variable ActivePower mit der GUI verknüpft werden?

Wenn die Funktionen laufen, wie kann ich ein neues Device zur Verfügung stellen? Über github?

Viele Grüße
Christian

Hallo,

habe den Fehler des Schaltens gefunden, Unterstriche “_” in den Namen waren die Ursache. Nun kann ich Problemlos die Steckdose über die GUI schalten.

Viele Grüße
Christian

Hallo Christian,

super, dass es geklappt hat. Leider ist die “Contribution Guideline” noch nicht dokumentiert… der nächste Schritt wäre, jetzt auf GitHub einen Pull-Request zu erstellen, den wir dann “reviewen” und am Ende “mergen” würden.

Gruß,
Stefan

Hallo Stefan,

es hat tatsächlich nun doch geklappt, auch die Variablen in der GUI anzeigen zu können. Die Funktion setnextvalue() war es.
Programmcode habe ich gerade per Pull-Request hochgeladen.

Viele Grüße
Christian

Super - vielen Dank. Hier für die anderen Mitleser noch der Link zum Pull-Request:

Leider läuft der Build aktuell noch nicht durch. Arbeitest du noch daran weiter?

Die setNextValue()-Funktion ist leider am Anfang schwer zu durchschauen, das verstehe ich. Die Notwendigkeit ergibt sich aus dem ProcessImage, das wir verwenden um die nebenläufigkeit in den Griff zu bekommen - ähnlich wie bei einer SPS-Steuerung. Wir arbeiten schrittweise die Nature-Interfaces so um, dass dieser Aufruf “versteckt” wird, damit man die Internas von OpenEMS nicht mehr verstehen muss, um damit zu arbeiten. Siehe hier: https://github.com/OpenEMS/openems/issues/1046#issuecomment-624875470

Das Lob gebe ich aber auch gerne wieder an die Community zurück. Schon toll was ihr da aufgestellt habt :clap:

In Github habe gerade nach mehreren Versuchen eine lauffähige Version hinbekommen. Komischerweise hatte ich in Eclipse keinerlei Fehler, während in Github ein Fehler kam. Das hat die Fehlerbeseitigung doch sehr erschwert.