Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better Moes HY368 (tuya) implementation #726

Merged
merged 11 commits into from
Feb 27, 2021

Conversation

xonestonex
Copy link
Contributor

@xonestonex xonestonex commented Jan 15, 2021

I've implemented almost all of the device functionality based on the device point descriptions of Zigbee2Mqtt.
The manufacturer specific stuff is also mapped to the individual clusters as manufacturer specific attributes, this should make it easier to provide more functionality in home assistant in a later step.

…ed on code from Z2M:

 - Provide all known device point attributes
 - Better mapping between thermostat cluster and tuya attributes
 - Provide additional manufacuturer specific attributes (schedule, operation modes, ...)
 - On/Off Cluster for window detection functionality
@codecov-io
Copy link

codecov-io commented Jan 15, 2021

Codecov Report

Merging #726 (798a5b6) into dev (9d9d6e7) will increase coverage by 1.09%.
The diff coverage is 95.90%.

Impacted file tree graph

@@            Coverage Diff             @@
##              dev     #726      +/-   ##
==========================================
+ Coverage   83.08%   84.18%   +1.09%     
==========================================
  Files         176      176              
  Lines        3956     4243     +287     
==========================================
+ Hits         3287     3572     +285     
- Misses        669      671       +2     
Impacted Files Coverage Δ
zhaquirks/tuya/__init__.py 87.83% <84.44%> (+4.50%) ⬆️
zhaquirks/tuya/valve.py 95.52% <97.98%> (+8.76%) ⬆️
zhaquirks/philips/zhadimmablelight.py 100.00% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9d9d6e7...798a5b6. Read the comment docs.

@coveralls
Copy link

coveralls commented Jan 15, 2021

Pull Request Test Coverage Report for Build 517842700

  • 281 of 293 (95.9%) changed or added relevant lines in 2 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+1.1%) to 84.186%

Changes Missing Coverage Covered Lines Changed/Added Lines %
zhaquirks/tuya/valve.py 243 248 97.98%
zhaquirks/tuya/init.py 38 45 84.44%
Totals Coverage Status
Change from base Build 512410068: 1.1%
Covered Lines: 3572
Relevant Lines: 4243

💛 - Coveralls

Tuya devices wait with a timeout for the response, until a next request is send.
@MattWestb
Copy link
Contributor

I think the ("_TZE200_kfvq6avy", "TS0601"), and ("_TZE200_c88teujp", "TS0601"), that is putted under MoesHY368 is in real Siterwell MCU with updated Zigbee module (the same zigbee module as MoesHY368) and need the SiterwellManufCluster, SiterwellThermostat, and SiterwellUserInterface, cluster for working.

Making one "class SiterwellGS361_2(TuyaThermostat):" class for this ones ??
Or perhaps Siterwell_type1 and Siterwell_type2 ?

If not its braking the support for 95 %.

By the way great work done and mutch cleaning of old code !!

@xonestonex
Copy link
Contributor Author

I've separated the signatures and replacements of the different thermostats.
According to Z2M code base some of the features I've implemented for the Moes HY368 should also work with the Siterwell models too. Someone with such a valve should do some tests.

@MattWestb
Copy link
Contributor

Looks great what i can see !

And hope all the devices IDs is the right one but 2 of them i have helping user to adding after they have verified its the right devices.

Then you have getting it merged i testing adding my Revolt 1 and looking how it working.
For the moment all function is not implanted for this devices so hope they is being added later.

Thanks you very much !

@MattWestb
Copy link
Contributor

I have one for testing on my table if you like doing testing :-)))

@MattWestb
Copy link
Contributor

Its also one more TRV in the tuya family that is missing and user is asking for it the Saswell #576.

But dont do all at the same time. Better doing it step by stap and getting things working well and not making on mess of what you have getting working.

@xonestonex
Copy link
Contributor Author

A test of a different TRV should be relative simple:

  1. Add it to the MoesHY368 class
  2. Reset the settings to default on the valve. This forces the valve to publish all its values.
  3. Look what attributes are filled in the MoesManufCluster.

