search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.89k stars 498 forks source link

MoesGo (Tuya) Smart Thermostat BRT-100 #5153

Closed alinfulgusin closed 2 years ago

alinfulgusin commented 3 years ago

Device

Screenshots

https://zigbee.blakadder.com/Beca_BRT-100.html https://www.amazon.de/-/en/Thermostat-Operated-Radiator-Regulator-Compatible/dp/B0972YM58R/ref=sr_1_5?dchild=1&keywords=heizk%C3%B6rperthermostat+moesgo&qid=1626946864&sr=8-5

Basic

Identify

Alarms

Device Temperature

Groups

Scenes

On/Off

Level Control

Color Control

Simple Metering

Diagnostics

Other clusters that are not mentioned above

Smanar commented 2 years ago

But this part need to be used first, no ?

        for hass_hvac_mode, device_mode in self._hvac_modes.items():
            if self._device.mode == device_mode:
                return hass_hvac_mode

Or self._hvac_modes.items() don't have all possibles mode ? (As previosuly this device don't support "mode")

EmJay276 commented 2 years ago

Hi, yes this part is used first, but therefore the state: on is not used by HA. If the mode is auto the mode will stay auto despite heating is on or not. Im not sure if this intended by HA or if the mode should switch to "heating" if the device is heating and then back to auto if its currently not heating but will if the temperature gets to low. I will look at some other devices how they are implemented and then make some changes in my fork and inform you when I'm done.

EmJay276 commented 2 years ago

Having a look at https://developers.home-assistant.io/docs/core/entity/climate/#hvac-modes and https://developers.home-assistant.io/docs/core/entity/climate/#hvac-action we should probably reconfigure the device and HA like this:

HVAC modes: Device: mode: manual <=> HA: HVAC_MODE_HEAT Device: mode: auto <=> HA: HVAC_MODE_AUTO Device: off ("OF" == 5°C) <=> HA: HVAC_MODE_OFF

HVAC Action Device: valve is open => HA: CURRENT_HVAC_HEAT Device: valve is closed => HA: CURRENT_HVAC_IDLE

Presets​ Device: boosts <=> HA: preset: BOOST Device: mode: holiday <=> HA: preset: AWAY + HA: HVAC_MODE_AUTO

But the hvac actions (CURRENT_HVAC_HEAT / CURRENT_HVAC_IDLE) seems not supported from the current deconz climate plugin https://github.com/home-assistant/core/blob/dev/homeassistant/components/deconz/climate.py

EmJay276 commented 2 years ago

