Loratap Tuya Smart Life ZigBee 3.0 Curtain Blind Switch for Roller Shutter Electric motor

[lukinno1]

Hello this curtain switch have Zigbee protocol. Some support for deconz??

https://www.loratap.com/products/tuya-smart-life-zigbee-30-curtain-blind-switch-for-roller-shutter-electric-motor-google-home-alexa-echo-voice-control-diy

https://www.zemismart.com/products/zigbee-eu-curtain-wall-light-switch-compatible-with-smartthing-hub-echo-plus-app-phone-voice-control

Device
Screenshots

[janmo0]

I'm also interested in the Loratap device working with deconz. It looks like they are pretty much the same. But I think no one knows until someone connects it with deconz.

The Zemismart should work. At least with the next release I think See:
#2999 or https://zigbee.blakadder.com/Zemismart_ZM-CSW002-D.html

[Mimiix]

@lukinno1 I've changed your request to a User question as this is not a device request.

We need the device in order to add support for it. Without that we can't do anything 😢

As @janmo0 mentioned, the Zemismart should have a degree on support in the next beta.

[janmo0]

We need the device in order to add support for it. Without that we can't do anything 😢

Ok, I ordered one to investigate. But need to wait at least 1 month for arrival.

As @janmo0 mentioned, the Zemismart should have a degree on support in the next beta.

You mean only basic functionality like up, down and stop?
Was already wondering how and if the set position is working?!

The only thing I could see in #2999 within the window covering cluster ist the 0x0015 and 0x0016 for 'Acceleration Time - Lift' and 'Deceleration Time - Lift' and maybe the mode on 0x0017 (which is used by the Ubisis Shutter J1 for setting the device into a configuration mode)

[Mimiix]

@janmo0 Great! Feel free to open a new device request issue when you get it!

@SwoopX might be able to answer this as he created the PR.

[SwoopX]

The only thing I could see in #2999 within the window covering cluster ist the 0x0015 and 0x0016 for 'Acceleration Time - Lift' and 'Deceleration Time - Lift' and maybe the mode on 0x0017 (which is used by the Ubisis Shutter J1 for setting the device into a configuration mode)

I don't know what you got that idea. The devices are controlled by the corresponding cluster commands, that's it. You'll probably see the lift percentage in the corresponding attribute then.

[janmo0]

I got the device today. It's working with Deconz via API or GUI.

In Phoscon its shown as:

I'm just wondering how to configure the device. Right now full open or close is around 10 seconds. What if the shade needs more or less to fully close or open?

[Smanar]

You can use the "lift" field to select the level.
Perhaps in phoscon using the brightness slider.

[cobirnm]

Maybe there is a way of entering Calibration Mode using the buttons. Has anyone been able to do it? I have the same issue.

[Smanar]

Right, I have same reaction for 2 other tuya covering. And one of them need a remote to set calibration.
without calibration the setLevel fonction don't work.

[cobirnm]

Right, I have same reaction for 2 other tuya covering. And one of them need a remote to set calibration.
without calibration the setLevel fonction don't work.

But have you been able to calibrate any of your devices?

[janmo0]

I can use the set level function without calibration on the Loratap device. But as default the device send power for 10 seconds. Or if I set to 50% then for 5 seconds.
That should be no problem for only open and close if the blinds close within 10 seconds and the motor has an mechanical or electric endstop.
But the set level function could be wrong then.

As said before, in the Ubisis Shutter J1 the 0x0017 setting is used to put the device into a configuration mode. As I read from the manual.

This is from the Loratap manual:

[cobirnm]

I can use the set level function without calibration on the Loratap device. But as default the device send power for 10 seconds. Or if I set to 50% then for 5 seconds.
That should be no problem for only open and close if the blinds close within 10 seconds and the motor has an mechanical or electric endstop.
But the set level function could be wrong then.

As said before, in the Ubisis Shutter J1 the 0x0017 setting is used to put the device into a configuration mode. As I read from the manual.

This is from the Loratap manual:

I have tried writing the 0x0017 parameter using VNC conection but I always get "writing failed". Does anyone know how can I achieve this?

