Help to get better integration for Viessmann Valve

[ChrisChoke]

Hey all,

I integrated the new Viessmann Thermostat Valve. I have some questions for the received data.

The piHeatingDemand data should be between 0-255. and z2m use some math to get percent value. Well the Thermostat seems to just send a payload between 0-5. have you any ideas how to debug that for more details?! i have a pcap with wireshark if its helpful. The Payload what z2m published to mqtt is always "received data" / 255 *100. if i received the data with 1. the mqtt payload is = 0.

Then i have attributes names 16384 with payload between 0 -3. it seems to be a manufactur specific attribute. the attributID is 0x4000. that i have sniffed with wireshark. But i need some help to come deeper in debuging and understanding the zigbee data what i can see in wireshark :-) Is there a possibilty to get to know what this attribute means?

how can i get the Firmware URL for OTA updates? can it be sniffed? or should i ask the manufacturer?

here the database.db entry:

{"id":4,"type":"EndDevice","ieeeAddr":"0x90fd9ffffe4a620e","nwkAddr":15806,"manufId":4641,"manufName":"Viessmann","powerSource":"Battery","modelId":"7637434","epList":[1],"endpoints":{"1":{"profId":260,"epId":1,"devId":769,"inClusterList":[0,1,3,10,32,513,516,2821],"outClusterList":[0,25],"clusters":{"genBasic":{"attributes":{"modelId":"7637434","manufacturerName":"Viessmann","powerSource":3,"zclVersion":3,"appVersion":0,"stackVersion":8,"hwVersion":69,"dateCode":"20190705","swBuildId":"01.12.0008 02.00"}},"hvacThermostat":{"attributes":{"16384":1,"16391":0,"16392":0,"localTemp":2216,"occupiedHeatingSetpoint":2100,"pIHeatingDemand":2,"systemMode":4,"ctrlSeqeOfOper":2}},"genPowerCfg":{"attributes":{"batteryPercentageRemaining":158}}},"binds":[{"cluster":0,"type":"endpoint","deviceIeeeAddress":"0x00124b0018e1ea90","endpointID":1},{"cluster":1,"type":"endpoint","deviceIeeeAddress":"0x00124b0018e1ea90","endpointID":1},{"cluster":3,"type":"endpoint","deviceIeeeAddress":"0x00124b0018e1ea90","endpointID":1},{"cluster":10,"type":"endpoint","deviceIeeeAddress":"0x00124b0018e1ea90","endpointID":1},{"cluster":32,"type":"endpoint","deviceIeeeAddress":"0x00124b0018e1ea90","endpointID":1},{"cluster":513,"type":"endpoint","deviceIeeeAddress":"0x00124b0018e1ea90","endpointID":1},{"cluster":516,"type":"endpoint","deviceIeeeAddress":"0x00124b0018e1ea90","endpointID":1}]}},"appVersion":0,"stackVersion":8,"hwVersion":69,"dateCode":"20190705","swBuildId":"01.12.0008 02.00","zclVersion":3,"interviewCompleted":true,"meta":{"configured":1},"lastSeen":1588708734905}

i would be happy if we could discuss this points and when i could learn more about zigbee and get deeper knowing :-)

i could provide a pcap from my sniffing. But i just sniffed the zigbee2mqtt network. not with the original bridge.

best regards Chris

[ChrisChoke]

okay we have to delete the reporting for OccupiedCollingSetpoint. now it throw an error while configuring:

error 2020-11-01 08:53:37: Failed to configure '0x90fd9ffffe4a620e', attempt 3 (Error: ConfigureReporting 0x90fd9ffffe4a620e/1 hvacThermostat([{"attribute":"occupiedCoolingSetpoint","minimumReportInterval":0,"maximumReportInterval":3600,"reportableChange":10}], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null}) failed (Status 'UNSUPPORTED_ATTRIBUTE')
    at Endpoint.checkStatus (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:173:23)
    at Endpoint.<anonymous> (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:386:26)
    at Generator.next (<anonymous>)
    at fulfilled (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:24:58))

attribute is not supported :-)

edit: pr #1721

[sjorge]

okay we have to delete the reporting for OccupiedCollingSetpoint. now it throw an error while configuring: attribute is not supported :-)

Yeah, that would make sense as... well it doesn't support a cooling mode :D

[ChrisChoke]

We can dump the image if it’s in the stream I believe,

Do you know how to do that @sjorge ? or can you explain how to do that? i would be interrested to learn more :-)

[sjorge]

I’ve never done it, but the data is send as-as so it should just be collecting all the bits. @koenkk may know?

~ sjorge

On 1 Nov 2020, at 19:55, ChrisChoke notifications@github.com wrote:

 We can dump the image if it’s in the stream I believe,