I created a pull request (https://github.com/Smanar/deconz-rest-plugin/pull/106) for the changes I suggested above. It's working fine for me.

I'm also added the CURRENT_HVAC_HEAT and CURRENT_HVAC_IDLE to the deconz HA plugin to see the current state of heating (https://github.com/home-assistant/core/pull/59989), sems to work locally for me with simple thermostats (only on off mode) and thermostats with 3 modes like this one.

The only thing im not completely happy about is the doubling between mode and preset of "auto" and "manual", but the presets "auto" and "manual" are always there for deconz Thermostats in HA, so it would be inconsistent not to use them.

Smanar commented 2 years ago

Thx, I have merged the file.

I m lost whith this changes ^^. But if it work, perfect for me, you are faster than me to test code modification. I just hope the code will be compatible for future clone.

he only thing im not completely happy about is the doubling between mode and preset of "auto" and "manual"

Yeah same, but I realy don't see how to do. the better solution will a be a specific combinaison by device, but not possible as deconz try to use a generic method.

I can make the PR, if all is fine.

But seriously I think it will be hard for validation as it, I think the code will be used to set a future DDF. You are able to compile it to use with HA on your side ?

EmJay276 commented 2 years ago

I am already using it with my HA, I will test it for some more days and report if anything does not behave as intended.

Smanar commented 2 years ago

NP, have made the PR to not forget it https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5500

EmJay276 commented 2 years ago

Just a short report - everything is working fine.

I've added a total number of 6 BRT-100 devices to my Deconz/HA without any problems. One of them is running live with an automation in HA for more than two days without any issue.

I had to reconnect all of them a second time, but thats probably related to me bulding a new deconz plugin within 2 hours for 20 times^^

To get corrects readings/view in HA, you need to change modes and temperatur setting / reading after connecting them for one time by hand and reload the deconz plugin in HA (change null values to something else). But thats not device related.

tukestolo1 commented 2 years ago

Guys congrats for the amazing job. It will do me a lot of good too. If they think this cool merge it please , so I can test it on my Homeassistant

EmJay276 commented 2 years ago

I noticed we forgot to implement the childlock reporting from the device, done here: https://github.com/Smanar/deconz-rest-plugin/pull/107

device => HA is working / tested

HA => device I can not test, don't know how to send from the HA UI "config: locked: true/false" If anyone can tell me how to send an event to the device from the "developer-tools/event" page in HA I will test it. But looking at (https://github.com/EmJay276/deconz-rest-plugin/blob/beed56d61688cacc1f01b0f63675d10df21b6aa4/rest_sensors.cpp#L1447-L1450) seems for me fine without need of testing.

EmJay276 commented 2 years ago

I also noticed some inconsistencies for rare case combinations, for example:

I will try to implement them within the next days, should be quite easy but lot of testing for rare case combinations

Smanar commented 2 years ago

Lol. Welcome in tuya world.

Have added your PR for the part for childlock in tuya file, for HA == > device the code was already in place

                        else if (R_GetProductId(sensor) == QLatin1String("Tuya_THD BRT-100"))
                        {
                            dpIdentifier = DP_IDENTIFIER_THERMOSTAT_CHILDLOCK_4;
                        }

Can use direclty the API to test it or curl command.

curl -H 'Content-Type: application/json' -X PUT -d '{"locked": true}' http://IP:PORT/api/APIKEY/sensors/ID/config

EmJay276 commented 2 years ago

Thanks, the curl works for me, now I can proberly test it! 👍

There was a line missing for the childlock 😅 and I already added the mode/preset change (like the device does) https://github.com/Smanar/deconz-rest-plugin/pull/108 . mode: auto AND preset: auto + temperature change => mode: heat AND preset: manual

I also found the offset setting for the device (0x02,0x69), I will implement it within the next days and then create a PR.

19:25:28:260 Tuya debug 5 : Status: 0 Transid: 125 Dp: 617 (0x02,0x69) Fn: 0 Data 4294967295    // Offset: -1
19:25:46:290 Tuya debug 4 : Address 0x84FD27FFFE8AEB89 Payload 007d69020004fffffffe
19:25:46:290 Tuya debug 5 : Status: 0 Transid: 125 Dp: 617 (0x02,0x69) Fn: 0 Data 4294967294    // Offset: -2
19:26:46:402 Tuya debug 5 : Status: 0 Transid: 127 Dp: 617 (0x02,0x69) Fn: 0 Data 0     // Offset: 0

There is also a schedule possible (for auto mode), if you have an example of another device how the result should look like in the json, I can try to implement it. But not sure if it is worth the time, it's not used in HA.

Smanar commented 2 years ago

I also found the offset setting for the device (0x02,0x69), I will implement it within the next days and then create a PR.

No, pls, there is another PR for offset, better to use this one https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5501 , more advanced.

The shedule too is on another PR, but I need to check the synthax for this one (will do that tommorow)

The other is aleady merged thx ^^.

But not sure if it is worth the time, it's not used in HA.

Nope, not yet, honneslty I have already started lot of shedule code, but never finished one.

Smanar commented 2 years ago

Ok, so I haven't found information about the schedule on this device. Can you try to set one manualy and share the log ? (shedule log are special, there is a special log for them)

Edit:

Have find it

define DP_IDENTIFIER_THERMOSTAT_SCHEDULE_1 0x65 // Moe thermostat W124 (4) + W002 (4) + W001 (4)

IDK if it still working, but it s already in code

EmJay276 commented 2 years ago

@Smanar I added the missing temperatur offset for this device not included in https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5501 and fixed a bug I noticed with resetting the boosting preset. See https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5701

Smanar commented 2 years ago

Ha nice thx. But I think here

                       if (productId == "Tuya_THD BRT-100") // temperature calibration (offset in degree) for Moes Tuya BRT-100
                        {
                            qint16 temp = static_cast<qint16>(data & 0xFFFF) * 100;
                            ResourceItem *item = sensorNode->item(RConfigOffset);

                            if (item && item->toNumber() != temp)
                            {
                                item->setValue(temp);
                                Event e(RSensors, RConfigOffset, sensorNode->id(), item);
                                enqueueEvent(e);
                                update = true;
                            }
                        }

Better to use something like "offset" instead of "temp"

EmJay276 commented 2 years ago

Changed it, thanks for mentioning!

nukleuz80 commented 2 years ago

Hey guys,

i‘m on 2.13.4 and paired the brt-100 succesfully. I include it twice but see only the sensor Not the light in API.

Is this correct?

thanks

EmJay276 commented 2 years ago

Hi, yes there is only a sensor in the API, looking like this (probably with the offset set to 0, its not rolled out yet)

    "4": {
        "config": {
            "battery": 86,
            "heatsetpoint": 2000,
            "locked": false,
            "mode": "heat",
            "offset": -200,
            "on": true,
            "preset": "manual",
            "reachable": true,
            "schedule": {},
            "schedule_on": false,
            "setvalve": false,
            "windowopen_set": false
        },
        "ep": 1,
        "etag": "f19e267a738408917fb052d859466d59",
        "lastannounced": "2022-01-31T08:15:02Z",
        "lastseen": "2022-01-31T08:15Z",
        "manufacturername": "_TZE200_b6wax7g0",
        "modelid": "TS0601",
        "name": "Thermostat 4",
        "state": {
            "lastupdated": "2022-01-31T10:40:17.350",
            "lowbattery": false,
            "on": false,
            "temperature": 2000,
            "valve": 0
        },
        "type": "ZHAThermostat",
        "uniqueid": "84:fd:27:ff:fe:8a:e4:03-01-0201"
    },
nukleuz80 commented 2 years ago

OK, thanks a lot - i see a different value by valve - why is my value 5 - it has to be 0 because it is off... (?)

{ "config": { "battery": 100, "heatsetpoint": 1500, "locked": false, "mode": "heat", "offset": 0, "on": true, "reachable": true, "schedule": {}, "schedule_on": false, "windowopen_set": false }, "ep": 1, "etag": "6eb2d55ddceb3984c479ed5b9394ac6d", "lastannounced": "2022-01-31T10:53:07Z", "lastseen": "2022-01-31T10:54Z", "manufacturername": "_TZE200_b6wax7g0", "modelid": "TS0601", "name": "Thermostat 118", "state": { "lastupdated": "2022-01-31T11:06:59.510", "lowbattery": false, "on": false, "temperature": 1900, "valve": 5 }, "type": "ZHAThermostat", "uniqueid": "84:fd:27:ff:fe:8a:ec:11-01-0201" }

EmJay276 commented 2 years ago

You mean the "valve" value? I noticed it is not always probably sent from the device. But it doesn't matter (and nothing we can do about).

The state "on" is "false", so it is correct reporting the device is off 👍

nukleuz80 commented 2 years ago

Yes, i mean valve.

Thank you man 👍