You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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 callingSetConfiguration
on an Eve Smoke with40020201
turns the test mode on and40020201
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:
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:
SetConfiguration
is an object that implementsencode()
that returns bytes - i.e. it expects aTLVStruct
. ButTLVStruct
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 aTLVStruct
variant that didn't blow up on unknown fields. Or maybe it should just log unknown fields and drop them anyway?The text was updated successfully, but these errors were encountered: