Skip to content

Conversation

@elupus
Copy link
Contributor

@elupus elupus commented Nov 30, 2025

Proposed change

These attributes are not available on the output side, only on the input side.

This fixes warnings about direction being wrong on the onoff cluster, since
the onoff cluster was removed on the input side.

Additional information

I have tested reading of the switch_mode attribute from this, which now works as expected.

Depends on: zigpy/zha#591 to ensure the OnOff cluster does not end
up adding a switch entity.

Depends on: zigpy/zha#590 to make sure this is added as a select entity

Device diagnostics

Checklist

  • The changes are tested and work correctly
  • pre-commit checks pass / the code has been formatted using Black
  • Tests have been added to verify that the new code works
  • Device diagnostics data has been attached

These attributes are not available on the output side,
only on the input side.

This fixes warnings about direction being wrong on the
onoff cluster, since the onoff cluster was removed on the
input side.
@codecov
Copy link

codecov bot commented Nov 30, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.28%. Comparing base (35d1fc1) to head (0ad7af7).

Additional details and impacted files
@@           Coverage Diff           @@
##              dev    #4537   +/-   ##
=======================================
  Coverage   92.28%   92.28%           
=======================================
  Files         371      371           
  Lines       12158    12163    +5     
=======================================
+ Hits        11220    11225    +5     
  Misses        938      938           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@elupus
Copy link
Contributor Author

elupus commented Nov 30, 2025

@MattWestb Do you remember why you added this attributes to the output side of this cluster? The rotation events seem to come from the output cluster, but the attribute data is on the input cluster.

Feel like we should remove those attributes from the output cluster (TuyaSmartRemoteOnOffCluster)

@elupus
Copy link
Contributor Author

elupus commented Nov 30, 2025

This looks like it should not be a complete OnOff cluster on input here, since not all attributes are supported on input and we end up creating a switch entity.

@elupus
Copy link
Contributor Author

elupus commented Nov 30, 2025

This will depend on zigpy/zha#590

@MattWestb
Copy link
Contributor

Hej du glade !!

Im not one code worrier and more "copy and paste / try and fail" but we was starting with the dimmer switch that is only having the short and long press commands but it was one long road getting there.
The device is only having one EP then being paired and cant initiating the other 3. After sniffing we was finding that tuya is sending some attribute reads and the device is being initiated as one scene controller (tuya magic) (the EP1-4 is not visibly then init the device but is working so the quirk looks very strange).
Happy we was adding the light commands we was seen and also implanting the attribute for switching working more (also possible do on the device).
The was not getting group binding working and finding that tuya is doing it ad the device is one light and adding one (only the last is added s working) the device is sending light commands to light OK. The large problem was in scene mode the device need default response in wrong direction that was not possible doing in ZHA at that time > the device can waiting for DfRs but it timing out before sending sending next scene command (i think this is only one EP 2-4 and was working OK on EP1).

Next was the rotating knob that we was decoding and only adding the new commands it was sending and it was looking working OK but no deep diving so more then likely it can being in wrong direction like tuya oft have done.

In the end the deleting the On/Of in cluster so THA is not doing one light in the GUI.
First deleting the group in cluster but was finding its need it then dont support Zigbee binding and must being treated as one light.

I have one dimmer switch and one rotating knob so can doing testing and sniffing if you need more info for debugging the problem.

@MattWestb
Copy link
Contributor

MattWestb commented Nov 30, 2025

By the way if you like doing some more deep fixing it shall being possible implanting the matter switch functionality for the scene commands its sending like IKEA was doing on Symfonisk 2 and sommrig and is exposed from Dirigera (the real matter commands was implanted on one manufacture cluster then it was not on the current matters spec) as switch entrees with last status:
Symfonisk1
I also think (have not looking in the latest matter (Z)Cluster Library) Matter shall have implanted rotary sensor that can being nice for the knob.
But we shall knowing in one week then Bilresa is start selling in some regions (5 December in Sweden Austria perhaps little later for me).

Edit: Correcting my Sw gramma: Not Bilresa (Eng Car trip) then its more then one device IKEA is releasing so its shall being Bilresor !!! (Eng Car tripos)

Edit2:
Not found rotary in "Matter Device Library Specification Version 1.4.2-mve-1" but keep looking !!

@elupus
Copy link
Contributor Author

elupus commented Nov 30, 2025

Anyway you can test reading writing of the switch mode on any of the devices you have? And see if you get any data from that attribute when it's on output endpoint? I cant get that to work on any of the ts004f.

(I would like to remove it from the output cluster if possible)

@MattWestb
Copy link
Contributor

MattWestb commented Nov 30, 2025

Was reading all attributes on Clusters:
TuyaSmartRemoteOnOffCluster (Endpoint id: 1, Id: 0x0006, Type: out)
and only cluster_revision (id: 0xfffd) was returning 1 and all other none.
Then changing the "swish mode" on the device ZHA is logging:
TS004F ROK Attribute Updated event was fired so something looks being broken in current ZHA.

Edit: Writing 0 or 1 say OK but no working mod not changed on the device and no attribute changed in ZHA log.
=> 2 is giving error = OK

@elupus
Copy link
Contributor Author

elupus commented Nov 30, 2025

Good then it looks like it works same as I see it. If you also add the onoff cluster or the attribute cluster on input side it works. (The events still must be on output side)

Maybe there was some compatibility that switches direction of a cluster command that was removed (the warning that is logged).

@MattWestb
Copy link
Contributor

The TS004X devices is having the same defect (and some other tuya devices) so i think they is also have lost some functionality from ZHA but still working on the device then its possible doing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants