Unterstützung bei Aktualisierung von https://fhem.de/HOWTO_DE.html gesucht!

Begonnen von krikan, 06 Juni 2017, 12:05:45

Vorheriges Thema - Nächstes Thema

nils_

vielleicht nur als kleine idee....

bei
https://wiki.fhem.de/wiki/HOWTO#Wichtige_Befehle_f.C3.BCr_die_erste_Zeit
könntest du auch noch die links auf die wiki seiten der befehle setzen.
(mir ist bewusst das die commandref der _master_ ist :) )
viele Wege in FHEM es gibt!

Beta-User

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

drhirn

Darf ich's umdrehen? Zuerst commandref, dann ein Link zum Wiki? Das immer-gültige zuerst.

ph1959de

Hallo Beta-User, mal kurz zu Deinen Off-Topics:
Zitat von: Beta-User am 13 März 2018, 10:15:17
Das korrekte Einsortieren im Wiki scheint aber mit der "Modulbox" automatisch zu erfolgen (hat etwas gedauert, bis auch ich den Mechanismus vielleicht verstanden habe ::) ).
Ja, abhängig vom gewählten Modultyp wird automatisch eine Kategorie gesetzt; die Zuordnung weiterer Kategorien ist natürlich möglich, muss aber manuell erfolgen.
Zitat von: Beta-User am 13 März 2018, 10:15:17
Ob das in der Form zielführend ist, ist eine andere Frage.
In wiefern zielführend? Wie gesagt: das Setzen weiterer Kategorien ist möglich (und sicherlich auch sinnvoll, aber nicht automatisch über den Modultyp möglich).
Zitat von: Beta-User am 13 März 2018, 10:15:17
dass der bisher nur auf der Liste der gewünschten Seiten gestanden hatte
Das passiert "automatisch", sobald jemand irgendwo die Seite mit [[allowed]] verlinkt (oder allgemein einen Text in [[]] stellt, den es nicht als eigene Wiki Seite gibt; mögliche Gründe also: Tippfehler, echte Absicht, eine bestimmte Seite anzulegen, Gedankenlosigkeit, ...).
Zitat von: Beta-User am 13 März 2018, 10:15:17
Dafür gibt es eine Seite mit "gewünschten Kategorien", die leer ist...
Auch hier: passiert "automatisch", sobald jemand eine noch nicht vorhandene Kategorie setzt (kann natürlich auch ein simpler Tippfehler in einem Kategorienamen sein).
Zitat von: Beta-User am 13 März 2018, 10:15:17
Die Mindmap (die ist übrigens zu klein...
Die Mindmap war seinerzeit (vor Jahren) nur ein Hilfskonstrukt um die Kategoriestruktur zu visualisieren. Ich werde bei Gelegenheit noch mal suchen, ob es dafür hilfreichere MediaWiki Tools gibt (ich glaube, der damalige Wiki-Admin wollte die zu der Zeit existierenden Tools nicht benutzen - Gründe weiss ich nicht mehr; da sind wir aber jetzt u.U. mehr Freiheiten).
Zitat von: Beta-User am 13 März 2018, 10:15:17
Denn irgendwo sollte ja bei "Server" wenigstens die Option bestehen, "normale" x86-HW einzusortieren (Zotac, Brix, NUC und Co.).
Denen würde ich vorerst die Kategorie "Server" verpassen - sobald mehrere Seiten zu einem Thema in dieser Oberkategorie auftauchen, sollten wir über eine eigene Unterkategorie nachdenken.

Mach gern zu solchen Dingen einen eigenen Thread hier in diesem Forenbereich auf - lässt sich hier sicherlich leichter diskutieren, als auf Wiki (Diskussions-)Seiten.

Peter
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

nils_

Zitat von: Beta-User am 13 März 2018, 11:15:28
Done, wo vorhanden...
super

Zitat von: drhirn am 13 März 2018, 11:18:28
Darf ich's umdrehen? Zuerst commandref, dann ein Link zum Wiki? Das immer-gültige zuerst.
ist mir recht!


nur jetzt sind die links leider "kaputt" (siehe screenshot) :(
viele Wege in FHEM es gibt!

ph1959de

Zitat von: drhirn am 13 März 2018, 11:18:28
Darf ich's umdrehen? Zuerst commandref, dann ein Link zum Wiki? Das immer-gültige zuerst.
Gibt es einen Grund, warum Du in vielen Fällen den Namen des Befehls durch "commandref" ersetzt hast? Ich würde da den Befehl erwarten. So ist es etwas unübersichtlich und erst unterscheidbar, wenn man mit dem Mauszeiger über den Link geht (d.h. für Tablet-/Handy-Benutzer gar nicht?).

Peter
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

nils_

Zitat von: ph1959de am 13 März 2018, 12:03:52
Gibt es einen Grund, warum Du in vielen Fällen den Namen des Befehls durch "commandref" ersetzt hast? Ich würde da den Befehl erwarten. So ist es etwas unübersichtlich und erst unterscheidbar, wenn man mit dem Mauszeiger über den Link geht (d.h. für Tablet-/Handy-Benutzer gar nicht?).

vermutlich copy&paste-fehler

so wäre es (glaube ich) richtig
==Wichtige Befehle für die erste Zeit==
*{{Link2CmdRef|Anker=list|Lang=de|Label=list}} - ([[list|Wiki]])
*{{Link2CmdRef|Anker=define|Lang=de|Label=define}}
*{{Link2CmdRef|Anker=defmod|Lang=de|Label=defmod}}
*{{Link2CmdRef|Anker=version|Lang=de|Label=version}} - ([[version|Wiki]])
*{{Link2CmdRef|Anker=update|Lang=de|Label=update}} - ([[update|Wiki]])
*{{Link2CmdRef|Anker=shutdown|Lang=de|Label=shutdown}}
*{{Link2CmdRef|Anker=notify|Lang=de|Label=notify}} - ([[notify|Wiki]])
*{{Link2CmdRef|Anker=at|Lang=de|Label=at}} - ([[at|Wiki]])
*{{Link2CmdRef|Anker=sleep|Lang=de|Label=sleep}}
*{{Link2CmdRef|Anker=cancel|Lang=de|Label=cancel}}
*{{Link2CmdRef|Anker=watchdog|Lang=de|Label=watchdog}} - ([[watchdog|Wiki]])
viele Wege in FHEM es gibt!

drhirn

Uhh, sorry! Da hatte ich wohl einen Komplett-Blackout. Änder ich natürlich gleich!

Beta-User

Danke für die Erläuterungen, langsam wird das Bild auch an der Stelle etwas klarer.

Ich wollte (und will eigentlich auch weiterhin) keinen separaten Thread aufmachen. Das wäre für eine konkrete kleine Anwenderfrage ok, aber ich will nicht "das ganze Internet" diskutieren oder Grundsatzfragen aufwerfen, sondern "nur" die Dinge halbwegs ordentlich zu Ende bringen, die ich angestoßen habe...

Mit zielführend war gemeint, dass insbesondere "allowed" zwar irgendwie auch ein "Hilfsmodul" ist (so jedenfalls die Festlegung des Autors in der commandref), diese Kategorisierung aber aus Nutzersicht (Wiki...) welche Aussage haben soll? Die sachlich korrekte Sortierung entsprechend commandref ist ok, aber ich fände hier Stichworte wie "Sicherheit", "FHEM-Verwendung" (ist es das nicht irgendwie fast immer?) oä. hilfreich. Da ich aber eben in der (wie ich gelernt habe) automatisch erstellten Liste nichts gefunden habe, was ich ergänzend gerne unten reingeschrieben hätte, bleibt es eben bis auf weiteres ohne eine derartige Angabe.

Das mit den Kategorien in der "Server-Hardware" ist auch geklärt, das kommt eben schlicht daher, dass z.B. die beiden BBB-Varianten in anderen Artikeln als Kategorie angegeben sind und daher in "Unterkategorien" auftauchen und nicht unten bei "Seiten". Ob das jeweils Sinn macht, sei mal dahingestellt, denn einer der Artikel verweist nur auf sich selbst, die anderen behandeln Email-Themen unter (Debian-)Linux (also was generelles und völlig HW-unabhängiges), im anderen Fall geht es um das auch bei anderen SBC's bestehende Problem, wie mit einer (noch) fehlenden Systemzeit umzugehen ist...

Wie gesagt, darüber kann man insgesamt lange diskutieren, aber wie bereits gesagt: das ist nicht mein Anliegen...

Zitat von: drhirn am 13 März 2018, 11:18:28
Darf ich's umdrehen? Zuerst commandref, dann ein Link zum Wiki? Das immer-gültige zuerst.
Klar, hatte keine speziellen Hintergedanke bei der ursprünglichen Variante und die nils_-Fassung gefällt mir gut. @drhirn: Machst du dann damit c&p :) .

Zitat von: Christoph Morrison am 13 März 2018, 10:35:46
Ich votiere für "Quick Start". Ein Guide ist IMHO wieder etwas ausführlicher und findet sich eher im Erste-Schritte-PDF. Es geht ja wirklich erst mal nur darum, einen Überblick zu bekommen.
Leuchtet mir ein, auch wenn ich die damit bestehende "Nähe" zu "ersten Schritten" wieder nicht so klasse finde. Aber it's always compromizing...
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

ph1959de

Zitat von: Beta-User am 13 März 2018, 12:24:07
Mit zielführend war gemeint, dass insbesondere "allowed" zwar irgendwie auch ein "Hilfsmodul" ist (so jedenfalls die Festlegung des Autors in der commandref), diese Kategorisierung aber aus Nutzersicht (Wiki...) welche Aussage haben soll? Die sachlich korrekte Sortierung entsprechend commandref ist ok, aber ich fände hier Stichworte wie "Sicherheit", "FHEM-Verwendung" (ist es das nicht irgendwie fast immer?) oä. hilfreich. Da ich aber eben in der (wie ich gelernt habe) automatisch erstellten Liste nichts gefunden habe, was ich ergänzend gerne unten reingeschrieben hätte, bleibt es eben bis auf weiteres ohne eine derartige Angabe.
Ich verstehe was Du meinst - daher auch der Hinweis auf das was automatisch möglich ist.

Aber deine Ergänzungen zu dem Thema ... lassen mich fragen (mich selbst und auch andere - Christian/Krikan?), ob sich nicht aus dem überlicherweise auch über die Modul-Infobox verlinkten Forenbereich eine weitere sinnvolle Kategoriezuordnung ableiten lässt.

Peter
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

Beta-User

[Teilweise OT]
Zitat von: drhirn am 08 März 2018, 11:45:25
Andererseits könnte es uns davor retten, dass alle anfangen, FHEM auf Windows zu installieren. Ein Raspberry ist eine kleine Einstiegshürde.
Aus gegebenem Anlaß greife ich den Punkt auch nochmal auf. (Vorab: ich habe keine umfangreiche Analyse gemacht, sondern gebe mal wieder nur Eindrücke wieder)

Stand der Dinge ist der, dass
- ein Einsteiger (verstanden als versierter Windows-Nutzer) immer noch sehr gut beraten ist, als Serverplattform ein (ggf. virtualisiertes) Linux zu wählen und einen Bogen um das zu machen, was er kennt (OS X-Anwender sind da außen vor). Die meisten Anleitungen (wie diese hier auch) gehen dabei standardmäßig davon aus, dass ein recht aktuelles Debian-Derivat (idR. Raspbian) läuft, oft eben auf einem Pi.
- dies nirgends im Wiki ausdrücklich oder jedenfalls deutlich erkennbar in die Richtung leitend steht.

"Früher" war das etwas anders, da gab es eine andere "Lieblingsplattform" für Einsteiger (von AVM), auf die dann so verwiesen wurde, dass Leute, die anderes vor hatten (Windows) zumindest die Chance hatten zu erkennen, dass sie damit von eben diesem (Linux-basierten) Standard abweichen werden und ggf. in entsprechende Probleme laufen.

"Heute" sollte es so sein, dass ein installationswilliger Mensch entweder wirklich
- frei wählen kann, welche Basis er nehmen will (hat er jedenfalls nach meiner Kenntnis eigentlich halt doch nicht oder nur unter Inkaufnahme erheblicher "Schmerzen") oder
- Hinweise erhalten sollte, wie er zweckmäßigerweise vorgehen sollte.

Die "gemischten Gefühle" zum Thema Pi kann ich  sehr gut nachempfinden - Themen wie die Frage, ob das gewerblich da Werbung wäre, über die Schlagworte SD-Karten, RTC und (vor allem) der Vermischung von Steuerung und Hardware bei Nutzung der GPIO's kann man lange und ausführlich diskutieren. Auch ist sowas immer irgendwie subjektiv, was gegen die allg. Wiki-Prinzipien wäre. Dennoch werde ich das Gefühl nicht los, dass man dazu irgendwo (bzw. ggf. an mehereren Stellen) ein paar einfache und klare Worte verlieren sollte. Vielleicht nicht einseitig zugunsten des Pi (ich habe nicht umsonst Versuche mit anderer HW gemacht und mein FHEM läuft jetzt auf einer anderen Plattform), aber bislang fehlt mir da eine zündende Idee.

Stellen, an die sowas ggf. gehören könnte: "Planung" (hat eigentlich einen ganz anderen Fokus, jedenfalls soweit man das bei diesem stub schon erkennen kann) und "Server Hardware" (Die Einleitung ist hier "sehr neutral" und fängt an mit: ...Windows). Die Installationsanleitung für Windows ihrerseits schweigt sich dazu aus, dass das eher als "experimentell" zu bezeichnen ist (Jedenfalls gibt es weder vorne noch hinten einen optisch deutlich wahrnehmbaren Hinweis dazu)...

Aber vielleicht übersehe ich ja auch was und der Selbstversuch von "the ratman" gibt doch nicht den aktuellen Stand der Dinge zu Windows wieder?

Zitat von: ph1959de am 13 März 2018, 12:37:56
Aber deine Ergänzungen zu dem Thema ... lassen mich fragen (mich selbst und auch andere - Christian/Krikan?), ob sich nicht aus dem überlicherweise auch über die Modul-Infobox verlinkten Forenbereich eine weitere sinnvolle Kategoriezuordnung ableiten lässt.
Wäre Automatisierung - bringt m.E. auch keinen wirklichen Mehrwert für Wiki-Leser.
Eine stringentere Vorgabe in den Kategorien wäre m.E. angezeigt, zumal das mindmap ja auch alles andere als aktuell zu sein scheint (ich habe es nur in Teilen angesehen und mich gefragt, warum z.B. FHEMWEB nicht als Frontend aufgeführt wird und wie die willkürliche HW-Auswahl bei den Servern zustande kam).
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

curt

Zitat von: Beta-User am 13 März 2018, 10:15:17
Zu allowed:
- Es gibt jetzt eine kurze Einleitung und eine "Einführung". Der Beitrag ist immer noch kurz und knackig, aber immerhingibt es ihn jetzt (s.u.).

Ich finde den Artikel jetzt ziemlich prima. Auf den ersten Blick wird ohne Schnörkel klar um was es geht und wie man es macht. So stelle ich mir alle Artikel für Anfänger vor.

Einen Satz würde ich anders fassen, so: "Es wird dringend empfohlen, für den Webserver FHEMWEB mithilfe des Attributes HTTPS eine HTTPS-Verbindung zu aktivieren."

Zu telnet bin ich mir nicht sicher. Also erstmal ganz unabhängig von jeder Doku: Braucht der gemeine FHEM-Admin denn telnet? Gibt es da sinnvolle Anwendungen?

Ich selbst dachte immer (immer ist gut, ich bin ein halbes Jahr dabei): Oh, telnet, das wird wohl ein Rudiment aus "es ist halt so gewachsen" sein. Und ich dachte immer: Wenn man das umschubst, fällt das niemandem auf.

Also aus meiner subjektiven Sicht braucht das der Anfänger nun überhaupt nicht. Eher ist das Problem, dass das wohl mit der Erstinstallation in der fhem.cfg ist. Wenn dem so ist, wäre es wohl klug, dem Nutzer zu erzählen, wie man telnet ausschaltet.

P.S: Quick-Start
RPI 4 - Jeelink HomeMatic Z-Wave

Beta-User

Danke für die Rückmeldungen.

Habe das HTTPS-Thema als Empfehlung in leicht modifizierter Form (kann mehrere FHEMWEB-Instanzen geben) übernommen, und der Artikel findet sich jetzt hier, nachdem die Namensgebung eine recht eindeutige Tendenz unter den Beteiligten Diskussionsteilnehmern aufweist.

Die englische Fassung ist daher auch hier bereits online gegangen. Da es zumindest zum Thema plotting auch bereits einen englischen Beitrag gibt, wäre es vermutlich das einfachste, das so zu basteln, dass man nur mit ein paar erläuternden Worten dorthin verlinkt - wenn nicht jemand schneller ist, schaue ich mir das bei Gelegenheit mal an...
EDIT: kurz gesehen, und da steht daneben: Veraltet...
Der in dem Hinweis verlinkte Artikel scheint aber wieder nur auf deutsch verfügbar zu sein - vielleicht mag den ja jemand übersetzen... Und das eine oder andere (einfache) grafische Beispiel sagt an der Stelle mehr als 1000 Worte.

footer: allowed. Für den Rest verzichte ich heute, da ist der Beitrag nicht lang genug, als das sich das lohnt 8) .

