request for price/cost device (similar to kWh but with configurable currency code)

[WillemD61]

This is an enhancement request for a dummy device that can be used to track prices and/or costs, positive and negative whereby the user can indicate the currency used.

With the increased/increasing focus on energy cost such a device is really missed in Domoticz. Currently workarounds have to be used such as storing such prices/costs on kWh devices.

It can be a simple device, i.e. no calculation based on tariffs as suggested in #2132.
Any calculation should be left to the user using dzVents scripts.

The device only needs to receive and display increasing, decreasing, positive and negative values, be able to display those in a graph and calculate daily totals for display in weekly, monthly and comparison graphs.

Currently one cannot store negative values on counter devices and the counter graphs cannot handle negative or even decreasing values. The only device that can handle it is a kWh device (General, kWh). The functionality of a kWH comes very close to the desired functionality of a cost device, but the new device should allow setting of the currency unit.
Required for a currency device ( and partly already possible on a kWh device):

1. Possible to increase and decrease in value.
2. Possible to handle negative values.
3. Intraday graph of type bar or line.
4. Graphs with daily values display bars of total (so no min,max or avg). The device values/counter should therefore be stored in the meter and meter_calendar table.
5. Daily switchover and insert into meter_calendar based on difference between first and last value of the day (like kWh), not on min/max, like counters.
6. Update of the device similar to updateElectricity(0,value) of a kWh device, i.e. no calculation based on time-based-rate.
7. It would be nice to have the option for DisableLogAutoUpdate and AddDBLogEntry so one can also enter future values via JSON calls in meter tables without affecting meter_calendar entries.

This request is based on the analysis shown here https://www.domoticz.com/forum/viewtopic.php?p=296335#p296335 and the fact that I am tired of using kWh devices as workaround. It is confusing/annoying and pollutes my Domoticz setup. As said, with increasing focus on costs and increasing use of hourly electricity prices, solar power, battery storage (resulting in negative/decreasing values), I am sure many more people struggle with this.

[gizmocuz]

How about using a custom sensor?

[gizmocuz]

What you might want to do is use the InfluxDB pusher and push the kWh (counter) and Price. Then you can create a chart with cost per hour/day

[WillemD61]

How about using a custom sensor?

No, a custom sensor is totally useless for this since after the end of the day it only shows min/max/avg and therefore can't be used for tracking costs over time. (it does not meet requirement 4 above)

[WillemD61]

What you might want to do is use the InfluxDB pusher and push the kWh (counter) and Price. Then you can create a chart with cost per hour/day

That is quite an extensive workaround. Dashticz might do the trick as well, or a python program. My point was to get it within Domoticz as a basic feature.

[gizmocuz]

Yes that's correct, that is with all sensors

You can install InfluxDB/Grafana with docker compose and you be up in no time (once you have configured it)

So we might need a new table to store hourly values and keep them (or keep then for xxx configurable days)
But the InfluxDB way solves it for now

[Zuikkis]

I'm looking into this as I have exact same problem. I'm currently using incremental custom counters that update automatically when the main kwh counter update, in dzVents script:

return {
        active = true,
        on = {
                devices = { 'Osku Kulutus' } 
        },
        data = {
                osku = {initial=0} 
        },

        execute = function(domoticz, item)

            -- electricity price per kwh stored in this sensor
            local ostoh=domoticz.devices('Sähkön tuntihinta').sensorValue         

            if (item.isDevice and item.name=='Osku Kulutus') then
                local counter=domoticz.devices('Osku hinta')
                local wh=domoticz.devices('Osku Kulutus').rawData[2]

                if (tonumber(domoticz.data.osku)~=0) then
                  -- calculate difference between current Wh and previous Wh (osku variable), multiple by Wh price
                  local hinta=domoticz.utils.round((ostoh*(wh-domoticz.data.osku))/1000,1)

                  counter.updateCounter(hinta)
                end
                domoticz.data.osku=wh
            end

        end
}

This works well for normally incrementing kWh counters, but causes all kind of trouble if "local hinta=" result becomes negative.

Instead of creating new device type, I thought I simply modify incremental counter (and perhaps regular custom counter?).. Changes needed are as listed by @WillemD61 above.

[luzpaz]

Any progress on this ?

[Zuikkis]

Any progress on this ?

Already working fine after my PR. Just create a custom sensor with your preferred unit (€, £, $) and a multiplier of 100 so you get cents... then just update with a dzvents script.

Example using an incremental counter above. Incremental is perhaps slightly easier but could be a regular counter too.

[roblomq]

When I use a custom sensor in Version: 2023.2 (build 15656) it looks like below. Not really useful when using costs would be better to have bars with totals a day, month, year and so on.

[Zuikkis]

Sorry I was a bit unclear in my previous post. Use a custom counter, not sensor.

Should look like this:

[roblomq]

Ah, it's a "Managed counter" and after creation you can set it to Type "Custom". Thanks!

[Zuikkis]

Or just "counter" or even "counter incremental", both can be set to custom. It depends on your dzVents code which is easiest to use. I'm using incremental counters.

[gizmocuz]

For Dutch users the Enever hardware in Domoticz could also be used when using a dynamic contract.
The actual electricity/gas price is provided as well as a daily(tomorrow) schedule