Beiträge von marco.gr

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.

Zitat von JSE222

Bei mir habe ich daher geplant die Heizung komplett zu steuern

Das ist zum Energiesparen ein sehr guter Punkt. Ich lasse momentan noch die Finger davon. Zu viele Abhängigkeiten zur Cloud oder batteriebetriebenen Geräten. Und wenn, dann würde ich das nur für die Übergangszeit aktivieren.

In meinem früheren Leben als Heizungsbauer hatte ich mal ein komplett eingefrorenes Schulgebäude mit geplatzten Leitungen. Der Hausmeister hatte in den Weihnachtsferien die Heizung ausgestellt. Dann kam ein richtiger Winter. Zwei Wochen lang selten wärmer als -10 Grad.

Aber gerne zurück zum Thema, ich bin gespannt, was der TE oder andere zum eigentlich Topic zu berichten haben.

Zitat von JSE222

Die Regeltätigkeit des einen ist Störgrösse für den jeweils anderen.

Ich habe zwar meine damaligen Diagramme nicht mehr zur Hand, aber ich kann es nochmal mit folgender Beobachtung unterstreichen:

Es gibt Phasen, in denen der TRV das Ventil kurz auf über 60% öffnet und zeitnah wieder schließt. Dadurch scheint er bewusst zu lernen.
Wenn man das neue Spielzeug gerade beobachtet sollte man wirklich geduldig sein. Sonst ist man als Anwender selbst der Störfaktor Nummer 1.
Auch Türen möglichst geschlossen halten kann bei einem kleinen Raum zum kalten Flur hin der Regelung helfen "ihren Weg zu finden".

Wenn du nun einen zweiten Heizkörper hast, der exakt in dieser Ruhephase heizt spielen die TRVs mehr oder minder Ping Pong miteinander.
Oder wie es mir erging, einer war immer stark dominant und der andere hat nahezu nie geheizt.

Und ich gebe auch Schubbie und weiteren recht: Wenn man sich hier zu viele Gedanken macht und permanent beobachtet verfällt man schnell dem Wahnsinn.
In vielen Räumen und Situationen wird man die kleinen Unterschiede auch nicht merken, wenn man nicht zu sehr darauf achtet.

Allerdings habe ich auch den Eindruck, dass der Regelalgorithmus vom Shelly eine Spur "übermotiviert" ist. Gerade wenn mal die Tür offen Stand oder plötzlich die Sonne hinter den Wolken hervorkommt.

Ich selbst bekomme es leider viel zu sehr mit, da ich im HomeOffice arbeite. Bei einer sitzenden Tätigkeit nimmt man Temperatur anders war, als wenn man sich bewegt.

Man darf durchaus festhalten, Perfektionismus führt bei einem Regelalgorithmus (in diesem Fall) zur Lösung, und schon gar nicht, wenn dieser eine Blackbox ist, welche man von außen beobachtet.
Deshalb greife ich mit meiner Lösung auch nicht in den Regler ein, sondern versuche ihm einen Störfaktor zu nehmen.