Zwave vertragingen Fibaro Zwave

[heggico]

Ik word langzaamaan gek van Zwave.

Naar mijn idee is het vrij simpel wat ik wil. Ik heb een paar fibaro motion sensors en neo coolcams hangen voor motion detection. Dit gecombineerd met een aantal qubino flush relay switches voor de lampen aan te sturen.

Nu zit hier altijd een merkbare vertraging tussen. Ik zie de motion sensor oplichten dat ze beweging zien, en een paar seconde later gaan de lampen pas aan. Ik dacht eerst dat dit te maken had met domoticz, maar ondertussen heb ik ook openhab, fibaro home center lite en veraplus geprobeerd, maar allemaal lijken ze hetzelfde probleem te hebben. Na beweging duurt het even voordat de lampen aangaan.

Ik dacht dat dit met zwave vrijwel instant zou moeten zijn. Soms is dat ook zo en reageert alles perfect. Maar heel vaak duurt het gewoon een paar seconde voordat de lampen reageren.

De switches en sensoren + controller zitten bij mijn tests allemaal binnen 5 meter van elkaar af, dus afstand zou geen probleem moeten zijn.

Heeft iemand een idee wat ik hieraan kan doen?

[Verwijderd]

Volgens mij niks. Die zwave dingen pollen gewoon niet instant.

[akatar]

Kan best zijn dat het probleem in de qubino relais zit, probeer eens 1 andere van fibaro ofzo.

[Cave_Boy]

Zwave heeft een polling interval. Deze is naar mijn weten wel iets aan te passen maar of dit altijd goed werkt is uitproberen. Wat gebruik je nu? Heb zelf ook Zwave op een Raspberry Pi 3 (geen plus) en dit met Domotics. Beestje doet alles direct. Heb zelf niet aan de polling interval gezeten.

[UltraSub]

Zwave kan pollen maar is voor wat hier beschreven wordt echt niet van toepassing. Dit soort schakelingen zijn milliseconden werk. Er is in dit geval zeer waarschijnlijk een zwave netwerk probleem. Retransmits, configuratie fouten op een sensor, of andere foutmeldingen die het netwerk verstoren. Ik zie Neo coolcam en daar zijn best veel gevallen van bekend waarvan zo’n sensor niet goed loopt en rotzooi veroorzaakt. Range is ook een ding. Pas met een aantal powered nodes gaat routering lekker werken. Als er alleen battery devices in je netwerk zitten kun je te maken krijgen met op het randje functionerende sensoren met veel retries.
Volgende punt, polling zet je uit. Zeer belastend voor je netwerk en echt niet nodig. Polling is alleen nodig bij crap sensoren die niet zelf rapporteren. Check je zwave logs.

[heggico]

Er zitten ook een hoop (stuk of 10) nodes die rechtstreeks aan netstroom hangen (qubino flush relay)

Ik heb nu een beetje zitten spelen met de associations, wat tot nu toe toch mijn problemen lijkt op te lossen. Sommige sensoren (neo coolcams) staan alleen default op 12 uur wake up interval... Deze even teruggezet dat ik straks even wat kan gaan uitproberen.

@akatar De qubino's reageren echt instant als ik schakel in de webinterface, dus ik verwacht dat het probleem gewoon in de controller zit met een delay tussen de sensor ontvangen en de relay aansturen oid..

[Verwijderd]

De wake up interval is echt niet de oorzaak. Dit is van belang voor het updaten van nieuwe instellingen, doorgeven van de batterij status, etc.. Zodra de Neo Coolcam of Fibaro bewegingssensor beweging detecteert zal deze dat direct naar de Gateway (bijv. Fibaro Home Center) zenden, onafhankelijk van wake up of polling settings. En mijn ervaring is dan dat de lichten direct binnen ca. 0,5 sec. inschakelen (Fibaro Dimmer en Switch), zowel via een scène als associatie.
Als je de wake up interval of polling korter zet vreet dit de batterijen op van je sensors.
Kijk even naar je scènes, of daar vertraging in zit, of mogelijk worden ze uitgeschakeld omdat het aantal lopende scènes teveel is (to many instances)
Gezien het feit dat je verschillende Z-wave Gateways hebt geprobeerd, en verschillende bewegingssensoren hebt (Fibaro en NEO), zou het wel eens de Qubino's kunnen zijn. Koop een Fibaro Switch en probeer dat eens. Die werken bij mij echt goed.

[HvB83]

Ik had dat in het verleden ook wel en heb ook alle controllers doorgeprobeerd. Voor het nieuwe huis hebben we nu een Homey en tot op heden werkt het goed. Achteraf is m'n vermoeden dat het bij mij de Fibaro RGBW-modules zijn geweest die voor de problemen zorgden. Die zitten nu niet aangesloten, maar schijnt wel dat brakke modules het netwerk kunnen overspoelen met berichten en daarmee voor opstopping zorgen.

[Gonadan]

heggico schreef op vrijdag 12 april 2019 @ 10:07:
Er zitten ook een hoop (stuk of 10) nodes die rechtstreeks aan netstroom hangen (qubino flush relay)

Ik heb nu een beetje zitten spelen met de associations, wat tot nu toe toch mijn problemen lijkt op te lossen. Sommige sensoren (neo coolcams) staan alleen default op 12 uur wake up interval... Deze even teruggezet dat ik straks even wat kan gaan uitproberen.

@akatar De qubino's reageren echt instant als ik schakel in de webinterface, dus ik verwacht dat het probleem gewoon in de controller zit met een delay tussen de sensor ontvangen en de relay aansturen oid..

Beetje mosterd na de maaltijd maar je zit in de goede richting. Als je de controller de acties laat bepalen geeft dat een zekere vertraging. Opdrachten worden daar gequeued en afhankelijk van de drukte op je z-wavenetwerk kan dat relatief vlot zijn of langer duren.
Voor realtime communicatie zijn de directe associaties bedacht (die had je al gevonden zag ik). Wanneer je die correct instelt zorgen ze ervoor dat je nodes direct met elkaar communiceren wat bij scenario's als schakelaar/lamp of pir/lamp best prettig kan zijn. Je verliest alleen wel wat mogelijkheden tot meer intelligentie, maar dat heb je lang niet altijd nodig.

Het wakeup interval zegt niets over het kunnen verzenden van wat ze zien. Dat is puur het interval waarop ze echt wakker worden en zich bij de controller melden om bijvoorbeeld een nieuwe configuratie op te halen. Dat interval wil je over het algemeen echt niet te kort hebben, dat vreet batterijen.