Beiträge von JSE222

Werde demnächst mal ausprobieren ob ein Blu DW meine Klingel berührungs- und elektrisch eingriffslos detektieren kann.
Ist so ein Gong, gut möglich das der Reedkontakt schon auf den E-Magnet reagiert, falls nicht, kommt halt ein Magnet auf den Klöppel.
Nächste Stufe wäre dann Energy-Harvesting: Mal testen ob ich den Blu DW irgendwie, allein aus dem Gong, versorgen kann.
Rückgewinnung von Klöppelenergie wollte ich immer schon mal in Angriff nehmen

BLE Debug App laut Playstore am 11.2.25 aktualisiert. Also vielleicht schon früher unbemerkt updated, wie hier.

Ich hab v. 1.8.1, laut Playstore soll das die aktuelle sein.

Ja, hatte ich gelesen und mich darauf bezogen, allerdings ohne das durch Zitat kenntlich zu machen, sorry.

Ein weiterer möglicher Zweck des Heizwiderstandes:
Die Seqenz zum Reset, im Besonderen die mindestens nötige Zeit für Aus soll möglichst unabhängig von der Konfiguration der LEDs niedrig gehalten werden.
Hypothese: Wenn die LEDs beim Einschalten mit angehen, besonders auf max. Leuchtstärke, sinkt beim Abschalten die interne Versorgung wahrscheinlich schnell genug ab. Sind aber die LEDs beim Ausschalten aus, hängt die Zeit bis zum tatsächlichen Powerdown des Controllers von seiner AKtivität zu dem Zeitpunkt ab, besonders wohl ob er gerade WiFI sendet oder nicht.
Falls nicht, besonders in irgendeinem Stromsparmodus, kann es dann schon sehr lange dauern bis der Controller "weg" ist und beim Wiedereinschalten auch wirklich ein PowerOnReset erzeugt wird. Irgendwie muss er ja die Sequenz erkennen und das wird er sicher durch Auswertung der Resetquelle in einem Register machen. Kein POR -> kein Weiterzählen des NV-Registers für den Werksreset.
Der R sorgt einfach dafür, das nach Ausschalten die interne Versorgung nach kurzer, definierter, max-Zeit auf 0V ist.

Hab etwas Ähnliches gerade durch, mit einem alten Lightify-RGBW-Streifen den ich via Zigbee in HA einbinden wollte. Die Einhaltung der Sequenz hab ich rein mittels Zählen einfach nicht hinbekommen, offenbar gab es enge Anforderungen an das Timing. Geholfen hat ein Youtube-"Video" welches nichts anderes macht als das nötige Timing zu piepsen, wonach man den Schalter betätigte und prompt das Ding ins Pairing ging.

Noch ein möglicher Grund und ein bischen Background:
Viele komplexere Digitalschaltungen, besonders Controller, haben min.-max. Fenster für Anstiegs- und Abfallgeschwindigkeit der Versorgungsspannung. Mit einem externem Resetgenerator muss das nicht immer eingehalten werden, aber viele minimalistische Schaltungen verlassen sich auf die internen PORs. Da gibts Solche und Solche. Wenn man sich drauf verlässt, ist man gut beraten die genannten Fenster auch einzuhalten. Das ist in gewisser Weise unabhängig von der Reset-An/Aus-Seqenz zu sehen, ein weiterer möglicher Grund für den Widerstand wäre dann eher so in Richtung nachträglicher Notnagel. Denn einen externen Resetgenerator reinzudesignen wäre günstiger gekommen als einen R händisch einzulöten und mit Schrumpfschlauch zu überziehen. Von den Kosten für Support, Reklamationen und Rückläufern mal ganz zu schweigen.

Ahh, so läuft das!
Frühwarmduscher aufgepasst, immer schön ganz nach unten scrollen!
Super, danke!

Ich würde gerne für den nächsten Tag eine einmalgie, für 2h andauernde Solltemperaturerhöhung programmieren.
Entweder direkt im Webinterface des Blu GW oder in HA, egal, was halt einfacher wäre.
Im Webinterface gibts Aktionen, aber alles irgendwie mit Bedingungen. Ich will als Auslöser aber einfach nur die Uhrzeit, ab der die Solltemperatur (ohne jegliche sonstige Bedingungen!) erhöht werden soll, und nach 2h wieder abgesenkt werden soll. Und "Schedules" kann man erst einrichten wenn man Aktionen eingerichtet hat.
Meinetwegen auch als Schedule für jeden Tag, dann muss ich es halt händisch wieder rausnehmen.
Ich würde das ja selbst rausfinden und ausprobieren, ist aber wirklich für morgen sehr früh warm duschen

Probier doch noch mal das Script, vielleicht muss nur eine kleine Sache angepasst werden. Mir wäre z.B. nicht klar wie der Tempsensor eingebunden wird: Per Kopplung ans GW oder direkt mit dem Master-TRV. Leider kann ich aktuell dabei wenig helfen, kann selbst noch kein Scripting und habe auch keinen Raum mit 2 HK wo ich das mal ausprobieren könnte. HT hab ich auch nicht.
Aber ich könnte ja mal Bad und Wohnzimmer koppeln. Dabei kann eigentlich nur Mist rauskommen, der Raum mit gesteuertem TRV wird nach einiger Zeit entweder Sauna oder Kühlschrank sein. Aber immerhin könnte man sehen ob priniziell die Steuerung läuft.

Ist dem so? Ich hatte ja verlinkt was die Gen 2 laut Shelly können sollen:

Aus anderem Thread auf Moderatorwunsch händisch hierher kopiert:

Hm, die interessante Stelle als Zitat im Zitat erscheint nicht, ich zitiere mal händisch:

"Die Änderung betrifft nur die öffentliche API, die Beobachterfunktionalität selbst bleibt natürlich bestehen. Der Observer wird automatisch gestartet, wenn dies erforderlich ist (z. B. wenn der Benutzer BLU-Geräte zum Shelly-Gerät hinzufügt, um einen Proxy für die Cloud zu erstellen; oder Skripte ausführt, die ble verwenden, usw.); und wird automatisch gestoppt, wenn es nicht mehr verwendet wird."

Was ein "Observer" genau macht, da muss ich mich erst schlau machen.
Nun kann man aber gerade bei den Plus Plug S keine BLU-Geräte via Web-IF hinzufügen, klingt für mich erst mal nach Gatewayfunktion nur via Script oder Cloud?

Sorry für 1/2 OT in diesem Thread, ich hab halt interessehalber und für den TE ausprobiert ob ich meine Blu DW und Motion vielleicht doch mit den "Shelly ^Plus Plug S (White) v2" und "Type F" (Verpackungsaufschriften) koppeln kann. Alle relevanten Einstellungen durchgegangen, nix gefunden, dachte das vielleicht die neue Beta was ändert. Zwar nicht daran, dafür an was Anderem.
Gezielt ausprobiert hatte ich die Gatewayfunktion bei den Plugs bisher nicht, dafür hab ich genug fest Installierte, permanent versogte Shellys. Aber es wäre schon gut wenn die Funktion erhalten bliebe, weil man die Dinger mal eben zum Testen schön frei bewegen kann um Funklöcher zu überbrücken. Bestens geeignet für ewige Provisorien

Zitat von MIHO

Der Shelly Plus Plug S kann Bluetooth, und kann als Bluetooth Gateway genutzt werden. Über dieses Gateway kannst du den Shelly BLU Motion z.B über die Cloud bedienen.

Nein, BT-Gateway kann er jetzt nicht mehr (Plus Plug-S Type F).
Die Gatewayfunktion ist mit dem FW-Update auf 1.5.0.Beta2 (vielleicht auch schon ab Beta-1) verschwunden. In der 1.4.4. (auf die man über das Web-IF zumindest im Moment noch zurück kann) konnte man das noch aktivieren.
Ich finde es bedenklich, wenn dem Kunden nach dem Kauf Features per Firmwareupdate weggenommen werden.
Hier ist es noch als Produktmerkmal erwähnt:
https://support.shelly.cloud/de/support/sol…-3-ger%C3%A4ten

Ein direktes Koppeln von BT-Sensoren ging aber auch mit 1.4.4 nicht und damit auch keine direkte Auswertung, jedenfalls habe ich die sonst üblichen Menüpunkte nicht gesehen.

Zitat von Schubbie

[...]

Das Leben ist zu kurz, um sich um solche kosmetischen Dinge den Kopf zu zerbrechen wird es irgendwo kalt, dann ist es natürlich was anderes.

Braucht einen nicht zu kümmern, solange keine grösseren Temperaturschwankungen auftreten. Man sollte aber die mögliche Instabilität (auch schon durch nebenher Regelung einer Heizung) als eine mögliche Ursache dafür im Hinterkopf haben.
Aber als jemand der seine gebastelten Lösungen gerne überprüft, würde ich auch folgende Dinge beobachten, auch weil übermässiger Verschleiss ja teuer werden kann (und TRVs die im Schlafzimmer das alte Rein/Raus-Spiel abziehen, können durchaus auch stören):
-Springt mit TRVs die Heizung öfter an als ohne,
-fährt sie andere Vorlauftemperaturen
-fahren 2 "teilautonome" TRVs öfters hin und her als z.B. einer als Master

Schon wenn man irgendwas über die Heizung legt, verändert man die Regelstrecke. Der Heizkörper kann nicht mehr so viel Wärmemenge abgeben. Auch die Konvektion ändert sich, das kann durchaus in die andere Richtung gehen: Der Sensor bekommt plötzlich mehr oder schneller die warme Luft.
Solche Sachen, wie auch Sonneneinstrahlung oder offene Tür, sind aber unabhängige Störgrössen, genau der Kram mit dem ein Regler klarkommen sollte, wofür Regler eingesetzt werden. Eine (Selbst-?) Optimierung für den ungestörten Fall macht vielleicht bei Öfen in einer Produktionsanlage Sinn, wo sich nicht zig Parameter ändern. In Wohnräumen gibt es dafür wohl zu viele Unbekannte.
(ich warte auf die ersten Thermostate die "mit KI-Rgelung" beworben werden

Ein weiterer Aspekt:
Jede Heizung hat ja schon eine mehr oder weniger komplexe Regelung für Brennerstart, Vorlauftemp. und Pumpenleistung, die zusammen mit nur einem geregelten TRV schon 2 vernetzte Regelkreise darstellt. Bei mir habe ich daher geplant die Heizung komplett zu steuern: Nur wenn mindestens ein TRV-Ventil offen ist, wird gepumpt und geheizt, sonst nicht. Falls das nicht funktionieren sollte, übernimmt eine übergeordnete Regelung auch die Steuerung der Ventile, möglichst überlappend reihum.

Die TRVs haben doch unbekannte Regelalgorithmen, es könnte z.B. ein selbstanpassender PID sein, die absoluten Ventilpositionen werden mit sicherheit irgendwie gelernt ("Kalibrierung") und irgendwelche Zeiten spielen vermutlich auch eine Rolle, die selbst Quarzgenau irgendwann auseinanderlaufen, vom sehr wahrscheinlich unterschiedlichen Startzeitpunkt beider TRVs mal ganz zu schweigen.
Dann hat man 2 unabhängige Regelkreise mit gemeinsamer Sollwertvorgabe und Istwertmessung, aber die Regelstrecke, d.h. der Einfluss der jeweiligen Ventilposition und sonstigen Beeinflussung (HK-Oberfläche, Abstand, Konvektionsverhältnisse) des Sensors wird mit Sicherheit unterschiedlich sein. Die Regeltätigkeit des einen ist Störgrösse für den jeweils anderen.
Bei derartig halbvernetzten Regelkreisen kann doch nur Scheisse, im Sinne von "die Regeln nicht synchron", bei rauskommen.
Man sollte sich auch nicht wundern wenn sich sowas aufschaukelt, womöglich mit Perioden im Tagesbereich.
Daher ist marco.grs Ansatz der Richtige, jedenfalls für diese Situation die einfachste Lösung.

Hängt an einer Fritz 7530, bisher alles noch ohne Repeater.

marco.gr:
Meinst du generell Scripte die auf dem BGW laufen, oder speziell bei irgendeiner Kopplung mit der IDE. Letzteres verwende ich nicht, aber HA scheint ein Script zu installieren, "aioshelly_ble_integration", das wird offenbar auch von HA aus gestartet. Die MQTT integration braucht(e ?) zumindest für discovery auch eins.
Werde mal versuchen das zu unterbinden, brauche dann aber irgendwas als "Rebootindikator".

Hier das gleiche Problem, egal welche Firmware. Habe auch mal alle sonstigen Blu-Devices (DW & Motion) auf andere Shellys als Gateways verteilt, da es ja (zumindest für die Anzahl TRVs) eine Begrenzung gibt, was auf Resourcenprobleme hindeuten könnte. Auch verschiedene Spannungsquellen durchprobiert. Hier ist das BGW einfach instabil, mal resettet es wenn ich die Solltemperatur an einem TRV verstelle, mal einfach so zwischendurch. Manchmal kommt es aus dem Reset gar nicht raus, rote LED bleibt dauerhaft an. Immerhin läuft es manchmal einen halben Tag durch...
Habe das Teil jetzt an einem Plug S, damit ich es ferngesteuert richtig neustarten kann.

Es gibt auch noch eine weitere Resetmöglichkeit, Taster gedrückt halten beim Einsetzen der Batterien, dann los lassen.
Finde gerade nicht die Seite, war aber was "offizielles". Keine Ahnung ob da was anderes als beim Factory-Reset passiert, aber soweit ich mich erinnere war dann in der Debug-App ein Bootloader mit alternativer BT-ID zu sehen.

Safari kann kein WebSerial, wenn du das meinst (von hinten durch die Brust ins Auge flashen), hab ich gestern ergoogelt, keine eigene Erfahrung.
Am besten zieht er mit nem Macbook kurz zum Homeserver, wird am einfachsten sein. Weil das Verbinden eines Flashers (muss übrigens 3.3V können, darf kein 5V-Only Typ sein) kann tricky sein und man will am ESP evtl. Reset drücken, LEDs gucken.

Einer VM kann man diverse USB-Sachen druchreichen, ein bestimmtes Device, ganzen Port. Soll bei manchen Timing-kritischen Sachen schon mal Probleme machen, ESP-flashen halte ich aber für eher Problemlos.

Ich bin Heimautomationsanfänger (wenn man mal von frühen Sachen mit mechanisch "programmierbaren" Zeitschaltuhren absieht).
Ich bin mir aber ziemlich sicher das ich keine "Szenen" will und auch keine vercloudete App. Solange ich zwei gesunde Hände hab, kommt mir sowas nicht ins Haus
Ich kann auch nicht verstehen wie man Scripte so ablehnen kann1!!11!

Ja, würde als Erklärung reichen, da braucht man die ganzen möglichen Akkueffekte gar nicht.
Ganz schnelle Messung, weil ich so ein Teil mit angeschlossenem Steckernetzteil und RGB-Streifen gerade hier liegen habe:
Im abgeschalteten Zustand, hirngemittelt so ca. 12- 14mA. Mein Fluke 771 schwankt aber zwischen 9 und 18mA, entweder stört das Steckerschaltnetzteil oder im RGBW2 zieht was zyklisch Strom. Also unter Vorbehalt weniger als die 0,5W. Bei denen mit 240V-Kondensatornetzteil, hab ich auch meist 1/2W gemessen, aber bei einem 12V-Teil fraglich, schon allein weil beim Design mit gängigen Standardkomponenten da eigentlich fast von selbst viel weniger bei rauskommen müsste.

@Roooobert, erzähl doch mal etwas mehr