Issue setting the "Comfort Temperature" for MTS100 TRV within an automation in Home Assistant

[TakeMeds]

Issue setting the "Comfort Temperature" for MTS100 TRV within an automation in Home Assistant

msh300 4.0.0 : Firmware: 4.1.35 : Hub 8x mts100v3 TRV's

Can you help me with this ? I have an automation running that turns on/off individual TRVs depending on room temperature sensors, discrete window open detectors and time schedules. This all works fine. When HVAC is turned on by the automation, the radiator attempts to heat until the TRV reaches the comfort temperature setting that has been set in the App.

I am trying to set the TRV comfort temperature within HA, with the following YAML

• service: number.set_value data_template: entity_id: number.smart_thermostat_living_room_01002f34_comfort_temperature value: "{{ states('input_number.h_lr_xx_temp_target') }}"

This too works, but causes havoc ..... It works to the degree that the comfort temperature does change to the value of the helper 'input_number.h_lr_xx_temp_target', however the following issues occur:- The TRV itself goes 'offline' for 2 to 3 minutes. My zigbee network (Sonoff hub) loses connection with sensors, this is random, this only happens when that YAML code is used. Eventually, the TRVs go off line and require the YAML code to be removed and the Hub restarted.

Any ideas ... ?

Thanks Rab

[TakeMeds]

EDIT: a little more experimentation suggests it may well not be the automation itself. If I create a card within HA, and show the TRV entities eg "temperature calibration" or "comfort temperature" (Heat), Then if I change the value of the entity on the card: 'All' the TRVs go "unavailable" for 2 minutes. When they return, the change has been registered.
Going "unavailable" clearly is an issue. Yesterdays problem would be the automation talking to each of the 8 TRVs at 5 minute intervals , and every time all the TRVs going offline and perhaps never really getting a change to go back online, with this level of 'chat' taking the network down ?

thanks Rab

[krahabb]

Well (sorry for being late..) this looks like an interference issue on the RF channel even though the zigbee radio channel should be really far from the claimed Meross hub RF (which is 433 Mhz per spec) which is used by the hub to reach out to the TRVs.

At any rate, if it were an interference issue I would expect any command issued to the valves would 'disrupt' the sonoff...

I can't really figure out a reasonable cause for this behavior but, for starting, you could try capture the hub 'diagnostic' while issuing the offending commands so we can see if anything goes wrong (or not) while meross_lan tries to send these commands

[TakeMeds]

Hi, Thanks for getting back to me. As is the way with computers and especially HA, over the weekend, it apparently got better, but is back to being troublesome this morning ??? Rebooting my home mesh networked ( 4x eero ) helped. I am not entirely convinced its 2.4GHz networking works well with IoT. I also put some distance between the Meross hub and the Sonoff hub, and I have not seen any further issue between them. I did try to see the diagnostics ( from the option in pic 4 ), but I get an 401 unauthorised error ?
Pics 2-4 show the errors as I see them. The current situation is that, when I try and change the 'TRV on target temp' (comfort temp) I do still get the TRVs going unavailable for a short duration, but oddly it is just the battery status that does not come back online. The card shown in pic one, has no automations and is simply created from the entities exposed by the integration.

Cheers

[krahabb]

Hello @TakeMeds, Thank you for the follow up.

• the 'signature error' happens randomly (some other users also reporting this sporadically) in my tests too: can't really figure out if the error is in the device generating a wrong key or in meross_lan verification. Last version of meross_lan (at the moment I don't remember if the patch already went into production) is adding some more context informations to the log in order to try better identify the reason for the error but, in current state, it is just a small 'glitch' (unavoidable though)
• the battery level gets polled once in a while so that's why it is still unavailable when the TRV comes back online. Nevertheless I need to investigate why it is not refreshed soon after the device comes back online (which should)
• the diagnostic is a bit tricky and doesn't work (you get the error) when you access that through a kind of proxy (Nabu Casa redirection included). Is this your case? When correctly working anyway, the diagnostic is not readily available but is collected 'on demand' and the response file will be sent to the browser later (around 10 minutes depending on meross_lan device configuration). If you still have issues with this you can use the 'tracing' feature (which collects the same data) from the meross_lan device/integration configuration entry

[krahabb]

Closing as being stale for too long