[RELEASE] Tasmota RGBW LED Light Bulb Driver

⚙️ Custom Apps and Drivers
34

I believe (99.5% sure) the issue is that you flashed your lights with the Hubitat specific tasmota firmware that is meant to be used with that specific tasmota driver. That firmware has a setting to report state changes back to hubitat which will result in that warning if not using the proper driver with the firmware as other drivers aren't expecting that data.

This driver is meant for devices using standard/generic firmware. It still works because the underlying command are the same, but your getting extra data back to the hub you cant use, which is wasting some of your resources.

You options are...

A. Re-flash your bulbs with tasmota-minimal.bin then tasmota.bin from either the maintenance release here http://thehackbox.org/tasmota/ or the main branch here http://thehackbox.org/tasmota/release/

B. Uninstall this driver and use the one your firmware was written for found here : [DEPRECATED] Tasmota 7.x/8.x firmware for Hubitat + Tuya, Sonoff and other drivers - #414 by anon62731458

C. Do nothing since everything "works" but if you experience hub slowdowns after a few days look into this as http stuff is suspected as a potential cause for the hub slowdowns some users experience after several days of uptime.

35

This is definitely my Tasmota firmware modified for Hubitat sending data. You have two more options:

D. Go to http://192.168.178.237/co and disable the Hubitat / SmartThings feature.
E. Change the "Device Network ID" of your device in HE to your device MAC "C44F33A1066E" or IP "C0A8B2ED". The parse function of this driver will then receive the data and should just discard it. Watch the logs for errors, but there shouldn't be any. The parse function "should" ignore anything unexpected.

Unless Teleperiod is set to anything other than default, that is one message every 5 minutes. And in terms of wasting resources, I seriously doubt that. Not from that. There's other things which are way worse.

1 Like
36

Let me preface by saying I am a beginner here and am still learning, so please understand I am not trying to argue with you at all, I am explaining my understanding of things, in hopes of having misconceptions or understandings cleared up for myself and anyone else who comes across this.

When i was using your firmware, i have reverted until you get the new version out which hopefully uses 8.1.0.6 for the connectivity adjustments, (they really help with getting your devices to use and stay on the best signal AP) I was under the impression any commands sent to the light resulted in it sending back that data so hubitat could remain properly updated on the lights state.

I didn't realize they auto sent every 5 minutes.

It might not seem like much but when you have a high number of these lights like oh say 60, thats 720 extra data points being sent per hour, and if I understand the functioning could be another 60 per light change if someone has a scene or mode that changes every light to a setting without any checks on state first.

There are other things that are worse yes, but some extensive reading the past few days has led me to understand the developers recommendation is to eliminate as much excess data sending between devices and the hub as you can, and if hes not going to be using the data why have it being sent to begin with?

Also it seems that the slowdowns some end up encountering are suspected to be partially related to http traffic, and i personally noticed a 20-40ms increase in the time it took the lights to change from motion detect etc with that hubitat settings enabled. Disabling it from the web UI for the light removed the increase.

So yeah not much at all BUT if your pushing the edge of that 250ms window of perception that small amount of resources saved from processing that data can be the difference from the lights feeling instant or delayed and having a high or low WAF/HAF.

37

Let's start here, did you notice a difference? If so I'll release 8.1.0.6 in a few hours most likely, just that I'm very conservative in making new releases unless it is for stability or some required features. I have my 50+ wifi devices reporting 76% connectivity and up. The RSSI value in Tasmota is actually percent.

This is the "heartbeat" of Tasmota, it can be adjusted to be once every 3600 seconds by using the command "teleperiod". Some of my drivers do keep it at 300 seconds though. My new driver currently only in the development repo can adjust it in the driver settings for all device types. This is NOT released and only for testing.

There is no real reason as to why you'd want to receive it, but with the number of devices I have, I have no decernable issues. But then I don't run basically anything except my own drivers and app + built-in and drivers from one other developer.

It is possible, I'll be running some more benchmarking against timing once I have my new drivers out, they have a bit more code, but are better and more optimized so they do run faster than my old drivers. Disabling that might result in unsynched states when using my drivers, but usually that is more an issue with dimmers. And for sensors it is of course needed to have it active. Polling is the real problem, that is something my drivers NEVER do.

To each his own, my WAF is high, so I guess it's all good :stuck_out_tongue: But yes, many things do come to play in this. I find I save more time in not using RM or other Apps and to use my own App tailor-made for my own use so that there is NO extra anything except the logic needed to get my home to work. That saves me more in response time than disabling callback from Tasmota.

With all of the above said, slowdowns are hard to diagnose on this platform, all I can say is that I do all that is possible for speed, but not at the expense of sacrificing having correct states.

Please confirm that you really have better connectivity with 8.1.0.6? But do so in my driver thread, please.

EDIT: To clarify, I have 52 Tasmota devices in my network as of yesterday, and 60+ Zigbee devices.

38

@markus I'd love to run on all my own code, but im no where near the point id feel capable of doing so. I'll get there eventually though, in the meantime we have awesome people like you sharing what youve done :slight_smile:

I currently have 28 zigbee devices connected with 5 more gen 2 iris outlets) on the way. I have a total of 60 tasmota bulbs going inside, and another 20 going outside. Currently only have 24 of the bulbs online, still putting in recessed cans in the rest of the rooms before adding the lights in.

I've been moving away from RM and towards apps with less overhead, in fact i only have one rule in RM and that is just a stupid on push play random message rule. I only have one user made app. and thats an alteration of simple motion lighting which i still need to figure out how to add fade in and out and lux control into, then i can do away with the inbuilt motion lighting app as well.

I love the platform but i am in the I wish we had some proper resource monitoring tools, and access to all the logs etc the devs have camp.

I'm not used to having the ability to run custom code without anyway to detect loads access to real logs etc...

I can partially understand the developers standpoint on it, we dont need a bunch of people on here making threads and opening support tickets because they think the load is too high even with a fully responsive and snappy system.

But since this platform is clearly intended for the enthusiast/hobbyist and not the consumer market that argument really doesn't make much sense as the community is the heart of the product and the first line of support. Be a lot easier to diagnose issues if we could see usage stats and be able to pinpoint for example that all systems encountering slowdown are having process x go into a loop cycle after x hours have passed, but what do I know lol

Ok enough derailing this thread, I apologize for that, I seem to be forming a bad habit of doing that... over to markus' thread to post about the 8.1.0.6 thing.

39

I've replied in the other thread to keep this thread from derailing more.

40

@markus I'm starting to move all of my drivers over to your firmware. I have all but my ifan02/ifan03 devices working with it at this point. I would be willing to work with you to convert them or if you want to take my driver and see what I'm doing and convert I'd be happy with that. I'd love to be able to shut down my drivers as your way has less overhead and I really don't have time to move to async http.

41

Hi @damon.dinsmore, nice to hear you're moving over to using my firmware :slight_smile: I could add support of ifan02/ifan03 in my new driver, I don't have one though and right now nothing of what I order here in China is being delivered.
My driver is different in philosophy to many others, I have it very performant and fast (when I put down my first foot in a room, my lights are on), but it has MANY lines of code. Most of those lines are not active when performing or receiving actions/updates since they are there for auto-configuration and setup, among other things. If you don't mind a driver such as that, I'd be happy to add iFan support.
For that I'd like the output of "status 0" in the Tasmota Console. This is the information I use for auto-detecting which device it is. The output of that together with your drivers and the template for the devices you use should be enough to get it working.

My driver contains entries like these for all directly supported devices:

[typeId: 'brilliantsmart-20676-plug' ,
        name: 'BrilliantSmart 20676 USB Charger Plug',
        template: '{"NAME":"Brilliant20676","GPIO":[0,0,0,0,0,21,0,0,0,52,90,0,0],"FLAG":0,"BASE":18}',
        installCommands: [["SetOption81", "1"]],
        deviceLink: 'https://templates.blakadder.com/brilliantsmart_20676.html',
        open: ["TuyaSend4", "101,0"],
        stop: ["TuyaSend4", "101,1"],
        close: ["TuyaSend4", "101,2"],
],

The above is not a correct device entry, but it showcases the types of settings it can take. For a fan instead of open, stop, close there would be the different fan-mode commands. Do you use anything that needs TuyaSend? I saw a fan controller driver with that from you?

You can take a look at my current development drivers, the parent, and a child driver. There would be need for a child driver for fans, there is no built-in Generic Component Fan, but those are simple and you could even make your own the way you want it and just put that one as the driver for the child device created by the parent if you don't want the one I'll make.

What do you think? I'd love to collaborate on this and I'd love input from a fellow developer :slight_smile:

For others reading this, the above driver is not yet released and not supported, unless you want to live on the bleeding edge and is very technically minded, don't use it.

42

@markus, I like what you have done. I was hoping to find a way to get Tasmota to do what you and ericm has done without having to modify the firmware but now that you have gotten the firmware to use the original interface with some additions it meets my needs.

I like that I can add devices just using the device drivers and not have to use the app to make the devices work with Hubitat. This allows me to move a device with all of its rules, connections and other groups or apps without having to redo all of that. The ability to use ip address was huge as well as I run VLANS to protect my devices and computers from possible hacks. Thank you!

