FHEM - Erweiterung - Baukasten

[Guest]

Originally posted by: <email address deleted>

Hallo zusammen!

Ich schaue mir regelmässig auch andere
Hausautomationsysteme/Server/Visualisierungen an.
Dabei fällt mir immer häufiger auf, das FHEM eine leichtere
Konfigurationsoberfläche unbedingt nötig hätte.

Nicht jeder kennt Perl so gut und ist in der Lage simple UND-/ODER-
Verknüpfungen oder Zeiten (at) direkt in der Config zu bearbeiten.

Uli hatte in der Floorplan - Erweiterung eine tolle Vorlage für ein Menu
geschaffen (die Dropdown Menu Auswahlbox).


Nun wäre meine Idee also FHEM soweit aufzubohren, dass entweder durch eine
weitere Seite in FHEM solche Kommandos bequem eingegeben und gemanaged
werden können.

Beispiel

 + (eventuell weitere Bedingungen bsp.ZEIT/Intervall usw ) =
Aktion

dieses müsste dann in einer Tabelle dargestellt werden und ggf. mit einem
Tastenklick editierbar oder zu löschen sein.
Schon bei der "AT" Abfrage fände ich solch eine Auflistung grafisch sehr
sinnvoll, da sie der Übersichtlichkeit dient WAS/WANN geschieht.

--->>> Bitte diesen Thread mal zum Ideen sammeln ansehen!!!!


/Sascha

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich habe in den letzten Wochen ein Konzept für quasi eine YAW (Yet Another
Webinterface) zusammengeschrieben, die allerdings nicht auf FHEM speziell
abzielt sondern auch XBMC etc. ebenfalls ansprechen soll und speziell drauf
abzielt Schalter durch Oberflächen auf Touch-Interfaces (wie zB einem
eingebautem iPod/Mediaplayer) zu ersetzen.

Das Konfigurationsinterface soll zB auch Assistenten anbieten um Devices in
FHEM zu konfigurieren.

2012/3/12 Sascha Reuthe

> Hallo zusammen!
>
> Ich schaue mir regelmässig auch andere
> Hausautomationsysteme/Server/Visualisierungen an.
> Dabei fällt mir immer häufiger auf, das FHEM eine leichtere
> Konfigurationsoberfläche unbedingt nötig hätte.
>
> Nicht jeder kennt Perl so gut und ist in der Lage simple UND-/ODER-
> Verknüpfungen oder Zeiten (at) direkt in der Config zu bearbeiten.
>
> Uli hatte in der Floorplan - Erweiterung eine tolle Vorlage für ein Menu
> geschaffen (die Dropdown Menu Auswahlbox).
>
>
> Nun wäre meine Idee also FHEM soweit aufzubohren, dass entweder durch eine
> weitere Seite in FHEM solche Kommandos bequem eingegeben und gemanaged
> werden können.
>
> Beispiel
>
>  + (eventuell weitere Bedingungen bsp.ZEIT/Intervall usw ) =
> Aktion
>
> dieses müsste dann in einer Tabelle dargestellt werden und ggf. mit einem
> Tastenklick editierbar oder zu löschen sein.
> Schon bei der "AT" Abfrage fände ich solch eine Auflistung grafisch sehr
> sinnvoll, da sie der Übersichtlichkeit dient WAS/WANN geschieht.
>
> --->>> Bitte diesen Thread mal zum Ideen sammeln ansehen!!!!
>
>
> /Sascha
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hört sich interessant an. Wäre sicherlich für Anfänger sinnvoll so etwas zu
haben.

@drdownload und Berlin_Fhemming: Wann wollt Ihr es implementieren?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Na, dann schaut mal auf
https://groups.google.com/forum/?fromgroups#!topic/fhem-developers/F9-cZBddBTc

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Das klingt ja wirklich interessant, allerdings weicht es doch vom
"Baukasten"-Prinzip der Automatisierung ein wenig ab.
Dass du die Oberfläche dynamisch "...ohne Reload" gestalten lassen möchtest
klingt sehr verlockend, aber ich dachte hier mehr an Auswahlmenüs (Rezepte)
um einfach und Übersichtlich die Verknüpfungen dem normalen User
offenzulegen.
Die fhem.cfg ist -wie schon gesagt- nicht für jeden das richtige Mittel zum
Ziel.

