Support Eve Vendor Configuration Characteristics

[Jc2k]

Eve devices have a bunch of settings behind a pair of characteristics:

• E863F131-079E-48FF-8F27-9C2605A29F52 - GetConfiguration (read only, no events)
• E863F11D-079E-48FF-8F27-9C2605A29F52 - SetConfiguration (write only)

SetConfiguration takes a TLV of a setting to change. For example, apparently calling SetConfiguration on an Eve Smoke with 40020201 turns the test mode on and 40020201 turns it off.

You can read back settings with GetConfiguration which returns all readable configuration as a big TLV structure.

Some of these settings would be useful to expose in HA. I am interested in adding switches for:

• Display orientation (It's a binary choice of normal or inverted)
• Child lock

From looking at decoded TLV data for my Eve Thermo, i think those 2 are key's 55 and 63, but i won't know which is which (or if im right) until i test writing to them.

I'm also interested in being able to control the "Valve Protection" setting and running the "Calibrate" setting - will have to run a HAP proxy to find those i think.

There are some challenges exposing these within our current HA integration:

• There will be multiple entities for the same aid/siid/ciid, so need to think about unique_id for this carefully.
• We probably don't want to poll these - it's unlikely they are going to change unless we change them through HA, and for Bluetooth it's probably going to be quite costly in terms of battery (most things we are able to monitor through encrypted advertisements and disconnected events).
• While trying to test this, I realised that we encode them differently in homekit_controller-entity-map for different transports. In CoAP and BLE, they come through as byte sequences (decoded with bytes.fromhex) rather than base64 like IP.
• Based on above, not sure how this is going to work when writing to them
• The current serialiser seems to assume that whatever you pass to SetConfiguration is an object that implements encode() that returns bytes - i.e. it expects a TLVStruct. But TLVStruct sucks here because the structure isn't well known. Could teach it to accept a dict, but then we wouldn't be able to do any typing. Could do with a TLVStruct variant that didn't blow up on unknown fields. Or maybe it should just log unknown fields and drop them anyway?

[virtualm2000]

Is this project any help? I have used the module with homebridge sometime ago.

https://github.com/simont77/fakegato-history