Beiträge von JoergZ

    Leider nur eine Ergänzung bzw. Kommentar: Teleperiod hat in der Tat keinen Einfluss auf die Tasmota interne Ereignis"wahrnehmung". Vermutlich bringt auch das Abschahlten der Weboberfläche nichts. Ich vermute Folgendes: Jeder Sensorwert ist ein potentieller Trigger. Weil das so ist, sorgt die Firmware dafür, dass Sensorwerte möglichst nah am realen Ereignis festgestellt werden. Das geht ja nur mit einer angemessen hohen Abtastrate, die vermutlich tief im Quellcode der Firmware verankert ist.

    Ich werde demnächst das Tutorial entfernen, weil Snips nicht mehr zugänglich ist - von Sonos aufgekauft. Dafür habe ich mich mit Mycroft resp. Picroft befasst, was ich auch einsetze und mir bereits zwei Skills für die Tasmota-(=MQTT-) Sprachsteuerumg bzw. die Sprachsteuerung diverser Internetradios (MPD) selbst programmiert habe. Läuft alles bei mir zuhause ganz gut. Für Mycroft gibt es eine sehr aktive Community, Schnittstellen (angepasste Skills) z. B. für Homeassistant und IOBroker gibt es bereits. Wenn ich wieder mehr Zeit habe, schreibe ich vielleicht ein Tut für Mycroft. Mycroft selbst ist zu 100 Prozent OpenSource aber es arbeitet nicht ganz cloudless, weil z. B. Google Translate genutzt wird. Dies geschieht jedoch in einer durch Mycroft anonymisierten Form und scheint mir einigermaßen sicher.

    Ich habe mir schon gedacht, dass diese Frage kommt. Ich kann dir im Moment nur kurz antworten. Du schickst den Prozess in den Hintergrund, indem du ein & anhängst:

    mosquitto_sub -v -t stat/+/POWER >> meinstatus.log &

    Das Terminal zeigt dir dann eine Prozessnummer an. Mit kill Prozessnummer stoppst du den Hintergrundprozess. Eleganter ist es einen systemd Startjob anzulegen. Das ist nicht schwer. Google einfach nach "eigenen systemd dienst anlegen". Den benutzt du, um dein Bash-Skript bzw den mosquitto_sub Aufruf schon während des booten zu starten und der läuft dann permanent im Hintergrund.

    Wäre es mit Rules nicht zB möglich, dass die Tasmota Geräte zu jeder Änderung ihres Status (also wenn von On auf OFF geschaltet wird oder umgekehrt) eine kurze Meldung an den Broker schicken

    Das machen die Geräte doch sowieso. Dazu brauchst du keine Rules. Du musst nur das Topic stat/+/POWER subscriben. Wenn du dieses schreibst:

    mosquitto_sub -v -t stat/+/POWER >> meinstatus.log

    schreibt die mosquitto_sub die Meldungen in die Datei meinstatus.log. Die Datei kannst du dir dann mit nano meinstatus.log anschauen.

    Interessant viellicht auch dies (mit Datum und Uhrzeit):

    mosquitto_sub -t stat/+/POWER -F "%I %t %p" >>meinstatus.log

    Jedenfalls ist dieses Tasmota eine unglaubliche MQTT Quasselstrippe.

    Naja, das kann man so oder so sehen. Bei meinen Tasmota (ESP8266) Geräten ist es bei teleperiod 0 erstaunlich ruhig. Da werkeln aber auch keine rules und kein Sensor will was mitteilen. Wenn deine rules Zustände abfragen oder Zustände ändern, dann ist das für den Broker schon interessant. Denn möglicherweise gibt es einen Abonnenten, der etwas wissen will. Ich denke, es ist eher der Zweck von MQTT, Mitteilungen zu produzieren. Allerdings gehen die nur bis zum Broker, wenn sonst keiner (subscriber) was wissen will. Von der Datenmenge her sind die JSON-Schnipsel ja Peanuts. Da ist vermutlich der Kommunikationsoverhead, der unsichtbar in einem WLAN permanent hin und her gejagt wird, wesentlich umfangreicher.

    Ich will ja gerade den Tasmota-Automatismus durch meinen eigenen ersetzen. Dies bezieht sich auch auf die MQTT Topics, in denen ich qualifizierte Namen einbaue, um so flexibel eine Hierarchie aufbauen und pflegen zu können,

    Wenn du so tief eingreifen willst, musst du vermutlich tatsächlich eine eigene Firmware programmieren, die mit deinen eignen Begriffen kommuniziert. Hast du mal ein paar Beispiele für eigenen Topics. So recht verstehe ich noch nicht, was das Problem ist. Nicht, dass ich eine Lösung hätte - es interessiert mich einfach.

    Code
    mosquitto_sub -t stat/Dose1/#
    oder
    mosquitto_sub -t stat/Dose1/Power

    interessant ist auch der Schalter -v. Das zeigt dir an welches Gerät was sendet z. B.

    Code
    mosquitto_sub -v -t stat/+/Power

    würde dir Änderungen des Power-Staus aller Geräte anzeigen.

    Oder muss ich das über mosquitto_sub machen, weils ja eigentlich ein lauschen und kein senden ist...?

    So sieht's aus. Allerdings musst du dem ein mosquitto_pub ...vorausschicken, damit die Antwort "abgehört" werden kann, denn mosquitto_sub kann ja nur was ausspucken, wenn vorher eine Message für das abonnierte Topic gesendet wurde. Vielleicht kommst du mir einem Bash-Skript mit curl schneller zum Ziel oder mit Python und der Bibliothek paho-mqtt dort besonders die Methoden publish.single() und subsribe.simple().


    Und wenn ich das mal habe, würde ich gerne den Status aller Switches in einer Abfrage haben, also nicht nacheinander jeden einzelnen abfragen, sondern sowas wie

    Naja, das schreit ja gerade zu nach einer Schleifenprogrammierung (oder dem Abonnieren (= subsriben) mehrer Topics).

    Als Beispiel für eine mögliche Bash-Programmierung, die stumpf Gerät für Gerät abfragt. In diesem Beispiel gehört zu jedem Gerät genau ein Switch. Die Switches müssen exakt in derselben Reihenfolge aufgeführt werden wie die Geräte. Wenn du pro Gerät mehrere Switches abfragen willst, sieht das natürlich anders aus. Das musst du natürlich chmod +x dateiname ausführbar machen und mit ./dateiname starten.

    Bash
    #!/bin/bash
    geraete=( geraet1 geraet2 ) #Hier deine Topics benutzen
    switches=( POWER1 POWER1 ) # Hier den switches in der Reihenfolge der Topics
    for (( i=0 ; i<${#geraete[@]} ; i++))
    do
    mosquitto_pub -t "cmnd/${geraete[$i]}/${switches[$i]}" -n
    done

    in einem zweiten Terminalfenster lässt du dann mosquitto_sub laufen und abonnierst +/stat/POWER oder +/stat/#. Leider ist mosquitto_sub "blocking", d. h. wenn das Programm läuft geht in dem Terminal nichts anderes. Deswegen braucht man zwei Fenster. Ich hoffe, das bringt dich etwas weiter.

    In dem Falle könntest du das einfach mit Dioden entkoppeln.

    In die Richtung habe ich auch gedacht. (Sperr-) Dioden setze ich jetzt auch schon an den Endabschaltern oben und unten ein, damit nur noch in die andere Richtung gefahren werde kann, wenn ein Ende erreicht ist. Mein Problem ist der Umschalter. Der sitzt ja jetzt vor dem Auswahlschalter für Gruppe 1, 2 und 3 (4, 5). Wenn ich deine Zeichnung richtig verstehe, funktioniert die Schaltung genau dann, wenn Plus und Minus so anliegen wie gezeichnet (bzw. du hast es ja nur auf geschaltetem Plus bezogen). Wenn die Pole aber getauscht sind, also in der Zeichnung ein Minus zum Auswahlschalter führt, dann lassen die Dioden doch keinen Strom durch, oder?

    Ich habe eine Innenraumverschattung gebaut für insgesamt 15 Fensterelemente. Diese sind zusammengefasst zu je 5 Fenstern, also in drei Gruppen. Angetrieben wird die Verschattung durch 12 Volt Gleichstrommotoren. Der Richtungswechsel (auf/ab) wird durch Umpolen mittels eines entsprechenden Schalters erreicht. Zudem habe ich einen Auswahlschalter, mit dem ich Gruppe 1 ODER Gruppe 2 ODER Gruppe 3 ansteuern kann .


    Nun meine Frage: Gibt es eine Möglichkeit es mit einfacher Schaltungstechnik zu erreichen, dass ich als weitere Schaltoptionen noch die Varianten Gruppe 1 UND Gruppe 2 gleichzeitig fahren lassen kann bzw. Gruppe 1 UND Gruppe 2 UND Gruppe 3. Der Auswahlschalter hätte noch ein paar Positionen frei.


    Vielleicht hat einer der Elektrotechniker eine Idee bzw. weiterführende Tipps.

    Kennt jemand eine Möglichkeit alle 4 Kanäle gleichzeitig schalten - ich meine tatsächlich gleichzeitig, so als würde ich mehrere Geräte mit demselben Grouptopic ansprechen. Diese schalten nämlich ohne spürbare Verzögerung. Eine Rule schaltet mit deutlicher Verzögerung die Kanäle nacheinander durch, auch ein (Bash-) Skript mit 4 MQTT-Befehlen ist zwar schneller aber doch deutlich nacheinander. Ich suche also so etwas wie ein Grouptopic für alle 4 Kanäle .

    Die Tasmota-Geräte können nur mit einem MQTT-Broker kommunizieren, aber mehrere Broker können untereinander kommunizieren und die Messages über Netzwerkgrenzen hinweg (MQTT Bridge) austauschen.