@hilbrand: Ahhhh, better. I’ll try that when I add the next one. Thanks!
@hilbrand I just tried it using discovery, but it didn’t work. Not surprising, since it is on a separate VLAN from the OH server. Not really an issue to add it manually, though. Thanks!
Just curious what you all use for refresh rate in the paper UI ?, does 1 sec mean it is updating the device every second as this seems excessive ?
My Kasas are set to one second, only because I never thought to monkey with the default value. There’s no discernable impact on my WiFi network, and I have about 10-15 of them in play. I assume Hilbrand had a reason for making that the default.
Only the switches are on 1 second, to get fast feedback if someone uses the switch.
2 Likes
You can easily configure your TP-LINK Kasa wifi connection using the NODE-based tplink-smarthome-api (GitHub - plasticrake/tplink-smarthome-api: TP-Link Smarthome WiFi API) cli and a computer with wifi. This is tested with EU HS100 and HS110 and E27 LB110 and LB120. To configure the devices, proceed as follows:
- Short reset the device so it sets into connection mode (3 power on cycles for the bulbs and pressing the cog button till wifi LED turns to orange). Then, the device will create a open wifi AP named “TP-LINK_Smart Plug/Bulb_[MAC_5_6]”.
- Connect the computer wifi to that AP. If using Windows 10, it will think twice before connecting to that wifi.
- Using the terminal issue the following command, replacing SSID and password second fields with the correct values. The IP must be 192.168.0.1 and I had to escape all the quotation marks to make it work:
tplink-smarthome-api send -u -D 192.168.0.1 "{\"netif\":{\"set_stainfo\": {\"ssid\":\"SSID\",\"password\":\"password\",\"key_type\":3}}}}" - The device will start connecting to the new network and if it is successful, the wifi LED will turn into green (for plugs) or fade out and in (for bulbs).
This works like a charm and saves me plenty of time when any of the bulbs reset due to too fast power on and off cycles.
1 Like
That technique has apparently been blocked. It results in an error: ‘netif’ not supported module.
Which device are you using? Maybe a HS100/110 UK plug HW 4.1? If so, the rear port was disabled due to a FW update (1.1.1). I have just tried a HS100 EU HW 3.1 and worked fine, but it was blocked from internet long time ago and never updated. More info at https://github.com/plasticrake/homebridge-tplink-smarthome/issues/154
Tip, I only blocked TCP connections from my devices but not UDP, so DNS and NTP keep working to be able to use the builtin scheduler.
You are correct: I should have been more specific. This was a just-purchased KL135. The app says the bulb firmware version is 1.0.6.
The original technique of using the app to get it connected worked, mostly. The “device Id” tip is priceless. I tried everything from the isolated network, but the Kasa app refused to function. I did the following:
- Hook phone up to nominal 5GHz WiFi network with internet connection (where the bulb cannot connect).
- Fire up the app - letting it snoop on whatever it wants (e.g. location information).
- Put the bulb in find-me mode (on/off three times).
- The app found it and asked me to connect my phone to the right WiFi network.
- Switch phone to the isolated 2GHz network.
- It hooked up.
- The app, amazingly, has the MAC address under Device Info.
- Cross-referenced that with the DHCP leases (openHAB Pi machine is also the WAP and DHCP server).
- Manually added the Thing using the “use any id” technique, above.
- The error message does contain the correct Id.
- Entered that and all was happy.
One more thing: The Pi does not let anything cross from WiFi to wired (no iptables rules at all). I’m just starting this adventure and I haven’t needed it, yet. However, I ran that command from a Windows 10 machine. The response was from the bulb, not the script itself, so UDP was flowing.
This device is not compatible with this API. I don’t know if there is any support for TP-Link newest devices neither a way to communicate with them without using their cloud.
I’m not surprised - the joys of proprietary protocols. Thanks for checking/confirming.
Note that the openHAB TP-Link binding works with it just fine - once you managed to get the Thing created.
The TP-Link binding communicates directly with Kasas, so you just have to use the Kasa app to add them to your network. If your router allows you to modify settings, you can then deny them Internet access and they’ll work just fine on your local network.
I’m looking in buying multiple kasa kp200 smart outlet and probably some kasa smart aeitch and dimmer. Looking at the price, it’s far cheaper then wemo.
By reading everything in here, I should be able to configure all of them and use them without having them connected to the internet? Because that’s my goal, something i wasn’t able to do with wemo.
Are reliable are they vs wemo?
You have to set them up with the Kasa app, and after that you can deny them Internet access. There’s a method to set up without, but I don’t personally think it’s worth the effort.
I should note that this is the same for the Wemo binding. The can also be controlled locally by OH.
I can’t speak about reliability relative to current Wemos, but Kasas are almost always less expensive. I have about 20 of various types, and don’t have any issues.
Great. The price is a big point why too. Less then 20$ each vs 60+ for a wemo is a no brainer if it work great.
As for my wemo, I have them phoning home because when OH decide it doesn’t work, I use the wemo app.
Check this out.
tp-link total went big brother and removed the local-only setup in their app.
After using the python-kasa utility I delete the kasa app and have not looked back.
Be sure to block your kasa devices, using your router/firewall, from accessing the internet or tp-link might update YOUR devices firmware without your knowledge and lock you out of them.
2 thumbs up to the person that created python-kasa.
Considering tp-link has gone completely big brother with their latest app update python-kasa is the best option for configuring kasa devices for local-only operation.
What does this mean? I don’t recall there ever being a “local-only” setup for Kasa devices, and I’ve had them pretty much since they launched. It’s always been a case of setting them up with a Kasa account, then denying them Internet access and connecting to them locally with openHAB’s Kasa binding.
Previously the Kasa app allowed a person to SKIP setting up a Kasa cloud account and provided a method to setup devices for local-only use.
TP-Link in a recent release removed that ability forcing people to sign up for a Kasa cloud account.
python-kasa has stayed the execution that tp-link has sentenced it’s paying customers to.
Interesting. Can’t say I ever noticed. I’d still rather just use the Kasa binding, but to each their own.
That’s a little dramatic. The vast majority of their customers benefit from the free cloud services that they provide, and no one’s forcing us to buy or use TP-Link devices. There are lots of other choices out there for people who don’t want to use cloud services.
I get why it feels constricting to people who are capable of setting up openHAB or using Python, but we’re a tiny niche audience with more technical expertise than your average consumer. If a small fraction of your audience is using a feature, it’s reasonable to cut the feature to avoid wasting valuable time on it (and in the case of software, avoid it becoming a security issue in the future). We’ve all been faced with this kind of decision in our professional lives.