Autor Thema: Wiki-Anpassungen zu FHEM 5.9  (Gelesen 4856 mal)

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6512
Wiki-Anpassungen zu FHEM 5.9
« am: 09 Oktober 2018, 10:34:36 »
Für (Neu)einsteiger gibt es mit FHEM 5.9 einige Neuerungen, die im Wiki angepasst werden könnten/sollten/müssten.

In der enthaltenen https://svn.fhem.de/trac/browser/trunk/fhem/fhem.cfg ist:
- kein telnet-Device mehr enthalten
- nur noch ein FHEMWEB-Device mit Port definiert

Auffälligste Neuerungen sind wohl die Änderung auf f18 als Default-Style und die iconpath-Änderung. In https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM werde ich die Screenshots demnach anpassen (müssen). Alternativ könnte man zwar den Style zu Beginn des Artikels ändern, aber das gefällt mir nicht wirklich.

Meinung, Ergänzung, Hilfe, .. ist -wie immer- gerne gelesen.

Gruß, Christian




Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7592
  • eigentlich eher user wie "developer"
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #1 am: 09 Oktober 2018, 11:39:01 »
In https://wiki.fhem.de/wiki/Quick-Start#Erster_Aufruf_von_FHEM habe ich das eben soweit gradegezogen; wenn der Text keine größeren Kritiker findet, würde ich das im englichen Text bei Gelegenheit nachziehen, wenn wir die neuen passenden Screenshots haben.

Sonst hatte ich auf den ersten Blick in diesem Dokument keinen Änderungsbedarf gesehen, andernfalls bitte um einen Schubs.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline ph1959de

  • Moderator
  • Sr. Member
  • ***
  • Beiträge: 949
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #2 am: 09 Oktober 2018, 18:55:07 »
Beschreibung von f18 (vor allem angesichts der vielen Tips, die es hier im Forum gab) hab ich seit Wochen auf meiner Todo Liste - bin leider bisher nicht dazu gekommen; wenn's in den nächsten Tagen niemand anderes erstellt, werd ich nochmal versuchen, mich zu motivieren - jetzt natürlich in Kombination mit den anderen 5.9-Änderungen.

Peter
[Fhem auf BeagleBone Black (Debian) | FS20, FHT (CUL) | HomeMatic (HMLAN+HMUART) | PCA301 (JeeLink)...]

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6512
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #3 am: 09 Oktober 2018, 20:30:45 »
Screenshots in https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM sind alle aktualisiert.

Btw. irriterend an f18-default ist u.a., dass Links keinen Unterstrich mehr haben, Button "attr", "set" usw. in Device-Detailansicht genauso wie Link aussieht, webcmd nicht von Link unterscheidbar ist, Hintergrund DEF-Edit nicht InputBackgroud bekommt -> Eigentlich mag ich mich nicht mit Styles beschäftigen... -> bekannte Themen?

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6512
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #4 am: 10 Oktober 2018, 08:31:58 »
In https://wiki.fhem.de/wiki/Quick-Start#Erster_Aufruf_von_FHEM habe ich das eben soweit gradegezogen; wenn der Text keine größeren Kritiker findet, würde ich das im englichen Text bei Gelegenheit nachziehen, wenn wir die neuen passenden Screenshots haben.
Gedanken:
Ist der neue Default-Style wirklich vom featurelevel abhängig? Meine in Trockenübung, das hängt nur am abweichend gesetzten Attribut "stylesheetPrefix". (Testen kann ich erst heute Abend.)

telnet geht als Alternative zur Konfiguration und Steuerung jetzt irgendwie im Quick-Start unter. Konfiguration taucht jetzt im geänderten Abschnitt gar nicht mehr auf. In https://wiki.fhem.de/wiki/Configuration bzw. https://wiki.fhem.de/wiki/Konfiguration kommt telnet auch nicht vor und eigentlich könnte man vom entsprechenden Quick-Start auch auf Konfiguration/configuration verlinken. Sinnvoll?

Screenshot https://wiki.fhem.de/wiki/Datei:Erster_aufruf_smartphone.png in Quickstart aktualisiere ich noch. https://wiki.fhem.de/wiki/Datei:Gplot-Editor1.png kommt afaik nicht aus der fhem.cfg.demo und ich habe noch keine schöne Alternative im Angebot.

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6512
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #5 am: 10 Oktober 2018, 20:19:48 »
Ist der neue Default-Style wirklich vom featurelevel abhängig? Meine in Trockenübung, das hängt nur am abweichend gesetzten Attribut "stylesheetPrefix". (Testen kann ich erst heute Abend.)
Behaupte nach Test, dass featurelevel keine Rolle spielt. Wer stylesheetPrefix nicht abweichend setzt, bekommt f18. Kann mich bitte noch jemand kontrollieren/bestätigen. Danke.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7592
  • eigentlich eher user wie "developer"
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #6 am: 10 Oktober 2018, 20:25:34 »
Das war nicht als technische Aussage gemeint, sondern nur als übergangsweiser Hinweis, dass es da jüngst Änderungen gegeben hat. Kann gern raus, komme nur grade nicht dazu, das selbst zu machen.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7592
  • eigentlich eher user wie "developer"
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #7 am: 03 Januar 2019, 13:36:31 »
Zur Info:
Habe eben das mit dem featurelevel ganz rausgenommen und auch die englische Version überarbeitet.

Korrekturen sind wie immer willkommen.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline andies

  • Hero Member
  • *****
  • Beiträge: 2210
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #8 am: 03 März 2019, 08:24:02 »
Ich bin mir unsicher: Erscheinen nicht FUUIDs auf den devices? Und erfordert das erneut neue Screenshots?
FHEM 5.9 auf RaspPi3 (Raspbian:  4.14.34-v7+ ); Perl: v5.20.2
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6512
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #9 am: 06 März 2019, 08:55:00 »
FUUIDs erscheinen in den Internals. Für mich ist das Thema aber kein Grund die Screenshots zu erneuern; halte ich nicht für wichtig und erklären mag ich das Thema in dem Artikel sowieso nicht. Hindere aber niemanden daran die Screenshots zu erneuern.  :)

Gruß, Christian

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6512
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #10 am: 09 April 2019, 09:00:08 »
Nach Einbau des + für den Raw-Import halte ich eine Aktualisierung nun doch für angebracht.

Nach meiner Meinung sollten wir in https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM und https://wiki.fhem.de/wiki/Quick-Start auch die Funktion des Raw-Imports über die "Text-Area" (wie heißt das Ding eigentlich?) erläutern.

Meinung/Ideen?

Gruß, Christian
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7592
  • eigentlich eher user wie "developer"
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #11 am: 09 April 2019, 10:23:34 »
Ich halte es auch für angebracht, da einen kurzen Hinweis einzufügen und auch die Screenshots passend zu erneuern.

