Zum Thema MQTT Update Intervall verkürzen gibt es verschiedene Lösungsansätze:
Erstens via Scripting, das ist für alle esp Controller möglich.
Zweitens via Berry Scripting: das ist nur für esp 32 Controller möglich, bietet aber die größten Freiheitsgrade.
Vielleicht lässt sich die Aufgabe auch auch mit Rules lösen, welche für alle Plattformen verfügbar sind . Johann
@Lötauge
Ich habe zusätzlich noch einen Offset beim Taupunkt-Vergleich berücksichtigt, sonst dauert das Entfeuchten ewig.
pasted-from-clipboard.png
Johann
Ich habe die letzten Tage eine Taupunkt-geführte Entfeuchtung via Ablüfter auf Tasmota-Basis mit Shelly Plus 1 erstellt.
Anstelle eines Sensors für Feuchte und Temperatur im Aussenbereich verwende ich die Wetter-API von
mit lokalisierten Daten.
Die API ist vorbildlich
Den Taupunkt berechne ich in meiner Applikation selbst.
Open-Meteo ist das mit Abstand Beste, was ich in Sachen Wetter-API bisher gefunden habe.
Damit kann man meiner Meinung nach auf den Aussen-Sensor verzichten.
Vielleicht hilft die Anregung für die weiteren Überlegungen.
Gruß Johann
Bei den Szenen werde ich dir nicht weiter helfen können, da ich diese nicht verwende.
Generell setze ich für die Steuerung der Hausautomatisierung nicht auf die Cloud. Gerne, wenn ich etwas (z.B. im Urlaub) überwachen will.
Dafür sind manche Themen einfach zu "ernst". So darf die Funktion meiner Heizung nicht davon abhängen, ob der Shelly-Server gerade verfügbar ist.
Vielfach wird an dieser Stelle auf Smart-Home-Systeme, wie NodeRed, IOBroker oder HA verwiesen. NodeRed verwende ich selbst.
Man ist zu Testen von neuen Ideen super schnell. Aber am Ende hängt alles vom Funktionieren des SmartHome-Systems ab.
Ich komme immer mehr dazu, die Logik direkt in die Geräte (Shelly + CO) zu verbauen und die SmartHome-Systeme nur für Monitoring, Visualisierung und Bedienung zu nutzen.
Aber es ist sehr gut, daß du dir abseits der Standardlösungen der Heizungsbranche gedanken machst. Und es kann sich auch lohnen.
Ich werde meinen Verbrauch an fossiler Energie wohl halbieren können, dank dieser Projekte:
Gruß Johann
Servus Flo,
ich habe vor Jahren mit einer UVR65 gearbeitet.
Das beschriebene Verhalten der UVR67 wäre bei korrekter Parametrierung der UVR67 ein Fehler der Firmware.
Der TA-Support hat bei mir auf Fragen sehr schnell und kompetent reagiert.
Hast du das schon versucht ?
Die Firmware wird immer wieder mal aktualisiert. Bist du hier auf dem letzten Stand ?
Ansonsten beschäftigen wir uns beide mit ähnlichen Themen.
Gruß Johann
Ich verwende Athom Plug V3 mit Tasmota32. Damit ließe sich meiner Meinung nach das Vorhaben problemlos umsetzen.
Hier gibt es, Neues zu berichten.
In diesem Beitrag zeigt Theo Arends wie es ihm gelungen ist, das Addon zu integrieren.
Das neue Feature ist dann wohl ab der Version 13.4 integriert.
Hallo Toni, du bist der erste im Forum, der sich dafür interessiert. Dokumentation habe ich noch keine erstellt.
Grüße Johann
Bleibt nur noch die zweite Frage: hat jemand eine Idee um Info “Überschuss vorhanden” von Huawei an Shelly zu bekommen?
Dazu ist zu klären welche "offenen" Schnittstellen der Huawei anbietet (Schaltkontakt, Netzwerk-Schnittstelle mit Protokoll, WEB-API).
Ich selbst lese den digitalen Haus-Stromzähler mit Tasmota + IR-Empfangskopf aus um Information zum Überschuss zu erlangen.
Dieser sendet diese dann an MQTT und/oder via UDP-Broadcast an alle Netzteilnehmer, die dann selbst entscheiden, darauf zu reagieren.
Johann
Hier habe ich den Regler für die Null Einspeisung beschrieben.
Das ist ein Beispiel für die Integration eigener Elemente in die Oberfläche von Tasmota.
Interessant sind auch Vergleiche zwischen Tasmota32 mit Berry und der Shelly Firmware mit JavaScript Möglichkeiten. .... Leider gibt es dort die von mir gerne genutzten Schedule Jobs nicht. Ich täte es begrüßen, wenn die Shelly Firmware auch auf sonstigen ESP32 Boards nutzbar wäre.
Zur Ehren-Rettung von Berry:
Mit tasmota.add_cron gibt es ein Kommando, welches analog zum linux-cron Befehl funktioniert.
tasmota.add_cron("*/1 * * * * *",...Via Duck-Typing kann jede beliebige Klasse registriert werden, die folgende Methoden aufweist und dann automatisch bei den every_-Methoden aufgerufen wird.
class MyDriver
def every_50ms()
end
def every_100ms()
end
def every_250ms()
end
def every_second()
# do something
end
...
end
d1 = MyDriver()
tasmota.add_driver(d1)Dann gibt es noch die klassischen Timer.
def TimeOutHandler()
print ("start TimeOutHandler")
end
var TimerName="myTimer"
tasmota.remove_timer(TimerName)
tasmota.set_timer(3000, TimeOutHandler,TimerName);Natürlich kann man auch einen Event-Handler via Rule auf die kalendarischen Timer setzen.
def ClockTimerHandler(value, trigger)
print ("!!! Power2Handler: value:",value," and trigger:",trigger)
end
tasmota.add_rule("Clock#Timer", ClockTimerHandler)Unter Tasmota kann man alle Scripte in eine Zip-Datei packen und hochladen.
Es ist also problemlos möglich pro Klasse mit 1 Datei zu arbeiten.
Sehr hilfreich finde ich auch die Möglichkeit via "assert" Test-scripte zu schreiben, um die eigenen Software automatisiert zu testen.
Tasmota bietet die Möglichkeit die bestehende UI durch eigenen Elemente zu erweitern.
Aber natürlich kann man auch eine komplett neue Seite erstellen.
Vor vielen Monaten habe ich mein Glück mit Mongoose versucht. Es waren jedoch noch sehr viele Bugs drin. Die Frustration war zu groß.
Wie du auch schon erwähnt hast, lassen sich viele Dinge (z.B. PWM) nur mit Tasmota lösen.
Aber cool wenn es nun besser läuft mit Mongoose
.
Die Skripting-Sprache der Shelly Gen. 2 Serie ist angelehnt an Javascript.
NodeRed ist in JavaScript programmiert und verwendet dieses selbst als Script-Sprache.
(Java hilft hier übehaupt nicht weiter)
Das wären gute Gründe den Javscript Kurs zu wählen.
Java spielt im IOT-Bereich bei den Scripting-Sprachen keine Rolle.
Grüße
Johann
Wobei das was da alles an unterschiedlichen Komponenten die Freigabe Schaltet schreit ja nur nach Fehlern. Dafür gibt es auch Komplette Steuerungen die dafür gebaut wurden und auch entsprechend erprobt sind.
Wenn man gerne bastelt und damit Leben kann das es mal Kalt ist dann ok aber ansonsten würde ich das so nicht umsetzen wollen.
Kesseltemperatur-Regler, Heizungs-Regler und Abgasklappe sind vom Hersteller des Kessels vorgegeben. Die Raumluftklappe verfügt über eine DVGW-Zulassung und muss nach Vorgaben, wie dargestellt in die Sicherheitskette eingebunden werden.
Die einzige "Bastell"-Nummer ist das Relais K1, welches von Shelly angesteuert wird.
Darauf zu verzichten würde die Einsparung von 12.000 kWh fossiler Energie pro Jahr zunichte machen.
Die Konstruktion ist übrigens schon mehrere Jahre störungsfrei im Einsatz.
Lediglich der Gasfeuerungsautomat musste schon mehrfach getauscht werden.
Danke Euch beiden für die Kommentare. Das hilft immer auch die eigenen Entscheidungen zu hinterfragen.
Die 5 Temperaturen am Addon sind nur informativ?
Nein, die meisten werden im Steuerungs- und Regelungs-Mechnismen vom SmartHome-System eingesetzt.
Die Bilder Shelly 2.5 sind doch bestimmt Plus 2PM?
aktuell sind noch 2.5 V1 verbaut, aber spätestens, wenn auch die analogen Werte via Shelly erfasst werden, wechsle ich auf die Plus Variante.
Die Heizkreispumpe ok, aber die Ladepumpe steuern?
Die induktive Lasten sorgen auch mal für Ausfälle (Reboots), da sollte ein Snubber/RC-Filter dran.
Die Ladepumpe wird eigentlich nicht mehr benötigt, da ein Heizstab für die Warmwasser-Bereitung verwendet wird.
Im Winter unterstützt die Ladepumpe den Heizstab, indem diese immer dann aktiviert wird, wenn auch der Brenner aktiv ist.
Im Sommer benötigt der Heizstab 4 kWh /Tag. Durch diese Maßnahme reduziert sich in der Heizphase der Tagesbedarf auf 2 kWh/Tag.
Die Steuerung dieses Verhaltens erfolgt über das SmartHome-System.
Die Heizstab-Lösung führt zu einer Reduzierung von 5000 kWh an fossiler Energie. Der eingesetzte Strom (1000 kWh) wird zum einem großen Teil via PV geliefert.
Danke für den Hinweise zu Snubber/RC. Die Wilo HE-Pumpe verursachte bisher keinerlei Probleme.
O1 von Shelly B ist Detached und auf AutoOff parametriert. Damit wird K1 nicht angesteuert und somit das T1 Signal weitergeleitet.
Das SmartHome System muss also immer wieder den On Befehl senden, um die Weiterleitung von T1 zu verhindern.
2. Ist das noch nach DVGW?
Ein Stück Draht wird durch einen Öffner ersetzt, keine Ahnung, ob das DVGW konform ist.
Meine 30 Jahre alte Viessmann Trimatic MC versieht immer noch tapfer ihren Dienst.
Ersatz gibt es nur noch gebraucht via Ebay.
2 Shellies unterstützen das alte Teil schon jetzt.
Für eine noch umfassendere Datenerfassung, Anlagen-Manipulation und Ersatz beim Ableben der alten "Dame" habe ich folgenden Plan ersonnen.
( bis auf den analogen Teil ist alles andere schon Bestand)
Das Hydraulik-Schema meiner Anlage ist sehr einfach.
(die rot markierten Position sind relevant)
Alle Sensoren, Ein/Ausgänge sollen über Shelly-Hardware abgebildet werden. Hierzu folgender Plan.
Zum Einsatz kommt 2x Shelly Plus 2 PM, einer davon mit Addon für die analogen Werte.
Die Sicherheitskette sieht dann aus wie abgebildet.
Jedes Element der Sicherheitskette kann das Einschalten des Gasfeuerungsautomaten verhindern.
Das Öffnen von K1 via Shelly B ist über das Totmann-Schalter-Prinzip realisiert. Sollte also irgend etwas im WLAN/Smart-Home-System nicht funktionieren,
wird der Kontakt geschlossen und der alte Heizungs-Regler bzw. KTR übernimmt als Fallback die Kontrolle.
Die Aktoren sind angeschlossen, wie am Beispiel der Heizkreispumpe gezeigt.
Damit kann der Status erfasst werden, zusätzlich die Pumpen-Leistung.
Weiterhin kann man nun via Smart-Home manipulierend eingreifen.
Mit 2 Shellies+ Smart-Home läßt sich somit eine komplette Heizungsregleung ersetzen inklusive Fallback (via KTR).
Woher weißt Du denn, welche Integrationszeit der Zähler hat?
Das habe ich im ersten Ansatz empirisch über die Schwankungen direkt an der Anzeige des Zählers ermittelt. Wenn sich in der Phase der Kompensationen weder Bezug noch Lieferzähler ändern ist man gut dabei.
Die Integrationszeiten der bisherigen Zähler lagen vermutet zwischen 0.5 und 1.5 Sekunde.
Systeme wie Fronius Ohmpilot oder TA Aton verfolgen das gleiche Ziel.
Die vorliegende Lösung ist im Vergleich dazu unschlagbar günstig und universeller einzusetzen.
Nach meinem Verständnis ist doch lediglich der Verbraucher schwingungspaket-gesteuert, nicht jedoch die Einspeisung?
Ja das ist so. Der Zähler saldiert über alle Phasen. In der Wellenpause „sieht“ er daher Überschuss. Die Position des Verbrauchers und Wechselrichters ist unerheblich.