Bisher gibt es keine veröffentlichen Schnittstellen zu homee, mit denen Entwickler bspw. eigene Apps entwickeln können. Wenn es diese APIs geben würde, könnten auch andere Entwickler Apps für Windows 10 oder andere Plattformen schreiben.
Eine offene API wäre klasse. Würde mir direkt eine Art Dashboard schreiben und auf dem Tablet im Eingangsbereich aufhängen. Dann wüßte ich auf einen Blick, ob noch irgendwo Fenster offen sind wenn ich das Haus verlasse oder ob sonst noch eine Aktion erforderlich ist.
Like!
9 „Gefällt mir“
Dieser Feature Vorschlag ist mir gar noch nicht aufgefallen… Ein klares “like” von meiner Seite. Denn je offener ein System ist, desto mehr kann die Community oder auch eine Partnerfirma tun um Homee weiterzubringen. Ebenfalls interessant wären Möglichkeiten einfache Scripts (wie LUA bei Fibaro) zu integrieren.
Das von @danielkagemann angesprochene Dashboard klingt auf jeden Fall schon mal interessant 
1 „Gefällt mir“
Wenn es soweit ist, kannst Du mir gleich eins mitprogrammieren 
1 „Gefällt mir“
Eine API faend ich ebenfalls klasse. Interessant ist, ob man das dann wirklich als HTTP API machen moechte, oder ob es her in Richtung Event Sourcing geht. Ich wuerde mir z. B. den kompletten Event Stream gern in eine Kafka Topic werfen und dann mit Stream Processors darauf arbeiten. Damit kann ich dann immer noch mit einen Materialized View bauen, damit ich ein Dashboard darauf setzen kann. Ein Traum waeren protobuf messages auf einem TCP socket oder gRPC in der Variante Server Stream (vgl. http://www.grpc.io/docs/guides/concepts.html).
Aber auch MQTT waere ein echter Gewinn. Hier kann man dann mal ueber z. B. eine Anbindung an Amazon’s IOT Platform nachdenken.
Ein Event Stream (ob nun ueber Websockets oder sonst wie realisiert) laesst dem Konsumenten die Chance auf die Events im Homee System zu reagieren. Bei ner HTTP API pollt man sich wieder den Server zu Tode. HTTP ist nett fuer einen “Snapshot” des Zustands, aber nicht fuer ein Zeit-basiertes System, welches beim Abruf der API nichts anderes tun kann, als zu diesem Zeitpunkt schon veraltete Daten auszuliefern 
Liebes Homee Team,
kann man eigentlich dit Websocket anzapfen, welchen Ihr fuer die Angular UI benutzt? Der Token, den ihr da im Header muss ja irgendwie herstellbar sein.
Ich verzweifle grade an der ganzen API Geschichte. Ich versuch grad schon einen zweiten Controller (nicht als SUC/SIS) ins Netz zu haengen und den als passive MQTT bridge zu benutzen. Langsam faellt mir nix mehr ein. Wenn von euch keine Indikation kommt, dass ihr API - technisch was plant, dann werd mal nen zweites Netz mit einem anderen Controller aufbauen und schauen, was sich da machen laesst.
1 „Gefällt mir“
Wer meine Versuche nachvollziehen moechte kann sich folgende Projekte und Links mal anschauen:
- https://github.com/OpenZWave/open-zwave: Die CPP implementierung des Z-Wave Protos
- http://www.fhemwiki.de/wiki/Z-Wave: Solide, deutschsprachige Einfuehrung in Z-Wave
- https://github.com/cdjackson/HABmin/wiki/ZWave-SUC-Controller-Mode: Gute Zusammenfassung von SUC/SIS
- https://github.com/OpenZWave/open-zwave/wiki/Config-Options: OpenZWave config Parameter
- http://www.activeautomation.co.nz/boards/topic/3/adding-aeotec-z-stick-as-a-second-controller-to-an-existing-z-wave-network: Wie man den Aeon Z-Wave Stick als secondary hinzufuegt
- https://github.com/OpenZWave/node-openzwave-shared: Node.js Projekt zum Bridgen von Z-Wave (auf Basis von OpenZWave-CPP) ueber Node.js in MQTT
Als Controller Hardware kommt, neben den Homee Cubes, https://www.heise.de/preisvergleich/acer-aspire-m1-601-schwarz-dt-b28eg-001-a1385419.html zum Einsatz. Wahrscheinlich werde ich meinen naechsten Versuch mit OpenHAB 2.0 (Achtung! Aktuell nur in der Beta4 verfuegbar) starten.
3 „Gefällt mir“
@Matz0r Ich habe zwar die E-Mail mit dem Hinweis auf den API Blueprint bekommen, kann aber deinen Post hier im Forum nicht sehen. Schade eigentlich, der Hinweis ist Gold wert ^^.
Das Github Repo ist auch gerade Verschwunden. Ohne jetzt eine Verschwoerungstheorie aufmachen zu wollen … aber das is schon seltsam. Ich hab mir auf Basis des API Blueprints fix mal n Script gebaut, was die API Events abfangen kann. Funktioniert genau so wie man das erwartet.
Liebes Homee Team, warum soll die API keiner sehen? Dit is doch sehr nahe an dem, was sich hier im Thread gewuenscht wurde.
Ich versteh euch echt nicht. Ihr habt hier ne Community, die gern auf der Basis von eurem Produkt “geilen Scheiss” machen will. Kein Feedback (und die Erklaerung, dass nicht alle Bock auf Forumsarbeit haben find ich eher schwach als nachvollziehbar.) von euch zu dem Thema. Dann taucht ein API Blueprint auf, der es mir erspart eure Websocket API aus der Web App “reverse zu engineeren” und der Forumsbeitrag des guten Menschen verschwindet kurz danach. BTW: Die Mail hab ich trotzdem erhalten. Dann verschwindet ein paar Minuten spaeter auch noch das referenzierte Github Repo. Ich verstehe eure Politik so ganz und garnicht und kann, wenn ich mir die Indizien anschaue, nur den Kopf schuetteln.
Wenn ihr nicht mit ner echt guten Erklaerung um die Ecke kommt, habt ihr mich als Kunden definitiv verloren.
Es ist unsere Entscheidung wann und ob wir die API veröffentlichen. Wir werden das Thema intern besprechen und dementsprechend handeln. Dass die API auf GitHub lag war mehr oder minder ein Fehler den wir behoben haben. Aktuell ist die API und auch die Dokumentation dazu unter keinen Umständen releasefähig. Es gibt unzählige nicht oder nur unzureichend dokumentierte Stellen, die jedem Entwickler, der nur diese Dokumentation zur Verfügung hat, früher oder später die Haare grau werden lassen. Eine öffentlich zugängliche API bedarf einer gewissen Stabilität und eines gewissen Detailgrades. Beide Punkte sind bei unserer API aktuell noch nicht erfüllt.
5 „Gefällt mir“
Ich finde es auch echt schade. Ihr verwendet doch eure API auch um die Apps damit zu verbinden. So instabil kann sie dann ja nicht sein.
Ich baue gerade eine Alexa Anbindung, da es fuer euch wichtigere Dinge gibt. Das ist aber mittels Webhooks auch total nervig.
@xenji wenn du weitere Infos hast, gerne an mich homee[at]programmieramt.de
1 „Gefällt mir“
Lieber Thomas, ich habe mit Nichten abgestritten, dass das eure Entscheidung ist. Was ich jedoch bemaegele, ist eure Kommunikationspolitik.
Ich denke, Du wirst mir zustimmen, dass die Reihenfolge der Ereignisse einen ziemlich unangenehmen Beigeschmack hinterlaesst. Die Informationen aus Deiner Antwort waere eine sehr gute Grundlage gewesen, um diesem Thread eine positive Perspektive zu geben. In diesem Forum wurde schon mehrfach (ich kann bei Bedarf gern Referenzen heraussuchen) angemerkt, dass “man” sich mehr Feedback oder Interaktion von/mit euch wuenscht. Einen Thread kommentarlos zu loeschen ist aus meiner Sicht da eher weniger das erwartete Verhalten.
Ob nun mit oder ohne API Blueprint jemand hingeht und eure Socket API gebraucht, dass koennt ihr aus meiner Sicht nur durch proaktive Kommunikation steuern. Spaetestens nach meinem Hinweis vom 2. November haette ich eine solche Information mir gewuenscht. Wenn ihr nicht proaktiv Informiert, dann ist die Konsequenz, dass sich Menschen ihre Wege suchen - was ja gerade hier in diesem Thread passiert.
Ich verstehe halt nicht, wo das Problem ist. Das, was mir jetzt als Blueprint vorliegt, ist genug fuer einen Entwickler mit ein wenig Motivation, um daraus zu lernen und zu testen. Wenn es fuer eure Web UI reicht, warum sollte es dann nicht fuer mich reichen? Klar unterliegt die API konstanten Aenderungen und ihr wollt nicht jede Version supporten, etc. Ich bin selbst Dev und kenne das Spiel nur zu gut.
Wenn ihr das wollt, dann kann ich oder auch der @Baschtl (oder wir zusammen), euch gern mal die Projekte zeigen, die wir auf Basis der WS API bauen. Vielleicht ist das Feedback ja wertvoll fuer eine stabile Version einer API in der Zukunft?
3 „Gefällt mir“
Wenn es fuer eure Web UI reicht, warum sollte es dann nicht fuer mich reichen?
Weil es aktuell einfach unzählige Workflows gibt die dort überhaupt nicht dokumentiert sind, aber im Zweifel wichtig für die korrekte Funktion. Zudem wirst du früher oder später auf eine Unmenge von “magic numbers” stoßen, welche dort auch schlecht bis gar nicht dokumentiert sind. Zudem kannst du aus dieser Dokumentation manche Dinge gar nicht wissen oder verstehen die hier intern, oft gern auch mündlich, kommuniziert werden. Wir wissen denke ich selbst am Besten wie es um die Dokumentation bestellt ist und treffen daher auch die Entscheidung diese zu Veröffentlichen oder nicht. Wenn du dir mit den Informationen die du nun hast etwas basteln möchtest, nur zu. Eine für die Öffentlichkeit und fremde Entwickler brauchbare Dokumentation ist dies im aktuellen Stadium leider noch nicht.
Ich habe mir homee gewählt weil ich einfach keinen Bock habe,selber Programme zu schreiben oder sonstiges in dieser Art. Auf dem Markt gibt es genügend Bastel Programme und Geräte. Bisher bin ich noch sehr überrascht wie wenig ich in diesem Jahr über Sicherheitslücken bei homee gehört habe. Mein Bruder, eben Programmierer, baut noch viel mehr an seinem “smarten Haus”, eben über Z-Wave. Ich lasse ihn. Lasst ihr bitte auch die Homme S . Oder zahlt das Geld damit sie davon leben können. homee, macht so weiter.
Grüße Peter
1 „Gefällt mir“
Das Argument lasst die Leute machen ist bezahlt sie dafür kannst du unter jeden Feauture Wunsch schreiben.
Es ist lediglich eine Anfrage, etwas zu nutzen das es schon gibt.
Und das schöne an einer Api ist ja das sie niemand nutzen muss.
Hallo Peter,
Schnittstellen gibt es ueberall, unsere digitale Welt basiert auf der Kommunikation zwischen Diensten und Geraeten. Sich der Illusion hinzugeben, dass durch das Weglassen ein API Sicherheit entsteht halte ich fuer gefaehrlich. Dieses Gefuehl von Sicherheit ist truegerisch und, rein faktisch, falsch. Die hier gefuehrte, sicherlich von meiner Seite etwas ueberstilisierte, Diskussion geht um eine Schnittstelle, die jeder Nutzer von Homee bereits verwendet, wenn die Webapp verwendet wird. Das Leugnen des Vorhandenseins dieser Schnittstelle fuehrt zu oben beschriebenem Effekt. Ich kann Dir, lieber @PeterS, nur versichern, dass die Jungs von Homee keine dummen Menschen sind und die API nach ueblichen und soliden Standards abgesichert haben und Du Dir damit keine grundlegenden Sorgen ueber die Produktqualitaet machen solltest.
Das diskutierte Thema geht vielmehr in die Richtung der Integration anderer Geraete in Verbindung mit dem Homee Stack, um einen von @Baschtl oder auch mir gesehenen Mehrwert fuer uns und auch vielleicht fuer Andere zu schaffen.
Zum Thema Geld:
Homee ist, bisher jedenfalls und nach meinem besten Wissen, ein one-time Produkt. Ob das nun gut oder schlecht, passend oder nicht ist, dass kann und will ich nicht bewerten. Was ich jedoch erwarte ist, dass wenn man eine solche Entscheidung fuer die Produktstrategie trifft, man sich Gedanken ueber die Fortentwicklung der Hard- und Software macht sowie die Finanzierung dessen aus den Produktverkaeufen. In einem Preis von z. B. 199 EUR fuer Z-Wave und Braincube stecken ja nur zu einem marginalen Teil die Materialkosten. Der Rest ist Lager, Personal, Marketing und Research & Development, was nicht nur vergangene Entwicklung sondern in diesem Fall auch zukuenftige Entwicklung bedeutet (da kein Abo / pay per month Modell vorhanden ist). Dazu kommt noch der Betrieb der Webseite, der Webapp und die Gebuehren fuer iOS Entwicklung, plus weitere Kosten, die ich vergessen habe oder nicht kenne. Natuerlich weiss auch nicht, ob da ein Business Angel oder sonstige Geldquellen die Finger drin haben.
Ich gehe daher davon aus, dass jedes Feature sehr stark geprueft wird, ob es auch zukuenftige Verkaeuft foerdert, denn das erscheint mir eine logische Konsequenz zu sein.
Eine oeffentliche, stabile und dokumentierte API ist, zumindest aus der Sicht eines Entwicklers, nicht nur ein Bastel-Instrument, sondern ein klares Verkaufsargument. Nun ist es absolut valide zu argumentieren, dass Entwickler nicht die Zielgruppe sind. Da stimme ich zu.
Bitte bedenke jedoch: Ein Produkt was sich nahtlos mit meiner Sonos Box, meiner Fritzbox oder sonstigen weiteren Devices integrieren laesst, ist immer attraktiver, als ein allein stehendes. Somit sehe ich eine API (als Integrationsmittel in bestehende, heterogene IoT Landschaften) als absolut positives Feature durch die value addition fuer eine einmalige Investition von Homee.
Ich hoffe ich konnte die Grundlage der Diskussion etwas verdeutlichen.
3 „Gefällt mir“
@Thomas: Mir ist klar, dass du dich hier nicht auf einen Flamewar einlassen willst und das der Grund ist, warum du meine Kritikpunkte in deiner Antwort vollstaendig ignorierst. Dieses Verhalten hat aus meiner Sicht leider den negativen Effekt, dass zumindest ich mich in meiner Ansicht nur bestaerkt fuehle, dass euch die Kritik egal ist. Ich ziehe meine Konsquenz daraus und werde mein Homee Zeug verkaufen und gegen eine OpenHAB / Z-Wave Loesung austauschen.
Auch wenn diese Diskussion sicherlich beidseitig einen besseren Verlauf und Ton haette nehmen koennen, wuerde ich mich freuen, wenn ihr euch in dieser, von euch erschaffenen, Community besser integriert.
In Referenz auf mein Antwort an @PeterS: Ich kann mir schon vorstellen, dass, sofern ich mit meiner Theorie recht habe, dass Bestandskunden weniger wichtig sind als Neukunden. Denkt einfach dran, dass Bestandskunden auch mit potentiellen Neukunden reden und dass andere Neukunden sich erstmal in der Community umschauen, bevor sie kaufen.
2 „Gefällt mir“
Guten morgen,
Kritik ist mit Nichten egal. Nur sollte bedacht werden das Kritik nicht so funktioniert dass wir einfach alles ändern was womöglich kritisiert wurde. Wir nehmen dies zur Kenntnis und werden es versuchen besser zu machen. Das Kommunikationspolitik wäre gar nicht aufgekommen wenn wir nicht intern den Fehler mit GitHub gemacht hätten. Dieser Fehler ist nun behoben und somit ist das Thema für jetzt vom Tisch. Ich schätze dich als sehr versierten Anwender ein und denke du wirst mit Lösungen wie Open-HAB wahrscheinlich am Ende des Tages sicher mehr Freude haben. Ich wünsche dir dennoch viel Spaß bei deinen zukünftigen Projekten.
2 „Gefällt mir“
Dank @Tektura konnte ich mir die API Blueprint - die ja versehentlich im GitHub existierte - mal zu Gemüte führen. Die Dokumentation fand ich im übrigen gar nicht so schlecht, wenngleich eine ggf. aktuelle Version nützlicher wäre.
Wie dem auch sei, ich habe anhand dessen heute morgen als ersten Schritt einen kleinen PHP Wrapper dafür gebastelt: https://github.com/CodeKingLabs/homee-php-api
Derzeit können darüber allerdings fürs erste nur alle verfügbaren Inhalte (Geräte, Gruppen, Homeegramme, Einstellungen, User, etc) ausgelesen werden, ich werde wohl auch erst im neuen Jahr dazu kommen diese zu erweitern, aber vlt. kann ja der eine oder andere bereits etwas damit anfangen.
Der PHP Wrapper ist auch bereits in meinem Dashboard im Einsatz, dann kann ich die Werte der einzelnen Geräte direkt auslesen und muss diese nicht mehr zwischenspeichern.
Viele Grüße,
Frank
P.S.: Bitte auch nicht zuviel erwarten, ist nur ein erster Ansatz
3 „Gefällt mir“
Ich hab in der Zwischenzeit die .dmg der Beta mal auseinandergenommen. Die verwendete Bibliothek ist diese hier:
http://www.openzwave.com/device-database
Ich suche eigentlich nur noch die Stelle an der die Deviceliste eigeschränkt wird. Da ich ja meine Homee verkauft habe für mich nicht mehr nützlich, aber für andere bestimmt…
VG
Michael
1 „Gefällt mir“