Beiträge von firebowl

Zitat von Frank Berges

Guten Morgen

Schau mal hier !

Shelly TRV: /status – API Reference

Shelly TRV: /thermostats/0

Attribute	Type	Description
pos	number	Position of the valve, 0..100 and -1 if not calibrated. Setting position to arbitrary value disables automatic temperature control

Per MQTT könnte man den Zustand des Ventiles kontrollieren wenn man es den möchte.

Möglicherweise hilft dir das weiter.

Ich mache alles per MQTT und da geht das. Ob das beim Shelly-Adapter auch geht kann ich nicht sagen.

Ostergrüße aus dem Sauerland

Alles anzeigen

Versteh nicht ganz was Du mir sagen möchtest. Natürlich seh ich die % Werte, genau das macht es ja so seltsam. Die Ventile sind laut MQTT und Cloud zu 0% geöffnet aber warm. Wenn die TRVs nicht mehr richtig schließen könnten wegen zu wenig Kraft, dann würde ich da keine 0% sondern 5% oder 1% erwarten.

Interessant, dass Du scheinbar immer sehr schnell beleidigt bist wenn dir jemand widerspricht.

Erklär doch bitte wie es an der Schwergängigkeit liegen kann, wenn es nach einer Kalibrierung wieder funktioniert. Ich möchte das verstehen und vielleicht bin ich ja auf dem Holzweg.

Wie gesagt, ich wäre direkt bei dir wenn es ab meinetwegen 80% permanent nicht mehr funktionieren würde.

Aber auch dann würde ich eine entsprechende Meldung erwarten. Die TRVs "wissen" ja wie weit der Weg ist, den sie das Ventil maximal bewegen können. Wenn das plötzlich nicht mehr geht, dann muss ich sowas melden können.

Er kann es ja schließen, genau das ist doch der Punkt. Lasse ich eine Kalibrierung laufen, dann ist alles wieder für ein paar Tage oder Wochen gut. Nach deiner Theorie dürfte das nicht funktionieren.

Wenn das nicht funktionieren würde, dann wär ich bei dir.

Außerdem sind meine Ventile nicht schwergängig, sind immer schön mit Silikonspray eingesprüht.

Ist aber doch vollkommen egal wie schwergängig die Ventile sind oder wie oft geregelt wird. Von mir aus darf der Akku bei "mehr Arbeit" weil Ventil schwergängig oder oft geregelt wird schneller leer werden aber es darf nicht sein, dass er ab genau 80% nicht mehr richtig arbeitet und man es nur mitbekommt wenn es brühwarm ist oder man es selber überwacht (wie ich jetzt).

Einer meiner TRVs hat vom 08.04.23 16:00 bis jetzt 10.04.23 8:35 Ladung von 99% auf 92% verloren. Ein zweiter TRV, der den gleichen Raum heizt und vom gleichen Plus H&T mit Daten versorg wird ist im gleichen Zeitraum von 99% auf 96% gefallen. Ist halt das doppelte.

Blockly Scripts laufen, ist doof aber lieber bekomme ich Benachrichtigungen und kann die TRVs laden als das sie wieder nicht richtig schließen. Hoffe die fixen das mit nem Update.

nicx* ich Bau mir jetzt erstmal ne Benachrichtigung für das unterschreiten von 80% damit ich rechtzeitig laden kann.

Zitat von nicx*

firebowl das problem habe ich bei manchen trvs auch, sobald diese unter ca. 80% akkustand fallen. nach Vollladung funktioniert es wieder. blöderweise ist 80% nicht wirklich "wenig". ich muss da glaube ich mal ein Bugticket bei Shelly anlegen.

Hab gerade mal die drei betroffenen TRVs angeschaut und alle haben teilweise sehr knapp weniger als 80%. Muss aber ein Softwarebug sein, eine Kalibrierung behebt das Problem ja wieder für ne gewissen Zeit.

Hab teilweise das Problem, dass meine TRVs angeblich geschlossen sind aber der Heizkörper trotzdem warm ist. Starte ich manuell eine Kalibrierung dann passt wieder alles. Hält dann ein paar Tage bis Wochen und dann kommt es wieder vor. Also kann es kein Problem mit dem Hub oder dem Motor sein. Sieht für mich wie ein Softwareproblem aus.

Nicht die große Menge, sorry falls sich das anders angehört hat.

Hab fünf im Haus verteilt

Das Python wüsste ich gerade nicht wo oder wie ich es laufen lassen kann.

Ich glaube die Shelly Variante funktioniert so eher suboptimal bis überhaupt nicht.

Hab mal alle meine TRVs eingetragen und bei allen kommt permanent die timeout Meldung, obwohl alle immer erreichbar sind. Klar, es dauert ein paar Sekunden bis sie aufgewacht sind aber ich kann alle sowohl übers Webinterface als auch über MQTT ansprechen.

Freu mich schon auf deine Weiterentwicklung.

Zitat

Das heißt, dass das TRV mit der IP 192.168.178.115 nicht erreichbar ist. Schlechtes Wlan.

Wie ist den de RSSI Wert?

Der RSSI Wert ist -74dBm (-71dBm laut Fritzbox).

Per Web und icmp ist er aber normal erreichbar.

Das Problem ist mal wieder die Meshthematik. Fast in direkter Sichtlinie 3 oder 4 Meter entfernt ist ein LAN gebundener Accesspoint aber verbunden hat sich der TRV mit einem anderen einen Stock tiefer.

Nach nem Reboot -57dBm aber wieder beim falschen Accesspoint. Aber wie geschrieben, per Web und icmp isser erreichbar.

Keine Ahnung ob das Zufall ist, bei mir laufen die ersten TRVs seit ein paar Monaten und das ohne jegliche Probleme. Drei davon werden von zwei Plus H&T mit Temperaturdaten versorgt. Der eine, der sich gestern aufgehängt hat, wird auch von einem Plus H&T versorgt und ist gerade mal zwei Wochen in Betrieb.

Gestern Abend hat plötzlich einer meiner Motion2 nicht mehr reagiert. Also die LED hat Bewegung gemeldet aber der Motion2 war nicht mehr erreichbar. Es half dann nur noch der harte Reset mit Neueinrichtung. Zum Glück hatte ich die http calls noch in nem Texdokument gespeichert.

In der Script Console bekomme ich folgenden Eintrag:

timeout 192.168.178.115 06:57:31

Der Eintrag kommt ungefähr alle 2 - 3 Minuten.

Soll das so sein?

Zitat

Da evtl. Python für einige nicht in Frage kommt, habe ich die /psovrd2 Idee mal in einem Shelly Script umgesetzt. Läuft bei mir auf einem ShellyPlus1PM.

Ihr müsst net = und devices = auf eure Gegebenheiten anpassen.

Code

function timerCode() {
  i += 1;
  if (i === devices.length){i = 0};
  Shelly.call(
  "http.get",
  {url: net + devices[i] + "/psovrd2",timeout: 8},
  function(result, error_code, error_message) {
    if (error_code !== 0) {
      print("timeout " + net + devices[i]);
    } 
    else if (result.code === 200) {
      let obj = JSON.parse(result.body);
      print("success " + net + devices[i]);
    }
  })
}

//Anpassen (max. 15 TRV)
let net = "172.16.0.";
let devices = ["64", "67", "68", "69", "70", "71", "72", "73", "75", "76"];
//Anpassen Ende
let wait = 150000/(devices.length);
let i = -1;
Timer.set(wait,true,timerCode);

Alles anzeigen

Hi,

danke für's Script, würde es auf einem Pro1 laufen lassen aber ich stell mir dir Frage was mit Username und Passwort ist.

Wenn ich das richtig verstehe, dann funzt das nur wenn die TRVs ohne Username und Passwort sind, oder?

Zitat von ehtron

hi

meinte devel

dann habe ich keinerlei erklärung dafür.. macht er bei mir mit der v2.1.8 auf allen TRVs so.

gesetzte .5° wird nicht übernommen.. wie in meinem shot ja gut zu sehen ist.

Ist laut Support ein bekannter Bug und soll ausgebaut werden. Ich kann .5 Werte über die App oder Gui setzen aber wenn es das Profil tun soll dann wird abgerundet.

Hab den Fehler auch gemeldet und als Antwort bekommen, dass er bekannt ist und "bald" behoben wird. Keine Ahnung was "bald" heißt. Der Fehler ist jedenfalls ziemlich nervig. Im Wohnbereich hab ich im Profil einen .5 Wert stehen und jedes Mal wenn beispielsweise von Nachtabsenkung auf Tagbetrieb gewechselt wird, muss ich von Hand um ein halbes Grad hochstellen. Das gleiche gilt für den Profilwechsel wenn alle das Haus verlassen haben und der Erste wieder nach Hause kommt.

Hi,

ich vermute Du nutzt auch den Shelly Adapter im ioBroker. Dieser hatte einen Bug der das Verhalten verursacht hat.

In der aktuellen Version 6.4.0 tritt der Fehler nicht mehr auf.

Hast natürlich recht, danke!

Finde auch das der Hinweis in die Anleitung sollte.

Ja es ist eigentlich logisch das man Credentials auch übergeben muss wenn man den Zugriff einschränkt aber trotzdem denkt man vielleicht nicht daran.

Genau wie Devil schreibt, war nur schneller als ich.