Beiträge von borsti0

naja, ich kann hier eben auch nur aus meiner "Embedded"-Erfahrung im Industriebereich sprechen. Wir haben auch einen "common source" für all unsere Targets, aber es gibt hald da so einige Gründe dafür, u.a.:
- CPU-Performance
- Programmcode-Größe (=> Flash Größenlimitierung)
- RAM-Größe für u.a. Heap/Stack
- "Eigenheiten" mancher Targets & CPU's (wir haben z.b. eine CPU die kann ausschließlich 32bit-Berechnungen, also kein int8/16/64 und double, float wird intern mit 40bit berechnet, extern mit 32bit)
- Politische Entscheidung alte Targets "sterben" zu lassen
- ...

Ich denk mir: die Kunden haben sich Geräte (hoffentlich) gekauft um das AKTUELLE Feature-Set zunutzen und nicht "zukünftige" Features. Solange die in der App (und "nur für mich" in Home Assistant ) weiterhin unterstützt werden sollte das ja passen.

Natürlich verstehe ich wenn man sie leid sieht wenn ein neues Target ein Feature bekommt das man gerne hätte, MEIN eigenes Beispiel dafür:
Ich habe mir für meine RAFFSTORE damals den aktuellen Shelly Plus 2PM gekauft und habe mir u.a. in HA eine Funktion geschrieben um auch die Winkelstellung steuern zu können.
=> Wie dann die Shelly 2PM Gen3 die "slat position" dann NATIVE bekamen habe ich mich natürlich geärgert dass das meine nicht können - aber auf der anderen Seite hatte ich da ja schon einen WorkAround.
Umso mehr habe ich mich dann gefreut dass dieses Feature einige Monate später auch auf Gen2 portiert wurde.

Ich habe nun seit ~1 Monat (mit diversen Rekonfigurationen und Resets) den Shelly BLU Distance draußen in der "Regentonne" im Einsatz. Der Empfang ist zwar immens schlecht (~-95dBm), aber hinreichend um ab und ann noch ein Update zu bekommen. Ich habe den Sensor auf eine Updaterate von 300sec gestellt, jedoch das Sampling bei Vibration derweil noch aktiv lassen, damit ich mir das Ausbauen des Sensors bei Umkomfiguration ersparen kann.

Mein Problem nun: Seit ~2 Tagen schickt der Sensor nun gar keine Daten mehr.

Was habe ich gemacht:
1) Mit Handy zum Sensor gegangen, Shelly BLE Debug-App geöffnet und dann an Sensor "geklopft" => keine Detektion des Sensors in der App
2) Dann Sensor ausgebaut und Taste gedrückt => noch immer keine Detektion in der App
=> mir ist dabei aufgefallen dass beim Drücken des Tasters KEIN "leuchten" des Tasters zu sehen war, dies sollte normalerweise schon sein.
3) Lithium-Batterie rausgenommen + (gleiche) wiedereingesetzt => dann meldet sich der Sensor

Es scheint so zu sein dass sich der Shelly BLU Distance komplett aufgehängt hat => ist das schon mal wem passiert?

Auch in Home Assistant meldete er sich sofort wieder und funktionierte auch problemlos wieder.
Home Assistance-History der letzten Tage:

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

"grüner" Block nochmals genauer aufgeschlüsselt:

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

auweia, da fallen die meisten meiner Geräte (z.b.: Shelly Plus 2PM) raus. Ich verstehe aber auch dass es "irgendwo" ein Limit gibt wie viel Firmware und CPU-Power bei alten Geräten verfügbar ist.
Deswegen empfehle ich auch hier alle in den Foren: kaufts bitte keine Gen2-Geräte mehr sondern mehr Gen3/4 wenn es das Budget hergibt, denn die Gen2 werden wohl über kurz oder lang wo rausfallen => v1.8.0 scheint wohl der "Anfang vom Ende" für Gen2 zu sein...

OK, also nicht mit verschlüsselter Inter-Shelly-Kommunikation .

ok, und nun lehne ich mich schon seeeeeeehr weit aus dem Fenster:
Für was kann ich dann bei den Shellys (zumindest ab Gen2) zusätzlich irgendwelche Zertifikate hinterlegen wenn ich dann keine verschlüsselte Kommunikation aufbauen kann? Ist das nur für irgendeinen Cloud-Dienst sinnvoll?
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.

Ich dachte das könnte man "theoretisch" zumindest für eine Kommunikationsverschlüsselung verwenden .

Bei unseren Industrieanlagen wird es in naher Zukunft PFLICHT dass die "Clients" quasi den "Controller" verifizieren und auch die Datenkommunikation nicht "so leicht" gefälscht werden kann.
Das bedeutet im Wesentlichen: Verschlüsselung und Zertifikate ÜBERALL, auch am Industriellen Echtzeitbus der ja eigentlich eh vom generischen "Hausnetz" physikalisch getrennt ist.
=> das wird dann irgendwo auch Shelly treffen.

Zitat von HKaufmann

Jedes Ladegerät zieht Strom auch wenn kein Verbraucher an ist.

Mir kommt es vor dass du bei diesem Problem den Wald vor lauter Bäumen nicht mehr siehst:
Soweit ich das mitbekommen habe hast du 2 "Probleme" die du lösen möchtest:
1) Akku nicht auf 100% laden damit dieser nicht kaputt wird (und auch nicht zu leer werden lassen)
2) Laptop nicht dauerhaft an Strom hängen lassen damit dieser nicht dauerhaft Energie bezieht und Kosten verursacht

Bin ich soweit noch richtig?

Du hast dabei eine Lösung gewählt der einiges an Hardware und "Komplexität" in der Programmierung und Verdrahtung voraussetzt um beide dieser Probleme zu lösen:
2 Shelly's + Laptop-Scripte + u.u. Shelly-Scripte/Actions/... + "richtige Verdrahtung"

Ich versuch mal MEINE Meinung dazu zusammenzufassen (und es scheint mir auch die Meinung vieler anderer User zu sein):
zu 1)
Bei einem halbwegs moderner Laptop sollte es kein/kaum ein Probleme sein diesen dauerhaft "aufzuladen" da das interne Batterie-Lademanagement sich darum kümmert dass dieser nicht vorzeitig altert

zu 2)
Wenn der Laptop dann erst einmal "fertig" aufgeladen ist (=> je nach Einstellung des Batteriemanagements des Laptops), dann ist die Leistung die das Netzteil + Laptop aufnimmt nicht mehr (realistisch) messbar.

Leistungsaufnahme meines alten ausgemusterten Laptops von 2011 (also 14 Jahre alt), gerade gemessen mit einer Shelly Plug PM Gen3:
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

=> die Standby-Leistung ist nicht messbar

Wenn du für dieses "Feature" nur 1 zusätzlichen Shelly einbaust, dann braucht dieser zusätzlich 24h am Tag ~1W Leistung und kostet dich je nach Typ ~23€ (Shelly Plug S Gen3)
Beispielrechnung:
Für die 23€ Anschaffungskosten brauchst du bei 20cent/kWh bei bsp: 5W Standby-Leistung des Laptops ca. 23€ / (0,2€/kWh) / 5W = 115kWh / 5W = 23000h = ~2.6Jahre um die Anschaffungskosten "verbraucht" zu haben.


Und ich rechne noch gar nicht ein dass dich so ein Barckground-Automatismus wahrscheinlich mehr ärgern wird als er dir hilft.

Als mein "allerletzter Appell" an dich, dann verabschiede ich mich von diesem Post um nicht noch mehr Ärger zu verursachen:
Mach es nicht, es wird sich nicht "auszahlen" sowohl in € als auch bei den Nerven.

Alternativvorschlag/Frage:
Da der Shelly BLU Button1 ja scheinbar dein EINZIGES Shelly-Gerät ist dann ist die Frage: gibt es nicht ein Gerät eines Konkurrentanbieters das mit deiner Haussteuerung direkt kompatibel ist? Du gehst hier fast mit der Kirche ums Kreuz um genau diesen Shelly BLU Button1 zum Laufen zu bringen.

