Why not just go for Neo Coolcam power plugs? They are Z-wave and cheap…
Mine works now, thank you for your time!
A day ago I’ve noticed that actually KAKU is second most popular app on homey if the display order on the “most popular” apps reflect number of installation actually. First one is fibaro.
That being said I really do like KAKU (CoCo) devices. For simple lights they really are efficient, keeps EM noise to a minimum and can be fully independent from the gateways. My main issue with KAKU app by Athom is that you cannot assign more then one code with KAKU light i.e. In reality each KAKU device can have up to 6 codes programmed into them. Unfortunately in Homey app this is impossible to replicate so this ends in completely wrong statuses in homey app. Pity as this really are good devices and app is relatively good aside of the mentioned issue.
This is always going to be a problem with 433Mhz KAKU devices, because the devices themselves provide no feedback. So if you use an external remote, either Homey or the device may or may not receive the signal, at which point the status will start deviating. Also when using Homey as the transmitter, it will never know if the device actually received the signal or not.
Sure sure, fully known. But in case you only have wireless sender switches homey would be fully capable of assigning multiple codes to a light and properly receiving the codes.
Biggest issue is present if you have two wireless switches located i.e. each end of the bedroom both programmed to the same light. You simply cannot avoid messing up the homey app with this kind of implementation. Situation complicates if you have dimming light you cannot fix it even with flows.
That would actually take away the added value for Homey. The KAKU-idea (without Homey) is that you can link multiple transmittors to a single reciever. Homey takes that over. (all transmittors send to Homey, and the reciever listens to Homey)
I strongly disagree with you. So in case of unavailability of homey you cannot even turn on the light? Like I said I strongly disagree and my main goal is to have homey as aid not as single point of failure. You can have wireless switch coded directly to the light and duplicated in homey and homey will pick it up and change the light status. What homey cannot do is have two switches to the same light (one yes).
Second solution is to have flow that detect push of the wireless switch and changes state of the light in “software” without radio transmitting. You can then avoid having wireless switch sending ON, then flow sending ON again.
I obviously understand what you’re trying to achieve, but as @robertklep said, this is one of the pitfalls of the whole KAKU setup (433 protocol). The targets don’t report back.
The idea of a domotica hub is to be the single point of control and with that a single point of failure for your entire setup.
Even if the Homey app would have multiple source id’s, then the known status could still be skewed if the receiver doesn’t receive or properly respond or if homey doesn’t recieve your switch, but your bulb does.
Yes, what you are saying is correct. This is known for coco. It might be off sync. But now, with this flaw “might” is not the situation, now it’s all the time wrong. This is my point.
We know that coco might get skewed but that doesn’t mean app should always be messed up because it’s not fully supporting real life implementations. If it’s so popular this could really be a bit adjusted (enhanced).
P. S. About single point of failure I again completely disagree. I have fibaro + kaku implementation. Both are fully independent of homey at least for basic function. Doorbird, netatmo, heating, most of my equipment is also independent. Homey simply is not so reliable to be SPOF for basic (critical) house functions.
Can Click On Click Off (KaKu) devices that are not in the Homey list (for example, a temperature gauge) are added to Homey without the intervention of a HomeWizard or other device?
Does anyone have experience with this? Then I would like to hear that.
My advice is to create an Enhancement Requests on GitHub.
Sorry @HansieNL Wrong answer!
This issue tracker is for bugs and issues found within Homey and Athom Apps.
If you require more general support contact Athom’s support team
at: support@athom.com
Request for support of new devices can be done in a new Form: https://go.athom.com/request-device-support
(If it was a new type KAKU 433Mhz socket or button it probably would have worked by paring as another socket/button but as you are not specific I would have to guess…)
What kind of range are people experiencing with the wireless wall switches? I don’t have a particularly large house, but with Homey in my office upstairs and the switch in the backyard, Homey wasn’t picking up on any button presses. I moved Homey downstairs into the kitchen for testing purposes and it’s working fine. I’d strongly prefer Homey in my office though, so I’m wondering if there’s anything I can do to improve the range.
I use KaKu (433) in my back garden, distance approximately 12 m, works fine.
Obstacles: brick (40 cm) wall with a window of triple layered glass, switch in wooden (4cm) shed.
There are kaku range extenders maybe that helps?
The weird thing is that zigbee and zwave have way smaller ranges in my house then 433 and 868 mhz have.
Homey is in my living room and can control all kaku / somfy (433 and 868 mhz) products on my property.
since homey 4.2.0 the klikaanklikuit devices don’t work for me anymore.
I’ve tried rebooting homey without any effect.
I’ve reinstalled the app (meaning I’ll have to re-add each device again, not an easy task since 7 of my klikaanklikuit devices are built-in…), but still no success.
When I tried to signal a klikaanklikuit device installed on homey, I got a 30000ms timeout.
Right now, I can add any klikaanklikuit devices, because when adding I get the same timeout issue.
I’ve ofcourse contacted homey support, but was wondering if any of you have experienced the same issues?
1 Like
Since it’s timing out, it sounds like an issue with the part of Homey that handles KaKu communication. Perhaps Homey is unable to contact the microcontroller that handles RF communication.
Have you tried setting the LED ring? That gets handled by the same microcontroller.
1 Like
Thanks for the idea, didn’t know that 
I’ve changed the colour and intensity of the LED ring, without a problem. So the microcontroller seems allright…
In developer.athom.com i get a “network request failed” error when trying to receive/record a 443 or 864 signal. Don’t know if that has anything to do with it…?
1 Like
Sounds like a similar issue to me. I think you’ll have to wait for Athom to respond.
One thing you don’t say doing is pulling the plug from Homey for about 10 minutes. That’s not the same as rebooting.
1 Like
