Beiträge von biberbb

Hallo zusammen

ok, vielen Dank für Eure Unterstützung.

Ich habe mir die Links durchgesehen und bin eher ernüchtert. Es scheint mir Shelly-seitig lieblos zusammengezimmert (oder vorsätzlich schlimmer).

Dass ich mir ein Offline FW-Update gegen den Herstellerwillen zusammenklauben muss, inkl. wirrer Hash-Dateinamen, die mir keinerlei Auskunft über Authentizität oder auch nur Versionsnummer geben, die von einem Server stammen, der nur über http erreichbar ist (also keine SSL Verschlüsselung anbietet, was schon fast als Rarität gelten dürfte), für ein Gerät, dem die meisten Nutzer vermutliche direkten Zugang zu ihrem Heimnetz geben.... gruselig.

Ich bleibe bei meiner Netzwerk-Isolationshaft für alle Geräte und gehe den Weg über die holprigen NotifyStatus MQTT Nachrichten. Dafür muss ich zwar meine Flows umstellen, aber sie funktionieren nun in meinen Tests zuverlässig. Das erscheint mir mittlerweile der bessere Weg.

Das soll aber in keiner Weise Eure Einsatz- und Hilfsbereitschaft schmälern. Vielen Dank für die Mühe und die Unterstützung.

Beste Grüße

bb

Hallo zusammen

Danke für die Antworten.

Wie gesagt, ich nutze weder Iobroker noch das shelly plugin, sondern setze ganz rudimentär einfach auf den MQTT Nachrichten auf. Für mich ist das ein Sicherheits-kritischer Prozess und ich möchte so wenige Glieder in der Kette haben wie möglich.

Ich kann mal testhalber bei einem die FW aktualisieren. Um das für alle 20 zu tun ist das aber äußerst lästig, da sie 1. in einem nicht mit Inet verbundenen Wifi hängen und 2. nicht alle vor Ort, sondern u.a. im Ferienhaus usw. installiert sind.

Melde mich hier mit dem Ergebnis.

NACHTRAG: Wo finde ich denn die Firmware zum manuellen Download? (Wie gesagt, die Shellies haben keine Inet-Verbindung)

Das Einzige was ich wiederholt online finde ist https://archive.shelly-tools.de/. Die Seite ist aber shady, weil sie nicht mal ein gültiges SSL-Zertifikat hat...

Gibt es eine offizielle FW-Download area von Shelly? (Habe nur diese gefunden https://api.shelly.cloud/files/firmware, und dort gibt es nur Gen1 FW. Und... alle Download-Links sind http, nicht https. WTF???)

Danke und beste Grüße

bb

Hallo,

vielen Dank für die Antworten und Ideen!

Zitat von schreckus

welche Firmwareversion ist auf dem Smoke?

Ich habe 20 Shelly PlusSmoke installiert. Ich habe gerade die Firmware auf einem davon überprüft. Es ist 20230912-082250/1.0.3-g6176478.
(Aber ehrlich gesagt wäre ich überrascht, wenn es sich um einen Firmware-Fehler handeln würde, da es sich hier nicht um eine nette Zusatzfunktion handelt. Ich wage zu behaupten, dass ich erwarten würde, dass *die* wichtigste Sicherheitsfunktion eines intelligenten Rauchmelders (Alarm über MQTT) in *allen* veröffentlichten Firmwares gründlich getestet wurde, um das Risiko von Bugs auszuschließen. Wenn schon nicht aus Gründen der Sicherheit der Kunden, dann zumindest aus Gründen des Reputationsrisikos; d. h. wenn jemand bei einem Brand stirbt, weil ein Shelly-Rauchmelder einen Firmware-Bug hat, wäre das wahrscheinlich ein ziemlicher Marketing-Flop).

Zitat von schreckus

kann es sein das du mit Smoke.GetStatus den Status beim Smoke "abholen" musst?

Ich nutze bewusst keine externen Anfragen an die Geräte, da diese ja die meiste Zeit im Sleep-Modus sind. Es ginge vermutlich, das ganze per Webhook zu triggern, aber es erscheint mir ein unnötiger point-of-failure.

Zitat von schreckus

bei mir holt das ShellyPlugin den Status regelmäßig beim Smoke ab. Immer wenn der Smoke wach ist. geht das bei dir auch=

Ich benutze kein Plugin, sondern die Geräte wachen auf (entweder 1x pro Tag, oder im Fall von Test-Alarm oder Alarm) und senden dann eine Reihe von MQTT Nachrichten, die bei mir in NodeRed verarbeitet werden.

Hier ein Beispiel einer Test-Alarm Nachricht (roh, so wie sie per MQTT vom Gerät kommt):

Das funktioniert einwandfrei.

Bei einem "echten" Alarm sollte (!) ein "method: NotifyEvent" analog Test-Alarm ausgelöst werden. Tut es aber nicht.

Kurz darauf kommt übriges in beiden Fällen (Test-Alarm und Alarm) das übliche "sleep" Event, wenn der PlusSmoke sich wieder hinlegt:

Ich habe gerade noch weiter rumexperimentiert. Es gibt neben NotifyEvent noch zwei weitere "method" Kategorien.

• NotifyFullStatus -> Wird typischerweise 1x pro Aufwachen gesendet, aber offenbar zu früh um den "Alarm" mitzuliefern (zumindest ist er in dem Event auf "false")
• NotifyStatus -> Eher ein Debug-Kanal aus meiner Sicht. Hier werden ständig Informationen in dutzenden Einzelnachrichten hingerotzt "Network: connected", "MQTT: on", usw.
  Unter anderem werden hier auch Statusänderungen am Sleep-Zustund ("Wakeup-reason") gepostet. Und Achtung: Dort taucht im Alarm Fall interessanterweise auch "Wakeup-reason: Alarm" auf.
  
  Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.
  
  
  Es wird aber eben kein NotifyEvent ausgelöst. Ich kann also nun theoretisch meine Flows anpassen, um zu schauen, ob meine Melder mit einem "Wakeup-reason: Alarm" aus dem Schlaf aufschrecken, und dies als "Alarm" verarbeiten. Geht vermutlich, ist aber nicht wirklich schön. Außer zum Debuggen sind die NotifyStatus Nachrichten ziemlich unhandlich, und ich verstehe nicht, warum Notify-Event für alles relevante (Sleep, Test-Alarm, ...) benutzt wird - außer für das Wesentlichste, nämlich Alarm...

Ist das ein Works-as-Designed, oder doch ein Firmware-Bug?

Danke für Eure Unterstützung und beste Grüße

biberbb

Hallo zusammen,

RonnyKiel , hast Du eine Lösung gefunden?

Ich habe dasselbe Problem. Ich habe meine ShellySmokes alle via MQTT eingebunden, und die Nachrichtenübertragung ist nachweislich ok (alle senden täglich ihren Akkustand, danach das "Sleep" event, und auch Test-Alarme werden korrekt versendet)

Nur "echte" Alarme erzeugen keine MQTT Events. Das ist ziemlich bescheiden...

So sind die Dinger nur so hilfreich wie ein nicht-smarter Detektor für 5€.....

Bin für jeden Hinweis dankbar!!

Danke und beste Grüße
biberbb