Umfrage: Welchen Adapter soll ich als nächstes entwickeln?

[Negalein]

@Mic sagte in Umfrage: Welchen Adapter soll ich als nächstes entwickeln?:

aber du könntest mithelfen beim testen/entwickeln für deine 2014er Version

gerne

[Mic]

Zwischenstand:

Bewegungsmelder ist bislang vorne.
Ist auch das komplexeste Projekt dieser Liste, so einfach wie es klingt, mal eben ein paar Lampen und Bewegungsmelder zu verbinden. Aber verschiedener Hersteller diverse Logiken wie "nicht schalten bei Abwesenheit", unterschiedliche Schaltzeiten pro Wochentag, Timer, Helligkeit, usw. Dann noch user-friendly einstellbar.
Aber wohl auch am interessantesten als Entwickler...
Bevor ich damit loslege, würde ich eh noch mal einen neuen Thread aufmachen, um eure Use Cases abzuklopfen.

[Tirador]

Hallo Mic, ich verwende dein aktuelles Bewegungsmelder Skript und habe gesehen, dass du nun einen Adapter in Planung hast.

Generell sehe ich das Thema Lichtsteuerung sehr zentral und würde mir eine erweiterte Logik wünschen, die mehrere Anforderungen in einen Adapter für die zentrale Lichtsteuerung integriert. Die Steuerung des Lichts (zumindest bei mir) ist von mehreren Faktoren abhängig:

• Benutzersteuerung (HUE Schalter, Licht an/aus an physischen Schaltern)

  • Merken des letzten Zustands eines Lichts auch bei physischem Ein/Ausschalten (Automatische Wiederherstellung)

• Automatische Lichtsteuerung in Abhängigkeit:

  • der Tageszeit z.B. Sonnenaufgang, Sonnenuntergang
  • in Abhängigkeit von Bewegungsmeldern
  • Aufbau dynamischer Szenen (Farbwechsel, Alarmsteuerung d.h. Blinken von Lichtern)
  • Wechsel der Farbtemperatur in Abhängigkeit der Tageszeit (siehe Dynamisches Licht).

• Nachrichtenereignisse, die alle anderen Lichtsteuerungen "übersteuern". Das Erzeugen / Verwalten und Visualisieren von Nachrichtenereignissen erfolgt über dieses MessageHandler-Skript Beispiele für die Lichtsteuerung nach Nachrichtenereignissen:

  • ein Ereignis ALARM (Feueralarm, Einbruchsalaram) sollte die Lampen im gesamten Haus anschalten (wenn es Nachts ist).
    Bestimmte Lampen sollen zudem auf rot gestellt werden.
  • ein Ereignis WARNUNG soll bestimmte Lampen gelb leuchten lassen.
  • ein Ereignis INFORMATION soll bestimmte Lampen blau leuchten lassen (z.B. das ein wichtiger Termin ansteht, oder dass Post eingewurfen wurde).

• Ausnahmeregeln für die automatische Lichtsteuerung

  • bei Abwesenheit sollen keine Bewegungsmelder und Nachrichtenereignisse ausgelöst werden

Lichtsteuerung ist damit ein komplexes Thema und Bedarf einer eigenen zentralen Steuerungslogik. Bisher habe ich leider noch kein Skript gesehen, was versucht hat alle Lichtsteuerungsregeln zu zentralisieren.

Was hälst Du davon, die Punkte alle in einen Adapter einfließen zu lassen?
DIe Punkte oben kann man schrittweise angehen.
Was mir aktuell in meiner Lichtsteuerung fehlt ist eine Priorisierung der Automatiken untereinander.

VG Tirador

[Mic]

Hi @Tirador ,

danke für dein ausführliches Feedback, genau das was ich brauche
Ich hatte eh vorgehabt, mal in die Runde (per neuen Thread) zu fragen, welche Features hier so für eine Licht-/Bewegungsmelder-/Gerätesteuerung sinnvoll sind.

Alleine dein Beitrag zeigt schon mal die Komplexität des ganzen.
Allerdings wäre so ein Adapter auch wirklich elementar eigentlich für jeden ioBroker-User, selbst für den interessant, der nur mal eben ein Licht angebunden hat.
Statistiken sicherlich keine verfügbar, aber ich vermute, mindestens 20% aller User-Blockly/JS behandeln dieses Thema.

Je länger ich darüber nachdenke, ist das auch wohl nicht von einem einzelnen Developer (also nur mir ) machbar, sondern müsste ein Gemeinschaftsprojekt sein. Alleine der Support ist tough (z.B. "meine neue Lampe abc vom Hersteller xyz wechselt nicht zur Farbe rot bei Alarm").
Oder mögliche Feature Requests wie zB:

• Sonos soll auf 15% Lautstärke den Radiosender 123456 starten, wenn jemand zwischen 7:00-8:00 ins Bad geht, aber an arbeitsfreien Tagen erst später, und nicht wenn der Wecker "Alexa Schlafzimmer" noch aktiv ist.

D.h. da kommen wir auch teils in sehr komplexe "If This Then That" Abfragen. Das will der Anwender dann natürlich dynamisch in VIS und auch in der Adapter-Konfiguration pflegen können.

