Shelly >= 10.0.0 mit verschlüsselten BLU-Geräten
-
@haus-automatisierung
Ich bekomme auf allen Shellys folgende Fehlermeldung mit dem Script 1.0✕ Uncaught ReferenceError: "unpackedData" is not defined at console.log('Received ' + JSON.stringify(unpackedData)); ^ in function called from systemWenn ich:
console.log('Received ' + JSON.stringify(unpackedData));auskommentiere
// console.log('Received ' + JSON.stringify(unpackedData));Ist die Fehlermeldung weg und die Bluetooth Geräte laufen ohne Probleme.
Danke
Heiko
-
@eve11
Bitte verwende die aktuellste Version des scripts. Der Fehler im Script und seit heute auch der Link in der Tabelle sind schon korrigiert.P.S. Genau diese Zeile wurde entfernt.
EDIT
siehe auch hierhttps://forum.iobroker.net/topic/80722/test-adapter-shelly-10-1-0-latest-beta/24
und nachfolgende Posts.
-
@haus-automatisierung
Lieber Matthias,
vielen Dank für das Mega Update ich bin schon von Anfang an dabei als du BLE integriert hast. Habe alles gemacht wie in deinen Video bei einem Blue Botton und läuft alles perfeckt mir der EcryptionKey. Mega Mega
Vielen Dank herzliche Grüße aus Köln
Fabio -
Nachdem ich gestern Sorgen hatte, welche Kopfstände ich denn machen müsste, um mit dem Raspberry meine neuen Shelly Door/Window-Sensoren abzufragen, habe ich hier die Lösung gefunden, die den Host komplett schlafen lässt (hinsichtlich Bluetooth) und die Arbeit in die anderen Shellys verfrachtet.
Nach der Lektüre zum Thema ging das dann erstaunlich einfach, sobald das Skript in meinem Energiemesser gestartet war, hatte ich auch schon die ersten Datenpunkte unter
shelly.0.ble.Über Nacht haben sich sogar die unausgepackten Sensoren aus dem Karton im Keller durch die Betondecke angemeldet.
Danke!
Wenn ich das richtig sehe, kann ich jetzt weitere Shellys mit dem Skript ausstatten, und die werden sich dann zu übertreffen versuchen, wer als erster neue Daten meldet, so dass Redundanz entsteht?
Zwei kosmetische Anmerkungen:
- In der Tabelle wäre es gut anzumerken, ob es tatsächlich eine 1:1-Zuordnung von Adapter- und Skript-Version sein muss, oder ob das neueste Skript auch einen älteren Adapter bedienen kann. Da kamen jedenfalls Warnungen im Log, nachdem ich dann auf 10.3.0 gegangen bin, sind die weg.
- der Datenpunkt
pidhat den Namen "Von Geräten empfangen", das klingt so als hätten 57 Shellys etwas weitergemeldet. Laut Shelly ist das aber die Paket-ID, die in einem 8-Bit-Záhler die Pakete nummeriert, offenbar damit man weiss ob man das aktuellste gesehen hat, das entspricht auch meiner Beobachtung.
Encryption schaue ich mir später an, hielt aber das Topic mit dem aktuellen Release für den sinnvolleren Platz.
Shelly 10.3.0-alpha.3
Skript v1.2 -
@hardwarefehler sagte in Shelly >= 10.0.0 mit verschlüsselten BLU-Geräten:
In der Tabelle wäre es gut anzumerken, ob es tatsächlich eine 1:1-Zuordnung von Adapter- und Skript-Version sein muss, oder ob das neueste Skript auch einen älteren Adapter bedienen kann.
Kann theoretisch schon. Wird aber unnötig komplex. Daher passt immer nur genau eine Script-Version zu einer Adapter-Version und alle anderen werfen einen Fehler.
@hardwarefehler sagte in Shelly >= 10.0.0 mit verschlüsselten BLU-Geräten:
der Datenpunkt pid hat den Namen "Vor Geräten empfangen", das klingt so als hätten 57 Shellys etwas weitergemeldet.
Genau das passiert ja auch, wenn das Script auf mehreren Shellies läuft?!
-
@haus-automatisierung said in Shelly >= 10.0.0 mit verschlüsselten BLU-Geräten:
Genau das passiert ja auch, wenn das Script auf mehreren Shellies läuft?!
Momentan läuft es bei mir auf genau einem Shelly, trotzem zählt die PID mit jeder Meldung artig eins hoch, was der API-Doku entspricht.
BTHome sensor data objects 0x00 packet id uint8 1 revolving counter -
@hardwarefehler sagte in Shelly >= 10.0.0 mit verschlüsselten BLU-Geräten:
Momentan läuft es bei mir auf genau einem Shelly, trotzem zählt die PID mit jeder Meldung artig eins hoch
Das ist ja auch richtig. Daran macht der ioBroker ja auch fest, ob er die Nachricht schon bekommen hat und fasst die gleiche Nachricht von mehreren Empfängern zusammen. Sonst würdest Du ja auch ggf. mehrere Events in einem Trigger bekommen. Das wäre ja unschön.
-
Genau. Mich irritiert ja nur der Name "Von Geräten empfangen". Meines Erachtens sollte das dann einfach "Paketnummer" heissen
-
@hardwarefehler Ach, jetzt verstehe ich das erst. Danke, ist ein Bug bzw. Copy/Paste Fehler. Korrigiere ich
-
@haus-automatisierung
Einer der Fenstersensoren auf dem Schreibtisch flutet grade das Log, etwa 2x/Sek, mitweb.0 2025-10-08 13:39:29.631 warn Read-only state "shelly.0.ble.********.rotation" has been written without ack-flag with value "8"wobei der Value zwischen zwei Zahlen alterniert.
Ich wüsste gern, ob ich beim Shelly- oder beim Webadapter zu suchen beginnen soll.
Bei meinen ersten Tests, als ich nur in die BLE-Objekte geschaut hatte, habe ich sowas nicht gesehen, erst als ich mit vis-2 angefangen habe das zu visualisieren.
-
@hardwarefehler
Ich würde da nicht den Shelly sonder denjenigen Adapter (web) in die Pflicht nehmen der den State versucht zu beschreiben. Der Shelly Adapter darf nämlich seine States beschreiben udn würde die Meldung nicht auslösen.Kurz:
web.0 schreibt wo hin wo er nicht darf.
Das ist KEIN Problem des Shelly Adapters.Da du schreibts dass das erst mit vis-2 angefangen hat solltest du dort zu suchen anfangen.
-
@mcm1957 - danke für deine Hinweise zur Eingrenzung des Problems.
Ursache ist mit hoher Wahrscheinlichkeit das
hqwidgets - CircleKnob, mit dem ich den Winkel visualisiert habe. Dieses erlaubt auch das Setzen des Wertes, egal ob dort der Schalter "Nur lesend" gesetzt ist oder nicht.
Mit bewusstem Setzen des Wertes konnte ich den Logeintrag reproduzieren. Das Flattern zwischen zwei Werten von heute nachmittag nicht, da muss noch ein weiterer effekt mitgespielt haben. -
Nur mal als ungetestete Idee
Ev kannst du nen Alias dazwischen schalten u via getrennte States f schreiben u lesen die Schreiboperationen blocken.Und natürlich kannst auch ein issue beuim widget einstellen. Bei RO sollte es natürlich nichts schreiben ....
