Sorry, für die späte Antwort!

Danke, für Eure Beiträge zu dem Thema - @Dieter_P @BananaJoe @Ro75

Mein Gedanke war zunächst, daß ich näher dran bin als ein Pflegedienst oder Rettungsdienst. So sind dann selbst Fehlauslösungen erstmal weniger aufregend. Es wäre auch eine gewisse Gewöhnungsphase an das Leben mit dem Notrufknopf, bevor das professionelle System dann wirklich unumgänglich wird.

Ich werde Eure Argumente in die Überlegungen einbeziehen!

Nur noch zur Info, der Notruf-Button sollte dem ursprünglichem Gedanken nach, einen Anruf an mein Handy auslösen sowie einen internen Alarm.
Alexa allerdings wäre selbst mir zu unsicher. Selbst wenn der Gedanke, daß man einfach nur um Hilfe rufen muss um eine Aktion auszulösen natürlich sehr gut klingt. Da denke ich daß ein lokales System besser läuft.

@haus-automatisierung
Vielen Dank, daß Du Dich der Sache so schnell angenommen hast!
Noch dazu, wo es ja eigentlich eher ein kosmetisches Problem ist. Wie Du sagst, der Code funktioniert ja.

@arteck said in console.log Hinweis:

@heidi02 gesehen ?

Ja, habe ich.
Bin mir (relativ) sicher, daß das console.log() da früher mit aufgelistet war. Zumindest wurde es früher nicht vom Compiler reklamiert. Wenn ich heute ältere Scripte öffne, haben die öfter diese häßlichen roten Kästchen als Fehlermarkierung am rechten Bildrand. So hätte ich die nie abgespeichert.
Aber was soll das ganze Lamentieren. Wenn log() der offiziell vorgegebene Weg ist muss ich mich halt umgewöhnen, auch wenn das den Fingern beim Tippen schwerfallen wird.

@arniworx
Ja, das stößt mir auch seit ein paar Tagen auf. Kann gar nicht sagen seit wann das so ist. Es ist aber auf jeden Fall neu.
Javascript Adapter 7.1.6

console.info wirft sogar eine Fehlermeldung "TypeError: console.info is not a function". Wo .info doch angeblich ein Alias für .log ist (laut nodejs Doku). Dazu kann ich aber nichts weiter sagen, da ich das vorher nie benutzt habe. Bin nur durch das console.log-Problem darauf aufmerksam geworden.

@ticaki
Tatsächlich, log(). Ist mir durch Deinen Hinweis erst aufgefallen. Huch!
Früher war console.log jedoch unauffällig.

Sorry, für die späte Antwort!

Danke, für Eure Beiträge zu dem Thema - @Dieter_P @BananaJoe @Ro75

Mein Gedanke war zunächst, daß ich näher dran bin als ein Pflegedienst oder Rettungsdienst. So sind dann selbst Fehlauslösungen erstmal weniger aufregend. Es wäre auch eine gewisse Gewöhnungsphase an das Leben mit dem Notrufknopf, bevor das professionelle System dann wirklich unumgänglich wird.

Ich werde Eure Argumente in die Überlegungen einbeziehen!

Nur noch zur Info, der Notruf-Button sollte dem ursprünglichem Gedanken nach, einen Anruf an mein Handy auslösen sowie einen internen Alarm.
Alexa allerdings wäre selbst mir zu unsicher. Selbst wenn der Gedanke, daß man einfach nur um Hilfe rufen muss um eine Aktion auszulösen natürlich sehr gut klingt. Da denke ich daß ein lokales System besser läuft.

Hallo,
ich habe mein Zigbee-Netz über 2 Repeater in eine etwas entfernte Wohnung "ausgedehnt". Dort passiert nicht all zu viel. Es sind ein Repeater ein Bewegungsmelder und zwei Schaltsteckdosen eingebunden. Das funktioniert auch soweit alles problemlos.
Ab und zu taucht im Log aber mal eine Fehlermeldung auf. Ein Timeout bezüglich einer der Schaltsteckdosen. Eine Blitzwolf SHP-13. Jeweils zu Zeiten in denen kein aktiver Zugriff auf die Steckdose erfolgt.

