FHEM - Bessere Darstellung von Automatismen und Regeln [Diskussion]

Pythonf · 07 Oktober 2015, 18:02:06

Sehr geehrte FHEM-Freunde,

Ich wollte hier einen Diskussionsthread zum Thema der besseren Darstellung der Automatismen bzw Regeln in FHEM eröffnen. Vorweg möchte ich kurz erwähnen, dass es mir hier um eine Diskussion der verschiedenen Interessen geht. Die Programmierer/innen von FHEM und den vielen Modulen haben meinen größten Respekt und ich finde dieses Konzept super. Dass FHEM in erster Linie für engagierte Heimautomatisierer/innen gedacht ist und keine Plug-n-Play Lösung darstellen soll weiß ich und darum geht es mir hier auch nicht! Doch ohne ein wenig Kritik gibt es auch kein Weiterkommen.

Zu meinem eigentlichen Thema:
In der Hausautomatisierung geht es neben dem Ansteuern von Geräten auch um deren intelligente Automatisierung. Hier bietet FHEM ja viele Möglichkeiten (Notify, DOIF, at, Watchdog, ...etc.)
Und hier wurde auch mittels "Regexp wizard" bei notify und "Timespec wizard" bei at der Umgang hiermit nutzerfreundlicher gemacht.
Doch je mehr man automatisiern oder per DOIF/Notify verknüpfen möchte, desto unübersichtlicher wird das Ganze. Sicherlich ist eine intelligente Nomenklatur der Übersicht sehr zweckdienlich doch in einem Beispiel meiner FHEM Konfiguration habe Ich alleine 11 Notifys, welche alle mehr oder weniger den selben Inhalt haben und zum Schalten eines RGB-LED Stripes verwenden werden. Dies wirkt doch leicht unübersichtlich. (Wer sich fragt wieso so viele: HUE,SAT,BRI mit HM-Schalter über short und long).
Mein Gedanke hierzu wäre eine Art von FlowChart (kein komplett neues Frontend, hier gibt es ja viele z.B. Smartvisu) der alle mit einem Device verknüpften Notifys, DOIFs, at und co. anzeigt. Kurz erstellte Grafik zur Visualisierung
(http://fs5.directupload.net/images/151007/ovsowfyo.png)

Der Gedanke hierzu wäre dann, dass beispielsweise bei einem Moushover genauere Informationen angezeigt werden, und bei einem Klick wird dann auf den entsprechenden FHEM-Reiter "/fhem?detail=...." verlinkt. Vielleicht könnte man hier das ausgewählte Device im Vordergrund halten und weiter über 2 Wege oder mehr, bzw. garnicht verknüpfte Geräte schwach ausgegraut im Hintergrund halten.

Dies würde meiner Meinung nach einen Anreiz schaffen, mehr zu automatisieren und FHEM noch besser einzusetzen.
So - das waren meine Gedanken hierzu und jetzt bitte Ich um das Feedback der eingefleischten FHEM Nutzer.

Beste Grüße
Fabian

Pythonf · 08 Oktober 2015, 22:35:13

Gelesen haben es schon ein paar aber noch keiner hat sich getraut zu antworten. Ich habe mir derweil ein wenig Gedanken gemacht, wie man das ganze Umsetzen könnte, da meine Programmierkenntnisse allerdings nicht ausreichen würden, um so etwas auf die Beine zu stellen bräuchte ich hier Unterstützung. Und hier ist eben auch das Hauptproblem, denn wie Groß ist der Aufwand-Nutzen Wert.
Da es hier allerdings um eine grafische Veranschaulichung geht und nicht um eine Vereinfachung des eigentlichen Erstellens der Notifys und co. findet sich ja vielleicht doch jemand.
Ich hab mal versucht das ganze für das Beispiel eines Notifys grafisch darzustellen. Vom Programmieraufwand stell ich mir diesen Teil nicht mal so aufwändig vor, das herrausfordernde wäre sicherlich die Daten dann in einem Flowchart auch angezeigt zu bekommen.
(http://fs5.directupload.net/images/151008/cl37kize.png)
Falls das ganze hier nur ein sinnloser und aller Wahrscheinlichkeit nach niemals in die Tat umgesetzter Vorschlag ist dann traut sich bitte jemand darunter zu schreiben, was für einen Quark ich hier beschreibe.

Beste Grüße
Fabian

viegener · 08 Oktober 2015, 23:40:02

Bisher ist es ja noch relativ wenige Diskussion

also schreibe ich mal was dazu.

Ich hatte selbst mal so etwas überlegt, denn es gibt dazu eine Javascript library --> Blockly
https://developers.google.com/blockly/

Siehe dazu auch den Screenshot von der Blockly homepage:

(http://forum.fhem.de/index.php?action=dlattach;topic=41925.0;attach=38407)

Allerdings wäre der Aufwand wohl nicht unerheblich, deshalb habe ich bisher eher an anderen Baustellen gearbeite. Durch die unterschiedlichen Frontends, müsste man auch am ehesten eine Einbindung in fhemweb vorsehen, damit das ganze möglichst viele erreicht.

Interessant wäre der Ansatz sicher, denn ich habe noch keine halbwegs elegante Lösung gefunden, um komplexe DOIF's zu bearbeiten.

steffen83 · 06 März 2017, 11:46:34

Hallo,

wurde dieses Thema eigentlich "beendet" oder entwickelt man hier noch weiter? Wollte es mal wieder in den Vordergrund heben

Gruß
Steffen

fstefan1960 · 06 März 2017, 11:58:10

Abgesehen davon, dass ich mangels entsprechender Kenntnisse dazu nichts beitragen kann, zeigen mir die Flowcharts z.B. in Automagic -> Android App, wie schnell so etwas dann auch sehr unübersichtlich werden kann.

Was mir schon immer sehr hilft, ist unten beim Device die verlinkte Anzeige, mit welchen anderen Devices (also auch Regeln) etwas verknüpft ist.

justme1968 · 06 März 2017, 16:53:25

zu blockly: ich habe mir das intensiv für diverse anwendungen in fhem angeschaut und versucht das am beispiel des statemachine moduls einzubauen.

das ganze scheitert daran das es keine sinnvolle möglichkeit gibt aus dem von blockly generierten (und dann eventuell auch noch manuell geänderten) code wieder ein blockly diagramm zu erzeugen um später daran weiter zu arbeiten.

das ganze ist im prinzip eine einbahnstraße blockly -> code und man muss immer die blockly xml repräsentation mit schleifen und änderungen nur daran durchführen/erlauben. nach jeder änderung muss dann der code neu erzeugt werden. das ganze ist für etwas komplexere aufgaben nur sehr eingeschränkt geeignet.

größere charts werden auch schnell noch unübersichtlicher als der zugehörige code es wäre.

so schön es auf den ersten blick ausschaut so unpraktisch ist es auf der code ebene.

wenn man etwas in dieser richtung weiter verfolgt wäre es vermutlich besser nur eine oberste ebene damit abzubilden so wie z.b der node red dashboard editor. gui elemente mit readings verknüpft.

viegener · 06 März 2017, 20:39:32

Generell ist das mit dem fehlenden Rückweg sicher eine Einschränkung, es gibt aber vielleicht auch Benutzer, die nie auf der Code-Ebene arbeiten wollen und damit völlig zufrieden wären.

Wenn ich die Anfängerfragen und auch meine eigene Erfahrung betrachte, dann gibt es eine Reihe von "klassischen" Ecken an denen Schwierigkeiten auftreten und bei denen wir für Nicht-Programmierer / NIcht-Nerds

Vereinfachungen machen könnten

- Regular Expressions
- notify, watchdog und ähnliches
- DOIF
- Tablet UI

Es gibt aber auch Themen bei denen auch mehr profitieren würden

- Automatisches Anlegen von devices - so eine Art Autocreate++ ?
- Grundeinstellungen - Backup
- dummys mit Verknüpfungen
- ReadingGroups

Wie gesagt, das ist jetzt nur eine Erweiterung des Themas auf grundsätzliche Vereinfachungen, denn es erscheint mir schon so, dass die Einstiegshürde für FHEM höher ist als sie sein sollte.

justme1968 · 06 März 2017, 21:29:29

selbst wenn ein user nichts am erzeugten code ändert muss man trozdem von hand einen parser von code zurück nach blockly implementieren. oder immer und überall das blocky xml format mit schleppen. und irgendwann gibt es probleme weil es unerschiedliche meinungen dazu gibt welches von beiden vorangegangenen hat. und blockly wird wirklich unübersichtlich wenn man mehr als 10 elemente verknüpft die auch noch parameter haben können.

das problem mit dem vereinfachen sehe ich so:
- 'einfache' dinge vereinfachen ist einfach. die machen aber den meisten keine probleme
die vereinfachung so zu machen das sie auch für komplizierte dinge hilft wird exponentiell schwieriger.
wenn es aber einen bruch gibt ist es besser es gleich zu lassen und von anfang an zu lernen wie es geht.
das ist besser als ein system das mit 80% aufwand doch nur 20% abdeckt.

- bei einem 'kommerzielles' produkt bei dem jemand anordnet xy muss so einfach sein das es jeder
bedienen kann kommt das ganze auf den entwicklungsplan und es wird fürher oder später gemacht.
bei fhem wo jeder sich die ecke zum entwickeln sucht die ihm gefällt muss sich jemand finden der so
etwas freiwillig angeht, es umsetzen kann und etwas abliefert das die anderen überzeugt. die meisten
stecken ihre energie vermutlich lieber in die eigentliche funktionalität.

- selbst diese systeme stossen oft an ihre grenzen wenn man das nur halb herzig umsetzt. siehe z.b.
die 'programmierung' komplexerer dinge in der ccu.

für tabletui könnte ich mir sehr gut etwas vorstellen das mit drag&drop arbeitet. der aufwand wäre zwar auch groß, aber zumindest auf den ersten blick wäre es einfacher als perl code wieder zurück zu blockly zu parsen.

zum autocreate++: zumindest für netzwerk fähige geräte die sich auf irgendeine art automatisch erkennen lassen bin ich dabei etwas in diese richtung zu versuchen. dauert aber noch. siehe die diskussion hier: https://forum.fhem.de/index.php/topic,67368.0.html.

viegener · 06 März 2017, 22:08:09

Zitat von: justme1968 am 06 März 2017, 21:29:29
selbst wenn ein user nichts am erzeugten code ändert muss man trozdem von hand einen parser von code zurück nach blockly implementieren. oder immer und überall das blocky xml format mit schleppen. und irgendwann gibt es probleme weil es unerschiedliche meinungen dazu gibt welches von beiden vorangegangenen hat. und blockly wird wirklich unübersichtlich wenn man mehr als 10 elemente verknüpft die auch noch parameter haben können.

das problem mit dem vereinfachen sehe ich so:
- 'einfache' dinge vereinfachen ist einfach. die machen aber den meisten keine probleme
die vereinfachung so zu machen das sie auch für komplizierte dinge hilft wird exponentiell schwieriger.
wenn es aber einen bruch gibt ist es besser es gleich zu lassen und von anfang an zu lernen wie es geht.
das ist besser als ein system das mit 80% aufwand doch nur 20% abdeckt.

- bei einem 'kommerzielles' produkt bei dem jemand anordnet xy muss so einfach sein das es jeder
bedienen kann kommt das ganze auf den entwicklungsplan und es wird fürher oder später gemacht.
bei fhem wo jeder sich die ecke zum entwickeln sucht die ihm gefällt muss sich jemand finden der so
etwas freiwillig angeht, es umsetzen kann und etwas abliefert das die anderen überzeugt. die meisten
stecken ihre energie vermutlich lieber in die eigentliche funktionalität.

- selbst diese systeme stossen oft an ihre grenzen wenn man das nur halb herzig umsetzt. siehe z.b.
die 'programmierung' komplexerer dinge in der ccu.

für tabletui könnte ich mir sehr gut etwas vorstellen das mit drag&drop arbeitet. der aufwand wäre zwar auch groß, aber zumindest auf den ersten blick wäre es einfacher als perl code wieder zurück zu blockly zu parsen.

zum autocreate++: zumindest für netzwerk fähige geräte die sich auf irgendeine art automatisch erkennen lassen bin ich dabei etwas in diese richtung zu versuchen. dauert aber noch. siehe die diskussion hier: https://forum.fhem.de/index.php/topic,67368.0.html.

Das mit den einfachen Dingen, das die meisten Leute hinbekommen ist relativ - Ich sehe die Leute schon am Erstellen eines Regexp für ein einfaches notify scheitern - nicht zu reden von gefühlten 1000mal warum funktioniert mein ELSEIF nicht aktiviert

DOIF wäre sicher mit all seinen Möglichkeiten sehr komplex aber notify (und vielleicht mit IF)

Ja ich stecke meine Energie auch lieber in Funktionalität sonst hätte ich mal fürs TabletUI angefangen, aber javascript ist auch nicht mein Spezialgebiet (wobei perl eigentlich auch nicht )

Achso und Danke für die andere Diskussion - die ist genau in die Richtung !!

Pythonf · 06 März 2017, 22:38:40

Ich möchte hierzu als OT auch noch etwas hinzufügen. Mittlerweile bin ich mit FHEM besser vertraut aber der Gedanke das ganze System übersichtlicher zu machen verfolgt mich immer wieder. Der Ansatz über Blockly scheint nicht realistisch zu sein aber eventuell der Weg über MQTT und Node-Red. Ob das allerdings dem FHEM-Einsteiger weiter helfen würde sei mal dahingestellt.
Zum Thema Übersichtlichkeit:
Ich habe mich lange Zeit mit Programmen für digitale Effekte wie Beispielsweise Nuke (Beispiel), Autodesk Flame oder Fusion beschäftigt. Sicherlich alles Programme die ein gigantisches Entwicklungsbudget mit sich bringen aber deren Komplexität die von FHEM meiner Meinung nach deutlich überschreiten und all diese Programme basieren auf Nodes und sind häufig bei vielen beliebter als Programme, die einen andere Herangehensweise haben. Mittlerweile bin ich auf einem anderen Gebiet unterwegs und auch hier wird im professionellen Bereich Software eingesetzt welche auf Nodes basiert (LabView).
Ich bin deshalb immernoch der Meinung, dass eine grafische Orientierung der Haussteuerung die Übersichtlichkeit erleichtern würde, selbst dann wenn es nur drei Nodes wie Schalter A - Notify - Lampe B wären.
Das nun das Notfiy mit dem selben Inhalt "gefüttert" werden muss wie es bisher auch schon der Fall ist würde ich nie abändern wollen, da gerade hier ja der Vorteil von FHEM gegenüber in sich abgeschlossenen Systemen besteht. Natürlich könnten vereinfachte Versionen zur schnelleren Verknüpfung entstehen wie es auch jetzt schon der Fall ist (vgl. notify <> DOIF). Aber ich könnte einfacher die Verknüpfungen erkennen. Entweder zwischen zwei Geräten verschiedener Module oder Beispielsweise für Homematic ob ein Peering funktioniert hat (Doppelpfeil) oder eben nur an einem Gerät angekommen ist (Einfacher Pfeil).
Ob und wie das ganze umsetzbar wäre steht auf einem anderen Blatt aber Vorteile sehe ich selbst bei deutlich komplexen Systemen immernoch. Des Weitern nehme ich auch an, dass nicht immer ein Gerät mit einer großen Anzahl an weiteren Geräten verknüpft ist, sondern das häufig von einander getrennte "Bäume" entstehen würden die eben getrennt betrachtet werden könnten.

Beste Grüße
Fabian

justme1968 · 06 März 2017, 22:52:15

nur kurz zum beispiel der nodes bzw. der beispiele oben für effekte, autodesk, ...

ein haupt unterschied zu fhem ist das bei deinen beispielen relativ wenig datentypen über viele unterschiedliche verkette module modifiziert werden. bei fhem ist es aber umgekehrt. viele unterschiedliche events werden über relativ wenige module miteinander verknüpft.

das hat zur folge das die einzelnen nodes/verknüpfungen nicht nur die parameter und einstellmöglichkeiten für den jeweiligen effekt brauchen sondern auch noch paramter und einstellmöglichkeiten um sie an die vielen ein- und ausgabe formate anzupassen. im gegensatz zu deinen beispielen bei denen jeder node wenige oder auch viele parameter um sein verhalten zu beeinflussen hat aber ein- und ausgabe sind aber weitgehend standardisiert ist.

ich glaube dieser unterschied macht die herausforderung aus und ist der grund warum die analogie nur sehr ungenügend zutrifft.

jedes neue fhem modul mit anderen readings (und ohne die metainformation was sie bedeuten) erfordert anpassungen an den node und deren konfiguration.

den nodes in einer audio oder bild bearbeitung ist im gegensatz dazu der inhalt der daten völlig egal. es sind immer audio (oder bilddaten) in einigen wenigen standard formaten.

der 'einfache' schalter muss halt für homematic, enocean, zwave, ... funktionieren die nicht alle einfach nur on und off verwenden. und sobald es mehr ist wie ein schalter (dimmer, rollladen aktor) wird es ganz plötzlich sehr kompliziert wenn auch damit umgehen will. das gleiche gilt für lampen. da gibt es halt mehr als nur ein und aus. dimmen, farben, ...

Thorsten Pferdekaemper · 08 März 2017, 12:58:09

Hi,
interessante Diskussion hier. Da würde ich gerne auch etwas beitragen.
Zuerst einmal zu dem Thema "programmieren ohne zu programmieren": (Ich meine damit den Versuch, Programme irgendwie grafisch zu "schreiben".)
Meiner Meinung nach ist das nur gut für Software-Firmen, die ihr Produkt damit einfacher verkaufen können. Der Grund ist der, dass diejenigen, die die Entscheidung über den Kauf fallen, oft keine Ahnung vom programmieren haben und deswegen glücklich seind, dass man nicht programmieren muss. Diejenigen, die das ganze dann einrichten müssen, sind dann die Dummen, weil es halt doch nicht so einfach ist. Der grafische Kram macht es dann oft noch schwieriger. Wie schon gesagt: Das ist nur für die einfachen Sachen geeignet, aber einfache Sachen sind eh einfach.

Was meiner Meinung nach tatsächlich interessant wäre, ist ein "Dokumentationstool". Also so in etwa: Man drückt in FHEM einen Knopf und dann wird automatisch ein PDF (oder so) erzeugt, dass die ganzen Devices mit ihren Verknüpfungen (auch Peerings bei HM) und zugehörige Parameter enthält. Natürlich ist das alles auch in FHEM selbst enthalten...

Zu Verknüpfungen und ihren Parametern: Ich bin gerade dabei, das für HM-Wired aufzuhübschen. Da läuft es so: Man macht ein Peering zwischen zwei Kanälen. Einer der beiden Kanäle definiert, welche Parameter das Peering haben kann. Dazu gibt es dann einen eigenen Dialog, der aus diesen Parametern generiert wird. D.h. so ziemlich Klickibunti, man muss keine komplizierten "set"-Kommandos eingeben. (Wenn das jemand interessiert, dann zeige ich mal ein paar Screenshots.)
Das ganze ist momentan natürlich nur für HM-Wired, aber ich glaube, dass man ein allgemeines Konzept daraus machen kann. Man erreicht damit nicht die Mächtigkeit eines allgemeinen notify oder so, aber ein paar Sachen könnten so gehen: Man verknüpft erst einmal zwei Devices, dann darf jedes Device sagen, was man an der Verknüpfung konfigurieren kann und daraus wird dann ein Verknüpfungs-Parameter-Dialog generiert. (Keine Ahnung, ob man sowas wirklich braucht...)

Übrigens: Ich erinnere mich gerade an eine Diskussion zwischen rudolfkoenig und betateilchen, notifies direct aus dem Event-Monitor heraus zu generieren. Also nach dem Motto: Event im Monitor finden, draufklicken und schon ist die erste Hälfte des notify gemacht. Ich weiß aber nicht, wie weit as gediehen ist.

Zum Tablet-UI: Ich könnte mir vorstellen, dass man aus dem, was man eh schon in FHEM hat, ein Tablet-UI generieren kann. Man hat Räume und die verschiedenen Devices. Daraus müsste man ein Standard-UI machen können. Darauf aufbauend kann man das dann konfigurierbar machen. ...wie oben: Nicht die volle Mächtigkeit, aber einfaches einfach.

Gruß,
Thorsten

rudolfkoenig · 29 März 2017, 10:36:26

ZitatÜbrigens: Ich erinnere mich gerade an eine Diskussion zwischen rudolfkoenig und betateilchen, notifies direct aus dem Event-Monitor heraus zu generieren. Also nach dem Motto: Event im Monitor finden, draufklicken und schon ist die erste Hälfte des notify gemacht. Ich weiß aber nicht, wie weit as gediehen ist.

Das gibt es seit ein paar Wochen, bisher ist wohl keinem negativ aufgefallen (will sagen, habe keine Probleme dazu gehoert).
Fuer die zweite Haelfte gibt es auch schon was: in der notify Detailansicht kann man ein einfaches set auch per dropdown definieren.

D.h. fuer das Anlegen eines notifies wie "define Schalter_notify_1 notify Schalter:on set Lampe on" muss man die Tastatur nicht anfassen, es reicht das Event Monitor und "Create/modify device" zu finden.