[Smanar]

Right, I have same reaction for 2 other tuya covering. And one of them need a remote to set calibration.
without calibration the setLevel fonction don't work.

But have you been able to calibrate any of your devices?

Not me, but yes he do #3161 (comment)

[cobirnm]

e to calibrate any of your devices?

In this case the calibration was triggered by a RF remote control. In the case of your switch and mine (I have one branded as Losonho) it seems, by the use manual that you sent me (the one that came with mine doesn't even mention it) that the app ( tuya app) can trigger the calibration, so for sure there is some kind ok command that can be sent to do it.

The Ubisis Shutter J1 uses the 0x0017 for this, but in Deconz implementation it is created a Sensor as a workaround to trigger this. Maybe someone could change the code in order to also create this sensor for these switches and we could test. (unfortunately I don't know how to do it)

[Smanar]

On my side I have searched and I haven't see on a zigbee project some information about a zigbee "calibration" command.
In all devices, it s always build in the hardware or with a 433 mhz remote (and the app)

[cobirnm]

On my side I have searched and I haven't see on a zigbee project some information about a zigbee "calibration" command.
In all devices, it s always build in the hardware or with a 433 mhz remote (and the app)

See the pictures of the manual on the above pictuture. The user manual I received only mentions how to pair but the one @janmo0 received shows how to calibrate in Tuya app. So the zigbee command exists.

Also when I look at window_covering.cpp I can see it was created using ZigBee Home Automation Public Application Profile Document 05-3520-29. In this document you can see on page 183 that it mentions attribute 0x0017 (sorry if I'm not using the correct naming). The usage of this attribute 0x0017 has been used for the implementation of the "Ubisys Shutter Control J1". This was done by creating a sensor. Maybe this kind of workaround could be applied to all of cover devices. Unfortunately this is an idea but I don't know how to program it.

No cover devices will work out of the box without calibrating it. So I believe zigbee aliance has inserted this in their code, and I hope deconz will allow this some day!

[Smanar]

Ha right.
For my device, I don't think it will work because they are using the tuya cluster but for you why not.
Have you try with deconz ? you can set this value in the GUI, but I m not sure for the value
From actual code

            <value name="Reversed" value="0"></value>
            <value name="Calibration Mode" value="1"></value>
            <value name="Maintenance Mode" value="2"></value>
            <value name="LED feedback" value="3"></value>

But from file and your doc

• 0x0017 bitmap8, Mode (bit0=if the motor direction is reversed, bit1=the device is in calibration, bit2=maintenance mode)

So for me the calibration mode will be 0/1/0 = 2

[janmo0]

I have tried writing the 0x0017 parameter using VNC conection but I always get "writing failed". Does anyone know how can I achieve this?

Same here 😕

[Mimiix]

@janmo0 Keep clicking the buttons to keep it awake. Battery devices are sometimes annoying.

[janmo0]

@janmo0 Keep clicking the buttons to keep it awake. Battery devices are sometimes annoying.

It's no battery driven device. It's always on main voltage.

[Mimiix]

Aah, My bad then :( @janmo0

[Smanar]

I m not sure but if the device don't support this attribute, you have another message ? "Unsupported something" no ?

This value is grayed or not in the table ? have you tried to read it ?

[janmo0]

After reading the value is greyed out in the table.

[Smanar]

ok, so bad luck.
There is an user that have asked for tuya documentation, I will ask to him.

But this working mode is possible without the gateway ?
It s possible the gateway just memorise the value up and down level and make the device stop itself.

[cobirnm]

I have found this under tuya documentation

Maybe it can help!

[Smanar]

Ha nice, not usefull for you, but it seem there is an attribute 0xF000 in the windows clovering cluster

0xF000 > Tuya Private Report Attr > Window Cover Status >0/1/2 > defaut(1)

a) After the device receives the 0x00 (open) command, it will immediately report the 0 (open) state through Tuya’s private reporting attribute 0xF000, and control the curtain switch relay to keep it open; run to the curtain switch stroke position, stop the curtain switch relay, And report 1 (stop) status.

b) After the device receives the 0x01 (close) command, it immediately reports the 2 (close) state through Tuya’s private reporting attribute 0xF000, and controls the curtain switch relay to keep it off; it runs to the curtain switch stroke position and stops the curtain switch relay. And report 1 (stop) status.

c) After the device receives the 0x02 (stop) command, it immediately reports the 1 (stop) state through Tuya's private reporting attribute 0xF000.

[janmo0]

Issue with same problem on Z2M repo: Koenkk/zigbee2mqtt#4257

[Jasonthefirst]

@navterro Did you find a way to calibrate the switch?

[navterro]

@Jasonthefirst nope - still on luck. I'm thinking about ordering tuya zigbee gateway.

[Jasonthefirst]

I ordered the gateway yesterday and it should arrive tomorrow. I'll try it and can give you some feedback. I can also try to get some additional informations if someone is interested and can point me in the right directions.

[lukinno1]

It is very easy.

[navterro]

@Jasonthefirst have you manage to calibrate switch using gateway ?

[jrochate]

I'm having the same problem with _TZ3000_1dd0d5yi using ZHA (Moes Zigbee+RF).
Note that this device is a zha.DeviceType.WINDOW_COVERING_CONTROLLER and not a WINDOW_COVERING_DEVICE (This is 0x0203 and not 0x0202). Maybe that's something to consider.

I do have a RF correctly configured using the push button on device, but even when using the RF it only moves about 10 seconds. Calibration give an error like above said.

Please let us know if you found out a solution, even if used a controller to set the travel time.

Thanks.

[Smanar]

@jrochate have you tried the manipulations written on the manual ?

But I don't understand, if you have a "WINDOW_COVERING_CONTROLLER" it s a switch ? So why you have too a RF controller ? to control the switch too ?

[jrochate]

@Smanar thank you for your reply.

About the device type:

"endpoints": { "1": { "profile_id": 260, "device_type": "0x0203", "in_clusters": [ "0x0000", "0x0004", "0x0005", "0x0006", "0x0102" ], "out_clusters": [ "0x000a", "0x0019" ] } }, "manufacturer": "_TZ3000_1dd0d5yi", "model": "TS130F",

and the device type is 0x0203 that corresponds to WINDOW_COVERING_CONTROLLER on the zigbee DB.

This is a Moes Zigbee + RF Curtain Switch Module (like this: link to product)

About the RF controller

I have also a base RF command that is paired with device and can operate up/down/stop actions.
But even with RF command, the device only travels about 10 seconds (a little more).

About the calibration command

One the screenshots on the link above, one can see that calibration does take place in the App.
When I issue the calibration comand on the cluster 0xf001, I get this error:

Read attribute for: cluster_id: [258] cluster_type: [in] endpoint_id: [1] attribute: [61441] manufacturer: [None] response: [None] failure: [{61441: <Status.UNSUPPORTED_ATTRIBUTE: 134>}]

It looks like this TS130F has not implemented the calibration on the same address like the others.

[Smanar]

You don't have the cluster 0xf001 on this device, try the calibration command available on cluster 0x0102

Edit:
Ok, it s a mistake, you are using the good cluster, 0xf001 is the attribute. So yes there is a problem here ...

[jrochate]

As you can see on my last message, the cluster_id 258 is 0x0102, and the calibration_id 61441 is 0xf001

Maybe I'm stuck here and the only way is to use the App, because the product link shows a calibration method on the App.
I'm not the only one with this. I have seen several posts on the internet about the calibration not available.
I was hopping for a solution :)