Viel Text würde ich aber an beiden Stellen nicht schreiben, sondern das nur erwähnen und auf den Hauptartikel dazu (https://wiki.fhem.de/wiki/Import_von_Code_Snippets) verlinken, den hatte ich heute morgen schon entsprechend erweitert (bessere Screenshots wären ggf. noch angesagt, bzw. ihr dürft das gerne kommentieren, wenn Verbesserungsbedarf besteht).

Allgemeine Anmerkungen noch:
- In den "ersten Schritten" würde sich eigentlich bei "Räumen" noch ein Hinweis gut machen, dass man diese auch gliedern kann ("Steuerung->Ungenutzte_Devices"; eine Fußnote würde m.E. reichen).
- Codemirror als nützliches Tool könnte man in dem Zusammenhang irgendwo auch noch erwähnen; ich hatte jüngst mit diversen Testsystemen zu tun, in denen der nicht "richtig" konfiguriert war. Da fällt einem erst auf, wie komfortabel das ist :D .
- was ist mit "show"?

Ohne das jetzt näher geprüft zu haben, sagt mein Bauchgefühl, dass wir eine "engere" Benutzerführung der Anfänger durch einige Grundlagenartikel haben sollten. Müßte man sich ggf. mal ansehen, wenn noch mehr ein ähnliches Bauchgefühl haben sollten.
Der Spur nach: die zwei von Christian verlinkten, RAW-Import, Device-Overview anpassen bzw. devStateIcon, Räume (auch gegliedert, show), Startraum und Gruppen, list. Zum Teil findet man da schon was im Einsteiger-pdf, aber das gibt die Möglichkeiten nur ansatzweise wieder und berücksichtigt nicht die jüngsten Neuerungen.
Dann wäre es vermutlich noch gut, wir würden dem list-Artikel noch einige Anmerkungen spendieren zu den Unterschieden eines "-r" list und einem "normalen" (Internals teilweise (?) sichtbar, -r ermöglicht Helfern, das Device einfacher "nachzustellen", also kurz: wann liefere ich bei support-Anfragen im Forum eigentlich was bzw. was kann ich selbst jeweils darauf ablesen).

(Ich kann gerne jedenfalls in Teilbereichen was dazu schreiben/ergänzen, aber es sollte nach allg. Meinung in die richtige Richtung gehen.)

Gruß, Beta-User
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6512
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #12 am: 11 April 2019, 14:27:40 »
Viel Text würde ich aber an beiden Stellen nicht schreiben, sondern das nur erwähnen und auf den Hauptartikel dazu (https://wiki.fhem.de/wiki/Import_von_Code_Snippets) verlinken, den hatte ich heute morgen schon entsprechend erweitert (bessere Screenshots wären ggf. noch angesagt, bzw. ihr dürft das gerne kommentieren, wenn Verbesserungsbedarf besteht).
Statt Verlinkung würde ich das  in https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM direkt einarbeiten; bspw. in https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM#Timer_bei_einem_Event_starten_-_notify_und_at statt dem dort bisher genannten manuellem Zusammenklicken.
Links gibt es in https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM bisher bewusst (fast) nur am Ende, um nicht zu sehr abzulenken. Halte ich weiterhin für sinnvoll.
Ob im Quickstart ein Link genügt, bin ich unentschieden. Durch "Abklemmen" von telnet in der derzeit auslieferten Standart-fhem.cfg, könnte man den Raw-Inport über "+"  als eine immer vorhandene Alternativlösung deklarieren.

Zitat
- In den "ersten Schritten" würde sich eigentlich bei "Räumen" noch ein Hinweis gut machen, dass man diese auch gliedern kann ("Steuerung->Ungenutzte_Devices"; eine Fußnote würde m.E. reichen).
Ist das nicht schon zu speziell? Ähnlich wie "show"?

Zitat
- Codemirror als nützliches Tool könnte man in dem Zusammenhang irgendwo auch noch erwähnen;

Bin ich gerade vorsichtig, da afaik Codemirror keinen Maintainer hat und gerade das "+" dann sich an einer falschen Stelle (teilweise außerhalb) des Bildschirms öffnet. Darum solange nicht gefixt und ohne Maintainer eher nicht.

Zitat
Ich kann gerne jedenfalls in Teilbereichen was dazu schreiben/ergänzen, [..]
Gerne doch.  :)

Gruß, Christian
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7592
  • eigentlich eher user wie "developer"
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #13 am: 11 April 2019, 16:13:44 »
Statt Verlinkung würde ich das  in https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM direkt einarbeiten; bspw. in https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM#Timer_bei_einem_Event_starten_-_notify_und_at statt dem dort bisher genannten manuellem Zusammenklicken.
Links gibt es in https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM bisher bewusst (fast) nur am Ende, um nicht zu sehr abzulenken. Halte ich weiterhin für sinnvoll.
Habe das an der genannten Stelle mal versucht und auch zwei Bildchen dazu gemacht im bisherigen Stil, und in der Einleitung auch einen kurzen Hinweis zu dem "+" reingemacht (ohne Link).

Zitat
Ob im Quickstart ein Link genügt, bin ich unentschieden. Durch "Abklemmen" von telnet in der derzeit auslieferten Standart-fhem.cfg, könnte man den Raw-Inport über "+"  als eine immer vorhandene Alternativlösung deklarieren.
Da ist im Moment nur die Kurzfassung mit link in der Einleitung. M.E. paßt das in dieser Form eigentlich ganz gut zum gesamten Charakter dieses Dokuments, das ja schon jetzt sehr viel an Informationen mit Links und Fußnoten beinhaltet.

Bin unschlüssig, ob man das aufbohren sollte, wenn, dann m.E. nur sehr moderat. Insgesamt ist mir durch die Aktion wieder bewußt geworden, dass es tatsächlich sinnvoll ist, beide "Varianten" zu haben. Die "ersten Schritte" sind eher für den grafisch orientierten, technisch noch nicht so versierten Leser geeignet, der Quick-Start hat eher was von einer Kurzreferenz.

Zitat
Ist das nicht schon zu speziell? Ähnlich wie "show"?
Aus diesem Grund habe ich das mit den gegliederten Räumen in den ersten Schritten draußen gelassen, aber in einer neuen Fußnote im Quick-Start dann aufgenommen, zusammen mit zwei weiteren "Kleinigkeiten", die vielen Usern gerne "durchrutschen" und jedenfalls teilweise scheinbar wenig bekannt sind.

Zitat
Bin ich gerade vorsichtig, da afaik Codemirror keinen Maintainer hat und gerade das "+" dann sich an einer falschen Stelle (teilweise außerhalb) des Bildschirms öffnet. Darum solange nicht gefixt und ohne Maintainer eher nicht.
Das ist mir bisher nicht passiert, aber auf dem Handy ist Codemirror (?) auch nicht zu gebrauchen. Wäre schön, wenn wir bzw. ein neuer Maintainer das gefixt bekäme, aber da beißt sich die Katze auch etwas in den Schwanz: Wer wird sich bereit erklären, wenn er es gar nicht kennt ??? ? Aber solange bleibt es auch aus dem Quick-Start draußen.

Wäre schön, wenn ihr feedback zum Quick-Start geben könntet, dann kann ich (oder jemand, der es besser kann) das zeitnah wieder in die englische Fassung einarbeiten. (Zur Klarstellung: Für die First Steps wollte ich mich eigentlich gar nicht erst freiwillig melden...)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6512
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #14 am: 25 April 2019, 11:16:48 »
Wäre schön, wenn ihr feedback zum Quick-Start geben könntet, dann kann ich (oder jemand, der es besser kann) das zeitnah wieder in die englische Fassung einarbeiten.
https://wiki.fhem.de/w/index.php?title=Quick-Start&type=revision&diff=30132&oldid=28932 habe ich mir angesehen. Feedback: Daumen hoch!  :)
Nur Neugier: Hast Du einen bestimmten Grund für die Änderung der Überschrift von "FHEMWEB (pgm2) anpassen"  auf "Das_Web-Interface_anpassen"? Hadere bei Überschriftsänderungen immer, da alte Links eventuelle ins Leere führen; hier aber vermutlich unproblematisch, da noch relativ neues Dokument.

Zitat
(Zur Klarstellung: Für die First Steps wollte ich mich eigentlich gar nicht erst freiwillig melden...)
Danke fürs "nicht freiwillig melden", aber "machen". Steht bei mir auch weiterhin auf Todo.

Gruß, Christian

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7592
  • eigentlich eher user wie "developer"
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #15 am: 25 April 2019, 11:45:13 »
Danke für die Rückmeldung, dann kommt bei Gelegenheit noch die englische Fassung dran (falls sich sonst keiner findet, der besser Englisch kann...).

Was die Überschrift angeht, war mir zum einen nicht präsent, dass das Nebenwirkungen hat (werde das zukünftig hoffentlich besser bedenken), zum anderen war es schon immer a) sehr technisch und b) eigentlich irreführend, weil weiter unten (auch schon immer) was von "andere Frontends" zu lesen war.
Würde daher vorschlagen, es so zu lassen, wie es jetzt ist?
(Wobei die Frage wäre, ob man den Einleitungsteil nicht mit der Überschrift "Styles" versehen sollte und dann (sehr) kurz erläutern, wie man das bzw. das Farbschema zu f18 umstellt? Wenn man nur die Überschriften ansieht, ist das m.E. nicht besonders intuitiv.)