I don't use the TuyaSend command except for the one driver that someone had asked me to attempt and he never responded. So I'm not worried about that one.

The ifan02 is very straight forward and should be able to be converted in the way you suggest.

The ifan03 is much more complicated because we have to send the command and a beep command as it is not hardware linked in the ifan03. I had worked with Theo Arends to add that support and it works great but causes the response back to be messed up because I was using the backlog command. If you have a way to fix this I'm all for it and would love to see the fix as I'm sure that we would have used for this in other drivers as well. iFan03 can use the template layout as you show in the example above.

I have 2 ifan02 and 2 ifan03 and can use one of each for testing. I can't remember off hand but we may have to compile a specific version of the Tasmota firmware to get it to load on the iFan. Not use but I will try and load it on one of each to get up to version 8.1.0.

Also, there is light control for each so it may take 2 child devices.

I look forward to working with you on this.

43

Nice to hear!

Yes, that is something I do as well, but it is an "advanced" usage so not anything most people do. The issue are with child devices if they were added as components. Then you "can't" change the driver they use. You actually can, the restriction is just in the html, so easy enough to get around. My new driver doesn't add as component devices and if you as the user set the wrong driver, that is your own problem... Usually it shouldn't be changed anyway. So full flexibility.
With that said, this new driver of mine doesn't use the parent as anything except for things like parsing and handling the communication with Tasmota. The only capability of note is Presence, this is used to show if that the Tasmota device is online and active, or not. This would make a switch device which previously had no child devices to have a child device as the switch. It would be possible to add an option to do it differently, but I chose to do it this way because sometimes people want their switches to be shown as lights in Google Home/Alexa integrations and other such things. It allows for more flexibility without having to touch the parent.
I can also have only 1 parent.

That is why that option exists, for us with non-simple home networks...

That was rude of that person! Then we don't need to worry about that one.

Ok, we do it as you have it in your code to begin with, when I get an iFan03 I will see what I can do to improve it.

If that is needed, tell me what the compile options you need are and I'll include it in my build configuration as a special build.

If the light is reported as Power by Tasmota, it will be added as a child device automatically. No extra code needed. This is why I want to see the result of "Status 0" from both devices, that way I can see if my detection methods will work properly.

Likewise, if you have the time to look through my code, I'd be happy to hear your opinions as well! Everything is stitched together from multiple files when "building" the driver, so there's auto-generated comments in the code about that.

1 Like
44

@markus, Sorry I missed that you needed me to do that. Here it is:

ifan02 Status 0

