Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TuYa_cover_control: Unhandled DP #101 for _TZE200_zah67ekd #17363

Closed
pawelsky opened this issue Apr 16, 2023 · 32 comments
Closed

TuYa_cover_control: Unhandled DP #101 for _TZE200_zah67ekd #17363

pawelsky opened this issue Apr 16, 2023 · 32 comments
Labels
problem Something isn't working

Comments

@pawelsky
Copy link

What happened?

When switching the Moes AM43-0.45/40-ES-EZ(TY) cover motor between the tilt and lift mode (by pressing the SET button 5 times) I'm getting the "Unhandled DP #101" errors as on screenshots below:

  • when switching to tilt mode
    image
  • when switching to lift mode
    image

Any chance to add support for this DP?

What did you expect to happen?

I'd expect the DP #101 to be handled

How to reproduce it (minimal and precise)

Power on and bind the motor. Press the set button 5 times, observe the logs/errors

Zigbee2MQTT version

1.30.3-1

Adapter firmware version

20210708

Adapter

Itead_Sonoff_Zigbee_3.0_USB_Dongle_Plus

Debug log

No response

@pawelsky pawelsky added the problem Something isn't working label Apr 16, 2023
@Koenkk
Copy link
Owner

Koenkk commented Apr 16, 2023

To figure out what these dp means, please follow https://www.zigbee2mqtt.io/advanced/support-new-devices/03_find_tuya_data_points.html

@pawelsky
Copy link
Author

Unfortunately I do not have Tuya Zigbee Gateway, but I'd assume that value of 0 for DP 101 means the device switched to tilt mode and value of 1 means the device switched to lift mode.

I may order the gateway at some point as I'd also like to figure out the battery level and light sensor (from the solar panel) reporting for this motor. Any recommendation which one to buy (and nod spend fortune on it)? Preferably a wired one.

@pawelsky
Copy link
Author

OK, so I was able to order a cheap, used Gateway from Moes (to match the Moes branded motor I have, just in case there are any differences to regular Tuya one).

I was able to confirm that DP 101 is indeed for switching between tilt and lift mode. It is called jolcon, where jol is representing the tilt mode and con the lift mode: Here is a screenshot from Tuya IoT Platform
jolcon

I've also detected 3 more useful DPs:

  • DP 104 for the bottom limit for the motor
    Limitset
  • DP 103 for the upper limit for the motor
    ulimitset
  • DP 102 for the reset of the device settings to defaults
    reset

Please let me know if any additional information is needed

@Koenkk
Copy link
Owner

Koenkk commented Apr 19, 2023

Can you check with the following external converter: https://gist.github.com/Koenkk/12256a02e6f582e4e369014d2ff1d03b

  • save this as file next to configuration.yaml as ext_converter.js
  • add it to configuration.yaml:
external_converters:
  - ext_converter.js
  • start z2m
  • wait some time, do the new data points appear under the z2m frontend -> device -> state tab?

@pawelsky
Copy link
Author

After adding the converter and playing a bit with the motor, yes, all four DPs are visible in the State tab

state

However with the new converter it is no longer possible to change the position, reverse_direction and and motor_speed in the Exposes tab

exposes

Also the invert_cover option is now gone from the Settings (specific) tab. This is how it looed like before, without the new converter.

image

Oh, and it would be great if the 4 new DPs were modifiable from the Z2M UI.

@Koenkk
Copy link
Owner

Koenkk commented Apr 20, 2023

We will add this back later, this is just for testing the converter. I'm a bit confused the upper/lower limit is a boolean, this doesn't make sense right? (should be a numerical value?)

@pawelsky
Copy link
Author

No, it does not return any numerical value, the boolean value just informs you whether the limit has been set or not. Before the limits are set the position DP is not even returned (as the motor does not know which position of your blind to interpret as 0% and which as 100%).

The way it works in the app is that you move the blind to the end position and set the corresponding limit to true. Once you've set both of them the motor now knows where the 0% and 100% is and starts returning the position DP accordingly.

Once set it is not possible to change the limits in the app. The only way to do that is to do the factory_reset, and set everything back again. From the motor itself however you can change a single limit with a button combination so I'm guessing it should be in general possible to set single limit back to false, move to a desired position and set it back to true, but I would need to experiment with that a little once setting of these values is implemented.

BTW there are two more DPs:

  • 7 - representing the (previous) working state (0 for opening and 1 for closing)
  • 105 - representing the motor_speed (numerical value representing RPMs)

I've added them to the converter file you provided and they are nicely updated on the Exposes tab

const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const extend = require('zigbee-herdsman-converters/lib/extend');
const ota = require('zigbee-herdsman-converters/lib/ota');
const tuya = require('zigbee-herdsman-converters/lib/tuya');
const utils = require('zigbee-herdsman-converters/lib/utils');
const globalStore = require('zigbee-herdsman-converters/lib/store');
const e = exposes.presets;
const ea = exposes.access;

