Danfoss Ally and weekly schedule/time issues

Hardware
, ,
1

I have recently expanded my system with a zigbee bus and 7 Danfoss Ally TRV.
I am using zigbee2mqtt and a tasmotized Sonoff device. The devices all have the same firmware (01.18.0008 01.18).
The achievement so far is that I am able to control temperature of the radiators in a very accurate way (I tried SASWELL devices previously, but they were not as precise as the Danfoss).

I wanted to share how I’ve setup the internal scheduler and the struggles I have faced.

In order to manually and easily control the valves, I am issuing these commands over MQTT:

  • set an arbitrary temperature setpoint (as a payload to zigbee2mqtt/DEVICE/set):
{"occupied_heating_setpoint" : 15}
  • make sure the TRV is working on a setpoint:
{"programming_operation_mode": "setpoint" }
  • to clean previous programming:
{"clear_weekly_schedule": 0 }
  • program with a set of time buckets to see where the valve will “land”:
{"weekly_schedule":{"dayofweek":62,"mode":1,"numoftrans":6,"transitions":[{"heatSetpoint":24.5,"transitionTime":0},{"heatSetpoint":25.5,"transitionTime":240},{"heatSetpoint":26.5,"transitionTime":480},{"heatSetpoint":27.5,"transitionTime":720},{"heatSetpoint":28.5,"transitionTime":960},{"heatSetpoint":29.5,"transitionTime":1200}]}}

(the weekly_schedule payload has a bit tricky as I could not find examples, but it is accepted. And 62 is just a bitmask apparently meaning all workdays in the week)

I had time synchronization issues (it took a while to understand) that forced me to unlink/reset and reconnect the TRVs several times because they were not synchronizing to a master clock.

Any idea how this can be solved permanently?
Is there a way to check the time acquired by the device?

Thanks for the feedback.

My source of information have been mostly:

https://www.zigbee2mqtt.io/devices/014G2461.html

2

Great, I’m actually about to start working on the same (opened a similar topic Danfoss Ally weekly schedule)

I’m using ZHA but you can check the internal time by querying cluster 0x000a and attribute 0x0000. This value can according to [1] both be read and written. The value stores:

This cluster provides a basic interface to a real-time clock.
The clock time MAY be read and also written, in order to
synchronize the clock (as close as practical) to a time
standard. This time standard is the number of seconds
since 0 hrs 0 mins 0 sec on 1st January 2000 UTC. [1]

I will probably set up an automation script to once daily update the timestamps of the TRVs.

[1] https://assets.danfoss.com/documents/193613/AM375549618098en-000102.pdf

3

Thanks for the input. I had started myself whit ZHA when I was running the SASWELL devices, then I switched to MQTT because of the vastly superior experience with that device.
I need to figure out how to query the device for time (and potentially set it) using ZIGBEE2MQTT. Any ideas?

4

Unfortunately not with ZIGBEE2MQTT. Never tried it.

Using ZHA I’ve just created a script like this which I call with ieee arguments for each TRV. Perhaps it can used as inspiration. Note that

trv_update_timestamp:
  alias: Update time for single TRV
  sequence:
  - service: zha.set_zigbee_cluster_attribute
    data:
      ieee: '{{ieee}}'
      endpoint_id: 1
      cluster_id: 10
      attribute: 0
      cluster_type: in
      value: '{{(as_timestamp(utcnow()) - as_timestamp("2000-01-01 00:00:00")) | int()}}'
  mode: single
5

I update the TRVs trigger_time publising:

zigbee2mqtt/FRIENDLY_NAME/set with payload {"trigger_time": Minutes_since_midnight}

Anyway using Z2M I often have a problem that randomly one or two TRVs stop communicating untill restart Z2M.

Never tryed to set the weekly schedule, does it work with Z2M?

Just tryed, I published

zigbee2mqtt/FRIENDLY_NAME/set with payload {"programming_operation_mode": "setpoint" }
and
zigbee2mqtt/FRIENDLY_NAME/set with payload {"clear_weekly_schedule": 0 }
and
{"weekly_schedule":{"dayofweek":62,"mode":1,"numoftrans":6,"transitions":[{"heatSetpoint":24.5,"transitionTime":0},{"heatSetpoint":25.5,"transitionTime":240},{"heatSetpoint":26.5,"transitionTime":480},{"heatSetpoint":27.5,"transitionTime":720},{"heatSetpoint":28.5,"transitionTime":960},{"heatSetpoint":29.5,"transitionTime":1200}]}}

after that I published

