Closed GaryJScott closed 1 week ago
git-tail-d
commented
7 months ago Hello,
You have misinterpreted the times.
01:00/20 10:00/18 24:00/20 means that 20 degrees are set from midnight until 01:00, 18 degrees from 01:00 to 10:00 and 20 degrees from 10:00 to 24:00.
If 18 degrees are to be set from 10:00 to 24:00, change 01:00/20 10:00/18 24:00/20 to 01:00/20 10:00/18 24:00/18
GaryJScott
commented
7 months ago Ah apologies, I can see the logic in that the segment temperature points backwards to the previous segment time. I had assumed it pointed forward which is more natural and the way a traditional timer would work i.e. at a time set the temperature going forward.
github-actions[bot]
commented
1 month ago This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days
What happened?
A schedule is configured on the device and the preset is set to “auto” so that it is activated. At the segment time the new temperature is set according to the next segment temperature instead of the current segment temperature.
Shown in the attchment is a formatted extract from the log showing: Time of log entry (12:44) The temperature setpoint at that time (20) The temperature that should be set (18 between 10:00 and 24:00)
What did you expect to happen?
The correct temperature for the segment should be set.
How to reproduce it (minimal and precise)
Setup a new schedule with (say) 10 minute spacing with different temperature settings. Observe the log (and an actual valve) over time to see the actual temperatures being applied. You will see at each scheduled time the 'next' segment time will be applied rather than the current as specified.
Zigbee2MQTT version
1.35.1
Adapter firmware version
20210708
Adapter
Sonoff zigbee 3.0 USB Dongle plus
Setup
Pi4, Docker, containers with Z2M, mosquitto and nodered.
Debug log
No response