I know that some TRV report the battery level and others like the Moes only have a low battery warning.
I also don't know if the mode mapping fits all TRVs. The Moes doesn't have a off state. Mode 0 is the "away" mode, that resets itself to normal mode after "away_duration_days".

Comment on lines 127 to 133
# Send default response because the MCU expects it
schema = foundation.COMMANDS[foundation.Command.Default_Response][0]
self.create_catching_task(
self.reply(
True, foundation.Command.Default_Response, schema, command_id, tsn=tsn
)
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With zigpy==0.32.0 you could do

Suggested change
# Send default response because the MCU expects it
schema = foundation.COMMANDS[foundation.Command.Default_Response][0]
self.create_catching_task(
self.reply(
True, foundation.Command.Default_Response, schema, command_id, tsn=tsn
)
)
# Send default response because the MCU expects it
self.send_default_rsp(hdr)

https://github.com/zigpy/zigpy/blob/2a851f1ce7694c4b331a6a87d5334969d95f57aa/zigpy/zcl/__init__.py#L620

@Adminiuga
Copy link
Contributor

@xonestonex sorry, had to push some zigpy changes which would require changes to handle_cluster_request() signature in this PR. See #748 for more details.

Let me know if you need very help and thank you for your contribution

@xonestonex
Copy link
Contributor Author

@Adminiuga thanks for the changes to handle_cluster_request in zigpy.

@MattWestb
Copy link
Contributor

Its gets one more version of the Moes TRV

Brand Model Manufacturer Name Model ID ZHA Quirk Request
Moes HY368 _TZE200_ckud7u2l TS0601 ✅ Moes
Moes HY368 _TYST11_ckud7u2ll kud7u2l No Moes

Its fund in the deCONZ TRV Wiki and i have puting it in ZHA Wili zigpy/zigpy#653 (comment)

If you have time it can being goof putting in the second zigbee module variant and dont need do it later.

@xonestonex
Copy link
Contributor Author

@MattWestb done.

@MattWestb
Copy link
Contributor

GREAT !!!!!

Looks like you have getting all the cluster OK butt i can't verifying it.
I making it as pending in my tuya TRV matrix.

I hope Adminiuga can mager this PR and then the other for Saswell that is making problems in the Moes part of the quirk and should being moved to one own section.

An thanks very much agen !!

@Roeland54
Copy link

This seems like the changes I need. Is there something I can do to help? I have a _TZE200_ckud7u2l here.

@MattWestb
Copy link
Contributor

For the moment the devs have freezing all tuya TRV then one user have adding one device in wrong TRV type. #751 (comment) and making one mess of all :-((
I have pinpointing it on the zigpy/zigpy#653 (comment).

Then getting all 3 pending PR merged with the correction for the ("_TZE200_c88teujp", "TS0601"), all major TRV is working but the Siterwell type is little limited function but its not worth doing any thing before all functions is in place.

Do you have trying if this PR is working with your Moes HY368 / HY369 ?

@MattWestb
Copy link
Contributor

@dmulcahey This is one of the best starting merging and then the other must being updated then its getting conflicts.
I have made one matrix with wot is in and wot is wot is ready for merging. zigpy/zigpy#653 (comment)

The bad one that have making the trouble is #710.
If adding #751 after this its overriding / deleting the bad changes made in #710.

@Adminiuga
Copy link
Contributor

@dmulcahey I frankly lost the track of all these Tuya thermostats (and screw tuya for having different devices under the same model) so probably the wrong person to ask.
Maybe we could keep a list of Tuya thermostat users anywhere (with different models) and ask them to test? Otherwise our best option (which I'm in favor of) is to release this early and ask users to test, prior the next beta cut.

@dmulcahey
Copy link
Collaborator

@MattWestb can you make this easy for us and tell us which ones should be merged?

@MattWestb
Copy link
Contributor

The old #710 is the braking one. (saswell sea801 TRV as Moes HY368 TRV)
The #751 is correcting it by implanting one "real" saswell sea801 and deleting the false manufacture id from the Moes TRV.

The #726 must then rebased for merger OK. Or you do the opposite then both is changing the same files.

The most important is correcting the #710 (("_TZE200_c88teujp", "TS0601"),) from Moes to the new saswell type.

After that i 2 more TRV types in the pipe but its coming later and dont do all at the same time.

In the matrix i have written user need one photo of the device and one link to the manufacture so its possible see if its the same type or not before adding them for not making one mess of it agen.

@MattWestb
Copy link
Contributor

I think the #726 is implanting more functions = easier adapting other tuya devices then the functions is already there.
On the code plane i cant saying any thing (luck of experience) so is not other things merger the with must added functions for making it more flexible and not braking things later by adding large PRs that is in place. The other may not like it but the best for ZHA have the first priority.

@niro1987
Copy link

I'm hoping this will also support _TZE200_ywdxldoj

@MattWestb
Copy link
Contributor

@niro1987 No its dont. If all is going well and its working without conflicts its only to adding the manufacture ID and its working but i think the devs dont like making more last minute changes.
You can taking on look on the tuya TRV matrix the ID is on the list but not implanted. zigpy/zigpy#653 (comment)

@niro1987
Copy link

@MattWestb Thank you for your feedback. If I understand correctly, it is best to wait for this PR to pass and then send in a Device request for the _TZE200_ywdxldoj model?

@MattWestb
Copy link
Contributor

MattWestb commented Feb 18, 2021

Yes you can download the PR and installing it by hand and adding you manufacture id but its not so easy (I was doing it for My TRV in the first PR for them in ZHA for helping the devs).
But its being easier then its being merged and you can using the dev branch and not the PR from the dev and also the devs is needing some user to testing it so they is knowing its not braking more things.

Download the PR and using the instruction: https://github.com/zigpy/zha-device-handlers#testing-quirks-in-development-in-docker-based-install is working (adding your manufacture ID before installing it in HA is making it easier).

Edit: For editing the manufacture ID in the container #693 is working 2.

@dmulcahey dmulcahey merged commit bd5d0f6 into zigpy:dev Feb 27, 2021
dmulcahey pushed a commit that referenced this pull request Feb 28, 2021
* Adding TRV _TZE200_ywdxldoj

Adding TRV _TZE200_ywdxldoj by user request in #726 (comment).

* Adding missing Saswell SEA801

Adding:
Saswell	SEA801	_TYST11_KGbxAXL2	GbxAXL2
HiHome	WZB-TRVL	_TYST11_zuhszj9s	uhszj9s
Hama	00176592	_TYST11_yw7cahqs	w7cahqs

All ID is verified from Z2M.
@sstefanowski
Copy link

sstefanowski commented Mar 6, 2021

Big thanks to @xonestonex. Great work!

This is right in time, for me :). I just got today(!) set of Meos HY368 Radiator Valves identified as _TZE200_ywdxldoj. After upgrading to the latest release it started to show in ZHA as zhaquirks.tuya.valve.MoesHY368_Type1
I have multiple bridges (Zigbee2Mqtt dongle, ZHA Sonoff with Tasmota, Original Tuya) - is there any way I can help you with pushing this forward for this specific device (like logging)?

A quick report to help identifying issues:
The most important setting - manual temp set - is working fine, but still comparing to TupaApp options (and Zigbee2MQTT) many are not present or malfunctioning (but I think you expected this).
The things that are not working correctly are Key Lock Entity Switch (aka Child Lock) entity is present in HA but not working fine.
Many attributes and settings like Preset, ForcedValveState, position of the valve, are not yet working (but I can see something very related in Meos... classes

@MattWestb
Copy link
Contributor

I agree with you @sstefanowski !!

Hi have getting "all in" for the TRV that is having most functions and hi like getting all that is possible also working in HA GUI and this is the first step for doing it.

I was doing one fast adding of the other TRVs that is known and the devs was merging them and its looks we have getting the chaos back to normal for our tuya TRVs and now its 14 different TRVs that have getting support in ZHA.

Can you reporting wot functions is working or not then you is using cluster commands and also HA GUI ?

I have doing one matrix with all functions i have finding that our TRV is having zigpy/zigpy#653 (comment).

Its being good for user to knowing it so not getting much complain of broken function and also for devs then fixing and making the HA GUI part.

For the moment its only my Siterwell that have the less functions working but is enough for having them in my production system and the rest is not so important only need little time for the devs fixing it then they is having time :-))

@xonestonex
Copy link
Contributor Author

I hope that I get time to improve the HA integration by end of march.

@MattWestb
Copy link
Contributor

Thanks @xonestonex you was doing the "all in" great and now we having 14 different TRV supported in ZHA :-)))

And the Sas have getting one separate quirk and not making problems for our users.

By the way I have dumped tuya TBGW flash and putting it on one private repro and inviting you to it if you like looking inside it. . .

@sstefanowski
Copy link

Hello @xonestonex , @MattWestb
I'm ready to help with debugging my version of MOES valve which is HY368 _TZE200_ywdxldoj. I need some steering from you what you'd like to know about compatibility and support.

Questions: Is this thread now logically "closed" and free for discussion as the pull-request was merged? Shall we continue the discussion here or leave this thread for discussions of code changes/comments?

@MattWestb
Copy link
Contributor

The issue is colored because one PR have being merged = the issue if fixed, but its still possible using it until the system (or devs) is locked but then its only opening one new issue.

I prefer then the followup is being in the same issue if its possible (not good if the issue is very long and cant finding the information like the Z2M tuya TRV issue).

I is no code warrior but i try helping then i can and is more on the hardware side.

If you like testing the functions of the device is working on the "zigbee level" then from the device card "manage cluster" and select on of the "Mose one" and try reading and sending attribute and commands. They is different cluster for different main functions and its connected to the zigbee standard. I think perhaps the On/Off cluster (0x0006) is used as on off mode for heating in the mose TRVs.

