Beiträge von borsti0

    Ich habe gedacht, daß es nur einen "visuellen" Unterschied in der Darstellung macht, scheinbar scheint aber auch die Messung anders zu verlaufen?

    Da ich ja die Shelly-App nicht verwende kann ich nur sagen was die Shelly BLE Debug-App so sieht: und da kann man nur die Sensor-Entfernungen, den Messintervall und den Vibrationssensor einstellen.
    Es kommen aber auch keine "extra" Daten raus, nur: battery, vibration, button und distance.
    => Wenn da nicht noch ein Parameter "versteckt" ist kann es eigentlich nur ein "visueller" Unterschied sein.

    Ich weiß aber auch dass ich bei den Sensor-Entfernunggen NICHT alle Einstell-Möglichkeiten zur Verfügung habe, vielleicht fehlt also auch noch ein anderer Parameter bei mir :(.

    Sollte man doch warten mit dem Kauf? Ein Kumpel wollte sich den kaufen um sein Regenwasserschacht (eher zum Gießen im Sommer für den Garten) zu überwachen. Damit wenn das Wasser zu weit nach oben steigt die Pumpe per Shelly angeht. Aber wenn man das hier liest muss man wohl erstmal abwarten oder?

    Um ehrlich zu sein: ich würde noch ein wenig warten, der Frühling wartet eh noch ein bisschen.
    So wie es z.z. bei mir aussieht würde sich mein Sensor alle 2-4 Wochen "aufhängen" und müsste ausgebaut + batterie rein&raus getan werden => das ist so nicht tragbar.

    Ich habe gerade eben ein Ticket erstellt damit Shelly selbst auch über DIESES Problem unterrichtet wird.

    Aber ich bin auch mit Shelly selber wegen eines anderen Problems (Encryption) mit dem Shelly BLU Distance in Kontakt. => Es scheint ein FW-Update "in der Mache" zu sein. Leider behebt das MEIN Encryption-Problem noch nicht, aber vielleicht hilft es bei diesen Stabilitätsproblemen. Leider weiß ich nichts näheres was bei dieser FW-Version "behoben" werden soll.

    OK, ich hatte bei meinem Shelly BLU Distance nun nach ~2 Wochen schon wieder einen "Totalausfall" - gleiches Verhalten wie vorher: Keine "Reaktion" mehr, auch nicht beim Drücken der Taste, hab auch nichts mit der Shelly BLE Debug-App bekommen, usw.
    Nach Wieder-Einsetzen der Batterie ging dann alles wieder "wie vorher".

    Es hatte beim Ausfall lt. meinen anderen Außensensoren ca. -5°C und es hatte geschneit, d.h.: der Sensor war etwas im Schnee "vergraben". Da er ja wasserdicht ist sollte ihm das aber nichts machen.
    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Der eigentliche Ausfall war dann um ~12h Mittags, also schon wieder etwas "in der Sonne".

    Das ist wohl kaum umsetzbar, da ja auch die ganzen statistischen Daten / Historie in der Cloud liegen. Wenn man nur die Grundfunktionen temporär hat, würden für diesen Zeitraum zudem die währenddessen anfallenden Werte fehlen - ja, ich weiß, wenn der eigentliche Cloud-Server offline ist ist das auch so.

    naja, wenn es "vollständig" redundant aufgebaut ist mit einer Synchronisierung der Daten im Hintergrund (=> IT-Problem!!!), dann würde man nur die Daten während des "switches" (+switch back zum "main") verlieren und nicht die Daten während des kompletten Ausfalls.

    Und ich behaupte einfach mal: am WICHTIGSTEN ist die "Funktion" und nicht die "Statistik", d.h.: die Szenen sollten nur so kurz wie möglich ausfallen, dass gewisse Graphen nichts anzeigen ist meistens nur ein "optisches Problem".

    Aber die Diskussion ist leider sowieso sinnlos solange Shelly das nicht umsetzen will...

    Um es auf die Spitze zu treiben: Was ist, wenn das lokale, übergeordnete System Schluckauf hat? :/:saint:

    Oder anders herum formuliert: Wer überwacht die Überwachung?

    Naja, wenn man den industriellen Safety-Ansatz wählt:
    Alles mind. doppelt ausführen (Sensorik, Aktorik, Auswertelogik/CPU's), am besten Diversitär, eine zyklische Querkommunikation der mind. 2 "Kanäle" und bei Unterschieden der Inputs/Berechnungen/Outputs schalten beide Kanäle unabhängig von einander in einen "sicheren Zustand" der nur durch einen power cycle beendet werden kann.

    tja, das will man hald nicht zuhause machen...;).

    gibt es eine Möglichkeit eine Präsenzmeldung bzw. ein Meldung zubekommen wenn ein Shelly nicht mehr da ist bzw. nicht mehr erreichbar ist?

    Um doch einen "produktiven Lösungsansatz" vorzuschlagen:
    Ich glaube mich zu erinnern dass so ein Szenario vor einiger Zeit schon mal diskutiert wurde (es ging glaub ich um eine batteriegepufferten Teil des Hauses der erkennen soll ob die "nicht" gepufferte Seite noch "lebt").
    Soweit ich mich noch erinnere wurde vorgeschlagen dass sich die "Kontroll-Shelly's" gegenseitig zyklisch "pingen" und bei n Ping-Ausfällen annehmen dass die Gegenstelle ausgefallen ist => daraufhin kann eine Aktion ausgeführt werden.
    K.a. ob dieser Vorschlag funktioniert hatte und umgesetzt wurde.

    Frage:
    Wenn ich dich richtig verstanden habe: hast du keinerlei "Abbruchbedingung" wenn das Curton oder Tor die Endposition erreicht hat? Wird da auch nicht "in Hardware" die Fahrt unterbrochen?
    => Wie verhinderst du so einen Defekt der Curton/Tor?
    Ist es somit wirklich "sicher" (und somit sinnvoll) dass du die einzige "Stop-Bedingung" nicht direkt an den Eingängen des Shelly 2PM Gen3 angehängt hast sondern "nur" übers WLAN per Shelly Plus i4?

    So, habe heute glaub ich die dritte!!! Test-Firmware von Shelly erhalten (v1.2.11-rc6).

    Sie scheinen nun den encryptionKey-Container endlich auf die 32bytes "hochgedreht" zu haben. Es wird nun auch ein Key beim encrypten angezeigt.

    Aber nun wird in der Shelly BLE Debug-App einfach "ein anderer Fehler" angezeigt: "error: Data scrambled"
    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Auch das Logfile weißt darauf hin dass der Schlüssel nicht passt (=> falscher Key?) oder das Gerät nach dem Verschlüsseln gar nicht mehr erkannt wird (=> Unknown characteristic, Unknown sensor type, ...)

    Auch wenn ich den Key in Home Assistant verwende bekomme ich dort die Meldung dass der "bindkey" nicht funktioniert hat und die Daten nicht decrypted werden konnten.

    Ich fragte also im Wesentlichen das 2te Mal ob sie diese Version ÜBERHAUPT 1x wo eingespielt haben und dieses Szenario durchgespielt haben - offensichtlich hat bei Shelly kein einziger Mitarbeiter mit einer Release-Hardware und Release-Software diese Firmware getestet.

    Und parallel ist die Kommunikation bei der Fehlersuche miserabel!! Es kommt einfach nach ~2 Wochen ein generisches eMail:
    Hallo xxx,

    Please test the latest fw version in the attached files.

    Mit freundlichen Grüßen,

    Shelly Support Team

    => jegliches Feedback von mir (das mit Bildern und Test-Werten, abläufen, usw. dokumentiert wurde) wird nicht einmal kommentiert bzw. darauf eingegangen. Fragen im eMail werden auch nicht beantwortet.

    Mittlerweile bin ich schon sauer, ich spiele hier nicht nur den Beta-Tester, ich bin eigentlich ein Alpha-Tester für die Entwickler. Dabei werde ich behandelt wie ein Laufbursche.

    Blöde Frage: sind dann ALLE Shelly's eines "Accounts" auf den gleichen Server eingeloggt oder kann es auch eine "Mischung" in 1 Haushalt geben?
    Dies würde ja im Fehlerfall dazu führen dass nur manche Shelly-Szenen ausfallen würden.

    Es währe auch interessant wenn es da eine "Failover"-Funktion geben würde => wenn 1 Server "down" ist dass ein anderer "fallback-Server" zumindest die Grundfunktionen übernehmen kann.

    Zuallererst würde ich nachschauen, dass die beiden Programmierschalter am Motor auch wirklich auf "aus" stehen.

    das ist ja 1 Problem: es gibt ENTWEDER die "Programmier"-Stellung oder die "LÖSCHEN"-Stellung.
    => Un man programmiert die Endlagen mit einer "Tastenkombination"
    Lt. Video & Doku ist das "1x runter zur Position fahren + 2x kurz rauf + 1x lange runtern" die Kombination zum Setzen der unteren Endlage. Invertiertes Verhalten für die Obere Endlage.

    Ich persönlich finde das kritisch/lästig, da man das ja auch "unabsichtlich" mal betätigen kann.

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

    Danke für die Antwort, das ist schon etwas schwierig mit dem lora Add-on, vor allem wenn man neu bei Shelly ist, das mit dem vertrag funktioniert nicht, denn bei mir läuft alles lokal ohne Cloud Anbindung mit Homeassistant.

    wie auch horkatz geschrieben hat:
    Es ist "eine" Option am 2ten Standort ein 2tes "lokales" LAN/WLAN aufzuziehen. Wenn man die richtigen Komponenten (=> Router) wählt können diese dann die 2 Netzwerke per VPN verbinden und zu 1 "virtuellen netzwerk" machen.
    D.h.: keine Cloud, an sich NICHTS "im Internet", sondern nur ein verschlüsselter Tunnel.
    Du kannst somit von dir zuhause die Shelly's pingen, das Webinterface öffnen, FW-Updates machen, HA verwenden, uvm.
    An sich "weiß" der Shelly dann nicht einmal dass er auf der anderen Seite der VPN sitzt.

    Um aber nicht alles "schön" zu reden:
    Natürlich bedarf das die richtigen HW-Komponenten auf beiden Seiten, hat zusätzliche Latenzen durch die VPN (=> hättest du aber über LoRa sowieso), wird sicherlich auch ab und an ausfallen (=> wie alles was mit IT zu tun hat ;)), und vor allem: kostet dich je nach Vertrag zusätzliches Geld (in Ö: ~10-20€/Jahr)

    ich will nicht schon wieder anfangen mit "Macht es doch offline mit iobroker, Home Assistant & Co", aber wenn das wirklich "öfters" ein Problem bei den Shelly Cloud-Servern ist muss:
    1) ... Shelly sich dahinter stellen und das besser in den Griff bekommen
    2) ... man sich überlegen was man WIRKLICH als Szene abbilden will oder ob mans doch als Action realisieren kann

    (...und ja: ob man nicht HA & Co verwenden will ;). Sry, ich kann einfach nicht aus meiner Haut :P)

    Ich glaub nicht dass es einen "direkten" Zusammenhang gibt, aber trotzdem meine Daten direkt vor dem Ausfall:
    - Montage: senkrecht im Deckel der Regentonne, Freistehend
    - Sampelrate: 300sek
    - Vibrationssensor: aktiviert
    - keine Vibrationen (gemeldet)
    - Batterie: "fast voll"
    - Bluetooth-Empfang: ~ -95dBm
    - Packet ID "relativ regulär" auch empfangen, aber nur alle (2...5) * 5min
    - Kein Regen
    - Humidity: 100%
    - Temperatur: 0...+5°C

    Ärgerlich das der Zugang zu den Sensoren immer mit größerer Arbeit verbunden ist

    ok, da bin ich in der "glücklichen Lage" dass ich quasi nur den Deckel anheben muss um zum Shelly BLU Distance zu gelangen. Und im Wesentlichen muss man froh sein dass Shelly "von oben" ein geschlossenes Gehäuse gemacht hat, so kommt von Haus aus weniger/kein Wasser ins Gerät hinein.
    Aber solange es noch immer Totalausfälle gibt ist es je nach Einbaumethode wirklich lästig da immer wieder ran zu müssen.

    auch die "Nicht-Sendung" von aktuellen Daten in iobroker immer wieder zu Ausfällen führt

    Was ist da bei dir das Problem? Bei mir in HA bekomme ich hald dann keine Aktualisierungen - aber HA an sich läuft ja trotzdem noch weiter.

    Habt ihr bessere Erfahrungen mit kürzeren Mess-Intervallen gesammelt?

    Ich habe während des Ausfalls das "maximum-Interval" = 300sec eingestellt gehabt incl. Sampling bei Vibration (was bei starkem Regen-"Aufschlag" ein Sampling von <<<30sec verursacht)
    Mittlerweile habe ich aber auch ein "Ersatzgerät" erhalten welches bei mir am Tisch bei ~22°C mit einer Sampelrate von 30sek dahintuckert.
    => Seit dem 1 Ausfall vor ~2 Wochen werkeln nun beide "Fehlerfrei"

    Im einfachsten Fall ist das eine Excel-Datei, wo schon mal aufgelistet ist, wo genau die Geräte verbaut sind und welche Funktionen sie haben...

    Also ich persönlich bin der Meinung dass ein "händisches System" zum Scheitern verurteilt ist. Da ändert man dann im Laufe der Zeiten immer wieder Kleinigkeiten an den Konfigurationen und vergisst dort und da was man nun WIRKLICH eingestellt hat und ob mans auch wirklich bei "allen 60 Stk" gemacht hat.
    => So was muss leider automatisch funktionieren. Am Besten dann auch gleich noch mit Versionierung um bei einer Fehlkonfiguration auch den Zustand "von letzter Woche" wiederherzustellen.
    Da liiiiiiiiiiebe ich dass bei mir so einiges über Home Assistant läuft welches in einer VM ist: da ist eben alles mit einem Snapshot gespeichert und im Wesentlichen auch versioniert. Wenn die Änderung von "letzter Woche" einen patschen hat, dann spiele ich hald die Konfigration davor ein und das Haus läuft wieder....