Für einen Adapter müsste man klar Grenzen setzen, und unbedingt "Exclusions" definieren. Adapter müssen auch einfach bedienbar sein. Gerade bei diesem Thema steht natürlich auch die User-Requests nach "VIS-Bedienung" und auch Widgets im Raum...

[Tirador]

@Mic Hallo Mic, das Problem an allen Heimautomatisierungslösungen ist nunmal dass viele nicht über WENN/DANN-Regeln hinauskommen bzw. es jedem Anwender überlassen ist, sich die komplexeren Logiken zu überlegen wie die Dinge/Geräte miteinander interagieren sollen in allen Anwendungsfällen.

Man braucht nur einen klar geordneten Aufbau für diesen Adapter und man sollte Logiken abstrahieren, die Teil des Adapters sind und die durch andere Adapter/Skripte hinzugebracht werden. Alles in einem Adapter abzubilden führt zur Redundanz und Unwartbarkeit von Logiken.
Eventuell braucht es mehrere "Teil"-Adapter bzw. Skripte, um das gesamte Puzzle zu lösen
D.h. der zentrale Adapter kümmert sich nur um die Lichtsteuerung, aber dafür notwendige Logiken werden größtenteils in Submodule/Adapter/Skripte verlagert. Aus der Skriptprogrammierung kenne ich nur die Schnittstelle per State/Datenpunkt.
In diesem Sinne würden die aus der Lichtsteuerung zu verlagernden Teilmodule States/Datenpunkte zur Verfügung stellen.
Z.B.

• Ein Skript/Adapter für die Vorgabe der Zeitsteuerung (Jeden Werktag 7:00 bis 8 Uhr, an arbeitsfreien Tagen später). Dieser Adapter ermöglicht dann die Erfassung von dynamischen Zeitregeln und die Zuordnung auf einen eindeutigen Bezeichner (z.B. "VORMITTAG WERKTAG", "ABENDS WOCHENENDE").
• Ein Skript/Adapter für die zentrale Steuerung der Nachrichten: Die Nachrichtenfunktion stellt einen Datenpunkt zur Verfügung, der sagt ob "INFO", "ALARM"; WARNUNG etc. eingetreten ist.
• Ein Submodul dient der Definition der Bewegungsmelder: die Bewegungsmelder-Funktion schaltet nicht selbst das Licht, sondern stellt nur einen Datenpunkt für jeden BWM zur Verfügung (Bewegung AN/AUS).
• Ein Skript dient der Anwesenheitsteuerung und stellt einen Datenpunkt (Personen anwesend ja/nein) zur Verfügung.
• Ein Skript stellt zu jeder Tageszeit die Lichtfarbe in Kelvin in einem Datenpunkt zur Verfügung (siehe Skript dynamisches Licht oben im Beitrag)

Der Adapter für die Lichtsteuerung baut dann nur auf States der anderen Adapter auf.
Damit kann man dann Regeln zuordnen wie folgt:

1. Nachrichtenereignisse: Wenn NACHRICHTENEREIGNIS gleich ALARM
   UND WENN Personen Anwenend
   DANN SCHALTE LICHT AUF xy

2. Bewegungsmelder: WENN BWM AN DANN SCHALTE LICHT AUF xy etc.

3. Normale Lichtregeln: WENN "ABENDS WOCHENENDE" DANN SCHALTE LICHT xyz EIN.

4. Manuelle Eingriffe:

D.h. der zentrale Adapter für die Lichtsteuerung kann sich auf das wesentliche konzentrieren:

• Vorgabe von Lichtregeln (für einzelne Lampen/Gruppen): Steuerung des Lichts durch Vorgabe von Lichtregeln (Helligkeit, Lichtfarbe, Temperatur, An/aus etc.)
• WENN/DANN-Regeln: Einfache WENN/DANN Regeln unter Hilfe der vorgelagerten Logiken
• Priorisierung von Lichtregeln untereinander (im Beispiel haben Nachrichten vorrang vor BWM und manuellen Steuerungen)

Wichtig für das Vorhaben, ist das das die Logiken abstrahiert und in einzelne Funktion aufteilt sind. Dann hat es eine Chance für ein echtes "SmartHome" und nicht die Einzelsteuerung von allem möglichen in jedem Skript für sich. Ich denke auch dass dies eine Person nicht stemmen kann, aber wenn man mehrere Mitstreiter findet, könnte man die Logiken systematisieren und somit aufeinander aufbauen.

[Omnedon]

@Mic Ein sehr interessantes Projekt.
Denn ein einfaches HM-Script das das Licht einschalten wenn Bewegung da ist und wieder ausschaltet wenn keine Bewegung da ist, funktioniert in den meisten Fällen auch.
Das Problem ist wenn jemand das Licht manuell einschaltet ohne dass der BWM das mitkriegt, dann brennt das Licht, denn es kommt kein Signal, dass es keine Bewegung mehr gibt.
Ein weitere Problem hier ist das Bad: wenn keine Bewegung da ist - man sitzt auf dem Klo - dann geht das Licht aus.
Dazu sage ich nur - schei..en im Dunkeln - nein danke!