Look in the "tuya TRV matrix" wot you is expecting to find and perhaps you is finding some extra @xonestonex have cocked in the code ;-))

And also good to knowing wot is working from the device card in HA like setting target temp and reading local temp and and operating modes.

@sstefanowski
Copy link

sstefanowski commented Mar 6, 2021

Hi, this is a list of parameters generated by Zigbee2MQTT for _TZE200_ywdxldoj. I can try to map them to Zigbee attributes in MOES clusters.

HA Entity Name HA Entity State State HA Entity Attributes
climate.0x........ auto hvac_modes: heat, auto, off
min_temp: 5
max_temp: 35
target_temp_step: 0.5
preset_modes: none, away, schedule, manual, boost, complex, comfort, eco
current_temperature: 20
temperature: 13
preset_mode: manual
auto_lock: MANUAL
away_mode: OFF
away_preset_days: 1
away_preset_temperature: 15
battery_low: false
boost_time: 400
child_lock: UNLOCKED
comfort_temperature: 21
current_heating_setpoint: 13
device:
....applicationVersion: 85
....dateCode: ''
....friendlyName: '0x847127fffe110824'
....hardwareVersion: 1
....ieeeAddr: '0x847127fffe110824'
....manufacturerID: 4098
....manufacturerName: _TZE200_ywdxldoj
....model: TS0601_thermostat
....networkAddress: 59054
....powerSource: Battery
....stackVersion: 0
....type: EndDevice
....zclVersion: 3

eco_temperature: 14
force: normal
holidays:
....- hour: 6
.... minute: 6
.... temperature: 10
....- hour: 8
.... minute: 7
.... temperature: 11
....- hour: 11
.... minute: 28
.... temperature: 12
....- hour: 12
.... minute: 39
.... temperature: 13
....- hour: 17
.... minute: 40
.... temperature: 14
....- hour: 22
.... minute: 11
.... temperature: 15

last_seen: 1615138545700
linkquality: 60
local_temperature: 20
local_temperature_calibration: -1
max_temperature: 36
min_temperature: 4
position: 0
preset: manual
system_mode: auto
update:
....state: idle

update_available: false
week: 6+1
window_detection: OFF
window_detection_params:
....minutes: 11
....temperature: 6

