HY368 (TS0601) - cannot control through the HA

[vincentlee20]

I am new to zigbee, and have integrated ZHA to control TRV HY368 (system recognised as TS0601. However, I cannot control the device, it seems that ZHA only returns the status of the TRV.

1. I turn off the TRV in HA, and HA shows it is on again a few second
2. the schedule cannot be changed in HA (can only be updated in the TRV itself)

I am using HA OS (clean install recently), and integrated ZHA. Not sure if I need to install the handler separately so I can control the TRV. Now, HA just acts as a reporter showing the thermostat info and the TRV status (on/off).

Thanks for your help

[MattWestb]

Can you please post the signature of the device (from the device card and "zigbee device signature" click in the text and the CTR A and then CTR C and past it in the issue with CTR V).

[vincentlee20]

{ "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, allocate_address=True, is_alternate_pan_coordinator=False, is_coordinator=False, is_end_device=True, is_full_function_device=False, is_mains_powered=False, is_receiver_on_when_idle=False, is_router=False, *is_security_capable=False)", "endpoints": { "1": { "profile_id": 260, "device_type": "0x0301", "in_clusters": [ "0x0000", "0x0001", "0x0004", "0x0005", "0x0006", "0x0201", "0x0204", "0xef00" ], "out_clusters": [ "0x000a", "0x0019" ] } }, "manufacturer": "_TZE200_cwnjrr72", "model": "TS0601", "class": "zhaquirks.tuya.ts0601_trv.MoesHY368_Type1" }

[MattWestb]

The quirk is loaded OK. I dont knowing the device but is shall have the basic function implanted and most on the cluster as attributes like schedule can being setted and readed with cluster commands.

Changing mode hall being made with presets on the thermostat card looks like this (but with more presets than my Siterwell) Its also one new quirk that is being tested with more elements in the ZHA GUI but i dont knowing how much is working OK but need more testing.

[vincentlee20]

When I turn it off in HA, it become on again in a few second as shown below.

For setting the preset, it can only be "schedule". No matter any option I select, it will return to "schedule". However, I cannot edit the schedule in HA

Before Changed Auto-return to original setting

[MattWestb]

The OnOff switch is not for turning the TRV on and off the one TRV is "always living" and is used for window open detection on or off.

If you is changing the setpoint temperature on the TRV is it updating in ZHA ?

Schedule you can setting and reading on cluster (manage cluster, MoesThermostat cluster and you have some attribute that you reading and writing).

[MattWestb]

Presets "None" = manual mode that shall being possible changing the setpoint temperature on the device that can being blocked then the device is in Schedule mode.

[vincentlee20]

Thanks. I have more understanding on it now.

I will need to explore how to turn it on or off (e.g. if I am not in the living room, I don't need to turn on the TRV), it will help to save my bill

[MattWestb]

The "tuya command" is MOES_FORCE_VALVE_ATTR = 0x046A # [0] normal [1] open [2] close and is mapped to attribute "valve_force_state".

The normal working mode is 0 then the TRV is trying getting the temperature equal as sett. If you is using 1 (100% open) and / or 2 (100% close) is the algorithm not working at all (its need days for "learning" how the room is reacting on heating) but is up to you using it as one on / off switch.

If you like you can making one template switch for changing the valve state in HA.

[vincentlee20]

Yes, I just get the TRV connect to zigbee (my first zigbee device), will need to have more trial. But at least I can turn it off when I go to bed LOL, and try the next day.

[MattWestb]

The best way is changing mode to one presets then the TRV is still working with algorithms. Away, Schedule, Manual, Comfort or Eco mode / presets with one lower setpoint and letting the TRV "doing its work".

Or running in manual mode (presets none) and sending new setpoint temperature to it from HA automations.

[vincentlee20]

I am thinking if we leave the valve running, and using HA autoamtion to set the target temp. 0c as closed, x for desired temp.

By the way, a silly question because I cannot locate the below. Quote The "tuya command" is MOES_FORCE_VALVE_ATTR = 0x046A # [0] normal [1] open [2] close and is mapped to attribute "valve_force_state".

[MattWestb]

On MoesThermostat cluster you shall having one attribute with the name "valve_force_state". And writing 0 = normal 1 = open and 2 = close.

[vincentlee20]

I try to set the preset to none in cluster but it does not work. Seem HA cannot update the TRV attribute

when I get the attribute, the return to schedule

Regarding the valve_force_state, I have change to 2. When I get the attribute again after setting it, it is set as normal. setting attribute to 2 Get the attribute again

[MattWestb]

Its looks like your device is sending status to ZHA but dont like getting commands from ZHA.

One thing can being that the TRV is is schedule and dont like getting "manual commands".

Is it possible doing changes on the device and ZHA is getting it like the setpoint temperature, other operating mode ?

My feeling is that all you is doing in ZHA is not working on the device :-((

Children lock shall only blocking local commands so shall not being any problems.

[vincentlee20]

I can do the changes on device and I can get the attribute value through ZHA. Even I set the target temperature in HA, there is no effect to the device. E.g. Preset schedule 35c, current temperature 26c, I set the target temperature 20c, the radiator is still working (very hot)

I am not sure if it is the issue in SONOFF Zigbee 3.0 USB Dongle Plus, or ZHA, or the TRV

[jacekk015]

configuration.yaml - add/update

logger:
  default: info
  logs:
    homeassistant.components.zha: debug
    zigpy: debug
    zhaquirks: debug

Restart HA. Do some changes on TRV and HA->TRV Min 5 minutes of logs, best is about 10 minutes. Put here ALL! logs as a text file. I mean ALL - do not cut anything. Logs will show if those commands were sent to TRV with success. [edit] Would be nice to see a device card as a picture.

[vincentlee20]

After I restart HA, I can now control the TRV. I have no clue, I just add update the configuration.yaml and restart the HA, and things works now log.txt

[vincentlee20]

when I remove the logger and restart HA, I encounter the error again. I have added back the debugged, and restart. Below is the log. The TRV is now set to idle, 5c....i cant' turn on now LOL log.txt

[MattWestb]

After the last restart of HA you is getting Request failed after 5 attempts: <Status.MAC_NO_ACK: 233> = ZHA cant communicating with the device,

And looking little more i can only finding one time ZHA have sending somthing to the coordinator:

2021-12-07 23:40:01 DEBUG (MainThread) [zigpy.application] Received frame on uninitialized device <ZNPCoordinator model='CC1352/CC2652, Z-Stack 3.30+ (build 20210708)' manuf='Texas Instruments' nwk=0x0000 ieee=00:12:4b:00:25:8d:4f:98 is_initialized=False> from ep 0 to ep 0, cluster ZDOCmd.Simple_Desc_rsp: b'\x05\x00\x00\x00\x0E\x01\x04\x01\x00\x04\x00\x01\x19\x00\x02\x00\x05\x02\x05'

And ZHA is trying finding on quirk for the coordinator but Fail because endpoint list mismatch: {1} {1, 2}. And it cant using the coordinator = very strange :-(((

If you is restarting HA is you getting the same or is it loading the coordinator OK ?

You was having the system working before but i dont understanding the reason it dont like talking with your Sonoff stick !!

Then you is reading attributes from the TRV is ZHA using old cached information if not getting replay from the device so you can only see if its working by doing changes on the device and getting updates in ZHA.

Also then all is working OK is the TRV one sleeping end device so it can taking some seconds for it waking up and receiving the command and it can being it need resending some time but if doing changes ok the device its updating very fast.

[jacekk015]

Definately Zigbee USB stick problems. Coordinator can't send anything to TRV. That's the problem to solve.

[MattWestb]

@jacekk015 what coordinator is you normal using ? I only using EZSP so i can't saying how the TI is doing the setup in the logs.

[jacekk015]

@MattWestb Sonoff ZBBridge with Tasmota and NCP 6.7.8 I've read recently that it isn't best - actually it drops sometimes serial Wifi connection and need to restart itself. Got also cheap Sonoff USB CC2531 stick

Also, according to Z2M recommendation I've bought Slaesh's CC2652RB stick with 3dBi antenna, which should be powerfull device. https://www.zigbee2mqtt.io/guide/adapters/#recommended Was testing Z2M with it, but I start to think of replacing ZBBridge with CC2652RB, so with USB it won't drop connection. And I will have a coordinator in home. Repeaters will need to reversally transfer signal from home to outside - I have a few IKEA Zigbee white bulbs outside of home. They are all routers so it works with no problem.

[MattWestb]

I have 2 CC-2531 but i dont using then now only in the beginning of the Zigbee eventure. I have one LIDL ZBGW and one tuya ZBGW that is hacked and one LIDL LED Light strips controller with one nice EFR32MG21 that is working very well. But for production i using IKEA modules "Billy EZSP" that working very good. Also using tuya ZBGW and Billys for sniffing Zigbee traffic and its working great.

One good thing with EZSP if you have more than 2 routers in your system is blocking the coordinator having direct children with:

    ezsp_config:
      CONFIG_MAX_END_DEVICE_CHILDREN: 0

The SonOff ZBB is having one very good Zigbee chip but its not calibrated in the factory and need the original signed firmware for working well with sleeping end device and the hardware is no so good (both the Zigbee module and the Sonoff PCB) is having problems. But many user having no problem with them.

Back to this case i dont knowing if its one firmware problem i the coordinator or if its not liking having only one end device and no routers. If having some Zigbee routers (lamps or outlet) it can being good adding some so the network is "living" then the coordinator is offline or being restarted.

[jacekk015]

CONFIG_MAX_END_DEVICE_CHILDREN

Can you explain more that setting?? I'm kind of happy of ZBBridge and don't have much problems - still thinking about it. Right now I've bought a cheap tablet from outlet for HA central steering.

[MattWestb]

First you need have at least one router added in your system (if not you cant adding any devices) and adding this in your HA config:

zha:
  zigpy_config:
    ezsp_config:
      CONFIG_MAX_END_DEVICE_CHILDREN: 0

You can having other then 0 but if you have 3 or more routers around the coordinator is better blocking it completely. Then you is opening the network for joining the coordinator is also open but if the joining device is one end device is the coordinator kicking it out and its trying with the next router.

I was killing one of my router by mistake in the small (TRV) test network (it was only having one router) and one end device was doing one checking and was not finding its parent and was trying the coordinator like one insane but it was not accepted but then the router was back online it was jumping back and working OK (i have adding 2 more routers now for better working test network).

I was 3 weeks on holiday in Spain and was taking the laptop with (its have my 2 test network in docker container) and after coming back and connecting the USB and starting the test HA all device was flagged online under one hour (80% sleeping end devices) then they have not losing the connection to the network then the coordinator was off line and the routers still working OK.

Sonoff ZBB can being very bad with most end device (normally IKEA controllers is draining there battery in 48 hours) and the best is running it with the factory EZSP 6.7.9.0 and have router around and if possible blocking it having direct children but still not 110% guarantee not triggering the bug in IKEA firmware.

The Sonoff Zigbee module looks being not so stable in the frequency (have no metal shield for the RF parts) and end device is having problem tuning frequency right in very short time they is not sleeping but routers is not having that problem then thy can adjusting the frequency all the time to all neighbours.

[jacekk015]

I have one IKEA repeater and one IKEA outlet as a routers. I can reprogram my CC2652RB to router firmware and stick it somewhere. 2 zigbee dimmers 230V are comming to me, probably tomorrow.

IKEA outlet behaves strange since I've started to add TRVs. It don't want to pair one more TRV and it has only 9 children. The connection is made ZBBridge -> repeater -> outlet - > TRVs [edit] checked logs - I do have older version

2021-12-08 12:24:02 INFO (MainThread) [bellows.zigbee.application] EmberZNet version: 6.7.6.0 build 327

BTW I have a very stable MESH WiFi network with Xiaomi AX3600 as a main router and a Redmi AX6 as a mesh NODE My HIKVISION video-intercom is networked by PoE over 20 meters outside my home, and two home panels are WiFi connected, so I don't have unstable network - I can't. BTW I'm IT engineer so it would be a bad if I couldn't do this myself ;-)

[MattWestb]

The last i have getting figuring out ;-))

It can being that IKEA have putting one limit in the Zigbee stack (nothing is infinite with resource in enabled devices) in the device but i have not hitting it then i have pretty much routers that working OK (after putting my HUE lights in the black box).

I think IKEA is not using maximum output power in the signal repeater firmware then its more stable (RF and CPU) if not heating the PA part of the chip but they is not only one routes then IKEA have more magic code for there blinds in it that we dont knowing how its working (they is binding the window clover cluster to one group with Light Link commands) that we cant do with normal Zigbee commands.

The recommended from Sonoff is the 6.7.9.0 and if you like flashing it its here https://github.com/arendst/Tasmota/tree/development/tools/fw_SonoffZigbeeBridge_ezsp (signed one for not hacked ZBB) but also dont change somthing that is working OK you is knowing ;-)

[jacekk015]

I just reprogrammed Slaesh CC2652RB and it was added to IKEA outlet with no problems. Maybe they just block end devices, a limit. Maybe those dimmers won't be needed, but if they come I'll try to automate the lights in daily room.

[MattWestb]

Maybe those dimmers won't be needed, but if they come I'll try to automate the lights in daily room.

😭

If the Dimmers i tuya is normally having good chips (Silabs MG1X or 21 series) and good hardware with exceptions.

[vincentlee20]

I am trying to reisntall the home assistant OS and everything. Hope it will work.

If it is the Zigbee stick issue, should I buy a new one or an Ikea switch/lamp will work for me? For a zigbee stick, any recommendation? I may then put sonoff stick as a router/repeater.

[MattWestb]

Deleting and reinstall ZHA is one good test.

The new generations TI sticks shall working OK with ZHA but have some strange problems. I think you shall testing upgrading the firmware before getting one new stick if you cant getting it working OK also after restarting ZHA.

You can also trying stopping HA and taking the stick out and waiting one minute and putting it back and starting HA (or if you is using one PI power it off and removing the stick).

I think baying one cheap light (IKEA 8€) or outlet (Not OSRAM ! ! ) and look is the stick like talking to it after restart of HA.

Sorry for jacekk015 and my writing little off topic things that happens with some teck freeks with both hard and software versions :-))

[vincentlee20]

after reinstalling everything, it looks working now. Will keep testing in the coming few days, and will further update.

Heard that previous discussion, it is around 20 devices support, and if we need to have another stick or what to support >20 devices? Thanks.

For light, do you guys buy a smart wall switch buy the individual bulbs? As lighting in a living room will contain more than one light bulb, it may seem costly if I buy 2-3 IKEA light bulbs. Alternatively, I am thinking a smart wall switch

Many thanks for all supporting me. Is there a supported product list so we can buy the compatible product? Thanks.

[MattWestb]

Great don and hope is staying stable !!

If you is having one CC-2530 or CC-2531 its normally getting large problems is having more than 20 devices and 50 its cant doing anything useful.

You new Zigbee stick with new TI chip shall not having any problem with 100 or more device if adding good routers and not mesing bad devices that messing al up.

With light is good if the switches can doing group binding so the light is working also then the host system is not online.

Good light switches is not easy finding (and if then is very expensive). IKEA controllers was working well but can draining batteries and most of them (not the new styrbar) have loosing group binding (but can doing device binding) with the last firmware update.

tuya is having some nice dimmer modules you can using in the wall and having "normal" switches that can being operated also if the host system is down but need doig little electrical connections in the wall box and having not so deep switches.

US have some very nice wall switches but i dont knowing how good they is working.

If you like have autonome light you shall not baying tuya TS0601 devices then they only working "online" (forgive my jacekk015 !!)

Also many "normal" switches / remotes is sending "clicks" and not commands for lights and need host system online ofr working.

Only large no go is OSRAM plugs that is corrupting packages and making problems with all devices in the network.

Philips HUE is very nice and expensive but also have some bad sides like they is not reporting there status and dont aging out children and neighbours that can making problems.

Look more how your TRV is working and if you like you can testing the new quirk that is adding more functions in ZHA GUI but its need testing and and likely some fixies for working 100% OK https://github.com/zigpy/zha-device-handlers/issues/1178#issuecomment-980294492

[vincentlee20]

Thanks Matt, I may go for the light bulb then, hopefully IKEA will provide some discount in its winter sale next week. By the way, what is autonome light?

[MattWestb]

Most TRVs have algorithms with hysteresis so they can still heating little after being "ON the setpoint" and also the algorithm need learning ho the heat demand for the room is so is not over or under shutting then start heating. My Kitchen TRV is normally heating very little but more after have open the balcony door for fresh air and going down then its have gettin the temperature OK (normal 10 cm of upper part warm and 100% cold back to the town). My TRVs dont have valve state so i cant saying how much its open but the i can see the calculated heating / idle and by touching the heater.

Zigbee light standard you can binding one or more remotes to one Zigbee group. Then putting the lights in the group and all is working also then HA is completely dead. I saying autonome = then its working without host system.

Some (most) switches cant doing binding (they is HA switches not light switches) so is not working then your system is down.

I have 2 killed SD-card on my R-PI and i like that the light is working then i coming home in the night.

I like baying kits from IKEA with one light or outlet with remote so can using them with my christmas light and plants lights and my neighbours is having problem getting there light on and off then the sun is rising and falling :-)))

[vincentlee20]

Yes, you are right, it seems it will be above 2.5c. Finally, it seems working. When I need it, I set the preset to Schedule, or away when out.

I am thinking if ZHA work with the IKEA gateway, so I can control the light even HA is down. If not, zigbee stick down (why HA down) will need to overall light failure.

[MattWestb]

If you have not setting any Schedule i think (= not knowing) the TRV is having some default one in its firmware after reset and paring and its can being little tricky then you must do the Schedule clocal on the device or on cluster or its dong its "own things" . And Away mode need extra info for working in the "Moes" TRVs. I think the easiest is putting down the setpoint in ZHA or do it with automations in .HA.

If you feel that the communication is working OK with the TRV you can trying one updated quirk that have more GUI implanted in ZHA but its still missing functions and need more tests and the "old one" you is using is stabile.

You can looking what @jacekk015 have doing here https://github.com/zigpy/zha-device-handlers/issues/1212#issuecomment-990213781 anf feel fre to testing if you like dut dont forgetting its cold outside if its not working OK ;-))

[vincentlee20]

The problem is intermittent, it can be resolved after reconnect. I am thinking if my USB stick is defective. May I know if there is any USB stick recommendeded?

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.