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“
Schau Dir die oben verlinkte inoffizielle API an, darauf basieren alle anderen Diettanbindungen (ioBroker, Node-RED, homebridge, Home Assistant). @stfnhmplr ist auch auf unserem Slack Channel , PN mit Mail und ich lade Dich ein.
Hat jemand odig/homeeToMqtt auf einer Synology zum Laufen gebracht und kann mir Infos dazu geben? Ich habe bisher Netatmo & eBUS Bridges im Einsatz und würde sehr gerne auch den Homee damit an MQTT anbinden.
Danke. Sehe gerade, dass ich da auch bereits gefragt habe. Der Thread bezieht sich aber auch auf das gleiche Repository. Die Entwicklung scheint 2018 geendet zu haben. Leider habe ich davon zu wenig Ahnung. Daten beim MQTT Broker per PHP lesen und schreiben bekomme ich noch hin, aber das ganze auf einer Synology zu installieren ohne bisher mit Node Red gearbeitet zu haben, dürfte für mich schwierig werden.
ich arbeite an der homee Integration für Homeassistant und bin auf der Suche nach der inoffiziellen API Doku - leider kann ich hier im Thread den Link nicht finden…
Danke.
ich bin auf der Suche nach einer Methode, um für ein Attribut den aktuellen Wert abzufragen.
Das einzige, was ich in der API dazu finde wäre die History - aber das ist eigentlich mehr als ich will.
Kennt jemand eine einfache Möglichkeit nur den lezten Wert zu bekommen?
1 „Gefällt mir“