Since a recent update to Local Tuya, one of the blind cards I use doesn’t show the position correctly. Two blind cards are stuck on 55%, regardless of what I do.
The Tuya motors have never been good at showing their position in HA, but it seems worse now. That might be the card’s fault, so I’ll have to check around. There is a “jumbo” card that worked fine, but they just take up too much room.
@Steve61 the issue isn’t with HA or the LocalTuya plugin, it’s that the devices themselves don’t report their current position, only what it was last set at. If you manually move the blinds without using the position slider, then it’ll move but the percent_state attribute doesn’t change. You can see that using the Tuya API to poll the device status.
When I poll mine, it returns the following:
{
"result": [
{
"code": "control",
"value": "open"
},
{
"code": "percent_control",
"value": 19
},
{
"code": "percent_state",
"value": 0
},
{
"code": "control_back_mode",
"value": "forward"
},
{
"code": "work_state",
"value": "opening"
},
{
"code": "fault",
"value": 0
},
{
"code": "border",
"value": "up"
}
],
"success": true,
"t": *edited*,
"tid": *edited*
}
I think the attribute percent_state is supposed to show the current position but it never changes from 0. percent_control is what it was last set at manually using the slider. If you move the blinds without using the slider, it won’t update the percent_control value as that’s not the one being used to move the blinds.
I suspect that’s a bug on the firmware of the blinds controller side (i.e. Zemismart). I wish there was a way to test multiple firmware versions or go back to an older firmware.
Also, for those who found that the arrows are sometimes inactive when they should be active, if you press the stop button it should become active. I think that’s another issue created because of the absence of data on the current position, HA has to assume the position it’s currently in based on the last input.
Back in [quote=“donburch888, post:21, topic:320048”] I documented the dp_id’s that I found on Tuya website for my M515xxxx motor
Functions Status
dp_id dp_id code type values Status
1 1 control Enum open,stop,close stop
2 2 percent_control Integer 0-100, step 1 39
5 5 control_back_mode Enum forward,back false
7 work_state Enum opening,closing opening
12 fault Bitmap Label: motor_fault 0
16 16 border Enum up,down,up_delete,
down_delete,
remove_top_bottom down
19 19 position_best Integer 0-100, step 1 0
[/quote]
I have been afraid to use CloudCutter on it because on a couple of occasions I have had to use the Tuya phone app to reset the upper and lower limits after problems with tension on the cord. Looking again, I see now that dp_id 16 will be used to set and delete the top (up) and bottom (down) limits.
Last year I migrated from LocalTuya to TuyaLocal, including this device and stability improved - however TuyaLocal seems unable to alter the device definitions to add the other dp_ids.
I would now like to migrate this blind motor to ESPHome, and that will definitely mean loosing the ability to set top and bottom limits.
hi everyone, I encountered a problem, I have an M515EGWT when setting up via localtuya, it gives me two entities as shown in the screenshot, if I set up one of them, it turns out that it either opens but is no longer closed, or, on the contrary, closes, depending on whether the inversion is ocated, oh, I have two working ones buttons stop start up or start down but there is no third option, what could be the problem how can I configure this curtain?