Zitat von horkatz

Device-Passwörter

Hier auch ein "Cloud-Verweigerer" und "Shelly App-Verweigerer", u.a. auch aus "meine Daten gehören mir"-Gründen:
Ich hatte zu anfangs auch gemeint ich verwende separate Passwörter für jedes Device um NOCH sicherer zu sein - hab aber dann auch schnell "aufgegeben". Ich will zwar auch das meine Geräte halbwegs "sicher" sind, aber das war dann für mich zu viel. Ich hatte aber auch noch Home Assistant als "Anfänger" in der Kette mit drinnen, k.a. ob ich das mittlerweile besser hinbekommen würde.
Ich "baue" nun mein Vertrauen drauf dass diese IoT-Geräte ein eigenes verschlüsseltes WLAN haben und auch im internen LAN in einem eigenen VLAN sind, somit nur eine begrenzte Anzahl an Geräten zur IoT Zugang haben. Es sind aber hald auch nicht nur Shelly's da drinnen.
In Zeiten von "Zero Trust" währe zwar eine Einzelverschlüsselung/Passwortschutz sinnvoller, aber ich bin wohl noch nicht bereit für so einen großen Aufwand.

Zitat von HKaufmann

Weil trotzdem kein Strom fliest, da ja die Shellys in der Steckdose sind. Außerdem scheint es nicht zu funktionieren.

jep, die solltest dann "ausbauen" oder 100% am Tag aktivieren - ohne Strom an der Steckdose kannst nichts machen.

Ich würde vorschlagen dass du dir anschaust OB es mit "Boardmitteln" des Laptops alleine funktioniert bevor du ein gekoppeltes System Laptop <=> Shelly einsetzt um das Batterie-Laden des Laptops zu optimieren.

Zitat von HKaufmann

Ob es schädlich weis ich nicht. Es ist nur nervig wenn ich andauernd auf die Batterieanzeige achten muß. Das ist bei mir der Hauptgrund.

Ich denk da anders rum: warum lässt du ihn nicht "24h am Tag" eingesteckt? Dann brauchst du nicht auf die Batterieanzeige achten da ja die Batterie eh immer bei 100% ist?.

Zitat von HKaufmann

Ich bin Anfänger auf Linux.

OK, gut zu wissen damit man die Vorschläge anpassen kann. Ich kann aber auch nur als "Anfänger von vor ~5 Jahren" sagen: vieles lässt sich aus Foren einfach mit bash-commandos rausholen die meist nur 1-Zeiler sind. Mit der Zeit hat bekommt man dann eh etwas "Gefühl" was/wie man mit Linux umgehen muss - aber ja: an die bash muss man sie da meist/oft gewöhnen.

Aber trotzdem: kann man bei dir das Batterieladeverhalten auch im Bios/UEFI einstellen?

OK, der Vorteil des Shelly Dimmer 0/1-10V PM Gen3 währe dass der Gen3 ist und direkt mit 230V betrieben wird.

Nachteile/KO's:
- maximal 10V => Lüfter kann somit nicht voll ausgesteuert werden
- max. 35mA => zu wenig Leistung für den Lüfter
- nur 1 Ausgang => es währen 4 Stk. davon notwendig

Aber wenn der Shelly Plus RGBW PM nicht funktionieren würde dann könnte/müsste man u.u. mit diesem Shelly eine externe Leistungsstufe für die Lüfter ansteuern

Ich habe selber ein Nuki SmartLock (ältere Generation) mit WLAN+Bluetooth aber noch ohne Matter.
Ich kann meines über WLAN + HomeAssistant-Integration "ansteuern", aber direkt im Shelly-Ökosystem hab ich davon noch nichts gehört. Ich könnt mir vorstellen wenn alles Matter ist (Shelly Gen3/Gen4 & Nuki SmartLock) dass du es dann auch "direkt" im Matter-Ökosystem ansteuern kannst.

Ich habe den schnell gegoogelt: https://www.arctic.de/p12silent
=> Bitte schau du auch noch nach ob das der Richtige ist!!!

