Unavailable Zigbee subdevice entities with Zemismart M1 hub (protocol 3.5)

[shift-del1]

Tried with latest stable (3.2.1) and beta (3.2.2b4). Hub and sub-devices are visible:

DPs also available (this is from beta, DP4 is not available for this brand (Siterwell GS361A-H04)):

Not sure if I chose the right DP for DP ID (as they are later it is used for target temperature too)

Dashboard shows as unavailable:

If I connect this TRV to Zigbee2MQTT, it works:

Changing modes (written in bold on the screenshots) also work (so DP4 is available through Zigbee2MQTT):

Tried a different TRV (same brand) in Local Tuya, it is better:

but whatever I try to set, it is always in Fahrenheit, not Celsius. Plus despite having DP4, the modes are not properly used (not as the other type TRV in Zigbee2MQTT). I have 1 more or less working and 4 non-working TRVs (same product, but bought them from different stores and in different time).

Environment

• Localtuya version: 3.2.2b4
• Home Assistant Core version: 2023.12.1
• Home Assistant HAOS 11.2
• [] Does the device work using the Home Assistant Tuya Cloud component ? not configured
• [] Does the device work using the Tinytuya (https://github.com/jasonacox/tinytuya) command line tool ? not tested
• [] Was the device working with earlier versions of localtuya ? Which one? this is the first time I tried
• [] Are you using the Tuya/SmartLife App in parallel ? no

DP dump

"result": {
"properties": [
{
"code": "temp_set",
"custom_name": "",
"dp_id": 2,
"time": 1701969576816,
"value": 225
},
{
"code": "temp_current",
"custom_name": "",
"dp_id": 3,
"time": 1702564905972,
"value": 222
},
{
"code": "mode",
"custom_name": "",
"dp_id": 4,
"time": 1698420642280,
"value": "manual"
},
{
"code": "child_lock",
"custom_name": "",
"dp_id": 7,
"time": 1698420514201,
"value": false
},
{
"code": "window_state",
"custom_name": "",
"dp_id": 17,
"time": 1698420514361,
"value": "open"
},
{
"code": "window_check",
"custom_name": "",
"dp_id": 18,
"time": 1698420513847,
"value": true
},
{
"code": "valve_state",
"custom_name": "",
"dp_id": 19,
"time": 1701925573149,
"value": "open"
},
{
"code": "valve_check",
"custom_name": "",
"dp_id": 20,
"time": 1698420514017,
"value": true
},
{
"code": "battery_percentage",
"custom_name": "",
"dp_id": 21,
"time": 1700308343106,
"value": 100
},
{
"code": "temp_correction",
"custom_name": "",
"dp_id": 27,
"time": 1698420495759,
"value": -10
},
{
"code": "cloud_temp",
"custom_name": "",
"dp_id": 102,
"time": 1698420495759,
"value": 50
}
]
},
"success": true,

[xZetsubou]

Not quite sure why it didn't reports dp 4, However the reason it shown unknown is probably because you haven't set HVAC mode Set, it's common for both DP ID and HVAC Mode DP shares the same DP

Try this config: in 3.2.2b4

1. add DP 4 in Manual DPS you can insert 4 in Reset DP if you want to test too.
2. In climate Configuration set DP ID 4 and HVAC Mode DP 4 try HVAC SET manual/auto. rest of configs set the correct one.

TIP:
If you added the device even with wrong configuration into localtuya you can go in HA -> Developer tools -> Events -> In Event to subscribe Insert localtuya_states_update then start listening after that go to Smart Life or the device it self and change the mode or temp etc... this will reports the DP ID that changed with it value.

[shift-del1]

I tried what you suggested, creating (manual DP and reset DP) and adding DP4 to the existing configuration indeed solved the issue. However the control of this thermostat is not as smooth as the one which provides DP4 by default. If I set the HVAC mode to manual/auto, as you suggested, I see the 3 available modes (off, heat and auto, which is perfect), but only auto (which is the scheduled in Tuya Smart) and heat (manual in Tuya Smart) can be chosen, when I select off (anti-freeze in Tuya Smart), it switches back to auto, however turns down the temperature to 5°C (and Tuya Smart also shows anti-freeze, so only the visualization is not ok in HA).
1 remark, when I tried to set up a new thermostat, DP 2 and 4 were missing:

When I manually and physically adjusted the thermostat, DP 2 appeared. Could it be that it goes into an energy saving status and DP 2 is not detectable? DP 4 is a different problem, as I mentioned I bought the 5 TRVs in 2 batches and the first "test unit" has DP 4 exposed. For the rest 4 I need to manually add them after I woken them up.

2 additional things: either modifying the existing thermostat or adding a new one, whether I choose Celsius as the UoM or not, the climate entity still shows Fahrenheit. The second thing that none of the automatic configuration options work and I was not able to create a template from my configured thermostat to apply it on the remaining 4. I know this is a beta release, just wanted to highlight it :-)

[xZetsubou]

1. By default localtuya add off mode to any climate entity added so I assume your thermostat doesn't have off mode?

2. As for missing DPs I had the same issue that my motion sensor when the gateway I shutdown then turn it on. the battery DP no longer reports battery value until I re-pair the device or wait for device battery to change until it starts to report it again. doesn't always happen and not sure if this is the device or gateway issue

3. Not sure why auto configure for climates is there an error message or error in logs? However can you go to your thermostat device and download the diagnostic and post it.

Note: if you want to check the values that your device report check the tip in: #77 (comment)

Edit 2: Template seems it works fine :), maybe you need to restart HA in order for templates to show up or insert the name of template file manually are you sure after saving the template it doesn't appear in custom_components/localtuya/templates

[shift-del1]

1. Yes, the below modes are available (according to Tuya IoT pltform (cloud):
   {
   "code": "mode",
   "custom_name": "",
   "dp_id": 4,
   "time": 1702638886538,
   "value": "auto"
   },
   {
   "code": "mode",
   "custom_name": "",
   "dp_id": 4,
   "time": 1702638968719,
   "value": "manual"
   },
   {
   "code": "mode",
   "custom_name": "",
   "dp_id": 4,
   "time": 1702638984671,
   "value": "freeze"
   }
   What is your recommendation for this scenario?

2. I think it s normal for battery operated devices.

3. Had no time to review the logs and I will be away till Monday, but once I'm back I will check if anything is written in the log. In the meantime please find attached the diagnostic (IDs and keys removed).

localtuya-714b3d930f365ccd7c58b59f45151776-kitchen thermostat-1cc15853d166893296eda592220006f1.json.txt

4. You are right, templates are there, I was just unable to browse them (despite it says type the name if not listed...). Will give it a try also when I'm back.

5. The only issues left are: find the right HVAC mode for my thermostats, change UoM to Celsius, solve the auto configuration problem for discovered devices.

Thank you.

update: if I select Fahrenheit, values change to Celsius, but UoM stayed Fahrenheit, however the dial still looks like it is in Fahrenheit (as 20°C should be in the middle, not in the bottom left):

[xZetsubou]

Home Assistant doesn't supports any HVAC as you can see here so I would say the best way is using freeze as Cool mode OR Add it as preset <- dunno if this is fine :)

Adding a checkbox in climate configure menu to whether add OFF mode or not is the way to go I guess to remove OFF Mode.

The UoM issue you had it because your Home Assistant System unit is Fahrenheit and the device unit is Celsius.
HA -> Settings -> System -> General. check system unit.

change UoM to Celsius, solve the auto configuration problem for discovered devices.

I don't understand what do you mean by this ^^

Edit: You can update to 3.2.2b5 to test I adjust some stuff.

• Min and Max temp can be manually.
• OFF Mode is removable.

Note: that your device Auto configure didn't works OK with it maybe because DP 4 was missing. I can fix this issue but I'm still not sure if my way to fix it is the best.

[shift-del1]

As you can see from the below screenshot (from the official Tuya cloud integration), it assigns cool to freeze as you suggested:

So Auto --> Auto, Manual --> Heat, Freeze --> Cool.

As a radiator TRV can not cool, I don't really like the official implementation (not to mention that Heat/Cool is listed 3 times).

I upgraded to 3.2.2b5 and was able to remove Off, but the best would be if you could add the below option to climate.py:

    "freeze/manual/auto": {
        HVACMode.OFF: "freeze",
        HVACMode.HEAT: "manual",
        HVACMode.AUTO: "auto",
    },

as freeze is closer to OFF, than to COOL from my opinion.

Regarding Uom, you were right, I just installed my test environment and default UoM was Fahrenheit. I changed it to Celsius and now everything looks fine. I had to reboot HA and now auto configuration is working for the detected devices as well for the entities within the device (however not all of the entities were discovered, so I went the manual mode + template instead).

To sum up all: everything is working as expected, except the 3rd mode (OFF for Freeze). Thanks in advance.

[xZetsubou]

    "freeze/manual/auto": {
        HVACMode.OFF: "freeze",
        HVACMode.HEAT: "manual",
        HVACMode.AUTO: "auto",
    },

To be honest this isn't ideal for everyone use case they will get confused that "freeze is off".
The HVAC and Preset sets may need to be refactored and handled better in the future.

[shift-del1]

How about COOL instead of OFF as in official Tuya cloud integration?

[xZetsubou]

How about COOL instead of OFF as in official Tuya cloud integration?

I think it makes more sense.

[xZetsubou]

Adding more and more sets isn't the best solution by far the best solution I found is manually mapping
Something like this

[shift-del1]

You won't believe but the same idea came into my mind, but didn't want to make any trouble to you. But I agree: a list of most frequent options plus a custom option is the way to go. Thank you so much.

[xZetsubou]

3.2.4 now HVAC fields supports manually mapping, Let me know if you test it and encounter any issues.