Gruß, Beta-User
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

drhirn

Zitat von: curt am 14 März 2018, 03:51:41
Zu telnet bin ich mir nicht sicher. Also erstmal ganz unabhängig von jeder Doku: Braucht der gemeine FHEM-Admin denn telnet? Gibt es da sinnvolle Anwendungen?

Hab ich in diesem Thread auch schon mal gefragt. Weil ich's nämlich auch noch nie verwendet habe ;). Aber leider keine Antwort bekommen.

Beta-User

Zu telnet versuche ich als Blinder mal von Farbe zu reden:

1. Die Diskussion ist hier m.E. falsch aufgehoben: Derjenige bzw. die Leute, die entschieden haben, dass FHEM standardmäßig mit dieser Schnittstelle in der fhem.cfg ausgeliefert wird, finden diese nach wie vor erforderlich. Ergo kann es vorliegend nur darum gehen, nachvollziehbar darzustellen, dass da eine Schnittstelle ist, die man folglich sinnvollerweise absichern sollte.

Damit ist das folgende ausdrücklich [OT]:
2. Ob das anders sein sollte, ist eine zweite Frage. Für telnet würde ich sagen: tendenziell erhalten und - wie vorliegend ja auch erfolgt - lieber einfach erklären, dass man das mit absichern sollte.
- Erstens gibt es nach meiner Wahrnehmung einige angeflanschte Lösungen, die diese schnelle, texbasierte und das System vergleichsweise wenig belastende Schnittstelle nutzen, um Infos darüber auszutauschen (u.a. TabletUI _könnte_ darauf basieren). Also werden wenigstens technische Experten es schätzen, wenn sie nicht danach suchen müssen, ob sowas vorhanden ist.
- Zweitens könnte auch das FHEMWEB-Modul ja mal kaputt sein oder das System sonst langsam reagieren (letzteres hatte ich schon mal bei Hitzeproblemen). Dann hat man eben eine zweite Alternative, die deutlich weniger Prozessorleistung erfordert und zumindest Notmaßnahmen ermöglicht. Finde ich nicht verkehrt.

3. Bevor also telnet nicht mit ausgeliefert und dargestellt wird, würde ich initialUsbCheck standardmäßig deaktivieren - jedenfalls auf arm-Rechnern. Das scheint bei Pi3-Modellen nämlich zu verhindern, dass das System überhaupt hochfährt, und das fällt nicht unbedingt in die Kategorie "einsteigerfreundliche Lösung"...
Vorteile bringt es auch nur bei CUL&Co., die wiederum Techniken bedienen, die man auch nicht unbedingt in den Vordergrund stellen sollte (da wären wir indirekt wieder beim Thema "Sicherheit") - FS20 und 433MHz-"Gruscht" (ausdrücklich pers. Meinung, bitte keine Kommentare von mir bekannten InterTechno-Liebhabern ;) ). Für HM gibt's eigentlich für Anfänger besser zu handhabende Lösungen, und alles andere muß sowieso mit Bedacht konfiguriert werden.

Damit will ich's aber auch - jedenfalls von meiner Seite - sein Bewenden haben lassen ::) .

Und nochmal ausdrücklich: Das ist m.E. alles [/OT]

Gruß, Beta-User
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