Open zett93 opened 12 months ago
I have the same problem. It says there should be only 4 temperature transitions (no more and no less!) and one of my valve sets not to 153.6 but 0 when the schedule hits idk why.
Hello, I have the same issue. Do u find any solution? Thanks
Hello. Same issue here. 2 x Avatto ME168 with SONOFF Zigbee 3.0 USB Dongle Plus. One ist setting 153.6 Β°C for target when switching to "auto", the other is setting 0Β°C for target. Beside that both devices often do not accept set commands, whether from "exposes" in Zigbee2MQTT or from changing the entity. LQI is around 50 for both devices. I am also very interested in a solution. Thanks.
Hello Koen, I have the same problem with Avatto [ME168] and Sonoff Zigbee 3.0 USB Dongle. The problem persists even though I brought the dongle close to the valves. The signal strength is now 96 to 160. A solution would be great! LG Micha
Same problem here: When the scheduler hits, I first see an mqtt message with a current_heating_setpoint with value "auto", and right after that a second message with a setpoint of 152.6 degrees. I'm using the latest Docker image (package.json says 1.33.2), zigbee dongle: Slaesh's CC2652RB stick.
Hello I also do have exactly the same issue with my new EM168 discovered device. Turning on "auto" mode results in target temperature 0.
As a workaround i created flow in NodeRED, that changes temperature values in heating mode. I smart-scheduler and function nodes, if someone is interested in, please comment, i'll share my code
I have exactly the same behawior as @zett93 described. I'm using SONOFF Zigbee 3.0 USB Dongle Plus-E. What I also noticed that my device do not match picture from z2m devices page. So it is detected as AVATTO ME168 but in reality it look like on picture from AVATTO ME167.
Z2M About: Zigbee Model: TS0601 Zigbee Manufacturer:_TZE200_p3dbf6qs Description: Thermostatic radiator valve IEEE Address: 0xa4c1381e73b5d3f6 Network address: 0x13F6 Manufacturer: AVATTO Model: ME168
@sychu - same situation with models and pictures
@sychu - same situation with models and pictures I also noticed that the description of schedule says 6 values ('HH:MM/C HH:MM/C HH:MM/C HH:MM/C HH:MM/C HH:MM/C'), but the setting is only saved if I set only 4 values ('HH:MM/C HH:MM/C HH:MM/C HH:MM/C')
I can confirm sychu, mine is also more looking like ME167
I can confirm @sychu - it says ME167 in my manual given with the valves. @zett93 the automation can be also very easily done with scheduler card but it would be nice to set it to the valve without HA interfeering
I have play around with this and it look like that main issue is that converter sends 4 values instead 6 (just like @ecotwist mentioned). I created custom converter which sends 6 values and it seem to work for me. I guessed some values for metadata days mappings. It work at least today (for Friday) but i have no idea what will happen tomorrows π. If anyone want to help with testing then I published fixed version here: https://github.com/sychu/avatto_me167_TZE200_p3dbf6qs/tree/main
I have play around with this and it look like that main issue is that converter sends 4 values instead 6 (just like @ecotwist mentioned). I created custom converter which sends 6 values and it seem to work for me. I guessed some values for metadata days mappings. It work at least today (for Friday) but i have no idea what will happen tomorrows π. If anyone want to help with testing then I published fixed version here: https://github.com/sychu/avatto_me167_TZE200_p3dbf6qs/tree/main
Just updated code so it should work for Fridays and Saturdays also π. Few more days to check.
I have play around with this and it look like that main issue is that converter sends 4 values instead 6 (just like @ecotwist mentioned). I created custom converter which sends 6 values and it seem to work for me. I guessed some values for metadata days mappings. It work at least today (for Friday) but i have no idea what will happen tomorrows π. If anyone want to help with testing then I published fixed version here: https://github.com/sychu/avatto_me167_TZE200_p3dbf6qs/tree/main
I can confirm that it does seem to work. The setpoint is way below 153ΒΊC now :)
I have play around with this and it look like that main issue is that converter sends 4 values instead 6 (just like @ecotwist mentioned). I created custom converter which sends 6 values and it seem to work for me. I guessed some values for metadata days mappings. It work at least today (for Friday) but i have no idea what will happen tomorrows π. If anyone want to help with testing then I published fixed version here: https://github.com/sychu/avatto_me167_TZE200_p3dbf6qs/tree/main
Just updated code so it should work for Fridays and Saturdays also π. Few more days to check.
I can also confirm that this works perfectly with my TZE200_p3dbf6qs/ - THX a lot for your fix @sychu
Just one small note to others - when adding the external converter record - use full filename including extension (.js) (README suggests it should be omitted )
i crashed my z2m...
[13:15:46] INFO: Preparing to start...
[13:15:47] INFO: Socat not enabled
[13:15:49] INFO: Starting Zigbee2MQTT...
Error: Cannot find module 'avatto_me167'
Require stack:
- /app/dist/util/utils.js
- /app/dist/util/settings.js
- /app/index.js
at Function.Module._resolveFilename (node:internal/modules/cjs/loader:1028:15)
at Function.Module._load (node:internal/modules/cjs/loader:873:27)
at Module.require (node:internal/modules/cjs/loader:1100:19)
at require (node:internal/modules/cjs/helpers:119:18)
at Object.getExternalConvertersDefinitions (/app/lib/util/utils.ts:173:25)
at getExternalConvertersDefinitions.next (<anonymous>)
at new ExternalConverters (/app/lib/extension/externalConverters.ts:12:20)
at new Controller (/app/lib/controller.ts:84:58)
at start (/app/index.js:106:18)
Error: Cannot find module 'avatto_me167'
That's what was I mentioning in my previous post - when adding external convertor name, include extension (.js) - _avattome167.js
That's why your z2m cannot find the file.
README is wrong on this in 3rd step of the installation guide
Edit: the instructions are already fixed by @sychu
@SirUlbrich Be carefull about right format and content of file you downloaded from github. And do not forget to extension.
For me this fix has solved problems! Thank you @sychu
avatto_me167
That's what was I mentioning in my previous post - when adding external convertor name, include extension (.js) - _avattome167.js
That's why your z2m cannot find the file. README is wrong on this in 3rd step of the installation guide
you posted after i did lol
Just one small note to others - when adding the external converter record - use full filename including extension (.js) (README suggests it should be omitted )
@michaljuris thx for spotting this mistake, I fixed this and also tweaked converter so it will match only _TZE200_p3dbf6qs. Now it should not impact other devices.
how did i change the external? GUI not open anymore. reinstall not working too =(
edit: found in configuration.yaml
how did i change the external? GUI not open anymore. reinstall not working too =(
you need to open configuration.yaml and edit it manually there
external_converters:
- avatto-me168.js
how did i change the external? GUI not open anymore. reinstall not working too =(
@SirUlbrich use File Editor. Open /homeassistant/zigbee2mqtt/configuration.yaml
and look for
external_converters:
- avatto-me168.js
how did i change the external? GUI not open anymore. reinstall not working too =(
@SirUlbrich use File Editor. Open
/homeassistant/zigbee2mqtt/configuration.yaml
and look forexternal_converters:
- avatto-me168.js
thx both of you. i found in configuration by samba
@sychu did you delete battery low? in code i see:
tuyaDatapoints: [
[2, 'system_mode', tuya.valueConverterBasic.lookup({'auto': tuya.enum(0), 'heat': tuya.enum(1), 'off': tuya.enum(2)})],
[3, 'running_state', tuya.valueConverterBasic.lookup({'heat': tuya.enum(0), 'idle': tuya.enum(1)})],
[4, 'current_heating_setpoint', tuya.valueConverter.divideBy10],
[5, 'local_temperature', tuya.valueConverter.divideBy10],
[7, 'child_lock', tuya.valueConverter.lockUnlock],
[28, 'schedule_wednesday', fixedValueConverter.thermostatScheduleDayMultiDPWithDayNumber(1)],
[29, 'schedule_thursday', fixedValueConverter.thermostatScheduleDayMultiDPWithDayNumber(2)],
[30, 'schedule_friday', fixedValueConverter.thermostatScheduleDayMultiDPWithDayNumber(3)],
[31, 'schedule_saturday', fixedValueConverter.thermostatScheduleDayMultiDPWithDayNumber(4)],
[32, 'schedule_sunday', fixedValueConverter.thermostatScheduleDayMultiDPWithDayNumber(5)],
[33, 'schedule_monday', fixedValueConverter.thermostatScheduleDayMultiDPWithDayNumber(6)],
[34, 'schedule_tuesday', fixedValueConverter.thermostatScheduleDayMultiDPWithDayNumber(7)],
[35, null, tuya.valueConverter.errorOrBatteryLow],
[36, 'frost_protection', tuya.valueConverter.onOff],
[39, 'scale_protection', tuya.valueConverter.onOff],
[47, 'local_temperature_calibration', tuya.valueConverter.localTempCalibration2],
row 35, "null"
r ow 35, "null"
@SirUlbrich no, but it's interesting. I will check history for this line in original repo.
@sychu's fix did fixed my issue also. Thank you!
@sychu mine too except one valve, that goes to 0 degrees tonight... i'll observe and check what was that
Dear all, thx, the converter have fixed my issue too. @sychu - In addition the AVATTO ME167, listed below, does really only accept 4 schedules a day but the z2m gui configuration example is showing 6 schedules (Schedule for monday, format: "HH:MM/C HH:MM/C HH:MM/C HH:MM/C HH:MM/C HH:MM/C") "device": { "applicationVersion": 67, "dateCode": "", "friendlyName": "xxx", "hardwareVersion": 1, "ieeeAddr": "xxx", "manufacturerID": 4417, "manufacturerName": "_TZE200_6rdj8dzm", "model": "ME167", "networkAddress": xxx, "powerSource": "Battery", "stackVersion": 0, "type": "EndDevice", "zclVersion": 3 }
Thanks to all for your Work! and have a good Christmas time
@sychu could you create a PR to integrate this fix?
@sychu could you create a PR to integrate this fix?
does anyone have tested this fix with ME168 ? can i give it a try ?
@TrolliRolli Fixed converter sends 6 values instead 4 and it is matching only _TZE200_p3dbf6qs. Are You sure that You applied external converter for Yours_TZE200_6rdj8dzm?
@sychu could you create a PR to integrate this fix?
@Koenkk sure i can try, but i tested it only with TZE200_p3dbf6qs so it look like it should be separate definition for this device?
@pgarnek
does anyone have tested this fix with ME168 ? can i give it a try ?
Sure just tweak script to match Yours device, in script uncomment line 69 and line 79 . Ensure that manufacturer match yours device
_TZE200_rxntag7i
. Let us know if it worked :-)
the thing is, i see my device as _TZE200_p3dbf6qs, but model (officialy) is ME168.... strange
i suspect, i should focus on the "_TZE200_p3dbf6qs", right ? :-)
@pgarnek It is exactly fix for Yours device. Please read description https://github.com/sychu/avatto_me167_TZE200_p3dbf6qs?tab=readme-ov-file#avatto_me167_tze200_p3dbf6qs
By default device _TZE200_p3dbf6qs is recognized by zigbee-herdsman-converters as ME168 but in fact it is ME167
After applying this external converter device will be matched properly to ME167
i've missed that, sorry. Thanks, i'll try and let know if everything goes well
As a workaround i created flow in NodeRED, that changes temperature values in heating mode. I smart-scheduler and function nodes, if someone is interested in, please comment, i'll share my code
Yes, I'm interested.
@sychu Can you prepare PR?
I have play around with this and it look like that main issue is that converter sends 4 values instead 6 (just like @ecotwist mentioned). I created custom converter which sends 6 values and it seem to work for me. I guessed some values for metadata days mappings. It work at least today (for Friday) but i have no idea what will happen tomorrows π. If anyone want to help with testing then I published fixed version here: https://github.com/sychu/avatto_me167_TZE200_p3dbf6qs/tree/main
The custom converter is no longer compatible with the latest zigbee2mqtt, so I will try to turn this into a PR now
I created the PR now, but I need some input from the other people here - did anyone try this patch and had to to change the fingerprint? If so speak up now so we can change the PR to support the other fingerprints as well. I can only test my own one.
(sorry for the duplicate notification, wrong account)
Hi, I have same issue, ME168 detected while I have ME167. I tried @sychu solution but submitting avatto-me168.js files I have an error : external converter must be array. Any idea please ? Thanks π
@StefanLobbenmeier If you still need help (I'm guessing so, since the PR isn't merged yet - but it's also a few months old by now). However, I don't really know how to check out your PR on my setup and how to test it out. I use homeassistant with zigbee2mqtt.
Hello nice people, thank you so much for this script @sychu !
I was wondering if it is possible to disable scheduling altogether and only use automation to change the temperature. When disabling the schedule in MQTT Devices, it just hides them from the UI, but they get still executed.
Yeah I mostly need someone more knowledgeable to resolve the failing test there. But there is another PR now so hopefully they will take care of it.
disable scheduling altogether
scheduling is easy to disable, click the button to hide the βclockβ symbol in the device itself or in home assistant set the device from automatic to heating
@StefanLobbenmeier thanks for the advice, I can't seem to find the "clock" symbol, neither in Zigbee2MQTT -> Device nor in Settings -> Devices & Services -> MQTT Devices -> Device
I will try setting it to heating, I just expected the heater not to automatically shut off when the temperature is reached, if I manually set it to heating. But I will give it a try. Maybe the setting is just confusingly named.
Unfortunately, the solution with the converter no longer works with a current zigbee2mqtt version and the PR is open. How can I solve the problem at the moment? Unfortunately, I cannot use the thermostat like this.
@richert-addisca i meant on the physical device itself there is a clock led glowing when the schedule is activated
What happened?
Hi!
I recently purchased several Avatto thermostatic valves. Everything works fine except for one stupid thing: When I change from heating to automatic, the temperature at my valve always increases to 153.6 degrees.
Changing the hours or temperatures doesn't change anything. I use SONOFF Zigbee 3.0 USB Dongle Plus ZBDongle-P.
The problem was reproduced on my 7 ME168 valves. Always the same.
Below I have pasted an example schedule from my z2m configuration:
00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0
And some logs from my z2m (after setting a schedule)
Look at the last line.
Regards!
What did you expect to happen?
I expected that my schedule will set proper temperature :)
How to reproduce it (minimal and precise)
Just set values on the valve (e.q. via "exposes" tab in z2m, or via MQTT
zigbee2mqtt/FRIENDLY_NAME/set
Zigbee2MQTT version
1.33.2 commit: 311ea07
Adapter firmware version
20210708
Adapter
SONOFF Zigbee 3.0 USB Dongle Plus ZBDongle-P
Debug log
debug 2023-11-20 14:55:37Publishing 'set' 'schedule_monday' to 'termostat-gabinet' debug 2023-11-20 14:55:39Received MQTT message on 'zigbee2mqtt/termostat-gabinet/set' with data '{"system_mode":"auto"}' debug 2023-11-20 14:55:39Publishing 'set' 'system_mode' to 'termostat-gabinet' info 2023-11-20 14:55:40MQTT publish: topic 'zigbee2mqtt/termostat-gabinet', payload '{"battery_low":false,"child_lock":"UNLOCK","current_heating_setpoint":21,"error":null,"frost_protection":"OFF","linkquality":75,"local_temperature":21,"local_temperature_calibration":0,"running_state":"heat","scale_protection":"OFF","schedule_friday":"00:00/16.0 07:00/19.0 09:00/20.0 18:00/18.0","schedule_monday":"00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0","schedule_saturday":"00:00/16.0 08:00/18.0 10:00/20.0 18:00/18.0","schedule_sunday":"00:00/16.0 08:00/18.0 10:00/20.0 18:00/18.0","schedule_thursday":"00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0","schedule_tuesday":"00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0","schedule_wednesday":"00:00/16.0 07:00/19.0 09:00/20.0 18:00/18.0","system_mode":"heat"}' debug 2023-11-20 14:55:40Received Zigbee message from 'termostat-gabinet', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[1,0,0,0,160,7,0,0,180,15,0,0,190,18,0,0,180],"type":"Buffer"},"datatype":0,"dp":28}],"seq":19712}' from endpoint 1 with groupID 0 info 2023-11-20 14:55:40MQTT publish: topic 'zigbee2mqtt/termostat-gabinet', payload '{"battery_low":false,"child_lock":"UNLOCK","current_heating_setpoint":21,"error":null,"frost_protection":"OFF","linkquality":69,"local_temperature":21,"local_temperature_calibration":0,"running_state":"heat","scale_protection":"OFF","schedule_friday":"00:00/16.0 07:00/19.0 09:00/20.0 18:00/18.0","schedule_monday":"00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0","schedule_saturday":"00:00/16.0 08:00/18.0 10:00/20.0 18:00/18.0","schedule_sunday":"00:00/16.0 08:00/18.0 10:00/20.0 18:00/18.0","schedule_thursday":"00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0","schedule_tuesday":"00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0","schedule_wednesday":"00:00/16.0 07:00/19.0 09:00/20.0 18:00/18.0","system_mode":"heat"}' info 2023-11-20 14:55:40MQTT publish: topic 'zigbee2mqtt/termostat-gabinet', payload '{"battery_low":false,"child_lock":"UNLOCK","current_heating_setpoint":21,"error":null,"frost_protection":"OFF","linkquality":69,"local_temperature":21,"local_temperature_calibration":0,"running_state":"heat","scale_protection":"OFF","schedule_friday":"00:00/16.0 07:00/19.0 09:00/20.0 18:00/18.0","schedule_monday":"00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0","schedule_saturday":"00:00/16.0 08:00/18.0 10:00/20.0 18:00/18.0","schedule_sunday":"00:00/16.0 08:00/18.0 10:00/20.0 18:00/18.0","schedule_thursday":"00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0","schedule_tuesday":"00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0","schedule_wednesday":"00:00/16.0 07:00/19.0 09:00/20.0 18:00/18.0","system_mode":"auto"}' debug 2023-11-20 14:55:40Received Zigbee message from 'termostat-gabinet', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0],"type":"Buffer"},"datatype":4,"dp":2}],"seq":19968}' from endpoint 1 with groupID 0 info 2023-11-20 14:55:40MQTT publish: topic 'zigbee2mqtt/termostat-gabinet', payload '{"battery_low":false,"child_lock":"UNLOCK","current_heating_setpoint":21,"error":null,"frost_protection":"OFF","linkquality":69,"local_temperature":21,"local_temperature_calibration":0,"running_state":"heat","scale_protection":"OFF","schedule_friday":"00:00/16.0 07:00/19.0 09:00/20.0 18:00/18.0","schedule_monday":"00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0","schedule_saturday":"00:00/16.0 08:00/18.0 10:00/20.0 18:00/18.0","schedule_sunday":"00:00/16.0 08:00/18.0 10:00/20.0 18:00/18.0","schedule_thursday":"00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0","schedule_tuesday":"00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0","schedule_wednesday":"00:00/16.0 07:00/19.0 09:00/20.0 18:00/18.0","system_mode":"auto"}' debug 2023-11-20 14:55:59Received Zigbee message from 'termostat-gabinet', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,6,0],"type":"Buffer"},"datatype":2,"dp":4}],"seq":20224}' from endpoint 1 with groupID 0 info 2023-11-20 14:55:59MQTT publish: topic 'zigbee2mqtt/termostat-gabinet', payload '{"battery_low":false,"child_lock":"UNLOCK","current_heating_setpoint":153.6,"error":null,"frost_protection":"OFF","linkquality":66,"local_temperature":21,"local_temperature_calibration":0,"running_state":"heat","scale_protection":"OFF","schedule_friday":"00:00/16.0 07:00/19.0 09:00/20.0 18:00/18.0","schedule_monday":"00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0","schedule_saturday":"00:00/16.0 08:00/18.0 10:00/20.0 18:00/18.0","schedule_sunday":"00:00/16.0 08:00/18.0 10:00/20.0 18:00/18.0","schedule_thursday":"00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0","schedule_tuesday":"00:00/16.0 07:00/18.0 15:00/19.0 18:00/18.0","schedule_wednesday":"00:00/16.0 07:00/19.0 09:00/20.0 18:00/18.0","system_mode":"auto"}'