Beiträge von chrissiboy

Habe inzwischen die Beobachtung gemacht, dass die Meldungen (außer der ersten) dann immer x:15, x:30, :x45 und x:00 kommen. Das sieht für mich so aus, als ob ein Timer auf ein 15-Sekunden-Rythmus eingestellt ist und nur der erste Impuls sofort ausgegeben wird. Danach läuft es, solange die Impulse anhalten, auf o.g. Schema raus.

tvbshelly : Könntest du oder einer der Co-Admins das mal aus erster Hand in Erfahrung bringen, ob das tatsächlich so ist und ob man da irgend etwas ändern kann ? Wäre natürlich top, wenn man solche technischen Informationen auch irgendwo nachlesen könnte

Ich habe einen MQTT-Broker und dort kommen die Informationen genauso an wie im WebUI.

Nein - das läuft synchron ...

Erst mal vielen Dank für eure Antworten. Ich denke, dass es allerdings kein Prell-Problem ist, sondern eher eine Einstellung in der FW ist. Zum einen ist es nicht so, dass ich die Anzahl der Impulse in Zweifel ziehe (was auf jeden Fall für ein Entprellen sprechen würde), sondern nur die Meldung etwas verspätet ankommt. Ich habe mal mit dem Fön "Sturm" gespielt und mir dann das Logfile angeschaut. Und da kamen exakt immer alle 15 Sekunden eine Meldung über die gezählten Impulse und die daraus resultierende Frequenz. Für die Regenmessung wäre das natürlich völlig irrelvant, Bei einer Markisen-Steuerung über die Windstärke sind 15 Sekunden natürlich schon eine etwas große Zeitspanne (zumindest subjektiv für mich ). Ich denke, das ist eine ähnliche Beschränkung wie z.B. bei den Bewegungsmeldern, die auch erst mal eine 30 sekündige Pause einlegen bevor sie gewillt sind, wieder eine Meldung abzusetzen. Was man dort mit dem Batterieverbrauch noch argumentieren könnte, trifft auf den Uni nicht zu. Also denke ich, es geht hier eher um die Begrenzung des Funkverkehrs, wobei ich denke, dass man das durchaus auch den Anwender entscheiden lassen könnte, wie oft die Komponenten eine Nachricht verschicken. Gerade bei den Motions finde ich 30 Sekunden schon extrem lang.

Nachtrag: Es gibt ja einige Script-Spezialisten hier im Forum. Vlt. gibt es die Möglichkeit, über den Weg eine sinnvolle Lösung zu finden.

Frage an den Moderator: Wäre es möglich, ein offizielles Statement hierzu zu bekommen ? Bei Tickets habe ich leider schon die Erfahrung gemacht, dass man keine Antwort erhält, sofern es sich nicht um einen Fehler bzw. um die Funktionstüchtigkeit eines Shelly handelt.

So, als Ergänzung noch : Auch die Windrichtung lässt sich über den analogen Eingang messen. Allerdings benötigt man hierzu dann noch einen separaten Widerstand, aber das ist ja kein Problem. MH-Helligkeitssensor funktioniert auch top. Regensensor und Temperaturmessung sind sowieso keine Herausforderung.

Bleibt noch die verzögerte Impulsmeldung. Kann hierzu jemand etwas hilfreiches beitragen ?

So, die UNIs sind da und ich habe mal mit einem einfachen Test angefangen. Ich habe den Regenmengenmesser an den Counter angeschlossen und siehe da, er zählt . Allerdings meldet er im WebUI die Pulse etwas verzögert. Der erste (von 10 Impulsen) kommt sofort und die anderen in zwei Raten zu 4 und 5 Pulsen. Eingestellt habe ich jedoch, dass er bei jedem Impuls sich melden soll. Gibt es hier noch eine andere Möglichkeit, dass er tatsächlich bei jedem Impuls (sofort) meldet ? Beim Regenmengen messen ist das natürlich kein Problem, aber ich möchte ja erst mal die Möglichkeiten ausloten.

So, den Windgeschwindigkeitsmesser habe ich auch mal angeschlossen und auch da macht der UNI was er soll - er zählt die Counts und aus denen kann man ja die Geschwindigkeit ausrechnen. Aber wie erwartet auch hier kommt die Rückmeldung mit der Summe der erreichten Pulse erst nach 10-12 Sekunden.

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

Nun ja, ich habe es jetzt hinbekommen, nachdem ich mehrfach ein Werksreset gemacht habe und das Teil in die Cloud gebracht habe (was allerdings auch mehrfach Versuche benötigte). Dort meint er dann, die Batterie sei leer (obwohl sie bei 88% ist) und irgendwann nach (nicht übertrieben) 20 mal Smoke aktivieren, hat er dann endlich den ersten Update gemacht.

Die obige Beschreibung hatte ich schon vorher probiert .. trotzdem danke für die schnelle Antwort.

Hallo,