Ebenso würde ich mir eine Tablelle der Zeitgesteuerten Aktionen wünschen um
dort eine klare Übersicht zu haben. Dahinter evtl noch ein Edit und Löschen
-Button....


DAS wäre was feines.


/Sascha


2012/3/13 Prof. Dr. Peter A. Henning

> Na, dann schaut mal auf
> https://groups.google.com/forum/?fromgroups#!topic/fhem-developers/F9-cZBddBTc
>
> LG
>
> pah
>
>
>  --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Puschel74]

                                               

Juhuu,

gibt es endlich ne Klicki-Bunti Umgebung mit der auch ich mein FHEM
bedienen kann??
Ne Scherz beiseite.
Tolles Projekt Hr. Professor.
Das würde sich so mancher Student wünschen machen zu dürfen.

Ich würde aber vorschlagen (Programmieren kann ich nicht aber testen
gerne) das ihr erstmal auf ein Pferd setzt
und nicht jeder das Rad neu erfinden versucht.
Gemeinsam kommt ihr evtl. schneller ans Ziel.
Aber das nur meine Meinung.

Wie gesagt wenn ihr ein Versuchskaninchen braucht teste ich gerne.

Grüße

On 13 Mrz., 06:45, "Prof. Dr. Peter A. Henning"
wrote:
> Na, dann schaut mal aufhttps://groups.google.com/forum/?fromgroups#!topic/fhem-developers/F9...
>
> LG
>
> pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich bin leider diese Woche noch seehr eingespannt, aber ab Freitag werde
ich mein Konzept ergänzen und hier reinstellen. Mein Ansatz ist aber wie
gesagt nicht für FHEM alleine (wenngleich natürlich FHEM erstmal die
Kernanwendung sein wird) und hätte noch einen Layer dazwischen um FHEM
nicht mit Dingen vollzumüllen die nichts mit Heimautomatisierung zu tun
haben.

Ziel des ganzen ist aber nicht programmatische Eleganz sondern
Time-to-market

2012/3/13 Sascha Reuthe

> Das klingt ja wirklich interessant, allerdings weicht es doch vom
> "Baukasten"-Prinzip der Automatisierung ein wenig ab.
> Dass du die Oberfläche dynamisch "...ohne Reload" gestalten lassen
> möchtest klingt sehr verlockend, aber ich dachte hier mehr an Auswahlmenüs
> (Rezepte) um einfach und Übersichtlich die Verknüpfungen dem normalen User
> offenzulegen.
> Die fhem.cfg ist -wie schon gesagt- nicht für jeden das richtige Mittel
> zum Ziel.
>
> Ebenso würde ich mir eine Tablelle der Zeitgesteuerten Aktionen wünschen
> um dort eine klare Übersicht zu haben. Dahinter evtl noch ein Edit und
> Löschen -Button....
>
>
> DAS wäre was feines.
>
>
> /Sascha
>
>
> 2012/3/13 Prof. Dr. Peter A. Henning
>
> Na, dann schaut mal auf
>> https://groups.google.com/forum/?fromgroups#!topic/fhem-developers/F9-cZBddBTc
>>
>> LG
>>
>> pah
>>
>>
>>  --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>
>  --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Ebenso würde ich mir eine Tablelle der Zeitgesteuerten Aktionen wünschen um
> dort eine klare Übersicht zu haben.

Das kann man mit "list TYPE=at" auch haben
Jaja, ich weiss, delete/edit/usw fehlt.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Es geht doch darum, kombinatorische oder gar sequentielle Logik per
"rumklicken" zu erzeugen. Das versucht eq-3 bei der Homematic mit ihrem
WEbinterface ja auch und das ist suboptimal aber für viele reicht es halt.
Vll kann man sich insofern daran orientieren (nicht klauen!) dass man sich
anshaut welches Konzept dahinter steckt und was die Stärken und Schwächen
davon sind.

Da das die meisten Anwender brauchen wäre es vll ein guter Anfang zuerst
einmal sich nur darauf zu konzentrieren, wie man eine Zeitsteuerung per
Mausklick einbaut. Also wie definiere ich mit möglichst viel Flexibilität
regelmäßige Aktionen (define ... at) .

VG

