Beiträge von marco.gr

Zitat von McLoud

Damit funktioniert auch die Auswertefunktion nicht richtig. Wieviel habe ich tatsächlich vom Energieversorger in den letzten 24h bezogen.

Den Workaround von tvbshelly werde ich mir bei Gelegenheit mal ansehen.

Beim Verbrauch innerhalb von 24h hat mich gestört, dass der 3EM im Vergleich zur Messeinheit nicht saldiert. Er misst zwar ausreichend genau was über welche Phase wohin geflossen ist, er weiß aber nicht ob sich Bezug und Einspeisung aus Sicht der Messeinrichtung aufgehoben haben.

Hierzu hab ich seit letzte Woche ein Script im Testbetrieb. Das Script versucht über die minütlichen Messdaten eine Annäherung an die tatsächlichen Werte zu erreichen. Das Ergebnis der Berechnung ist erstaunlich gut und von den Rahmenbedingungen Abhängig.

Bei Interesse bereite ich das Thema nächstes Wochenende auf, sobald ich ein paar Messdaten gesammelt habe.

Auch wenn dieser Thread schon älter ist - ich hatte gerade das selbe Problem "rund 50% Abweichung" und einen Fehler in meiner Verkabelung gefunden.

In irgendeinem Anfall von Selbstsicherheit hatte ich wohl an stelle des Anschlussdiagramms ein beliebiges Foto aus dem Internet angesehen .
Wahrscheinlich dachte ich, ist ja nicht mein erster PM Mini.

Erkenntnis:

Wenn man an einer einer 0 Klemme zusätzlich L anschließt und an der anderen die Steckdose, so misst man an einer Mini PV Anlage ungefähr -68 Watt anstelle der gerade eingespeisten ~150 bis 180 Watt.
Wenn wir hier den Eigenverbrauch vom Mikrowechselrichter und Toleranzen abziehen trifft es "rund 50% Abweichung" sehr gut.

Wenn man Fehler macht sollte man auch dazu stehen und anderen helfen.

Hallo Muck77 ,

bei elektronisch gesteuerten Fußbodenheizungen verwendet man die Ventilstellungen auf oder zu. Also 0% oder 100%. Aufgrund der Trägheit einer Fußbodenheizung ist auch gar nichts anders sinnvoll. Auch ein Regelalgorithmus ist hier nicht sinnvoll. Deine Fragestellung zeigt mir, dass du das bereits erkannt hast.

Einen hydraulischen Abgleich können wir für das Thema Regelung erstmal ausklammern. Denn dieser dient ja nur dazu, dass du eine gerechtere Verteilung auf die Heizkreise untereinander ermöglicht wird.

Um es auf den Punkt zu bringen: Der interne Regelalgorithmus vom Shelly BLU TRV ist derzeit absolut ungeeignet für eine FBH. Allerdings lässt er sich deaktivieren und Ersetzen.

Wenn du Geduld mit mir hast, kann ich dir mein FBH Script von meinem Shelly Pro 4 auf das Gen3 Gateway + BLU TRV anpassen.

Viele Grüße,

Marco

Zitat von apreick

Hm, der topic war falsch

Jetzt wo du den passenden herausgefunden hast, verstehe ich auch die Dokumentation.

Je mehr ich von der Dokumentation lese, desto weniger verstehe ich:
https://tasmota.github.io/docs/MQTT/#mqtt-topic-definition

Ich kann nur deine Screenshots frei interpretieren.

Der komplette Topic sollte <prefix>/sharky775v2_db6b60/cmnd/restart lauten.
Gibt es irgendwo eine Konfiguration für den Prefix?

Prüfe mal, ob sich unter 'Full Topic' ein String ohne Platzhalter, wie z.B: 'mein-topic-test' speichern lässt und teste mit:

mein-topic-test/cmnd/restart

Als RPC über HA, hier mit 22°C und BluTRV ID 201:

http://192.168.xxx.xxx/rpc/BluTrv.call?id=201&method=Trv.SetTarget&params={id:0,target_C:22}

(Die BLU TRV ID siehst du in der URL, wenn du auf Settings Seite vom TRV bist - oder über RPC Befehl Shelly.GetComponents)

In Zukunft ist es mit neuer Shelly Firmware und HA Version auch als Automatisation möglich.