Do you know how to do that @sjorge ? or can you explain how to do that? i would be interrested to learn more :-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[mweinelt]

In general set the required keys per protocol to decode stuff. Then identify what packets we need and concat their payload.

I'm not too familiar with ZigBee so I'm fuzzy on the keys part.

[sjorge]

We got the key, I think it’s just extracting the payload from the request/response sequences and indeed merging the result.

By hand it seems like a non starter though as the packers are tiny.

~ sjorge

On 1 Nov 2020, at 20:02, Martin Weinelt notifications@github.com wrote:

 In general set the required keys per protocol to decode stuff. Then identify what packets we need and concat their payload.

I'm not too familiar with ZigBee so I'm fuzzy on the keys part.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[houssemsioud]

Hi I am trying to change and set the setpoint in Viessmann Valve using CLI commands and Zigbee2MQTT I was able to change the setpoint in the device (in both methods the setpoint changes in the display) but the motor does not turn (when I turn the valve manually to change the setpoint the motor turns) Using CLI commands: zcl global write 0x0201 0x0012 0x29 {B8 0B} send shortID 0 endPointID Using Zigbee2MQTT: Topic: zigbee2mqtt/[FRIENDLY_NAME]/set Data: {"occupied_heating_setpoint":30"} Was anyone successful in turning the valve motor after changing the setpoint using remote commands ?

[ChrisChoke]

well i know what you mean. you expect that the valve control his opening if you set the heating setpoint instantly. hmmm good objection. the valve control the radiator regardless. i hear how it conrol. and the radiator is heating or not heating. so anything the valve is doing :-) but i can pair it with manufactrurer bridge again and look what the manufacturer send to the valve.

too sad that @Koenkk dont answer if he can help with the ota extracting.

[houssemsioud]

but i can pair it with manufactrurer bridge again and look what the manufacturer send to the valve.

@ChrisChoke It would be helpful if you could share the packets sent by the manufacturer to the valve when setting a high setpoint (30°C) and hearing the valve opening (motor turning). I don't have the manufacturer Zigbee bridge to test this.

[ChrisChoke]

@houssemsioud i paired my TRV with the manufacturer bridge today on afternoon. I setted up the heating point on 30°C. so one time i noticed the motor drive. so i setted the heatpoint down and wait a while and setted back to 30°C. then i didnt notice motor drive. i repeat it several times but i didnt notice the motor drive again.

the vicare app works a bit weird. if i set up the heating point with the app, i have to confirm the manual change and only then the bridge send the write command for the heating point. this manual control hold for 2 hours, and then go back to 20°C default value. if i set up heating point by turn on the Valve, i dont have to confirm the manual control and it perfom like expected. i saw some manufacturer specific write commands to manufacturer specific attributes on thermostat cluster in the near of the write command while setting up the heatpoint. can be coincidence, dont know. but i dont know the meaning of this attributes. viessmann told me, they dont share their zigbee cluster/attributes implementation. but i dont let up. maybe they need some good arguments to give it to me. will continue to annoy :-)

[sjorge]

If it's in a wireshark dump, we can probably grab what it send and also send it... to see what the effect is.

[ChrisChoke]

zigbee_20201215.zip

here it is :-)

[sjorge]

On 2020-12-15 19:31, ChrisChoke wrote:

zigbee_20201215.zip [1]

here it is :-)

-- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [2], or unsubscribe [3].

Do you have the network key? As otherwise it shows a encrypted.

-- ~ sjorge

Links:

[1] https://github.com/Koenkk/zigbee-herdsman-converters/files/5697814/zigbee_20201215.zip [2] https://github.com/Koenkk/zigbee-herdsman-converters/issues/1242#issuecomment-745480622 [3] https://github.com/notifications/unsubscribe-auth/AAC4WEOWWICSG7FYCAZXNNDSU6TQ7ANCNFSM4NDQ26ZQ

[ChrisChoke]

linkkeys.zip

i shared above in an other comment. but here they are again

[sjorge]

edit: got the key working

Write Attribute: 0x4009
Data-Type: 16-bit UINT
Value: 202

Write Attribute: 0x4009
Data-Type: 16-bit UINT
Value: 212

Write Attribute: 0x4009
Data-Type: 16-bit UINT
Value: 202

Write Attribute: 0x4009
Data-Type: 16-bit UINT
Value: 192

Write Attribute: 0x4009
Data-Type: 16-bit UINT
Value: 172

Looks like the gateway (?) is writing to 0x4009... I think this is direct valve control. It looks like these are happening a bit after a read of 0x011c + 0x011d, not sure what those are yet. Assuming 0x4009 has the same range as piHeatingDemand 0=0% and 254=100% open.

Do these line up with you doing an action in the app?

Read Attribute: 0x011c
Data-Type: 8-bit UINT
Value: 152
Read Attribute: 0x011d
Data-Type: 8-bit UINT
Value: -62

