Ach, auf deiner Sicherung liegt das Internet. Dann muss ich dich also anrufen, wenn es mal wieder ausfällt, damit du die Sicherung wieder rein drückst.
Genau so machen wir es.
Und wenn ich Glasfaser bekomme, lasse ich zusätzlich das Licht im Keller brennen, damit ich nicht im Darknet lande!
Ihr Erinnert mich daran, dass ich vor zwei Monaten folgendes festgestellt habe:
Nachdem das seit 15 Jahren so ist, werde ich das im Frühling korrigieren.
Das nächste Thema lautet dann: "Obwohl ich beide TRV zwangssynchronisiere, ist es in einer Raumhälfte immer wärmer".
Dem muss ich laut meinen Messungen widersprechen, denn genau das behebt das Script. 
Vor dem Script hatte ich eine gemessene Hysterese von 2-3 Kelvin, nun liegt diese bei 1 Kelvin. Damit deckt sie sich nun mit den Zimmern, in denen ich nur einen HK mit Blu TRV betreibe.
Des weiteren lässt die unausgeglichene Wärmekonvektion im Raum nach, welche sich trotz steigender Raumtemperatur wie ein unangenehmer kalter Luftzug anfühlt.
Eine sinnvolle Positionierung des Temperatursensors ist dennoch wichtig.
Dafür, dass die Heizkörper sinnvoll und gleichmäßig die Wärme an den Raum abgeben können sind zwei Kenngrößen wichtig. Die Dimensionierung der Heizkörper und der hydraulische Abgleich.
Und sollte dies tatsächlich ein Problem darstellen, weil o.g. Bedingungen ungünstig sind, so könnte man für den Slave noch ein Offset einführen.
Ich freue mich auf Feedback, da mich natürlich interessiert, wie sich das Script in unterschiedlichen Räumen verhält. 
Ich meinte einfach alles auf das du verzichten kannst, solltest du erstmal deaktivieren. So auch die aioshelly Integration.
Auf meinem besagtem Gateway läuft ein eigenes Script zur TRV Synchronisation. Und das Gateway läuft seit Tagen stabil.
Ich kann dir definitiv bestätigen, dass es ungeklärte und sporadische Neustarts gibt. Manchmal sogar, wenn du einfach nur zwei WebUIs gleichzeitig öffnest.
Ich werde bei Gelegenheit für dich Prüfen, ob das Verhalten seit der aktuellen Beta Firmware weg ist.
Hallo imautohutraeger,
meine BLU TRVs haben auch nach Tagen mehr gegeneinander als miteinander gearbeitet. Obwohl sie sich den Temperaturfühler teilten.
Aus diesem Grund habe ich mir ein Script geschrieben, um die BLU TRVs zu synchronisieren. Eines arbeitet dann als Master mit der Steuerung von Shelly - das andere als Slave mit identischer Ventilposition.
Siehe hier: RE: 2x Shelly BLU TRV mit BLU H&T als Sensor
Und hier: https://community.shelly.cloud/topic/8098-gro…/#comment-23543
Meine Gateways läuft stabil.
Allerdings konnte ich beobachten, dass es eines permanent neu startet, wenn mit VS Code und dem Shelly AddOn entwickeln möchte.
Ein ähnliches Verhalten konnte ich auch bei einem Shelly1 Mini feststellen.
Irgendwann habe ich alles was dem Gateway zu viel werden könnte deaktiviert (Diagnose, MQTT, passives BTHome von HA). Seitdem läuft er und ich habe noch keine weitere Zeit in die Fehlersuche investiert.
Wie perfomant läuft es denn mit gerade mal 1GB RAM?
Zumindest ist die GPU schneller getaktet als beim Vorgänger.
https://versus.com/en/mediatek-mt6580-vs-unisoc-sc7731e
So lange du bei der Original Firmware bleibst, werden die 4GB (statt bisher 8 GB) reichen.
Da ich es gerade als angenehme Herausforderung empfand, hab ich ein Beispiel Script geschrieben.
Der Anwendungsfall ist nicht so trivial umzusetzen, wie er auf den ersten Blick scheint.
Da ich ein Freund der Virtuellen Komponenten bin, habe ich mich direkt für diese entschieden. Diese müssen erst eingerichtet und Konfiguriert werden:
Zusätzlich habe ich noch eine Gruppe zur Ansicht auf dem Dashboard angelegt, so ist es möglich die Zeit für 'an' und 'aus' zu setzen.
Das Script unterstützt sowohl 'button' als auch 'switch', wichtig ist nur, dass du input und switch im 'detatched' Modus betreibst. Denn das übernimmt das Script für dich.
Als zusätzlichen Trigger habe ich einen virtuellen Button vorgesehen. Diesen kannst du bequem in der Oberfläche zum Testen verwenden, oder auch von extern aufrufen:
http://192.168.xxx.xxx/rpc/Button.Trigger?id=200&event="single_push"
Im Config Objekt müssen ggf. die IDs der Komponenten angepasst werden. Momentan unterstützt das Script Sekunden statt Millisekunden. Und es handelt sich immer um einen Mindestwert und niemals um einen exakten Zeitwert. Das kann die Shelly Firmware ohnehin nicht.
Für Interessierte:
Um nicht in Konflikt mit anderen Events zu geraten, habe ich mich für ein eigenes Event und einen Timer entschieden. Somit lässt sich das Script leicht auf verschiedene Trigger anpassen.
const CONFIG = {
switchId: 0,
inputComponent: 'input:0',
timerOnVHandle: Virtual.getHandle('number:200'),
timerOffVHandle: Virtual.getHandle('number:201'),
vButtonComponent: 'button:200', // optional
timerHandle: null
}
function resetLoop(config){
// break loop
Timer.clear(config.timerHandle);
config.timerHandle = null;
// set default: switch off
Shelly.call('Switch.Set', {id:config.switchId, on: false}, function(result, error_code, error_message, config){
if(error_code){
print(error_code, error_message);
}
}, config);
}
// callback for error handling only
function toggleSwitchCallback(result, error_code, error_message, config) {
if(error_code){
print(error_code, error_message);
resetLoop(config);
}
};
Shelly.addEventHandler(function(event_data, config){
if(event_data && event_data.info && event_data.component){
// Trigger for input type 'switch'
if(event_data.component === config.inputComponent && event_data.info.event === 'toggle') {
if(event_data.info.state === false){
// stop endless loop
resetLoop(config);
} else {
if(config.timerHandle === null){
// start endless loop
Shelly.emitEvent('SwitchToggleLoop', true);
}
}
}
// Trigger for input type 'button' with 'single_push' (or virtual component button)
if((event_data.component === config.inputComponent || event_data.component === config.vButtonComponent) && event_data.info.event === 'single_push') {
if(config.timerHandle){
// stop endless loop
resetLoop(config);
} else {
// start endless loop
Shelly.emitEvent('SwitchToggleLoop', true);
}
}
// Endless loop via own 'SwitchToggleLoop' event
if(event_data.info.event === 'SwitchToggleLoop'){
// toogle switch
Shelly.call('Switch.Set', {id:config.switchId, on: event_data.info.data}, toggleSwitchCallback, config);
var period = event_data.info.data ? config.timerOnVHandle.getValue() : config.timerOffVHandle.getValue();
//print('wait: ', period);
// keep endless timer loop running
// break: resetLoop(CONFIG);
config.timerHandle = Timer.set(period * 1000, false, function(setOn){
Shelly.emitEvent('SwitchToggleLoop', setOn);
}, !event_data.info.data)
}
}
}, CONFIG);Ich verwende die selbe Blueprint. Ich meine mich zu erinnern, dass du die letzte Action auch als Pflichtfeld definieren musst.
Hier meine Daten zum Abgleich:
Als YAML in der Blueprint-Konfiguration:
id: '12345678xxx'
alias: Wäschetrockner fertig
description: ''
use_blueprint:
path: >-
sbyx/notify-or-do-something-when-an-appliance-like-a-dishwasher-or-washing-machine-finishes.yaml
input:
power_sensor: sensor.waschetrockner_power
starting_threshold: 10
finishing_hysteresis: 5
actions:
- action: notify.alexa_media
data:
message: >-
<amazon:emotion name='excited' intensity='medium'>Ob es geklappt hat
oder nicht, erfährst du Keller!</amazon:emotion>
target: media_player.uberall
data:
type: announce
method: all
pre_actions:
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 1Ich habe bei der pre_action einen delay von 1 Millisekunde definiert.
ich habe gerade meine beiden neuen Shelly Blu TRV mit dem Gateway gekoppelt.
Anschließend kam der Hinweis, ein Firmwareupdate durchzuführen.
D.h. du hast das BLU TRV Update über das Gateway angestoßen?
Dann solltest du die Shelly Debug App installieren und dieser das Update nochmal probieren.
Gibt es eine Erklärung dafür?
Wenn du die Status Meldungen und Events analysierst, wirst du feststellen, dass eine Änderung der Zieltemperatur nur über die Statusmeldung möglich ist.
Ich habe den Zeitwert nie gemessen. 0 bis 30 Sekunden Zeitverzögerung kommt schon hin.
Wenn man der Anleitung folgt und alle alten Entitäten (z.B. durch MQTT Einbindung) löscht, sollte es keine Probleme mit der Integration geben.
Diese gibt es in der internen Shelly Integration nicht, das ist momentan kein Steuerelement sondern nur eine Anzeige der Ventilposition (Daher auch im Bereich Diagnose) und kann nicht gesetzt werden
Korrekt. Das ganze lässt sich nur per RPC Call Umstellen.
TRV Modus deaktivieren:
http://192.168.xxx.xxx/rpc/BluTrv.Call?id=200&method=TRV.SetConfig¶ms={id:0,config:{enable:false}}
--> Danach kann die Valve Position in HA geändert werden - dafür ist kein Thermostat mehr möglich.
--> In der WebUI und Shelly App ändert sich dadurch nichts. Das TRV verharrt einfach ohne Regelung.
Im Script kann man dann die Position setzen:
Shelly.call('BluTrv.Call', {id:targetTrv.trvId, method: 'TRV.SetPosition', params:{id:0, pos: newValvePosition}}, callback);
Oder eben über:
http://192.168.xxx.xxx/rpc/BluTrv.Call?id=202&method=TRV.SetPosition¶ms={id:0,pos:100}
Ich hab nochmal aufgeräumt und verwaiste Entitäten gelöscht. Nun wird auch in HA aktualisiert. Zwar nicht unbedingt sofort, aber mit akzeptabler Verzögerung.
Danke für deine Hilfe.
Mein erster Eindruck:
Letzteres wundert mich nicht, da dies über MQTT auch schon hakelig war. Hintergrund ist, dass im Gateway leider kein direktes Event zur Temperaturänderung ausgelöst wird. Man kann hier nur auf den Intervallmäßigen Status Handler zurückgreifen.
Es wäre zu wünschen, Shelly würde hier mit der nächsten FIrmware noch ein Event einführen.
Vielen Dank apreick für die ausführliche Anleitung.
Da ich einen TRV manuelle steuere (er ist per Script als 'slave' an einen 'master' gebunden), kann ich noch etwas Ergänzen:
Die Valve position wandert bei dieser Konfiguration hin zu den Steuerelemente, was soweit auch korrekt implementiert wurde.
(Nicht erschrecken, die Temperatur stimmt hier nicht, diese liegt im Raum bei 21°C)
Die Kachel für die climate Entität ist dementsprechend unbrauchbar und sollte in HA ausgeblendet werden.
Auch das ist soweit gut gelöst, denn das Setzen der Zieltemperatur am TRV ist zwar technisch möglich, allerdings aus Sicht von HA irreführend.
Tippe mal das HA 2025/2 heute ausgerollt wird 🧐
Mit einer Beta HA spiele ich nicht 🤨
Wie ich es vermutete, die Integration benötigt die neuere Firmware von Shelly:
Und das spielt ja bei dir eh keine Rolle 🤔er kann in HA mit der Integration jetzt nicht genutzt werden, und wenn das bei einem Update von HA nicht funktioniert => dann hast du das gleiche
Seitdem ich von Zigbee Thermostaten mit zigbee2mqtt, generic thermostat und Shelly Pro4 auf eine reine Shelly Lösung ohne Cloud umgestiegen bin, bin ich nicht mehr von HA Abhängig. Da hast du Recht.
Wäre ich geduldiger, würde ich Updates nur außerhalb der Heizperiode machen 
.
In der HA Version 2025/2 ist der BLU TRV kompatibel 😎
Hat das schon jemand ausprobiert?
Ich kann keine neuen Funktionen finden. Verwende aktuelle die Firmware 1.4.99
Das Problem ist bekannt und die Lösung ist ein Shelly Blu H&T. Dieser kann direkt als alternativer Sensor im Wall Display verbunden werden.
Wenn du Glück hast wird dir in der Shelly App noch ein Promocode angezeigt. Mit diesem kannst du dir einen Sensor im offiziellen Shelly Shop bestellen.
