Power consumption monitoring

[patrickstigler]

Is your feature request related to a problem? Please describe

No - just a request.

Describe the solution you'd like

I'd like to also see and log the power consumption per print in the history of i.e. Mainsail. That will require a additional attribute in moonraker.

Describe alternatives you've considered

Plugins for the frontend would be possible, or just read it from the smart power plug. But then there is no automatic logging and automatic price calculation is not possible.

Additional information

No response

[kondas]

+1, i'd love to see this implemented. I'm using Sonoff Pow R2, with Prometheus metrics exporter so at any given time the accumulated power consumption can be read from a http endpoint. A very quick and dirty solution would be simply calculating the delta between that at the start and the end of a job.

[PSandro]

Hi, I'd like to work on this if possible. Frontends like Mainsail or Fluidd show a Temperature graph with history for the current session. Eventually it would be nice to have a similar graph for power monitoring.

Since the type of power device is already set in the power section of the config, power monitoring could be automatically integrated for capable devices. This would also require less configuration for the user. Currently it is already possible to configure a power sensor for mqtt enabled devices. Using the power section with device type information, one could also communicate directly with the device e.g. via http(s) which eliminates the need for a mqtt broker.

I will start working on an implementation for shelly and tasmota devices. Do you have any more requirements or suggestions?

[kondas]

@PSandro Thanks for stepping in, i'd be eager to help with testing if needed. IMHO adding extra "capabilities" to the power device is a good approach.

Defineable MQTT topics for generic power monitor attributes like power,voltage,current,energy, in the same manner as existing attributes could be a good way to set this up.

[power printer] type: mqtt ... power_topic: zigbee2mqtt/pow-printer power_response_template: {payload.power}

EDIT: The main benefit for me would be to have the consumed power indicated for each job in the print history. Having it on the graph would be also very nice.

[Arksine]

I do not think that power.py should be extended to report sensors on a switch, that is what sensor.py is for. The power module is exclusively for switch implementations and functionality that is related. If I had to do it over again it would be called switch.py, however I do not wish to break existing configurations or the API.

As previously mentioned, it currently possible to configure MQTT based sensors in sensor.py. It probably wouldn't be that difficult to add an http type to sensor.py that supports http polling.

[PSandro]

I see your point, it makes sense to differentiate between a 'sensor' and 'switch' internally. Usually when it comes to devices like shelly or tasmota relays, they combine those features. So setting up this device once in the config would be cool.

The alternative would be to have separate configuration entries for the same physical device, being sensor my_shelly and power my_shelly. To keep it consistent with the power configuration, would it be appropriate to also have specific options for the type: field, like tplink_smartplug, tasmota, shelly, homeseer, ... or should we stick to the generic http polling with a configuration option for url, headers etc? A specific device type is convenient but would produce redundant code: Device specific logic already exists in power.py. The power metering information is sometimes event part of the json response but not used. See here: https://github.com/Arksine/moonraker/blob/a71c5c159d04bae72c2aab9d92b5433aeb0c4d38/moonraker/components/power.py#L1012

I'm motivated to implement either approach (or another one?), just let me know what you think.

EDIT: Sorry if I got a bit off-topic here. My concern is that measuring the energy delta for a job duration requires some stateful logic with a counter for the consumed watt-hours. I'm not sure if a generic implementation like the current mqtt type in sensor can be enough for that. It could be done with an additional component energy_meter in which the sensor is linked and declared as an energy sensor. From there the information would be fed into the job state.