Support for futurehome thermostat (TS0601_TZE204_e5hpkc6d)

[Reinachan]

This PR adds basic support for the Futurehome thermostat based on the Tuya TS0601 chip.

Supports

Based on my current findings, I've been able to add support for

Setting

• target temperature
• temperature calibration
• child lock
• window detection
• turning it on/off (using system mode)
  • this is equivalent to holding the on/off button on the device, turning it entirely off
• presets
  • user
    • is equivalent to 'heat' in the futurehome app, however, this preset is used whenever the user sets a custom target temperature, so 'user' feels more accurate. It also restores the previously used user-overriden value if you select this preset
    • does not get a default icon in Home Assistant, however, "heat" does
  • home
    • gets default icon in Home Assistant
  • away
    • is equivalent to 'eco away' in the futurehome app, however, the eco part feels pointless imo.
    • gets default icon in Home Assistant when using 'away' but not for 'eco away'
  • auto
    • does not get a default icon in Home Assistant

Reading

• room temperature
• floor temperature
• current running state of the heating (idle or heat)
• the temperature sensor being used. Can only be read, not set.

Investigation

I know that most of the device settings are missing. I've picked up on some more values, but haven't quite figured out what they mean yet. I'll probably make new PRs in the future if I can figure them out.

Known Datapoints

Implemented

• 1
• 2
• 16
• 24
• 28
• 30
• 101
• 102
• 103
• 104
• 106
• 107

Unimplemented

These were not in the original implementation, however, the device reports values for them. I don't know what they are.

• 120 (number)
• 121 (number)
  • Has values like [0,0,0,228], [0,0,0,114], [0,0,0,237], [0,0,0,239]. Changes on its own. Maybe power draw?
• 122 (number)
• 123 (number)

Known Missing Functionality

• Power draw

Advanced Settings

Some of these may or may not be possible to configure through Zigbee

source (navigate to "attachments" tab and download the "user manual" pdf)

• Floor sensor type / external
  • 0: 10 kOhm | 1: 12 kOhm | 2: 15 kOhm | 3: 47 kOhm
• Max guarding temperature
  • Manual says this has to be set on the device itself, so might not be possible to implement
• Turn - 1-9°C, Standard is 2 ° C
• Calibration: -9 to + 9 ° C, Standard is 0 ° C
• Highest set point: 35-90 ° C, Standard is 35 °C
• Lowest setpoint: 0-30 ° C, Standard is 5 °C
• Home mode setpoint: The standard is 22 ° C
• Setpoint for away mode: The default is 15 ° C
• Brightness in sleep mode: 1-10, default is 1
• Open window detection: 0 = Disabled / 1 = Active

Additional Notes

I've reached out to the manufacturer about this device, and they've said they'll try to provide me with the protocol used. When I get that, I'll try to implement the missing stuff and correct anything I've potentially done wrong in a new PR

Feel free to let me know if I need to make any changes

[Reinachan]

The failing test doesn't seem related to my work. I did git checkout 512a595 (latest commit not done by me) and ran npm test there and got the same error.

Edit: npm run build works without error

[Koenkk]

Note to self; after this merge Koenkk/zigbee2mqtt.io#2282

[Reinachan]

Sorry it took some time to get back to this. Was busy.

Anyway, I've gotten most of the way there, however, there's a couple issues remaining that I can't figure out how to fix. For some reason, I can't get the hysteresis, max_temperature_protection, and sensor endpoints to work bi-directionally, despite how they work with the original implementation. Is there something I'm missing?

They can currently read incoming data, but when you try to send data, an error pops up like this

@Koenkk

[Reinachan]

Once that's fixed, I just need to remove dead code and then this should be feature-par with some improvements over the current implementation.

[Koenkk]

They need to be added to

zigbee-herdsman-converters/src/lib/tuya.ts

Line 857 in aec2760

'temperature_unit', 'temperature_calibration', 'humidity_calibration', 'alarm_switch', 'tamper_alarm_switch',

[Reinachan]

@Koenkk I think the rewrite is complete now. I'll make a separate PR later if I figure out what the other unimplemented datapoints are. I haven't gotten a response from the manufacturer yet, but they said they're going to send me the protocol eventually :)

Some things to note

1. I only have the _TZE204_e5hpkc6d model to test on, so I can't verify if this works on the other variants of this device or not. I'm assuming they work the same, but I can't guarantee it.
2. I deleted the file with the old approach and moved this all over to futurehome.ts as that seems to be their new branding and is what they use in their Zigbee device certification now.
3. I haven't tested that the changes you mentioned in your previous comment actually works on the device. I'd have to mess with my config to be able to test that in action, which I'd prefer not to. I know everything else works on my device.

I have no idea what this actually does, but the old code had it, so I included it.

whiteLabel: [
    tuya.whitelabel('Futurehome', 'Co020', 'Smart thermostat', ['_TZE200_e5hpkc6d']),
],

How this differs from the old approach (ergo, the breaking changes from a user perspective):

	Old approach	New approach
on/off state	is its own binary control	is controlled by climate system mode
device presets	spread across various different controls despite being an enum where only one can be true	is just climate presets like how the device works and how it works in Futurehome
"heat" preset	is named "heat" despite how it functions as the user-overidden temperature target	renamed to "user" as a preset instead of system mode
temperature sensor	named "internal", "external", "both"	renamed to "room sensor", "floor sensor", "max guard" based on what the manual calls them

[Reinachan]

Btw, off-topic, but having read through a lot of the source code now, I have some stuff I'd like to just mention.

// Should be avoided
some_converter: {
  // ...
} as Fz.Converter

// Instead you should do
some_converter: {
  // ...
} satisfies Fz.Converter

The as keyword asserts that you know better than TypeScript what the type actually is, so TypeScript will skip typechecking it and just assume you know what you're doing. satisfies will typecheck it and let you know if it's incompatible with the type.
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-9.html

Other than that, adhering to your codestyle is kinda hard without something like a prettierconfig. I turned off my prettier autoformatting as it heavily conflicted with your preferences. I'd suggest adding a prettier config.

[Koenkk]

Thanks!

• I didn't know about the satisfies yet, could you make a PR to use this in the whole code base?
• Regarding code style, currently eslint (I know prettier does much more), but I think it's good enough for now.

[Reinachan]

I didn't know about the satisfies yet, could you make a PR to use this in the whole code base?
@Koenkk

I'll see if I get around to it sometime. It might be a big undertaking as I may have to fix a lot of stuff alongside it, which is hard without extensive knowledge of the project as a whole. But I'll have a look at it at least when I have time for it. Could be easier than I think :p

Thanks for the help in getting this merged <3