#Hum I guess the problem is that I don t

1 messages · Page 1 of 1 (latest)

winter tangle
#

I opened a Thread to keep it more tidy.

I would suggest looking at what other people have done maybe there is something to copy (https://github.com/zigpy/zha-device-handlers/tree/dev/zhaquirks/bosch)

But also look at issues your debug and pairing log as well as other projects there might be some usefull information.

In general you have to look at the current signature of the device to see what capabilities it advertises and then check/debug what it does different. Tedious but doable. Best is when you have a Zigbee Gateway that works with the device and you can just listen in on the Zigbee Messages transmitted when interacting with the device.

narrow junco
#

Alright, thanks for the heads up.

Right now I have it paired to my home assistant instance via an USB zigbee coordinator.

I have its signature and already built the skeleton for the quirks, right now I'm just stumped on how to do the bit you described as tedious.

I suppose your recommendation would be to turn on zigbee debug logs to the max on the home assistant and check what I can see?

winter tangle
#

Yeah thats were the reverse engineering fun starts.

narrow junco
#

I just saw that Zigbee2MQTT basically covers all available features. Do you think it would be wise to see how they did it?

winter tangle
#

Yes I by myself are a bit unsure in how to convert their implementation/information to ZHA but it sure helps.

narrow junco
#

Well, right now I'm trying to find where they actually store the code for their devices. 🤔

#

Just looking for Bosch came up empty

#

In their repo

#

Something I found in the logs which looks a bit weird:
system_mode=[<SystemMode.Heat: 4>]/heat
The /heat at the end looks like it's not meant to be there? Which would explain why sending the command to change the mode fails, because it's malformed.