Am Dienstag, 13. März 2012 08:06:04 UTC+1 schrieb puschel74:
>
> Juhuu,
>
> gibt es endlich ne Klicki-Bunti Umgebung mit der auch ich mein FHEM
> bedienen kann??
> Ne Scherz beiseite.
> Tolles Projekt Hr. Professor.
> Das würde sich so mancher Student wünschen machen zu dürfen.
>
> Ich würde aber vorschlagen (Programmieren kann ich nicht aber testen
> gerne) das ihr erstmal auf ein Pferd setzt
> und nicht jeder das Rad neu erfinden versucht.
> Gemeinsam kommt ihr evtl. schneller ans Ziel.
> Aber das nur meine Meinung.
>
> Wie gesagt wenn ihr ein Versuchskaninchen braucht teste ich gerne.
>
> Grüße
>
> On 13 Mrz., 06:45, "Prof. Dr. Peter A. Henning"
> wrote:
> > Na, dann schaut mal aufhttps://
> groups.google.com/forum/?fromgroups#!topic/fhem-developers/F9.<http://groups.google.com/forum/?fromgroups#%21topic/fhem-developers/F9.>..
>
> >
> > LG
> >
> > pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi,
Ideensammlung ist gut
vielleicht als (Zwischen)schritt in ne etwas andere Richtung:

- neue globale Variable globalPrograms, unter der alle (!) Module gelistet
sind, die es in SVN gibt, jedes mit max. 3 Sätzen Beschreibung und jeweils
ner checkbox, ob's geladen werden soll. (wäre mir eh lieb - wenn ich in
mein FHEM-Verzeichnis schaue, nutze ich wohl nur ne Hand voll der ganzen
Module.)
---Luxusvariante: Wenn man ein device anlegt, und das zugehörige Programm
ist noch nicht vorhanden, popup: Soll geladen werden? - dann aut. download,
reload.
---dabei müsste auch das 'Beziehungswissen' hinterlegt sein - zB wenn ich
FHEMRENDERER haben will, muss auch xmllist mitgeladen werden. Andere
Programme nicht deaktivierbar, zB FHEMWEB.

- Ähnlich bei den devices: Im Detail-View *immer alle *Attribute listen,
jedes mit 2 Sätzen Beschreibung und nem Radiobutton/checkbox/dropdown,
welcher Wert es sein soll. Bei manchen müssten evtl. auch die Werte jeweils
kurz erklärt sein.  Also eine Konfigurationsoberfläche, bei der die
technische Speicherung in den Hintergrund tritt (ähnlich wie arrange-mode
bei floorplan: das attr im Hintergrund soll den user eigentlich gar nicht
kümmern. Oder so wie Fritzbox-Konfig-Oberfläche - da sieht man auch nicht,
wie das im Hintergrund verwaltet wird, welche Helferprogramme aufgerufen
werden etc.).

Von Einrichtungsassistenten für devices, at, notify & Co mal ganz
abgesehen. Von Sprachabhängigkeit ebenso.


Für fhem würde das erfordern, dass jedes Modul eine Kurzerklärung
hinterlegt. Außerdem je Attribut die Liste gültiger Werte und eine
Kurzerklärung . Ne Menge Arbeit. Und wohl nur bedingt realistisch - weiss
nicht, ob noch alle Entwickler mit dabei sind, die jemals was beigetragen
haben.

Anders betrachtet: Ne Menge Arbeit, ohne diesen Schritt jedoch wird fhem
m.E. immer eher was für Techies bleiben.
Bitte nicht falsch verstehen - will niemand auf den Schlips treten. Was
hier zustandegebracht wurde ist beeindruckend!

Gruß, Uli


Am Montag, 12. März 2012 13:04:54 UTC+1 schrieb Berlin_Fhemming:
>
> Hallo zusammen!
> --->>> Bitte diesen Thread mal zum Ideen sammeln ansehen!!!!
> /Sascha
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich habe noch eine andere Baustelle, ich gebs ja zu:

Bei den Modulen OWAD.pm und OWTEMP.pm habe ich versucht, eine konsequenten
Einheitendarstellung zu erreichen. Beispielsweise Temperatur nicht als
nackte Zahl, nichts als °, nicht als (Celsius) - sondern ordentlich als
°C. Und den "fliegenden Wechsel" zwischen Celsius-Skala, Kelvin-Skala
und Fahrenheit-Skala.

Beim Modul OWAD.pm kann für jeden Kanal des AD-Wandlers in der Konfig
festgelegt werden, wie er heißt und welches die Einheit ist. Da
gleichzeitig Offset und Skalenfaktor hinterlegt werden können, kann damit
jede lineare Funktion des Messwertes realisiert werden. Beispiel:

define OWX_AD OWAD 724610000000 45
attr OWX_AD room OWX
attr OWX_AD BName   VDD|voltage
attr OWX_AD BAlarm  both
attr OWX_AD BLow 5.0
attr OWX_AD BHigh 5.0
attr OWX_AD DName   RelHumidity|humidity
attr OWX_AD DAlarm  high
attr OWX_AD DHigh   50.0
attr OWX_AD DOffset -0.8088
attr OWX_AD DFactor 31.907097
attr OWX_AD DUnit   percent|%

sorgt dafür, dass Kanal B im FHEM angezeigt wird als Messung von VDD (Typ
Spannung, gemessen in Volt, Abkürzung V),
Kanal D als Messung der Relativen Feuchte (Typ feuchtigkeit, gemessen in
Prozent, Abkürzung %). Zu jedem messwert gehört also nicht nur eine Zahl,
sondern mit Typ, Einheit und Abkürzung drei weitere Werte. Wie das dann
angezeigt wird, kann das Frontend entscheiden.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dr. Boris Neubert]

                                             

Hallo,

Am 16.03.2012 18:18, schrieb UliM:
> - neue globale Variable globalPrograms, unter der alle (!) Module
> gelistet sind, die es in SVN gibt, jedes mit max. 3 Sätzen
> Beschreibung und jeweils ner checkbox, ob's geladen werden soll. (wäre
> mir eh lieb - wenn ich in mein FHEM-Verzeichnis schaue, nutze ich wohl
> nur ne Hand voll der ganzen Module.)
> ---Luxusvariante: Wenn man ein device anlegt, und das zugehörige
> Programm ist noch nicht vorhanden, popup: Soll geladen werden? - dann
> aut. download, reload.
> ---dabei müsste auch das 'Beziehungswissen' hinterlegt sein - zB wenn
> ich FHEMRENDERER haben will, muss auch xmllist mitgeladen werden.
> Andere Programme nicht deaktivierbar, zB FHEMWEB.
verstehe ich nicht. fhem macht doch genau das jetzt schon.
>
> - Ähnlich bei den devices: Im Detail-View _immer alle _Attribute
> listen, jedes mit 2 Sätzen Beschreibung und nem
> Radiobutton/checkbox/dropdown, welcher Wert es sein soll. Bei manchen
> müssten evtl. auch die Werte jeweils kurz erklärt sein.  Also eine
Das ist geplant. Es fehlt nur die Zeit, es umzusetzen. Teile davon sind
schon implementiert bzw. nebenan (in fhem-developers) diskutiert worden.

> Konfigurationsoberfläche, bei der die technische Speicherung in den
> Hintergrund tritt (ähnlich wie arrange-mode bei floorplan: das attr im
> Hintergrund soll den user eigentlich gar nicht kümmern. Oder so wie
> Fritzbox-Konfig-Oberfläche - da sieht man auch nicht, wie das im
> Hintergrund verwaltet wird, welche Helferprogramme aufgerufen werden
> etc.).
Wo ist genau der Unterschied zu pgm2 + autocreate?

> Für fhem würde das erfordern, dass jedes Modul eine Kurzerklärung
> hinterlegt. Außerdem je Attribut die Liste gültiger Werte und eine

commandref.html?

Grüße
Boris

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

Hallo Uli,

> Ideensammlung ist gut

Das ganze in fhem-devel waere noch besser Und daran denken: ich nehme gerne
Patches entgegen, aber ungern Ideen, die ich dann in Patches umwandeln soll.
Ideen habe ich auch noch welche


> - neue globale Variable globalPrograms, unter der alle (!) Module gelistet
> sind, die es in SVN gibt, jedes mit max. 3 Sätzen Beschreibung und jeweils
> ner checkbox, ob's geladen werden soll.

Nett gemeint, aber: fhem laedt nur die module die man per "define" anfordert,
oder die mit 99 beginnen.



> ---dabei müsste auch das 'Beziehungswissen' hinterlegt sein - zB wenn ich
> FHEMRENDERER haben will, muss auch xmllist mitgeladen werden.

Das kann das Modul selber mit require erledigen.


> Außerdem je Attribut die Liste gültiger Werte und eine Kurzerklärung.

Das waere nett, erfordert aber ein durchnudeln aller Module: fleissarbeit.
Weitere "Idee": dokumentieren aller Events. Ich hab damit schon im commandref
angefangen, ist aber auch fleissarbeit. Natuerlich waere schoen das auch vom
Programm zugreifbar zu haben, damit man das im Frontend einfacher auswaehlen
kann. Ich persoenlich finde aber eine bessere Doku wichtiger.

Gruss,
  Rudi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi Boris,


Am Freitag, 16. März 2012 18:46:17 UTC+1 schrieb Boris:
>
>  Hallo,
>
> Am 16.03.2012 18:18, schrieb UliM:
>
> - neue globale Variable globalPrograms, unter der alle (!) Module gelistet
> sind, die es in SVN gibt, jedes mit max. 3 Sätzen Beschreibung und jeweils
> ner checkbox, ob's geladen werden soll. (wäre mir eh lieb - wenn ich in
> mein FHEM-Verzeichnis schaue, nutze ich wohl nur ne Hand voll der ganzen
> Module.)
> ---Luxusvariante: Wenn man ein device anlegt, und das zugehörige Programm
> ist noch nicht vorhanden, popup: Soll geladen werden? - dann aut. download,
> reload.
> ---dabei müsste auch das 'Beziehungswissen' hinterlegt sein - zB wenn ich
> FHEMRENDERER haben will, muss auch xmllist mitgeladen werden. Andere
> Programme nicht deaktivierbar, zB FHEMWEB.
>
> verstehe ich nicht. fhem macht doch genau das jetzt schon.
>
Ömm, wo? Es gibt irgenwo im Hash ne Liste der geladenen Module. Nicht die
der nicht-geladenen. Nicht für den User sichtbar. Nicht mit automatischem
Nachladen, wenn ich define typ XYZ eintippe - da kommt nur 'Typ xyz
existiert nicht, pls check help'
Oder ich kenn da was ganz Tolles noch nicht


> - Ähnlich bei den devices: Im Detail-View *immer alle *Attribute listen,
> jedes mit 2 Sätzen Beschreibung und nem Radiobutton/checkbox/dropdown,
> welcher Wert es sein soll. Bei manchen müssten evtl. auch die Werte jeweils
> kurz erklärt sein.  Also eine
>
> Das ist geplant. Es fehlt nur die Zeit, es umzusetzen. Teile davon sind
> schon implementiert bzw. nebenan (in fhem-developers) diskutiert worden.
>
Sehr gut.

>
> Konfigurationsoberfläche, bei der die technische Speicherung in den
> Hintergrund tritt (ähnlich wie arrange-mode bei floorplan: das attr im
> Hintergrund soll den user eigentlich gar nicht kümmern. Oder so wie
> Fritzbox-Konfig-Oberfläche - da sieht man auch nicht, wie das im
> Hintergrund verwaltet wird, welche Helferprogramme aufgerufen werden etc.).
>
> Wo ist genau der Unterschied zu pgm2 + autocreate?
>
Autocreate ist ja schon genau richtig - zum Anlegen. Nur nicht zum weiteren
Bearbeiten oder zur 'manuellen' Anlage neuer devices.Im Detail-View eines
devices gibt's aktuell ein dropdown mit einer Liste mehr oder weniger
sprechend benannter Atribute. Erklärung muss ich in commandref nachschauen.
Klar geht das alles, es benutzen ja viele Leute - aber eben eher
Tekkie-Style (wie schreibt man das richtig?). Und sowas wie deleteattr
stell ich mir da auch nicht vor - halt ein Häkchen rausnehmen (die Zeile
bleibt aber auf dem screen).
 

>
> Für fhem würde das erfordern, dass jedes Modul eine Kurzerklärung
> hinterlegt. Außerdem je Attribut die Liste gültiger Werte und eine
>
>
> commandref.html?
>
Genau. commandref in Bröckchen aufgeteilt und diese Bröckchen an der
geeigneten Stelle anzeigen. Gleich auf der Konfig-Seite, nicht nach
Absprung durch Klick auf 'Device specific help' .
Ich glaub ich stell mal ein Beispiel (in Excel) zusammen, vielleicht wird
dann klarer was ich meine.
 

>
> Grüße
> Boris
>

Gruß, Uli

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com