UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Mic]

@e-s
Danke

smart living klingt sehr gut und vor allem mehr "generic" als reduziert auf Raum oder Licht / Bewegung. Namen sind ja eigentlich Schall und Rauch, aber passen sollte es dennoch

[Mic]

@crunchip sagte in Planung neuer Adapter: Licht-/Raumsteuerung und mehr:

wenn ich irgendwo sitze und das Licht wurde durch nen BWM aktiviert(timer 10min)und nun blätter ich gemütlich im Buch...erkennt das der BWM nicht unbedingt...egal wo ich den platziere, weil es in dem Fall nur ne kleine Handbewegung ist, von daher finde ich das schon sinnvoll, die Möglichkeit zu haben, BWM Zeitgesteuert, aber manuelles Schaltes soll dies ausser Kraft setzen. Gibt vllt auch Gründe, das man in einem Raum bewusst das Licht mal brennen lassen möchte.

Bin absolut bei dir, wird deswegen auch eingebaut
Ebenso die Möglichkeit, nach x Minuten ausschalten zu lassen (z.B. nach 2 Stunden) falls kein Trigger wie BWM mehr was auslöst, um Fälle abzudecken wie "der User ist eingeschlafen" Vermeidet dann auch Festbeleuchtung um 3:00 Uhr Nachts.

[e-s]

@crunchip
Hast du schon mal an einen drucksensor unter der toilettenbrille gedacht...

Aber sonst hast du schon recht, wenn man das licht an haben will, dann soll das auch an bleiben.

[crunchip]

@e-s ich lese nie auf der Toilette
aber ich saß schon am Esstisch, bzw das Kind am Hausaufgaben machen und zack war das Licht aus.

[Scrounger]

@Mic
sehr cooles Projekt
Da hast dir was sehr anspruchsvolles rausgesucht, hat das Potential das man iob doch irgendwann mal per maus "zusammen klicken" kann.

Folgende Namensvorschläge hätte ich:

• mySmartControl, mySmartHome, myIntelligentHome bzw. mySmartLiving
• Nett wäre auch myWifesShock

den Zusatz my fände ich sehr aussagefähig bzgl. "generic" bzw. das man es individuell konfigurieren kann.

Bzgl. Widgets kann ich gerne unterstützen bzw. ggf. im MDW noch passende Schnittstellen einbauen. Musst halt json strings zur verfügung stellen

[klassisch]

Sehr interessantes Thema, Bewegungsmelder.
Habe etliche BWM und auch Tür-Fensterkontaktsensoren (HM und 433MHz).
Allerdings sind bei mir die Lichtfunktionen schon weitgehen "hartverdrahtet" oder mit HM-Direktverknüpfungen umgesetzt. Zuverlässig, könnte aber noch komfortabler werden
Was ich noch brauchen könnte:

• Abhängigkeit der Schaltaktionen von
  • Astro
  • Helligkeitswert eines Helligkeitssensors
• Damit verknüpft eine Rampensteuerung der Dimmfunktion (speziell für Durchgangsräume): schnelles Andimmen, Haltezeit, Langsames Ausfaden mit der Möglichkeit per Taster wieder das Licht einzuschalten. Dieses realisiere ich derzeit mit einem Eltako EUD12D-UC was sehr gut funktioniert. Aber ich möchte von 230V LED auf 24V Stripes umstellen, z.B. mit Schelly o.ä.
  Mit dieser Erweiterung wäre es möglich nachts eine "wärmere" Lichtfarbe einzustellen als morgens und tagsüber.

Ferner nutze ich derzeit meine BWM und Türkontaktschalter mit einem selbstgeschriebenen holprigen JS Script

• Meldung (z.B. email) bei den ersten 3 Betätigungen pro Tag, die nach einer definierten Uhrzeit (z.B 06:30) erfolgen und mind. x Minuten Abstend haben.
• Zählen der Betätigungen pro Tag
  Und wenn diese Funktionen schon drin sind, dann könnte man die Wassermelder auch gleich mit reinnehmen (Benachrichtigung).
  Vielleicht passt so etwas noch in den Umfang des Adapters?

[siggi85]

Vielleicht noch ein Gedankenansatz:

1. Man kann ein Licht ja mit einer neuen Einstellung aufgrund eines Triggers starten lassen
2. Man kann aber auch zu gewissen Zeiten die Lichteinstellungen (Helligkeit, Lichtfarbe etc) setzen, OHNE das Licht hierbei anzuschalten. Also quasi die Lichteinstellungen nur proaktiv setzen.

