Homey Community Forum

Nichtverfügbarkeit von Geräten erkennen

🇩🇪 Deutsch (German) Fragen & Hilfe
#1

Hallo zusammen,

wie erkenne ich in Homey, wenn ein (Z-Wave-)Gerät nicht mehr erreichbar/steuerbar ist?

Ich habe/hatte da schon diverse Probleme.
Von Batterie leer, über Mesh-Reichweitenproblem bis “einfach so” ist alles dabei.

Die Geräte haben doch einen Meldeintervall. Homey müsste doch erkennen, wenn er mehr als 24h von einem Gerät nix mehr gehört hat.

Konkrete Beispiele:
Die PIR-Batterie geht immer während eines Bewegungsalarm leer. Heißt, das Zuhause bleibt für immer aktiv und sämtliche darauf basierende Flows fahren gegen die Wand.

Der Batteriealarm im Heizkörperthermostat taugt nix mit Akkus. Nach wenigen Tagen, wird nur noch 1% angezeigt und ich bekomme nicht mit, wenn die Akkus tatsächlich leer sind. Erst wenn es richtig heiß oder kalt wird.(normalerweise melden sich die Thermostate ja alle 15 min bei Homey)

Einer von 13 Qubino Shuttern lässt sich von einem auf den anderen Tag nicht mehr steuern.

Ein NeoCoolcam Plug verweigert den Dienst.

Zumindest bei den ersten zwei Beispielen wäre ich für Lösungen dankbar.

Gruß
Flo

#2

Versuch mal folgendes:
Erstell einen Flow:
Wenn - Geräte - ein Gerät hat sich nicht gemeldet

Du solltest für jedes Gerät 24 Stunden einstellen, dann weißt du zumindest, wenn sich jemand einen Tag nicht gemeldet hat.
Je nach dem wieviel Geräte du hast, kann das viele Flows geben. Als Alternative kannst du die App groups verwenden und Geräte gruppieren. Dann weißt du zumindest in welcher Gruppe ein Gerät den Dienst verweigert.
Das die Batterie‐ Anzeige mit Akkus gar nicht funktioniert, hab ich schon öfters gelesen. Trotzdem kann die App Battery Monitor zumindest Hinweise geben, wer sich bald verabschiedet.
Ich hab zwar sowas nicht am Laufen, aber das wäre ein Ansatz.

1 Like
#3

Im Grunde erkennt Homey das auch. Mehr oder weniger kann man das in Developer/Z-Wave überprüfen.
Wenn in der Spalte „Flags“ „Unreachable“ steht, dann können Kommunikationsprobleme vorliegen. In der Regel weisen diese Geräte auch einen rel. hohen „Rx“ Wert auf.
Ebenso wenn in der Spalte „Route“ „Prev. last working Route“ steht.

Warum „mehr oder weniger“ und „können vorliegen“?
Eine Hand voll von Aktoren von mir zeigen immer wieder den Status „Unreachable“. Betätige ich den „Test“ Button (Menü hinter den 3 Punkten) wird zu 99,9 % „reachable“ angezeigt und das „Unreachable“ verschwindet. Die Geräte sind also doch erreichbar und haben in der Praxis auch keine Probleme gemacht.
Etwas anders sieht es aber bei batteriebetriebenen Geräten aus. Wenn bei denen „Unreachable“ steht, dann gibt’s meistens auch Probleme, kommt bei mir aber so gut wie nie vor.
Ein weiterer Punkt ist, wenn in der Spalte „Route“ „unknown“ steht, dann ist das Gerät, egal ob batterie- oder strombetrieben, ziemlich sicher nicht mehr erreichbar.

Ein paar weiterführende und fachmännische Infos findest Du hier.

1 Like
#4

viele Dank für die Infos.
Für mein Heizkörper/Batterie leer Problem sollte der Auslöser passen.

Ist der Auslöser einmalig oder löst er z.b. alle 24h aus, wenn sich das Gerät weiterhin nicht meldet?

Ich bin Mal gespannt, ob der Flow in 24h meinen Rollladen meldet.
Muss auch Mal im Developer schauen. Vermutlich routet der Node munter weiter, hat nur kein Bock mehr sich steuern zu lassen.

Habt ihr noch eine Idee für die PIR-Alarme? Kann man ein Geräte disablen, damit das Zuhause nicht mehr aktiv ist?
Aktuell verschiebe ich das Gerät manuell in einen “Akku leer” Bereich und prüfe nicht die Aktivität im Zuhause, sondern auf einer Unterzone/Bereich.

#5

Ich habe grade mal ein bisschen ausprobiert aber keine Möglichkeit gefunden ein Gerät oder eine Zone zu deaktivieren, bzw. ein Gerät in eine andere Zone zu verschieben.
Eventuell ist es mit Homey-Script möglich, damit kenne ich mich aber nicht aus.

Das einzige was mir sonst einfällt ist ein Flow, der Dich benachrichtigt. Das nützt zwar recht wenig wenn Du unterwegs bist, aber zumindest weißt Du dann bescheid und kannst z.B. Heimdall aus der Ferne deaktivieren:

Wenn…
– Batteriestand hat sich geändert
Und…
– Logik-Karte Tag “Batterie” ist kleiner als 20
– Der Bewegungs-Alarm ist an
– Niemand ist zu Hause *1
Dann…
– Push-Nachricht

*1 Ist nicht zwingend erforderlich. Ohne diese Bedingung bekommst Du halt auch eine Meldung wenn Du zu Hause bist und kannst die Batterie direkt tauschen.

Edit:
Das funktioniert natürlich nur, wenn der Batteriestand auch korrekt gemeldet wird.
Ich hatte zuletzt mit einem NEO PIR übrigens dasselbe Problem und hatte auf GitHub einen Issue erstellt. Eventuell ist es ja möglich, dass eine Option zum Deaktivieren des Geräts in die App(s) einprogrammiert werden kann.

#6

Mir fallen dazu nur die Philips HUE Motion Sensoren (innen/außen) angebunden per HUE Bridge ein. Die haben das Feature (on/off) seitens des Herstellers bereits in der HUE App implementiert und somit über die API als card in der Homey App von Athom verfügbar.

#8

dann bleibts wohl beim manuellen Verschieben.:neutral_face:

Der Rollladen Shutter ist über die Devtools nicht erreichbar und wird über meinen Flow auch nicht gemeldet.
Kann es passieren, dass ein Shutter sein Netz vergisst oder keinen Bock hat zu senden?

#9

Steht in Dev. bei Flags „Unreachable“ oder ist die Route „Unknown“?
Hast Du mal „Test“ und/oder „Heal“ ausprobiert?
Mach mal bitte einen Screenshot von Dev.

So ein Gerät kann natürlich auch defekt sein der eine Macke oder einen Wackelkontakt haben. Hast Du schon mal die Anschlüsse überprüft?

#10

image
image2040×104 10.7 KB

habe eben noch mal auf Test geklickt. Beim ersten mal hat er behaubtet, den RS erreicht zu haben. Das beweifle ich aber. Beim Klick auf Heal und weiteren Tests war der RS dann unreachable.

Vor Ort über die Taster lässt sich der RS problemlos steuern. Ich habe auch mal die Sicherung rausgemacht, damit der RS “neu startet”. Aber keine Besserung.

Und ja, dieser RS war vorher auch nicht der stabilste, sondern hat den ein oder anderen Fahrbefehl ignoriert. Entfernung zum Homey ca 12 m Luftlinie mit einigen Wänden/Hindernissen im Weg. Der Empfang ist echt ein Witz. Ich kann es nicht verstehen, warum der Empfang so mies ist und so viele Hops benötigt wurden.

Ergänzung: Im Screenshot geht/ging der Hop über Node 139. Node 139 hat imo noch nie existiert. Ich bin erst bei 128 angelangt.

btw: wie bekomme ich Z-Wave Leichen “Unknown Nodes” entfernt, wenn die Geräte im Homey UI nicht mehr vorhanden sind, aber auf Z-Wave-Ebene noch erreichbar? Homey lässt ja nur das entfernen von nicht erreichbaren Knoten zu…

#11

Na ja, es gibt zig Störmöglichkeiten/-quellen, aber deshalb suchen sich Z-Wave Geräte eigentlich ja auch selbstständig eine gut funktionierende Route und deshalb auch soviel Hops. Letztendlich ist es ja auch das Funktionsprinzip von Z-Wave. Also nicht alle Geräte direkt mit dem Gateway verbunden zu sein sondern ein Netzwerk aufzubauen. Die Reihenfolge der Hops ist meistens nicht mit Logik zu erklären, aber irgendeinen Sinn wird es schon haben.

Das wird das Problem sein. Deshalb steht bei ID 69 ja auch “Unknown” in der Spalte Route. Der RS hat also definitiv keine Verbindung mehr zum Mesh. Da hilft eigentlich nur excludieren bzw. löschen und neu includieren. Excludieren bzw. löschen der ID 69 vermutlich nur über die 3 Punkte am rechten Rand und dann “Remove” anklicken. Sollte “Remove” noch ausgebaut sein, einmal “Test” und “Heal” anklicken, spätestens dann sollte “Remove” funktionieren.

Wie oben beschrieben.

#12

wenn ein Node beim Test reachable ist, bleibt remove ausgegraut. Hier geht es nicht um den RS, sondern ein anderes Gerät. Der RS ist ja auch noch ganz normal in Homey als Gerät vorhanden, wo ich ihn auch löschen kann.

das Neuanlernen des RS führt mich zu folgendem Thema:

#13

Das weiß ich, Du hast oben aber von dem RS gesprochen inkl. Screenshot.

Und wenn der “unreachable” ist, dann kann man diesen über “Remove” entfernen.
Das eigentliche Problem wird vermutlich die ID 139 sein, und deshalb muss der RS so oder so entfernt werden in der Hoffnung, dass die ID 139 dann auch verschwunden ist.

Btw, bei solchen Problemen bitte auch Athom informieren. Ich gehe davon aus, dass solche Fehler durch Fehler in der Homey FW entstehen.

#14

hab’s Mal an Athom gemeldet