Read Attribute: 0x011c
Data-Type: 8-bit UINT
Value: 144
Read Attribute: 0x011d
Data-Type: 8-bit UINT
Value: -64

Not a clue what these could be...

Report Attribute: 0x4001
Data-Type: 16-bit UINT
Value: 2676
Report Attribute: 0x4001
Data-Type: 16-bit UINT
Value: 2255

Been a while but I think thse reports are already hanled? They look like temperature values?

[sjorge]

So I think we need to modify https://github.com/Koenkk/zigbee-herdsman/blob/master/src/zcl/definition/cluster.ts#L1847 and add this to the attribute list.

            ViessmannValvePosition: {ID: 0x4009, type: DataType.int16, manufacturerCode: ManufacturerCode.VIESSMAN_ELEKTRO},

And then we can use a convertor like this

    viessmann_valve_position: {
        key: ['valve_position'],
        convertSet: async (entity, key, value, meta) => {
            if (value >= 0 && value <= 100) {
                await entity.write('hvacThermostat', {ViessmannValvePosition: ((value / 100) * 254}));
            }
        },
        convertGet: async (entity, key, meta) => {
            await entity.read('hvacThermostat', ['ViessmannValvePosition']);
        },
    },

I don't have the valve mounted at the moment to test though, the get bit might need to go, not sure as I did not see reads for that attribute, but we can try reading I guess if it errors, we just drop the convertGet

I guess you could give it a go @ChrisChoke if you got time.

[sjorge]

Some further observations, it seems to try and sync the time... not sure this automatically works? @Koenkk ?

Also found some writes hvacTherm 0x404b / INT8 / 0 hvacTherm 0x4020 / UINT8 / 1 hvacTherm UI 0x4000 / Enum8 / 0x00

Also to the wellknown systemMode attrib: 4 and 9

[helgek]

Hi, thanks a lot for your efforts on this device! I'm also considering to try out these valves for my apartment (4 radiators) and I wanted to ask if you'd mind to share your long-use experience and if you'd still recommend them? I just had another terrible experience with Danfoss Ally and Viessmann ViCare is my new hope since they have a strong reputation and they're producing these valves in Europe. Thank you! Helge

[sjorge]

I'd wager on the Danfoss Ally, although the Viessmann is VERY similar, I stopped using mine because it couldn't get all the info I could get from a Danfoss Ally.

I'm not 100% satisfied with any TRV I tried at the moment, which is a shame, I find the Danfoss to be too expensive but it's the best one so far. I have all kinds of trouble with the Eurotronic one, and most TuYa based one don't really follow the zigbee spec which I find important.

[helgek]

Thank you for the follow-up @sjorge ! I opened a discussion in the Viessmann forum https://www-viessmann--community-com.translate.goog/t5/Konnektivitaet/Vorabfragen-zu-Viessmann-Heizkoerperthermostat-ViCare/m-p/192125?_x_tr_sl=de&_x_tr_tl=en&_x_tr_hl=de&_x_tr_pto=nui and also quoted your experience. My initial experience a couple of days ago with Danfoss thermostats (POPP thermostats respectively, a Z-Wave brand using Danfoss as OEM with slightly modified firmware) wasn't great either but I may have blamed the Danfoss thermostats too early for Zigbee connectivity issues since I found out that the latest ZHA version in connection with Conbee II could have also been the root cause for the connection issues. So I will give Danfoss one more chance. But one thing I'm pretty sure about though is that current Danfoss firmware has no pro-active mechanism to attempt reconnect to the Zigbee coordinator once connection got lost but I could also be wrong here since my coordinator didn't seem to work correctly because of ZHA issues.

[sjorge]

Seems to line up with my experience, the Danfoss (and the Viessmann for that matter) would occasionally need an on device input to trigger it to reconnect after I rebooted my coordinator. Although they do seem to eventually reconnect so I'm guessing it might be a battery saving feature.

[helgek]

This is interesting. Did you experience automatic reconnect after longer period of time or did it only happen based on on device input (I had to remove and reinsert battery)?

[sjorge]

This is interesting. Did you experience automatic reconnect after longer period of time or did it only happen based on on device input (I had to remove and reinsert battery)?

Input seemed to work most of the time, the other one I just left as it was summer and I only have one of each I was using for tested and I noticed it was back a day or two later.

[helgek]

Good to know, thanks. I will then start my own observations over a period of time and also try to get some info from Danfoss on this aspect and of course I will share any findings

[h0nIg]

the bridge requested an update. but it was already installed. the full request was: http://zeroseriesupdate.viessmann-platform.io/firmware/hb2/7637415_Vitoconnect-100_OTOL2.version

can you please share further informations about this file? I was looking for a way to download these firmware files, however i get a 404 for the link