TP-Link WiFi Switches

I have one of the TP-Links bulbs set up. Hope to play with it tomorrow with the scripts.

Berkinet and Ramias have made MANY changes to support multi-plug devices and devices that report energy usage, but nothing specific for light bulbs. Thanks, guys!

The GitHub master has just been merged with all of those changes, but I haven't yet made this into a "release".

JAY - if you have time please check it out and remind me what I need to do to release it. I am rereading the indigo_7.3_documentation:plugin_guide, so just mistakes I might make that aren't documented.

I have one of the TP-Links bulbs set up. Hope to play with it tomorrow with the scripts.

You too. download the GitHub master and see it it does everything you need. If not ... how's your python
or maybe its already working for you !

[jay (support)]

On Github, just create a release, zip up the plugin and attach it to the release, then in your Indigo Account just edit the plugin and save it - it should automatically pick up the new one.

Looking forward to this as Amazon has the dual-outlet one on sale today and I just picked one up...

[jay (support)]

Well, the upgrade didn't go well. Did a status request on an existing device and got:

Code: Select all

   TP-Link Device Error            Error in plugin execution CalcDeviceFunc:

Traceback (most recent call last):
  File "plugin.py", line 372, in getDeviceStateList
AttributeError: 'NoneType' object has no attribute 'append'

   TP-Link Device Error            Error in plugin execution ServerReplacedElem:

Traceback (most recent call last):
  File "/Library/Application Support/Perceptive Automation/Indigo 7.3/IndigoPluginHost.app/Contents/Resources/PlugIns/plugin_base.py", line 1179, in deviceUpdated
  File "plugin.py", line 146, in deviceStartComm
KeyError: key multiPlug not found in dict

   TP-Link Device Error            Error in plugin execution ExecuteAction:

Traceback (most recent call last):
  File "plugin.py", line 250, in actionControlDimmerRelay
KeyError: key multiPlug not found in dict


Then, did another, and:

Code: Select all

   TP-Link Device Error            Error in plugin execution ExecuteAction:

Traceback (most recent call last):
  File "plugin.py", line 333, in actionControlUniversal
TypeError: not enough arguments for format string


So, something broke my existing smart plug...

I'll revert back until these issues are worked out.

Well, the upgrade didn't go well.... ...So, something broke my existing smart plug...
I'll revert back until these issues are worked out.

Devices from previous versions of this plugin are not compatible with the new version. You will need to delete the old devices and then recreate them.

[jay (support)]

Devices from previous versions of this plugin are not compatible with the new version. You will need to delete the old devices and then recreate them.

What??? That really sucks...

What??? That really sucks...

Or not. There is now only one device type for all TP-Link WiFi plugs. The plugin does a discovery process for all compatible devices on the local network. The Indigo device is then automatically configured, though you can change a few options. Give it a try.

[jay (support)]

What??? That really sucks...

Or not. There is now only one device type for all TP-Link WiFi plugs. The plugin does a discovery process for all compatible devices on the local network. The Indigo device is then automatically configured, though you can change a few options. Give it a try.

That's great for people adding new devices.

It sucks for us that have existing devices that we have to go recreate since deleting devices means I have to go manually change all the places they've been linked. This is not a good user experience...

What??? That really sucks...

Or not. There is now only one device type for all TP-Link WiFi plugs. The plugin does a discovery process for all compatible devices on the local network. The Indigo device is then automatically configured, though you can change a few options. Give it a try.

You do know it's possible to change the devices when the new version of the plugin starts?

...You do know it's possible to change the devices when the new version of the plugin starts?

Yes I do, and I felt that given the significant functional and design differences between the new and old releases and the likely small number of devices anyone might have, it was better to have a fresh start.

It sucks for us that have existing devices that we have to go recreate since deleting devices means I have to go manually change all the places they've been linked. This is not a good user experience...

I had a similar problem with a different plugin I was working on. I found that I could "salvage" the old devices by changing them to a different type with a manual address (like X-10) then change them back to the correct plugin with the new device type.

Yes I do, and I felt that given the significant functional and design differences between the new and old releases and the likely small number of devices anyone might have, it was better to have a fresh start.

Then it would have been better to use a different plugin ID, which is what I ended up doing with the Ecobee plugin. I couldn't make them backward compatible, so the users were going to have to change the devices anyway.

[jay (support)]

I had a similar problem with a different plugin I was working on. I found that I could "salvage" the old devices by changing them to a different type with a manual address (like X-10) then change them back to the correct plugin with the new device type.

Yeah, I'll give that a try. It often won't work for custom devices (since state information that could be used in actions might break), but since these are standard relay and dimmer devices, it might work.

Then it would have been better to use a different plugin ID, which is what I ended up doing with the Ecobee plugin. I couldn't make them backward compatible, so the users were going to have to change the devices anyway.

If there is some holdup to migrating devices (which should always be the first choice if possible), then another option, and one we took with the WeatherSnoop plugin, would be to leave legacy devices in place and add a new device type. This would not "break" anything, but would allow users to use the new device type when adding devices. In the case of WeatherSnoop, WS v2 had a fixed set of states regardless of the type of weather station that it was talking to. But with WS3, each agent presented all the data available for the specific hardware (or service) it was talking to. So it didn't make any sense to attempt to migrate those devices (since the data sets were so different) but we also didn't want to break any existing users.

Yes I do, and I felt that given the significant functional and design differences between the new and old releases and the likely small number of devices anyone might have, it was better to have a fresh start.

I understand the sentiment even if I don't agree. But at the very least, you should catch when an older device attempts to start up, log an error with what to do to deal with the issue, and then disable the device. Still not a great solution, but much better than allowing random stack traces to show up in the Event Log. Better UX with likely a minimum amount of work.

...Then it would have been better to use a different plugin ID, which is what I ended up doing with the Ecobee plugin. I couldn't make them backward compatible, so the users were going to have to change the devices anyway.

And then you’d be right where you are today, having to recreate all your devices.

Quite simply, if you don’t like the new version, don’t use it. Enough said,

Due to the Alexa Hue being neutered (thanks Amazon!!) I decided to buy an HS110 and it works well but when I Send Status Request or Update I get the following error

Code: Select all

 TP-Link Device Error            Error in plugin execution ExecuteAction:

Traceback (most recent call last):
  File "plugin.py", line 333, in actionControlUniversal
TypeError: not enough arguments for format string