Eve Signatures / Log Entries

stefdude commented 4 years ago

Hi,

Not sure if this the best way to add some of my insights, but this seemed the only way.

I've been following this work for a few days, and I can only tell: great job!

However, I'm not sure that the "signatures" as exposed in characteristic 116 are so magical. I think they are "which data is available for logging".

For Eve Thermo, the "Signature" I have is: 06 0102 1102 1001 1201 1d01 2302 I'm "decoding" this as: 6 different types of data 0102: 01 = Type (Temperature), 02 bytes 1102: 11 = Type (Setpoint Temperature), 02 bytes 1001: 10 = Type (Valve %), 01 byte 1201: 12 = Type (Heating Mode???), 01 byte 1d01: 1d = Type (???), 01 byte 2302: 23 = Type (Battery Voltage???), 02 bytes

Then, on the logging in characteristic 117, the "entry type" is a bit mask: e.g.: 01 would mean "I'm only reporting the 1st data type now => Temperature (2 bytes) The Eve Thermo that I was spying on reported a few logs with "entry type" 1f: (0001111) => Temperature (2bytes), Setpoint Temp (2bytes), Valve% (1byte), Heating Mode (1byte), ????(1byte) ==>> total size 7 Newer log entries have "entry type" 3f: (0011111) => same + "battery voltage???"(2 bytes) ==>> total size 9

So, I think that 116 and 117 really work together; and I believe that not each log entry needs to report ALL data (i.e. the logging is dynamic); even though that most data will allways be reported all the time.

I also have spied on an Eve Energy (Firmware 1.2.9): "Signature" 05 0b02 0c02 0d02 0702 0e01 5 different data types 0b02: ????, 2 bytes 0c02: Volt x 10, 2 bytes 0d02: ????, 2 bytes 0702: Watt x 10 (???), 2 bytes 0e01: On/Off, 1 byte

Extract from the log (117) for this Eve Energy 0b 21590000 b140cc00 10 01 Entry type 10 (binary: 00010000) => I'm only reporting my 5th data point 01 => Switch On (1 byte) 12 22590000 a642cc00 0f 0000 0b09 0000 0000 Entry type 0f (binary: 00001111) => I'm only reporting my first 4 data points Data Type 0B (???), 2 bytes => 0 Data Type 0C (Volt x 10), 2 bytes => 2315 => 230,5 Volt Data Type 0D (???), 2 bytes => 0 Data Type 07 (Watt x 10), 2 bytes => 0 => 0 Watt

(with this interpretation, it would seem that fakegato is currently sending "Temperature" (set to 0), "Humidity" (set to 0), "Watt" (filled with correct data) and "Air Quality" (set to 0) for TYPE_ENERGY ... which indicates that they are quite liberal in what they can handle in app)

Hope my contribution helps... regards, Stef

ebaauw commented 4 years ago

You're definitely on to something!

As a quick and dirty test, I constructed a combined history for temperature and on/off using 116 fingerprint 02 0102 0e01 and 117 entry: 0d %s %s 03 %s %s with arguments currentEntry, time, temp, and on. The 0d is the length of the entry (incl. the length byte itself). It seems to work!

volschin commented 4 years ago

Propably 0D in the fingerprint is Ampere. To check, you should switch it on.

stefdude commented 4 years ago

Propably 0D in the fingerprint is Ampere. To check, you should switch it on.

I have remote access to the Eve devices (as a guest in a shared home). The Eve Energy is currently powering a LED strip with almost no consumption, so the logs for 0B, 0D and 07 is 0.

I’ll ask to do some tests when I’m physically in his house :)

ebaauw commented 4 years ago

I tried including 0C02 in the history, but Eve shows no history graph for Voltage. I think 1201 and 1D01 are indeed current and target heating mode, but when exposing them, Eve doesn't show any new graphs. Moreover, as of v3.8.1, Eve no longer shows the graph for valve position under Mode. EDIT It's under Valve, which now shows as a separate characteristic, but hidden by default.

