add energy_meter component: energy usage per job

[PSandro]

fixes #445

This adds a new component energy_meter which is used for starting and stopping a energy measurement. For the actual data, a sensor is to be specified in the config section. The history component collects print stats already for jobs, I added the energy measuring there: On print start, the current value from the sensor's energy counter is saved. When the print stops, this saved value then gets subtracted from the most recent sensor value and voila, we get the energy used for the print.

Here's a sample configuration used for a ShellyPlus1PM:

[mqtt]
address: 192.168.230.1
username: {secrets.mqtt.username}
password: {secrets.mqtt.password}
enable_moonraker_api: True

[sensor powermeter]
type: mqtt
name: powermeter
state_topic: shellies/shellyplus1pm-4855199da2e4/status/switch:0
state_response_template:
  {% set notification = payload|fromjson %}
  {set_result("power", notification["apower"]|float)}
  {set_result("voltage", notification["voltage"]|float)}
  {set_result("current", notification["current"]|float)}
  {set_result("energy", notification["aenergy"]["by_minute"][0]|float * 0.000001)}

[energy_meter]
sensor: powermeter
field: energy

[kondas]

Awesome! Works flawless using generic power meter, example config:

[sensor powermeter]
type: mqtt
name: Power
state_topic: zigbee2mqtt/pow-printi
state_response_template:
  {% set notification = payload|fromjson %}
  {set_result("energy", notification["energy"]|float)}

[energy_meter]
sensor: powermeter
field: energy

[PSandro]

Thanks for testing @kondas !

This is how the energy consumption information is then included in the history api endpoint.

I think for now this is ready for review. I was thinking about an edgecase where moonraker restarts and the state of energy_meter is lost - but in this case we might have a gap in measurement anyways and it kinda makes sense for the measurement reporting to 'fail'.

[kondas]

Bumping this, because i'd really like to see this feature merged

[tomoinn]

This looks fantastic, exactly what I was looking for. Thank you for doing the coding so I don't have to :)

[PSandro]

@Arksine can I improve anything in this PR in order to get this merged? Thank you

[Arksine]

Sorry for the delay, when I sit down to write feedback for this PR something always seems to pull me away. The short of it is there are some blockers that prevent this from being merged for the time being. I think this feature is useful so I'll work to help get it added.

• With rare exceptions its preferable to avoid dependencies between optional components. That is, the history component should not attempt to look up optional components, nor should the energy_meter. Generally when we want to depend on an optional components we use events, however that will not be adequate in this case so some changes need to be made to history.

• Currently all of the fields reported by history are guaranteed. We don't want to make the API unstable by adding fields that may or may not be available. In addition I'm currently in the process of migrating Moonraker's database to Sqllite3. This will introduce a schema for the stored data, so we want to avoid adding or removing fields. We can accommodate these limitations by creating an additional auxiliary_data field reported by the history component and place optional fields there. The same can be done with totals.

I need to resolve the history changes. It meets the requirements to be a core component, and I suspect the overwhelming number of users have history configured, so I will make that change. In addition I will add functionality that allows components to register auxiliary fields. I have already started work on these changes, however this addition is behind a few items in my current queue of things to be merged (one being the afore mentioned SQL changes). With current time limitations I can't give a firm date, hopefully not too long. I will update this PR when the history module is ready.

As for the energy_meter, I think it would be better to add "delta" tracking directly to the sensors module. It could be a configured option that we can expand on in the future with different kinds of trackers. Once the history requirements are merged the sensor can be configured to register auxiliary fields that are tracked in job history.

[Anywherexu]

moonraker.log

[mqtt]
address: 192.168.5.****
port: 1883
username: admin
password: ***********
enable_moonraker_api: True

[sensor powermeter]
type: mqtt
name: powermeter
state_topic: Voron/powermeter
state_response_template:
  {% set notification = payload|fromjson %}
  {set_result("Power", notification["Power"]["by_minute"][0]|float * 0.000001)}
  {set_result("Voltage", notification["Voltage"]|float)}
  {set_result("Today", notification["Today"]|float)}
  {set_result("Total", notification["Total"]|float)}
  
[energy_meter]
sensor: powermeter
field: energy

This is the MQTT message received from nodered. Is this the format, I don't know if it's the right thing to send?

Hello, this is a machine translation I don't know if I can express it. Thank you for your understanding.
I added the sensor from mqtt. Homeassistant is receivable, but fluidd cannot be displayed. There is an error in the moonraker .log file. Don't know how to fix it. Ask for guidance.

[Arksine]

I know it was a long time coming, but I finally found some time to complete support for adding auxiliary fields to the job history. Front ends will need to implement it, however you can manually call the API and view the data. Each field is presented with a consistent schema, which should make it easier for frontends to determine how to display the data.

The documentation explains how to configure one or more "history fields" for a sensor. In addition, a sample that should work with tasmota devices is provided.

[Arksine]

Since support for this is now available I will close this PR. Thanks.