-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Eve Signatures / Log Entries #75
Comments
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 |
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 :) |
I tried including The Thermostat history still shows, when using fingerprint For my combined Current Temperature / On history, I now send entries Next steps:
|
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:
So the recipe for a temperature sensor is:
And for a temperature/humidity sensor:
Note that this doesn't require any change in fakegato-history; these changes need to made in the plugins. |
- Add old Eve _Weather_ service to expose history for only temperature or temperature/humidity, see simont77/fakegato-history#75 (comment); - Move _Last Updated_ and _Heartrate_ charactertistics to _Temperature Sensor_ service.
Proof of concept for Eve history, see simont77/fakegato-history#75 (comment): - Don't expose _AIr Pressure Sensor_ service when `noPressure` or `noHumidity` is set; - Don't expose _Humidity Sensor_ service when `noHumidity` is set; - Expose _Weather_ service when `noPressure` or `noHumidity` is set.
- Add `History.Rpi` service delgate with history for _Current Temperature_ and _On_; - Add optional temperatureDelegate to `History.Motion`. - Rationalise history fingerprints and return values, see simont77/fakegato-history#75.
Here is my 2 cents:
|
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:
|
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 |
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
The text was updated successfully, but these errors were encountered: