@hblaschka schick mir mal via PN die Adresse wo der homee hin muss, dann kümmer ich mich.
9 „Gefällt mir“
dauert nen moment, ich klaer es via github ab…
2 „Gefällt mir“
… jetzt wird’s immer besser!!!
2 „Gefällt mir“
3 „Gefällt mir“
Gibts hier eigentlich was Neues seitens Entwickler. Das Feature ist nun seit über 2 Jahren auf “geplant”. Eine REST API mit JSON wäre ein Traum.
Ich habe aktuell einen Anwendungsfall, den ich sonst nicht lösen kann. Ich möchte die Ist-Temperatur von einem Heizungsthermostat mittels Webservice abgreifen und auf einen LaMetric Time pushen, damit dieser den Wert anzeigt. Alternative wäre extra einen Temperatursensor dafür zu kaufen, was ich aber nicht unbedingt wollte, da ja jedes Heizungsthermostat in jedem Raum die Werte hat, die ich haben will.
1 „Gefällt mir“
Wenn Du Dir selber was bauen willst, dann kannst Du die homee API von @stfnhmplr als Basis benutzen - die benutzt er selbst für seine Lösungen (HomeKit, Node-RED) und wird auch vom ioBroker-Dev eingesetzt.
Alles weitere hier:
3 „Gefällt mir“
Hallo,
das nutze ich bereits. Aber ich fände es eleganter, wenn das direkt ginge ohne einen Docker/Raspi mit Node-Red.
Was genau erwartest du denn? Kannst du das ein wenig genauer beschreiben?
In erster Linie möchte ich gern sämtliche Werte der Geräte (Temperatur, Feuchtigkeit, Batterieladung usw.) auslesen können. Diese kann man dann in externen Anwendungen verwenden. Z.B. ein eigenes Monitoring oder auch auf anderen Displays wie z.B. LaMetric.
@homee Ich wuerde gern noch einige Wuensche zum Thema API Design aeussern.
Wie vielleicht bekannt, arbeite ich recht viel mit der nicht offiziellen API, die auch fuer das Web Interface verwendet wird.
Ich arbeite vornehmlich mit stark getypten Sprachen wie Kotlin, Java und C#, daher ist der aktuelle Shape der Messages, welche ueber das Socket vom Brain Cube aus versendet werden fuer mich echt unpraktisch.
Mein Feedback mag ich in drei Teile splitten:
Envelope
Beim Transfer von allen Nachrichtentypen ueber ein und den selben Draht, wie es beim Websocket oder auch TCP der Fall ist, kommt es immer wieder zum Problem, dass man Nachrichtentypen auseinanderhalten muss. Ich mache das aktuell mit einer Prefix Search, was ziemlich hampelig und wackelig ist. Fuer eine offizielle API wuerde ich mir ein Envelope Format wuenschen, welches einen fixen Teil der Nachricht beinhaltet. Dieser Envelope sollte nach meiner Ansicht enthalten
- Message Type (Attribute, Node, All, User, etc)
- Sender Timestamp
- Sender Backreference (Impliziert die Moeglichkeit beim Senden einer Message eine Reference mitzugeben, auf die sich diese Antwort bezieht)
- Einen Message Signatur (evtl. via Pub/Priv Key signing oder Aehnliches zur Verhinderung von Spoofing. Wir sprechen hier immerhin ueber potentiell sicherheitsrelevante Aktionen)
- Message Payload, also die eigentliche Nachricht
All das macht natuerlich die Message groesser und stellt neue Herausforderungen dar.
Wire Format
JSON ist klasse, gut zu lesen und kann von jeder mir bekanntne Sprache verarbeitet werden. Leider ist es ebenso ineffizient und verbose. Ich bitte euch, dass ihr euch Alternativen anschaut. Aus beruflicher und persoennlicher Erfahrung mag ich euch Protobuf ans Herz legen. Kompakt, gute forward und backward compatibility Moeglichkeiten, fuer fast jede Sprache verfuegbar (C/C++ fuer Embedded, JS, Java, Node, C#, etc etc) und o.g. Enveloping laesst sich damit Klasse umsetzen (Die Envelope Message traegt dann einen Bytestring, den man dann separat parsen kann).
Allgemein
Das Thema Sicherheit wuerde ich gern noch ansprechen. Mir ist klar, dass die aktuelle API nie fuer die Oeffentlichkeit bestimmt war und deswegen nicht der Massstab sein sollte. Ich mag hier einfach sagen, dass ich mir fuer eine richtige Public API ein anderes Authentication und Authorization verfahren wuensche, entweder per z. B. Signatur, Zertifikat oder bewaehrtem Standard wie OAuth2.
8 „Gefällt mir“
Dieses Thema ist zwar inzwischen mehr als 4 Jahre alt und der letzte Kommentar 2 Jahre her, aber ich möchte als homee-Neuling hier unbedingt starkes Interesse bekunden. Eine ordentliche API wäre wirklich großartig und würde so manches erleichtern. Da ich selbst Entwickler bin habe ich natürlich schon ein gutes Dutzend Anwendungsfälle für so eine API im Kopf. 
Wie bereits erwähnt ist das Thema schon sehr alt. Gibt es dazu neue Erkenntnisse? Wurde vielleicht in einem anderen Thread darüber diskutiert, den ich nicht gefunden habe?
Offiziell gibt es nichts. Da zieren sich die homee-Kollegen etwas.
Inoffiziell hat sich mit vhih einiges getan.
Siehe hier:
1 „Gefällt mir“
Das werde ich mir mal in Ruhe zu Gemüte führen. Danke für den Tipp.
Aber eine offizielle API wäre schon toll 
Auch nicht offiziell, basiert Aber auf der internen Doku und wurde vom selben DEV als Basis für die Node-RED und HomeKit-Plugins benutzt. Dazu basiert auch die ioBroker-Schnittstelle darauf. Die Devs kennen das und Supporten es (indirekt). Da kannst Du drauf aufbauen, und wenn Du mit Python klarkommst: Wie brauchen noch eine direkte Schnittstelle Richtung Home Assistant
Die API sollte relativ stabil sein, denn hih basiert da ja auch drauf…
2 „Gefällt mir“
Oh yes!!
1 „Gefällt mir“
Dringend - Dann hätte der homee bei mir eine Chance längerfristig bleiben zu dürfen…
Weil du dann damit genau was umsetzen kannst?
3 „Gefällt mir“
Hi Chris,
ich denke die API wäre vor allem gut um sich ein eigenes Dashboard zu bauen. Aber natürlich könnten ggf. komplexe Szenarien, welche sich aktuell nur mit vielen Homeegrammen (oder auch nicht ;-)) realisieren lassen einfacher erstellen, zumindest für Leute mit entsprechendem Wissen. Ich bin selbst Entwickler (.Net), wollte aber eben keine Bastellösung, sondern etwas fertiges, mit welchem ich die meisten Szenarien relativ einfach abdecken kann, hierfür ist homee aus meiner Sicht sehr gelungen. Ist halt auch eine strategische Frage, so eine API macht einen großen Aufwand (Pflege, Dokumentation, Kombatibilität) und kann zur Last werden bei eventuell größeren Änderungen da es dann kein in sich geschlossenes System mehr darstellt, ich bin der Meinung die Kraft ist besser investiert in Punkte, welche die Usability für Menschen ohne Programmierwissen steigert, hier ist die Zielgruppe wesentlich größer und Bastellösungen gibt es eh schon genug!
Viele Grüße
Gerd
1 „Gefällt mir“
ganz genau und das ist der interne Punkt der uns immer wieder zur Diskussion führt.
Aber wir haben das Thema auf dem Schirm, da es uns stetig mit externen Partnern tangiert.
6 „Gefällt mir“