Riley_S wrote

  @Vapian,

So the problem that I see here is that the Smart Bulbs always require their load to be at 100% as the device needs to stay connected to the internet and still be an active device on  your network. This is why we don't recommend placing smart bulbs on a dimmer switch, as the dimming functionality would break the functionality of the bulb.  

I understand this, which I why I currently have the lights wired directly to power, bypassing the switch. The switch is paralleled to the same power line, but can't do anything to it. Right now it pretty much must be wired this way to avoid the problem you describe. In my idea with the "Kasa Only" setting, power could always pass through the switch to the lights without being affected - the Power and Dimming buttons would only send commands, not perform any physical actions.

To perhaps clarify the overall intent here, it seems very possible - and exceptionally useful - that any Kasa switch should be able to act as not just as a Smart Switch / Dimmer / Motion Sensor for standard lights with just a few features for your KL bulbs, but also as a full-fledged Smart Control for your Smart Lights and Groups, without necessarily exerting any On / Off / Dimming control on the power load.

That is what I thought the marketing material implies is possible ("Kasa Smart Switch is now an integrated Smart Controller"), but really isn't.

I think true, comprehensive Smart Control of other Kasa products from your Switches would be a very compelling selling point.

 

  @Riley_S 

As I've continued to live with a group of eight KL135 lights and two ES20M wall switches, it's become clear that these devices need some way to communicate at least group state to each other (not to mention group capabilities, which is fairly well covered in previous posts).

As a user with those devices and the KASA app configured so that motion at either ES20M triggers a Smart Actions to change the state of all eight KL135 and the other ES20M to "On", and another Smart Action so that if either ES20M changes state to "Off" all of the KL135 bulbs change state to "Off", I expect that those functions will work - that effectively, any change in the On or Off state of either ES20M will result in the same change in On or Off state of all of the bulbs - so that the lights in that space are always in the same state.

As it is now, any time the On or Off state of either of my ES20M changes, chances are no better than a coin flip as to whether all of my KL135 bulbs will change state to match. In this space, where the bulbs are roughly in four rows of two bulbs each, what happens is that some bulbs are either On when they should be Off, or vice versa, about half the time that any trigger event (motion sensed, or motion timed out, at the ES20M switches) occurs.

At the very least I would expect that state change from any device in a group would be broadcast to all devices in the group, and all other devices would follow.

For reference, when controlling the group from the Kasa app or from an Alexa or Google Home group, the lights respond to On, Off, and other commands relatively quickly and in sync. It's the group response to Smart Actions in particular that routinely fails to perform the expected actions.

I realize this is not necessarily an easy protocol to implement. Methods would have to be developed (or borrowed) to elect a group leader, transfer leadership if a leader becomes unreachable, define a hierarchy for device leaders (e.g., switches before bulbs, if present in group), paying attention to time stamps of state broadcasts, etc. - but it can definitely be done. Google for the WLED Project UDP Sync for reference.

This would greatly improve the end-user experience by maintaining grouped light state sync (for On, Off, Color, Color Temp, Brightness, etc.).

  @Riley_S 

How is your smart action set up? It may be worth trying to separate the devices from the group when sending the commands. If they are already separated, try to control all the devices with a group command.

 

I've tried it a number of different ways:

- With one Smart Action using the On/Off state of either one switch, or both switches (which the app implies is an "OR" action) in the "When" section,

- With the "Then" action triggering a Scene that itself controls individual bulbs,
- With the "Then" action triggering individual bulbs directly (via Turn On, Turn Off, and Set Lighting, which also has limitations with respect to precisely selecting color temps or colors),
- With the "Then" action triggering the Group power state (that being the only commands available for a Group within a Smart Action).

This has been tried in various combinations with the bulbs in a group, and not in a group. I've even tried having each switch's state change the state of the other switch, with different subsets of four bulbs tied to the state of each of the two switches, in an attempt to minimize the number of devices each switch might be sending commands to. I think I've exhausted most if not all of the options available in the app.

Speaking of which, control from the app (e.g., selecting the Group and controlling directly from the app) seems to work much more reliably than the Smart Actions executed while the app is closed. I'm assuming that's happening on the devices rather than from a cloud server, but haven't yet explored where these Smart Actions are actually stored or executed.

From my work testing other IoT devices, this random lack of sync seems very much like issues I've seen in which UDP packets are just not getting to their destination. And with no communications betweeen bulbs and switches, there's no way for them to know anything was missed. I kind of want to write a test script with python-Kasa to run through all of the possible features, maybe even fold pytest into that, but not sure my skill set is up to fleshing out new test framework from scratch just yet.

Also, are your devices configured in such a way that they are disconnected from power often or are changing IP addresses. I am curious if the light status does not change because the device was 'unreachable' due to the device reconnecting to the cloud. Two things that may be worth your time: Setting Static IP addresses for Problem Lights, or Moving your Lights to a guest network and seeing if the behavior persists.

It probably got lost in the several things I've posted (sorry/not sorry!), but unless we lose power to the house or cycle the breaker at the panel, these KL135's and ES20M's never lose input power. The bulbs are wired directly to power, with no dimmer or switch between them and the line. The ES20M's are wired in a similar fashion, in parallel with the lights for input power, and with no load connected to them. I did it this way because I'm not directly controlling any standard dimmable bulbs, and the marketing copy out there implied that they are capable of "smart control" of other Kasa devices (which might be overstated just a bit?).

