I will test 1.5.0 on 4 plugs. The driver has an little error in last line:
unexpected token: } @ line 1029, column 1.
1 Like
After 2-3 hours when home I will publish another test version trying to disable the frequent ‘Tuya Check-in’ messages.
Also adding Receive and Transmit counters, these will show the real communication load picture.
1 Like
Will be nice to see all those add-ons, thank you for your development.
First impression of 1.5.0: only with the following setting, the log seems to be clear and empty untill a value differs, did not look at the debug logs yet but will do in your next update:
But whatever I do, it always will give kWh values when they change and always in 0,01 kWh steps.
edit post:
btw: all my dashboard tile activity histories are only mentioning the kWh (and I think the V/A/W values) once with the time it has changed. Also when automatic polling and energy reporting are ON but then the Hubitat logs gets several reports for the same vaulues when they do not change.
After a lot of experiments, my conclusion is that the automatic reporting (without polling) of these Tuya plugs can not be configured. It is hardcoded for the Energy and seems to depend on the current power usage (respectively the kWh increase rate). Energy and OnOff custers allow the configuration to be written and read back, but that;s all,,, nothing really happens! TS004F simply echoes back the stored minimum and maximum time periods, but does not take them in effect. Also, there is no delta (minimum Wh change) parameter at all when configuring and reading the energy cluster reporting configuration!
The above means, that the currently shown preferences 'Energy shortest reporting interval', 'Energy longest reporting interval' and the 'Energy minimum change to be reported, Wh' do not have any effect (although sent and stored in the plug NV memory). So I plan to remove these 3 parameters in the next version update.
The automatic reporting for the Power, Voltage an the Amperage can not be either read nor written.
In the latest 1.5.0 version codeupdate there is a test command 'Configure reporting' defined near lines 71...77, which is commented out. If you remove the surrounding /* and */ sequences and Save the changed driver, the simple test command will be shown on the web UI. It is for testing purposes, so there are no any parameters checks. All the parameters must have some value, so fill in zeroes in all fields even for Read operation, otherwise the driver will throw an exception in the logs.
The result from the Read or Write configuration test commands can be seen in the logs.
dev:24762022-06-05 22:48:39.849 infoTS011F Lelki Socket (_TZ3000_ps3dmato) Received Read Reporting Configuration Response (0x09) for cluster:0702 attribite:0000, data=[00, 00, 00, 00, 25, 3C, 00, 10, 0E, 00, 00, 00, 00, 00, 00] (Status: Success) min=60 max=3600
Accepting the fact, that the automatic Energy reporting can not be re-configured from the driver, next question is what type of polling to implement for it ( currently the energy is not polled when "Optimize polling and logging" option is On - it doesn't; make any sense to poll for kWh every 60 seconds....
One approach would be to simply leave it as it is now - the socket will report the Energy as frequent as it is hardcoded ( BTW, when paired to Tuya gateway there is no way to configure the reporting periods as well!)
The second approach (polling) will require a second preference parameter - 'Energy polling interval', that by default could be set to 1 hour or similar (but not 60 seconds). So every hour the plug will be polled to report the kWh energy consumption (this reading will be in addition to the incnfogurable automatic reporting that may happen in between the 1 hour periods)
This confirms my findings above.
This is the default behavior with all events in Hubitat - if the event value has not changed, the event is not registered and more important - all the applications that listen for this event are not triggered (as there was no change of this parameter). This can be changed by forcing 'isStateChange: true' when processing the event, where really needed.
I'd prefer if we didn't have such frequent voltage events recorded. My plug's rarely in use but when it is, I want it reporting power draw every minute. However this means I get a voltage report every minute all the time even when it's not being used. Would it be possible to opt out of the voltage events? Being on the town grid, I don't really need to worry about the voltage, even though it does fluctuate by a couple of volts which is presumably why it's recording events at all.
1 Like
Well, that's a pity, but at least it is possible that no V/W/A logs are created with which I am very very happy. Don't know if this is possible to change with Tuya firmware, I did not investigate firmwares yet so at this moment I even do not know how to find which hardware and/or firmware versions my plugs have, let alone how to update plug firmwares...
Besides firmware change (would that even be possible?), I think an hourly/daily/weekly or whatever kWh (and perhaps V/W/A for other users) logging rate could be interesting.
I tried the "configure reporting", but when I save preferences, all values disappears. So I copied before save (don't know if I hit save when I saw read or write)
This is the log with it:
Summary
dev:1312022-06-06 11:12:29.744 debugDiepvries Event enter: [name:switch, value:on]
dev:1312022-06-06 11:12:29.740 debugDiepvries parse: description is read attr - raw: C5140100060800001001, dni: C514, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 01
dev:1312022-06-06 11:12:15.564 debugDiepvries energy is 31.9 kWh (no change)
dev:1312022-06-06 11:12:15.561 debugDiepvries Desc Map: [raw:C51401070212000025760C00000000, dni:C514, endpoint:01, cluster:0702, size:12, attrId:0000, encoding:25, command:0A, value:000000000C76, clusterInt:1794, attrInt:0]
dev:1312022-06-06 11:12:15.555 debugDiepvries parse: description is read attr - raw: C51401070212000025760C00000000, dni: C514, endpoint: 01, cluster: 0702, size: 12, attrId: 0000, encoding: 25, command: 0A, value: 760C00000000
dev:1312022-06-06 11:12:15.514 debugDiepvries Desc Map: [raw:C514010B041E050521E6000805213F010B05294800, dni:C514, endpoint:01, cluster:0B04, size:1E, attrId:0505, encoding:21, command:0A, value:00E6, clusterInt:2820, attrInt:1285, additionalAttrs:[[value:013F, encoding:21, attrId:0508, consumedBytes:5, attrInt:1288], [value:0048, encoding:29, attrId:050B, consumedBytes:5, attrInt:1291]]]
dev:1312022-06-06 11:12:15.505 debugDiepvries parse: description is read attr - raw: C514010B041E050521E6000805213F010B05294800, dni: C514, endpoint: 01, cluster: 0B04, size: 1E, attrId: 0505, encoding: 21, command: 0A, value: E6000805213F010B05294800
dev:1312022-06-06 11:11:06.322 infoDiepvries Tuya Cluster 0000 attrId FFE4 value 00)
dev:1312022-06-06 11:11:06.320 infoDiepvries Tuya Cluster 0000 attrId FFE2 value 35)
dev:1312022-06-06 11:11:06.317 infoDiepvries Tuya check-in Cluster 0 attrId 1 (application version is 4A)
dev:1312022-06-06 11:11:06.312 debugDiepvries parse: description is read attr - raw: C514010000180100204AE2FF2035E4FF2000, dni: C514, endpoint: 01, cluster: 0000, size: 18, attrId: 0001, encoding: 20, command: 0A, value: 4AE2FF2035E4FF2000
dev:1312022-06-06 11:09:27.659 debugDiepvries energy is 31.9 kWh (no change)
dev:1312022-06-06 11:09:27.657 debugDiepvries Desc Map: [raw:C51401070212000025760C00000000, dni:C514, endpoint:01, cluster:0702, size:12, attrId:0000, encoding:25, command:0A, value:000000000C76, clusterInt:1794, attrInt:0]
dev:1312022-06-06 11:09:27.651 debugDiepvries parse: description is read attr - raw: C51401070212000025760C00000000, dni: C514, endpoint: 01, cluster: 0702, size: 12, attrId: 0000, encoding: 25, command: 0A, value: 760C00000000
dev:1312022-06-06 11:09:27.621 debugDiepvries Desc Map: [raw:C514010B041E050521E50008052146010B05294900, dni:C514, endpoint:01, cluster:0B04, size:1E, attrId:0505, encoding:21, command:0A, value:00E5, clusterInt:2820, attrInt:1285, additionalAttrs:[[value:0146, encoding:21, attrId:0508, consumedBytes:5, attrInt:1288], [value:0049, encoding:29, attrId:050B, consumedBytes:5, attrInt:1291]]]
dev:1312022-06-06 11:09:27.612 debugDiepvries parse: description is read attr - raw: C514010B041E050521E50008052146010B05294900, dni: C514, endpoint: 01, cluster: 0B04, size: 1E, attrId: 0505, encoding: 21, command: 0A, value: E50008052146010B05294900
dev:1312022-06-06 11:08:28.951 infoDiepvries Tuya Cluster 0000 attrId FFE4 value 00)
dev:1312022-06-06 11:08:28.949 infoDiepvries Tuya Cluster 0000 attrId FFE2 value 35)
dev:1312022-06-06 11:08:28.946 infoDiepvries Tuya check-in Cluster 0 attrId 1 (application version is 4A)
dev:1312022-06-06 11:08:28.941 debugDiepvries parse: description is read attr - raw: C514010000180100204AE2FF2035E4FF2000, dni: C514, endpoint: 01, cluster: 0000, size: 18, attrId: 0001, encoding: 20, command: 0A, value: 4AE2FF2035E4FF2000
dev:1312022-06-06 11:06:28.196 infoDiepvries energy is 31.9 kWh
dev:1312022-06-06 11:06:28.194 debugDiepvries Desc Map: [raw:C51401070212000025760C00000000, dni:C514, endpoint:01, cluster:0702, size:12, attrId:0000, encoding:25, command:0A, value:000000000C76, clusterInt:1794, attrInt:0]
dev:1312022-06-06 11:06:28.188 debugDiepvries parse: description is read attr - raw: C51401070212000025760C00000000, dni: C514, endpoint: 01, cluster: 0702, size: 12, attrId: 0000, encoding: 25, command: 0A, value: 760C00000000
dev:1312022-06-06 11:06:24.378 debugDiepvries energy is 31.89 kWh (no change)
dev:1312022-06-06 11:06:24.376 debugDiepvries Desc Map: [raw:C51401070212000025750C00000000, dni:C514, endpoint:01, cluster:0702, size:12, attrId:0000, encoding:25, command:0A, value:000000000C75, clusterInt:1794, attrInt:0]
dev:1312022-06-06 11:06:24.371 debugDiepvries parse: description is read attr - raw: C51401070212000025750C00000000, dni: C514, endpoint: 01, cluster: 0702, size: 12, attrId: 0000, encoding: 25, command: 0A, value: 750C00000000
dev:1312022-06-06 11:06:24.342 debugDiepvries Desc Map: [raw:C514010B041E050521E60008052143010B05294800, dni:C514, endpoint:01, cluster:0B04, size:1E, attrId:0505, encoding:21, command:0A, value:00E6, clusterInt:2820, attrInt:1285, additionalAttrs:[[value:0143, encoding:21, attrId:0508, consumedBytes:5, attrInt:1288], [value:0048, encoding:29, attrId:050B, consumedBytes:5, attrInt:1291]]]
dev:1312022-06-06 11:06:24.332 debugDiepvries parse: description is read attr - raw: C514010B041E050521E60008052143010B05294800, dni: C514, endpoint: 01, cluster: 0B04, size: 1E, attrId: 0505, encoding: 21, command: 0A, value: E60008052143010B05294800
dev:1312022-06-06 11:05:43.601 infoDiepvries Tuya Cluster 0000 attrId FFE4 value 00)
dev:1312022-06-06 11:05:43.598 infoDiepvries Tuya Cluster 0000 attrId FFE2 value 35)
dev:1312022-06-06 11:05:43.596 infoDiepvries Tuya check-in Cluster 0 attrId 1 (application version is 4A)
dev:1312022-06-06 11:05:43.591 debugDiepvries parse: description is read attr - raw: C514010000180100204AE2FF2035E4FF2000, dni: C514, endpoint: 01, cluster: 0000, size: 18, attrId: 0001, encoding: 20, command: 0A, value: 4AE2FF2035E4FF2000
dev:1312022-06-06 11:03:43.775 debugDiepvries energy is 31.89 kWh (no change)
dev:1312022-06-06 11:03:43.772 debugDiepvries Desc Map: [raw:C51401070212000025750C00000000, dni:C514, endpoint:01, cluster:0702, size:12, attrId:0000, encoding:25, command:0A, value:000000000C75, clusterInt:1794, attrInt:0]
dev:1312022-06-06 11:03:43.767 debugDiepvries parse: description is read attr - raw: C51401070212000025750C00000000, dni: C514, endpoint: 01, cluster: 0702, size: 12, attrId: 0000, encoding: 25, command: 0A, value: 750C00000000
dev:1312022-06-06 11:03:43.738 debugDiepvries Desc Map: [raw:C514010B041E050521EA0008052140010B05294900, dni:C514, endpoint:01, cluster:0B04, size:1E, attrId:0505, encoding:21, command:0A, value:00EA, clusterInt:2820, attrInt:1285, additionalAttrs:[[value:0140, encoding:21, attrId:0508, consumedBytes:5, attrInt:1288], [value:0049, encoding:29, attrId:050B, consumedBytes:5, attrInt:1291]]]
dev:1312022-06-06 11:03:43.729 debugDiepvries parse: description is read attr - raw: C514010B041E050521EA0008052140010B05294900, dni: C514, endpoint: 01, cluster: 0B04, size: 1E, attrId: 0505, encoding: 21, command: 0A, value: EA0008052140010B05294900
dev:1312022-06-06 11:03:02.708 infoDiepvries Tuya Cluster 0000 attrId FFE4 value 00)
dev:1312022-06-06 11:03:02.705 infoDiepvries Tuya Cluster 0000 attrId FFE2 value 35)
dev:1312022-06-06 11:03:02.702 infoDiepvries Tuya check-in Cluster 0 attrId 1 (application version is 4A)
dev:1312022-06-06 11:03:02.698 debugDiepvries parse: description is read attr - raw: C514010000180100204AE2FF2035E4FF2000, dni: C514, endpoint: 01, cluster: 0000, size: 18, attrId: 0001, encoding: 20, command: 0A, value: 4AE2FF2035E4FF2000
dev:1312022-06-06 11:02:34.155 infoDiepvries Received Configure Reporting Response for cluster:0702 , data=[00, 00, 00, 00] (Status: Success)
dev:1312022-06-06 11:02:34.153 debugDiepvries Desc Map: [raw:catchall: 0104 0702 01 01 0040 00 C514 00 00 0000 07 01 00000000, profileId:0104, clusterId:0702, clusterInt:1794, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:C514, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00, 00, 00, 00]]
dev:1312022-06-06 11:02:34.148 debugDiepvries parse: description is catchall: 0104 0702 01 01 0040 00 C514 00 00 0000 07 01 00000000
dev:1312022-06-06 11:02:32.037 infoDiepvries Received bind response, data=[20, 00] (Sequence Number:20, Status: Success)
dev:1312022-06-06 11:02:32.035 debugDiepvries Desc Map: [raw:catchall: 0000 8021 00 00 0040 00 C514 00 00 0000 00 00 2000, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:C514, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[20, 00]]
dev:1312022-06-06 11:02:32.030 debugDiepvries parse: description is catchall: 0000 8021 00 00 0040 00 C514 00 00 0000 00 00 2000
dev:1312022-06-06 11:02:30.046 infoDiepvries Received Configure Reporting Response for cluster:0006 , data=[00, 00, 00, 00] (Status: Success)
dev:1312022-06-06 11:02:30.044 debugDiepvries Desc Map: [raw:catchall: 0104 0006 01 01 0040 00 C514 00 00 0000 07 01 00000000, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:C514, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00, 00, 00, 00]]
dev:1312022-06-06 11:02:30.038 debugDiepvries parse: description is catchall: 0104 0006 01 01 0040 00 C514 00 00 0000 07 01 00000000
dev:1312022-06-06 11:02:28.031 infoDiepvries Received bind response, data=[1E, 00] (Sequence Number:1E, Status: Success)
dev:1312022-06-06 11:02:28.028 debugDiepvries Desc Map: [raw:catchall: 0000 8021 00 00 0040 00 C514 00 00 0000 00 00 1E00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:C514, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[1E, 00]]
dev:1312022-06-06 11:02:28.023 debugDiepvries parse: description is catchall: 0000 8021 00 00 0040 00 C514 00 00 0000 00 00 1E00
dev:1312022-06-06 11:02:26.025 infoDiepvries energy is 31.89 kWh
dev:1312022-06-06 11:02:26.022 debugDiepvries Desc Map: [raw:C51401070214000025750C00000000, dni:C514, endpoint:01, cluster:0702, size:14, attrId:0000, encoding:25, command:01, value:000000000C75, clusterInt:1794, attrInt:0]
dev:1312022-06-06 11:02:26.017 debugDiepvries parse: description is read attr - raw: C51401070214000025750C00000000, dni: C514, endpoint: 01, cluster: 0702, size: 14, attrId: 0000, encoding: 25, command: 01, value: 750C00000000
dev:1312022-06-06 11:02:24.015 debugDiepvries Event enter: [name:switch, value:on]
dev:1312022-06-06 11:02:24.011 debugDiepvries parse: description is read attr - raw: C5140100060A00001001, dni: C514, endpoint: 01, cluster: 0006, size: 0A, attrId: 0000, encoding: 10, command: 01, value: 01
dev:1312022-06-06 11:02:23.828 debugDiepvries skipping Tuya parse of cluster 0 attrId 4
dev:1312022-06-06 11:02:23.825 debugDiepvries parse: description is read attr - raw: C51401000068040042105F545A333030305F676A6E6F7A73617A0000002003010000204A05000042065453303131460700003001FEFF003000, dni: C514, endpoint: 01, cluster: 0000, size: 68, attrId: 0004, encoding: 42, command: 01, value: 105F545A333030305F676A6E6F7A73617A0000002003010000204A05000042065453303131460700003001FEFF003000
dev:1312022-06-06 11:02:23.692 traceDiepvries sendZigbeeCommands received : [he raw 0xC514 1 0x01 0x0000 {10 00 00 04 00 00 00 01 00 05 00 07 00 FE FF}, delay 200, he rattr 0xC514 0x01 6 0 {}, delay 2000, he raw 0xC514 1 0x01 0x0702 {10 00 00 00 00}, delay 2000, zdo bind 0xC514 0x01 0x01 6 {A4C13835DF825222} {}, delay 2000, he cr 0xC514 0x01 6 0 16 0 600 {}, delay 2000, zdo bind 0xC514 0x01 0x01 0x0702 {A4C13835DF825222} {}, delay 2000, he cr 0xC514 0x01 1794 0 37 60 3600 {} {}, delay 2000]
dev:1312022-06-06 11:02:23.674 traceDiepvries polling.. refreshAll is true
dev:1312022-06-06 11:02:23.672 debugDiepvries refresh()...
dev:1312022-06-06 11:02:23.668 infoDiepvries configure()..
dev:1312022-06-06 11:02:23.665 infoDiepvries configuring the switch and energy reporting..
dev:1312022-06-06 11:02:23.663 infoDiepvries Auto polling is disabled
dev:1312022-06-06 11:02:23.657 infoDiepvries Debug logging will be automatically switched off after 24 hours
dev:1312022-06-06 11:02:23.635 infoDiepvries Debug logging is true Description text logging is true
dev:1312022-06-06 11:02:23.632 infoDiepvries Updating Diepvries (Energy plug 7) model TS011F presence: present AlwaysOn is false
could you perhaps also share your RM rule and variables for the Hubigraph?
That seems interesting to play with for one or two plugs.
This is the link to the exported TS011F Energy .json rule on my OneDrive (link)
When importing into RM 5.1 ( the cog wheel icon) you will be asked to replace the devices with your actual devices as I remember. And you will have to create two Hub Variables for each pug - one for the hourly energy and second for the daily energy ... Yes, there will be a lot of rules and variables for 20 plugs, so it will be worth to implement this RM rule into the driver code in the future..
On the 'Configure Reporting' - this is a command, like the 'On' ,'Off', 'Refresh', etc.. So you don't need to press Save button (Save button works only for the parameters, aka Preferences ). Just click on the 'Configure Reporting' button.
@Inge_Jones - the voltage events can be fully stopped if you toggle the 'Voltage Reporting' off:
(available in the latest beta version)
That'll teach me a lesson for not updating promptly 
1 Like
Thanks, will try it, but for sure not on 24plugs, maybe 1 or 2 when I think I have an necessary usecase. It is my first RM rule with variables and just created the hub variables. But I have to study this, as the import created some broken rules. When I find the time for this, I guess I will manage as it pushes me to learn more about RM, variables and .json and stuff, which I think I need/want to know.
The following settings give me only 0,01 delta kwh logs for all my plugs 
:
As soon as "Optimize polling and logging" is turned off, the log is showing returning kWh values without delta (besides the delta kWh off course).
An update on the "randomly turning off" issue:
I reported the problem to the seller, and they just came back to me, they sent an OTA update to my relays (v1.0.13)... I updated both my devices, turned them ON...
and now I'm waiting.
P.S.: To make sure I'm testing the "official" behavior, they're still connected to the Tuya hub
2 Likes
Thank you for the update, @guyeeba ! This is a very serious issue that affects a lot of newly produced Tuya plugs. Let's hope for the best (that a firmware update will fix the random turning off problem).
My two plugs that use this driver have turned voltage reporting and description text logging back on apparently by themselves twice since I last posted. The first time I thought maybe I'd forgotten to Save Preferences. But the second time I knew it wasn't me 
I can't think how this could be, unless something is happening to reset them to defaults. The hub did restart after I last changed the preferences, as I did an update. Stupidly, I didn't think to check whether the settings had toggled back on after doing that and due to the log spamming I can't see further back than this morning.
What’s the driver version?
I just rebooted the hub again to see, and the settings were reset again. So it's definitely something that happens when the hub starts up.
1 Like
I have delayed too much pushing into HPM the driver version 1.5.0 which fixes this bug... Will do it this evening when home.
I don't use HPM but the dev branch is separate from where I check.
Tested: Yep that seems fixed, thanks 
1 Like
Version 1.5.0 was also pushed for updates via HPM.
@guyeeba are your DIN relays working without the "randomly turning off" issue after the update to Tuya firmware version 1.0.13 ? I have updated my relay yesterday and there are no any problems in the last 24 hours!
I am not quite sure whether it is an effect of the firmware update, but now I see that the energy reporting configuration works (without polling!). So for your use case, disabling the automatic polling option and configuring the Energy minimum and maximum reporting intervals should work.
What is not supported by Tuya metering plugs is the ' Energy minimum change to be reported'. This parameter however can be taken in account from the driver logic, so that although the plug actually sends the kWh updates over the air, these can be ignored and no HE events generated.
I have also noticed that the "Identify" command works with the DIN relays after the update! You can uncomment the 'Capability Identify' lane in the driver and confirm it with your device - when sent, the relay LED should start blinking (approx 1 per second) in the next 30 seconds, then the LED will go to its previous state. If working for your as well, I will enable the Identfy command in the next driver update.
They have spent 3 days already on the Tuya hub and 2 days on Hubitat without turning off... and they're reporting power readings for me as well (voltage, at least, as I still have no load connected to them).
And yes, I confirm that identify command works properly.
Despite the serious issues we had in the beginning, these relays became quite cool little devices.
1 Like
