Push
Gerade in Kombination mit dem geplanten Feature Vergleich mehrerer Sensoren ein echter Mehrwert.
Man kann sich ja erst Mal auf die einfachen „Geräte“/Variablen beschränken.
Schalter/Boolean sind indirekt ja bereits über die Enocean Steckerleiste verfügbar. Interessant wären vor allem noch Thermostate als Temperaturwerte sowie Dimmer/Rollläden als %-Werte.
@Chris schaut euch den Vorschlag bitte unter dem Aspekt noch Mal an und bewertet ihn neu. 
Ich dachte heute, schau doch noch mal bei den Homee-Vorschlägen „Virtuelles Gerät“ (Feature oder Gerät - egal) vorbei. Leider wieder nix . . .
Nach Jahren Pflege hatte ich es nun endgültig satt und habe die HA Bridge aus meiner Konfiguration rausgeschmissen. Dabei will ich doch nur ein paar Webhooks abfeuern. Das habe ich jetzt direkt in Verbindung mit Alexa-Szenen bzw. -Routinen umgesetzt. Damit erreiche ich zwar nicht dasselbe, es reicht aber. Dazu der Mehraufwand in der Alexa-App. Im Gegenzug gibt’s einen freien Webhost und weniger Stress.
Ehrlich gesagt, verstehe ich das Zögern oder den Widerstand bei dieser Idee nicht. Wie viele Wikis und Workarounds müssen noch ge- und beschrieben werden? An der technischen Umsetzung kann es m. E. nicht liegen.
Gruß Stefan
Als Homee-Neuling und Informatiker habe ich mich sofort gewundert, daß es sowas nicht längst gibt.
Virtuelle Geräte könnten auch dazu beitragen, in komplexen Smarthome-Installationen die Struktur der Homeegramme übersichtlich zu halten. Wenn man z.B. 5 identische Aktoren hat, bräuchte man ggf. nicht mehr 5 Homeegramme zur Steuerung dieser, sondern nur noch eines, wenn man beim Aufruf das zu steuernde Gerät benennen (als Parameter übergeben) kann.
Kapiere nicht, wie dir da ein virtuelles Gerät helfen kann und wie du auf 5 HGs kommst. Kannst du ein Beispiel nennen?
(Klingt so, als wenn deine Anforderung mit einer Gruppe bereits umsetzbar ist)
Das ist mal wieder eine tolle Idee von Dir. Wirklich! Aber leider funktioniert es nicht, zumindest bei mir, nicht besonders gut. Bei Gruppen ab einer Größe 3 werden nicht alle Geräte gesteuert. Also bin ich da wieder weg von. Und noch ein Beispiel. Eine Gruppe Rollos, sagen wir 4, davon 2 mit Smarten Fenstergriffen. Da sollen die Rollos nur schließen wenn auch die Fenster geschlossen sind. Da braucht man schon 2 Gruppen…
HG 1 = wenn Auslöser (Zeit, Sonnenuntergang…)
dann Rollladen 1 schließen (ohne Verzögerung)
Und dann 2. Rollladen schließen
(1 Sekunde Verzögerung)
usw
HG 2 = (Auslöser) wenn Rollladen schließt
(Bedingung) Fenster 1 ist nicht geschlossen
(Aktion) dann Rollladen auf 0% setzen
Das funktioniert bei mir ohne Probleme.
Moin, so ähnlich mache ich das auch.
Ich habe ja nur festgestellt, dass wenn man Gruppen nutzen möchte man bei meinem Beispiel 2 Gruppen braucht.
Hi Wildsparrow,
da IPWF kein Beispiel nennt, mache ich das mal. Man könnte mit Variablen z.B. in HG schreiben zu öffnen eines Rollos.
wenn hg abgespielt wird
dann setze rollo(&rollo1) auf wert(&wert)
übergeben wird dann der name des Rollos und der Wert:
dann setze rollo(rollo1) auf wert(30%)
je nach Tages-, Jahres- oder Uhrzeit könnte man dann das gleiche HG verwenden. Oder wie ich hier im Forum schon gelesen habe habe:
nur wenn Nachts (zb. Uhrzeit, oder aktives hg,…)
dann schalte Licht(&licht) auf wert(&wert)
also Nachts auf 20% am abend auf 80%, oder, oder…
Klar kann man alles lösen und unter umständen wird auch die Anzahl der HGs nicht weniger… aber eventuell wird es übersichtlicher 
Ja, da würden Variablen helfen. Aber hier geht es ja um ein virtuelles Gerät. Und darunter verstehe ich sowas wie nen Schalter (den es nicht physisch gibt) und du kannst auf den Schalterzustand reagieren. So ähnlich wie Bool. Aber sobald da verschiedene Temperaturen und Werte ins Spiel kommen, sind wir ja nicht mehr bei einem Gerät, sondern bei einer normalen Variable 
Ein „Gerät“ (nicht DER Gerät) hat nach meiner Definition (egal ob real oder virtuell) durchaus auch „Attribute“ (Temperatur, Lautstärke, Schaltzustand, usw.).
Eine Variable (EINE Variable, ein Zustand) ist demnach etwas anderes als ein virtuelles Gerät (mehrere Variabeln, ggf. ein Array an Werten).
Wir könnten uns evtl. darauf einigen, dass dieser Vorschlag schlicht und einfach den falschen Titel hat
Wow, was ist denn hier los? Als Ideengeber des „Virtuellen Gerätes“ melde ich mich auch mal zu Wort. Wie man dem Datum entnehmen kann, ist der Vorschlag 4,5 (!) Jahre alt. Ich habe ihn gemacht in der Hoffnung, auf diese Weise schnell und ohne großen Aufwand auf Seiten der Homee-Entwickler eine praktikable Lösung für eine „globale Variable“ mit ggf. bis zu 256 Werten zu bekommen, auf die HGs zugreifen können. Das funktioniert ja auch wunderbar, wenn man „echte“ Geräte für so einen Zweck nutzt - nur muss man für ein solches echtes Gerät Geld ausgeben und kann es möglicherweise für seinen eigentlichen Zweck nicht nutzen.
Der Vorschlag ist im Frühjahr 2021 natürlich völlig aus der Zeit gefallen. Schade nur, dass Homee bislang in diese Richtung nichts Adäquates anzubieten hat - oder ist mir da was entgangen (bin für Hinweise dankbar)?
… wie die Zeit voranschreitet. Der Vorschlag ist (Stand heute (Nov 21)) mehr als 5 Jahre alt. Dennoch hat sich nichts getan. Ich halte Webhook - Geräte (oder wie man diese auch immer nennen mag) über eine enorm vielseitige Schnittstelle. Würde der Logik von Homee voll entgegenkommen. Viele unterschiedliche Hersteller, eine Zentrale.
Ich mach jetzt nur ein bisschen in VBA rum (Achtung gefährliches Halbwissen), halte den Aufwand für vertretbar das zu integrieren. Eine Webhook - Schnittstelle ist vorhanden, die grafischen Module auch. Jetzt muss man das doch „nur noch“ zusammenführen. Man kann ja mal mit der einfachsten Variante anfangen.
Mich würde mal eine Stellungnahme von der Homee GmbH interessieren. → abgelehnt, wird umgesetzt wenn Zeit ist, wird umgesetzt bis zum.
Mit einem Enocean Würfel gibt es diesen hack:
Oder viel besser noch so:
Na der Tipp ist mal richtig gut. Geht in die Richtung. Ich hab zum Glück den Enocean Würfel.
Was mir dann aber nicht in den Kopf will → dann wäre die Implementierung ja noch einfacher. Es ist ja alles da… Warum ist das dann noch nicht gemacht von der Homee GmbH? Das wäre doch ein gutes Verkaufsargument. Eine zusätzliche Funktion die wenige Wettbewerber (aktuell ist mir keines bekannt) bietet. Ich gehe sogar noch ein Schritt weiter → Wenn das gut gemacht ist, kann das die Funktion sein, welche zur Kaufentscheidung beiträgt.
Dafür müssten Sie nur den Entwickler/n was bezahlen. Oder eine Eigenentwicklung, was nun wieder Blödsinn wäre, weil es eine wirklich gute Umsetzung gibt.
Niemand hat gesagt, dass es Umsonst sein muss. Ich habe mir den Homee mit einer gewissen Funktionalität gekauft. Wenn die Funktionalität erweitert wird, stellt das ja gegenüber dem ursprünglichen Stand ein Mehrwert dar. Daher bin ich auch durchaus bereit so was zu vergüten.
Der Hersteller muss halt abwägen, was Ihm wichtiger ist. Die Funktionalität sich bezahlen lassen durch ein kostenpflichtiges Update (was sicherlich den einen oder anderen User verprellt) oder es als F&E Projekt sieht und die entstandenen Kosten über weitere Verkäufe rein holt. Marketingtechnisch nicht zu unterschätzen ist die Mund-zu-Mundprobaganda der User die eine kostenfreie Erweiterung der Funktionalität gern mit nehmen und dadurch den Würfel vielen Benutzern / Bekannte / Freunde empfehlen.
Ist wie bei einer guten Bohrmaschine von Fein. Hier bekomme ich heute noch für alte Modelle Ersatzteile. Bei Konzernen mit kurzfristigem Gewinndenken liegt die Maschine kurze Zeit im Müll wenn was kaputt ist. … na? Welche Bohrmaschine habe ich zu Hause? (obwohl ich Hobbyanwender bin).
Da bin ich absolut bei dir. Ich wäre durchaus bereit für Erweiterungen einen angemessenen Betrag zu zahlen. Wir bekommen ja auch permanent über den Reverse-Proxy eine kostenlose Dienstleistung. Mit irgendwas muss die Firma ja Geld verdienen. Aber das Thema wurde ja bereits schon öfters hier behandelt.
@annaeymnd ich denke hier können wir zwar noch einiges verändern, aber als Umgesetzt schon einstufen.