Neueste Beiträge

#91

Sonstiges / Aw: Probleme mit dem SIP-Modul

Letzter Beitrag von Beta-User - 24 November 2025, 19:58:05

Also muss es vermutlich so heißen:

Code Auswählen Erweitern

define Klingel.not notify Klingel.closed

Wie war das: NOTIFYDEF wird überschätzt...

#92

Sonstiges / Aw: Probleme mit dem SIP-Modul

Letzter Beitrag von betateilchen - 24 November 2025, 19:54:08

Das Problem lag am Trigger.

Code Auswählen Erweitern

2025-11-24 14:22:26 CUL_HM Klingel closed
Da kommt doch im Event "state" gar nicht vor.
Also muss es vermutlich so heißen:

Code Auswählen Erweitern

define Klingel.not notify Klingel.closed

#93

MQTT / Aw: Lora Device per MQTT in FH...

Letzter Beitrag von Jamo - 24 November 2025, 19:39:39

Also das TTN (oder Chirpstack) Netzwerk brauchst Du, ohne das kannst Du deine Devices nicht verwenden. Weil die Devices müssen ja in einem LoRaWan Netzwerk angemeldet sein und dort von einem Gateway empfangen werden. Bei TTN kannst Du deinen Temperatursensor auch mit nach Italien oder Malta nehmen, solange der Sensor eine Verbindung zu einem TTN Gateway hat, bekommst Du zu Hause in FHEM die Daten. Das schöne an LoRaWan ist die Reichweite, bei mir über 5 Etagen mit Betondecken bis in den Keller. Oder ich kann mit dem Temperatursensor auch um den Häuserblock laufen (wer macht sowas?) und empfange die Daten trotz dichter Bebauung. Das geht mit WLAN/BT/Homematic/etc so einfach nicht.
Kommt eben auf den Einsatzzweck an.

Alternativ machst Du Chirpstack, dann bleiben deine Daten bei Dir und sind auch nur mit deinem eigenen (einzelnen) Gateway gekoppelt und werden auch nur in deinem privaten Chirpstack Netzwerk empfangen.
Meiner Meinung nach kannst Du das LPS8 auch mit Chirpstack verwenden. dann muss man nur im Gateway bei der Server Adresss "<dei.ne.IP.Adr>" eintragen (also die IP adresse von dem Rechner wo Du Chirpstack installiert hast), anstelle von "eu1.cloud.thethings.network". Port ist ebenfalls 1700. Die Anmeldung von Devices im CS Netzwerk ist äquivalent zu TTN, kein Unterschied, und die Funktionalität ist die gleiche, CS ist halt offene Software..
Das ist alles, alles andere äquivalent zu oben, auch mit MQTT funktioniert das gleich, nur die MQTT Einrichtung ist ein bischen anders.

Chirpstack Installation und Einrichtung ist gut dokumentiert, aber man muss sich ein bischen durchbeissen. Vielleicht gibts das auch schon im Docker. Man muss ja keine Ports durchreichen, sollte also mit Docker auch einfach sein.

#94

MQTT / Aw: Lora Device per MQTT in FH...

Letzter Beitrag von thinman - 24 November 2025, 18:42:53

Vielen Dank. So langsam kapiere ich es...
Wenn ich richtig verstehe, kann ich den LPS8 (ohne V2) nicht ohne das TTN Network verwenden weil um die Daten von der Sensor zu "broadcasten" ein MQTT Server und nicht nur ein MQTT Client braucht und der LPS8 hat ja nur ein Client.
Ist natürlich doof, dass die Messwerte erst um die halbe Welt tingeln müssen um danach wieder bei mir ausgewertet zu werden.

  LoRa wird als was ganz tolles, neues angepriesen aber am Ende ist es wieder nur ein überkompliziertes (und sehr teures) System welches nur einigen Hersteller zu gute kommen. Hat man keine Ahnung, fällt man den schönen Werbewelt herein... Business as usual

