I have been using Popp outdoor plug for a month. All the sudden the energy, power, current and voltage reporting doesn’t update at all in the place where it is used (20m and 1 wall away from Homey). After multiple inclusion/exclusion the reporting doesn’t work but the on/off control of the plug works. When I move it close to Homey the reporting works.
So the problem is somehow the range, but strangely the on/off control still works, but the reporting doesn’t. Anybody else having these problems?
Other question is that is it possible to include the Popp outdoor plug unsecured? I tried to include it with the Fibaro Walli Switch trick, but the device is still included S2 Secured.
I tried creating a new z-wave device with the new flag but that flag is to force secure. It does not seem able to force insecure. So without Athom adding support, I don’t think it is possible to prevent S2 security.
S0 however is now off by default, so if the device does not support S2 a new inclusion should be unsecure. If it supports S2, it will include S2 secure.
This is a real problem for me as I am no longer able to add associations, because my switches add S2 and my dimmers unsecure. As security levels need to be the same for associations to work, I am royally screwed.
I don’t understand why Athom don’t let the user choose if they want the devices unsecure or secure paired.
With the Fibaro HC2 e.g. you have the choice.
The message on slack is a little bit outdated in terms of information I knew (was given) back then and has changed slightly.
there is only 1 tag, but the default value changes based on what devices it is S0 or S2.
Forcing it unsecure is only for S0 devices, where it by default the value of that tag = false, so if a developer wants it included secure, he/she will have to add the tag with true.
for S2 devices the default for that tag = true, so needs to be put to false by the developer for the different behaviour (include unsecure).
Thus as the value is dynamic, not sure you can add a S2 device unsecure by selecting a different device.
They didn’t the increase of support questions about adding a device secure vs unsecure, Homey is meant (they tried at least) for the ordinary people that aren’t tech savy, so they won’t know what it means and is kinda hard to explain if you don’t have some knowledge in computers.
Well I tried creating a dummy z-wave device driver (a Walli like substitute) and put the flag to false, but using it to include a Heat-it switch still resulted in S2 secure. So I cannot confirm the default is true for S2.
The documentation states it should be set to true to force locks to S2 and refuse unsecure. A useless feature IMO because it wiil include S2 if it can. So as I read it the one and only flag left cannot be used to force anything unsecure.
I appreciate that. But there are also topics about people not understanding why associations won’t work, and this is a major cause. That also needs a lot of explaining.
For me: I’ve had to send in Homey three times for repairs/investigation which usually meant one to two weeks no Homey. That would have kept me in the dark, if not for KAKU direct connections of buttons to the lights. But Athom could not fix my KAKU issues (Homey going deaf for 433Mhz after a while until a Homey reboot).
So I spent a ton of money on 18 fibaro dimmers/switches and 18 wall remotes to replace the KAKU that wasn’t reliable (had been reliable for years with Homewizard and ICS-2000). All are linked with associations so I can control my lights when Homey should fail me. Except for a new combo that cannot be linked anymore because of the S2 security being enabled on a wall remote and not the Fibaro dimmer. So I am more than a little annoyed.
I sent in a request to Athom explaining my predicament, but as always on feature requests, no reponse.
Why don’t you *1 open an “Ideas / Feature Request” thread like it’s suggested in this thread?
There will be definitely more hearts given than those users write a feature request to the Athom.
Then I will open a german language thread with a link to the “official” request thread, just to inform those users who can speak no or just little english and would ignore the “original” thread.
*1: You, because you have much more knowledge about Z-Wave, know the limitations and speak much better English than I do.
