Now I'm getting beeps when changing speeds. So does rule 1 1 have to be run before it enables the rule?
Also I'm using 71 and my remote is working. So we probably don't need to 44
Nice! "Rule1 1" should have been run by the driver, so something is still not right...
I'll comment out 44 and if it is ever needed it's easy to add
Sounds good on the 44.
Let me know when your ready to test it again and I'll try it on my other one.
New changes pushed to the repo, it should work as expected with the Buzzer now. Do you get buzzer sounds with the remote as well?
That did it! I'll test the iFan02 shortly but I am sure it will work
1 Like
Nice, then this is functional, you're the first one to even try this type of driver from me. Any and all feedback is appreciated, once the App is fully functional as well, I intend for this driver to replace all my other Tasmota drivers.
iFan02 tested and working.
It is very solid. I like the interface and I love the universal driver idea. I had the same idea earlier in the MQTT alpha. When you can separate code like this it makes things much easier to maintain and for end users to use. For Tasmota this makes it a viable stable add on for Hubitat.
Thank you for doing all this and your very appreciated by me and soon to be many more in the community. I will be trying light bulbs next.
I will be adding a few additions to your drivers for my water leak sensors and a basic pest control device that I have modified by adding a wemos D1 and a relay. I just modified you generic switch driver with WaterSensor and MotionSensor and added some code to match what I needed done.
I do strive for it to be solid, I've looked for all the best coding practices with Groovy and the platform and try to follow that as far as it makes sense. What's missing are unit tests with execution speed tests...
This is why I can even do this, I would go nuts trying to write this otherwise... It's annoying enough to not have classes...
That is what I want, for switches, dimmers and ligths I want to stick to wifi in my home since that way I can run my own code, this driver makes it easy and stable...
The Universal Multisensor child-driver should be usable to you then. I don't mind adding what is needed to get them running if some extra parsing is needed in the Universal Parent. If you create a device config in the style of my driver and send me the output of "status 0" that would take just a few minutes to add. I'm still thinking about how I could best keep the dropdown from being WAY too long... But for now this works. I could do it with Javascript, but not sure that is such a great idea. I already inject CSS to hide state, data and commands (The delete all children button).
EDIT: What I mean is, if you can keep any extra logic in a child driver, you only need to modify that one with what you need, instead of the giant Universal Parent. So any changes needed in the parent I could add so that your child driver receives/sends the data it needs.
@markus if you want/need anyone to help test your new drivers I am game. I have a large number of Tasmota flashed lightbulbs i can test on, along with a couple outlets. 
1 Like
I'll PM you 
@NeighborGeek, I have a few of those bulbs that I've only been controlling via the Feit app and Google Assistant. I'm interested in following what you did to get them connected to Hubitat. I've installed the driver from @damon.dinsmore and flashed the bulb using Tuya-connect with the built-in tasmota firmware and connected it to my WiFi.
What I can't figure out is how to connect it to Hubitat.
What am I missing?
Install a virtual device, and select the driver. Then fill out any needed settings on the device page.
Is there a written up "how-to" anywhere that walks you through how to do this? I have a light strip I want to use (as well as some other plugs that were using Smart Life that I believe can do this as well) but like to have something to look at to know what I'm doing.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