Was freiwillig melden zu First Steps angeht: da ging es um die englische Fassung; dass es (erst mal für die deutsche Fassung) wichtig war, das Thema gleich zentral abzuarbeiten, zeigt v.a. die Diskussion um die jüngsten Änderungen bei "RAW-Import"...
Ansonsten fühle ich mich auch weiter nicht für die deutsche Fassung zuständig. (Mir gefällt insbesondere das mit dem Dummy-Beispiel weiterhin nicht so recht, das verleitet nach meinem persönlichen Geschmack die Leute dazu, Informationen unnötig umzupacken statt direkt Readings zu verwenden. Aber mangels besserer Alternativen ist es halt so; was evtl. stattdessen ginge, wäre MQTT2_SERVER+DEVICE, das braucht auch keine Hardware und wäre gleich zweistufig, wie die meisten Hardwareanbindungen).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6512
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #16 am: 25 April 2019, 13:28:33 »
Würde daher vorschlagen, es so zu lassen, wie es jetzt ist ?
Ja.

Zitat
(Wobei die Frage wäre, ob man den Einleitungsteil nicht mit der Überschrift "Styles" versehen sollte und dann (sehr) kurz erläutern, wie man das bzw. das Farbschema zu f18 umstellt? Wenn man nur die Überschriften ansieht, ist das m.E. nicht besonders intuitiv.)
Mach ruhig, wenn es Dir anders besser gefällt. Bist dich einer der Hauotersteller des Artikels.

Zitat
Was freiwillig melden zu First Steps angeht: da ging es um die englische Fassung; dass es (erst mal für die deutsche Fassung) wichtig war, das Thema gleich zentral abzuarbeiten, zeigt v.a. die Diskussion um die jüngsten Änderungen bei "RAW-Import"...
Ansonsten fühle ich mich auch weiter nicht für die deutsche Fassung zuständig.
Ah, habe ich Dich wohl mißverstanden. Es bleibt: Danke. Und mach das wozu der Lust/Zeit/Energie hast....

Zitat
(Mir gefällt insbesondere das mit dem Dummy-Beispiel weiterhin nicht so recht, das verleitet nach meinem persönlichen Geschmack die Leute dazu, Informationen unnötig umzupacken statt direkt Readings zu verwenden.
Bin mir nicht sicher, ob das wirklich daher kommt. Eigentlich sind die Beispiele nicht so, dass man den dummy als Datenspeicher nutzt. Ich vermute eher das kommt aus alten Beispielen im Netz, da "früher" die direkte Readings-Verwendung nicht so alltäglich war. Viele Reading-Funktionen (userReadings, ..) sind erst später gekommen.

Zitat
was evtl. stattdessen ginge, wäre MQTT2_SERVER+DEVICE, das braucht auch keine Hardware und wäre gleich zweistufig, wie die meisten Hardwareanbindungen).
habe keine Ahnung von MQTT und CO. Ist Dein Bereich.
 