Als Beispiel die Deckenbeleuchtung gesteuert über einen Shelly Dimmer: Hier möchte ich gerne, dass der Dimmer selber das Licht anmacht, um unabhängig vom zentralen System zu sein. Denn mindestens das Deckenlicht jeden Raumes soll in meinem Setup auch ohne zentrales System noch angehen können.
Beim Shelly Dimmer mit Shelly Adapter wird bspw. das Licht nicht automatisch angeschaltet wenn der Helligkeiswert geändert wird. Ich weiß nicht ob sich alle im ioBroker integrierten Lampen so verhalten.

Vielleicht kann man dies auch im Adapter berücksichtigen, gerade im Bezug auf zeitabhängige Lichteinstellungen. Gerade dieses ist für mich sehr interessant, da die Konfiguration über einzelne Blocklys sehr unübersichtlich ist.

[Ein ehemaliger Benutzer]

@Mic Klasse Idee, das würde viele Scripte ersetzen und die Wartung vereinfachen.

[Mic]

@Scrounger @klassisch @siggi85 @ilovegym

Danke für euer Feedback

@Scrounger
Super Namensvorschläge! myWifesShock gefällt mir am besten , aber wird wohl jetzt "mySmartControl". Wobei ich noch nicht sicher mit dem "my" bin, denn dann sollte man das ja an konsequenterweise an jeden Adapter-Namen dran hängen, der nicht nur als reiner "Verbinder" einer Hardware mit dem ioBroker dient. Mal sehen

Bzgl. Widgets kann ich gerne unterstützen bzw. ggf. im MDW noch passende Schnittstellen einbauen. Musst halt json strings zur verfügung stellen

Herzlichen Dank für dein Angebot!! Darauf komme ich sehr gerne im Bedarf dann zurück.

@klassisch
Danke für deinen Use Case. Ist notiert.

@siggi85
Danke, ebenso notiert.

[Mic]

Kurzes Update / Zwischenstand:
Bin aktiv an der Entwicklung, aber wie ich halt so dazu komme, habe relativ wenig Zeit, Dauert also noch etwas
Je mehr ich entwickle, desto mehr stelle ich das große Potenzial des Adapters und dieses Konzeptes fest, also später nicht mehr nur begrenzt auf Licht/Raumsteuerung etc., sondern auch ein einfach zusammen-klickbares "If This, Then That"mit optionaler Zeitsteuerung, etc..... Mal sehen, lassen wir uns überraschen

Accomplishments:

• User friendly Admin-Oberfläche steht. Hat mich viel Zeit gekostet, aber war es wert!
• Saubere input validation für die User-Angaben im Admin (z.B. ob Datenpunkte existieren, die angegebenen State-Values mit Type des Datenpunktes etc. übereinstimmen, usw.) für alle Konfig-Tabellen implementiert. Gekapselt in eine Function, daher gut skalierbar usw.
• Alles async/await und mit ES6 class, damit sauberer Code zustande kommt. Musste mich erst einarbeiten in die Thematik
• Verkettung/Abgleich der Config-Tabellen mit vielen Abhängigkeiten (in Kürze schwierig zu erklären, aber war sehr zeitintensiv)
• Vieles weitere.

Derzeitiger Entwicklungsstand: ca. 25% fertig. Jetzt fängt es an, Spaß zu machen mit den Logiken, etc.

[EdgarM]

Hi,

wenn du noch Ideen suchst, hier was ich mir gerade bastle:

abhängig von Tagesphase ändere ich die Werte, ob eine Lampe überhaupt angehen soll und welche Helligkeit sie haben soll. Falls ich viel Lust habe, werde ich die Farben bzw. Farbtemperaturen miteinbauen.

Außerdem baue ich in manchen Räumen ein automatischen Licht aus mit ein, je nachdem welche Tageszeit gerade ist oder ob z.b. die Luftfeuchtigkeit gestiegen ist ( also jemand duscht ).

Ich baue das aber aktuell einfach als javascript, da ich iobroker erst vor ein paar Wochen installiert habe und an einen Adapter hab ich mich noch nicht rangetraut.

Falls du Hilfe benötigst beim entwickeln könnte ich da wohl auch einiges machen.

grüße

[EdgarM]

und noch eins:

Wenn es einen Timer gibt, würde ich eine "Warnung" miteinbauen, also 10% der Zeit bevor es ausgeht das Licht kurz aus und wieder anmachen.

[sigi234]

@Mic sagte in Planung neuer Adapter: Licht-/Raumsteuerung und mehr:

Derzeitiger Entwicklungsstand: ca. 25% fertig. Jetzt fängt es an, Spaß zu machen mit den Logiken, etc.

Wie weit bist du jetzt?

[Mic]

@EdgarM Danke für deine Ideen/Vorschläge.

@sigi234
Sehr weit, größer 80%.
Sehr bald gibt es eine Erstversion zum Testen auf github. Zum Testen erzeugt der Adapter übrigens optional extra Datenpunkte unterhalb 0_userdata.0, damit man schön simulieren kann.

[Mic]

Ausblick / Konzept so weit:

Ein paar generelle Optionen:

Auslöser

Als erstes legt man Auslöser an, also Bewegungsmelder oder irgendwelche Geräte (Fensterkontakte, Wandschalter, Post im Briefkasten, etc.).

Zu schaltende Ziele

Dann legt man zu schaltende Ziele an. Auch hier beliebige Datenpunkte, und sowohl true/false als auch String möglich. Ebenso andere Datenpunkte zum ausschalten.

Bereiche

Als nächstes definiert man beliebig viele Bereiche, also z.B. Räume, Raumbereiche, oder auch nur den Briefkasten usw.
Den Bereichen ordnet man dann die Auslöser (Trigger) sowie die zu schaltenden Ziele zu, die man vorher definiert hat.

Bedingungen

Dann legt man noch ein paar Bedingungen an, also z.B. ob jemand anwesend, ob gerade Feiertag, die Eingangstüre offen, usw.

Schedule

Zum Schluss gehts zum "Schedule", also zur Planung, wann was geschaltet wird. Natürlich inklusive Astrozeiten, usw. Geschaltet wird dann auch nur, wenn die eingestellten Bedingungen zutreffen, z.B. "mindestens eine Person ist anwesend", oder "heute ist Feiertag".
Ebenso kann man Ausschlusskriterien auswählen, also wann nie geschaltet wird.

Zukunftsplanung, die es ggf. nicht in die erste Test-Version schaffen wird:
Als Auslöser nicht nur Bewegungsmelder, Wandschalter, Fensterkontakte etc. ermöglichen, sondern auch ein Zeiteintritt. Also z.B. (erste Spalte noch ein beliebiger Auslöser-Name, fehlt hier im Screenshot).

Löst dann auch diverse Scripts wie zur Weihnachtsbeleuchtung usw. ab. Auch diese Auslöser werden dann beliebigen Bereichen und Schedules zugeordnet, damit man das alles individuell und einfach konfigurieren kann.

[Mic]

Für die very, very, extremely early testers ist hier das Repo auf Github, hat soweit schon alles drin wie oben beschrieben, nur diverse Logiken noch nicht!!
Ich entwickle auch stetig weiter, und es wird hier noch Fehler geben, Errors im Log usw.
WARNUNG: also bitte nur in Testumgebung und mit Vorsicht. Das ist kein Aufruf zum testen, der folgt noch, sobald die erste Testversion fertig gestellt.
Die Errors etc. braucht ihr mir bitte nicht mitteilen, ich bin ja selber noch dabei

https://github.com/Mic-M/ioBroker.smartcontrol

[Chaot]

@Mic Das war mit Abstand die eindringlichste Warnung vorm Testen die ich hier je gelesen habe.

[Mic]

@Chaot
Haha
Tatsächlich sehe ich zu, dass ich bei der Entwicklung möglichst viele Fehler abfange, die User machen könnten bei Dateneingabe, also States die nicht existieren usw., sonst werde ich nicht mehr froh beim Support
Und vor allem auch, dass der ioBroker nicht irgend wann Nachts abschmiert, nur weil man ein Sonderzeichen im State oder in der Zeitangabe hat, usw., z.B. das wird schon beim Speichern der Admin-Konfig gleich geprüft.
Die Vorsicht deshalb tatsächlich, weil der Adapter auf diverse fremde States zugreift, und schaltet wie er meint dass "Schedule" zutrifft, dass könnte theoretisch schon bei einer Endlosschleife zu lustigen Effekten führen
Aber bitte keine Angst, ich berücksichtige das alles im Code und prüfe alles usw. bevor was ausgeführt wird.
Durchgehend async/await, solide Eingabevalidierungen usw. stellen das soweit sicher.

[FredF]

@Mic Das sieht schon sehr vielversprechend aus
Testen werde ich den Adapter auf jeden Fall, nur noch nicht in dem frühen Status

[sigi234]

@FredF sagte in Planung neuer Adapter: Smart Control:

Testen werde ich den Adapter auf jeden Fall, nur noch nicht in dem frühen Status

Dito, warte auch noch.