ich bin jetzt beim Einrichten des 7. Plus Smoke und nun habe ich das Problem, dass dieser auf einer FW-Version 0.13.99 ist und beim Suchen nach neuer FW nichts findet und meint, die FW wäre aktuell. Habe auch schon auf Werkseinstellung zurückgesetzt aber das brachte keine Besserung. Gibt es eine Möglichkeit, die FW manuell einzuspielen und wo bekomme ich diese her. Ich denke man müsste wohl zunächst die 1.3.3 flashen.

Vielen Dank für die Unterstützung. Ich denke, ich werde es mal versuchen. Ich müsste sowie 2 Stück nehmen, da ich noch einen Helligkeitssensor anschließen möchte, der auch einen analogen Eingang benötigt.

Also die Wetterstation habe ich schon und für die Windrichtung gibt es 16 Stellungen mit unterschiedlichen Widerständen. Über die kann man die Windrichtung feststellen. Die Windgeschwindigkeiten kann man anhand der Impulsgeschwindigkeiten berechnen, die bei der Drehung abgegeben werden. Das könnte man auch über einen digitalen Eingang aufzeichnen. Das gilt auch für den Regenmengensensor.

Hallo,

ist es möglich, über einen Shelly Plus UNI die Wind-Werte einer Wetterstation auszuwerten ? Die Windgeschwindigkeit über den Impulseingang und die Windrichtung über den analogen Eingang ? Auch einen Regenmengensensor sollte man über einen Impulseingang auslesen können.

Zitat von funkenwerner

mit einem Rauchprüfspray?

ja

Zitat von thgoebel

Dann ist die Akustik in Ordnung. Kann es sein, daß der Smoke plus auf „mute“ gesetzt wurde („hush“ mode)?

also mute war "false" - habe versucht im WebUI den Wert zu ändern, aber es passierte nichts

ja, beim Betätigen der Prüftaste piepst das Gerät

Hallo,

ich habe erstmals versucht, einen Rauchalarm auszulösen. Sowohl WebUI als auch MQTT haben den Alarm bestätigt. Der Rauchmelder selbst hat allerdings keinen Ton von sich gegeben.

In den Einstellungen habe ich nichts gesehen und die Stummschaltung steht auf false (lässt sich scheinbar sowieso nicht ändern). Hat jemand eine Idee ?

Hallo,

ich stehe vor dem gleichen Problem - gibt es hierzu etwas Neues ? Ich bekomme zwas NULL als Response, was ja eigentlich positiv ist, aber im WebUI oder im Backend-System (MQTT/IP-Symcon) ist keinerlei Reaktion zu erkennen.

OK - scheint am TRV zu liegen. Ein anderes Gerät hat sich einwandfrei einbinden lassen.

Ich habe nun das gleiche Problem, nur dass die vorgeschlagene Vorgehensweise nichts bewirkt. Beim Update hat das Teil noch auf 100% gezählt und ist dann stehen geblieben. Seitdem geht gar nichts mehr. Hat noch jemand eine Idee ?

Hallo,

ich habe gerade ein Gateway Gen 3 in Betrieb genommen und auch gleich die 1.62 installiert. Danach habe ich ein BLUTRV angelernt und festgestellt, dass irgendetwas nicht stimmen kann. Bisher war es so, dass man auf dem WebUI auf der Homeseite diese Ansicht hat :

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

und wenn man ein TRV auswählt, folgende Seite kommt :

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. Auf diese Seite kommt man aber nicht mehr und damit kann man auch kein FW-Update des TRV mehr durchführen. Die Seite heißt eigentl. IP/#/blutrv/200/settings. Die gibt es aber nicht mehr.

Habe ich etwas verpasst oder stimmt da mit der 1.62 etwas nicht ? Was auch seltsam ist, dass nach dem Anlegen der Sensoren in der Komponentenseite die Sensoren erst nach einem Reboot des Gateways auftauchen.

Grüße Frank

OK - danke für die Rückmeldung, aber müsste der TRV nicht das gleiche Problem bekommen ?

Ich verstehe ja, dass man bei batteriebetriebenen Komponenten einen Sleepmodus verankert, damit die Batterien möglichst lange halten. Nun kann man den H&T ja auch mit einem USB-Anschluss betreiben und hat damit keine Probleme mit der Batterie-Laufzeit. In diesem Fall wäre es doch extrem hilfreich, diesen Sleepmodus deaktivieren zu können, damit man bei der Konfiguration nicht ständig die Verbindung verliert und vor allem, dass die teilweise schlechte Verbindungsqualität der H&T's (hierfür gibt es auch einen bereits 2 Jahre alten Beitrag im Forum) nicht bei jeder Meldung auf die Probe stellt, weil er sich erst mal WLAN-Verbindung aufbauen muss. Bei der alleinigen Verbindung über Bluetooth müsste das auch im Batteriebetrieb funktionieren. Die TRV's laufen ja z.B. mit nur 2 Batterien und sind auch ständig ansprechbar.