I would like to direct your attention to this post....
I asked point blank if he wanted my honest input. That is what I provided. I didn't put this up without first being asked to give it. I merely offered my recommendation on what I thought was the best solution to the OP's problem. Nowhere did I mention @markus's code until he asked me to provide that feedback. If you don't want me to say what I think, don't ask me what I think. Fair enough?
BAHAHA i had no idea this site existed that's gold! Thanks mate!
EDIT: what I should have said is "pull your head in you flaming galah!"
We’ll have to work hard on your predictions not coming true then 
Only if you flag them. 
I was asked for my opinion. If you don't like that, blame @markus, not me.
No worries, blame me this time 
I did ask in the hope something constructive comes out of this, if it doesn’t I guess I was wrong
@Ryan780 can you help us out with the Wiki? @markus and I would love to make this as simple as possible for other's. We would really appreciate the support.
I don't understand why you would ask me that. You just said that you didn't want to hear me complaining . You asking me that is like asking Hannibal Lecter to cater your party and then being annoyed by what's on the menu. I wouldn't do anything other than fight with Markus about his approach to one device (and by this i mean model of device) = one driver. That isn't the right way to do this, in my opinion. I wasn't as forceful at first but after Mike Maxwell made the exact same comment later on, I decided that maybe I was right after all.
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. 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. It does not really gain you anything. It also means that you are going to have to end up having one driver for every variation of template that the Tasmota devices have.
Look at it this way...Tasmota didn't wan to have the user create a different firmware for every device, right? So, they create a means to configure the firmware for the capabilities of the device. That same model should be used in Hubitat. Don't make the user pick the driver for the device. Let the driver be build in such a way as to work with any device and let the configuration be dynamic depending on the device in question.
@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.
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.
Jesus I was not expecting an essay, alright I will let @markus sift through that noise then and decide what is useful. Hannibal Lecter out..
In this metaphor, I was Hannibal Lecter. Obviously you didn't read very far in.
Again, you asked me....I don't get it people. If you don't want me to talk, stop asking me direct questions.
As I said I'm out, got to spend some time with the wifey now before the working week starts. Enjoy! 
If you're not even going to bother reading my response then there's no point in me replying further. Best of luck. Topic Muted.
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?
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.
First, don't take this out of context:
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.
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.
Wow, never thought this thread I started can turn out to have some very intense discussion. I have to say though, @markus has probably been the most helpful responsive DEV guy I have ever experienced in community / forum. He answered all my questions and help a noob like me to finally got my Sh*T out of the cloud. Lol. Hats off to you @markus, and keep up the good work. I'll try to look into further into these as I definitely am interested in skilling up so that one day hopefully I can be useful and give something back to the community.
@markus - Hi Markus, A quick question hopefully on the driver for the plugs. As Power Meter drive is what's recommended. I've been trying to set a notification by monitoring the power meter / power factor. what I've been trying to do is to use this on dishwasher, so that it will send notification when the machine has finished (general power factor = 0)
Even though the rule seems to work ok during test, it doesn't seems to be working properly in reality. I don't find the polling happens regularly.
I've read some articles on node-red (within home assistant environment), where you can set how often you want it to check / check interval. Can this be achieved with RM4?
If anyone else has experience / suggestion on this, please do share them.
Thanks
The driver gets power reading once every 5 minutes (not polling, this is pushed from Tasmota), this can be made more frequent by setting teleperiod to a number less than 300. It is also possible to write a rule in Tasmota that sends the power reading as soon as it goes below a certain level (this is a bit more advanced though). As for monitoring power readings to determine the state of a dishwasher, this can sometimes be complicated in RM (although very much doable). There's also a couple of different apps I've seen in the forum which should accomplish this, though I've not tested any of them.
Thanks Markus,
Yes I've set it from 300 (default) to 10 on the device, and as for rule, I've set a trigger events to send notification when PowerFactor = 0.04. (that seems to be the number when the machine is on idle).
Testing the rule work when I click on (Run Actions), but it doesn't seems to be checking powerfactor during the washing and after washing is done. (hence no notification)
Clicking on refresh button within the device seems to "wake" it up (which then sends the notification) for certain amount or time, then it kinda gone back to sleep.
Can you please advise the names of those apps you've seen for this purpose?
That you don't get events fired doesn't sound right, I'll see if there's something up with the driver together with RM, but there shouldn't be... Events fire as they should for me...
10 is VERY frequent, that is a call to Hubitat once every 10 seconds from Tasmota... Not sure how good that is for HE... But if you don't have any issues with your hub and don't have loads of devices, I have 40+ wifi devices and 60+ zigbee devices so I'm not sure I would get away with a teleperiod like that one...
As for the names, there's a lot of them, but search for laundry in Code Share, I really can't recommend one since I've never used one.
LOL, yeah. I set this up deliberately with 10 because I'm still testing it just on one device. I want to see it works before putting it back to a realistic interval.
I'll take a look at that
Thanks!
Hi @markus, I gave laundry code a go and it seems to be screwing my plug around.
I've tuya converted an Aoycocr smart plug and it's now running tasmota 8.1.0.
it's all hunky-dory until I added this plug as child device under laundry code.
It for some reason inverted the LED. So when it's off, the relay is on and vice versa.
then after a while, it stopped working and found my plug template converted from what I've manually set for U3S UK model to Sonoff POW R2. I had to reset it to get it back to how it was.
I'll persevere with RM4.0 notification for now.
Anyone else got other suggestions I can try? cheers
Which driver are you using, the Generic one? If so, this could only happen if you don't run the latest version, there was a bug where this could happen if the driver was reset to defaults. If the app requires you to install the device as a child device (which would require you to remove it and install it again but with that app) and not just select it as an already installed device, it will not be a great choice for use with any of my drivers.
As for the issue with changing the settings of the plug to incorrect ones, this can not be blamed on anything than my driver. Please update to the latest version.
Download the Hubitat app
