Ja wird langsam lächerlich 
Eventuell öffentlicher bei Twitter auf den Thread verweisen und fragen ob noch eine Antwort folgt.
Auch wenn mich die Antwort nicht interessiert finde ich es schon wirklich einfach nur noch lächerlich 
Nein, eigentlich betrachte ich das Thema schmunzelnd und frage mich welche Auswirkung das nach außen trägt @Chris
1 „Gefällt mir“
nein, FLiRs Geräte werden definitiv nicht gepollt.
In der Tat trat dieser Fehler in der ersten Zeit bei einigen Gateways auf, als erste FliRs Geräte nach Europa kamen. Ursprünglich waren FliRs Geräte vor allem in den USA verbreitet, denn da ist es üblich das die Leute ein Gateway haben, an welchem 5-10 Fenserkontakte angelernt sind und ein Türschloss (mirt FliRs) verbunden ist. Wenn Sie das Haus verlassen ist das System scharf und sollte ein Alarm anstehen (meistens Fehlarlarm weil die Bewohner wieder bei sich selbst eingebrochen sind) kommt ein Sicherheitsdienst.
Aber genug OT …
Als die Geräte nach Europa kamen gab es einige Smart Home Zentralen welche FliRs Geräte gepollt haben, das führt dazu das die Batterie <24h leer ist.
Aber nein, homee tut das nicht.
4 „Gefällt mir“
Heisst das also dass es keine FLIRS limitation mehr gibt bei Homee?
Hallo @Chris,
vielen Dank, dass sich nach so langer Zeit jemand zum Thema äußert.
Damit wäre die Frage nach dem Polling beantwortet.
Wie sieht es bei den Aussagen die @Thomas getroffen hat?
-
FLiRS Geräte erhöhen die allgemeine Netzwerklast überproportional zu anderen, “normalen” Geräten
-
Zusätzlich verkürzt sich die Batterielaufzeit aller FLiRS Geräte jedes mal ein wenig mehr wenn ein weiteres solches Gerät im Netzwerk ist.
-
8 FLiRS Geräte würde ich in meinem Netzwerk nicht betreiben
Sind diese nach wie vor zutreffend? Und wenn ja, ist es ein allgemein gültiges Z-Wave Problem oder verstehen sich die FLIRS Geräte nur nicht so gut mit homee?
Vielen Dank und Gruß
Osorkon
Das ist allgemein gültig.
Zusätzlich verkürzt sich die Batterielaufzeit aller FLiRS Geräte jedes mal ein wenig mehr wenn ein weiteres solches Gerät im Netzwerk ist.
-> die Geräte gehen nicht in den Tiefschlaf und lauschen mit. Dabei wird aber nicht der gesamte Netzwerkverkehr “aufgemacht” sondern die Geräte warten auf den Aufwachintervall.
Setzt du nun also die Temperatur für das Thermostat im Kinderzimmer, wachen durch dieses “Auchwachsignal” alle deine FliRs Geräte auf. Also alle Thermostate, Türschlösser ect. Durch das “hochfahren” verkürzt sich unweigerlich die Batterielaufzeit. Daher auch die Aussage das 8 Geräte so lala sind. Das ist aber keine harte Grenze - eher eine Empfehlung.
Aber laut Z-Wave Spezifikation hat das Aufwachintervall wie du es nennst doch eine eindeutige Zieladresse. Somit dürfte doch doch nur das zu adressierende Gerät aus seinem Tiefschlaf erwachen?!
Lässt sich die erhöhte Netzwerklast auch auf deine Erläuterungen zurückführen?
Das ist doch das, was @Thomas hier schon beschrieben hat:
Die Art und Weise wie FLiRS funktioniert erhöht per Definition die Netzwerklast überproportional.
The Beam is a carrier that is transmitted for a preset period . The 2-way battery devices operate as follows: the radio turns off (to conserve battery) for 1 second and then wakes up for 1 second. If a carrier ‘Beam’ is detected the battery device will fully wake up, checks into the network with a broadcast to all the surrounding nodes. When the FLiRS device receives this broadcast, it responds with an “I do” and beams the command to that particular slave node. If it does not hear the beam command, it falls back to sleep and 1 second later starts the cycle over.
Zusätzlich zu der Tatsache, dass FLiRS Befehle nicht einfach kurz gesendet werden, sondern der Carrier Beam den Kanal für min. 1 Sekunde belegen muss, werden anschließend noch allerlei Broadcasts und Antworten auf diese rumgeschickt.
Die Flirs-Aktoren wachen alle Sekunde halb auf und lauschen, ob ein Beam kommt. Wenn ja, wachen sie ganz auf und schauen nach, ob er für sie selbst oder einen Nachbarn im Mesh ist, an den sie es weiterleiten sollen. Wenn ja machen sie die Weiterleitung und teilen das mit.
Das heißt aber, wenn so ein Beam kommt, werden erst mal alle wach, verbrauchen also mehr Batterie als wenn sie bis zum nächsten Aufwachintervall weiterschalfen würden usw.
D.h. wenn ich mehr solche Geräte haben, sende ich auch vom Controller mehr solche Befehle, die alle Flirs aufwachen lassen.
1 „Gefällt mir“
Das stimmt so aber nicht ganz wenn icj das richtig verstanden haben. flirs Geräte repeaten nicht. Das heißt sie lauschen aber nur auf das was sie betrifft.
Hallo @ch.krause,
wenn Du mir noch eine andere Quelle außerhalb der homee Community zeigst, die dieses Verhalten der FLIRS Geräte beschreibt und somit auf die Problematik der Batterielebenszeit und Netzwerklast verweist, wäre ich Dir sehr verbunden!
Bitte schöne:
https://www.silabs.com/documents/login/white-papers/Z-Wave-FLiRS.pdf
Eigentlich soll FLiRs doch bei angemessenem Batterieverbrauch die Reaktionszeit runter setzen:
It is this partially awake mode combined with the special Beam that provides for battery lives on par with fully sleeping devices while providing communications latencies of around one second.
Wenn ich aber sehr viele von diesen Geräten habe, wachen immer alle bei einem Beam auf, um zu sehen, ob sie auf das Kommando reagieren müssen, oder nicht.
When the FLiRS device receives this beam, it immediately fully wakes up and then communicates with the controller or other Z-Wave device utilizing standard Z-Wave protocol commands. If the device does not hear a Beam it goes back to full sleep for another period until it partially awakes again and listens for a Beam.
1 „Gefällt mir“
Das Dokument kenne ich schon, wurde hier im Verlauf schon mehrmals verlinkt.
Und wo finde ich jetzt die Passagen?
- Alle FLIRS Geräte wachen auf, wenn nur ein Gerät angesprochen wird.
und
- Vorsicht beim Einsatz von FLIRS Geräten (Batterielebesdauer/ Netzwerklast)
@anon11314990 man merkt du bist bei dem Thema leicht angespannt.
@ch.krause kann für deinenFrust nichts 
Ich glaube fast du wirst hier im Forum nicht abschließend alle Fragen zu deiner Zufriedenheit beantwortet bekommen. Es sind ja nun schon diverse Antworten gekommen, die du jedoch irgendwie immer wieder neu hinterfragst oder anzweifelst 
Mein Gefühl, kann auch anders sein 
PS: Das Dokument ist eine externe Quelle, auch wenn du es schon kennst 
2 „Gefällt mir“
An welcher Stelle habe ich meinen Frust ausgelassen?
Ich stelle Fragen, ja das ist richtig.
Habe zu keinen Zeitpunkt jemand persönlich angegriffen oder mich im Ton vergriffen.
Das Z-Wave Protokoll ist eines der beliebtesten Protokolle im Bereich der Heimautomatisierung und somit auch sehr verbreitet. Jedoch habe ich auch nach intensiver Rechergen keine Quelle gefunden die den eingeschränkten Einsatz der FLIRS Geräte beschreibt, bzw. die hier diskutierte Problematik.
Auch erfreuen sich die FLIRS Geräte einer immer Größeren Beliebtheit. Wenn nun eine Empfehlung ausgesprochen wird nicht mehr als 8 dieser Geräte einzusetzen, diese habe ich bis jetzt nur in Zusammenhang mit homee gehört. Darf man sich doch die Frage stellen, warum andere Z-Wave Gateways damit anscheinend keine Probleme haben.
Diese Frage wurden zumindest für mich noch nicht beantwortet.
Falls die Community hier keinen weiteren Klärungsbedarf sieht und sich bereits mit der Limitierung der FLIRS Geräte abgefunden hat, kann man den Thread auch gerne schließen.
Falls sich doch jemand von mir persönlich angegriffen gefüllt hat, bitte ich um Entschuldigung.
1 „Gefällt mir“
Nein, zumachen wird das niemand von uns Mods, mir gefällt das Gesumme in diesem Thread
4 „Gefällt mir“
Hallo Chris,
So wie ich es (und vielleicht auch andere hier in diesem Thread) aus mehreren Dokus verstanden habe, lauschen die FliRs-Geräte doch nur auf ein fix festgelegtes Nachbar-Gerät, welches dieses Beaming unterstützt, mit dem sie gepaart sind und dann auch nur auf einen direkt an sie adressierten Beam. Kommt dieser für sie adressierter Beam, wachen sie auf, die anderen Beams werden ignoriert.
Ich habe auch die Erfahrung gemacht das Beaming auch nur funktioniert, wenn ein entsprechender Nachbar-Node in relativ naher Umgebung ist, sonst hört das FLiRs-Gerät den Beam gar nicht. (Das waren meine Anfangsschwierigkeiten mit den Spirits als ich noch nicht soviele am Netz hängende FliRs-unterstützende Nodes hatte.)
Wenn jetzt alle „8“ FLiRS-Geräte an einem Node hängen, kann ich mir vorstellen, dass dies zu Probleme (beim Node) führt.
Vielleicht stimmt hier die beschrieben Theorie (laut FliRs-Dokumentation) und die tatsächlich angewendete Praxis nicht überein. Das wird dann zu der Unsicherheit bzw. zu dem Unverständnis hier in diesem Thread beigetragen haben.
Vielleicht kannst du hier noch Aufklärung betreiben.
Gruß Harry
Ich würde das jetzt auch eher so sehen, dass andere Gateways nichts dazu verlautbaren weil alles funktioniert und denen der Batterieverbrauch der Kunden egal ist. 
Und Thomas hat die Grenze von 8 als Empfehlung rausgehauen um das „optimalste“ Leistungs-/Batterieverbrauchsverhältnis von FLiRS-Geräten zu ermöglichen. Es gibt ja auch einige Leute die mehr Geräte ohne Probleme in benutzung haben, da glaube ich auch dass man da kein Limit hat, wenn man dann allerdings den erhöhten Batterieverbrauch in Kauf nimmt.
Ich bin nicht drin in der Z-Wave-Programmierung, für mich hört sicht aber das in dem PDF-Dokument so an, als gäbe es für FLiRS-Geräte nur eine Art von Beam, mit denen alle Geräte aus dem halbschlaf gerissen werden und gucken dann, ob das für die war und empfangen den Befehl und schicken ein „Jo, erledigt!“ zurück oder gehen wieder in den Halbschlaf, wenn der Befehl nicht für ihn war.
1 „Gefällt mir“
Dass die FLIRS Geräte nicht mehr gepollt werden, kann man auch aus den Release Notes homee Core | 2.11.1 (8453895) entnehmen. Das können wir also abhacken.
"FLiRS-Geräte, wie z.B. die POPP Solar-Außensirene. werden jetzt nicht mehr ständig abgefragt – das sollte die Batterielaufzeit deutlich verbessern."
Laut Z-Wave Spezifikation hat der Beam eine eindeutige Zieladresse (Node-ID) somit wird nur das FLiRs Gerät aufgeweckt, an welchen das Datenpacket auch adressiert ist. Alle anderen FLiRs Geräte schlafen brav weiter. Es wäre auch absurd, dass bei Geräten die dafür Entwickelt wurden um möglichst hohe Batterielebensdauer trotz einer 2-Wege-Kommunikation zu erreichen, von Datenpaketen aufgeweckt werden die nicht für sie bestimmt sind.
Somit kann ich die Aussage nicht nachvollziehen: Je mehr FLiRs Geräte im Netzwerk desto geringer die Batterielebensdauer dieser. Außer es wurde an der Spezifikation vorbei Implementiert.
Dass die Netzwerklast mit Zunehmender Anzahl an FLiRS Geräte steigt kann ich auch nicht nachvollziehen. Zugegeben, werden mehrere FLiRs Geräte gleichzeitig angesprochen kann es hier zur temporären Spitzen kommen. Die Lösung wäre hier „FLiRs-Multicast“. Da diese Protokoll Spezifikation noch recht neu ist, gehe ich mal davon aus, dass dies von homee noch nicht unterstützt wird.
Kapitel 4.3
Z - Wave 500 Series SDK v6.81.02
Somit darf die Anzahl an FLiRS Geräten in einem Netzwerk keinen Einfluss auf die Batterielebensdauer und auf die allgemeine Netzwerklast haben. Lediglich die Anzahl der gleichzeitig anzusteuernden FLiRs Geräte führt temporär zur einer höheren Netzwerklast. Optimieren lässt sich das durch die Umsetzung von FliRs-Multicast.
Wenn es bei homee trotzdem Abhängigkeiten gibt zwischen Anzahl FLiRs Geräte, Batterielebensdauer und Netzwerklast. Dann liegt es meiner Meinung nach nicht an der Natur der FLiRs Geräte, sondern an einer nicht optimalen Integration/Umsetzung des Z-Wave Stacks.
1 „Gefällt mir“
Hallo,
ich habe hier lange nichts dazu gesagt, weil ich auch alles was es zu sagen gibt schon erklärt habe. Einige Nutzer scheinen die Sache auch absolut korrekt verstanden zu haben. Ich schätze die Erklärung von @memooo trifft es hier auch am besten.
3 „Gefällt mir“
…und das beste an Deiner Aussage ist: Die SummSumm-Theorie hat sich bewahrheitet