workdays:
....- hour: 6
.... minute: 1
.... temperature: 10
....- hour: 8
.... minute: 2
.... temperature: 11
....- hour: 11
.... minute: 32
.... temperature: 12
....- hour: 12
.... minute: 33
.... temperature: 13
....- hour: 17
.... minute: 34
.... temperature: 14
....- hour: 22
.... minute: 5
.... temperature: 15

friendly_name: 0x847127fffe110824
supported_features: 17

BTW. It looks like from SmartLife App (and Tyua Bridge) I can send daily schedules to the valve. Is this possible in HA via any ZHA Service? I can see then MoesThermostat cluster is defining the command set_weekly_schedule (id: 0x0001). If the answer is yes can anyone tell me how to do it?

@sstefanowski
Copy link

sstefanowski commented Mar 7, 2021

Hello again,
this table contains mappings of parameters/attributes settable from Tuya Smart Life for _TZE200_ywdxldoj valve.

I've preset/changed Valve parameters to custom/unique values ones using Tuya App (via Tuya Bridge) and then rejoined Valve to ZHA to read the settings and get the mappings. I guess this might be helpful.

MMC = MoesManufCluster
MT = MoesThermostat Cluster
MUI = MoesUserInterface Cluster
TPCC = TuyaPowerConfigurationCluster
B = Basic Cluster
HA Attr = HA Parameter name set by Zigbee2MQTT

Hmmm I don't know how it works but... it looks like:
Note1: When you pair brand new MEOS Valve with the ZHA many of the parameters in a table are NOT present (report None when queried from ZHA). They become present when you pair with Tuya App and then with ZHA. It looks like Tuya Smart Life App sends some initialization values when paired first-time.
Note2: ALL settable parameters of the Valve are present just in MeosManufCluster. Many of them are replicated in MeosThermostat (and the other Meos clusters) but I don't know if the presence of the other Moes Clusters is needed for setting/getting the right values.
Note3: MT contains one very important read-only attribute non existing in MMC (valve_open_percentage (id: 0x4004)). BTW. Maybe it's settable - that would be a really nice hack!

Parameters settable from Tuya App

Tuya App Setting HA Attr ZHA Cluster + Attribute Extracted values
? KeyLock MMC + auto_lock (id: 0x0174)
MUI + auto_lock (id: 0x5000)
0
Bool.false
Boost Time (S) ? MMC + boost_duration_seconds (id: 0x0269)
MT + boost_duration_seconds (id: 0x4005)
400
?KeyLock
?Child Lock type
? MMC + child_lock (id: 0x0107)
MUI + keypad_lockout (id: 0x0001)
0
KeypadLockout.No_lockout
Comfort Tem Set ? MMC + comfort_mode_temperature (id: 0x026b)
MT + comfort_heating_setpoint (id: 0x4000)
21
2100
EcoTemp Set ? MMC + eco_mode_temperature (id: 0x026c)
MT + eco_heating_setpoint (id: 0x4001)
14
1400
MaxTemp Limit max_temp MMC + max_temperature (id: 0x0267)
MT + max_heat_setpoint_limit (id: 0x0016)
-
36
3600
(default=35C)
MinTemp Limit min_temp MMC + min_temperature (id: 0x0266)
MT = min_heat_setpoint_limit (id: 0x0015)
-
4
400
(default=5)
Mode ? preset_mode
preset
MMC + mode (id: 0x0404)
MT + operation_preset (id: 0x4002)
2
Preset.Manual
temperature
current_heating_setpoint
MMC + target_temperature (id: 0x0202)
MT + occupied_heating_setpoint (id: 0x0012)
190
1900
Temp Calibration MMC + temperature_calibration (id: 0x022c)
MT + local_temperature_calibration (id: 0x0010)
-10
-100
Valve Setting force MMC + valve_force_state (id: 0x046a)
MT + valve_force_state (id: 0x4006)
0
ForceValveState.Normal
AutoMode Type MMC + week_format (id: 0x046f) 1
?(0=5+2, 1=6+1, 2=7)
Restday MMC + weekend_schedule (id: 0x0071) [15, 11, 22, 14, 40, 17,
13, 39, 12, 12, 28, 11,
11, 7, 8, 10, 6, 6]
6:06=10C, 8:07=11C,
11:28=12C, 12:39=13C,
17:40=14C, 22:11=15C
Workday MMC + workday_schedule (id: 0x0070) [15, 5, 22, 14, 34, 17,
13, 33, 12, 12, 32, 11,
11, 2, 8, 10, 1, 6]
6:01=10C, 8:02=11C,
11:32=12C, 12:33=13C,
17:34-=14C, 22:05=15C
Window Parameter MMC + window_detection (id: 0x0068) [11, 6, 0]
6C for 11min 0=off
Holiday Mode
Set Days
MMC + away_duration_days (id: 0x0275)
MT + unoccupied_duration_days (id: 0x4007)
10
Holiday Mode
Set Temp
MMC + away_mode_temperature (id: 0x0272)
MT + unoccupied_heating_setpoint (id: 0x0014)
15
1500