The Thermostat history still shows, when using fingerprint 03 0102 1102 1001. Note that your Thermostat service needs to include characteristics ProgramCommand (12C) and ProgramData (12F). I just return ff04f6 for ProgramData (schedule disabled, see #40) and ignore any changes to ProgramCommand. The app seems happy with that, and doesn't keep busy while trying to read the schedule. I think this changed with v3.8.1 as well.

For my combined Current Temperature / On history, I now send entries 0b %s %s 02 %s (no Temperature) when On changes and periodic entries 0d %s %s 03 %s %s (incl. Temperature). As I hoped, the Temperature history shows an entry per 10 minutes, and the On history shows the event times.

Next steps:

Try fingerprint 01 0102 for a temperature sensor, and 02 0102 0202 for a temperature/humidity sensor;
Try fingerprint 02 1c01 0102 for a PIR motion sensor that also reports temperature.

ebaauw commented 4 years ago

Try fingerprint 01 0102 for a temperature sensor, and 02 0102 0202 for a temperature/humidity sensor;

No joy. Eve insists on having a (standard) Temperature Sensor, a (standard) Humidity Sensor, and a Pressure Sensor (00A) service to show the weather history.

In the early days, the Eve Weather would use a custom Weather service, 001, which combined Current Temperature (standard) Current Relative Humidity (standard), and AirPressure (10F) characteristics in a single service. It looks like the Eve app still accepts this service for showing history:

When exposing an accessory with a Weather service with only Current Temperature, Eve shows the history, even with the "full" 03 0102 0202 0302 signature. However, Apple's Home app will show a Not Supported tile for this service.
Exposing an accessory with an empty (no charactertistics) Weather service and a Temperature Sensor service and a 03 0102 0202 0302 History service works for Home. However, in the At a Glace and Rooms views, Eve shows the symbol for a custom service and no value.
Exposing an accessory with a Weather service with a hidden Current Temperature characteristic and a Temperature Sensor service causes HomeKit to block homebridge (for non-compliance?).
Exposing an accessory with a Weather service with only Current Temperature, and a Temperature Sensor with a regular Current Temperature characteristics looks good in Home, and in the At a Glance and Rooms views in Eve. It does show the temperature characteristic twice in the accessory details view. This is the best compromise, imho.

So the recipe for a temperature sensor is:

Expose a Weather service with only a Current Temperature characteristic;
Expose a regular Temperature Sensor service;
Expose a regular weather History service (with fingerprint 03 0102 0202 0302).

And for a temperature/humidity sensor:

Expose a Weather service with only a Current Temperature characteristic;
Expose a regular Temperature Sensor service;
Expose a regular Humidity Sensor service;
Expose a regular weather History service (with fingerprint 03 0102 0202 0302).

Note that this doesn't require any change in fakegato-history; these changes need to made in the plugins.

izmmisha commented 3 years ago

Here is my 2 cents: type ids (currently without data length/format)

01      Temperature
02      Humidity
03      AirPressure
04      AirQuality
05      PowerApparent
06      Door
07      Power10thWh
08      WaterFlow
09      WaterTemperature
0a      WaterEnergy
0b      PowerWatt
0c      PowerVoltage
0d      PowerCurrent
0e      PowerOnOff
0f      VOCHeatSense
10      ValvePercent
11      TargetTemperature
12      ThermoTarget
13      Motion
14      Switch
15      PowerOnOff2
16      SmokeDetected
17      CurrentPosition
18      TargetPosition
19      PositionState
1a      ObstructionDetected
1b      SmokeDetectorStatus
1c      MotionActive
1d      OpenWindow
1e      unknown
1f      InUse
20      WindowState
21      PotState
22      VOCDensity
23      BatteryLevelMillivolts
24      StatelessSwitchEvent
25      BatteryLevelPercent
26      Lock
27      AirPressureChange

ebaauw commented 3 years ago

Thanks, @izmmisha, this is a lot more than I've seen so far!

I would really appreciate if you could add, where known, for each type:

The data types and length, as you indicated;
The HomeKit service and characteristic(s) required for the Eve app to actually display the history;
The Eve device(s) that uses the type.

n0rt0nthec4t commented 3 years ago

Wondering if anyone has access to an Eve Smoke to do some dumps from to work our the signatures/log entries that need to be sent back? I've worked out how to make a smoke sensor appear/act as an Eve Smoke (I'm my case, Nest protects), but have been unable to determine the correct signatures/fields to send back

simont77 / fakegato-history

Eve Signatures / Log Entries #75