danfoss: Add thermostat schedule support

[kennylevinsen]

Note that I have not tested the popp/hive side of things.

[Koenkk]

Please move this expose to exposes.js, could you also improve the description?

[kennylevinsen]

Please move this expose to exposes.js

As its own thing or as another withXyz on the climate expose?

could you also improve the description

Sure, but it will be a little wordy.

[Koenkk]

As its own thing or as another withXyz on the climate expose?

Own thing

Sure, but it will be a little wordy.

No problem, no need to keep things short there.

[Koenkk]

Looks good to me, if you can fix the merge conflict I can merge it.

[kennylevinsen]

Sorry for the delay, rebased!

[2Max2Pax]

Is this issue still open?

I 'm using Zigbee2MQTT version: 1.22.2 commit: 414c51f
In the "dev console" the attribute weekly_schedule (or thermostat_weekly_schedule ) is missing.
What is the correct way (and mask) to set the weekly schedule and read it back?

[kennylevinsen]

It is merged and works. You set weekly_schedule over mqtt as an object that looks something like:

{
   days: 0b1111111, // bitmask of days
   mode: 0x1, // heat mode
   transitions: [ // times are minutes since midnight
      {transitionTime: 660, heatSetpoint: 21.5},
      {transitionTime: 1200, heatSetpoint: 18.0},
   ]
}

Remember to change the programming operation mode to schedule for it to work.

[2Max2Pax]

@kennylevinsen , thank you for the answer.
I published topic:

zigbee2mqtt/trv_studio/set/weekly_schedule

Payoload:

{"days": 0b1111111, "mode": 0x1, "transitions": [{"transitionTime": 660, "heatSetpoint": 21.5},{"transitionTime": 1200, "heatSetpoint": 18.0},]}

Tested also without the comma before ]
I got the following error:

Publish 'set' 'weekly_schedule' to 'trv_studio' failed: 'TypeError: payload.transitions is not iterable'

I also tryed adding "numoftrans":2 to the payload but I always get the same error

[kennylevinsen]

For reference, this is the code snippet I used:

const setSchedule = (schedule, days, radiator) => {
	console.log("Setting schedule" + (radiator ? " for " + radiator.key : ""), schedule);
	if (!days) {
		return;
	}

	for (let room_type in schedule) {
		let transitions = schedule[room_type];
		let payload = {
			dayofweek: days, // Already a bitmask
			mode: 0b01,      // Heating
			transitions: transitions.map(t => ({
				transitionTime: timeFromMidnight(t.time),
				heatSetpoint: t.temp,
			})),
		};
		payload.numoftrans = payload.transitions.length; // This should just be deduced by z2m...
		radiatorsForType(room_type)
			.filter(r => !radiator || radiator.key === r)
			.forEach(r => client.publish(r + "/set", JSON.stringify({
				weekly_schedule: payload,
				programming_operation_mode: "schedule",
			})));
	};
};

The error you are getting would be from here, and seems to suggest that either there is no field named "transition" in what you sent, or it is not an array.

If you are sure that you are sending a well-formed JSON serialized message (remember to JSON.stringify), maybe add a log there to see if what the payload contains?

[2Max2Pax]

I publish MQTT with mosquitto.
I made several tests, changing the value of days: , with or without comma before] in the topic
This is what i get subscribing the topic " zigbee2mqtt/#" :

zigbee2mqtt/trv_studio/set/weekly_schedule {"days": 0b1111111, "mode": 0x1, "transitions": [{"transitionTime": 660, "heatSetpoint": 21.5},{"transitionTime": 1200, "heatSetpoint": 18.0},]}
zigbee2mqtt/bridge/logging {"level":"error","message":"Publish 'set' 'weekly_schedule' to 'trv_studio' failed: 'TypeError: payload.transitions is not iterable'"}

I do not use java, so I do not use stringify.

in the whole log file, all the entries about weekly schedule look like:

�[31mZigbee2MQTT:error�[39m 2022-01-17 15:43:57: Publish 'set' 'weekly_schedule' to 'trv_studio' failed: 'TypeError: payload.transitions is not iterable'

[kennylevinsen]

If that is what z2m is logging, then what you are sending is not valid JSON. What I quoted is JavaScript, and you need to serialize it as JSON first.

It should be enough to convert the binary and hex notated numbers to decimal and remove the trailing comma.

[2Max2Pax]

Oooops, you are right. I just realized that in the test with decimal I made a typo ... corrected. No errors anymore.

Now, I still miss 2 points:

1. How can I read back the weekly schedule?
2. If I want to make a different schedule for each day (or group of days) of the week, should I publish as many payloads as the dyas or group of days?

[kennylevinsen]

1. You should be able to "get" the field as well.
2. Yes, write per schedule group you need. Note that any day included in a write is wiped of its previous schedule - there can only be one.

[2Max2Pax]

I made some tests and I could not find a way to read back the weekly schedule. I suppose I do not use the correct payload or Z2M doesn't get correct data or doesn't expose it at all.

I noticed that I cannot set more than 6 transitions: Z2M doesn't return any error but the TRV simply doesn't apply any transition.
Changing numberOfWeeklyTrans and/or numberOfDailyTrans in the dev.console generates the following error:

Publish 'set' 'write' to 'trv_studio' failed: 'Error: Write 0x804b50fffe3da0a8/1 hvacThermostat({"numberOfDailyTrans":6,"numberOfWeeklyTrans":42}, {"sendWhenActive":true,"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'READ_ONLY')'

So there is no chance to use 7 or more transistions.

I'm going to test separate weekly schedule for today and tomorrow and see if it works.

[kennylevinsen]

The numberOfXYZTrans fields tell you what the device limitation is - they are not something you can change. Doing more than 6 transitions in a day does seem aggressive for a thermostat considering the thermal mass of a room/home.

As for getting the weekly schedule, that may be a device bug. I recall someone saying that Danfoss thermostats only reply with their weekly schedule when asked solely for heat schedule, instead of all schedules as z2m asks. Not something I have tested. Would require a Danfoss quirk.