Hallo,
was sowohl blutigen Anfängern als auch eingefleischten FHEM-Anhängern das Leben stark vereinfachen würde ist ein dialoggeführtes Erstellen von defines. Vorbild wäre das "Create_SVG_Plot" innerhalb von Filelog.
Bei einem define notifiy könnte das so gehen:
- Unterstützung bei der Auswahl des richtigen Readings durch Analysieren des Event-Monitors und anbieten der möglichen Events wie es schon länger beim gplot-Tool angeboten wird. Möglichst auch mit sinnvollem setzen der Wildcards.
- Einfügen eines set-Devices aus einer Liste von möglichen Geräten
- Anbieten der passenden CMDs on/off, up/down, etc.
- erzeugen eines eindeutigen Namens für das define: notify_Lampe7_an_mit_Schalter9_Button3
Suchen würde ich diese Funktion auf der Detailseite der Geräte unterhalb
Select icon
Extend devStateIcon
Device specific help
"define notify erstellen"
"define at erstellen"
von hier aus gestartet wäre ein Teil des defines auch schon festgelegt.
oder gibt es so etwas schon und ich habe es nur übersehen?
hat meine Unterstützung ;) wurde absolut das Leben erleichtern
markus
Fänd ich eines super Sache
Hallo,
für ein
define Lampe_aus at +*22:35:00 set Lampe auswollt ihr einen Wizard ???
Naja, FHEM hat ja sonst keine "Baustellen".
Grüße
Sehe ich wie Puschel. Überflüssig bis kontraproduktiv (der Anwender versteht dann immer weniger von den System).
Vielleicht waere eine Art "Setzkasten" zum Erstellen von Defines, attrs usw... die Arbeit eher wert.
Es ist nun mal nicht Jedermanns Sache sich mit Befehlen und dergleichen herum zu schlagen.
Man koennte seinen Setzkasten aus einer Reihe dropdown Feldern erstellen.
Wenn man define auswaehlt koennte man danach gleich ein leeres Feld fuer den Namen, dann ein dropdown mit der Art des defines usw... anbieten.
Wenn man ein attr auswaehlt entsprechend die vorhandenen definierten Geraete zu denen ein attr moeglich ist.
Das wuerde es wohl einfach bequemer machen. Ja ich weiß wir sind nicht wegen der bequemlichkeit bei fhem gelandet, aber je groesser die Community wird, desto groesser auch die Zahl derer, die bequemlichkeit haben moechten. Ohne das Streben nach Bequemlichkeit gaebe es wohl auch kein fhem ;)
Markus
Aber es ist doch nicht bequem, wie bei deinem Vorschlag in einem Dropdown aus mehreren 100 Entities zu wählen (und die hat eine FHEM Installation sehr schnell). Ich sehe hier zu einem normalen Define überhaupt keinen Bequemlichkeitsvorteil. Es ist schon jetzt unglaublich bequem, in die Kommandozeile etwas wie
define not-001-IRGENDWAs notify IRENDWASANDERES {}
einzugeben und dann im DEF des Devices mit dem Javascript-Editor (in dem es ja Hilfen, wie das Anzeigen der Devices gibt) den Rest zu machen.
ob das bequem ist? das ist Ansichtssache ;)
nicht ohne Grund hat sich die GUI durchgesetzt.
vielleicht wäre auch etwas analog einer Suchhilfe eine Idee? die beim tippen der Befehle Vorschläge gibt?
Nein. Dropdowns mit mehr als 10 Einträgen haben sich nicht "durchgesetzt" ;)
Eine Eingabehilfe für die Kommandozeile in FHEMWEb wurde hier schon einmal irgendwo diskutiert. Da ging es darum, den Javascript-Editor, der ja die von die erwähnten Vorschläge kann, dort zu integrieren.
Zitat von: marvin78 am 27 September 2014, 08:03:15
define not-001-IRGENDWAs notify IRENDWASANDERES {}
Dafür muss man aber hat genau wissen was die einzelnen Befehle auslösen und wie genau die Syntax sein muss. Tu mir da oftmals schwer mit, von daher halte ich das schon für eine bedienungs Erleichterung .....
Hallo,
für Attribute gibt es das doch bereits ???
Macht mal ein update - wie alt ist eure Installation ::)
Und da ich nicht täglich code oder Codes umbaue benötige ich diese "Erleichterung" zum Glück nicht.
Aber wie oben schonmal erwähnt - es schadet nicht wenn man den Syntax kennt und kann.
Wer Bequemlichkeit will soll sich ne CCU kaufen :P
Und das obwohl ich die Teile nichtmal kenne ;D
Aber wenn einer von euch sich berufen fühlt so eine "Erleichterung" zu programmieren --- haut in die Tasten Jungs das der Code glüht 8)
Grüße
Edith: Es wird NIE eine mitdenkende Erleichterung geben können - um den Syntax werdet ihr euch immer selbst kümmern müssen.
Ein Dilemma: die Leute, den 'Code liegt', brauchen das nicht. Und diejenigen, den 'Code nicht liegt', können wohl nicht programmieren. ;D
Zitat von: hexenmeister am 27 September 2014, 09:22:46
Ein Dilemma: die Leute, den 'Code liegt', brauchen das nicht. Und diejenigen, den 'Code nicht liegt', können wohl nicht programmieren. ;D
Das ist das Problem:-( :-)
Es wird ein Designer gebraucht, der beide Seiten überzeugt. :)
Problem as desinged nennt man das glaube ich? :)
FHEM ist schließlich nur für Bastler und nicht für NurBenutzer gedacht! ;)
Hallo,
Zitat von: punker am 27 September 2014, 13:32:01
FHEM ist schließlich nur für Bastler und nicht für NurBenutzer gedacht! ;)
Wenn man sich die Beiträge im Anfängerbereich und in den diversen Unterforen so ansieht dann - ja, FHEM ist für Bastler gedacht und noch weit weg um auch "NurBenutzer" zufrieden stellen zu können.
Den auch der "NurBenutzer" muss sich leider mit der Technik auseinander setzen und sich den Syntax von FHEM und Perl (wenn nötig) aneignen.
Daher hab ich vorher ja auch geschrieben:
ZitatWer Bequemlichkeit will soll sich ne CCU kaufen
mWn braucht man sich bei Verwendung einer CCU nicht um einen Syntax kümmern - kann allerdings auch NUR Homematic verwenden.
Der Preis der Vielfältigkeit ist leider die Komplexität.
Grüße
Sowas wie vorgeschlagen hatte ich vor zwei-drei Jahren vorgesehen, es gab im Frontend Links unten ein "Define Device" (oder so), ich habe es aber wegen fehlender Motivation nach einem Jahr wieder ausgebaut.
Der Click auf "Define Device" hat eine Liste von Modulen angeboten, und beim Click auf dem Modul waere erstens eine im Modul programmierte Maske gekommen, um die Definition zu erleichtern, und darunter die Dokumentation des Moduls. Die fuer sowas bei notify benoetigte Liste aller Events wird mit eventType seit Version 5.5 auch gesammelt.
Ich wäre sehr auf einen Wizard gespannt, der mir ein solches Ergebnis liefert, ohne dass ich als Benutzer dabei nachdenken muss...
define cal_SwitchHeizungOn notify Kalender_Heizung:modeStarted.* { calHeizungStart($EVENT) if(ReadingsVal('heizperiode','forceOn',(!($month ~~ [4..9]))))}
Und wenn ich bei der notify-Erstellung ohnehin nachdenken muss, brauche ich einen Wizard auch nicht 8) Ich finde perl Syntax jedenfalls sehr viel logischer und "handlicher" als irgendwelches Rumgeklicke in der Weboberfläche.
Da ist natuerlich der Wizard des DOIF Moduls von Damian gefordert. :)
Wenn die Sache komplexer wird, dann steht ein Wizard immer im Weg: ich musste schon mehrere Projekte, die mit grafischer Programmierung angefangen haben (Stichwort ETL) mit einem "richtigen" Programm retten.
Bei einfachen Problemen koennen Wizards aber manchen Leuten helfen, und uns den Supportaufwand ersparen, siehe SVG-Editor oder FileLog-Erweiterung. Mwn gibt es aber keine weiteren Wizards in FHEM.
Idealerweise hat man beide Moeglichkeiten, und der Wizard generiert Code, was man erweitern kann.
Hallo,
danke für dein Beispiel betateilchen 8)
ZitatIdealerweise hat man beide Moeglichkeiten, und der Wizard generiert Code, was man erweitern kann.
Und spätestens beim erweitern MUSS man sich mit dem Syntax rumschlagen - und nur für das define braucht es den Wizard nicht.
Das define ist idR (vom regexp mal abgesehen) das einfachste des "Codes".
Weiters würde sich ein Wizard maximal für Einzeiler anbieten - alles was länger wird sollte sowieso in eine pm (ist hier immer zu lesen ::) ).
Und da kann ein Wizard nicht wirklich helfen (vermute ich mal).
Das anlegen eines Device wird doch grösstenteils schon per Wizrad (autocreate) erledigt.
Ich bin ja auch gar nicht gegen so einen Wizard.
Es muss sich nur jemand finden der das macht und programmiert.
Ihr - ich mein jetzt Rudi, betateilchen, Boris, pah und alle die "für" FHEM programmieren - sind mMn bereits soweit gebunden das keine Zeit für einen Wizard bleibt.
Das Privatleben soll ja nicht zu kurz kommen.
Wenn sich also sonst jemand findet dann will gerade ICH demjenigen die Arbeit sicher nicht madig machen.
Nur zu und legt los - ich kanns leider nicht.
Ich bin schon froh das meine Installationen das tun was sie sollen -
von das tun was ich will mal abgesehen ;DGrüße
Hm,
ich finde die Idee eines Wizards gar nicht dumm.
Nur wenn er quasi bei 0 Anfangen muss, wird es schwierig.
Imho haben komplexere Programme für derartige Fälle Templates. Quasi einen fest vorgegebenen Lösungsweg (der durchaus auch komplex sein kann!), dessen Befüllung mit den nötigen Parametern dem User vereinfacht wird.
Ich nehm jetzt als (halb) passendes Beispiel den Windows Task Scheduler. Das geht bequem über klicki bunti, man kann ihn auch von Hand programmieren.
Fhem bräuchte also eine Art Skript-Sprache, um Templates abbilden zu können.
aus dem Cisco-Umfeld ist man beispielsweise gewohnt, dass man sich nach jedem Befehlsteil mit "?" die weiteren moeglichen Kommandos anzeigen lassen kann.
bei Null anfangen ist aber oft, wie der Vorrednet schon sagte, sehr kompliziert. Besonders wenn man mal n paar Monate nichts gemacht hat und dann nicht mehr so firm mit der Sache ist.