Beiträge von schwarzbold

Zitat von Norwegen60

• Dann habe ich die IP auf x.x.x.255 geändert.

Bevor du weiter an deinem Netzwerk rumfummelst und irgendwelche Adressen vergibst: Mach dich über die Grundlagen eines IPv4-Netzwerkes schlau. Wenn du da was richtig versemmelst, stehst du ggf. im (netz-)finstern. Solange lässt du die shellys bitte im DHCP

Desweiteren könnte man in Sofia mal fragen, warum die 255 überhaupt eintragbar ist ... aber gut. der Netzwerkstack musste sparsam in der Größe gestaltet werden und man ging davon aus, dass die Zahl der Unwissenden nicht zu groß sein wird.

Hier ist die Bestätigung: Pixel 6a mit A14 und CAT-S61 mit A9 und Samsung Tablet 2016 mit A-irgendwas als auch Iphone 12mini mit IOS 18.1.1: alle 4 gehen seit letzthin nicht mehr aus, wenn die Shelly-App im Vordergrund ist. Für das Tablet ganz nett (hängt an der Wand nur um Shellys zu steuern), für die Handys Grütze. Lässt sich nicht einstellen.

Und schaltet dann bei steigender Spannung nicht zu .. hab ich mir fast gedacht ... dann muss ich wohl in den sauren Apfel beissen und noch ein Netzteil dazu bauen. Oder eine Z-Diode ausprobieren, die bei 10V auf Durchzug schaltet ... ich werde sehen und berichten.

Ich habe einen Uni-Plus an einem Akku eines Balkonkraftwerkes. Es misst die Spannung und regelt den WR entsprechend ein bis hin zum Abschalten des Wechselrichters. So weit so gut. Die letzten Tage aufgrund des Mistwetters ist trotzdem die Batterie in den OFF-Modus durch Eingriff des BMS gegangen. Auch soweit so gut. ABER der UNI startet nicht wieder, wenn das BMS die Batterie nach Spannungszufuhr durch die PV-Panele wieder freischaltet. Übersehe ich etwas oder muss ich den UNI jedesmal händisch trenn und wieder verbinden? Dann startet er nämlich wieder.

Zitat

.. und downgraden geht bei den BLU Geräten meines Wissens nicht.

Aber falls jemand Lust auf Abenteuer hat, nur zu... 😜

Sollte es nicht mit der DEBUG BLE gehen?

Auf den Schildchen steht was von 150W ... da würde ich geschmeidig auf das Zusatzschütz verzichten. Die Pumpen laufen zwar mit einem erheblichen Strom an, dürften aber den Shelly nicht in Bedrängnis bringen. Die Schaltzyklen sind dann auch nicht so, dass der Abrissfunke im Relais frühzeitig schaden anrichten würde. Trotzdem ist hinsichtlich der sicher verbauten WMZ noch zu prüfen, ob diese über diesen Stromkreis mit Strom verbunden sind und was die (bzw. deren Batterie) dazu sagen, wenn die getrennt werden. Das wäre also insgesamt mit dem Wärmenetzbetreiber abzuklären. Ebenso ist bei einem solchen hart vom Netz trennen zu klären, was die Stellelemente in der FW-Station dazu sagen. Gehen die in einen definierten Zustand oder bleiben die, wo sie sind?

Die elektrische Seite ist damit relativ einfach geklärt. Ob es die FW-Station mitmacht und ob die dadurch enstehenden Zustände gut sind, ist mit dem Netzbetreiber zu klären.

funkenwerner: da gebe ich dir recht. Wenns ein Ölradiator ist, ist es dem wurscht. Wenns eine Heizung mit Steuerung ist, eben meist nicht. Ich wollte nur mal grundsätzlich ausholen, bevor ich kurz und knapp auf die eigentlich rein elektrische Frage eingehe.

Heizungsanlagen sollten NIE per externem NETZ-AUS geschaltet werden. Ab und an mögen die das nicht. Es erschließt sich mir nicht die Notwendigkeit eine Hitzung mittels Netz-Aus zu steuern. Das geht anders besser. Aber seis drum. Zur Frage:

Wo der Shelly sitzt ist egal, solange der den Außenleiter trennt.

Kleine Ergänzung:

Ich habe jetzt auf ALLE BLE-Beobachter, auch die shelly-Plugs, das Script zur Meldung an IOBroker (https://github.com/iobroker-commu…/ble-devices.md) installiert. Seitdem scheint auch Ruhe zu sein. Dieses scheint ebenfalls dafür zu sorgen, dass nicht mehr so viel überhört wird. Dabei habe ich den Schalter für die Gateway-Funktion angelassen!

Ok ... dann müssen die FW ja nur angepasst werden. Der Strommehrverbrauch dürfte sich ja bei Netzgekoppelten Geräten im Rahmen halten.

Die WD scheinen für die Tickets ja kein Problem zu sein. Wenn ich alle Meine BLE-HT nur über die WD abhören lasse, sind mir nämlich noch keine Aussetzer aufgefallen. Allerdings kann man die WD aber nicht nutzen um die Meldungen auf IOBroker umzuleiten ... und man hat natürlich auch nicht überalle ein WD in der Nähe, wo man die BLE-HT einsetzen möchte.

Kurzanalyse meinerseits: es liegt am Plug-Plus. Ich habe einen BLU-HT, der nicht senden wollte. Habe diesen an einen anderen Standort verbracht. Dort hat er ebenfalls Verbindung mit einem Plug Plus. Dort geht er. Der BLU-HT, den ich dann von dort geholt habe, hat am alten Standort ebenfalls Aussetzer. Mit einem Plus1 an der Seite sind die Aussetzer per Meldung über den Plus1 weg. Also sind manche Plug Plus die Tatverdächtigen.

Der kleine Unterschied ist halt, dass man mit dem HT-GEN1 durch das WLAN weiterkommt als mit dem HT-BLU, der zusätzlich noch einen Shelly mit BT nebenan braucht ... aber ansonsten zeigt meine Testreihe ein ähnliches Ergebnis (der GEN1 läuft inkl. Korrektur der RF parallel zum BLU)

Nochmal: wenn die Spannung im Nachkommabereich abweicht, ist das wurscht ... es war nur erwähneswert ...

Viel interessanter ist, dass einer meiner 1PM+ 225 Volt meldet und stattdessen aber 236V anliegen ....

Zitat von thgoebel

Das ist die selbe Spannung, aber ein Rundungseffekt der App macht scheinbar zwei daraus. Du misst selten mit digitalen Meßgeräten, oder? Die kleinste angezeigte Stelle darf man getrost vergessen…

Mich wundert eher, dass die Cloud zwei draus macht. Es kommt vom 2PM+ ja nur eine und die wird in der Cloud verschieden zerlegt .... ist aber auch wurscht ... ist ja nur ne Randerscheinung ... Und ich messe oft genug mit digitalen Messgeräten um den Effekt zu kennen ... allerdings, dass EINE Datenbank dann zwei Werte draus macht, ist mir neu ...

Ich habe mal probiert den AM2302 direkt auf das Addon+ zu setzen. Die Reihenfolge der Anschlüsse schreien ja förmlich danach.

Eine weniger Gute Idee. Abweichungen von etlichen Kelvin, je nach Shelly. Und dabei liegen die offen auf dem Schreibtisch. Es muss also zwingend eine größere räumliche Trennung zwischen Shelly und DHTXX geben, da hier die Abstrahlungswärme des Shellys die Werte versaut.

Shelly1: 6 Kelvin

Shelly 1PM 9 Kelvin

Shelly 2PM: 10 Kelvin

Raumtemperatur 18,5°C (nach WD und externem kalibrierten Messgerät - die beiden habe ich zumindest Syncron und jedesmal bei einem Softwareupdate Angst, dass mir das wieder um die Ohren fliegt)

Was noch verwundert: der 2PM wird ja in 2 Geräte aufgegliedert. Diese zeigen ohne eine Last an den Ausgängen (nix dran) zwei unterschiedliche Spannungen an. Spannend.

Wenn ich doof fragen darf: wo befinden sich die Klimadaten, wenn das Ding im Sleep-Modus ist? Und wie frage ich die per Skript ab? Da bin ich grade ein wenig Vorstellungsfrei.

Zitat von ostfriese

Falsch, kann man prima machen. Sowohl für alle Shelly BLE, als auch für Ruuvi.

Ruuvi bietet dabei mehr Messwerte.

Und Teilweise hast du Recht, was das Abfragen anbelangt. Abfragen muss man die nicht, die senden ihre Daten autonom über BT.

Verarbeiten per Skript geht aber wunderbar.

Ähm ... wenn ich die Klimadaten benutzen möchte um eine im Haus befindliche Aktion auszulösen, dann muss ich die Daten beim BLU abgreifen, was nur geht, wenn der auch antwortet. Das tut er nicht. Er sendet maximal ... umgekehrt wäre eine Abarbeitung des Skriptes auf dem BLU denkbar, was aber konkurriert mit langer Akkulaufzeit ...

Wäre (k)eine Möglichkeit. Du kannst dann allerdings die Daten nicht per Script abfragen und verarbeiten. Du musst die ganze Sache dann über ein übergeordnetes System laufen lassen um bspw. eine Lüftersteuerung. Also wiedermal nur halbgut. Wir werden noch eine Weile mit den DHTXX leben müssen.

Alles klar ... ich dachte nur, dss hier shonmal was aufgetaucht ist und es schon eine Lösung gibt.

Ich nehme nicht 11 TRV aus der Cloud und binde die wieder ein - LEbenszeitvergeudung. Das sollte seitens der Cloud gelöst werden und nicht seitens des Nutzers. Die Dinger tun ja, was sie sollen .... nur eben dieser Fehler. Ich habe in einem anderen Netz auch noch 4 Stück, deren Ereignisprotokoll ist auch leer. Allerdings ohne Fehler.