Beiträge von JSE222

Zitat von MIHO

Über die Stable ist es sehr wohl noch möglich.

Und so wie ich Bullgarien verstanden habe, wird es auch zukünftig gehn, nur wird es halt anders aktiviert bei Bedarf. Also abwarten.

Mit 1.4.4 habe ich keine Möglichkeit direkt einen BT-Sensor zu koppeln, das Webinterface bietet das schlicht nicht.
Möglich das es über die App geht, muss dann jeder selber wissen ob er Daten seiner Firma über eine App via Cloud durchs Netz schickt.
Ich habe Bulgarien da anders verstanden, denn ein Observer mag zwingender Teil eines Gateways sein, allein ist er aber keins. Und wie soll eine direkte lokale Kopplung "anders aktiviert" werden als übers Web-IF? Es ergibt einfach keinen Sinn das anders zu machen.

Beim Lautsprecher wird es natürlich schwierig mit Reedkontakt.
Aber bei den alten e-mech. Klingeln nach Wagnerschem Hämmerchen könnte es gehen.

horkatz : Nein, geht nicht, keine Kopplung von Blutoothgeräten möglich, auch keine Gatewayfunktion. Vielleicht über die App, oder sicher über ein System wie HA, aber nicht über die Geräte direkt.

Thema

Bluetooth Observer indirekte Änderung in FW Beta 1.5.0 Beta1/2 (Observer Funktion bleibt trodem erhalten)

(Zitat)


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…

JSE222

10. Februar 2025 um 08:31

Natürlich besteht an der Stelle keine echte Notwendigkeit für Energyharvesting. Es wird ein Testcase für verschiedene Möglichkeiten, ist ja leicht zugänglich.
Aber zunächst gehts mal darum ob ein DW als Sensor überhaupt geht, wäre ja für den TE vielleicht eine Möglichkeit. Ich werde berichten.

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: Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

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.