-
Notifications
You must be signed in to change notification settings - Fork 628
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
Conversation
…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 Report
@@ 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
Continue to review full report at Codecov.
|
Pull Request Test Coverage Report for Build 517842700
💛 - Coveralls |
Tuya devices wait with a timeout for the response, until a next request is send.
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 ?? If not its braking the support for 95 %. By the way great work done and mutch cleaning of old code !! |
I've separated the signatures and replacements of the different thermostats. |
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. Thanks you very much ! |
I have one for testing on my table if you like doing testing :-))) |
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. |
A test of a different TRV should be relative simple:
I know that some TRV report the battery level and others like the Moes only have a low battery warning. |
zhaquirks/tuya/__init__.py
Outdated
# 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 | ||
) | ||
) |
There was a problem hiding this comment.
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
# 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) |
@xonestonex sorry, had to push some zigpy changes which would require changes to Let me know if you need very help and thank you for your contribution |
@Adminiuga thanks for the changes to handle_cluster_request in zigpy. |
Its gets one more version of the Moes TRV
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. |
@MattWestb done. |
GREAT !!!!! Looks like you have getting all the cluster OK butt i can't verifying it. 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 !! |
This seems like the changes I need. Is there something I can do to help? I have a _TZE200_ckud7u2l here. |
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 :-(( 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 ? |
@dmulcahey This is one of the best starting merging and then the other must being updated then its getting conflicts. The bad one that have making the trouble is #710. |
@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. |
@MattWestb can you make this easy for us and tell us which ones should be merged? |
The old #710 is the braking one. (saswell sea801 TRV as Moes HY368 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. |
I think the #726 is implanting more functions = easier adapting other tuya devices then the functions is already there. |
I'm hoping this will also support |
@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. |
@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 |
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). 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. |
* 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.
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 A quick report to help identifying issues: |
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 :-)) |
I hope that I get time to improve the HA integration by end of march. |
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. . . |
Hello @xonestonex , @MattWestb 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? |
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. |
Hi, this is a list of parameters generated by Zigbee2MQTT for
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 |
Hello again, 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 Hmmm I don't know how it works but... it looks like: Parameters settable from Tuya App
Note: weekdays and weekend schedules are also acessible from MT Cluster (distinct attributes for 6 timeslots hour, minute, temperature). 263 = 23 attributes
Attributes Just Queryable?
|
Hi @xonestonex,
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 I tried to send |
I also have a |
Hello ZHA engineers, Dear @dmulcahey, The questions are:
|
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.
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: Question: How can I set the time of the device using ZHA? Can anyone guide me? |
Koenkk/zigbee2mqtt#5620 is the most interesting reference and would be really lovely to see it implemented here too. |
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
Now, I think this attribute could be directly mapped to HA Climate HVAC_MODES What do you think? |
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.