[Smanar]

Sorry, I don't have more news than you, ATM the only attribute used for that is the 0xff01, and it s strange because other TS130F (like _TZ3000_vd43bbfq) are using this one ...

[jrochate]

Ok, what about this plan:

1. Buy a Tuya Zigbee controller
2. Install Tuya App
3. Pair the Moes MS-108ZR (TS130F) using the App
4. Install a Zigbee sniffer like ZShark
5. Sniff the zigbee network with ConBee II
6. Calibrate using the App
7. Check for results and find which records and Cluster Attributes were used

Sound too expensive, and I could just drop out the 3 devices :)

[Smanar]

Yeah realy expensive just for that.
You can too just wait for someone with the same stuff and a sniffer can found the attribute.
There is no other way to calibrate it, using switch or RF remote ?

[FelR]

@aelias-eu found a solution for zigbee2mqtt. Any chance we see this integrated in deconz?
Koenkk/zigbee2mqtt#7128 (comment)

[lukinno1]

@aelias-eu našiel riešenie pre zigbee2mqtt. Je nejaká šanca, že to uvidíme integrované v deconz?
Koenkk/zigbee2mqtt#7128 (komentár)

What is problem? In deconz run this device.

[FelR]

That’s the problem: #3134 (comment)
Moes seems to use a slightly different implementation than Loratap, that supports no calibration with the currently available commands

