Smartlife Tuya Aoycocr

[markus]

@Ryan780

The best way to handle Tasmota devices, from a usability perspective, is to have have the user create the parent device and then have that device create children as it receives information from the physical device. If it receives a switch 1 status, it creates switch 1. If it receives energy meter 1 info, it creates energy meter 1. If it receives switch 2 status, it creates switch 2. And so on. This would mean you would only have to create and maintain 1 parent driver and then 1 each of the child drivers for the number of capabilities that the devices support. So, one each for switch, power meter, dimmer, rgbw, etc. That takes the responsibility out of the hands of the user to figure out what drivers to use.

This is a very nice approach, I have considered it, and also here, and it is also the approach recommended here. See, constructive. My only concern is if all the logic that is needed for this is running constantly, that it would become too much to still have a nice and fast system. But I'd say it is probably worth a try.

I would probably like to have the child devices as a couple of different drivers since they need to present different capabilities, for example for things like Alexa where you might want either Switch + Outlet or Switch + Light, but not Switch + Outlet + Light.

There's also the RF and IR drivers, those I will keep separate since they will already create a bunch of different child devices depending on how they are used, or maybe I can come up with a way to combine that as well... Hmm...

I'm sure that on the way, there will be scenarios where this will not be possible to adhere to 100%, but it is a nice approach.
What I would like vetted from people who have developed large drivers on this platform before, is how well they behave performance-wise?

@Ryan780

It does make the user configure their Tasmota device, but since the templates site pretty much gives that information directly to you for every device it supports anyway, that's not really an unreasonable expectation. The requirement that the Hubitat driver setup and configure the Tasmota device is unnecessary in my opinion and creates way too much complexity.

This could be handled by an App for those that want it, or, for those like me, who have a lot of the same devices which require a lot of configuring (not just a module or driver), here I'm talking about TuyaMCU-based devices, for example.
For those that prefer doing the configuration in Tasmota, that would also be doable. It could be possible to even skip the requirement of an app, just configure Tasmota, add the main driver as a virtual device, set the IP (and possibly password) of the device in the virtual device device config and wait. If you need a specific type of child device (like one compatible with Alexa), just change the driver once the child device has been created.

@Ryan780

@markus thinks that the only way to do this is dynamic commands and capabilities. When told those weren't a thing his reply was

I want them to work that way

That, to me, is not learning to develop for the platform. That's like showing up at a basketball court where everyone is already playing and saying "New rule, you don't have to dribble" and just expecting everyone to capitulate. He had no interest in hearing what people who have had the system for a lot longer or people who work for hubitat had to say about it.

First, don't take this out of context:

The behavior of a method generating Commands

Look, I don't understand your attitude, not at all. I'm looking for constructive feedback. Such as WHY this would not be a good thing, or WHY it would be a good one. Or anything else that is constructive. I do want this feature, but, will I send a direct e-mail and ask for this to be added in the future, very unlikely. I bring it up here, because it is something I want and it interests me to see if there is a community response and others that also see a need. Will I get this feature? Probably …

And don't forget the following:

While we don't have any immediate plans to implement this, we understand the need and benefit of this.
from here.

Second, don't assume to know what I think, that was a specific topic about a specific type of flexibility I would like to see. As it is, this flexibility doesn't exist and is highly unlikely to EVER exist. And me not listening, that must be some projection of your own thoughts.

@Ryan780

In it's current formation, these drivers are not sustainable. You already have over 50 of them. Are you going to make one for every device listed on the tasmota templates page? That's a lot of wasted effort, IMHO.

In terms of development effort, not at all, very easily maintained with a common code base and auto-generation logic. Combine that with a spider and it is 100% automatic... In terms of usability for the user, definitely not ideal.

To conclude, you do have valid points, but please don't take quotes of me, or anyone, out of context. The changes you talk about, or at least something similar in effort, are needed to get to a mature project, I agree in that. Do keep in mind, this is so far just a 7-8 week effort using my spare time, all the while learning the system and having an actual life. The changes discussed here are substantial, but not unfeasible. With good collaboration with people in this forum this can be made to be very nice.