Ändern mag ich es eigentlich nicht mangels Überzeugung und nicht zuletzt aus Faulheit  8) ; Meine Todo soll nicht noch mehr zunehmen.

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6512
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #17 am: 25 April 2019, 13:35:37 »
zeigt v.a. die Diskussion um die jüngsten Änderungen bei "RAW-Import"...
Bzgl. RAW-Import: Könntest Du bitte mal in https://wiki.fhem.de/wiki/Diskussion:Import_von_Code_Snippets, ob Du dazu etwas sagen/schreiben kannst. Ansonsten warte ich auf Trelle/Elllert.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7592
  • eigentlich eher user wie "developer"
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #18 am: 25 April 2019, 14:15:18 »
Sehe mich zwar nicht als Hauptautor (das war vermutlich mal Rudi), aber deinem Vorschlag folgend
Mach ruhig, wenn es Dir anders besser gefällt.
habe ich den Teil kurz erledigt, und gleich noch Hinweise reingebastelt, dass man mehrere Instanzen für unterschiedliche Zwecke haben kann. Da könnte man wohl auch noch ein eigenes Wiki-Dokument draus basteln (oder mehrere), aber da habe ich auch keine best Practice dazu und zu wenig ausgetestet (als ich in das Thema eingestiegen bin, gab's praktisch noch keine Möglichkeiten, überhaupt irgendwas einzuschränken).

Allg.: kann man für "normale" User den Zugriff auf die Detailseiten abdrehen? Durch die jüngsten Änderungen zu devStateIcon kann ja jetzt "jeder" recht einfach alle wichtigen Dinge grafisch (und schaltbar) im DeviceOverview unterbringen. Daher wäre es eigentlich naheliegend, "einfache" User schlicht auf die Raumübersicht zu beschränken. Auf Raumebene geht es dann nach meiner Erinnerung wieder ohne weiteres, die für den User jeweils zulässigen Räume zu festzulegen, und schon hat man (halbwegs ) ein reines Bedienerinterface.

Vielleicht gibtst du mir noch ein kurzes feedback zu dem "Styles"-Teil? (Nicht, dass wir da eine ander Überschrift wählen sollten, Styles ist eigentlich auch sehr verkürzt. Aber ob es Sinn macht, das auszuweiten nach "Styles, Instanzen, User", ist eine andere Frage...?!?)

Bzgl. RAW-Import: Könntest Du bitte mal in https://wiki.fhem.de/wiki/Diskussion:Import_von_Code_Snippets, ob Du dazu etwas sagen/schreiben kannst. Ansonsten warte ich auf Trelle/Elllert.
Fehlanzeige, ich habe mit dem ominösen exportdevice auch noch nicht gearbeitet und weiß nicht, wo das herkommt. Verlinkung nach https://wiki.fhem.de/wiki/List#Erweiterte_Optionen fände ich aber auch zielführend, vielleicht müßte man da den Link zu "Import" noch etwas aufhübschen, das steht noch etwas "verloren" da.

Ansonsten merkst du ja, dass ich mir die Zeit und Freiheit nehme, Dinge einfach zu ändern, wenn mich der aktuelle Zustand zu sehr stört. Aber an so grundsätzlichen Fragen wie Dummy=>MQTT2_DEVICE wollte ich auch nicht ohne Rückfrage rühren. Und solange man nur auf STATE-Ebene bleibt, ist der Unterschied sowieso marginal, vielleicht wäre es (bei Gelegenheit...) auch eine Idee, auf die Reading-Ebene bei Dummy zu wechseln. Wäre dann aber eher was für einen "Teil 2"....
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7592
  • eigentlich eher user wie "developer"
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #19 am: 26 April 2019, 16:45:05 »
So, kurze Vollzugsmeldung zum englischen Quick-Start. Wie immer wäre ich froh, wenn da nochmal jemand mit wirklichen Englisch-Kenntnissen drüberlesen würde; manches war da schon drin...

Ansonsten habe ich das RAW-Thema grade auch in https://wiki.fhem.de/wiki/Konfiguration#RAW-Import (auch in der engl. Fassung, dort aber ohne Bild) noch kurz ergänzt.

Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6512
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #20 am: 02 Mai 2019, 08:35:39 »
Mir gefällt insbesondere das mit dem Dummy-Beispiel weiterhin nicht so recht, das verleitet nach meinem persönlichen Geschmack die Leute dazu, Informationen unnötig umzupacken statt direkt Readings zu verwenden.
Korrigiere mich: Das stand ursprünglich nicht drin. Jetzt ist aber so ein Satz enthalten, der genau das aus meiner Sicht beinhaltet:
Zitat
So etwa ist die Benutzeroberfläche von FHEM selbst ein device ("FHEMWEB"), ebenso gibt es Devices ohne physische Geräte, die dazu benutzt werden können, um eine Variable zu speichern.
Das wurde eingebaut, als auch das Restliche mMn unnötig und unscharf erweitert wurde (Modulnummer, Erläuterung Reading, Internal,..).

Allg.: kann man für "normale" User den Zugriff auf die Detailseiten abdrehen? Durch die jüngsten Änderungen zu devStateIcon kann ja jetzt "jeder" recht einfach alle wichtigen Dinge grafisch (und schaltbar) im DeviceOverview unterbringen. Daher wäre es eigentlich naheliegend, "einfache" User schlicht auf die Raumübersicht zu beschränken. Auf Raumebene geht es dann nach meiner Erinnerung wieder ohne weiteres, die für den User jeweils zulässigen Räume zu festzulegen, und schon hat man (halbwegs ) ein reines Bedienerinterface.
Keine Ahnung (allowed?). Mit Frontends beschäftige ich mich nicht wirklich, da ich Automatisierung im Hintergrund ohne Frontend betreibe.

Zitat
Vielleicht gibtst du mir noch ein kurzes feedback zu dem "Styles"-Teil? (Nicht, dass wir da eine ander Überschrift wählen sollten, Styles ist eigentlich auch sehr verkürzt. Aber ob es Sinn macht, das auszuweiten nach "Styles, Instanzen, User", ist eine andere Frage...?!?)
Habe nichts zu meckern.  :)

Zitat
Fehlanzeige, ich habe mit dem ominösen exportdevice auch noch nicht gearbeitet und weiß nicht, wo das herkommt. Verlinkung nach https://wiki.fhem.de/wiki/List#Erweiterte_Optionen fände ich aber auch zielführend, vielleicht müßte man da den Link zu "Import" noch etwas aufhübschen, das steht noch etwas "verloren" da.
Habe ich auf die Schnelle geändert.

In "Erste Schritte" habe ich Screenshots erneuert.

In https://wiki.fhem.de/wiki/Konfiguration habe ich mit der Screenshot-Erneuerung und Umstellung auf f18 begonnen (muss einige nochmal verbessern) und codemirror auf separate Seite ausgelagert. Die Befehlsvervollständigungsfunktion mit codemirorr bekomme ich in f18 nicht in Gang.