zigbee2mqtt/FRIENDLY_NAME/set with payload {"trigger_time": 240}
and after 1 minute
zigbee2mqtt/FRIENDLY_NAME/set with payload {"trigger_time": 241}

Update: works!

6

Happy that it is working.
Apparently, all my time synchronization issues are gone (I never encountered them again, even after multiple resets of the devices).

The trigger_time and day_of_week attributes appear to be linked to the “exercise time”:

image
image2065×123 59.7 KB

I presume this functionality is related to “exercising” (i.e. fully cycling) the valve every week or so to avoid clogging.

7

Cool the weekly schedule is working! I have the same problem that two TRVs stop communicating randomly until HA is restarted. Using ZHA I was actually considering trying Z2M.
Right now I’ve given up on HA and Ally TRVs due to communication dropping but might give it a shot later.

8

I’m willing to start using the schedule , but I need help in building the payload.
I want to make a specific program for each day of the week.

{
	"weekly_schedule": {
		"dayofweek":62,  #<- decode?
		"mode":1,        #<- what does it mean? OK, I got it
		"numoftrans":6, 
		"transitions": [
			{"heatSetpoint":24.5,"transitionTime":0},
			{"heatSetpoint":25.5,"transitionTime":240},
			{"heatSetpoint":26.5,"transitionTime":480},
			{"heatSetpoint":27.5,"transitionTime":720},
			{"heatSetpoint":28.5,"transitionTime":960},
			{"heatSetpoint":29.5,"transitionTime":1200}
		]
	}
}

I’ve looked at Zigbee specs but I could not get to a solution…
weekly_schedule should be a list of dicts (like transitions in your example) and each dict filled with the program for the day?

EDIT:
the TRVs do not update trigger_time, so I’m wondering if the schedule could work without updating from outside

EDIT2:
I got the meaning of “mode”:1.

9

after the zigbee specs (look at table 6-37 in the document you reference) dayofweek is a bitmap calculated as follows:
bit 0 weight 1 for Sunday
bit 1 weight 2 for Monday
bit 2 weight 4 for Tuesday
bit 3 weight 8 for Wednesday
bit 4 weight 16 for Thursday
bit 5 weight 32 for Friday
bit 6 weight 64 for Saturday
bit 7 weight 128 for “away” (not supported by Danfoss Ally)

So 62 means all days from Monday to Friday and 65 means Saturday+Sunday

Mode 1 is just “heating” which equals 1.

The transition block has to be stricly increasing with respect to transitionTime

Finally: trigger_time is a parameter, not the current time. I think it is a setup to tell the valve when it has to complete a full cycle (see above)

10

Thanks for the answer.
I found a way to get the internal clock time:
in the web frontend of zigbee2mqtt, from dev console you can set:
endpoint=1
cluster= genTime
Attribute= time
and push read button.

I have not been able so far to read weekly schedule, which should be an Attribute of cluster hvacThermostat:
https://github.com/Koenkk/zigbee-herdsman-converters/blob/18bf8c574c23eb3b7032ffe973cd30d5db5a59b5/converters/fromZigbee.js

11

So far I have tried reading back but I have not been successful…

image
image1301×348 12.5 KB

I push but nothing happens… any suggestion?

12

I’m using z2m ver: 1.22.2 commit: 414c51f

It works on all my 9 devices (7 with fimware 01.18.0008 01.18, and 2 still with original firmware 01.12.0008 01.12).
I got the following :

Read result of 'genTime': {"time":695487344}

in HA → Developer Tools → TEMPLATE

{% set data_z2m=695487344 | timestamp_custom('%d/%m %H:%M') %}
risultato : {{ data_z2m }}

I get the correct date (it was today at 3:55 pm)

Anyway, the test schedule doesn’t work anymore with any TRV.
By chance it worked whenI used trigger_time, but as you said trigger_time is a different issue.

Finally, I couldn’t get any result trying to read the weekly_schedule.

13

I am not able to get it to work. (My Z2M is the current stable that “comes” with HA -
1.22.2 but lists commit as “unknown”).

Never mind… as long as it is working I will leave it there.
Yesterday I went through I kind of nightmare as Z2M began restarting itself with little traces and all my devices disappeared: this morning I have restarted the network and detached momentarily one of the devices that acts as a coordinator and it came back. But yesterday I tried a number of things while offsite and nothing worked…

On your weekly schedule issue: are your clock really synchronized? When I was experimenting, I determined that the schedule was indeed working by using 127 as “dayofweek” and then dissecting the 24 hours with different transition buckets.
Clearly the fact that I cannot read back had an impact.

