amsreader-firmware icon indicating copy to clipboard operation
amsreader-firmware copied to clipboard

Sending accumulated values more frequently

Open jonthe101 opened this issue 1 year ago • 6 comments

Describe your problem I have recently started using AmsToMqttBridge and collecting the accumulated values (import/export) in home assistant through mqtt which works great. But I've noticed that the accumulated values are only sent once per hour. The values often gets sent a few seconds after the whole hour with the result that the energy consumption graphs in home assistant is displaced by one hour. This means that the daily consumption in HA is not correct (hours 00-01 contains consumption for 23-00 the day before). When combining with hourly electricity prices (in HA) the cost also isn't correct.

Is there any solution to this? Is it possible to get accumulated values more often through mqtt? I can see that the realtime consumption in the UI is updated more frequently.

Otherwise it's a really great software!

Hardware information:

  • Country: Sweden
  • Meter: Kamstrup
  • Encryption enabled: no
  • AMS reader: Pow-K+
  • M-bus adapter (if applicable):

Relevant firmware information:

  • Version: 2.1.6
  • MQTT: yes
  • HAN GPIO: [e.g. GPIO5]
  • HAN baud and parity: [e.g. 2400 8N1]
  • Temperature sensors [e.g. 3xDS18B20]
  • ENTSO-E API enabled: yes

jonthe101 avatar Aug 16 '22 15:08 jonthe101

If you get accumulated once every hour, this means that your meter only reports it at this rate (same as in Norway). There is no perfect solution for this. With MQTT in raw mode you would have had /realtime/import/hour and /realtime/import/day topics that would constantly send an estimated value for how much is used. These values are not currently implemented for HA payload. Nor are they 100% correct, but it is pretty damn close. It probably would be a good idea to implement the same data for HA, but I would need some advice on how the sensors should be configured.

gskjold avatar Aug 16 '22 18:08 gskjold

Ok, thanks for the explanation. I suspected that it was caused by the meter. I will test using the raw mode instead event though auto discovery is really nice. What configuration are you talking about? On the HA side i don't think there is any more configuration needed for the autodiscovered sensor.

jonthe101 avatar Aug 17 '22 08:08 jonthe101

There is no need for configuration for the autodiscovered sensors because the config is sent by the firmware :) So I need to know what kind of configuration to send for the sensors for realtime data. I am not a HA user myself, so I need some input on this.

gskjold avatar Aug 17 '22 08:08 gskjold

Yes, i know, that why it's great with autodiscovery :) I meant that i don't think it's necessary with any additional configuration in the autodiscovery messages that is already sent. Can't see why it wouldn't work with the existing config but with just more frequent updates. Oh, looked at the /realtime topics in the wiki, i see that it's per hur and day and not total.. it's the total that would be useful for the energy dashboard. I could look into configuration and see if realtime per hour and day can be used in some smart way. It's not possible to add a sensor with the accululated total + the calculated hourly values? With the same sensor config as the existing "Accumulated active import"?

I'd be happy to try out a beta if you want any input!

jonthe101 avatar Aug 17 '22 09:08 jonthe101

If you want to include /realtime/import/hour and /realtime/import/day to the HA payload I believe that the config should be the same as "Accumulated active import" ("dev_cla": "energy", "sta_cla": "total_increasing") at least from what I can tell from the docs and this blog post. A decreasing value would be interpreted as a new cycle. If these values are included in the HA payload I could make a template sensor combining accumulated and hourly values.

It would also be nice if the mqtt messages for accumulated values had the retain flag. As of now, if HA is restarted, the accumulated is undefined for an hour until next message is received.

jonthe101 avatar Aug 20 '22 11:08 jonthe101

I use MQTT Discovery a lot in my setup. I'll gladly have a look at the code and do some testing.

On this topic I would like to have the option on what topic to send the discovery config on, or at least change the default to sending the config based on the selected MQTT topic from the web gui. Seems to be hard coded to "homeassistant/sensor/" as far as I can tell from a quick look at the sources. This is a problem for anyone who has changed the mqtt discovery_prefix to from the default as you're only allowed one discovery_prefix in HA. The best and easiest solution is probably to use the input from the web gui to send all mqtt messages. E.g. "hemma" as a user input would send configs to "hemma/sensor/#" and the state data to "hemma/-static ams name-" or similar. Should work for HA without affecting other channels. An alternative would be to add a user input field for "discovery_prefix" which only is active or visible if "home assistant" is selected as a payload.

StarkJohan avatar Aug 31 '22 09:08 StarkJohan

Work in progress. Currently implemented auto configuration for sensors containing price and realtime data.

What I need to verify:

  • The new firmware functions with device configured from old auto config data (Version 2.1.7 or below)
  • The new price sensors are functioning as expected (Has future price 0-11, min/max price ahead and 1hr, 3hr and 6hr cheapest times ahead)
  • Real time sensors functioning as expected (Has month max, threshold, peaks, hour/day/month use/cost/produced)

WARNING: Use the DEV firmware below at your own risk. You need to be able to flash by USB/TTL if firmware does not work. esp32.zip esp32s2.zip esp8266.zip

gskjold avatar Sep 28 '22 18:09 gskjold

Merged this issue into #320

gskjold avatar Sep 30 '22 17:09 gskjold