Note: weekdays and weekend schedules are also acessible from MT Cluster (distinct attributes for 6 timeslots hour, minute, temperature). 263 = 23 attributes
Note: MWD contains attributes for window detection settings (all present already in a single attribute (array) of MMC)

Tuya App Setting HA Attr ZHA Cluster + Attribute Extracted values
Window Detection On/Of MWD +on_off (id: 0x0000) Bool.false
Window Detection Temperature MWD + window_detection_temperature (id: 0x6000) 600
Window Detection Minutes MWD + window_detection_timeout_minutes (id: 0x6001) 11

Attributes Just Queryable?

Tuya App Function HA Attr ZHA Cluster + Attribute Extracted values
Ambient Temp current_temperature
local_temperature
MMC + temperature (id: 0x0203)
MT + local_temp (id: 0x0000)
205
2050
state MMC + valve_state (id: 0x026d)
MT + running_state (id: 0x0029)
0
RunningState.Idle
MT + running_mode (id: 0x001e) RunningMode.Off
Battery Alert MMC + battery_low (id: 0x016e) 0
MT + ctrl_seqe_of_oper (id: 0x001b) ControlSequenceOfOperation.Heating_Only
MT + occupancy (id: 0x0002) Occupancy.Occupied
MT + programing_oper_mode (id: 0x0025) ProgrammingOperationMode.Simple
MT + system_mode (id: 0x001c) SystemMode.Heat
Valve position in % position MT + valve_open_percentage (id: 0x4004) 45
Battery percentage
two batteries means 200%???
TPCC + battery_percentage_remaining (id: 0x0021) 200 ????
Aplication version?? B + app_version (id: 0x0001) 85
Hardware version?? B +hw_version (id: 0x0003) 1
Manufacturer B + manufacturer (id: 0x0004) _TZE200_ywdxldoj
Model B+ model (id: 0x0005) TS0601
Power Source B + power_source (id: 0x0007) 'PowerSource.Battery'
B + stack_version (id: 0x0002) 0
B + zcl_version (id: 0x0000) 3

@sstefanowski
Copy link

sstefanowski commented Mar 7, 2021

Hi @xonestonex,
You mentioned earlier that:

  1. Reset the settings to default on the valve. This forces the valve to publish all its values.
  2. Look what attributes are filled in the MoesManufCluster.