Es scheint ein DC-Gesteuerter Lüfter zu sein (=> also KEIN PWM-Signal!!), da er einen 3-Pin Anschluss hat (GND, 12V, FAN_SPEED-Feedback) und eine "Anlaufspannung" angibt.

DC-Parameter lt. Homepage:
Minimalspannung: 4.8V
Maximalspannung: 12V
Leistung: 12V * 90mA = 1.09W => hat der Lüfter wirklich nicht mehr Leistung?!?

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

Ich habe leider selber keine RGBW-Module (Shelly Plus RGBW PM bzw. Shelly Pro RGBWW PM) im Einsatz. Soweit ich die Shelly-Homepage verstehe generieren diese per 833Hz PWM eine "DC-Spannung", welche aus der 12V/24V-Versorgungsspannung generiert wird.
Dies suggeriert dass ein diese in Kombination mit einem 12V-Netzteil für deine Aufgabe geeignet sind, leider sind die nur Gen2 und es gibt z.z. keine Gen3/Gen4-Varianten
=> Es müsste dir aber noch ein Foren-User bestätigen ob das nun wirklich so geht und ob du noch zusätzliche hardware (z.b.: RC snubber) brauchst. Es hat sicherlich schon wer DC-Lüfter mit diesem Modul im Einsatz.

Ich verwende in HA für die eigentliche "Automatisierung" dann "Node-RED". Dort habe ich mir für jede Geräteklasse einen Subflow kreiert den ich dann für jedes physikalische Gerät instanzieren kann. D.h.: eine Änderung in diesem Subflow wird auch für alle Instanzierungen übernommen .
Dort habe ich den State Node "Read" instanziert der eben alle Datenpunkte dieser 1 Instanzierung ausließt, der demux danach splittet dann die Messages auf in "Das war die Temperatur, Batterie, Taster, ..."-Ports.
Der "Read"-Block sendet auch jeden Frame in meinen überall verwendeten "Timeout"-Block. Wird dieser nicht immer wieder getriggert setzt er eine Fehlermessage ab.
Bsp Shelly BLU H&T:
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Der Timeout-Block ist kompliziert - wird aber glaub ich >40x instanziert, eben überall wo ich timeouts handeln will. Wenn man auf die "Recovery-time detection" verzichtet ist es eigentlich nur mehr der mytimeout node "Connection timeout" der übrig bleibt
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Zitat von Jensi72

Ich hab gesehen das die PacketID jede Minute um 1 hochzählt. Fängt er nach 24 wieder von vorne an?

Nein, der zählt immer um +1. Da es ein 8bit-Zähler ist läuft der einfach bei 255 auf 0 über. Je nach Gerät zählt dieser Zähler hald schneller oder langsamer.

Bsp: Ich habe 2 Shelly BLU Distance im Test: davon läuft einer mit der "Default"-Sampelrate (blau), der andere mit 5min/sample (gelb). Wenn HA ein Packet nicht empfängt zählt das BLU-Gerät trotzdem fürs nächste mal weiter (zu sehen bei den kleinen "sprüngen" bei der gelben Linie - da ist der Empfang bei ~-95dB).
In dem Screenshot ist auch mal HA selber ausgefallen - nachdem es wieder gelaufen ist hat es hald das nächste Packet des BLU-Gerätes empfangen mit dem jeweiligen Packet ID-Counter
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

allgemeine Frage: weil du schon von "PC Lüftern" sprichst: Willst du die analog regeln oder sind das Lüfter mit PWM-Eingang?
Es geht im Wesentlichen darum ob du nun eine analoge Spannung mit relativ hoher Leistung generieren musst oder nur ein PWM-Steuersignal.

OK, ich verstehe das noch nicht ganz:
Du willst einen Shelly direkt "in die Decke" vor die Lampen verbauen und hast keine Möglichkeit 2 Drähte dorthin zu ziehen wo du deine Schalter haben willst?

