Ik heb meerdere goed functionerende fibaro dimmers 2 in Homey. 4 dimmers zijn in group5 van een dimmer aan elkaar gekoppeld op basis van hun id’s. Zodat ze gelijktijdig aan en uitgezet kunnen worden.So far so good.
Nu heb ik een nieuwe fibaro dimmer 2 opgenomen in het netwerk en deze wil ik toevoegen aan de groep van 4 gekoppelde dimmers. Dit lukt dus niet, en als ik het zo lees her en der komt dit doordat alle dimmers secure zijn behalve deze nieuwe dimmer die is niet secure.
Dat deze nieuwe dimmer default niet secure is vind ik vreemd aangezien dit de default van de dimmer is. Ik heb geprobeerd deze dimmer expliciet secure te setten middels parameter 27 op waarde 15. Ook hier reageerd de dimmer niet op. De dimmer zelfs in een ander zwave netwerk opgenomen met een fibaro controller, en deze geeft wel aan dat de dimmer groups secure zijn.
Wat kan ik nog doen om deze dimmer secure te krijgen gelijk aan de andere dimmers? Zodat ze uiteindelijk in dezelfde group kunnen communiceren.
Alvast dank voor hulp
M.v.g.Marcel
Om associaties goed te laten werken moeten de security levels overeenkomen. Ik vermoed dat je eerdere fibaros hebt toegevoegd met firmwares voor versie V7. Toen ondersteunde Homey S0 security en unsecure. S0 security is echter (in ieder geval met Homey) voor veel mensen instabiel en traag gebleken. Veel mensen (inclusief ikzelf) hebben er daarom destijds voor gekozen met een truukje alle z-wave unsecure te koppelen.
Met versie 7 van de Homey firmware is S2 security geintroduceerd. Deze schijnt veel sneller en betrouwbaarder te zijn dan s0. Met die stap heeft Athom ook besloten S0 security default niet meer te ondersteunen tenzij een Homey app daar expliciet om vraagt. Fibaro’s ondersteunen volgens mij nog geen S2 security, vandaar dat ze terugvallen naar unsecure.
Op de Homey developer page zou je moeten kunnen zien welke security je devices hebben en of ik het juist heb.
Ik heb een tijd terug daarum deze wens bij Athom ingediend [REQUEST] User selectable Z-wave security levels in order for associations to work - like deze en hopelijk dat Athom erop reageert. Dien voor de zekerheid ook een support ticket in bij Athom.
Zelf heb ik na een hoop gespeur ontdekt hoe ik devices weer kan dwingen unsecure te includen (want het truukje die ik voorheen gebruikte werkte ook niet meer). Ik heb daarum de app [APP][PRO] UnZ-Cure (add z-wave devices unsecure) in het leven geroepen zodat ik weer alle dimmers en knopjes unsecure kan includen, want een hogere security is m.i. voor dimmers en knopjes niet zo relevant en unsecure is volgens mij nog steeds de meest stabiele en snelle optie.
Als het om één knopje bij je dimmer gaat zou ik zeggen: include dat knopje ook unsecure met mijn app. Wil je alles hetzelfde dan wordt het meer gedoe.
Je wilt neem ik aan S0 security voor je meest recente dimmer. Eigenlijk raadt ik (en Athom) dat dus af. Mijn UnZ-cure app is in principe aan te passen om dat ook te kunnen. Of het wijs is in jouw geval hangt af van hoe stabiel en hoe snel je z-wave is.
Maar het alternatief zou zijn al je andere dimmers en knopjes ook unsecure te includen. Dat is nogal een gedoe met alle associaties opnieuw leggen en flows fixen.
De security levels zijn overigens na het pairen niet meer te wijzigen, dus het klopt dat parameteraanpassingen weinig helpen.
ps. voor de duidelijkheid: ik wil best een poging wagen UnZ-Cure aan te passen om S0 security te forceren maar dat doe ik natuurlijk alleen als je werkelijk S0 had en dat ook echt wil blijven gebruiken (ondanks dat Athom het niet meer aanbeveelt). Laat even weten welke richting je kiest.
Hallo, Ik zie inderdaad nu ook dat mijn fibaro powerplugs nog S0 secure gebruiken terwijl alle overige zwave Secure (x) aangeven. de Fibaro app is van Athome maar die ondersteund nog geen S2, gaat dat op korte termijn nog komen of is het raadzaam om van S0 dus over te gaan naar unsecure ?
Mijn Fibaro tussenstekkers doen het wel maar geen route door voor andere apparaten lijkt het.
Ik heb de post geliked dat nog eens is aan te passen. Hier werkt alles meestal prima, maar van tijd tot tijd is de homey wel eens even onbereikbaar en heel soms werkt een sensor (zwave) wel eens even een keer niet.
de Fibaro pluggen waren in dit geval ook juist bedoelt om als router functie te werken vanwege het betere signaal. Als ik het goed begrijp kan ik ze beter naar unsecure overzetten lees ik hier.
wel bijzonder dat juist de fibaro pluggen nog geen S2 zouden ondersteunen, weet iemand of dat dan ligt aan de homey app of aan de firmware van het fibaro apparaat , of beide ?
Een apparaat moet het uiteraard ook ondersteunen, veel Fibaro apparaten hebben geen S2, alleen S0.
Ik heb ergens gelezen dat in principe S2 security achteraf op alle bestaande apparaten toegevoegd kan worden via een firmware update. Maar of/wanneer Fibaro dat gaat doen is de vraag, en als Fibaro dat doet, dan krijg je die firmware via Homey niet in je device. Homey ondersteunt namelijk de API voor het updaten van de firmware niet.
Dan moet je het apparaat dus uit Homey verwijderen, toevoegen aan een Fibaro controller (of andere controller die firmware updates ondersteunt) updaten en dan weer opnieuw aan Homey koppelen. De app zal het dan vrijwel zeker direct herkennen als S2 ondersteund wordt, want de app laat al het zware werk over aan Homey.
Mijn advies zou zijn over te gaan naar unsecure, maar dat moet dan voor alle z-wave devices die nu op S0 zitten en waar je associaties mee wilt gebruiken. Dat doe je door ze uit Homey te verwijderen en opnieuw te koppelen. Devices die geen S2 ondersteunen worden vanzelf unsecure. Devices met een pin kun je unsecure forceren door de pin 00000 te gebruiken. S2 devices zonder pin kun je dus unsecure toevoegen met de UnZ-Cure app. Zoals gezegd gaan dan alle flows stuk dus die moet je repareren, en je moet al je associaties opnieuw instellen.
Ik kan me voorstellen dat je daar nu voor een powerplug niet heel veel zin in hebt. Maar ik vermoed dat het soms niet reageren weg is, en de ervaring van velen is dat het er veel sneller van wordt. Athom geeft aan dat er veel overhead op S0 security zit. Er is meer rekenkracht voor nodig en de hoeveelheid informatie die gecommuniceerd wordt is veel hoger. Dat duurt langer en gaat eerder mis doordat iets anders er doorheen zendt. Het zou me ook niet verbazen als S0 secure devices geen routering doen voor unsecure devices.
Mocht je een deurslot met z-wave ondersteuning hebben dan zou ik die natuurlijk wel op S2 security zetten, of als die dat niet heeft dan maar op S0. Unsecure is best secure maar met moeite wel te doorbreken. Deursloten maken dat natuurlijk meer de moeite waard. En dan ben je weer blij dat unsecure devices je secure slot niet zomaar kunnen bedienen.
ok heel duidelijk. ik heb ze nu unsecure draaien (eenvoudig verwijderen en opnieuw toevoegen werkte prima) en het lijkt misschien al iets vlotter te reageren maar mijn zwave netwerk moet zich nog wat gaan aanpassen lijkt het.
Ik wacht het even rustig af om te zien of dit zich vanzelf hersteld.
het zou wel mooi zijn dat firmware updates op de apparaten nog eens ooit ondersteund worden of duidelijk zichtbaar welke apparatuur (met name die er toe doen) S2 zou ondersteunen voor het geval je een slot of iets zou gebruiken dat beveiliging nodig heeft.
bedankt zover voor alle info!
Als je het herstel van de mesh een zetje wilt geven kun je de “heal” functie gebruiken uit het 3 puntjes menu op de developer page. Dan stuurt het device een berichtje uit naar al z’n buren. Voor batterijgestuurde apparaten moeten ze wel wakker gemaakt worden volgens de handleiding van het device.
Hi Edwin. Inderdaad de dimmers verwijderen en toevoegen zorgde voor het unsecure opnemen. Nu alle dimmers gelijk zijn werkt het met het groeperen. En ze reageren aanzienlijk sneller.
Dank voor de heldere uitleg en snelle reactie.
Nog een aanvullende vraag. Ik heb in de group5 van de dimmer ook zijn eigen id opgenomen in de veronderstelling dat de lamp die rechtstreeks op de dimmer zit meeschakeld, maar dat is dus niet zo. Enig idee waarom dat niet werkt en of dat wel kan?
Nee, helaas heb ik daar geen ervaring mee. Maar helemaal verbaast het me niet dat de dimmer niet verwacht dat je een code wilt uitzenden die voor zichzelf bedoeld is.
