Chaot : Danke, finde ich sehr gut! Gutes Beispiel für die Aufgabe des "Lektors"
Beiträge von JoergZ
-
-
Wow! Das geht aber jetzt ab hier! Toll! Herzlichen Dank HoerMirAuf für den Aufschlag zu den rules! So umfangreich habe ich es nicht gedacht - macht aber Sinn, wenn es etwas mehr als eine Übersetzung sein soll. Super Beispiele!
Zur Organisation mache ich mal folgenden Vorschläge.
Arbeitsplattform
Wir nehmen GoogleDocs als Arbeitsplattform. Muss ich noch kennenlernen. Wird schon gehen. Können wir deinen Account dafür nutzen HoerMirAuf ? Wie kommen wir anderen darauf? Lädst du uns ein oder wie geht das?
Arbeitsteilung:
Ich habe die Commands Seite auf 16 Tabellenblätter einer LibreOffice-Calc Tabelle verteilt, wobei das Programm völlig egal ist, mir kam es nur auf die Struktur an. Diese Blätter sind:
Main | Sensor | Timers | Management | Wifi | MQTT Specific | Serial Bridge | SeptOption Overview |
Logging | POW, S31 und Pzem004T | WS2812, AiLight, Sonoff Led, B1, BN-SZ01, H801 and MagicHome |
WS2812 Led string specific | Sonoff RF Bridge 433 | Domoticz | KNX | IRemote |
Meine Vorstellung: Wir melden unser Interesse an, bestimmte Themen als "Autor" komplett zu bearbeiten. Und wir geben ein, zwei Themen an, wo wir uns als "Lektor" anbieten, d. h. wir lesen den Text von jemand anderem gegen und machen evt. Veränderungsvorschläge.
Ich würde z. B. Main (habe ich schon angefangen), MQTT Specific und Domoticz als "Autor" bearbeiten und als "Lektor" z. B. SetOption Overview und Logging (oder was anderes) ko-bearbeiten.
Und dann gibt's da Dinge, von denen habe ich noch nie gehört: BN-SZ01, KNX...
Struktur der Artikel
Da können wir die Methode von HoerMirAuf als Blaupause übernehmen: Kurze Beschreibung des Sinns und der Bedeutung der Befehle, Funktions- und Wirkungsbeschreibung der Befehle (Referenz) anschließend Beispiele. Das wird unterschiedlich lang sein, da manche commands selbsterklärend sind, z. B. Power On
Begriffsklärung und Begriffsvereinheitlichung
Es kann sein, dass wir ein Dokument brauchen, in dem wir bestimmte Begriffe klären. Beispiele: Wie nennen wir den anliegenden Strom (nicht den geschalteten Strom): Versorgungsstrom oder Netzstrom oder wie? Wie nennen wir das Schaltelement Relais oder Schalter? Ich habe noch keinen Überblick wie groß dieses Problem ist. Es gibt aber eine Stelle, da taucht es mit Sicherheit auf: Wenn jemand SetOption Overview bearbeitet dann hängt es mit vielen anderen Abschnitten zusammen, da die SetOptions sich quer durch alle commands verteilen.
Um mit was Konkretem zu enden, können wir das Projekt bei HoerMirAuf hosten? Wer würde welche Themen als "Autor" bzw. als "Lektor" übernehmen?
-
NoitaercX , Chaot und Supermicha
ihr habt so viele Nägel auf den Kopf getroffen, ich kann allem nur zustimmen- ABER warum soll man nicht den Versuch wagen etwas daran zu ändern. Deswegen finde ich es gut, wenn mehrere mitwirken. Folgende Aufgabengebiete sehe ich:
Änderungen und Ergänzungen: Wir brauchen so eine Art Versionskontrolle. Keine Ahnung wie man das macht
Struktur des Originals: Historisch gewachsen, manchmal merkwürdig was zu Main gehört und was zu Management z. B.
Verwendung von (Fach-) Begriffen: Kontrolle auf Richtigkeit bzw. Angemessenheit, 2. Kontrolle: Konsistenz: Werden immer dieselben Begriffe für dieselben Sachverhalte verwendet
Schnittstellen (MQTT, IOBroker,...) Manches kann man nur verstehen, wenn man etwas über die dahinter stehenden Systeme vermittelt.
Beispiele: Beispiele für Verwendungsszenarien (z. B. bei Rules) und Beispiele für die Syntax bzw. Verweis auf weiterführende Informationen wie Struktur und Syntax von JSON
Seltene Hardware: Erst einmal weglassen?? um Denglisch zu vermeiden.
In diesem Sinne, Packen wir's an schreibt Nobby doch immer, oder so
-
Hey urmel76 , ich hatte gehofft, dass auch du mitmachst! Das freut mich! Bisher habe ich die Originaltexte auf 16 Tabellenblätter einer Libreoffice-Calc Tabelle verteilt. Das könnte z. B. eine Struktur für eine arbeitsteilige Herangehensweise sein. Jeder nimmt sich ein oder ein paar Tabellenblätter vor. Ich würde ganz gern den Gedanken noch etwas reifen lassen, wie die "Referenz" aussehen könnte und diesen Vorschlag mit den Mitmach-Bereiten besprechen. Solange warte ich dann auf jeden Fall noch auf weitere Mitmacher.
Martin Hesse Hallo Martin, schau dir mal bitte diesen Thread hier an und sag uns, was du von dem Vorschlag von Sascha in Beitrag #9 hältst.
-
Mein Wunsch wäre natürlich eher, dass nach frei vereinbarten Absprachen oder nach fachlichen Kenntnissen bzw. nach vorhandenen Geräten mehrere Leute parallel arbeiten: Einer macht den Abschnitt Main, ein anderer Sensors, ein dritter MQTT usw. Wenn ich das alleine mache, braucht es entsprechend lang. Ich kann eben nicht pausenlos daran arbeiten.
Ich persönlich hätte da lieber ein deutsches Tutorial für die Commands bzw Rules incl Deutsch erklärter Beispiele usw. ....
Genau das schwebte mir auch vor, nicht nur eine Überstezung und deshalb müssen ein paar mehr Kollegen (Kolleginnen scheint es hier nicht zu geben) mitmachen, die fachlich mehr drauf haben als ich. Wir wärs's mit dir HoerMirAuf ? Ein paar Beispiele und Erklärungen könntest du doch bestimmt beitragen, oder? Es gibt ja noch ein paar mehr Leute, die häufig Antworten in diesem Forum liefern, und deren Mitwirkung ich mir wünschen würde, aber ich will keinen bedrängen.
-
Supermicha hat natürlich recht. Ich möchte damit nur eine Hilfestellung zum Selbermachen für die deutschsprachigen Amateure wie mich einbringen. Natürlich bleibt die Befehlssprache englisch! Dafür gibt es einen Berg wirtschaftlicher, technischer, kultureller und linguistischer Gründe.
-
Mit der Baudrate hätte es aber auch leicht ins Auge gehen können. Aber es hat ja funktioniert. (Das Problem lag dennoch mit Sicherheit an einem Konfigurationsfehler in Atom oder nicht richtig in den Flash-Modus geschaltet. Es ist ziemlich egal, womit du flasht, wenn die Parameter stimmen und die Kabel richtig stecken und die Schalter im richtigen Moment und in der richtigen Länge gedrückt werden. Dann klappt's mit allen Programmen. )
-
Aufgrund eines Erlebnisses zu einer Fragestellung in einem anderen Subforum dieser Site, kam bei mir wieder der Gedanke in den Vordergrund, in diesem Forum eine deutsche Übersetzung der Tasmota-commands anzufertigen. Ich würde es ungern alleine tun, schon allein aus dem Grund, weil ich a) nicht alles verstehe und b) auch bei Dingen, die ich zu verstehen glaube, nicht unbedingt die treffende Übersetzung finde, weil es dafür fachsprachliche Ausdrücke aus IT, Elektronik und Elektrotechnik gibt. Mit mehreren kann man sich die Arbeit aufteilen und ein bisschen gegenseitig Korrektur lesen
Hätte jemand Interesse daran mitzuwirken?
-
-
Kann man so machen, aber ich halte es für besser klar definierte Befehle zu geben als indirekte, die davon ausgehen, dass ein bestimmter Zustand nach einem Restart gegeben sind. Meine Methode kann dann zusätzlich bedeuten, dass man erst einmal prüft, welcher Zustand gerade herrscht, und dann das ausgelöst wird, was man möchte.
Wenn du mit Fhem arbeitest, scheinst du dich ja zumindest ein bisschen mit perl auszukennen. Damit kann man das Thema ganz sicher auch bearbeiten. Es geht aber auch mit cron und/oder bash und/oder curl mit den Protokollen http oder mqtt.
-
Laäuft MQTT bei dir z. B. auf einem Raspberry Pi, bzw. hast du einen Server, der ständig läuft? Dann nimm cron. Mit cron kannst du nach einem von dir bestimmten Zeitplan etwas ausführen lassen, z. B. ein MQTT publishing für Off bzw. On abschicken. Ich würde mit cron ein Bash-Sript aufrufen, dass dann nach soundsoviel Sekunden/Minuten wieder den "Gegenbefehl" schickt. Geht aber auch nur mit cron.
-
Weder automatisch noch manuell. Zum Vergleich: Welchen Sensortyp wählst du für den TH10 aus? Ich habe Temp+Hum. Und was beim POW? Hast du sowohl MQTT_Discovery und MQTT-Client installiert?
-
So ist mir die Installation des Plugins domoticz_mqtt_discovery gelungen:
Download des aktuellen Raspbian-lite Image (2018-10-09) von raspberrypi.org
Grundreinrichtung über raspi-config (ssh, Lokalisierung, File system expand). Anschließend reboot
Download von Domoticz ins Benutzerverzeichnis pi mit:
Überprüfen, ob Domoticz läuft
Überprüfung der Python-Version und gegebenenfalls Installation nachfolgender Pakete:
Codepython3 -V #Ergebnis: python3.5.3 sudo apt install libpython3.5-dev sudo apt install libpython3.5 sudo apt install python3.5-dev #letzteres vermutlich entscheidend, da die anderen Pakete bereits vorhanden waren sudo reboot
Danach stand das Modul MQTT Discovery auf der Seite Hardware der Domoticz-Administrationsseite zur Verfügung. Ich vermute, dass das Plugin erst ab der Python-Version 3.5.3 auf dem Raspberry läuft. Die vorangegangenen erfolglosen Versuche waren auf einem Jessie-System mit Python 3.4.
Nicht so schön ist, dass nun die Sensoren für Temperatur und Luftfeuchtigkeit des TH 10 und die Strom-/Spannungswerte des POW nicht mehr in Domoticz ausgelesen werden. Ich hoffe, es gibt bald ein Update...
Edit (16.11.2018): Wenn man den mitgelieferten MTTQ-Client-Gateway with LAN interface zusätzlich installiert, können die Sensoren wieder ausgelsen werden.
-
Ich habe mindestens 3 Geräte (2 Mal Basic, 1 Mal S20), die mindestens ein halbes Jahr ohne je vom Netz genommen worden zu sein, mit 5.12 gelaufen sind. Ob die Geräte selbst einen spontanen Neustart durchgeführt haben, kann ich nicht sagen. Mittlerweile ist überall 6.2.1 drauf - läuft...
Dennoch: Sonoff/Tasmota ist nicht geeignet und spezifiziert für den Einsatz auf Intensivstationen und in Atomkraftwerken, will sagen: die Restrisiken sind einfach etwas höher Andererseits: Was haben wir hier alles schon von stundenlangen Server-Downs bei ewelink gelesen. Dagegen läuft doch Tasmota wie ein Schweizer Uhrwerk, oder?
-
nur den Schritt
-eine Hardware: MQTT discovery anlegen-übersprungenMeinst du damit, den Eintrag MQTT-Discovery aus der Auswahlliste auf der Seite Hardware auszuwählen und zu konfigurieren? Wenn das so ist, hilft es mir leider nicht, denn bei mir erscheint der Auswahlpunkt einfach nicht in der Liste.
-
elute Wenn's dir nichts ausmacht, sag doch mal, was du gestern übersehen hast. Es sind ja häufig die kleinen Fehler. Und ich bekomme es auf einem Rechner nicht an's Laufen und bin für jede Idee dankbar.
-
Hast du das frisch reingeclonte Plugin, also die plugin.py auch mit
ausführbar gemacht? Darüber hinaus ist es mir auf dem Produktivsystem auch noch nicht gelungen, das Plugin verfügbar zu haben.
Einen kleinen Einwand/Bedenken hätte ich schon jetzt: Das Aktivieren des Homeassistant-Gedöns mit setoption19 1 läßt den MQTT-Traffic "explodieren". Dauernd haben die Geräte was zu erzählen, und in welcher Menge. Aber anders kann man wohl derzeit keine Kontrolle gewinnen.
-
Bei jedem Gerät.
-
plugins ist korrekt und so heißt es auch bei mir.
Einen kleinen Erfolg kann ich schon vermelden: Auf einem Experimentiersystem (Raspberry 3b+, Raspbian lite Stretch, Python 3.5) habe ich nach Installation des Paketes python3.5-dev die neue Hardware zur Verfügung. Nun erscheint MQTT Discovery. Mal schauen, ob ich mein Produktivsystem auch überreden kann das Plugin zu benutzen.
-
mit der Beschreibung und Github hat die Installation auf dem Raspi 5 min gedauert.
Na toll! Ich hatte das Plugin auch bereits entdeckt und bekomme es aber nicht aktiviert. Was auch immer ich tue, es erscheint einfach kein MQTT_Discovery in der Hardware-Liste, Dort steht nur der "normale" MQTT-Client. Was mache ich bloß falsch? Ich habe es unter Jessie mit Python 3.4 (und 3.7) und unter Stretch mit Python 3.5 probiert.
Domoticz ist im Home-Ordner installiert, das Plugin-Verzeichnis heißt also in /home/pi/domoticz/plugin.
In plugin liegt nach der Installation das Verzeichnis domoticz_mqtt_discovery und darin die Datei plugin.py. Die Rechte sind auf 755 gesetzt. Die Sonoffs haben individuelle Topics - und trotzdem bekomme ich das plugin nicht aktiviert. Domoticz neu gestartet bzw. kompletten Reboot des Systems. Ich bekomme die neue Hardware einfach nicht angezeigt. Hast du noch einen Tipp für mich?