Wiki-Anpassungen zu FHEM 5.9

Begonnen von krikan, 09 Oktober 2018, 10:34:36

Vorheriges Thema - Nächstes Thema

Beta-User

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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

krikan

Zitat von: Beta-User am 25 April 2019, 11:45:13
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.

ZitatWas 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.

Zitatwas 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.

krikan

Zitat von: Beta-User am 25 April 2019, 11:45:13
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.

Beta-User

Sehe mich zwar nicht als Hauptautor (das war vermutlich mal Rudi), aber deinem Vorschlag folgend
Zitat von: krikan am 25 April 2019, 13:28:33
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...?!?)

Zitat von: krikan am 25 April 2019, 13:35:37
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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

krikan

Zitat von: Beta-User am 25 April 2019, 11:45:13
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:
ZitatSo 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,..).

Zitat von: Beta-User am 25 April 2019, 14:15:18
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.

ZitatVielleicht 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.  :)

ZitatFehlanzeige, 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.

andies

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 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

Zitat von: andies 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.
Löschen fände ich nicht richtig, aber ganz glücklich macht mich das auch nicht. Ich würde mal folgendes zur Diskussion stellen:
ZitatDiese 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.

Zitat von: krikan am 02 Mai 2019, 08:35:39
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...).

ZitatHabe 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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

andies

Zitat von: Beta-User am 02 Mai 2019, 11:10:09
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 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

Zitat von: andies am 02 Mai 2019, 13:44:44
Ist das nachvollziehbar?
Was mich angeht: Ich denke schon.
ZitatIn 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.

ZitatWas 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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

andies

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 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

Zitat von: andies am 02 Mai 2019, 14:16:52
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:
ZitatDiese 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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

andies

FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

Zitat von: andies am 02 Mai 2019, 15:14:30
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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

krikan

#29
Zitat von: Beta-User am 02 Mai 2019, 15:34:49
Thx, hab's reingebastelt
Ihr habt mich abgehängt.  :-[
In "Erste Schritte" oder wo? In "Erste Schritte" finde ich keine Änderung....