It would be nice if someone we could get our own firmware uploaded to some of these products. Would solve a lot of issues.
Custom firmware would involve too much and too complicated work to handle all the different hardware variations / different chipsets. I don't think anyone has the time to do it.
1 Like
I guess for tweaks it might be useful.. But you are probably right (I mean face it, I'm just a hardware guy, not a developer) I can fantasize though!!! 
While we wait for a fix...
I found it quite annoying that the LED on the relay is red when it is ON, and green, when it is OFF, so I dug out a solution for it:
def setLed(value) {
List<String> cmds = []
cmds += zigbee.writeAttribute(zigbee.ON_OFF_CLUSTER, 0x8001, 0x30, value.toInteger())
sendZigbeeCommands(cmds)
}
I don't know how other Tuya devices behave, but I can use the following parameters:
0 (or any other value): Always green
1: red when ON, green when OFF (it was the default in my case)
2: green when ON, red when OFF
3: always red
One can even make a warning indicator with it by periodically toggling between mode 1 and mode 2... 
Maybe I'm the only one whose OCD was triggered by the LED's color, but it might be a useful feature for someone, so I thought I should share it with you.
1 Like
It's strange for me too, but I read somewhere that this is a kind of a standard for circuit breakers, the red color meaning 'warning, high voltage!'
Thank you very much, I will implement it as a command in the next driver release, hopefully very soon.
Do you happen to know how to configure the 'power on behavior'? It is probably very similar, attribute 0x8000 or 0x8002 or ..... This is in my TODO list for a long time, but I started too many other projects here and never had the time to research and implement it.
I think that the 'LED status' and the 'Power on Behaviour' options will be handled better if implemented as parameters/preferences instead of commands. However, this approach will require some more significant changes in the driver code. Currently, all parameters are always initialized with a default value. But for parameters like these where the default value is unknown, there should be a 'not initialized' or null value. Only if the same parameter was read or received from the device, or if it was explicitly manually changed from the device page web UI - only then the driver should send a command to change it to the device.
BTW, I will gladly accept any Pull Requests for this (and my other drivers) on GitHub.
Are you looking for this, Sir?
/*
Power on mode
0: OFF
1: ON
2: remember state
*/
def setPowerOnMode(value) {
List<String> cmds = []
cmds += zigbee.writeAttribute(zigbee.ON_OFF_CLUSTER, 0x8002, 0x30, value.toInteger())
sendZigbeeCommands(cmds)
}
Had no time to test it yet, but it should work...
1 Like
Thank you! This should work for some of the Tuya plugs/relays, for the rest that do not support the standard Zigbee OnOff cluster I already have the DataPoints, so hopefully these configurations will work for almost all of the supported models/manufacturers.
@kkossev I just received several of these Tuya TS011Fs today. They easily paired and work with you driver. I'm curious as to why these plugs are labeled on the physical plug with a model number BSD01 which appears to be a Casalink wifi plug but are sold as Tuya 20 Amp Zigbee Smart Plug.
Many thanks for the driver.
1 Like
Probably reusing shells
1 Like
hello guys, I received a new plug, I tried to use the current version driver but the device does not starts
would anyone have a solution
ID: 93EB
Manufacturer: _TZ3000_5f43h46b
Product Name:
Model Number: TS011F
deviceTypeId: 562
manufacturer : _TZ3000_5f43h46b
idAsInt : 1
inClusters : 0003,0004,0005,0006,0702,0B04,E001,E000,0000
endpointId : 01
profileId : 0104
application : 4A
outClusters : 0019,000A
initialized : true
model : TS011F
stage : 4
manufacturer :
idAsInt : 242
inClusters :
endpointId : F2
profileId : A1E0
application :
outClusters : 0021
initialized : true
model :
stage : 4
1 Like
@user778 I have updated the driver with your device fingerprint.
Please use the development branch (link in the second post) to manually update the driver. Then REMOVE the device from its Web UI and pair it again to HE. This driver should be now selected automatically.
This plug exposes the 'Green Cluster' Zigbee endpoint, which is rather unusual for a mains powered device... and it seems like F2 endpoint confuses the HE pairing and driver matching process sometimes.
Please let me know if it works for you with the latest driver version.
1 Like
It's working fine.
1 Like
IMHO if red is being used for on, then the light needs to be off when off. It would definitely confuse me. For instance, my TV has a red light in standby and none when either not powered, or contrarily, actually on!
1 Like
The dev. branch was updated (same ver. 1.4.5, but new time stamp). The new version can be now easily updated directly from HE Drivers Code editor - locate the driver and press the Import button.
Added new configuration commands:
These configurations for sure will not work for all the different models, but if the command was accepted there should be an Info log as confirmation.
As expected, the LED configuration commands are different for the plugs/sockets if compared to the circuit breakers (or DIN relays). The 'Child Lock' command does not work for my BlitzWolf plug, but may work for other plugs/sockets.
1 Like
done, now it's working, thank you very much!
the link:
1 Like
Great driver, thank you very much kkossev!!
Recently I started with home automation and the hubitat is my first hub which I have since April. Because off your driver, I (again) ordered more Tuya plugs and I soon will have 24 Tuya TS011F plugs all around my house and garage (it's 14 at this moment). Besides all the smart plugs/appliances I created this way, I hope to create an strong repeater zigbee mesh around the house and garage.
But it also creates an problem, as not all my plugs needs all voltage, current, energy and power measurements all the time plus it will flood the zigbee network with polling data for 24 plugs and the logs will be huge... I do like to know kWh measurements for most off the plugs (and sometimes other electrical values for some plugs). Therefore I am trying to alter your driver and removing everything with energy, voltage, current, amperage, etc and that seems to work. But it for sure is not the cleanest method, as the plug will create logs with "other Tuya oddities - don't know how to handle it, skipping it for now..." as I removed all the coding for that.
As I am not a coder and hardly understand what is happening in your driver, I would like to ask: how can I alter your driver so that some of the different electrical measurements are not polled/logged/send over zigbee mesh? Or may I suggest to add on/off switches for power, amperage, voltage and energy? I don't know how hard it is to implement the on/off switches, but it will for sure add a lot of functionality to your driver.
Thanks again for your work on this driver 
1 Like
Hi @FrankieH , welcome to Hubitat community and thank you for your feedback!
Your comments and the proposal to add on/off switches make perfect sense. In fact, these were on my TODO list for quite a long time... So finally today I added the preference options for switching the energy, voltage, current, and the amperage polling and processing. By default, all are enabled. When switched off, the active polling for the particular V/A/W attribute is stopped, the events are not registered and no logs are written.
The Energy switch is an exception: when switched off, the active polling is disabled, but if the plug sends automatically an Energy consumption report, it is processed as an event and is shown in the logs. The Energy reporting intervals can be fine tuned with the existing options, so there should be possibilities to cover all the different use cases and needs.
The new on/off switches are available in the development branch (the link from the the second post). If this new version works OK, I will push it later to the main 'production' branch that is available for update from Hubitat Package Manager – HubitatCommunity (HPM).
If the driver is successfully updated to the latest dev. version, the new preference options should look like this:
What is your plugs Model and Manufacturer data values?
Handling 24 reporting plugs will be an interesting challenge... if you have any other ideas for improvements/optimizations, don't hesitate to share them here.
1 Like
Wow, that was really quick 
I started with 4pieces IG019 with (I guess) Polish manual from NEO ZigBee On Off Power Metering Plug ultrasmart.pl where I also bought my Hubitat C7.
The Hubitat device page with using your 1.4.6 driver is giving the following data:
- endpointId: 01
- application: 44
- softwareBuild:
- inClusters: 0003,0004,0005,0006,0702,0B04,E001,E000,0000
- outClusters: 0019,000A
- model: TS011F
- powerCluster: 0B04
- manufacturer: _TZ3000_gjnozsaz
The powerCluster is only mentioned in one of the 4 plugs, this is one unit which is not responding anymore on digital on/offs since a weird power (spike?) issue a few days ago in the neighboorhoud (very rare, never saw this before). These 4 units don't seem to remember their powerstate when unplugged, which is very unfortunate when your measuring kWh for your fridge or something.
Within 2 weeks after those 4, I bought locally from some guy 10pieces NAS WR01B which look almost identical. These 10 units seems to remember their powerstate when unplugged (I have to do some further testing), which is an feature which all smart bulbs/plugs/etc should have imho...
- endpointId: 01
- application: 4A
- softwareBuild: 0000004A
- inClusters: 0003,0004,0005,0006,0702,0B04,E001,E000,0000
- outClusters: 0019,000A
- model: TS011F
- powerCluster: 0B04
- firmwareMT: 1141-D3A3-0000004A
- manufacturer: _TZ3000_gjnozsaz
I checked all 10 driver manufacturer data and only one is mentioning the above values, 9 others are mentioning:
- endpointId: 01
- application: 4A
- softwareBuild:
- inClusters: 0003,0004,0005,0006,0702,0B04,E001,E000,0000
- outClusters: 0019,000A
- model: TS011F
- manufacturer: _TZ3000_gjnozsaz
One of these 9 plugs is mentiong outClusters: 0021
At this moment, I have changed 4 of my plugs drivers to 1.4.6, 2 for the IG019 and 2 for the NAS WR01B. Both sets I will be testing one plug with all measurements and one with only kWh.
None of the 4 plugs with new driver will save ChildLock, PowerOnState and LedMode.
As I was writing this, I received my other 10 plugs from which I have installed 9 and at this moment I have 23plugs using driver1.4.6 metering kWh or nothing. This I have to further investigate what is happening once the zigbee mesh is settled. To be continued as I will be testing the timings and minimum Wh to be polled (which does not seem to work) and other stuff I think off... If you have a suggestion what I should test, please tell me, maybe I am able to.
Suggestions:
- would it be able to reset the Energy kWh value to zero?
- perhaps (only) polling kWh value at the end off the day, week or month (I am more or less interested in power consumption during longer periods of time). Or would that be the value which can be used at shortest and longest interval (which I also want to test if it works)?
1 Like