Die wohl "beste" Option um keine Batterien zu haben ist dass du eine Position für einen Schalter findest wo du dahinter einen zweiten Shelly mit mindestens 1 Eingang (z.b.: Shelly I4 Gen4, Shelly 1Mini Gen4, ...) verbauen kannst. Dieser sendet dann das Taster-Signal über WLAN an den Decken-Shelly (z.b.: Shelly 1 Gen4 oder Shelly 1 Mini Gen4, je nach Leistungsanforderungen) damit dieser die Lampe ein/ausschaltet => damit brauchst du dann keinen batteriebetriebenen Taster.

Alternativ kannst du natürlich als "Input" JEDES "BLU"-Gerät nehmen, da ja alle irgendwo einen Taster drauf haben den du verwenden kannst. Damit mein ich: theoretisch könntest du sogar einen Shelly BLU Door/Window verbauen (ist aber natürlich unpraktisch ).
Bsp:
- Shelly BLU RC Button 4
- Shelly BLU H&T
- ...

Anforderungen für direkte BLU-Verwendung:
- der Shelly-Aktor muss mindestens Gen3 sein (also keine Gen1-Geräte & Gen2 = "Plus"-Geräte) um BLU-Geräte direkt einbinden zu können
- beim Shelly-Input-Gerät muss im Wesentlichen nur "BLU" dabeistehen um "BTHome" zu unterstützen - der Rest ist wohl Geschmackssache.

Zitat von horkatz

Ganz ketzerisch: Netzteil anschließen, Stecker in die Steckdose, fertig...
In der Firma nutzen wir ausschließlich Dell - Laptops, meine hängen immer am Strom, außer, ich bin damit im Werk unterwegs. Konnte bis jetzt in all den Jahren noch keine Nachteile feststellen, Akkus zeigen auch nach ein paar Jahren noch keine merklichen Kapazitätsverluste.
Zu Hause (leider kein Dell, war mir in meiner Wunschausstattung dann doch zu teuer) halte ich es genauso. Beim aktuellen Rechner nach 20 Monaten noch keine Probleme. Der Vorgänger ist jetzt deutlich über 11 Jahre alt, davon war er etwa 10 Jahre im Einsatz. Der Akku hat gegen Ende zwar nachgelassen, das war aber nicht das Hauptproblem...

Bei mir in der Arbeit auch das gleiche: keinerlei Probleme obwohl der Laptop quasi 4 Jahre lang 24h am Tag am Strom hängt.
Aber man muss schon sagen: es sind hald auch "nur" 4 Jahre: im Privatbereich hat man einen Laptop vielleicht dann doch noch etwas länger....

Zitat von hominidae

Matter Controller (1x Google Hub 2nd Gen und 1x Nest Mini 2nd Gen) sind per WLAN im 5Ghz Band
Auf die Idee mit dem Mesh bin ich auch schon gekommen ... habe auch getestet, wenn Hub und 2PM auf dem gleichen AP verbunden waren.
Es funktioniert bei den anderen 6Stck. 2PM und dem heute in der Schublade aber auch "gemischt", über die APs im Mesh hinweg..

Ich hatte bei meinem Unifi-Netzwerk mal "Client Isolation" eingestellt. Das hatte den "witzigen" Nebeneffekt dass sich in meinem Mesh Geräte, welche die gleiche SSID nutzten, auf dem selben AP NICHT mehr gegenseitig sahen aber wenn diese auf unterschiedlichen AP's waren schon wieder (da die AP's untereinander die Clients dann doch nicht blockierten).

Was ich damit nur sagen will: steck doch mal testweise alle AP's bis auf 1 aus (=> Haupt-Router/AP).
Dann sind sicherlich alle WiFi Client-Geräte auf 1 gemeinsamen AP und es gibt keine komischen "Mesh-Effekte"
=> Probiere dann nochmals aus ob sich was an den "guten" und "schlechten" Geräten geändert hat (die hald noch in Reichweite sind ).

tvbshelly : danke, hatte keinen Screenshot von nem Gen1-Interface bei der hand

eine kurze Suche ergab schon mehrere potentielle Ergebnisse:
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.