@cjcharles, I think that child devices make sense on the devices with a larger switch count (3,4 - 8) but to be honest I don't want to maintain two paradigm's. If you wanted to publish your child version for the 4 and 8 port version I'd be happy to put a link on my GitHub and make references to the child version in the Hubitat forums, I could also include a link in my code.
I don't have any plans to make any significant changes to my Tasmota drivers so I don't see the capabilities getting splintered between our two versions. Current version meets most needs and I've moved onto another project.
I'm glad you got rid of all the child devices. Its one of the things that bugged me about Marcus' driver. I like yours so much better.
I don't see much need for any significant changes but I sure hope you'll continue to monitor and maintain if needed for any new Tasmota versions that might require an update to the driver. I'm volunteer a driver writer too (but I know very little about tasmota protocol) so I understand there is no obligation. Just hope you're not completely "moving on"
Yes child devices is annoying for single switch outputs without a doubt, but I thought it was quite useful for linking with Google Home without needing rules to synchronise a virtual switch with the 'parent'. Happy to push them for 3/4/8 output devices, but I guess some people may want them for a 2 output device? Either way its totally optional whether you create them or not (it doesnt affect current functionality).
Sounds good, I like the optional aspect and will probably use that myself for the 3/4/8 devices. Unfortunately I'm leaving and heading south tomorrow until March with only my iPad and phone and don't have the time to spend on this at the moment. I'm currently on a packing and prep marathon as we leave at 7:00AM tomorrow. Sorry, I know that is bad timing but I do appreciate your contribution and will publish on my return once I've had the opportunity to try it out in my home environment.
I just proposed two small PRs to the outlet plugs to replicate the energyToday value over to the standardized "energy" attribute. The change will allow the plugs to be used with my app:
@garyjmilne , just wanted to drop in and say thanks. I flashed two Sonoff S31s with Tasmota yesterday, and used your drivers to integrate into Hubitat. Worked fantastic!
Next challenge: I have a SonOff iFan04 on the way. Hoping that flashing it will finally give me the solution for my fans I've been wanting.
I have about 6 fans w/ lights. They are the style that only has a single set of wires going to them, and the fan and light are controlled by an old-style RF remote. Not any of the new fancy computerized DC motors and smart remotes or anything.
I've made the fan on one of them work with Hubitat using an RF repeater, but it's no good for the light, since it doesn't provide feedback. And it didn't work well enough for me to roll out an RF repeater in every room.
Fingers crossed for the Tasmota solution!
Edit: I've seen that in the 4 years since I installed all those fans, various fan makers have cycled through different "smart" solutions. I saw there was a KoF zigbee solution for a bit, though people said it had a poor radio. Lately it seems like they're all either packaging a Bond hub with their fan, or forcing you to use some crappy proprietary internet-required app without an open api. Forget that. Not in my home! We go local or nothing.
I use one at home and it works well. Before you put it up in the housing there is a little LED you might want to cover up or disable as it’s quite noticeable at night.
I use one of these as my remote to cycle through the fan speeds or turn the light on or off. In fact we have two so we each have a convenient control.
I also use 3 zigbee bulbs in the fan and use the above mentioned remote to go through some preset brightness levels for daytime or nighttime use. The Advanced Button Controller software is what enables this.
@garyjmilne , what would you say are your favorite Tasmota-capable devices? Up until now I've stuck to z-wave and zigbee, but now that I've tried one Tasmota, I want to try more!
The Sonoff S31 WiFi. They are about $10 each on Amazon, easy to flash and they let you access all kinds of power data which gives you options.
I use them on my washer dryer and get announcements when they stop.
I use them on my cameras so I can power cycle them.
I also have them on my gutter heaters (to melt snow and ice) and I can verify they are working based on the power stats.
I’d have one on my dishwasher but I can’t get back there.
Even if you don’t need the power data they are still a good plug.
There are a few vendors that sell pre flashed devices. It used to be possible to flash Tuya devices without opening them but that door is closed so for devices like bulbs pre flashed is the way to go.
I also like the Sonoff TH10\TH16 which is a power switch with built in temp and humidity controls. Temp and humidity and never needs batteries changed.
There are a bunch of them but all depends on your household situation.
I found that if a fan change happened on the device (such as from the Sonoff remote), it would sync back an updated fanSpeed attribute, but not the speed attribute. This caused problems with how the fan showed in HomeKit.
@garyjmilne One other edit I made. (But I have not sent a PR, since I don't know that it's the best solution.)
I have my Hubitat hooked up to HomeKit via HomeBridge. I'm using the Hubitat MakerAPI plugin for HomeBridge. What I found from testing was that, if I adjusted the fan speed on my phone, it was sending two commands to your driver: Yes, it would send the new speed command. But first it would send a cycleSpeed command. This caused all sorts of problems, and there were timeout errors in the logs, and nothing updated correctly.
Now, I don't think this is a bug in your driver. I think it's more likely to be a bug in the Hubitat MakerAPI plugin. But I worked around it in your driver by putting a return statement at the top of the cycleSpeed method. I don't need that method anyway. Once I did that, the integration with HomeKit worked wonderfully.
One other thing I noticed: I saw in your first post that you decided against using parent-child devices, for some good reasons. The iFan04 is a weird case because it really is 2 separate devices. A lightswitch and a fan controller, that operate pretty independently. HomeKit isn't seeing it as 2 devices, so HomeKit just focuses in on the fan part. I think my solution will be to add a virtual switch that gets bound to the state of the light in the iFan04. Then expose the virtual switch to HomeKit. That should solve it.
FYI @cjcharles submitted an update to GitHub that allows for the creation of child devices but effectively using my driver. Don’t know if it would work in this case but I plan to take a look at when I get home in March. Perhaps @cjcharles could comment on this?
FYI that the speed command\attribute in Tasmota refers to the fade speed of a bulb and has nothing to do with fan. So it seems there is something else going on here.
Could easily be modified to create child devices with the ifan but probably not super simple given the multi-switch setup works because if the sequential numbering of each switch and command.
Also perhaps the fan attribute into homekit needs a review anyway, if speed isn't working (also there are only 3 speed settings, so most variable speed/dimmer controls may get confused). I don't have any apple stuff to test with but I do have an ifan so can see how it works with the default config in android hubitat...
