search

robertklep / homebridge-klikaanklikuit

Homebridge plugin for KlikAanKlikUit outlets
15 stars 7 forks source link

KAKU works with old driver, not with homebridge-klikaanklikuit #21

Open x5nder opened 6 years ago

x5nder commented 6 years ago

Hey Robert,

I have installed a 433Mhz transmitter on Raspberry Pi physical GPIO pins 4 (VCC), 6 (GND) and 8 (ATAD) and compiled the original kaku app found on the Tweakers forum. With data transmission on pin 8 (= GPIO 14 / wiringPi 15) the original app works perfectly and I was able to assign two different codes to my lamps (112233 1 and 123450 0). Turning the devices on and off from the command prompt works like a charm.

Now I've installed homebridge-klikaanklikuit and I can't get the plugin to work. In config.json I set "pin": 8, but no response from the lights, so I installed kaku-rpi and tried different commands like kaku 8 123450 0 1 and even checking every single possible number for the pin. No dice.

I then checked your guide and saw that you use physical pin 11 (GPIO 17 / wiringPi 0) so I moved the ATAD connector to pin 11, rebooted, recompiled the original app with 'pin = 0' and sure enough, that one still works [sudo ./kaku 123450 0 on]. The new kaku-rpi again, no dice [kaku 11 123450 0 1 from the node_modules/kaku-rpi/bin directory]...

Any idea what's wrong here? Xander

robertklep commented 6 years ago

I don't know what the "original kaku app found on the Tweakers forum" is, but I suspect that there might be a mismatch between how that app sends codes, and how my plugin sends codes (433Mhz RF codes are a bit tricky).

Since you have already installed kaku-rpi, it's probably easier to have the devices learn a code that gets transmitted from that tool (put the device in learning mode and send the ON code using kaku-rpi). Most Kaku devices are able to learn up to 8 codes, so if you have other transmitters that do use the original code, the devices will still respond to that.

x5nder commented 6 years ago

Hey, that seems to work... partly! :-) One device was easily assigned when put in discovery mode (./kaku 11 3864 0 1) but the other one, an outlet plug, refuses to be assigned. It's the one that starts the assignment process by unplugging and plugging in. No matter what I throw at it (./kaku 11 3865 1 1 or ./kaku 11 1927 1 1 or ./kaku 11 3759 0 1), there's no click, the light just stops blinking and turns solid -- the other app can still control it, so I know it's within reach of my transmitter and working. Do I miss something or is there an actual reasoning behind the codes I should send? I'm now picking codes and devices numbers completely at random.

robertklep commented 6 years ago

There's not real reasoning behind the codes :) I believe there's a maximum (32768, I'm guessing), but that's about it.

Are you sure that the outlet plug is actually a Klik Aan Klik Uit plug? If so, what model type is it? I don't have a considerable arsenal of KaKu devices, but mine either use the old-fashioned method (with a code wheel) or have a small button that you have to press to put the device in learning mode.

x5nder commented 6 years ago

It's the KlikAanKlikUit APA3-1500R / PER-1500.

I've tried pilight as well, same results as with kaku-rpi; the first device responds, but this plug won't register. Really weird. I've also tried hooking up a receiver to the Pi (GPIO 18 / wiringPi 1) but then pilight-receive receives a ton of codes, I'd say one or two per second, from completely random devices but no KlikAanKlikUit codes when I press the remote... lol.

robertklep commented 6 years ago

Depending on the receiver, you may be receiving random data. There's different encodings that are used, different timings, etc. I had a self-learning receiver that was able to learn cheap 433 remote control codes, but it was never able to learn KaKu codes.

As for the outlet device: not sure what's going on. Try using a code lower than 16, perhaps it has a limited range.