Expose the power consumption to Homekit

[cschildhorn]

In the release notes I found:

• Shelly 1PM, Plug and PlugS power measurement support (Shelly 1PM power consumption #27)

I was expecting that the plugs now show power like e.g. the Eve Plugs in the Eve app etc.

How is this supposed to be in 2.7.0 currently? And is it planed to expose it according to Eve Plugs?

This is how a Eve Plug shows power:

This is an updated Shelly Plug S with 2.7.0:

[pivale]

Hey,

For now you only have status, current consumption, total consumption.
The storage on the devices is very limited, so there might be some trouble in storing it...

But an alternative (like storing in a remote location/device) would be great, but we have nothing like that at the moment.

[cschildhorn]

Hmm the Eve plugs do only cache the data for a certain time as well. The data into homekit via a history service as far as I know.

Homebridge community uses this heavily https://github.com/simont77/fakegato-history but perhaps there is a better way.

[BlancoDeMallloca]

This would be a great feature. May the export to HomeKit/Eve could be implemented in the future. Also Shelly 2.5 has a power measurement function

[rojer]

i wonder what service/characteristic they use to expose power measurements. is there a spec or some documentation? HAP standard has nothing for this.

we already support reading power consumption on shelly 2.5, it's only matter of finding a way to expose this to homekit.

[cschildhorn]

I think there is nothing official by Eve but some people are doing a lot of work rev it.

https://gist.github.com/gomfunkel/b1a046d729757120907c

I think this guy used the work above to create a Homebridge part that is used by many other plugins to write data to the eve characteristics

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

here some example that use this to expose power consumption as far as I know:

https://github.com/SeydX/homebridge-fritz-platform

https://github.com/ebaauw/homebridge-hue

The editor of homebridge-Shelly plugin does not support it but seams to look into it at some point as well.

alexryd/homebridge-shelly#48

[cschildhorn]

This is perhaps the most complete overview link I found currently

https://github.com/simont77/fakegato-history/wiki/Elgato-Eve-History-Protocol

[pivale]

It seems this is not supported by HomeKit but rather by the Eve app.
If I had a choice, I would rather have the devices write to some shared drive on my network a CSV file than using a proprietary app/protocol/framework from a 3rd party.

But I also think this is a cool feature to have in the future :)

[cschildhorn]

Csv export might be nice as well.

With the usage of the fakegato stuff you could create automation with the messured values in homekit itself. Which is great if you want to monitor for example if a washing machine is finished with the job etc.

[thaetig]

What about „keeping it simple (KIS)“ for the beginning?
Do NOT store the values in a timeline (like eve devices), save this (advanced issue) for later, but...
... expose only the already/current measured values in the WebGUI (Actual Watts, Total Watts) to HomeKit ... just like Fibaro does in its device? This should be a quick (but very helpful) add-on as Apple HAP supports it.

After/if you figured out how to store the data (I think the fakegato project should be a good start), you could still add this feature later on?

Here the Fibaro device screen from the eve app... You can also see another issue I would like as an enhancement (not sure, if this is possible): after resetting the device (or firmware update), your Firmware automatically resets the „Total Watts“ value - it would be great if this value would persist after reset/update and could be resetted with a separate switch(?). I know the Shelly is loosing current for a while upon reboot/reset, so this might be impossible...

Thanks in advance (and for your great work done so far, too!!!)

[pivale]

Hey,

For now you only have status, current consumption, total consumption.
The storage on the devices is very limited, so there might be some trouble in storing it...

But an alternative (like storing in a remote location/device) would be great, but we have nothing like that at the moment.

It already does current and total consumption @thaetig ;)

[thaetig]

@pivale: Sorry, but... it´s not (please read my comment again... but slowly). the values are already measured and written to the webGUI (:= the picture you have posted), BUT: it does NOT write these into the Apple HomeKit / eve app (so you have to switch between HomeKit and WebGUI to see the values). its possible to include these values (as attributes of a device) directly i to Apple HAP (like Finaro does - see the difference?).

[timoschilling]

Both characteristics aren't supported by HAP, they are custom char's defined by Eve. @rojer would you accept PR for it?

[rojer]

i don't mind as long as the accessory continues to work in the Home app.

[thaetig]

Both characteristics aren't supported by HAP, they are custom char's defined by Eve. @rojer would you accept PR for it?

As I hat time to look into the HAP protocol now I understand the issue. By default Apple only supports fixed/enumerated data types for objects (described here: https://developer.apple.com/documentation/homekit/hmcharacteristic/characteristic_types). EVE has set a „de facto standard“ to enhance these... not as simple as I thought then, either :( But this must be quite common/widely spread, too- as many tools are interchsngeable to show these values... (e.g. the HOOBS ShellyPlugIn can do it in a perfect way... so maybe I can gather some code sniplet there?!)

Update: the buzzword I was searching for is „Custom Characteristics“ - and it can (intentionally) be done... as e.g. defined here: https://github.com/RavenSystem/esp-homekit-devices/blob/master/devices/common/custom_characteristics.h

[fototeddy]

when using my Shellys via home bridge-mqttthing it is possible to read out all the date and store it in Eve. Store something in eve does not change any behavior in Home App but adds nice features when using EVE. So maybe looking into the homebridge-mqttthing code could help do add these Fakegate features for Shelly H&T and also for the Power measure Shellys

[cschildhorn]

Any update on the request? Still would be awesome to add this. Would open ways for nice automation stuff.

[rojer]

wasn't this done in #690 ? what are we still missing?

[timoschilling]

#690 only added the current consumption, Eve also supports a historic consumption.
The problem is that Eve needs it as time history and not only as a sum value, so we can't build it on top of our current total consumption.

[rojer]

it expects time series data in a HAP characteristic? can we always export series of length 1 with the last reading?

[timoschilling]

it expects time series data in a HAP characteristic?

yes, take a look somewhere above there is a link to the reversed engineered HAP Char.

can we always export series of length 1 with the last reading?

No because then Eve will collected the old values from yesterday and sum them up with the new values from today. That would only work if we reset our sum each day.

[rojer]

ok, i won't go into details but if someone is willing - we could probably spare a couple KB on the filesystem to store some value history though i worried about grinding the flash with constant writes. perhaps, if it's not enabled by default, then fine. we do not have any RAM available on gen1 devices for this, memory is very tight. on gen2 we can spare, perhaps, 10K.

[timoschilling]

Would it be ok to write just once a hour or once a day to the flash an keep the current sum in the ram, then we only need one int in ram?

[rojer]

hourly writes seem reasonable. also should save on reboot.

[hardcore]

@cschildhorn do you have a working solution for power consumption history? Greetings to Gommersche ;-)

[ragges]

Was the hourly write implemented?
Hourly writes would mean 8766 writes per year which would likely wear out the flash in a year or so, but if there is incremental writes, wear leveling, and/or other methods to save the flash, that would of course not be a problem.
Sorry for being a newbie to this code.
@rojer @timoschilling