Offline andies

  • Hero Member
  • *****
  • Beiträge: 2210
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #21 am: 02 Mai 2019, 09:41:01 »
Ich würde gern einen etwas anderen Text zu dummies einfügen, weil ich darüber schon früher gestolpert bin (und auf mich auch ein paar Aussagen zu Internals etc zurückgehen). Ich trage das einfach mal ein, löschen könnt Ihr das ja nach wie vor.
FHEM 5.9 auf RaspPi3 (Raspbian:  4.14.34-v7+ ); Perl: v5.20.2
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7592
  • eigentlich eher user wie "developer"
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #22 am: 02 Mai 2019, 11:10:09 »
Ich würde gern einen etwas anderen Text zu dummies einfügen, weil ich darüber schon früher gestolpert bin (und auf mich auch ein paar Aussagen zu Internals etc zurückgehen). Ich trage das einfach mal ein, löschen könnt Ihr das ja nach wie vor.
Löschen fände ich nicht richtig, aber ganz glücklich macht mich das auch nicht. Ich würde mal folgendes zur Diskussion stellen:
Zitat
Diese Einleitung soll Ihnen ein Gefühl für die Funktionsweise von FHEM vermitteln, ohne dass Ihnen konkrete physische Geräte (spezielle Funk- oder WLAN-Steckdosen, 433MHz-Sender,  Homematic-Lampen, ZWave-Aktoren usw.) zur Verfügung stehen müssen. Um ein rein "virtuelles Gerät" nutzen zu können, greifen wir auf ein dummy-device zurück. Ein ''dummy'' wird Ihnen häufig begegnen, wenn es darum geht, Informationen userseitig verfügbar zu machen. Beachten Sie dabei aber, dass Ihnen später sehr viele Möglichkeiten offenstehen, um Informationen abzuspeichern, auszuwerten oder anzuzeigen, sobald Sie FHEM-Geräte für physische Hardware angelegt haben. Hier wird es häufig übersichtlicher sein, Informationen zu einem Gerät direkt bei diesem zu verwalten. Neben den Attributen und Readings, die die hierfür jeweils genutzen Module bereits automatisch bereitstellen, können Sie z.B. bei allen Devices weitere Attribute (userattr) oder Readings (setreading) generieren.
(Achtung: Meinung...) userreadings würde ich eher meiden wollen, das hat m.E. einen doch eher speziellen Zweck und ist häufig ein workaround für Dinge, die man eigentlich modulseitig fixen sollte. ReadingsGroup ist dann eigentlich wieder thematisch ein ganz anderes Ding.

Keine Ahnung (allowed?). Mit Frontends beschäftige ich mich nicht wirklich, da ich Automatisierung im Hintergrund ohne Frontend betreibe.
Geht mit hiddenroom :) , cref sollte man lesen können ::) , und es stand sogar ein kleiner Hinweis zu hiddenroom schon in der bisherigen Fassung :o ; habe jetzt eine Fußnote reingemacht, weil nicht nur ich vermutlich sowas (zu) leicht überlese. Ob man neuerdings dann den Zugriff auf die Detailseiten via allowed effektiv unterbinden kann, wäre aber noch auszutesten, für's erste reicht mir, den Schnellzugang abzuschalten.
(Ich hatte bisher auch wenig mit UI-Gestaltung gemacht, viel wichtiger ist das, was im Hintergrund abläuft. Aber scheinbar gibt es auch user, für die ein hübsches, aufgeräumtes UI pro "Enduser" wichtig ist, und dafür dann weite Umwege in Kauf nehmen; das ist dabei das, was ich im Hinterkopf habe bzw. warum ich überhaupt manches austeste...).

Zitat
Habe nichts zu meckern.  :)
:) Danke. Ist auch (etwas anders) schon in der englischen Fassung drin, nachdem kein schneller Widerspruch kam...

Das Auslagern von codemirror war m.E. eine gute Sache. Soweit ich das verstanden habe, ist das die Komponente, die für Syntax highlighting verantwortich ist, oder? (Dann würde ich bei Gelegenheit da z.B. bei Import auch verlinken, im QuickStart habe ich das schon in eine Fußnote bei FHEMWEB gepackt.)
Wäre echt super, wenn sich da jemand finden würde, der das Tool wieder vollst. auch unter f18 zum Laufen bekäme (ist Javascript, da gäbe es doch einige hier, die das auch beherrschen...)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline andies

  • Hero Member
  • *****
  • Beiträge: 2210
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #23 am: 02 Mai 2019, 13:44:44 »
Löschen fände ich nicht richtig, aber ganz glücklich macht mich das auch nicht. Ich würde mal folgendes zur Diskussion stellen:(Achtung: Meinung...) userreadings würde ich eher meiden wollen, das hat m.E. einen doch eher speziellen Zweck und ist häufig ein workaround für Dinge, die man eigentlich modulseitig fixen sollte. ReadingsGroup ist dann eigentlich wieder thematisch ein ganz anderes Ding.
Was da konkret als devices steht, ist in meinen Augen eher zweitranging. Ich meine nur folgendes. In der ganzen Einleitung kommen ständig dummies vor und die Leute glauben dann, dass dummies die Dinge der Wahl sind. Diese Sichtweise würde ich gern vermeiden. Dummies sind für die Einleitung super, aber danach wäre es nicht schlecht, wenn man "woanders" nachschaut. Was genau woanders ist, das sollten wir klären.

Ist das nachvollziehbar?
FHEM 5.9 auf RaspPi3 (Raspbian:  4.14.34-v7+ ); Perl: v5.20.2
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7592
  • eigentlich eher user wie "developer"
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #24 am: 02 Mai 2019, 14:12:17 »
Ist das nachvollziehbar?
Was mich angeht: Ich denke schon.
Zitat
In der ganzen Einleitung kommen ständig dummies vor und die Leute glauben dann, dass dummies die Dinge der Wahl sind.
Zum einen ist es nicht nur die Einleitung, auch viel Beispielcode im Wiki und im Forum nutzt - aus verschiedendsten Gründen - Dummies. Das ist im Prinzip auch nicht weiter tragisch, Dummy ist (auch) eine Möglichkeit, Infos "zwischenzulagern". Tragisch ist nur, dass wir
a) eine nicht ganz unerhebliche Anzahl von Usern haben, die (z.B. als Reading) vorhandene Info erst mal in einen Dummy "umpacken", um dann auf den Dummy zuzugreifen (k.A. warum)
b) noch viel mehr eine Unzahl von dummys nutzen und verketten, um eigentlich zusammengehörige Info zu verwalten. Hier scheint einfach nicht bekannt zu sein, dass man jedes Device im Prinzip beliebig selbst erweitern kann. Da ist dann nur die Frage wie.