[Smanar]

Yep on your link it s the model _TZ3000_1dd0d5yi
This one use classic attribute for calibration

tuyaCalibration: { ID: 0xf001, type: dataType_1.default.enum8 },

But they are using too a new attribute

You can the set the calibration time via mqtt by sending the value in seconds via /set
{"calibration_time":5}
moesCalibrationTime: { ID: 0xf003, type: dataType_1.default.uint16 }, // aelias 20210810

Can try with editing the xml file, with something like

			<attribute id="0xf002" name="Motor Reversal" type="enum8" default="0" required="m" access="rw">
				<value name="Off" value="0"></value>
				<value name="On" value="1"></value>
			</attribute>

			<attribute id="0xf003" name="Calibration time" type="u16" default="0x0000" required="o" access="rw"></attribute>

        </attribute-set>

and set different values

[Pedder007]

Hi all,
I do have a couple of the TS130Fs (_TZ3000_ltiqubue) and was always able to calibrate the shutter moving time (via the deCONZ gui). But I see another problem with the devices, for which I have the hope on some help here.
When moving the shutter down (from 100% open) to whatever percentage, letting it alone for a while and then moving it up again, it always stops 1-2 seconds too early, means before the former 100% physical 'open'. Means the shutter switch (TS130F) seems thinking that he is up (shows 100%), but these 100% come to early. Thus the shutter motor is stopped to early and the shutter itself is physically not 100% open.
When moving it completely down (0% open) and then up again, this mistake is gone and the right full open position is reached again.

Has someone seen the same or maybe an idea whats going wrong? - in general I always calibrated the shutter switches (TS130F) in a way, that they held the up or down position 2-3 second more than the shutter motor needs for the complete movements. The motors themself have a an own stop, which assures no 'over'-movement.

[aelias-eu]

@Pedder007 what kind of blinds do you have? Because for venetian blinds, you have the tilt "function" and that consumes some time when you change direction between up and down movement. At first it will tilt the blinds and then it will start to move.

[Pedder007]

@aelias-eu, I doubt that that these shutter motors have ‚tilt‘ as they are simple shutter motors from rohrmotor24 with an electronic end-position adjustment.
They drive simple up/down shutters directly in front of the windows.

[Blobby0815]

Can try with editing the xml file, with something like

			<attribute id="0xf002" name="Motor Reversal" type="enum8" default="0" required="m" access="rw">
				<value name="Off" value="0"></value>
				<value name="On" value="1"></value>
			</attribute>

			<attribute id="0xf003" name="Calibration time" type="u16" default="0x0000" required="o" access="rw"></attribute>

        </attribute-set>

and set different values

@Smanar
If I did not miss anything none of the other "Moes Owners" (TZ3000_1dd0d5yi) replied to your post #3134 (comment) yet.
Tried it today:
Your suggested solution works perfectly with DeConz in my environment. Thank you so much!
I only changed "required" to "m".
Oh, by the way: The unit that is used for the value is "tenth of a second".

[Smanar]

Nice, thx, have just added it in this PR with the unit > #5235

[alaturqua]

Hi all, I do have a couple of the TS130Fs (_TZ3000_ltiqubue) and was always able to calibrate the shutter moving time (via the deCONZ gui). But I see another problem with the devices, for which I have the hope on some help here. When moving the shutter down (from 100% open) to whatever percentage, letting it alone for a while and then moving it up again, it always stops 1-2 seconds too early, means before the former 100% physical 'open'. Means the shutter switch (TS130F) seems thinking that he is up (shows 100%), but these 100% come to early. Thus the shutter motor is stopped to early and the shutter itself is physically not 100% open. When moving it completely down (0% open) and then up again, this mistake is gone and the right full open position is reached again.

Has someone seen the same or maybe an idea whats going wrong? - in general I always calibrated the shutter switches (TS130F) in a way, that they held the up or down position 2-3 second more than the shutter motor needs for the complete movements. The motors themself have a an own stop, which assures no 'over'-movement.

I do have the same issue on my loratap devices. SC500ZB or in Home Assistant _TZ3000_dbpmpco1. Did you find any solution or do you think there can be done anything code based in Home Assistant?

[Igor01-Tech]

Hi all, I do have a couple of the TS130Fs (_TZ3000_ltiqubue) and was always able to calibrate the shutter moving time (via the deCONZ gui). But I see another problem with the devices, for which I have the hope on some help here. When moving the shutter down (from 100% open) to whatever percentage, letting it alone for a while and then moving it up again, it always stops 1-2 seconds too early, means before the former 100% physical 'open'. Means the shutter switch (TS130F) seems thinking that he is up (shows 100%), but these 100% come to early. Thus the shutter motor is stopped to early and the shutter itself is physically not 100% open. When moving it completely down (0% open) and then up again, this mistake is gone and the right full open position is reached again.

Has someone seen the same or maybe an idea whats going wrong? - in general I always calibrated the shutter switches (TS130F) in a way, that they held the up or down position 2-3 second more than the shutter motor needs for the complete movements. The motors themself have a an own stop, which assures no 'over'-movement.

Same Here... Any News?

[Pedder007]

Nope, still the same here. Partly in summer really annoying, when it is a shutter of a garden door, which has a net against flys which is then blocked by the shutter and you have to move first completly down and up to get out 👎

[Blobby0815]

Nope, still the same here. Partly in summer really annoying, when it is a shutter of a garden door, which has a net against flys which is then blocked by the shutter and you have to move first completly down and up to get out 👎

Similar issue here. Using it for our awning and the cloth does not get pulled back into the housing completely.
Will replace this actor sooner or later.

[kababoom]

Hi all, I do have a couple of the TS130Fs (_TZ3000_ltiqubue) and was always able to calibrate the shutter moving time (via the deCONZ gui). But I see another problem with the devices, for which I have the hope on some help here. When moving the shutter down (from 100% open) to whatever percentage, letting it alone for a while and then moving it up again, it always stops 1-2 seconds too early, means before the former 100% physical 'open'. Means the shutter switch (TS130F) seems thinking that he is up (shows 100%), but these 100% come to early. Thus the shutter motor is stopped to early and the shutter itself is physically not 100% open. When moving it completely down (0% open) and then up again, this mistake is gone and the right full open position is reached again.

Has someone seen the same or maybe an idea whats going wrong? - in general I always calibrated the shutter switches (TS130F) in a way, that they held the up or down position 2-3 second more than the shutter motor needs for the complete movements. The motors themself have a an own stop, which assures no 'over'-movement.

For anyone having a calibration issue I'm posting here the above method works for TS130. In deCONZ gui turn on calibration, close your shutter all the way, turn off calibration. The Calibration time then changes, perhaps just changing this value is enough, I haven't tried.

[Pedder007]

Hi @kababoom, but I fear that doesn't solve the issue I explained. As written, calibration wasn't the issue. The issue occures later, in daily live.

Just to add here: I meanwhile switched my enviroment nearly 100% away from deCONZ/ConBee over to the ioBroker/
zigbee2mqtt adapter, using a CC2652P coordinator. But the explained issue there also stays the same. So it seems to be a problem of the devices themselves.
I fear we will have to live with it :-(

[kababoom]

Hi @Pedder007 Yes it does not solve your issue but it did solve mine. And since I found several other threads on 'how to calibrate without Hub and Tuya app' topic I posted this, perhaps it helps others.