Für den ESP CommunityCube suche ich ein neues Projekt.
Da kam es mir in den Sinn ein Webhook Projekt mit Geräten abzubilden.
Somit könnte jedes Gerät das über eine http Schnittstelle angesprochen werden kann in den homee als vhih Geräte integriert werden.
Ist diese Idee interessant für euch und habt ihr Meinugen und Vorschläge dazu?
VG
Ein Tradfri Würfel war doch noch vorgeschlagen….
Ich finde Webhooks in Homee mit am zuverläsigsten und nutze das auch viel in Verbindung mit dem Opushack und Shelly I4 mit Tasterfeld:
Ich find die Idee gut.Wäre der 2te ESP im Hue Cube dafür auch nutzbar?
Was mir in Homee aber am meisten fehlt sind Variabeln,also Speicherung von Virtuellen Werten oder Zuständen sie ich hinterlegen und abrufen kann wie zum Beispiel Kevin oder Dimmer %.
Unabhängig vom OPUS Hack wäre sicher ein ESP, in dem man über eine entsprechende WebGUI virtuelle Geräte anlegen kann, die man dann über hih im homee nutzen kann, eine sinnvolle Anwendung.
Hallo,
Die Idee eines generischen Konzepts um Geräte zu erstellen die eingebunden werden können, finde ich gut, allerdings bin ich mit nicht sicher wieviel Mehrwert ein Gerät im Homee bringt, wenn man nicht an den Status über einen Rückkanal kommt.
Dann kann ich auch die Webhooks in den HGs verwenden, oder übersehe ich hier etwas?
Ich weiß nicht, ob sowas auf einem esp32 geht. Aber wäre ein generisch konfigurierbarer MQTT Broker eine Option?
Sven
MQTT hat ja homee jetzt auch an Board. Fehlt halt nur die passende Konfiguration.
Mit den Shelly’s ist da ja nichts anderes.
Wer sagt denn das es keinen Rückkanal geben kann.
Es gibt ja auf jedenfall eine Antwort vom Server das der Befehl angekommen ist.
Genau für sowas ist der zweite ESP gedacht.
Das klingt sehr interessant =)
Besonders das man Geräte erstellen kann, dessen werte aus einem webhook/einer webapi kommen und dann wie auch immer transformiert (jsonpath/regex) werden um als eigenschaft in homee dargestellt zu werden.
Mein konkreter anwendungsfall wäre mein bsb-lan adapter zur heizungssteuerung. An die werte komm ich via webapi - aber bisher hab ich vhih auf dem raspi nicht eingerichtet um von da ab die werte in homee angezeigt zu bekommen. Wenn das über’n esp mit klick klick fertig gehen würde - hätt ichs schon 
Übrigens könnte man damit auch 1000 andere sachen realisieren, wie lampe auf grün wenn der dax über trallalla punkte kommt oder was man im internet sonst alles so noch abgrabbeln kann.
Edit: und um den bogen richtig aufzuspannen - könnte dieser cube die werte von Homee geräten auch per http api anbieten. Dann kann man nämlich problemlos ein zabbix oder grafana dran anschliessen u hat richtig gute visualisierungen =)
Jup. Und zwar den punkt das du mit webhooks nur irgendwas steuern kannst aber nicht andersrum, geräte ihre werte aus webapis beziehen. Bzw überhaupt das ein virtuelles gerät dafür angelegt wird.
Edit (des informatikers beste freundin sagt): es ist eigentlich genau das was du meinst - ein rückkanal auf ein eigenes (virtuelles) gerät dessen eigenschaften (temperatur, helligkeit was auch immer) du mittels dem ding schreiben und dann auch via hg kontrollieren kannst.
Wie wär’s mit einem Variablen/virtualDevice-Cube neben den HTTP-Devices?
Der Nutzer erstellt ein Gerät in der WebUi und hinterlegt dort die Daten, on und off url oder url mit value bei Dimmer. Den genauen Aufbau muss ich mir noch überlegen.
Dann wäre da noch die Rückmelde url interessant insofern es denn unterstützt wird.
Oder den Antwort Request als Rückkanal nehmen.
Ich kann dir dazu mal was fertig schreiben und du testet das mal ob es Sinn macht
Eine Bridge sollte doch bei Zigbee reichen 
Schauen wir mal was das neue Gateway von Ikea kann.
Unterscheidet sich der Ansatz, den du im Kopf hast, von einem vhih Gerät? Damit habe ich ein paar Variablen gespeichert…
Ein rechnender Cube? Mit echten Formeln?
Brauchst du gar nicht so kompliziert machen, da homee keine unmittelbare antwort erwartet (daher auch der watchdog).
Ich würde wie oben geschrieben es dem user überlassen welche Eigenschaften (werte) und Methoden (an, aus, vielleicht) er für das virtuelle Gerät anlegt. Bei allem fragst du nach einer url und bietest ein jsonpath/regex zum transformieren an.
Bei den Methoden siehst du ein dropdown vor, welche Eigenschaft(en) er nach dem Methodenaufruf mit welcher Verzögerung abfragen soll - und fertig ist der Rückkanal.
Setzt jetzt jemand die lampe auf an, wird die methode an aufgerufen und nach x sekunden eine abfrage des lampenzustandes getriggert (das was sonst das gerät von sich aus melden würde).