z.B.
Send command to 0x60a423… failed with no error code (Timeout - 8832 - 1 - 253 - 6 - 11 after 10000ms)
Send command to 0x60a423… failed with no error code (Timeout - 8832 - 1 - 7 - 6 - 11 after 10000ms)

Ich frage hier eigentlich eher interessehalber, was kann ich aus diesen Meldungen entnehmen. Timeout nach 10 sec, klar. Aber was sagen mir die anderen Zahlen?

Wie entstehen die Fehlermeldungen? Wie gesagt sonst funktioniert alles ohne Probleme.

Jürgen

Hallo,
ich möchte meine Mutter mit einem SOS-Button versorgen.
Dazu habe ich probehalber ein Modell von Tuya bestellt. TuYa TS0215A_sos
Er hat zwar einen deutlichen Druckpunkt, aber für mein Gefühl lässt er sich zu leicht drücken. Ich befürchte dadurch Fehl-Alarmierungen.

Kennt jemand diesen und/oder andere SOS-Buttons und kann ggf. etwas zur Auslösekraft sagen? Vielleicht noch andere Ideen, Tipps oder praktische Erfahrungen?

In der Datenbank von Zigbee2Mqtt findet sich nur ein weiterer SOS-Button. Der sieht mir noch gefährdeter für ungewolltes Betätigen aus.

@dimaiv

Ah, ein interessanter Ansatz. Die Suche vom Ziel her aufrollen. Das schaue ich mir an. Danke!

@arteck

Danke!
Klare Antwort. Dann muss ich ja nicht weiter daran herumbasteln.

Wobei mir ja die Momentaufnahme für das jeweilige Paket schon reichen würde.

@codierknecht
Danke!
Nein, die Netzwerkkarte ist leider nicht eindeutig. Es gibt genau eine Verbindung vom Sensor zum Router. Aber vom Router gibt es mehrere mögliche Verbindungen, zum Teil über weitere Router, bis zum Coordinator.
Wenn ich den Verbindungen mit der höchsten "Link Quality" folge ergibt sich ein möglicher Übertragungsweg. /*/
Ist dieser aber tatsächlich genutzt worden?

Ich hatte die Hoffnung, daß im Datenpaket hinterlegt ist, welche Router unterwegs genutzt wurden. Bzw. welche, oder zumindest wieviele, Hops es gemacht hat.

/*/
Dieser mögliche Weg würde vom Sensor, über meinen CC2538-Router, weiter über eine LED-Lampe bis zum Coordinator führen. Die "Link-Quality" der Sensordaten ist unter Objekte mit 185 angegeben. Ich finde jedoch auf dem ganzen Weg keine Verbindung mit 185.
Die Netzwerkkarte zeigt mir vom Sensor zum CC2538-Router 58 (was mir, nebenbei, deutlich zu wenig erscheint). Vomr Router zur Lampe 118. Und von der Lampe zum Coordinator 167.
Das passt irgendwie überhaupt nicht zu den 185 von oben.

Ich habe einen Zigbee-Sensor entfernt platziert. Damit er Verbindung zum Heim-Netz bekommt habe ich ihm einen Router in der Nähe gegönnt. Die Daten des Sensors laufen jetzt also über mindestens einen Router, eventuell sogar über zwei.

Besteht eine Möglichkeit herauszufinden welchen Weg die Datenpakete real nehmen?

Ich habe schon einen alten CC2531 als Sniffer geflasht und versucht mit Wireshark nachzuschauen. Leider finde ich den aufgezeichneten Daten nichts entsprechendes. Einmal hatte ich einen vielversprechenden Eintrag "relay" gesehen, kann ihn aber nicht mehr finden. Im Wireshark Listing taucht die Hex-Adresse meines Sensors überhaupt nicht auf, wohl aber die des Routers. Sensordaten kommen auf jeden Fall an.

Das Ganze ist eher eine Frage der akademischen Neugier. Vielleicht könnte es auch helfen die Router besser zu platzieren.

Jürgen