Beiträge von Bekka420

bei mir fiel eine schaltung in den nicht existenten zeitraum zw 2:00 und 3:00 uhr nachts, doof gelaufen, aber verschmerzbar

allerdings habe ich einen 1pm mini der via sonnenauf- und untergang einen kleinen wechselrichter schaltet - der blieb heute unbemerkt aus.
ebenso das script auf einem pm mini gen3 welches sich zu sonnenaufgang starten soll wurde nicht gestartet.

die systemzeit ist korrekt, zeit wird vom lokalen ntp (pihole) gezogen und das passiert für gewöhnlich einige male pro tag.
hab den wechselrichter jetzt manuell eingeschaltet und mal abwarten ob er dann ausschaltet 🙏

müssen die schedules neu angelegt werden oder reicht ein reboot ? (frage bereits beantwortet, log bestätigte es)

alle sonstigen fixen schedules arbeiten wie sie sollen

DIYROLLY

hast du daran eigentlich weitergebastelt `?

mit unterstützung von thgoebels schaltplan kann man die pfade von den inputs recht einfach auf dem pcb lokalisieren.
hab den pullup R entfernt und den pulldown R gg 470k getauscht, um mit der geringen signalspannung eines bodenfeuchtesensors (0-1,5v real nutzbarer bereich, 3v max wenn trocken wie die wüste) etwas bessere auflösung zu bekommen.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

das kalibrieren über die webgui ist nervig und erfolgt am einfachsten über einen rpc , beispiel:

/rpc/Input.SetConfig?id=0&config={%22type%22:%22analog%22,%22range_map%22:[80,100],%22range_map_values%22:[0,100]}


ausgabe im webinterface sieht dann so aus:

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

problem leider wie gehabt, analogwerte vom input werden nicht in die cloud übergeben und damit auch nicht in die smart control app.
workaround:
ein script auf dem rgbw pm pusht änderungen auf einen Gen3 shelly direkt in eine virtual component (number zb). so bekommt mans doch in die cloud und kann infolgedessen auch loggen und sonstige spielereien damit machen

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

ich weiß das thema ist alt, aber ich habs beim suchen nach rgbw analoginput via goggle gefunden und das tun vllt auch andere
ahso und zu guter letzt - gpios kann man leicht frittieren, also obacht

nein, sie liegen nur auf einem gemeinsamen GND. eine der beiden psus versorgt den shelly + einen led streifen, psu 2 versorgt exklusiv den zweiten led streifen
man erkennts nicht so gut weil alles schwarz gezeichnet ist.


den rgbw dazu auf light mode einstellen um kanäle getrennt regeln zu können

edit bild in farbe - und bunt xD

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

schaltnetzteile parallel schalten ist nicht unbedingt die beste idee, lastverteilung oft schlecht.

du kannst allerdings beide netzteile an einem rgbw pm verwenden ohne sie parallel zu schalten

einer meiner rgbw pm wird bspw mit 24vdc versorgt, die lastkreise selbst laufen aber auf einer anderen psu mit 12v.
(in meinem fall stimmt die berechnete leistung nicht, aber da hängen lüfter dran und es ist an der stelle nicht wichtig)
solange die netzteile auf einem gemeinsamen gnd liegen kann man das schon machen.

edit falsches bild,

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

moin

bin dabei mit scripten und tagesenergiezählern zu spielen. dabei fiel mir eben auf, dass entgegen dem knowledge base artikel, kein light.resetcounters implementiert zu sein scheint.

https://shelly-api-docs.shelly.cloud/gen2/Component…htresetcounters

der call lieferte mir eine 404,

{"code":404,"message":"No handler for Light.ResetCounters"}

listmethods ergab , dass es den endpoint (oder ähnlich klingende) garnicht gibt.

getestet mit Dimmer 0/1-10V PM Gen3 & Plus RGBW PM

hat shelly das vergessen ? andere dimmer modelle mit energiemessung hab ich leider nicht zum testen

Lg

kleines update:

der plus uni ließ sich weder mit einem besseren sensorkabel noch zusätzlichem 47uF C ordentlich zum funktionieren bewegen (mehr gibt die bastelkiste grad nicht her, paar sachen hab ich aber bestellt).
es gibt zwar keine doppelten messwerte mehr in der cloud, dafür war das log zeitweise voll mit:

shelly_dht22.cpp:81 Error in DHT sensor reading!

es ist nicht unwahrscheinlich, dass diese fehler schon länger da waren.
sie traten heute morgen aus mir unbekannten gründen gehäuft auf, sodass in der cloud eine lücke zu erkennen war und ich daraufhin genauer hinsah.

mir fiel irgendwann auf, dass der eco mode aktiviert war. da die dimmer keinen mehr haben dachte ich da garnicht mehr dran.
ausgeschaltet - seitdem sind mir keine solchen fehler mehr aufgefallen, hab das log extra im auge behalten.

----------------------

bei den 0-10v dimmern ist nach kreuztausch zweier am2301 der fehler nicht mitgewandert.
der vermeintlich defekte sensor läuft einwandfrei, umgekehrt wirft der gute sensor am anderen dimmer jetzt fehler.
hab nen verdacht, das ganze ist aber noch nicht aussagekräftig und muss nach dem basteln erstmal ein paar tage laufen.

ich muss einen teil meiner aussagen revidieren

nach erneuter durchsicht der ganzen temperaturlogs fiel mir auf eines übersehen zu haben

ein Dimmer 0/1-10V PM Gen3 mit addon (b3223) & am2301 hat über jahre keinen einzigen ausreißer im log. alle anderen sehen mehr oder weniger aus wie aus den grafiken oben zu entnehmen. dieser hatte sogar noch die alte zusammengefrickelte sensorleitung.
dh -> uni gen1 und dieser gen3 sind sauber

die kabellängen bewegen sich allesamt im 1-2 meter bereich. damalsTM habe ich alles mögliche verwendet was kein extra geld kostete, reden wir besser nicht drüber xD die neueren oder überarbeiteten installationen verwenden entweder LIFY12Y11Y-3X0.25 oder reste vom kabel der ds18b20 temp sensoren.

hab die zeit genutzt und ein paar sensorleitungen getauscht + den "schlimmsten" und "besten" sensor über kreuz - mal sehen ob der fehler mitwandert

ich habe diverse asair gelabelte am2301 im einsatz und alle zeigen spikes im temp log. die sensoren stammen aus 2024-2025 via ibäh und ali gekauft.
hier ein beispiellog eines shelly plus uni von 2024

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

daten aus 2026 sehen nicht viel anders aus.
auffällig finde ich, dass die spikes sehr oft exakt dem doppelten des eigentlichen messwerts zu entsprechen scheinen.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

der einzige shelly, den das alles nicht juckt, ist der alte uni gen1 . keine solchen "spikes" im gesamten log über jahre
alle anderen (mehrere dimmer mit addons, mehrere uni plus) zeigen die gleichen auffälligkeiten, nur in anderer häufung.
komischerweise zeigen die mit den zusammengestückelten kabelresten weniger fehler als die neueren installationen, bei denen ich mir etwas mehr mühe gab
bei scripten, deren quelldaten auf solchen sensoren beruhen, habe ich nen plausibilitätscheck reingefriemelt, um fehlauslösungen zu unterbinden

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

mit 3.74.2 scheint es wieder in Ordnung zu sein

kleines update: inzwischen sind via wifi wieder -alle- devices locked

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

init über wifi dauert recht lange, tw +30 sekunden

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

nach wifi init (manchmal sind sie auch vertauscht, dann wieder beide locked)

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

wifi aus, mobile daten - alles tutti

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

wifi wieder an - locked devices wieder da - die beiden sind abgesteckt also 110% offline xD
was ich eben erst bemerkt habe -
ein dritter (auch abgesteckter) 1pm mini ist ebenfalls betroffen von diesem verhalten, ein uni gen1 hingegen wird immer korrekt als offline angezeigt, genauso wie ein weiterer 1pmm g3, der hatte aber zuvor kein paswort

mir scheint es die app kann derzeit nicht korrekt zwischen 401 und nem timeout unterscheiden

es scheint nicht 100% fixed (eindeutig besser als vorher, da ging über wifi praktisch nüscht)
im wifi werden offline devices als "locked" ausgegeben, auf mobilnetz klappts . wenn ich umschalte auf mobile daten werden sie korrekt als offline angezeigt, schalte ich zurück auf wifi gehen sie mit zurück auf locked.
evtl wird "keine antwort" als misslungene authentication gewertet?
allgemein dauert der app init deutlich länger als vor 3.74, betrifft aber auch nur wifi. über mobile daten kommt die app instant

hab grad drölfzich mal passwörter eigegeben

Beitrag

RE: Leistung wird seit gestern nicht mehr in den Räumen angezeigt

Das Problem ist bekannt und bereits in Untersuchung bei den Entwicklern. Bitte das nächste Hotfix abwarten, danke.

Angel

27. August 2025 um 12:53

mglw haut dir dieser bug rein

Kann es bestätigen, hier gibt die App seit gestern Abend nicht mehr viel von sich was leistungswerte angeht. Nur ein einzelner plugs gen3 wird noch ausgegeben

Temperatur und Feuchtigkeitswerte sind davon nicht betroffen.

Am Laptop steht seit dem reload (und damit Update) der seite auch alles.

Nein , kein Bild zu sehen

Zitat von tvbshelly

Nein, da wurde nichts zurückgezogen.

Was du beobachtest wird vermutlich einfach nur die Diskrepanz sein zw. Sicht des Shelly Update Servers (welcher die Bereitstellung in Phasen durchführt) und einem ggf. manuell durchgeführtem Firmwareupdate.

ob da etwas zurückgezogen wurde kann ich nicht beurteilen, mir scheint es jedoch so.

wiedersprechen muss ich dir bei meinen beobachtungen
die shellys, die ich heute updaten wollte, bekamen gestern /vorgestern noch via update funktion in der app die 1.70 anbeboten, da war ich aber nicht zu hause. später wollte ich die updates daheim nachholen und das geht stand jetzt nicht mehr.

die manuell geflashten habe ich ganz außen vor gelassen, sind andere modelle (plus1pm zb) und haben mit meiner vorigen aussage nichts zu tun

interessehalber, ist an dem shelly auf dem das addon steckt, der eco mode an ? falls ja, schalte den doch mal aus und beobachte das voltmeter / den log nochmal auf veränderungen

zittern / schwankungen / voltmeter error/ n/a etc auf dem analogeingang korrelierten bei mir häufig mit dem eco mode

stimmt zu, wollte später daheim eine ladung 1pmm g3 als auch ein paar unis auf 1.70 stable updaten, doch nun ist das stable release scheinbar zurückgezogen worden. die, die bereits auf 1.70 laufen, bieten nur noch 1.62 an

moin

der crash beim update mit addon scheint noch nicht ganz okay zu sein.

beim Dimmer 0/1-10V PM GEN3 löst das anstoßen des updates nach ein paar sekunden lediglich einen reboot aus. es hängt ein dht dran + voltmeter.
manchmal sind im log voltmeter fehler zu sehen gewesen, wie bei dem 1PM Gen3 neulich beim updateversuch auf beta3. war zum capturen allerdings zu träge.

/edit sagt:

der 1PM GEN3 der beim letzten mal mit addon probleme machte, wollte auch erst nicht. es brauchte mehrere reboots und gefriemel. habe das voltmeter deaktiviert & neu gestartet, danach verlief mit aufgestecktem addon das update auf beta4 erfolgreich. zufall ?

der dimmer hat eben nach ein paar weiteren versuchen plötzlich das update durchgezogen. ich kann nicht nachvollziehen was da los ist aber so 100% scheint es noch nicht zu laufen.

shos_ota.cpp:289        Starting update (0x3fcc49b4), to=600 cd=0/ct=25 ignore_same=0
shos_ota.cpp:430        manifest.json: 1342 bytes (hdr 260 desc 0 CRC f2386bb2)
shos_ota.cpp:608        fw: Dimmer0110VPMG3 ver 1.7.0-beta4 20250728-074252/1.7.0-beta4-g3ec9541
shos_ota.cpp:181        OTA status in_progress, 0 %
shelly_zx_synchroni:346 OTA in progress: synchronizer disabled
shelly_update.cpp:479   incoming fw signatures: 03
shos_ota_esp32_back:553 Will write to slot 0
shos_ota.cpp:430        bootloader.bin: 20960 bytes (hdr 44 desc 0 CRC 94152a84)
shelly_notification:210 Event from sys: {"component":"sys", "event":"ota_begin", "msg":"in_progress", "ts":1754008856.83}
shos_ota_esp32_back:804 Boot: cur 010000ff, new 010001ff, min 010000ff, update? 0
shos_ota.cpp:430        partition-table.bin: 4096 bytes (hdr 49 desc 0 CRC 2207497b)
shos_ota.cpp:430        boot_state.bin: 8192 bytes (hdr 44 desc 0 CRC 292d6ffd)
shos_ota.cpp:430        Dimmer0110VPMG3.bin: 2260576 bytes (hdr 49 desc 0 CRC bca8bf32)

Eine meiner beiden Plug s gen 3 verhält sich ebenfalls merkwürdig in Sachen wlan, leider ging dieser Thread bisher an mir vorbei.
Habe bis auf die beiden genannten keinerlei Erfahrung mit plugnplay Teilen und bin stellenweise damit fast verzweifelt.
Irgendwann hab ich sie gegeneinander getauscht , Steckdosen und Ausrichtung sind ansonsten identisch. Seitdem funktionieren beide tadellos. Weiß der Geier wieso.

Eine sitzt nen Meter neben dem Router, die Andere ist am Ende der Wohnung. Vor dem Tauschen wollte die eine partout nicht am vorgesehenen Platz neben dem Router funktionieren, obwohl die +20 anderen shellies rundherum keine Auffälligkeiten zeigten und der rssi bei -50dBm und besser lag.

Gibt es ne Chargennummer oder sowas um herauszufinden wer betroffen sein könnte ?

/edit: das Eingangs beschriebene problematische Einbinden, neustarten und Hänger waren bei diesem einen Exemplar auch der Fall