Ich versuche es dann so wie Du beschrieben hast und dann schauen wir weiter.
Vielen Dank für die detaillierte Beschreibung!

#95

Anfängerfragen / Aw: aWATTar - Dynamischer Stro...

Letzter Beitrag von Prof. Dr. Peter Henning - 24 November 2025, 18:37:53

Vielleicht gibt es Interessenten, die das programmiert bekommen, und so die aWATTar-Implementierung ergänzen können

Ich habe immer meine Probleme mit Menschen, die extensive und spezielle Wünsche äußern - aber dann behaupten, sie könnten das leider nicht selbst programmieren. Das ist in der Regel einfach eine faule Ausrede.

Nur abgesehen davon, dass alle die oben genannten Features problemlos mit FHEM-Bordmitteln bereitgestellt werden können: Einfach mal einen Blick auf das SolarForecast-Modul werfen.

pah

#96

Multimedia / Aw: MagentaTV

Letzter Beitrag von Monti - 24 November 2025, 18:37:11

Wow, danke für die Änderung das gibt klar einige Daumen hoch!
Nun müsste das nur noch in das Modul damit es bei einem Update nicht wieder "verschwindet".

#97

DOIF / Aw: DOIF_Readings|event_Readin...

Letzter Beitrag von holle75 - 24 November 2025, 18:19:19

Danke Damian, ja, könnte man testen, aber so ist es auch für Nachfolgende festgehalten. Ich suche mir immer die Finger wund im Forum und habe auch zu dieser keine Antwort gefunden. Bzw. für den Teil der Frage den du beantwortet hast schon.

Was ich noch immer nicht verstehe (das war die Kernfrage): ist ein attr do resetwait für einen Strang ohne wait das Selbe wie ein attr do always?

Die commandref schweigt sich dazu aus (bzw ist es wahrscheinlich so und bedarf keiner Erklärung?)

#98

Sprachsteuerung / Aw: [37_echodevice] Amazon Ech...

Letzter Beitrag von passibe - 24 November 2025, 17:57:27

Liege ich falsch, dass das cookie abläuft und deshalb automatisch regelmäßig erneuert wird ?

Die Aktualisierung des Cookies hat damit überhaupt nichts zu tun.

Es ist doch keine "Sicherheitlücke" in alexa-cookie2, sondern in npm !

Nein. npm hat keine Sicherheitslücke in dem Sinne, sondern es werden einfach die Konten der Entwickler "beliebter" Pakete durch Social Engineering, Phishing usw. gekapert und dann wird Schadcode in deren Projekte eingefügt. Man kann sich das ungefähr so vorstellen, als würde jemand deinen Account hier im Forum kapern und dann darüber Links zu irgendwelche Betrugswebsites verbreiten.


Ansonsten: Es handelt sich hier um einen Supply-Chain-Angriff. Da gibt es jetzt im Hinblick auf alexa-cookie2 zwei Möglichkeiten:

1. Der Entwickler von alexa-cookie2 selbst wird Ziel des Angriffs. Angreifer erhalten Zugriff auf sein npm-Konto und veröffentlichen eine neue alexa-cookie2-Version, die Schadcode enthält.
Dass das passiert ist aber eher unwahrscheinlich, weil alexa-cookie2 jetzt keine große Bibliothek ist, die anderswo haufenweise als dependency verwendet wird.
Zudem ist unwahrscheinlich, dass, selbst wenn das passieren würde, das den FHEM-Nutzer betrifft, weil der FHEM-Nutzer ja erstmal diese neue (schädliche) Version von alexa-cookie2 überhaupt installieren müsste. Und ich bin der Meinung, dass viele Nutzer alexa-cookie2 einmal beim Einrichten von echodevice installieren und danach eben nicht mehr aktualisieren, außer etwas funktioniert nicht oder man installiert das gesamte System neu. Typischerweise wird aber einigermaßen schnell bemerkt, dass das Konto gekapert wurde, sodass dann die schädliche Version wieder zurückgerufen wird und das Zeitfenster, in dem die überhaupt verfügbar ist, recht klein ist. Dementsprechend ist es auch relativ unwahrscheinlich, dass ein FHEM-Nutzer genau in diesem Zeitraum alexa-cookie2 aktualisiert bzw. neu installiert.

