Hi Johan Goodmorning and its good to see you again and hope everything is going well with you.
I partly using also the Universal Tuya ZigBee app from Dylan now that support some devices here.
I’m also going to try the one’s who are still not working fine or not at all to add them in yours.
Good luck and nice to see you again.
Best regards Peter.
Homey will normally choose the correct driver (if supported) even if there are more than one device looking like yours. Reason for having multiple devices is simply that Tuya implementations are anything but standard between white label brands.
Thanks! 
Hmm, as said it’s hard to troubleshoot stuff that works 
When you see anything send me a diagnostic ticket.
I understand. It’s on my to do list to wrap up what happened here and see if something is still going on.
From what I can see the TX and RX values for all Tuya based devices are WAY higher than for other Zigbee devices. This is information that we didn’t use to have. And in the Homey version where we received this update things started going south. I must admit that I was on experimental updates at the time. Since the most recent stable update there is no issue anymore and I left the experimental updates.
Having said that: the TX and RX numbers are still through the roof. Every second or so the TX and/or RX value increases by one
Together with Google Gemini I have been working for hours and hours to update the device.js in order to push how often the device pushes data to Homey, but in the end it didn’t work. It only broke reporting of power, current and voltage values entirely 
As an example: here is the wasmachine a few minutes later
Hi there, great to have you back. I have several different soil moisture meters. Some work, some don’t at all. Could you find out why? What would you need to do that? Here’s an error message I’m getting where I can’t get the device to connect. It’s listed as an Unknown Node in the Zigbee list, though.
My next question is why there are two Soil Drivers available. What’s the difference?
Thanks in advance and best regards.
_TZE284_oitavov2 |
|---|
| TS0601 |
|---|
If those are smart plugs with power measuring capabilities, then I can understand why the RX count would be high. As the A/V/W-values may change frequently, which the plug then reports back to Homey. Not sure what the reporting interval is though in your case.
What I find strange is that you have such a high TX value (and corresponding error rate). Why is Homey sending so many commands to the smart plug?
If I look at my INNR smart plugs, only 1 command (TX) is recorded when switching on the plug. Then only the RX count is updated when power measurement values change (every 1-2 seconds but only if changed). When I switch off the plug, again 1 TX command is recorded.
Yes, they are smart plugs with power measuring capabilities. I have set the polling interval to 60 seconds. Have tried 3600 seconds too. But that is how often Homey reaches out to the device, right?
There was no setting to adjust how often or what threshold should be applied for sending data from the device to Homey. I tried to add that and failed. I was able to push some changes to the plugs but then they stopped sending those updates all together. Google Gemini told me that the Tuya plugs out of the box send way too many messages.
TX is a polling message from Homey? RX is a message received by Homey?
Yes, as far as I know. TX also includes commands, like switch on/off, set dim level, etc (see this post for more details).
What happens if you set higher min report times for the device in settings?
Hi Johan, I added my LCD Temp & Humidity sensor _TZE200_vvmbj46n TS0601 into Homey again but still no Battery readings there, see screenshot. Device has 3 x AAA batteries.
"ids": {},
"endpoints": {
"ieeeAddress": "a4:c1:38:88:b9:00:41:69",
"networkAddress": 39475,
"modelId": "TS0601",
"manufacturerName": "_TZE200_vvmbj46n",
"endpointDescriptors": [
{
"status": "SUCCESS",
"nwkAddrOfInterest": 39475,
"_reserved": 20,
"endpointId": 1,
"applicationProfileId": 260,
"applicationDeviceId": 81,
"applicationDeviceVersion": 0,
"_reserved1": 1,
"inputClusters": [
4,
5,
61184,
0
],
"outputClusters": [
25,
10
]
}
],
"deviceType": "enddevice",
"receiveWhenIdle": false,
"capabilities": {
"alternatePANCoordinator": false,
"deviceType": false,
"powerSourceMains": false,
"receiveWhenIdle": false,
"security": false,
"allocateAddress": true
},
"extendedEndpointDescriptors": {
"1": {
"clusters": {
"groups": {
"attributes": [
{
"acl": [
"readable",
"reportable"
],
"id": 0,
"dataTypeId": 24,
"name": "nameSupport",
"value": {
"type": "Buffer",
"data": [
0
]
},
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 65533,
"dataTypeId": 33,
"name": "clusterRevision",
"value": 2,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
}
]
},
"scenes": {
"attributes": [
{
"acl": [
"readable",
"reportable"
],
"id": 0,
"dataTypeId": 32,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 1,
"dataTypeId": 32,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 2,
"dataTypeId": 33,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 3,
"dataTypeId": 16,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 4,
"dataTypeId": 24,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 65533,
"dataTypeId": 33,
"name": "clusterRevision",
"value": 2,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
}
]
},
"basic": {
"attributes": [
{
"acl": [
"readable",
"reportable"
],
"id": 0,
"dataTypeId": 32,
"name": "zclVersion",
"value": 3
},
{
"acl": [
"readable",
"reportable"
],
"id": 1,
"dataTypeId": 32,
"name": "appVersion",
"value": 72
},
{
"acl": [
"readable",
"reportable"
],
"id": 2,
"dataTypeId": 32,
"name": "stackVersion",
"value": 0
},
{
"acl": [
"readable",
"reportable"
],
"id": 3,
"dataTypeId": 32,
"name": "hwVersion",
"value": 1
},
{
"acl": [
"readable",
"reportable"
],
"id": 4,
"dataTypeId": 66,
"name": "manufacturerName",
"value": "_TZE200_vvmbj46n"
},
{
"acl": [
"readable",
"reportable"
],
"id": 5,
"dataTypeId": 66,
"name": "modelId",
"value": "TS0601"
},
{
"acl": [
"readable",
"reportable"
],
"id": 6,
"dataTypeId": 66,
"name": "dateCode",
"value": ""
},
{
"acl": [
"readable",
"reportable"
],
"id": 7,
"dataTypeId": 48,
"name": "powerSource",
"value": "battery"
},
{
"acl": [
"readable",
"writable",
"reportable"
],
"id": 65502,
"dataTypeId": 32
},
{
"acl": [
"readable",
"reportable"
],
"id": 65533,
"dataTypeId": 33,
"name": "clusterRevision",
"value": 2
},
{
"acl": [
"readable",
"reportable"
],
"id": 65534,
"dataTypeId": 48,
"name": "attributeReportingStatus",
"value": "PENDING"
},
{
"acl": [
"readable",
"reportable"
],
"id": 65506,
"dataTypeId": 32
},
{
"acl": [
"readable",
"reportable"
],
"id": 65507,
"dataTypeId": 72
}
]
}
},
"bindings": {
"ota": {},
"time": {
"attributes": [
{
"acl": [
"readable"
],
"id": 65533,
"dataTypeId": 33,
"name": "clusterRevision",
"value": 1
}
]
}
}
}
}
}
Thanks already for looking into this with best regards Peter.
I know that post I was involved in that part as well I don’t know why Homey would send waaaaaay more messages to Tuya Zigbee devices than others. Only explanation could be that it is sending acknowledgements.
They’re set to 300. Which is 5 minutes. So, it doesn’t really clarify the increase, right? I can adjust some and set them to 3600
Ah sorry, did not see that 
.
I don’t know why the Tuya plugs have that behavior. I have two plugs from Adurosmart Eria and they have a similar behavior, though not as extreme as yours: Homey sends a message approx. every 30 secs. I assume this behavior is either triggered by the app or part of how the firmware of the device works. But it’s really a black box (at least for me).
Done and in the 20 minutes since posting all three of them have 30 more TX and RX messages
Hi Rudi,
Just fyi:
I happen to use a dozen of _TZ3000_gjnozsaz measuring plugs as well, but used with zigbee2mqtt. I don’t see any network flooding. Sometimes they don’t report for a minute.
I did not change any default setting like debounce or minimum_report interval.
See screenvid here
The only excessive flooding Tuya device is the PJ-1203A dual power measurer w. clamps, even when the clamps are unused.
Thanks for sharing, Peter!
As I understood, if I were to add a Tuya Zigbee hub and add these Tuya Zigbee devices to the Tuya official app rather than to the Tuya Zigbee app (like I do with my Tuya WiFi devices) the excessive messages would either be caught by the Tuya Zigbee hub or the Tuya Zigbee hub would be able to “silence” the devices a little bit. But I want to limit the number of hubs…that’s why I picked the Homey Pro, right? So, I don’t see it as a real solution. And again: currently there is no real issue other than me thinking here is quite a lot more traffic on my 2.4 Ghz network than needed.
This is why I was so interested in which way this communication goes and what causes this communication. And since it only happens with Tuya Zigbee devices, I am tempted to think it is caused by the Tuya devices and not by my Homey Pro
Hi again.
I notice the driver polls for data quite ineffective.. I’ll have a go at streamlining it once the latest test version has been published as Live.
That would be great! Did you also add some new devices? Otherwise I will download it and make my own version with the added devices
Repo at Github is updated with a few new devices and ~20 new ID’s.
I will first wait if you find something for all of those messages
Hello Johan.
Is it possible to include:
BSEED 2 buttons wall switch zigbee with nuetral _TZ3000_l9brjwau_TS002and the
BSEED 3 buttons wall switch zigbee with neutral _TZ3000_qkixdnon_TS003?
