Beiträge von JoergZ

    Kann ich eigentlich von einem Tasmota Werte ,per MQTT, auf ein anderes Tasmota schicken ohne einen Broker?

    Nein. MQTT ist ein Client-Server-System. Tasmota-Geräte sind immer und ausschließlich Clients. Sie können an einen Broker (= Server) Nachrichten eines bestimmten Topics senden (publish) und ein anderes Gerät kann ein bestimmtes Topic abonnieren (subscribe). Der Broker ist ein "man in the middle" und zwingend erforderlich. Ein Raspberry Pi kann gleichzeitig Broker und MQTT-Client sein aber nicht ein Tasmota-Gerät.

    Wenn nur ein Wert gesendet werden soll ist MQTT wohl oversized.

    Ganz bestimmt nicht. MQTT ist ein extrem schlankes und robustes Protokoll und zum Austausch von Nachrichten (Werten) zwischen Geräten und anderen Instanzen hervorragend geeignet. Und alle gängigen Hochsprachen haben Module, Bibliotheken oder wie es auch immer in der jeweiligen Sprache heißt, um MQTT-Nachrichten auszuweten bzw. zu senden. Zu allen anderen Themen kann ich nichts sagen....

    Findet sich was Auffälliges unter:

    Telefonie -> Eigene Rufnummer -> Sprachübertragung (z. B. hohe Jitter-Werte)

    oder

    Internet -> DSL-Informationen -> Störsicherheit: mal auf Maximale Stabilität stellen und ein paar Tage beobachten.


    Stören sich WLAN und DECT? Dazu habe ich gefunden:

    Zitat

    DECT sendet im Bereich von 1880 bis 1900 MHz. WLAN liegt in Europa im Bereich 2412 bis 2472 MHz. Die Frequenzbereiche liegen also recht weit auseinander, sollte also kein Problem darstellen.also wohl eher nicht.


    EDIT: Das habe ich noch gefunden: https://www.golem.de/1109/86670.html Vielleicht ist es die Mikrowelle....

    wificonfig 2 macht m. E. nur Sinn bei der Erstkonfiguration bzw. bei der Integration in ein anderes WLAN, dennes startet ja jedesmal einen eigenens Accesspoint. Das ist im Dauerbetrieb eher störend. Danach kann er sich wahrscheinlich nur mit dem WLAN1 verbinden (habe ich nicht getestet).

    Da ich Node-Red nicht kenne nur so als fragende Anregung: Wir wäre es, bei allen Geräten, die gleichzeitig schalten sollen, dasselbe grouptopic zu definieren. Damit könnten man alle Geräte auf einmal ansprechen. Beispiel als MQTT-Ausdruck:

    cmnd/GROUPTOPICNAME/Power 1


    Falls man ein Grouptopic in Node-Red als Gerät einrichten kann, geht das. Dennoch bleiben alle Einzelgeräte schaltbar.

    savedata sollte immer auf 1 stehen, es sei denn du willst was ganz spezielles ausprobieren, bei dem du befürchtest, es könnte dir alles zerschießen. Dann erst savedata auf 0, ausprobieren und wenn alles ok ist, wieder savedata 1 eingeben. Wenn savedata auf 1 steht und du den tempoffset eingerichtet hast, überlebt der Korrekturwert einen Restart/Stromausfall.

    Ja genau.

    Und das am besten mit unterschiedlichen Zeiten an unterschiedlichen Wochentagen

    So weit ich es überblicke, wird es mit Tasmota Scripting schwierig. Aber damit kenne ich mich nicht aus. Vielleicht kann gemu2015 dazu mal eine Einschätzung abgeben. Ich für meinen Teil würde so etwas mit MQTT und Python machen. Vermutlich geht es auch mit IOBroker und Co. Du solltest erst einmal einen Plan machen, wann was passieren soll und welche Bedingungen dabei erfüllt sein müssen. Dann gibt es vielleicht präzisere Antworten als diese hier.

    Nur zur Klärung: Meinst du folgendes: Wenn die Grundsteckdose erst nach 10 Uhr einschaltet und die aktuelle Uhrzeit ist größer gleich 10:00 UND kleiner gleich 16:00 Uhr, dann schalte die Tasmota-Steckdose ein (und um 16:00:01 Uhr wieder aus).

    Hi, ein Paar Tips kannst du auch hier finden. Das ist ein Artikel über das Smart Home.

    Sieht für mich eher nach einem Werbelink für Standardprodukte aus. Kaufen und machen lassen, kann man viles. Hier ist eher DIY gefragt. Bitte verschone uns mit solchen Links.

    Als ebenfalls Pelletheizungsbetreiber möchte ich zu bedenken geben, dass die Staubentwicklung im Pelletbunker erheblich ist - insbesondere beim Einblasen. Das könnte eine Laser basierende Messeinheit "blind" machen. Also mindestens müsste der Sensor gut erreichbar sein und ein Staubwischen ;-) immer möglich bleiben. Weiter Optionen: Ultraschall, Gewicht (unterhalb der Pellets angebracht). Habe aber keine Erfahrung mit solchen Sensoren.

    Hoffentlich ist es nicht ein grundsätzliches Speichermanagement-Problem. Auch 4 oder 8 GB können volllaufen. Dauert zwar eine Weile, schaun wir mal. Grundsätzlich ist der RPi 4 mit 4 GB eine feine Sache. Habe da die Spracherkennung Mycroft (Picroft) drauf laufen, was eine richtig fette Python-Anwendung ist. Es läuft auf dem kleinen genauso gut wie auf meinem Desktop (i7 4700 mit 16 GB).

    Wie gesagt, keine Ahnung von IOB, aber was du sagst, leuchtet ein. Andererseits ist SSH nicht so ein Speicherfresser und recht schlank und es soll schließlich eigentlich "immer" funktionieren, damit man mit dem Host immer noch was machen kann aus der Entfernung und sei es ein Neustart. Aber wenn es mal geht und mal nicht, dann muss man sich mit solchen try and error - Verfahren und Beobachtung von Situationen herantasten, um herauszubekommen, woran es wirklich liegt. Beim Raspi auch immer wieder für Überraschungen gut: schlappe Stromversorgung. Also mal dmesg und journalctl einsetzen und nach undervolting Ereignissen suchen.

    Ok, Mem ist gut voll aber m. E. noch nicht bedrohlich voll. Gegen Überlastung spricht auch Taktfrequenz und Temperatur. Wobei es schon besser wäre, diese Parameter über einen längeren Zeitraum zu beobachten. Wenn möglich Raspi neu booten und nach ca. 5 Minuten die Erreichbarkeit testen. Bis dahin sollten alle Prozesse hochgefahren sein. Mal die oben ermittelten Werte mit den dann aktuellen vergleichen. Vielleicht schaukelt sich da was auf, was man durch gelegentliche Neustarts "einfangen" könnte. Mir ist in den Daten oben nichts wirklich Auffälliges begegnet, außer der relativ hohen Prozess- und Zombiezahl. Aber ich habe keine Ahnung vom IOB und was der alles braucht.