Open ElCaplar opened 3 months ago
Similar issue was described here: https://github.com/Koenkk/zigbee2mqtt/issues/23277 but there they mention HA as a buggy, once you say that downgrade of Z2M helps.
I have the same problem after update z2m
I have the same problem with two Moes TS130F (_TZ3000_1dd0d5yi) devices. Shutters are open - HA shows closed and vice versa. Connection correct - hardware buttons work. Two are partially not working and two without any issues. Sometimes I have to press the switch three times for the shutter to close / open completely. It behaves very strangely and is annoying.
{ "calibration": "ON", "calibration_time": 19, "linkquality": 69, "motor_reversal": "OFF", "moving": "STOP", "position": 0, "state": "CLOSE", "update": { "installed_version": 71, "latest_version": 71, "state": "idle" } }
Are they open or closed with "position": 0, "state": "CLOSE"
?
Are they open or closed with
"position": 0, "state": "CLOSE"
?
In this state, the roller shutter is completely open. In the “open” state, the roller shutter is closed. However, the switches function correctly.
@eerguen fixed!
Changes will be available in the dev branch in a few hours from now.
Hey... After the newest update my cover status is shown incorrectly :( before the update my moes roller shutters works perfectly fine. HA is showning closing but in truth it is opening in this moment. Motor Revese does not change it.
Same happen to me, after I updated today's version.
Model zb TS130F Manufacturer zb _TZ3000_1dd0d5yi Manufacturer Moes Model MS-108ZR
I have the same issue after updating to Z2M 1.41.0. It was always working perfectly with the Moes MS-108ZR and Z2M 1.40.2 (and all earlier versions) and since the update to 1.41.0 the cover status is incorrect. I seems that only the MS-108ZR shutter switches are affected. Other TS130F shutter switches in my setup are still working correctly (also after the update to 1.41.0).
Well, same issue on my side with 4 MS-108ZR. Back to normal when reverting back to 1.40.2-1
Same here for _TZ3000_1dd0d5yi
. They used to work as expected.
After the update, I had to enable the invert mode for them work as expected again. However, now my physical controls are inverted and I will need to rewire 😞.
Other TS130F shutter switches in my setup are still working correctly (also after the update to 1.41.0).
@rogervdh, can you share the "Zigbee manufacturer" for the shutters that don't work and the ones that work?
I have the suspicion that _TZ3000_1dd0d5yi
are broken with the update but others might be ok.
Other TS130F shutter switches in my setup are still working correctly (also after the update to 1.41.0).
@rogervdh, can you share the "Zigbee manufacturer" for the shutters that don't work and the ones that work?
I have the suspicion that
_TZ3000_1dd0d5yi
are broken with the update but others might be ok.
@afharo, TS130F Moes switch which doesn't work correctly since 1.41.0:
Zigbee Model TS130F Zigbee Manufacturer _TZ3000_1dd0d5yi Description Zigbee + RF curtain switch module
Other TS130F switches which are still working correctly:
Zigbee Model TS130F Zigbee Manufacturer _TZ3000_ltiqubue Description Curtain/blind switch
Zigbee Model TS130F Zigbee Manufacturer _TZ3000_qqdbccb3 Description Curtain/blind switch
Can you provide the data/database.db entry of _TZ3000_1dd0d5yi
and indicated wether the state is inverted with 1.41.0 or not?
@Koenkk FWIW, with my _TZ3000_1dd0d5yi
fully open on 1.41.0:
$ cat database.db | jq 'select(.ieeeAddr == "0x540f57fffe896eab")'
{
"id": 28,
"type": "Router",
"ieeeAddr": "0x540f57fffe896eab",
"nwkAddr": 29337,
"manufId": 4098,
"manufName": "_TZ3000_1dd0d5yi",
"powerSource": "Mains (single phase)",
"modelId": "TS130F",
"epList": [
1
],
"endpoints": {
"1": {
"profId": 260,
"epId": 1,
"devId": 515,
"inClusterList": [
0,
4,
5,
258,
6
],
"outClusterList": [
25,
10
],
"clusters": {
"genBasic": {
"attributes": {
"65503": "�\u0010�.\u0016",
"65506": 31,
"65508": 0,
"modelId": "TS130F",
"manufacturerName": "_TZ3000_1dd0d5yi",
"powerSource": 1,
"zclVersion": 3,
"appVersion": 71,
"stackVersion": 0,
"hwVersion": 1,
"dateCode": ""
}
},
"closuresWindowCovering": {
"attributes": {
"moesCalibrationTime": 280,
"tuyaMovingState": 1,
"currentPositionLiftPercentage": 100,
"tuyaMotorReversal": 0,
"tuyaCalibration": 0
}
},
"genOnOff": {
"attributes": {
"20480": 0,
"tuyaBacklightSwitch": 0
}
}
},
"binds": [],
"configuredReportings": [],
"meta": {}
}
},
"appVersion": 71,
"stackVersion": 0,
"hwVersion": 1,
"dateCode": "",
"zclVersion": 3,
"interviewCompleted": true,
"meta": {},
"lastSeen": 1730708760400
}
$ cat state.json | jq '."0x540f57fffe896eab"'
{
"calibration_time": 28,
"moving": "STOP",
"position": 100,
"motor_reversal": "OFF",
"linkquality": 255,
"state": "OPEN",
"update": {
"state": "idle",
"installed_version": 71,
"latest_version": 71
},
"update_available": false,
"calibration": "ON"
}
$
Reverting back to 1.40.2-1 (without moving the cover manually or through HA). Shown as open
in HA:
$ cat database.db | jq 'select(.ieeeAddr == "0x540f57fffe896eab")' | diff - 1410_db_open
73c73
< "lastSeen": 1730709188731
---
> "lastSeen": 1730708760400
$ cat state.json | jq '."0x540f57fffe896eab"' | diff - 1410_state_open
4c4
< "position": 0,
---
> "position": 100,
7c7
< "state": "CLOSE",
---
> "state": "OPEN",
After pressing open
in Z2MQTT (did nothing as the cover was already opened):
$ cat state.json | jq '."0x540f57fffe896eab"' | diff - 1410_state_open
$
Same for me, after the update: When it's closed, I get the following states: { "calibration": "ON", "calibration_time": 47, "last_seen": "2024-11-04T16:13:41.251Z", "linkquality": 43, "motor_reversal": "OFF", "moving": "STOP", "position": 100, "state": "OPEN" } I had to enable the invert mode for them work as expected again but I need to change all my automations.
Hello, I’m also having the same issue with the 1.41.0-1 update. The cover’s state appears inverted; when it’s closed, it shows as open. The open and close buttons work correctly. I have the Moes MS-108ZR model. I have returned to the previous version of zigbee 2 Mqtt and everything is correct.
Seems to be the same issue as this one #23277
Hello, in the latest version 1.41 the MOES MS-108ZR device does not work correctly. When it is closed it appears open and vice versa. I have gone back to the previous version and it works fine again.
I think it was fixed in https://github.com/Koenkk/zigbee2mqtt/issues/23483 already, can you check if everything is ok with the dev branch?
I guess you meant #24609, updating the converters with this changelog: https://github.com/Koenkk/zigbee-herdsman-converters/pull/8259 🧡
The malfunction is still present. When the shutter finishes opening, it appears as closed, and conversely, when the shutter closes, it then appears as open. I reverted to version 1.39.1 to restore normal functionality. Moes MS-108ZR
@theyort did you also check thedev branch?
I think it was fixed in #23483 already, can you check if everything is ok with the dev branch?
I just tested the docker tag latest-dev
and it works for me as intended. I only own _TZ3000_1dd0d5yi
, though. So maybe owners of the other models can confirm that it still works for them in those ones.
Hello everyone,
Following an update to Zigbee2MQTT 1.39.00 , I have noticed strange behavior with some of my roller shutters (specifically those with modules recognized as TUYA-TS130F. I have 2 other MOES modules [MS-108ZR] that are working correctly).
When I fully raise the shutter, the status visible in Home Assistant is "closed" even though the shutter is open. Below is the trace from the development menu:
On zigbeemqtt interface here is :
{ "calibration": "OFF", "calibration_time": 32, "indicator_mode": "off", "linkquality": 255, "motor_reversal": "OFF", "moving": "STOP", "position": 100, "state": "OPEN" }
The shutter appears closed while it is actually open. When I click on "STOP," the status updates correctly
I am experiencing exactly the same strange behavior when I close the shutter, as it appears to be in open mode. When I use intermediate positions, there is no issue.
When i downgrade on 1.38.00 version, all is ok.
Do you have any possible solutions or workarounds for this behavior?
Originally posted by @ElCaplar in https://github.com/Koenkk/zigbee2mqtt/discussions/23480