How can I do reset of the valve? From ZHA? Or you mean hardware reset? (I'm a bit concerned that it will reset Zigbe pairing)

I'm asking because one of my HY368 installed and paired out-of-the box with ZHA has most of "None" values for most of MoesFactCluster attributes (even the ones I suspected should have "default values" like auto_lock have None). But, in case of another HY368 when I preset some values via Tuya App the values in a Zigbee cluster are present.
Therefore I think the App/Software is needed to initialize many of the HY368 attributes.

I tried to send reset_fact_default (id: 0x0000) command from Basic Cluster and nothing changes - the valve did not publish anything. I don't even know if I sent this command correctly. How to do it? Should I use some parameter?

@niro1987
Copy link

Hi @sstefanowski

I also have a _TZE200_ywdxldoj model that I can pair / reset however you need. How can I help?

@sstefanowski
Copy link

Hello ZHA engineers,
Hello @xonestonex,
I have a quick question: Are you still planning to push a quirk for MOES valve a bit ahead? I'm asking because I played with the valve a bit and it looks like ZHA is still the best option to serve it without Tyua gateway. I tried also Zigbe2MQTT but it has also some problems with this device, therefore, I would stay with ZHA which was the most stable, but... just incomplete.
I tried to investigate ZHA and quirk code, but unfortunately, I'm was never very experienced in Python. I got the general concept of quirk (as described) but do not have time to learn the code-base fast.

Dear @dmulcahey,
If @xonestonex do not have time, I wonder if we can hack somehow the current MOES implementation with some HA scripting? The functionality I'm missing most is turning on the presets (especially "holiday" and "schedule") and config of the schedule (hours and temperatures). I imagined I could implement a workaround of the setup for these functionalities by altering Moes Valve ZHA cluster attributes and calling the cluster methods.

The questions are:

  • Is there any way to steer the ZHA device by reading/writing attributes of Clusters using HA services - I could see there is set_zigbee_cluster_attribute but I can't see any "getter" service. Is there any?
  • Will the device react to attribute change or we should just use some Cluster commands to change them?
  • Is the device pulling the time from the HA server by default? It's needed for schedule aligning? If yes, then is time sync repeated after some period?

@sstefanowski
Copy link

sstefanowski commented Mar 28, 2021

Well, I got no answer, I understand the community may be busy :)

As I meant ZHA quirk code structure is a bit too complicated for me, and I don't know how to extend it to add all the features. In meantime, I've implemented a control panel of MOES HY368 (_TZE200_ywdxldoj) using pyscript and HA packages. This is a custom solution to overcome issues with the lack of control of HY386 settings from ZHA. I think I will publish it in a few days on community pages.
The solution:

  1. periodically (every minute) queries ZHA DB using SQLite (zigbee.db) and publishes a set of HA sensors (last-seen, battery, position, preset, and others) with rich attributes.
  2. enables a list of HA inputs (selects, date-times, numbers) to control some list settings (mode, preset, week format) and schedule (time and temperatures). I'm sending attribute updates (of MeosThermostat Cluster) after any state change in HA and it works! The settings are changed in the device!

I'm pretty satisfied with the solution. I can control now most of the features I wanted to control. but.... I have just last serious problem, and I don't know how to solve it (the problem is described below):

These are just two screenshots of my thermostat and control cards in UI(in polish):

Now.... the problem is the time control of the Thermostat. I can see the time on the device gets unsynchronized (very unprecise clock in the device) so I'd like to send a correct time every midnight. I don't know how I can do it with ZHA. The TuyaManufCluster has methods set_time() but it fails regardless of the parameter I'm sending. The code of ZHA in TuyaManufCluster says something about getting time request from the device first (pull???), but I think there must be a way of "pushing" time to the device. Time setting (corrections) of Tuya/Meos was solved in Zigbee2MQTT:
Koenkk/zigbee2mqtt#5916
Koenkk/zigbee2mqtt#5620

Question: How can I set the time of the device using ZHA? Can anyone guide me?

@almico
Copy link

almico commented Mar 29, 2021

Koenkk/zigbee2mqtt#5620 is the most interesting reference and would be really lovely to see it implemented here too.

@sstefanowski
Copy link

sstefanowski commented Mar 29, 2021

Hi @xonestonex,

Thank you for implementing presets in home-assistant/core#48178. You rock! I really wish I could help you with extensions, but diving into ZHA code is something too complicated for me.

In the pull requirest, you mentioned that MOES Thermostat has no real OFF state and I wonder if this a really true. I'm thinking that maybe MEOS supports three modes controlled by valve_force_state attribute in MeosTheromostat cluster. This gets three values and:

  • Normal means the valve is operating according to the selected preset
  • Openmeans that valve if fully opened (I guess ignoring the preset)
  • Close means that valve is fully closed (also I guess ignoring the preset)

Now, I think this attribute could be directly mapped to HA Climate HVAC_MODES AUTO, HEAT, OFF respectively AUTO=Normal, HEAT=Open, OFF=Close

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet