DDF add support for Neo TS0601 #7832

ThiemeNL · 2024-07-02T20:06:59Z

Product name: Neo siren alarm with battery
Manufacturer: _TZE200_t1blo2bj
Model identifier: TS0601
Device type to add: Siren, but recognized as light

#6112 with help of @Smanar

SwoopX

Hi and thanks for the PR. Besides a couple of minors, there's 1-2 changes to be made to stay consistent with other sirens.

I'm not too sure if the would allow us to remove quite some lines of the current source code presumably dedicated only to this device, but those can also be deleted later on with a seperate PR.

devices/tuya/_TZE200_t1blo2bj_neo_siren.json

SwoopX · 2024-07-02T21:55:21Z

devices/tuya/_TZE200_t1blo2bj_neo_siren.json

+  "status": "Gold",
+  "subdevices": [
+    {
+      "type": "$TYPE_ON_OFF_LIGHT",


The type warning device would be more appropriate here

The c++ code block tuya siren (they are not using the WD IAS cluster), not possible to use warning device type.

I'm afraid I have to disagree here, at least partially. With a DDF supported device, the DDF defines what type of device it is, not the device itself anymore (meaning it's changable to your liking). So, if you make a warning device out of it, this generally allows following the expected code paths. Tuya is not blocked here per se.

In case the siren is still not able to sound up, it is more a matter of what you pass over for processing.

I was not able to make it work as a warning device. Changing it to a light was a fix for me. More info at #6112

SwoopX · 2024-07-02T21:57:54Z

devices/tuya/_TZE200_t1blo2bj_neo_siren.json

+        {
+          "name": "state/on",
+          "write": {
+            "dpid": 13,
+            "dt": "0x10",
+            "eval": "Item.val == 1 ? 1 : 0;",
+            "fn": "tuya"
+          },
+          "parse": {
+            "dpid": 13,
+            "eval": "Item.val == 1 ? 0 : 1;",
+            "fn": "tuya"
+          },
+          "default": false
+        },


None of the sirens/warning devices has this attribute and we should stay consistent as much as possible. I'd rather see the functions move up to state/alert

Same comment, not possible to use state/alert for tuya siren.

Resource item usage is not (or should not be) limited to a vendor/manufacturer, but generally usable. Therefore, the 3 possible functions define what needs to be done with sent/received data. If that cannot be ensured in this case, we might want to change the (legacy) code to allow this in future. This shouldn't be anything heretic 😂

No It's the same problem for tuya covering.
The DDF core can handle state/on for exemple but not state/open or state/alert.
The problem is not the vendor/manufacturer, but the DDF code. We have already speak about that.

This is the workround. I was not able to get it work as a warning device.

devices/tuya/_TZE200_t1blo2bj_neo_siren.json

SwoopX · 2024-07-11T20:34:38Z

Took me a while to have a closer look. Thanks for the recent changes, the majority seems to look fine. I'm afraid this PR doesn't get my vote to get merged for a couple of reasons. Let me try to explain:

The light should use state/alert as previously mentioned for consistency
In contrast to Smanar's believe that anything for Tuya is blocked, anything is workable for any device. Especially the DDF code is so rediciously simple to have all light related resource items work with DDFs that I couldn't believe it at the beginning. What is adding complexity here, admittedly, are the various Tuya hacks already in the code. This gives me the creeps and they should go as soon as possible, even with the risk of breaking stuff imho. The longer that code stays, the more difficult wil it be to remove it.
The DDF will only work for 1 of the 2 manufacturer/modelid combinations mentioned (siren usage more precisely)
For the TZE204 manufacturer, it should not be possible to sound the alarm via DDF, as the hacks prohibit that in general by tumbling down a spaghetti code rabbit hole. @ThiemeNL I assume you have the TZE200 variant? Even with that, one need to know what to put into the DDF unfortunately

Having said that, @ThiemeNL could you please let us know with which value you test state/alert? Please redo with a type other than "warning device".

Smanar · 2024-07-12T17:45:13Z

In contrast to Smanar's believe that anything for Tuya is blocked, anything is workable for any device. Especially the DDF code is so rediciously simple to have all light related resource items work with DDFs that I couldn't believe it at the beginning. What is adding complexity here, admittedly, are the various Tuya hacks already in the code. This gives me the creeps and they should go as soon as possible, even with the risk of breaking stuff imho. The longer that code stays, the more difficult wil it be to remove it.

You don't remember ? with DDF to send request (all is working for incoming request), you can use only state/on state/bri (with this PR #5868 ), not possible to use state/lift for exemple, make a try on your side on a covering, you can reverse a return but not reverse the request.
All is possible using "config" endpoint but not the "state".

And it's not locked for tuya, it's locked for ALL brands. You need to use defaut request or give up.

SwoopX · 2024-07-12T22:51:47Z

You don't remember ? with DDF to send request (all is working for incoming request), you can use only state/on state/bri (with this PR #5868 ), not possible to use state/lift for exemple, make a try on your side on a covering, you can reverse a return but not reverse the request. All is possible using "config" endpoint but not the "state".

And it's not locked for tuya, it's locked for ALL brands. You need to use defaut request or give up.

No, I indeed do not remember that one, thanks for sharing. That also finally helped me explaining why it is working at all with state/on, was about to say it's a coincidence and following the legacy code paths while using some unexplainable zigbee Tuya glitches 🙂 However, it's not here and a state change is truly used though located at a very unexpected location.

However, all this doesn't change anything on my overall position. Everything is possible with DDFs, so I'll neither go with the default requests nor will I give up. In essence, adding a single line of code would be sufficient but practically, it will be just a few more. The current state changes are created, but not set up correctly. Will raise some PRs for making sirens and covers work shortly.

github-actions · 2024-08-07T18:03:03Z

Hey @ThiemeNL, thanks for your pull request!

Tip

Modified bundles can be downloaded here.

DDB changes

Modified

tuya/_TZE200_t1blo2bj_neo_siren.json : Neo (Tuya) smart siren ❌
- Invalid enum value. Expected item from generic attributes definition, received 'config/on' - Invalid enum value. Expected item from generic attributes definition, received 'state/alarm' - The device is missing the device definition (subdevice1.schema.json) for the type "$TYPE_ALARM_SENSOR"

Validation

Caution

Some errors have been reported. Please check the error annotations here and the logs here.

_{🕜 Updated for commit 84492a2}

Zehir · 2024-08-07T18:22:34Z

Not sure what is the problem reported by the validator because the file exist. Maybe an update of the base branch could help

Added Neo (Tuya) smart siren device

732f567

ThiemeNL changed the title ~~DDF add support for Neo _TZE200_t1blo2bj~~ DDF add support for Neo TS0601 Jul 2, 2024

SwoopX requested changes Jul 2, 2024

View reviewed changes

ThiemeNL added 4 commits July 7, 2024 16:19

pr comments

6de0852

device 0x0403 to 0x0051

3899af7

using Tuya cluster 0xEF00

ace9ce9

removed state/alert from HAAlarm

e89f68b

ThiemeNL requested a review from SwoopX July 7, 2024 18:38

Replace type ZHAAlarm with correct constant

84492a2

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DDF add support for Neo TS0601 #7832

DDF add support for Neo TS0601 #7832

ThiemeNL commented Jul 2, 2024

SwoopX left a comment

SwoopX Jul 2, 2024

Smanar Jul 3, 2024

SwoopX Jul 3, 2024

ThiemeNL Jul 7, 2024

SwoopX Jul 2, 2024

Smanar Jul 3, 2024

SwoopX Jul 3, 2024

Smanar Jul 4, 2024

ThiemeNL Jul 7, 2024

SwoopX commented Jul 11, 2024

Smanar commented Jul 12, 2024 •

edited

Loading

SwoopX commented Jul 12, 2024

github-actions bot commented Aug 7, 2024

Zehir commented Aug 7, 2024

DDF add support for Neo TS0601 #7832

Are you sure you want to change the base?

DDF add support for Neo TS0601 #7832

Conversation

ThiemeNL commented Jul 2, 2024

SwoopX left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SwoopX commented Jul 11, 2024

Smanar commented Jul 12, 2024 • edited Loading

SwoopX commented Jul 12, 2024

github-actions bot commented Aug 7, 2024

DDB changes

Modified

Validation

Zehir commented Aug 7, 2024

Smanar commented Jul 12, 2024 •

edited

Loading