Beiträge von chris929

Selbst mit redundanten AP's und maximaler coverage ist WLAN nunmal als Luftschnittstelle störungsanfällig im Gegensatz zum LAN - und MQTT ist ja leider keine TCP mit re-transmit - da braucht nur irgendeine interferenz kurz auftreten und schon ist das kleine MQTT-Paket im "off" verschwunden (Broker hat gesendet, Shelly hat nicht empfangen, Game-Over). Eben aufgrund meiner Enterprise-Infrastruktur hier Zuhause (extremster overkill) kommt das nur so selten vor

Danke für die Info - dann teste ich das nachher mal, schalte den Adapter auf 1 und stelle dann nach und nach mal die Shelly's um.

Moin zusammen,

da ich hin und wieder merke (sehr selten), dass Aktionen meiner Scripte nicht zuverlässig ausgeführt werden (weil WLAN nun mal nicht 100% liefern kann) überlege ich aktuell das QoS-Setting von 0 (Fire and Forget) auf 1 (bestätige zumindest mal, dass du es bekommen hast) umzustellen.

Das muss ich ja zum einen im Adapter des iobroker.Shelly in den Settings machen, dann in den Shelly's selbst (WebUI/REST) und in meinen Scripten vermutlich auch.

Welche Auswirkungen hat das aber wenn ich das zuerst im Broker ändere, dann in den ca. 300 Shelly's hier im Haus?

Laufen die zwischenzeitlich solange nicht, bis beide Seiten QoS auf 1 haben oder akzeptiert MQTT auch einen "Mischbetrieb"? Vermutlich nicht, oder?

Hat das schon mal jemand in der Größenordnung gemacht und nen Tipp für die Migration?

Gruß

Wollte auch mal nachfragen, ob Seven of Nine vielleicht Infos für uns hat? Inzwischen haben wir ja fast 2023 und Matter bringt per Zwang IPv6 (läuft ja mit v6 unter der Haube) - da wäre es doof wenn Shelly bei z.B. Ausschreibungen rausfällt weil kein IPv6

Hallo zusammen,

ich habe vor, die DUO RGB in meinen Gartenlampen einzubauen - leider sind die mal viel zu groß

Angenommen jemand würde den "Lampenschirm" sagen wir mal "modifizieren"...

Erfüllt der außer das Licht zu "verteilen" noch ne andere Funktion? In der Lampe ist nochmal ein eigener Schirm + Gummidichtung, sodass das "doppelt gemoppelt" ist.

Sehe da erstmal kein Problem mit - aber dachte ich frag mal lieber bevor die anderen 15 Birnen geöffnet werden

Dass der Motion die Werte per MQTT nicht sauber überträgt ist ein bekannter Bug im Shelly - nicht im IoB.

Hat der Shelly-Support mir gegenüber bereits bestätigt und arbeitet an einem fix

Ich hatte selbst mit meinem neuen Ofen das "Problem", dass ich den 1PM naiv wie ich war dahinter verbaut hatte - der Ofen hat ja 230V als "Steckdose"...

Nun ja - bis ich das "Pizza-Programm" testen wollte und der Shelly bei Sprachausgabe folgendes gesagt hätte "ALTER HAST DU NE MACKE??? Heute keine Pizza für dich..."

Seit dem Tag nutze ich den Shelly EM. Mir ging es ja nur darum, den Verbrauch grob zu messen.

Der Ofen muss ja nicht an oder ausgeschaltet werden - schon alleine nicht weil dann die Uhr in der Küche "tot" wäre

Hab ich ja auch gemacht

Aber mir als "Shelly-Fan" der das gesamte Haus damit ausgestattet hat blutet das Herz wenn ich sehe wie die Plus-Serie aktuell läuft
Doch: Hoffnung stirbt zuletzt - bessert sich bestimmt mit der Zeit

Aufgrund der ganzen Probleme mit der "Plus" Serie würde ich eher wieder mal auf nen Bug tippen...

Leider ist das u.a. der Grund, warum ich im gesamten Haus noch auf Gen1 Shelly's setzen muss

Gen2 ist einfach noch nicht bereit für die "Produktion" und hätte mit der bisherigen Software nie released werden dürfen - just my 2ct.

Aber das machen aktuell ALLE Hersteller so - der Kunde ist halt der beste QA-Mitarbeiter...

Fängt bei MQTT "violations" an (halten sich nicht an best-practices bzw. Standardaufbauten des Protokolls [Stichwort korrekte Gliederung]), und endet bei inkorrekten Spannungs, Strom und Leistungsmessungen

Dazu dann "freezes" bzw. wildes "an- und ausschalten" - ich hab aufgehört die Anzahl der Tickets zu zählen die mit "known issue - will be fixed soon" und "this shouldn't have happened - we will fix this asap" zurück gekommen sind...

Hoffentlich sind die Jungs in 1/2 Jahr so weit, dass man mal langsam ernsthaft über einen Refresh von Gen1 zu Gen2 nachdenken kann.

Aktuell wäre das "grob fahrlässig" - leider...

Ich würde sogar eher den EM für Herd, Backofen etc. nutzen...

Auf Dauer mögen die kleinen Teile keinen großen Load

Schon gemacht - initial scheint der das 1x abzurufen - aber nie zu aktualisieren?

Passiert das bei euch auch? Also der Sensor selbst "pushed" keine Änderung des Wertes via MQTT

Hi zusammen,

