Closed ericvb closed 1 year ago
Hello, I noticed the same problem and I modified the composite. I made 2 composites and it works. It's not pretty, I know. and since version 127.1 the fields are no longer filled in by default. It was convenient....
I think this issue is about the same problem...
Hello, I noticed the same problem and I modified the composite. I made 2 composites and it works. It's not pretty, I know. and since version 127.1 the fields are no longer filled in by default. It was convenient....
Hi, i have the same problem with my TS0601, can you explain how you made these "2 composites"? My zigbee skills are very low an i only want to solve this problem, thankx
/opt/zigbee2mqtt/node_modules/zigbee-herdsman-converters/devices $ sudo nano tuya.js
find: zigbeeModel: ['kud7u2l'], fingerprint: [ {modelID: 'TS0601', manufacturerName: '_TZE200_ckud7u2l'}, {modelID: 'TS0601', manufacturerName: '_TZE200_ywdxldoj'}, {modelID: 'TS0601', manufacturerName: '_TZE200_cwnjrr72'}, {modelID: 'TS0601', manufacturerName: '_TZE200_pvvbommb'}, {modelID: 'TS0601', manufacturerName: '_TZE200_9sfg7gm0'}, // HomeCloud {modelID: 'TS0601', manufacturerName: '_TZE200_2atgpdho'}, // HY367 {modelID: 'TS0601', manufacturerName: '_TZE200_cpmgn2cf'}, {modelID: 'TS0601', manufacturerName: '_TZE200_4eeyebrt'}, // Immax 07732B ], model: 'TS0601_thermostat', vendor: 'TuYa', description: 'Radiator valve with thermostat',
and replace EXPOSE by this
exposes: [
e.child_lock(), e.window_detection(),
exposes.binary('window_open', ea.STATE).withDescription('Window open?'),
e.battery_low(), e.valve_detection(), e.position(),
exposes.climate().withSetpoint('current_heating_setpoint', 5, 35, 0.5, ea.STATE_SET)
.withLocalTemperature(ea.STATE).withSystemMode(['heat', 'auto', 'off'], ea.STATE_SET,
'Mode of this device, in the heat
mode the TS0601 will remain continuously heating, i.e. it does not regulate ' +
'to the desired temperature. If you want TRV to properly regulate the temperature you need to use mode auto
' +
'instead setting the desired temperature.')
.withLocalTemperatureCalibration(-9, 9, 1, ea.STATE_SET)
.withPreset(['schedule', 'manual', 'boost', 'complex', 'comfort', 'eco'])
.withRunningState(['idle', 'heat'], ea.STATE),
e.auto_lock(), e.away_mode(), e.away_preset_days(), e.boost_time(), e.comfort_temperature(), e.eco_temperature(), e.force(),
e.max_temperature(), e.min_temperature(), e.away_preset_temperature(),
exposes.composite('programming_mode').withDescription('Schedule MODE ⏱ - In this mode, ' +
'the device executes a preset week programming temperature time and temperature.')
.withFeature(e.week())
.withFeature(exposes.text('workdays_schedule', ea.STATE_SET)),
exposes.composite('programming_mode').withDescription('Schedule MODE ⏱ - In this mode, ' +
'the device executes a preset week programming temperature time and temperature.')
.withFeature(e.week())
.withFeature(exposes.text('holidays_schedule', ea.STATE_SET))
],
and reload MQTT
It's not pretty..... but .....it's ok
thank you! so my zigbee2mqtt runs in a docker container by homeassistent and it's quite hard for me to manipulate that image without destroying everything... So i will wait for someone smarter when me to fix this :-)
So if it's helping someone. I get this error message in homeassistent then i try to set the time/temperature pairs. Only in the v1.29.2-1 edge version:
No converter available for 'programming_mode' ({"holidays_schedule":"08:30/22°C 10:30/18°C 13:00/18°C 18:00/18°C 21:00/18°C 23:00/16°C","week":"5+2","workdays_schedule":"06:30/22°C 08:30/18°C 13:00/18°C 18:00/18°C 21:00/18°C 23:00/16°C"})
the stable version reports no error an do also not set "workdays_schedule" only "holidays_schedule"
There is some regression apparently in the latest version from the DEV branch. If this goes unnoticed into the next release, we have a problem for this device and maybe other devices also, if the problem resides in basic code. @Koenkk, what can we do to help?
hello,
I agree, do not make changes in the sources.
Here is the list of problems.
Another issue #16328 related to the same problem?
Same here. No converter available for 'programming_mode'
- A display problem for the Week/Holiday/workday fields. It works until version 1.27.0 and not in 1.27.1 at now. (info present in "STATUS").
I tested it with a 1.27.0 proxy version and i could not reproduce it to work with the current (2023.2.3) homeassistent version.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
I would say this is still valid, I still get the "No converter available".
It looks like it's 100% reproducibility with TS0601 - confirming I got the same behavior with latest Zigbee2mqtt version. Basically, it prevents from the possibility of editting the schedule. Anybody who decided to use HA/Zigbee2mqtt instead of crappy native Tuya APP will not be able to customize the schedule on the TRV. Kinda severe issue from the functionality standpoint.
It looks like it's 100% reproducibility with TS0601 - confirming I got the same behavior with latest Zigbee2mqtt version. Basically, it prevents from the possibility of editting the schedule. Anybody who decided to use HA/Zigbee2mqtt instead of crappy native Tuya APP will not be able to customize the schedule on the TRV. Kinda severe issue from the functionality standpoint.
Yes, that's right. So I still use version 1.28.2-1 Schedule doesn't work in later versions.
I reported a few more problems here: https://github.com/Koenkk/zigbee2mqtt/issues/15903#issue-1516836975 (first post). The other problems I reported there are not z2m related...
This bug seems to be still present in 1.30.3 :-(
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
Still present in 1.30.4
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
Still present in 1.31.2-1
@mrwogu, thank you for testing this each time. An annoying bug...
@Koenkk, is this unwanted behavior globally for the TS0601 type thermostat or just for a particular brand? The problem appears not be in basic code, I don't see other issues describing the same problem, so it must be more specific to the type of hardware. Can we do something to help to debug this issue?
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
The problem is still present in 1.32.2-1, but I've no possibility to reopen this ticket? The screen misses now also the labels workdays_schedule and holidays_schedule! When clicking on the button 5+2, following error:
same at me
The winter is coming again for the northern earth side, so I will take the time to test this again :-) Probably I will recreate a new ticket linked to this one, because I can't open this one who was closed by this da... bot. Maybe there is already a new one based on this one?
I was at the same point when I realize it needs different topic, different from the other commands correct is "zigbee2mqtt/friendly_name/set/schedule"
then I use service in HA, MQTT publish
yaml code:
service: mqtt.publish
data:
topic: zigbee2mqtt/TRV spalna/set/schedule
payload: >-
{ "workdays":[ {"hour":6,"minute":0,"temperature":15},
{"hour":8,"minute":0,"temperature":15},
{"hour":17,"minute":30,"temperature":17},
{"hour":20,"minute":30,"temperature":20},
{"hour":22,"minute":0,"temperature":20},
{"hour":23,"minute":30,"temperature":20} ] }
note: you can change time and temperature in each time slot, but leave all 6, don´t delete even one
Seems like a long standing issue with no one really solving it. If it just takes the command to be fixed, it shouldn't be such a big deal, or?
probably here : https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/src/devices/tuya.ts (line 2544) and here : https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/src/lib/legacy.ts (line 7563) but have no experience here...
A follow up. After installing the new release of the Zigbee2MQTT 1.35.0-1, I see a correct representation of the schedules. Probably due to this correction: https://github.com/nurikk/zigbee2mqtt-frontend/pull/1851
But now I don't see the Week options, they are gone : 5+2, 6+1 and 7 options Before: After installing latest version:
Edit 2024-01-08 A correction in a next version, is done by KoenK and will correct the missing Week option.
After updating zigbee2mqtt from version 1.24.0.1 to version 1.35.0.1. the setting of the TUYA TS0601 thermostatic head has changed. Current temperature, desired temperature and % valve opening are not shown. Do you have any solution? Thank you
@stockno, are you running the latest HA version? The printscreens are the old HVAC cards.
I have installed the latest HA version and then you get this:
I had everything up to date. But I tried again, but this time in a different order. I updated HA first and then zigbee2mqtt. And now everything works for me. The problem was in the order of the updates
What happened?
Was trying to set the schedules in the programming mode, but the default workdays_schedule was never changed after clicking on apply. The week and holidays_schedule were adapted.
What did you expect to happen?
In the logfile of Z2M I saw this, a payload with 3 items, but only 2 sets?:
I expected a third line: Zigbee2MQTT:debug 2023-01-14 15:38:22: Publishing 'set' 'workdays_schedule' to 'Badkamer venster' But this was not generated.
So I did a manual test via the option to publish manually a packet. I reconstructed the same payload, but now in a different order.
The result was this:
Now the holidays_schedule was not updated. I played a little with the order and always only the first 2 items were set.
How to reproduce it (minimal and precise)
Construct manually a topic and payload and publish it.
Zigbee2MQTT version
1.29.2-1
Adapter firmware version
20220219
Adapter
CC2652P2 TCP ZigBee Coordinator V0.2 cod.m
Debug log