Die Schedules, welche du suchst sind bei den TRV Settrings im Webinterface versteckt

Einfach das TRV anklicken und bis ganz nach unten scrollen. (z.B.: http://192.168.xx.xx/#/blutrv/200/settings)

Zitat von Flutschi

Wieso ist das eine kritische Anwendung?

Ich habe nicht behauptet, dass DIESE Anwendung kritisch ist. Das kann man natürlich auch anders interpretieren.

Die eigentliche Information sollte dennoch aus dem Post hervorgehen: Eine autarke Lösung hat eine höhere Ausfallsicherheit.

Der Gedanke zu diesem Hinweis kam mir, weil mir auf einer Schulung ein Brandfahnder von einem Großbrand durch eine Stalllampe berichtete.

Für mich persönlich wäre der Stromverbrauch der Lampe bei Ausfall vom WLAN ein ausreichender Grund für ein Script.

Mit Sicherheit, ich kenne nur keine passende URL:

Nach deinem Thread bleibe ich mal lieber bei der 2.3.2 - auch wenn das aktuelle Update weitere Bugs beheben sollte.
Vielleicht solltest du nach einem Link auf die letzte 2.2.x Version suchen. Diese lief meines Erachtens recht stabil.

Bei kritischen Anwendungen würde ich immer ein autarkes Script auf dem Shelly empfehlen.
Selbst bei guter WLAN Verbindung.

Klar macht das mehr Aufwand und muss auch sauber umgesetzt sein, dafür gewinnst du an Zuverlässigkeit und Stabilität.
Dank virtueller Komponenten kann man per WLAN Parameter anpassen, manuell Schalten oder den Zustand überwachen.

Deshalb auch von mir die Frage: Mit was hast du das denn bisher umgesetzt?

Das was du als "Longpush aktiv" bezeichnest, verstehe ich als "alle Lampen an". Der Longpush ist ja nur ein kurzes Ereignis.

Ich versuche deinen Wunsch unabhängig von der verwendeten Technologie darzustellen:

Single Push an Shelly X:
	- Falls Shelly X aus, schalte Shelly X ein
	- Falls Shelly X an, schalte ALLE Schelly aus

Longpush an Shelly X:
	- Schalte ALLE Schelly ein	

Bei diesem Vorgehen hast du nur eine einzige, einfache Bedingung. Somit ist es wie Schubbie schon sagte einfach umzusetzen.

Ich weiß jetzt nur nicht wie Gen1 Geräte genau reagieren. Hier sehe ich noch ein Fehlerpotential. Gen2+ Geräte müsstest du 'detachted' betreiben, damit sie nicht direkt reagieren.

In der alten (1.x ?) Firmware gab es die Möglichkeit eine statische IP zu vergeben. In der neuen gibt es nur noch DHCP.

Dies führte bei mir und anderen nach dem FW Update zu Problemen.
Bei mir hat Zurücksetzen geholfen.

Ich verstehe es noch nicht.
LONGPUSH ist doch bei Shelly ein Wert und keine Variable? Diese wird in Events als Momentaufnahme verwendet und ist nicht dauerhaft?

Wenn du lediglich per MQTT auf einen Longpush reagieren möchtest, um mehrere Shellies einzuschalten, musst du doch nichts zurücksetzen.

Mit welchen MQTT Befehlen arbeitest du? Hier gibt es ein paar grundlegende Unterschiede.

Hallo pcfriesede ,

deine Frage ist mir noch viel zu unverständlich.

Zitat von pcfriesede

Ich habe bereits ein Shelly 1PM, der per Url seine Daten an ein Script auf meiner Homepage liefert und visualisiert,

Ich verstehe nicht, wie du das aktuell machst. Meine PM Shellies bieten mir keine Variablen an, welche ich per URL und Action senden könnte.
Kannst du uns davon einen Screenshot der WebUI schicken?

Zitat von pcfriesede

Wie muss z.b. die URL aussehen wenn ich die Gsamtleistung oder sie von einzelnen Phasen a z.b. http://www.beispiel.de/Script.php senden will, was muss dahinter stehen ?

Welches Parameter deine Ziel URL enthält, können wir nicht Wissen, denn diese ist von deinem individuellen Ziel abhängig. Also wohl von deinem Script.php File. Hier müsstest du einen "PHP Menschen" um Rat fragen.

Beim Absenden deines HTTP Requests zum Ziel kann dir hier bestimmt jemand helfen.

Ich erinnere mich. Das sollten Kombinationen aus Rücklauftemperaturbegrenzer und Raumthermostaten sein.
Hier sehe ich nur ein aufwendiges Script als Lösungsansatz.

Das passt allerdings in diesen Thread so gar nicht rein.

Was verstehst du unter einer möchtegern Fußbodenheizung?

Ich kenne FBH ohne, welche statt einem geregeltem FBH Kreis nur einen Rücklauftemperaturbegrenzer haben.
Und es gibt welche bei denen am Rücklauf eines Heizkörpers noch ein paar Schlaufen verlegt wurden.

In diesen Fällen würde ich einen hydraulischen Abgleich empfehlen. Falls das Theromstat-Oberteil das nicht unterstützt, auf ein Oberteil mit Voreinstellung wechseln oder am Rücklauf das Absperrventil etwas weiter Schließen.

Zitat von MichaelGo

Das Deaktivieren funktioniert bei mir jedoch nicht.

Ich habe es mir nochmal angesehen, und eine Methode zum Ermitteln der korrekten ID gefunden:

http://192.168.xx.xx/rpc/Shelly.GetComponents

Diese Methode liefet eine sehr umfangreiche Liste. Am besten suchst du hier nach dem Namen deines TRVs. Bei mir ist es 'blutrv:202':

    {
      "key": "blutrv:202",
      "status": {
        "id": 202,
        "target_C": 21.4,
        "current_C": 22.8,
        "pos": 0,
        "rssi": -51,
        "battery": 100,
        "packet_id": 21,
        "last_updated_ts": 1739256749,
        "paired": true,
        "rpc": true,
        "rsv": 28
      },
      "config": {
        "id": 202,
        "addr": "f8:xx:xx:xx:xx:xx",
        "name": "TRV HomeOffice Slave",
        "key": null,
        "trv": "bthomedevice:208",
        "temp_sensors": [],
        "dw_sensors": [
          "bthomesensor:217",
          "bthomesensor:229"
        ],
        "override_delay": 30,
        "meta": {

        }
      },
      "attrs": {
        "flags": 17,
        "model_id": 8
      }

Im Block Config siehst du dann die bthomedevice id, welche du zuerst verwendet hattest.

Diese Daten spiegeln wieder, was das Gateway über die Komponenten weiß. Den Status, ob im BLU TRV das Thermostat aktiviert ist, sieht man hier nicht.
Wenn du kontrollieren möchtest, ob die Thermostat Funktion im BLU TRV deaktiviert ist, benötigst du die BluTrv.Call Methode.

http://192.168.7.89/rpc/BluTrv.Call?id=202&method=TRV.GetConfig&params={id:0}

{
  "id": 0,
  "enable": false,
  "override_enable": true,
  "min_valve_position": 0,
  "default_boost_duration": 1800,
  "default_override_duration": 2147483647,
  "default_override_target_C": 8,
  "flags": [
    "anticlog"
  ]
}

Die BluTrv.Call Methode kommuniziert direkt mit dem jeweiigem BLU TRV und dessen Firmware.

Wenn das jetzt zu viel war, dann erstelle ich gerne einen dezidierten Thread mit einer Schritt für Schritt Anleitung.

Zitat von JSE222

Mir wäre z.B. nicht klar wie der Tempsensor eingebunden wird: Per Kopplung ans GW oder direkt mit dem Master-TRV.

Der Slave richtet sich nach dem Master. Und diesen kannst du konfigurieren wie du möchtest.

• Nur interner Sensor
• Externer und interner Sensor kombiniert
• Nur externer Sensor

Beim Slave spielt es für die Regelung keine Rolle.
Da er (Slave) auch für die Temperatureinstellung genutzt werden kann, habe ich hier einen externen Sensor angebunden, um einen korrekten Wert angezeigt zu bekommen.

Zitat von imautohutraeger

Das ist für mich leider mit zuviel Bastelkram verbunden, das ich nicht gut genug verstehe, um es effizient anpassen zu können. Es muss zuverlässig ohne Wenn und Aber für die ganze Familie funktionern

Verstehe ich absolut!
Danke für dein Feedback.