ist euch ein Bug bekannt bei dem der Shelly Motion (neueste Firmware) den Helligkeitswert (Lux) zwar in der Web-UI korrekt aktualisiert aber per MQTT nicht "published"?

Bastele aktuell wieder viel mit dem Motion - wurde vom Adapter als Bug gemeldet - konnte ich nachstellen.

Support schweigt bisher - hat sonst noch jemand das Problem und ggf. nen Workaround?

Also bei mir hat das Update beim Austauschgerät funktioniert (hatte auch erst Angst).

Scheint so, als wäre da irgendwann mal eine fehlerhafte Charge rausgegangen - vermutete zumindest der Support in meinem Fall.

Die kenne ich auch - der US-Algorithmus wahrscheinlich nicht xD.

Erinnert mich an den Jungen damals bei Wer wird Millionär, der die Redewendung "Klappe zu, Affe tot" nicht kannte und versucht hat, da mit Logik an dieses Sprichwort ran zu gehen

Weiß jemand, wann der "Shelly 5" Adapter mal ins "stable" wandert? Die meisten Nutzer haben ja den ioBroker auf "stable" stehen und bisher rennt der Adapter ja 1a!

Beta ist ja schön und gut aber der 5er Adapter ist ja schon lange draußen - sollte doch bald mal an alle gepushed werden, oder?

Mehr User = mehr Feedback = besserer Code

Ich mache jetzt seit 6 Jahren "Facebook Freizeit" - bereuhe keinen einzigen Tag.

Facebook ist ein hate verseuchter Ort voller "Zombies" geworden die eh alle alles besser wissen - bei den meisten kann man bei der IQ-Schmelze zusehen...

Gibt (z.B. dieses Forum) sooooo viele schönere Orte an denen man die Zeit viiiiiiel sinnvoller Nutzen kann

Hätte aber in diesem Fall getippt, dass die dumme KI dir eher wegen "Aufruf zur Waffengewalt" das SEK automatisiert sendet

Bin ja mal gespannt, wann der Shelly5 Adapter von "dev" nach "stable" wandert.

Ich bräuchte quasi ein "true" bei FW + ein "jetzt ist er online und ich will updaten" - der soll ja erst nach einer "freigabe" das Update einspielen - meistens warte ich nach Veröffentlichung 5-7 Tage (installiere nur auf Testgeräten) bevor ich das ganze Haus update.

Firmware "true" sehe ich auch im iobroker.

Aber ich habe mal versucht auf diese Änderung bzw. ne Änderung in der Uptime zu matchen - bisher war der trotzdem nie lange genug "online" um das update zu bekommen...

Wie schaffst du es, dass er den Befehl auch bekommt?

Hab mal nen ICMP-Monitor laufen lassen - meine Geräte sind für ca. 1sek da und dann schon wieder "offline" - der ioBroker loggt fleißig die Temp und Humidity-Änderung, aber diese 1sek scheint meiner "Logik" irgendwie nicht zu reichen (bis das verarbeitet ist, ist das Teil schon wieder offline)

Hi zusammen,

vielleicht hat jemand von euch sich damit schon beschäftigt

Ich hab meine Shelly (1PM, 2.5, H&T) in einer DMZ ohne Internetzugriff laufen.

Mit einem selbstgebauten Python-Script kann ich den 1ern und 2.5ern jeweils das Firmwareupdate pushen - ist ja kein Hexenwerk.

Bei den H&T habe ich ja die "Herausforderung", dass die nur alle x Minuten mal kurz Werte liefern und dann wieder "schlafen".

In der Shelly Cloud gibt es ja den haken "mach das update wenn dein Gerät das nächste mal ans Netz geht".

Hat das schon mal jemand lokal nachgebaut? Würde gerne intern (kann ja ein Webserver sein) das file irgendwo hinlegen, sodass der H&T sich das ebenfalls beim nächsten "wake" zieht und auch mitbekommt, dass er ein Update fahren kann.

Bin für jeden Hinweis dankbar

Gruß

Christian

Na ja - ich hab keinen Importeur - kaufe direkt im Shop.

Auf der Seite habe ich recherchiert (logo, den kauft man nun mal nicht täglich) und bin auf besagte Doku gestoßen.
Ob das jetzt Sinn macht oder nicht mag ja jeder selbst entscheiden.

Das Gerät hat die N-Klemme, die Doku sagt "Optional" also sage ich als alter Perfektionist: Um alles "100%" zu haben, will ich das Teil dann auch haben.

Hinterher höre ich dann vom Support "not supported" / "will not be supported"...
Wäre N niemals "optional" in der Doku aufgetaucht dann hätte niemand je die "nutzlose" Klemme gekauft (ich nutze die jetzt für meinen EM).

Ich frage mich jetzt auch ernsthaft nach dem generellen Sinn dieser Schnittstelle wenn selbst Allterco sagt "we will not implement this".
Hätte man mit nem anderen Gehäuse plump "verdecken" können wenn die Platine das unbedingt gebraucht hätte (bezweifle ich ebenfalls).

Was keinen Sinn macht oder nie supported wird (so lese ich meine Antwort von Shelly direkt) sollte meiner Meinung nach nicht existieren, oder?
Man sieht ja, dass das zu extremer Verwirrungen führt und zu "unmut" beim Support.

Manchmal verstehe ich Hersteller einfach nicht... Scheint ne generelle übergreifende Krankheit zu sein sich selbst Eier zu legen