DDF for Moes Thermostat

[Smanar]

Long story, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/7135 It's a wall mounted Thermostat already managed by legacy code, but not the clones. Have finally found someone able to test the DDF.

• Product name: Moes Tuya Thermostat BTH-002
• Manufacturer: TZE204_aoclfnxz
• Model identifier: TS0601
• Device type : Thermostat

[manup]

Hi is this already safe to include or may it break any of the listed devices in the DDF? Reason I'm asking is that I'd like to make a small beta v2.26.0 today and then a v2.26.1 stable on Monday or Tuesday (basically just a small release cycle to get the fixes in).

[Smanar]

"manufacturername": ["_TZE200_ztvwu4nk", "_TZE204_5toc8efa", "_TZE200_5toc8efa", "_TZE200_ye5jkfsb", "_TZE204_aoclfnxz", "_TZE200_u9bfwha0"],

The one managed by the code is {"_TZE200_aoclfnxz", "TS0601", "Moes", "Tuya_THD BTH-002 Thermostat"},

So no conflict.

[manup]

There is no "read" function for tuya cluster. No report, no bind, all native, not customisable, the device make that it want when it want. It's the "working mode" for tuya, need to put 1 {"fn": "tuya"} and after only {"fn": "none"}, I have never asked why.

There is one, it is selected by {"fn": "tuya"}. It's a strange one since it can't read specific attributes but it triggers a global "report all data points". Currently one more odd thing for the Tuya read function is that it can only be executed every 15 seconds, this is a global interval, not per device! This isn't optimal since devices will fight over this slot, and some might starve.

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/0107459aa42f8ac5333c67f415e2482069e4ff79/device_access_fn.cpp#L825

So better define a read interval, note if none is given like in this case not even in the generic item (which should have one) 0 is assigned, which means read always and as soon as possible.

Which might be the cause for the hammering we see in some setups which even with 2.25.3 see higher CPU usage. I'm preparing a small PR to prevent that and change 0 values to 10 or perhaps 20 seconds to prevent hammering. But ideally items should define something useful here (at least the generic items).

[Smanar]

The read function is special and must only be specified on one item (here state/on). It doesn't actually read a single value but triggers the Tuya device to report all datapoints.

@manup So I need more explanation here, for me this line was just a "1 shoot" request to initialise the tuya stuff.

The "tuya ask all dpid" request is done periodicaly ? So it can be just disabled ? Can use just {"fn": "none"} ? As this one is useless ? The device make itself his reporting when it want. And can do that on all tuya device ?

On classic devices, the poll is a security, but on tuya cluster not sure it's usefull. Asking all dpid every 1 hour for exemple is not normal, if the device don't make report after a period it don't mean it's badly configured or don't support report/bind, but the device is dead.

And the choosed field is important too, If I put this line in a state/temperature, it's fine, there is so mcuh report for this one, but if I put it in a config/mode, it can trigger the request periodicaly for nothing.

[manup]

So I need more explanation here, for me this line was just a "1 shoot" request to initialise the tuya stuff.

It's called like a regular read function based on wherever the item to which it is bound, for example state/on, has a fresh value. Fresh here means when the item was last updated (e.g. parsed) from an incoming command of the device.

So when the refresh.interval is 84000 this would be done at most once per day.

When the read function is called the Tuya Data Query Command (0x03) is send to the Tuya cluster (0xEF00), and the device will send the reports for the data points after that (at least that's what it did when I last tested it).

Note: The same can be done manually, in the deCONZ GUI Cluster Info Panel of the Tuya specific cluster (0xEF00).

Can use just {"fn": "none"} ? As this one is useless ? The device make itself his reporting when it want. And can do that on all tuya device ?

Not sure if I understand correctly, but if you don't need the above command to trigger a report just use {"fn" : "none"}. If it is needed for the device setup (not sure?) I'd propose to add {"fn" : "tuya"} to one item but use a large refresh.interval so that it is triggered for setup and also once per deCONZ start.

And the choosed field is important too, If I put this line in a state/temperature, it's fine, there is so mcuh report for this one, but if I put it in a config/mode, it can trigger the request periodicaly for nothing.

Yes the item should be one that is updated (parsed) from the device, since fresh value timestamp comes into play here.

Of course this is all a bit of a hack :D but for now that's how it works.

[Smanar]

Not sure if I understand correctly, but if you don't need the above command to trigger a report just use {"fn" : "none"}. If it is needed for the device setup (not sure?) I'd propose to add {"fn" : "tuya"} to one item but use a large refresh.interval so that it is triggered for setup and also once per deCONZ start.

Right, can be usefull at first start. Have updated this DDF, but can be usefull on so much of them (all in fact .....)

[Finne75]

Hello, I think variant _TZE200_aoclfnxz should be added here as well, no?

[Smanar]

This one is already managed by the legacy code. So as idk how wll react the code for user that already have this device working, I have skip it.