05:09:07 CMD: status 0
05:09:07 RSL: STATUS = {"Status":{"Module":44,"FriendlyName":["Sonoff"],"Topic":"sonoff","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
05:09:07 RSL: STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/release/sonoff.bin","RestartReason":"Software/System restart","Uptime":"29T05:09:06","StartupUTC":"","Sleep":50,"CfgHolder":4617,"BootCount":81,"SaveCount":124,"SaveAddress":"F8000"}}
05:09:07 RSL: STATUS2 = {"StatusFWR":{"Version":"6.5.0(basic)","BuildDateTime":"2019-07-30T12:29:19","Boot":7,"Core":"2_5_2","SDK":"2.2.1(cfd48f3)"}}
05:09:07 RSL: STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["WLAN-Devices",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00008001","280500000100000000000000000000000000","00000000"]}}
05:09:07 RSL: STATUS4 = {"StatusMEM":{"ProgramSize":467,"Free":536,"Heap":27,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"144051","FlashMode":3,"Features":["00000809","07002380","00000000","00000006","000000C0"]}}
05:09:07 RSL: STATUS5 = {"StatusNET":{"Hostname":"sonoff-7841","IPAddress":"192.168.50.101","Gateway":"192.168.50.1","Subnetmask":"255.255.254.0","DNSServer":"(IP unset)","Mac":"DC:4F:22:DB:9E:A1","Webserver":2,"WifiConfig":1}}
05:09:07 RSL: STATUS7 = {"StatusTIM":{"UTC":"Fri Jan 30 05:09:07 1970","Local":"Fri Jan 30 05:09:07 1970","StartDST":"Thu Jan 01 00:00:00 1970","EndDST":"Thu Jan 01 00:00:00 1970","Timezone":"+00:00","Sunrise":"07:23","Sunset":"16:43"}}
05:09:07 RSL: STATUS10 = {"StatusSNS":{"Time":"1970-01-30T05:09:07"}}
05:09:07 RSL: STATUS11 = {"StatusSTS":{"Time":"1970-01-30T05:09:07","Uptime":"29T05:09:06","Vcc":3.486,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER1":"OFF","FanSpeed":0,"Wifi":{"AP":1,"SSId":"WLAN-Devices","BSSId":"34:8F:27:55:F7:48","Channel":11,"RSSI":94,"LinkCount":10,"Downtime":"0T00:01:06"}}}

ifan03 Status 0

03:42:08 CMD: status 0
03:42:08 RSL: STATUS = {"Status":{"Module":71,"FriendlyName":["TH Kitchen Fan"],"Topic":"sonoff","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
03:42:08 RSL: STATUS1 = {"StatusPRM":{"Baudrate":9600,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/release/sonoff.bin","RestartReason":"Power on","Uptime":"52T03:42:07","StartupUTC":"","Sleep":50,"CfgHolder":4617,"BootCount":19,"SaveCount":99,"SaveAddress":"F9000"}}
03:42:08 RSL: STATUS2 = {"StatusFWR":{"Version":"6.6.0.4(basic)","BuildDateTime":"2019-08-12T13:22:25","Boot":7,"Core":"2_5_2","SDK":"2.2.1(cfd48f3)"}}
03:42:08 RSL: STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["WLAN-Devices",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00008001","280500000100060000005A00000000000000","00020000"]}}
03:42:08 RSL: STATUS4 = {"StatusMEM":{"ProgramSize":471,"Free":532,"Heap":28,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"144051","FlashMode":3,"Features":["00000809","87082383","003003A0","20021706","010001C0","00000001"]}}
03:42:08 RSL: STATUS5 = {"StatusNET":{"Hostname":"sonoff-4884","IPAddress":"192.168.50.103","Gateway":"192.168.50.1","Subnetmask":"255.255.254.0","DNSServer":"(IP unset)","Mac":"DC:4F:22:AA:33:14","Webserver":2,"WifiConfig":4}}
03:42:08 RSL: STATUS7 = {"StatusTIM":{"UTC":"Sun Feb 22 03:42:08 1970","Local":"Sun Feb 22 03:42:08 1970","StartDST":"Thu Jan 01 00:00:00 1970","EndDST":"Thu Jan 01 00:00:00 1970","Timezone":"+00:00","Sunrise":"06:46","Sunset":"17:21"}}
03:42:08 RSL: STATUS10 = {"StatusSNS":{"Time":"1970-02-22T03:42:08","Epoch":4506128}}
03:42:08 RSL: STATUS11 = {"StatusSTS":{"Time":"1970-02-22T03:42:08","Epoch":4506128,"Uptime":"52T03:42:07","UptimeSec":4506127,"Vcc":3.427,"Heap":28,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"POWER1":"OFF","FanSpeed":0,"Wifi":{"AP":1,"SSId":"WLAN-Devices","BSSId":"34:8F:27:55:F7:48","Channel":11,"RSSI":76,"LinkCount":28,"Downtime":"0T00:02:55"}}}

45

@markus So in looking at my firmware that I compiled for the ifan02/03 I have my size down to 468kb

I'm about to backup and try to upload your hubitat firmware at 547kb

We will see what happens.... Well its successful on the ifan03....

46

Ok, I see that is an older Tasmota firmware, do follow the upgrade instructions for Tasmota. Using minimal etc...

Ok, that’s great

47

@markus, Ok so all firmware is updated and ready. Just need a driver now

48

Which template do you use? The one found here:

50

@markus

{"NAME":"Sonoff iFan03","GPIO":[17,255,0,255,0,0,29,33,23,56,22,24,0],"FLAG":0,"BASE":44}

51

Module 44 is for iFan02 and iFan 03 is module 71. Have you tried the one in the Tasmota Docs I linked to (which is module 71)? Is there a reason you don't use it?

I've ordered an iFan03, iFan02 doesn't exist anywhere in stock right now, but I guess I don't truly need that one. I don't really know when they will ship it, but we'll see. Since I don't have a fan to use, I'll just connect it to an incandescent lightbulb, that should do just as well for testing.

I'll see if maybe I can get this into my new driver sometime tomorrow, shouldn't take long.

52

@markus, I don't think module 71 existed for the ifan03 when I started BUT I do think I tried it and at the time the beep would not work when using 71 so I just kept with the custom one.

LOL on the light bulb. That will probably work. I have a few hundred Wemos D1 mini's here so I usually use one of those for testing. Whatever works works right?

53

Ok, SetOption67 indicates that the beep should work unless disabled when using module 71. None of this is critical to make the driver, I'll make it with what you use first, then a variant for the dropdown list selection without beep could be added.

Yes, I don't have that many, but a few, until I get my iFan03 I will test on one of those. That's a lot of Wemos D1 minis...

54

I look forward to testing the driver out. I did the same thing with a dropdown in the driver to allow the beep or not.

Yes I ordered a large batch as I make a lot of my own sensors. Water leak, pest control, and others.