Das sollten wir erklären, aber m.E. nicht unbedingt (auch noch) in den ersten Schritten.

Zitat
Was genau woanders ist, das sollten wir klären.
Das war mein Anliegen mit dem konkreten Textvorschlag, daher etwas mehr zu den "Hintergedanken":
Direkt "beim" Device geht es mit Attributen (userattr) und Readings (setreading und userreadings), wobei userreadings (nach meinem bisherigen Verständnis) ein Sonderfall eines internen notify sind, um reinkommende Info umzuformatieren, andere Namen dafür zu nehmen oder zu einer Vollinfo zusammenzubauen (z.B. r,g,b nach rgb). Da letzteres (userreadings) ein Spezialfall ist, sollte man das m.E. hier noch nicht erläutern, sondern ggf. erst bei Readings (https://wiki.fhem.de/wiki/Reading).
setreading geht immer, dagegen ist userattr erforderlich, um ein entsprechendes eigenes Attribut nutzen zu können. Da wir in den ersten Schritten auf links verzichten, war eben der Vorschlag, nur diese beiden wichtigen Stichworte anzubieten. (Wobei leider noch die Frage offen bleibt, was man aus welchem Grund wofür nutzen kann/sollte).

ReadingsGroup ist eine Option, um mit einem weiteren Device irgendwas (ggf. grafisch) aufzuarbeiten. Sowas kommt nach meinem Geschmack thematisch erst dann, wenn man einige Geräte hat (oder ein Gerät mit sehr vielen Readings, das man anders darstellen will, aber dann sind wir thematisch auch bei https://wiki.fhem.de/wiki/DeviceOverview_anpassen - ergo weiteren Geschmacks- und Abgrenzungsfragen.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline andies

  • Hero Member
  • *****
  • Beiträge: 2210
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #25 am: 02 Mai 2019, 14:16:52 »
Ich stelle mir das so vor: "Jetzt dummies und für später merke, lieber Leser, dir folgende Stichworte, bevor Du ein dummie einsetzt:" <und da reichen schon zwei Stichworte oder Links, die sind sowieso zu früh>

Ich war so ein dummie-freak. Warum? Weil ich nichts anderes kannte. Ich dachte, das muss so ein. Ich wäre nie auf die Idee gekommen, eine Readingsgroup zu verwenden. Das ist war für Perl-Programmier, dachte ich.
FHEM 5.9 auf RaspPi3 (Raspbian:  4.14.34-v7+ ); Perl: v5.20.2
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7592
  • eigentlich eher user wie "developer"
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #26 am: 02 Mai 2019, 14:47:10 »
Ich war so ein dummie-freak.
;D
(...DIESEN "Fehler" habe ich nie gemacht, das war mir immer suspekt. Stattdessen hatte ich eine größere Anzahl von Eventhandlern diverser Typen, die im Prinzip (gruppenweise) alle dasselbe gemacht hatten. Erst später bin ich dann in die myUtils-Welt eingestiegen und habe jetzt deutlich weniger Doppelungen, sondern in der Regel nur einen Funktionsaufruf via notify, der sich dann anhand des triggernden Geräts (und ggf. Events) den Rest selbst zusammensucht, also z.B. bestimmt, welches Gerät denn eigentlich wie geschaltet werden soll...).
Das ist auch so ein Punkt, den man ggf. noch etwas mehr pushen könnte (aber das ist eine Frage, über die die "Ein Zielgerät, ein bestimmter Eventhandler"-Fraktion eventuell ganz anders denkt).

Folgender update zum Vorschlag:
Zitat
Diese Einleitung soll Ihnen ein Gefühl für die Funktionsweise von FHEM vermitteln, ohne dass Ihnen konkrete physische Geräte (spezielle Funk- oder WLAN-Steckdosen, 433MHz-Sender,  Homematic-Lampen, ZWave-Aktoren usw.) zur Verfügung stehen müssen. Um für diesen Kurs ein rein "virtuelles Gerät" nutzen zu können, greifen wir auf ein dummy-device zurück. Ein ''dummy'' wird Ihnen auch später noch häufig begegnen, wenn es darum geht, einen Testaufbau zu erläutern oder zur Steuerung eines Programmablaufs Informationen userseitig verfügbar zu machen. Beachten Sie dabei aber bitte immer, dass Ihnen später auch '''sehr viele andere Möglichkeiten''' offenstehen, um Informationen abzuspeichern, auszuwerten oder anzuzeigen, sobald Sie FHEM-Geräte für physische Hardware angelegt haben. Statt hierfür Geräte des Typs ''dummy'' zu verwenden, wird es für Sie zukünftig häufig übersichtlicher sein, Informationen zu einem Gerät direkt bei diesem zu verwalten. Neben den Attributen und Readings, die die hierfür jeweils genutzen Module bereits automatisch bereitstellen, können Sie z.B. bei allen Devices weitere Attribute (userattr) oder Readings (setreading) selbst in fast beliebigem Umfang generieren und darin Ihre eigenen Informationen bereitstellen.

Was das "Übersehen" von Modulen angeht, ist das Auffinden wirklich wichtiger Module zunehmend schwierig, aber generell sollte man davon ausgehen, dass Module immer eher den "normalen" user im Blick haben, weniger die Perl-Programmierer ;) .
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline andies

  • Hero Member
  • *****
  • Beiträge: 2210
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #27 am: 02 Mai 2019, 15:14:30 »
Gefällt mir sehr gut.
FHEM 5.9 auf RaspPi3 (Raspbian:  4.14.34-v7+ ); Perl: v5.20.2
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7592
  • eigentlich eher user wie "developer"
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #28 am: 02 Mai 2019, 15:34:49 »
Gefällt mir sehr gut.
Thx, hab's reingebastelt und vorhin auch noch den Reading-Artikel kurz soweit erweitert (auch zu userreadings), dass man m.E. die Baustelle abbauen konnte. Mal schauen, ob das Verlinken aus dem QuickStart ggf. Sinn macht...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6512
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #29 am: 02 Mai 2019, 19:10:11 »
Thx, hab's reingebastelt
Ihr habt mich abgehängt.  :-[
In "Erste Schritte" oder wo? In "Erste Schritte" finde ich keine Änderung....
« Letzte Änderung: 02 Mai 2019, 19:32:57 von krikan »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7592
  • eigentlich eher user wie "developer"
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #30 am: 02 Mai 2019, 19:36:54 »
Ihr habt mich abgehängt.  :-[
In "Erste Schritte" oder wo? In "Erste Schritte" finde ich keine Änderung....
Mist, da war mir wohl das "Speichern" durchgegangen... Jetzt ist es wirklich drin :) .
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline andies

  • Hero Member
  • *****
  • Beiträge: 2210
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #31 am: 02 Mai 2019, 19:56:36 »
FHEM 5.9 auf RaspPi3 (Raspbian:  4.14.34-v7+ ); Perl: v5.20.2
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6512
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #32 am: 03 Mai 2019, 07:53:10 »
Soweit ich das verstanden habe, ist das die Komponente, die für Syntax highlighting verantwortich ist, oder?
Ja. Eingebundener externer Editor.

Zitat
Wäre echt super, wenn sich da jemand finden würde, der das Tool wieder vollst. auch unter f18 zum Laufen bekäme (ist Javascript, da gäbe es doch einige hier, die das auch beherrschen...)
Habe gestern festgestellt, dass es nicht an f18 liegt. Vielmehr kommt codemirror afaik nicht mit dem cfsrToken klar. In https://svn.fhem.de/trac/browser/trunk/fhem/www/codemirror/fhem.js.unoptimized Zeile 857 erfolgt der Aufruf ohne cfsrToken. Darum geht die Befehlsvervollständigung nur wenn der cfsrToken auf none steht. Mich wundert, dass bisher dazu keine Beschwerden kamen. Scheint niemand zu nutzen!?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7592
  • eigentlich eher user wie "developer"
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #33 am: 03 Mai 2019, 08:49:54 »
Mich wundert, dass bisher dazu keine Beschwerden kamen. Scheint niemand zu nutzen!?
Ich nutze codemirror schon und hatte auch festgestellt, dass das nicht so ganz wie beschrieben funktioniert (anderes schon); da er trotzdem hilfreich ist (und der Part für mich nicht so wichtig), habe ich halt einfach mal gehofft, dass sich irgendwann mal einer kümmert, der weiß, was zu tun ist :) .

Wäre schön, wenn "jemand" das fixen würde (rapster war lt. Forumliste im Dez. das letzte mal angemeldet).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6512
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #34 am: 03 Mai 2019, 13:54:52 »
Nach Einbau des + für den Raw-Import halte ich eine Aktualisierung nun doch für angebracht.

Nach meiner Meinung sollten wir in https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM und https://wiki.fhem.de/wiki/Quick-Start auch die Funktion des Raw-Imports über die "Text-Area" (wie heißt das Ding eigentlich?) erläutern.

Meinung/Ideen?
Hadere immer noch mit der Benennung.

Aus Erste Schritte:
Zitat
Links daneben befindet sich ein umrahmtes "+"-Symbol, über das Sie ein Eingabefeld für den Import von RAW-Code erreichen können
Finde diese Benennung mit RAW-Import, RAW-Code usw. -insbesondere auch an der Stelle- nicht wirklich verständlich. Eigentlich ist das doch nichts anderes als das auf mehrzeiligen Input erweiterte Command/Befehl(s)-Eingabefeld. Warum das jetzt RAW ist, entzieht sich meiner Kenntnis.

Für mich ist das ein mehrzeiliges Kommandofeld über das eben auch Code (Defintionen) importiert werden kann.

Anmerkungen/Ideen?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7592
  • eigentlich eher user wie "developer"
Antw:Wiki-Anpassungen zu FHEM 5.9
« Antwort #35 am: 03 Mai 2019, 14:08:15 »
Hadere immer noch mit der Benennung.
[...]
Für mich ist das ein mehrzeiliges Kommandofeld über das eben auch Code (Defintionen) importiert werden kann.
Das mit RAW hat sich halt irgendwie so eingebürgert, aber im Prinzip hast du recht, das ist eine "betriebsblinde" Bezeichnung ohne wirklichen Aussageinhalt...

"mehrzeiliges Kommandofeld" finde ich eigentlich auch passender bzw. sprechender.

Von daher würde ich auch dafür votieren, das - jedenfalls für den ersten Start - genau so zu benamsen. In den Quick-Start käme dann noch der Hinweis, dass sich dafür eben diese Bezeichnung eingebürgert hat? (Fußnote, wie dort üblich...)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

 

decade-submarginal