2. Die zweite Möglichkeit ist, dass das Konto des Entwicklers einer der dependencies (Abhängigkeiten) von alexa-cookie2 (klick) gekapert wird. Wie man aber sieht, sind die Versionen der dependencies da einigermaßen fix und, soweit ich sehe, aktualisiert der Entwickler von alexa-cookie2 diese dependencies auch stets manuell (klick) und sowieso auch nicht so häufig. Dass diese seltene, manuelle Aktualisierung dann ausgerechnet in einen Zeitraum fällt, in dem eine der dependencies über ein gekapertes Entwicklerkonto eingefügten Schadcode enthält, ist also erneut relativ unwahrscheinlich. Zumal auch dann der FHEM-Nutzer immer noch alexa-cookie2 manuell aktualisieren (oder neu installieren) müsste.

Diese Supply-Chain-Angriffe zielen a) auf Pakete ab, die bei ganz vielen anderen Paketen als dependency benutzt werden und b) auf Umgebungen, in denen dependencies automatisch aktualisiert und dann auch automatisch das "Endpaket" aktualisiert wird. Beides ist hier nicht der Fall.

Ich hoffe, das klärt es ein bisschen auf.

FHEM betreffend sind sicherheitsmäßige Probleme eher anderswo zu finden. Nämlich z.B. darin, dass Leute Port 8083 ohne Weiteres ins Netz stellen oder generell ihr Betriebssystem überhaupt nicht aktualisieren. Diese Sache mit npm fällt angesichts dessen (und auch angesichts der sonst geringen Wahrscheinlichkeit, wie dargestellt) nach meiner Auffassung ganz ganz untergeordnet ins Gewicht.

[nfbox]

#99

FRITZ!Box / Aw: 72_FRITZBOX.pm ab Version...

Letzter Beitrag von neobiker - 24 November 2025, 17:54:52

Hallo Jörg,

Hallo Neobiker,

wg Deiner Race-Condition könntest Du ja zusätzlich auf das Reading retStat_lastReadout triggern. Das wird ganz zum Schluss mit eine readingsSingleUpdate geschrieben.

Grüße Jörg

gute Idee, das bringt mich darauf, den Trigger umzuziehen in den Notify des Dummy, dann brauch ich kein UserReading in fbox mehr dafür:
notify: fbox retStat_lastReadout -> setreading DG_Thermo readValues fbox -> alle UserReadings aus fbox lesen

Probiere ich aus.

nfbox

Code Auswählen Erweitern

defmod nfbox notify fbox:retStat_lastReadout.* { fhem "setreading DG_Thermo readValues fbox ;;;; setreading Wz_Thermo readValues fbox" }
Gruss
Neobiker

#100

DOIF / Aw: Weihnachtsbeleuchtung scha...

Letzter Beitrag von Damian - 24 November 2025, 17:51:36

Funktioniert deine Definition denn?

Der einzige Trigger im ersten und zweiten Zweig ist [LiSens_Garage_0Uhr:state]. Wenn es am besagten Tag keinen Trigger gibt, wird der Befehl jeweils nicht ausgeführt.

Ich würde die tägliche Lichtsteuerung von den Sonderbehandlungen logisch trennen und als Anfänger in zwei DOIFs im FHEM-Modus aufteilen. Als Perlkenner kann man alles in einem DOIF-Perl-Device unterbringen. Dort lassen sich die unterschiedlichen Funktionen durch einen modularen Aufbau logisch voneinander trennen.