Ich habe mich damit auch ein wenig befasst und ein relativ einfaches Programm zur Lichtkontrolle geschrieben.
Es bindet Lichtaktoren, Bewegungsmelder und Türen ein.
Die Türen haben hier eine Schalterfunktion, d.h. unabhängig von Lichtstatus, wenn die Tür zu ist, dann bleibt der Lichtstatus so wie er ist (aus oder an) - so sitzt man nicht im Dunkeln auf dem Klo!
Darüberhinaus gibt es einen Timer der abläuft und dann sobald wirklich keine Bewegung da ist, das Licht ausschaltet.
Jede Bewegung oder manuelles Lichteinschalten setzt den Timer zurück.
Die Idee von @Tirador mit den Lichtregeln finde ich sehr gut!
Es wäre auch gut wenn man einzelne Räume auch je nach Bedarf auch deaktivieren könnte.

[Mic]

@Jey-Cee sagte in Umfrage: Welchen Adapter soll ich als nächstes entwickeln?:

@Mic hm also Phillips und Sonos wären jetzt für mich sachen die man auch in den eigentlichen Adptern unterbringen könnte.

@Mic sagte in Umfrage: Welchen Adapter soll ich als nächstes entwickeln?:

Hi @Jey-Cee

Guter Punkt. Da würde ich mich dann auch mit den jeweiligen Entwicklern abstimmen.

Wobei Sonos ist schon sehr speziell -- da ist es ggf. schon sinnvoll, den bestehenden stabilen Sonos-Adapter zu haben, und dann einen weiteren (z.B: "Sonos Control") für die spezielleren Sachen, der sich erst aufgrund User-Feedback nach und nach dynamisch entwickeln muss. Zumal wohl Sonos bald die API umstellt bzw. ab Juni (?) neue Software ausliefern soll, das wird ggf. eh eine Herausforderung.
Also ähnlich wie die beiden Homematic-Adapter.... (wobei der Vergleich hinkt)

Habe es hier mal für Sonos zur Diskussion gestellt: https://github.com/ioBroker/ioBroker.sonos/issues/67

Mic-M created this issue in ioBroker/ioBroker.sonos

closed Adapter Dev Question: Extend this adapter or develop new adapter? #67

[Mic]

@Tirador
@Omnedon

Danke für eure Antworten, Ideen und Ausführungen zu "Adaper für Licht/Bewegungs/Geräte-Steuerung".

Ein Stolperstein für mich ist noch die Umsetzung im ioBroker Admin:
Ich habe mal bei anderen Adaptern geschaut, etwa https://github.com/simatec/ioBroker.shuttercontrol von @simatec bietet in den Adapter-Optionen eine Tabelle an (wo man also dann z.B. einzelne Bereiche anlegen könnte - z.B. "Flur 1. OG"), und einen Stift, mit dem ein Untermenü kommt.
In diesem Untermenü bräuchte ich dann weitere Tabellen zur einfachen Konfiguration, aber blicke es leider (noch) nicht, wie ich das integriert bekomme. Dies ist aber meines Erachtens notwendig, um die komplexeren Setups einfach abzubilden....

Die Herausforderung ist also erst mal, eine vernünftige user-friendly Konfiguration hinzubekommen , der Adapter-Code selbst dahinter ist dann eher einfach (relativ gesehen )

[Tirador]

@Mic Hey Mic, so ganz kann ich dir von der Benutzer/Bedienerführung noch nicht folgen. Vielleicht kannst Du genauer erläutern, wie Du dir das Datenmodell und die GUI für den Anwender vorstellst. Vielleicht können wir ja gemeinsam überlegen, wie man das dann anlegen könnte.

[Mic]

@Tirador
Hi,
es geht mir um die einfache Abbildung im Admin, damit die User das auch übersichtlich und einfach konfigurieren können.

Erstentwurf meines Konzeptes steht schon, wird sich aber sicherlich noch ändern.

Unter "Triggers" erfasst man alle Auslöser, also Bewegungsmelder, Wandschalter, usw.

Unter "Target Devices" erfasst man alle zu schaltenden Geräte:

Unter "Rooms" führt man diese dann zu "Bereichen/Räumen" zusammen, also "Leseecke", "Esstisch", "Flur EG" usw.

Weiteres wie Zeitsteuerung usw. fehlt hier noch. Ebenso sowas hier, das dann den Räumen/Bereichen zugeordnet werden kann.

[sigi234]

@Mic

Schaut schon gut aus, ich bin jederzeit bereit zu testen.

[Mic]

@sigi234
Bitte noch etwas Geduld, hab noch 0 Zeilen Code (außer Admin-Konfig) geschrieben
Sobald die Admin-Konfig steht, lege ich los, dann macht es richtig Spaß das in node.js/JS umzusetzen Die Admin-Konfig bremst mich da immer ziemlich aus und verbrät leider sehr viel Zeit.

[Mic]

Hier geht es weiter

Planung neuer Adapter: Licht-/Raumsteuerung und mehr