By the way: what kind of zigbee device are you using? I understood that my Sonoff with EZSP is unstable/limited. Could this be the cause behind my inability to read back from the devices?

14

I have Z2M in docker so I can update it easily.
My coordinator is this one:
Z-Bee Duo
I have the wi-fi version.

Is your sonoff the new stick ?

I’m able to read back just the time, completely unable to read the weekly schedule.
Despite the fact that now my TRVs and Z2M work properly, I’m willing to open an issue or ask Koenkk directly about reading back (time, weekly schedule …).

P.S. I’m Italian, are you Italian as well?

15

My Z2M is in a docker too but I don’t know how to upgrade. Can you share a tip?

I am using a sonoff zigbee bridge (SONOFF ZBBridge - Smart Home Zigbee Bridge - SONOFF Official) with a custom Tasmota firmware. I understood that its chipset and the fact that I am basically running a serial over wifi is not the best option. I will look into other options. So… it is not a stick.

Improving support for this TRV would be nice. It appears to be very feature rich (the new version should offer also some adaptive scheduling that would be nice to play with).

Sono italiano… calorifero mi ha rivelato :slight_smile: Ciao!

16

Upgrade Z2M with docker-compose, given that the name of container is zigbee2mqtt

docker-compose pull zigbee2mqtt
docker-compose up --build -d zigbee2mqtt
docker image prune -f

if you use docker (without compose):

  1. stop the container:
docker container stop zigbee2mqtt
  1. remove the container:
docker rm -f zigbee2mqtt
  1. remove the image:
docker rmi -f koenkk/zigbee2mqtt:latest
  1. restart the container (like the first time you did it) it should be something like this:
sudo docker run --init -d --name="zigbee2mqtt" -e TZ=Europe/Rome -v /home/pi/zigbee2mqtt:/app/data --device=/dev/ttyXXX --network host --restart always koenkk/zigbee2mqtt

I would use the following options:
volume: /home/pi/zigbee2mqtt:/app/data replace /home/pi/zigbee2mqtt with your current setup (this is the folder where you have your Z2M configuration.yaml)
device: --device=/dev/ttyXXX . Check your current set-up, I can’t tell how your systems handles the ZBBridge. In my set-up, I 've completely removed the device option.

Anyway, it looks like you have a recent version of Z2M.

There is a nice Italian chat on Telegram, look for inDomus.it - Domotica Chat
I’m still a beginner and very-very often I use the guides from the web site indomus.it

17

Hi, I’m trying to add a schedule to my Popp TRV which is a Danfoss Ally in fact. How to construct the payload for the MQTT message when I want different schedules for the weekend and for working days? Or should I publish these in different messages?

18

Hi
I am using a couple of automations: 1 for workdays and 1 for weekend. I hope it helps.

type or paste code hservice: mqtt.publish
data:
  topic: zigbee2mqtt/calorifero studio/set
  payload: >-
    {    "weekly_schedule":{       "dayofweek":62,       "mode":1,      
    "numoftrans":6,       "transitions":[          {            
    "heatSetpoint":10.0,             "transitionTime":0          },         
    {             "heatSetpoint":22.0,             "transitionTime":380         
    },          {             "heatSetpoint":19.0,            
    "transitionTime":495          },          {            
    "heatSetpoint":24.0,             "transitionTime":1005          },         
    {             "heatSetpoint":27.0,            
    "transitionTime":1230          },          {            
    "heatSetpoint":10.0,             "transitionTime":1325          }       ]   
    } }
alias: calorifero studio lun-ven

and then

service: mqtt.publish
data:
  topic: zigbee2mqtt/calorifero studio/set
  payload: >-
    {    "weekly_schedule":{       "dayofweek":65,       "mode":1,      
    "numoftrans":6,       "transitions":[          {            
    "heatSetpoint":10.0,             "transitionTime":0          },         
    {             "heatSetpoint":22.0,             "transitionTime":380         
    },          {             "heatSetpoint":23.0,            
    "transitionTime":540          },          {            
    "heatSetpoint":24.0,             "transitionTime":1005          },         
    {             "heatSetpoint":27.0,            
    "transitionTime":1230          },          {            
    "heatSetpoint":10.0,             "transitionTime":1325          }       ]   
    } }
alias: calorifero studio sab-dom
2 Likes
20

Hi,

is : “transitionTime” mean : How fast the TRV reacts ?
Or the Time between the Points?

Ennox