While I hadn't mentioned this before, I have tried all this both with and without DHCP address reservations (since the Kasa app does not directly support configuring a static address for your products), and on two different networks: Google Nest WiFi (three routers, one acting as router and two as nodes/points), and Asus ZenWiFi XT8 (two routers, one as router and one as node).

The Nest WiFi system is probably the most reliable consumer mesh network I've tested, with eero Pro being a close second, but even those two struggle to keep up sometimes with the 140+ devices in my house. And the Guest networks on both of those systems are IP isolated and don't allow devices to talk to other devices, so that would fail right out of the gate unless everything is controlled remotely via cloud server, which is really isn't an acceptable solution. The Asus XT8's were... not great, at least not when lots of UDP and mDNS traffic came into play. 

I suspect that on a separate, non-Guest network with only a few devices (say, less than 16 or 24), the Kasa products would very likely perform more reliably. But that adds additional network hardware, complexity to working with and managing the network(s), and probably isn't a solution you'd want Customer Service recommending to most customers (trust me, I've been there!).

I'm currently searching for a replacement WiFi system that handles UDP and mDNS well, but even with great refund policies some places, buying and returning product gets old, fast.

The one issue that I have always found with syncing devices together, is that different models/brands seem to calculate colors differently. However, I see nothing wrong with using the other attributes for synced states and will pass the recommendation on.

I've run into similar issues with the products I test, both for a living and in my home. With respect to Kasa lights, I think there a couple of possible approaches to that:

- When like devices with matching capabilities are grouped, all properties of devices in the Group can be controlled within their full range of values (brightness, color, etc.).
- When dissimilar devices are grouped, those devices become limited to the least-capable devices in the group; or

- When dissimilar devices are grouped, those devices sync within the min/max ranges they share. When min/max values are set beyond the least-capable devices, the least-capable devices go to their limits, but more-capable devices are allowed to go to their own, broader limits.

Personally I'd probably be fine with app features that limit configurations in reasonable ways, per the first and second examples above.

For example, I'd expect a Group of just KL135 bulbs (and ES20M switches) to be able control every capability those bulbs have.

While I personally would never do this, if I were to create a single group of both KL110's and KL135s, I'd probably expect Group control to be limited to On/Off and Brightness.

Were I to mix KL125, KL130, and KL135 (unlikely for me, but still), I'd probably expect full control, but would have no expectation that brightness, color temp, or colors would always match.

In either of the last two scenarios, I'd expect the app to provide a prompt/notice when first adding dissimilar devices to the Group, so I don't get too far in creating the group before being informed it may not act the way I might expect. Something like, "Selected bulb(s) have different features than bulbs already in the Group. They can be added, but Group control may be limited, or different bulbs may not appear the same at all settings." Give that prompt buttons for Cancel / OK / Don't Show this Again, and at least I've been warned.

Different customers will expect different things, but in my experience, communication of whatever is implemented and allowed is absolutely key. UI/UX will have to get involved, define some stories and common use cases, do some testing outside the development and testing teams to see what "normal" people want, expect, need to see or be told to figure out what the capabilities and limitations are, and what they say they will settle for. Regardless, I'm sure the Product Owners and Managers will push for what can be done fastest and cheapest. :) But those decisions do have consequences.

  @Riley_S 

Another thought, also based somewhat on experience:

Assuming that you do implement some sort of grouped-device communications, I would recommend part of the functional requirements include:

- At least internally, consider creating a measurable performance requirement, e.g., "All lights in a Group must respond and conform to a change in state within 0.5 seconds at least 80% of the time, regardless of the source of state change (mobile app, voice command, switch operation, etc.)".

- Specifying, and publishing / letting users know, the number of devices officially supported within a group. It's possible the implementation may work well for, say, sixteen devices (including bulbs, switches, outlets, etc.) but group communications might begin to degrade beyond that. If so, users should know that, or the app should prevent them from adding more than you know can be supported. Sixteen devices minimum is probably a reasonable and achievable goal. Whatever is decided upon, must be tested to scale.

- Consider whether you intend to support structures (homes), floors, zones, rooms, and/or groups. It's all do-able, I believe. Starting smaller is easier, but can make it difficult to expand the framework if you later decide to broaden the scope if that wasn't taken into consideration early on.

- Definitely test on as many readily available makes and models of consumer / residential grade WiFi network / mesh systems as possible, including TP-Link, and including multiple wireless backhaul nodes/points for mesh systems. The ability of those systems to get UDP packets through the router, and every individual node, and back again, will make or break any implementation.

- Further expansion to the above: Test on those network system makes / models in real-world, home environments, with as many other devices including printers, streaming media players, smart TVs, networked speakers, Homekit products, etc. as can be reasonably achieved. It's shocking the effects that one badly-behaving third-party product can have on what seems like a bulletproof implementation.

Please forgive me If things like this seem obvious, but in my experience they are clearly overlooked by a lot of manufacturers in a lot of products.