const definition  = {
    fingerprint: [{modelID: 'TS0601', manufacturerName: '_TZE200_zah67ekd'}],
    model: 'TS0601_cover_custom',
    vendor: 'TuYa',
    description: 'Curtain motor/roller blind motor/window pusher/tubular motor',
    fromZigbee: [tuya.fz.datapoints],
    toZigbee: [tuya.tz.datapoints],
    exposes: [
        e.cover_position().setAccess('position', ea.STATE_SET),
        exposes.enum('work_state', ea.STATE_SET, ['opening', 'closing').withDescription('Last working state'),
        exposes.enum('reverse_direction', ea.STATE_SET, ['forward', 'back']).withDescription('Reverse the motor direction'),
        exposes.numeric('motor_speed', ea.STATE_SET).withValueMin(0).withValueMax(255).withDescription('Motor speed'),
        exposes.enum('mode', ea.STATE_SET, ['tilt', 'lift']).withDescription('Mode'),
        exposes.binary('factory_reset', ea.STATE_SET, true, false).withDescription('Factory reset'),
        exposes.binary('upper_limit', ea.STATE_SET, true, false).withDescription('Upper limit'),
        exposes.binary('bottom_limit', ea.STATE_SET, true, false).withDescription('Bottom limit'),

    ],
    meta: {
        tuyaDatapoints: [
            [1, 'state', tuya.valueConverterBasic.lookup({'OPEN': tuya.enum(0), 'STOP': tuya.enum(1), 'CLOSE': tuya.enum(2)})],
            [2, 'position', tuya.valueConverter.coverPosition],
            [3, 'position', tuya.valueConverter.raw],
            [5, 'reverse_direction', tuya.valueConverterBasic.lookup({'forward': tuya.enum(0), 'back': tuya.enum(1)})],
            [7, 'work_state', tuya.valueConverterBasic.lookup({'opening': tuya.enum(0), 'closing': tuya.enum(1)})],
            [101, 'mode', tuya.valueConverterBasic.lookup({'tilt': tuya.enum(0), 'lift': tuya.enum(1)})],
            [102, 'factory_reset', tuya.valueConverter.raw],
            [103, 'upper_limit', tuya.valueConverter.raw],
            [104, 'bottom_limit', tuya.valueConverter.raw],
            [105, 'motor_speed', tuya.valueConverter.raw],
        ],
    },
};

module.exports = definition;

image

@Koenkk
Copy link
Owner

Koenkk commented Apr 21, 2023

but I would need to experiment with that a little once setting of these values is implemented.

I see you added the corresponding exposes, can you try if setting them works?

@pawelsky
Copy link
Author

Only changing the state works. Setting the rest of them does not (see errors on the screenshot below)

image

@Koenkk
Copy link
Owner

Koenkk commented Apr 22, 2023

@pawelsky
Copy link
Author

No change, same errors. :(

@Koenkk
Copy link
Owner

Koenkk commented Apr 22, 2023

@pawelsky
Copy link
Author

Unfortunately that did not help either, still same errors :(

@Koenkk
Copy link
Owner

Koenkk commented Apr 23, 2023

Ah sorry, made another mistake, https://gist.github.com/Koenkk/12256a02e6f582e4e369014d2ff1d03b should do it

@pawelsky
Copy link
Author

Now all of them work except position which gives error as below
image

I've played a bit with these DPs and here are my thoughts:

  • work_state - I don't see any effect of changing it. I believe it should stay read only (or even completely removed as I'm not sure it serves any useful function)
  • mode, motor_speed, reverse direction, factory_reset - these work perfectly fine
  • bottom_limit, upper_limit- you cannot 'unset' the limit by setting their value to false, the limit still stays where it was. What you can do though is to set them to false, move the blind to a different position and set it back to true to set a limit in that new position, but you can only do that within previously defined limit range, i.e. you can only make the range narrower, not widen it. The only way to widen the range is to do a factory reset. It is worth noting that the motor seems to be smart enough to not accept upper and lower limit in the same position, upper below lower or lower above upper (it will ignore the command in such case).

I'm not sure how flexible the UI is but the way I see it for the limits is just a read-only display of the current state of the limit and a "SET" button that would send the "true" value to the motor (+plus a comment explaining that you need to do the factory reset to widen the range).

@Koenkk
Copy link
Owner

Koenkk commented Apr 23, 2023

Please test with https://gist.github.com/Koenkk/12256a02e6f582e4e369014d2ff1d03b

@pawelsky
Copy link
Author

After correcting the DP names in the key array (the linked file had still the old ones) everything except position works (I'll switch to the dev branch later and report back), but I have some suggestions:

  • instead direction I'd use the name motor_direction (to make clear that we are talking about motor rotation direction here) with values 'default' and 'reversed' as it is hard to define what 'forwards' and backwards' really means.
  • I'd add rpm units for motor_speed and % unit for position
  • regarding the limits one can't see now whether they are actually set or not. This is a critical information as without limits set you can break the blind mechanism and/or the motor itself.
  • I'd put factory reset at the bottom (i.e. jut above the LQI) as this is the 'last resort' setting. Also I'd make it more difficult to execute (e.g. is it possible to display a "Do you really want to do the factory reset?" kind of confirmation before setting it to true?) Since the factory reset also clears the limits I'm a bit worried than someone may do it by accident and destroy the mechanism next time they try to Open or Close the covers.

@pawelsky
Copy link
Author

Had some issues with switching to the latest-dev branch so I've tested position with Zigbee2MQTT Edge Add-on (which I believe is an equivalent of the dev branch) and the position setting works well. Let me know if that is enough.

Koenkk added a commit to Koenkk/zigbee-herdsman-converters that referenced this issue Apr 24, 2023
@Koenkk
Copy link
Owner

Koenkk commented Apr 24, 2023

Updated https://gist.github.com/Koenkk/12256a02e6f582e4e369014d2ff1d03b

  • position unit is added in latest-dev

is it possible to display a "Do you really want to do the factory reset?

  • this is currently not possible, I've moved it to the bottom.

Let me know if everything is OK then I will merge it.

@pawelsky
Copy link
Author

The strings in 'key' array are still incorrect.

Regarding limit setting I have the following proposal (similar to mobile app behavior). The value is displayed as boolean, but when setting (regardless of which value is chosen) it will be always set to true.

changes to the valueConverter

const valueConverter = {
    setTrue: {
        to: (v) => true,
        from: (v) => v,
    },
};

changes to exposes

        exposes.binary('set_upper_limit', ea.STATE_SET, true, false).withDescription('Set the upper limit, to reset limits use factory_reset'),
        exposes.binary('set_bottom_limit', ea.STATE_SET, true, false).withDescription('Set the bottom limit, to reset limits use factory_reset'),

Not sure if that is 100% correct (not an expert in JS, doing some guesswork here) but it works for me - it displays the current state (which was missing) and always sets the value to true.

image

The only thing I'd change would be to make the value read only when it is true, but I don't know how to do that. That would be the exact copy of the mobile app behavior.

@Koenkk
Copy link
Owner

Koenkk commented Apr 25, 2023

The strings in 'key' array are still incorrect.

Will fix this once it's integrated

The only thing I'd change would be to make the value read only when it is true,

We cannot make it readonly in the UI, what we can do is throw an error when false is set:

const valueConverter = {
    setTrue: {
        to: (v) => {
              if (v) return true;
              else throw new Error('Limit cannot be unset, use factory_reset')
        },
        from: (v) => v,
    },
};

@pawelsky
Copy link
Author

That did the trick. I think it is ready to be integrated.

Koenkk added a commit to Koenkk/zigbee-herdsman-converters that referenced this issue Apr 27, 2023
@Koenkk
Copy link
Owner

Koenkk commented Apr 27, 2023

Great, integrated!

Changes will be available in the dev branch in a few hours from now. (https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html)

@Koenkk Koenkk closed this as completed Apr 27, 2023
@pawelsky
Copy link
Author

I can see the set_upper_limit and set_bottom_limit are still ea.SET only, not ea.STATE_SET, so the current state is not really visible. Was it intentional or an omission?

Koenkk added a commit to Koenkk/zigbee-herdsman-converters that referenced this issue Apr 29, 2023
@Koenkk
Copy link
Owner

Koenkk commented Apr 29, 2023

nope, fixed!

@pawelsky
Copy link
Author

Great, thanks! Would you also mind adding a picture for this device. I've prepared a TS0601_cover_4.jpg (150px x 150px) for your convenience:

TS0601_cover_4

@Koenkk
Copy link
Owner

Koenkk commented Apr 29, 2023

Thanks, will do that (with the next release on 1 May)

@pawelsky
Copy link
Author

pawelsky commented May 1, 2023

nope, fixed!

I'm afraid the newly released 1.30.4 version still has the limit DPs set as enum rather then the binary.

@bachoo786
Copy link

nope, fixed!

I'm afraid the newly released 1.30.4 version still has the limit DPs set as enum rather then the binary.

1.30.4 has messed up the cover/blinds with homeassistant to be fair :(

@pawelsky
Copy link
Author

pawelsky commented May 9, 2023

1.30.4 has messed up the cover/blinds with homeassistant to be fair :(

You mean for the Moes motors, or in general? The Moes motors seem to work for me.

@reaper7
Copy link

reaper7 commented May 10, 2023

1.30.4 has messed up the cover/blinds with homeassistant to be fair :(

#17621

@bubez81
Copy link

bubez81 commented Nov 29, 2023

hello! What about the battery state?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
problem Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants