When setting OLED Type to 0 (no OLED display), I wouldn't expect any calls to OLED related stuff during boot.

With firmware 2.0.1:

      Firmware Version [v2.0.1 (17-04-2020)]
              Compiled [Dec 11 2020  19:24:43]

such OLED calls seem to happen while booting:

         OLED Type (0, 1, 2) : 0
OLED Sleep Min. (0=oneindig) : 0
     Flip Oled (0=No, 1=Yes) : 0
                  Index Page : DSMRindex.html

==== MQTT settings ==============================================
          MQTT broker URL/IP : :1883 (NOT Connected!)
                   MQTT user :
               MQTT password : *************
          MQTT send Interval : 0
              MQTT top Topic : DSMR-API
-
[15:54:35][  23184| 22944] oled_Init   (  89): OLED is [128x 64], charHeight[14], lineHeight[16], nrLines[4]

Hello,

What do i have to change/add to my config files so that i can Configure grid consumption in the new home assistant energy dashboard?

Regards,
Joey

Hi @mrWheel,

First of all thanks for your great work on this. I'm really happy with my DSMR logger 4.5.
I was wondering on 2 things.

1. Is there a specific reason why on MQTT the value and unit are returned in an array? We can expect only one value and unit for each topic, right?
2. Why is the topic name also returned in the MQTT message?

Example:
Topic: DSMR-API/power_delivered
"{"power_delivered": [{"value": 1.674, "unit": "kW"}}"]

Could be:
Topic: DSMR-API/power_delivered
{"value": 1.674, "unit": "kW"}}"

I made a code change to not add the [] in the jsonstuff.ino (to fix question 1). Do you want me to make a PR on this for future addition?

Hi,

Today I noticed that the time is off on my DSMR logger. It is showing 2020-12-10 16:59:55 which is incorrect.
I'm unable to find a way to adjust it.
Please guide me!

Kind regards,
Mathieu

Enabled

#define USE_NTP_TIME 

And see in serial monitor:

[20:58:28][  20008| 19824] setup       ( 368): Time is set to [210605205828W] from NTP

(The "W" is strange btw) and no time is set if i debug the /api/v1/dev/time request:

Also reflects as such in the UI:

1. Het haakje sluiten symbool van "OLED type" staat na de input box ipv ervoor zoals het bij de rest is.

2. De UI box van de "Oled Screen Time (Min., 0=infinite)" heeft een up en down arrow in de input box maar als je deze gebruikt om van "0" naar een hogere waarde te gaan kun je hem niet meer met die arrows op 0 zetten. Lijkt erop dat de minvalue van de controls op '1' staat.

Zou het mogelijk zijn om het gas gebruik berekend op de api te krijgen? Mijn doel is om het gas gebruik op een 24u chart te laten zien, telijk met energie gebruik en levering (home assistant).

Ik gebruik MQTT om te publishen vanaf de logger. Daar wordt wel Gas_delivered gepost, maar dat is de som van het gebruik. Ik zag dat het in de UI al ergens berekend getoond wordt:

Maar ik zie deze waarden niet op de rest API: http://dsmr-api.local/api/v1/sm/fields (en ook niet op mqtt).

Is het mogelijk om het (berekend, iets als gas_used_today ) gas gebruik (bijv. in Home Assistant te krijgen, door de DSMRLoggerAPI te gebruiken?

Overigens, bedankt voor de DSMR-logger. Werkt perfect!

DSMR4, DSMR logger v4.5 met DSMRLoggerAPI (huidige laatste versie)

How do i get the correct entity in my Energy dashboard of Homeassistant.

In my configuration i have added :

• platform: rest
  name: "DSMR_API_Gas gebruik"
  resource: http://192.168.2.98/api/v1/sm/fields/mbus2_delivered
  unit_of_measurement: m3
  value_template: '{{ (value_json.fields[1].value) | round(3) }}'
  device_class: gas
  state_class: total_increasing

Using the 4.5 kit with software version 3.0.1 currently. While the DSMR is connected to my main wifi network, it is still broadcasting its own DSMR network. Is there an option to disable this in case the wlan client is connected to an AP?

Ik heb op externe locatie een DSMR logger met de DSMR-API v3.0.2 draaien. Deze verzend de MQTT berichten elke X periode naar een broker bij mij thuis. Met enige regelmaat veranderd het veld "Verzend MQTT Berichten (Sec.)" naar "0" waardoor ik geen MQTT berichten meer binnen krijg.

Of ik deze waarde nu op 5, 20 of 60 zet. Dat maakt niet uit. Wanneer ik constateer dat HomeAssistant geen updates meer krijgt en ik extern inlog op de DSMR logger dan zie ik dat "Verzend MQTT Berichten (Sec.)" weer eens op "0" staat. Zodra ik dit aanpas naar een getal boven 0 dan komende updates weer binnen.

Is dit een bug?

Hi Willem,

Are the pre-compiled .bin-files for v3.0.1 also suitable for the ESP-01 board (with 1MB flash)?

If not, could you create them?

Thanks!

Hello, could you please correct my name in your documentation and blog.
if you want to refer someone from GitHub, check the name on the users page.
my name is Juraj Andrassy, not Jan Drassy

See attached screenshot.
Y-axis unit of measure shows Watt/hour (watt per hour)

valid unit of measure is Watt-hour (Wh)

Having Wemos as hardware, both Wemos devices result in Bailout due to low heap (8088 bytes)) in about 30 minutes till 2 hours after (re)start.

Most of the times the request per heading [Time----][FreeHeap/mBlck][Function----(line): alternates between (5 times):

• processAPI(/api/v1/dev/time)

and (1 time == once a minute):

• processAPI(/api/v1/dev/info)
• processAPI(/api/v1/sm/actual)
• processAPI(/api/v1/dev/time)

Board info

==================================================================

            (c)2019 by [Willem Aandewiel]
      Firmware Version [v2.0.1 (17-04-2020)]
              Compiled [Dec 11 2020  19:24:43]
         compiled with [dsmr.h]
              #defines [USE_MQTT]
   Telegrams Processed [257]
           With Errors [1]
              FreeHeap [1424]
             max.Block [1256]
               Chip ID [DB515B]
          Core Version [2_7_1]
           SDK Version [2.2.2-dev(38a443e)]
        CPU Freq (MHz) [80]
      Sketch Size (kB) [490.86]
Free Sketch Space (kB) [1556.00]
         Flash Chip ID [00164068]
  Flash Chip Size (kB) [4096]
   Chip Real Size (kB) [4096]
      SPIFFS Size (kB) [1907]
      Flash Chip Speed [40]
       Flash Chip Mode [DIO]
==================================================================

            Board type [ESP8266_GENERIC]
                  SSID [AP]
               PSK key [**********]
            IP Address [192.168.33.28]
              Hostname [MaSa-DSMR]
     Last reset reason [Exception]
                upTime [0(d)-00:49(H:m)]
==================================================================

           MQTT broker []
             MQTT User []
         MQTT PassWord [**********]
             Top Topic [DSMR-API]
       Update Interval [0]
==================================================================

De huidige implementatie heeft een REST API, een MQTT client en https://mindergas.nl/ push connectie. Het lijkt me tof om daar ook een generieke HTTP push functionaliteit bij te maken. Gewoon de allersimpelste implementatie waar de DSMRLogger de hele packet upload naar een te definiëren URL. Dat scheelt weer een actief draaiende broker, en kan bijvoorbeeld op een serverless oplossing draaien om de data op te slaan. Moet prima passen in bijvoorbeeld de Free Tier van Google Cloud Run.

Zou u daar oren naar hebben als ik dat contribute? Of heeft u dat zelf al eens gemaakt?

Met een dynamisch op te maken payload kan je het zelfs uploaden naar een gratis instantie van Grafana. Daarvoor kan je requests maken zoals deze:

# Prometheus format
API_KEY="1234:your-api-key"
URL="https://influx-prod-01-eu-west-0.grafana.net/api/v1/push/influx/write"

curl -X  POST -H  "Authorization: Bearer $API_KEY" -H  "Content-Type: text/plain" "$URL" -d "test,bar_label=abc,source=grafana_cloud_docs metric=35.2"

of deze

# Graphite format
API_KEY="1234:your-api-key"
URL="https://graphite-prod-01-eu-west-0.grafana.net/graphite/metrics"

curl -X  POST -H  "Authorization: Bearer $API_KEY" -H  "Content-Type: application/json" "$URL" -d '[{
        "name": "test.metric",
        "interval": 10,
        "value": 12.345,
        "tags": ["foo=bar", "source=grafana_cloud_docs"],
        "time": 1690564325053
    }]'

Met deze settings zou je er vgm moeten zijn:

• url
• headers
• payload format, met daarin %01% tm %99% die dan vervangen worden met vaste velden uit de DSMR payload.

The ESP can run AP mode and connect to another network simultaneously. This is a useful scenario when you don't have your main Wi-Fi enabled 24/7, and log the telegrams externally in DSMR reader (which can connect to the ESP). Perhaps one additional option can be added in the configuration options to enable this behavior (with a password).

Hi,

I just got my Slimme meter uitlezer V4.5 with DSMRloggerApi and I'm very glad how it works.
I'm using Home-Assistant and I have first tried to use the DSMR Slimme lezer integration for Home-Assistant via network.
This integration connects to the reader via telnet and expects only raw telegram lines; DSMRloggerApi is a bit too chatty and HA can't cope with all the logs.
Of course I can (and did) use the rest sensors with the provided API, but as HA is already ready for this, would it be difficult to adapt DSMRLoggerApi with the possibility to just get the telegram messages and nothing else over telnet?
Maybe add a setting that limits the telnet logs output to the raw telegram messages and so HA can read them and no need to use the rest sensor.

Thanks

Daniel

Hi,

Thanks for all the hard work on this very interesting repository! I would like to try the firmware before buying the official hardware. I have successfully installed DSMRloggerAPI on a generic esp-12s module. Unfortunately I haven’t been successful in collecting data from my slimme meter. I have connected gnd to gnd 3.3v to rts and rxd to txd. Does this firmware listen on a different gpio somehow? Is wat i want to achieve even possible? Thanks allot!

Goedemorgen,

Ik heb de DSMR-logger en deze werkt al een tijdje naar behoren.
Wat me wel opvalt is dat er geen waardes worden gegeven bij gebruik, zowel totaal als per fase.
Wel wordt de totale energie verbruikt weergegeven. Dit berekent hij toch en dan zou je verwachten dat de andere waardes ook aanwezig moeten zijn..
Is dit normaal en waarom wordt dit niet weergegeven?

na upgrade naar 3.0.3 krijg ik geen telegram meer:

/CTA5ZIV-METER

1-3:0.2.8(50)
0-0:1.0.0(221014124503S)
0-0:96.1.1(4530303639303030373036303438353230)
1-0:1.8.1(015656.494kWh)
1-0:1.8.2(007273.675kWh)
1-0:2.8.1(005398.994kWh)
1-0:2.8.2(011377.465kWh)
0-0:96.14.0(0002)
1-0:1.7.0(00.913kW)
1-0:2.7.0(00.388kW)
0-0:96.7.21(00052)
0-0:96.7.9(00123)
1-0:99.97.0(10)(0-0:96.7.19)(220926071459S)(0009424614s)(220926071459S)(0009424614s)(220926071459S)(0009424614s)(220901104303S)(0007277098s)(220901104303S)(0007277098s)(220901104302S)(0007277097s)(220807141135S)(0005129610s)(220807141135S)(0005129610s)(220807141135S)(0005129610s)(220713174005S)(0002982120s)
1-0:32.32.0(00010)
1-0:52.32.0(00013)
1-0:72.32.0(00013)
1-0:32.36.0(00016)
1-0:52.36.0(00038)
1-0:72.36.0(00028)
0-0:96.13.0()
1-0:32.7.0(238.0V)
1-0:52.7.0(238.0V)
1-0:72.7.0(239.0V)
1-0:31.7.0(003A)
1-0:51.7.0(002A)
1-0:71.7.0(001A)
1-0:21.7.0(00.358kW)
1-0:41.7.0(00.554kW)
1-0:61.7.0(00.000kW)
1-0:22.7.0(00.000kW)
1-0:42.7.0(00.000kW)
1-0:62.7.0(00.388kW)
!6583
Telegram has 1036 chars

[12:44:55][ 17440| 5616] processAPI ( 64): from[192.168.13.14] URI[/api/v1/dev/time] method[GET]
[12:44:57][ 17688| 5616] processSlimm( 36): handleSlimmerMeter RawCount=[ 20]
[12:44:57][ 17440| 5616] processAPI ( 64): from[192.168.13.14] URI[/api/v1/sm/actual] method[GET]
[12:44:59][ 17440| 5616] processAPI ( 64): from[192.168.13.42] URI[/api/v1/sm/telegram] method[GET]
[12:45:00][ 17400| 5616] handleSmV1Ap( 306): read [1014] bytes
[12:45:00][ 16056| 5616] handleSmV1Ap( 309): telegram > [1024] bytes. Bailout!

De telegrams lijken te groot en zijn niet meer op te vragen omdat MAX_TLGRM_LENGTH op 1024 staat.

Jur.

Via Telnet:
processSlimm( 166): Parse error
1-0:31.7.0(000.91*A)
^
Missing unit

raw telegram:
1-0:1.8.1(000861.264kWh)
1-0:1.8.2(001283.641kWh)
1-0:2.8.1(000054.676kWh)
1-0:2.8.2(000026.493kWh)
0-0:96.14.0(0001)
1-0:1.7.0(00.000kW)
1-0:2.7.0(00.621kW)
1-0:21.7.0(00.000kW)
1-0:41.7.0(00.000kW)
1-0:61.7.0(00.000kW)
1-0:22.7.0(00.077kW)
1-0:42.7.0(00.219kW)
1-0:62.7.0(00.325kW)
1-0:32.7.0(233.1V)
1-0:52.7.0(232.4V)
1-0:72.7.0(233.3V)
1-0:31.7.0(000.94A)
1-0:51.7.0(001.38A)
1-0:71.7.0(001.43A)

The time is fixed at 2021-01-11 19:52.
I updated firmware and spiffs.
After that time is fixed at 2001-01-01 01:01:01
Because time is not right, all measurements are placed in wrong interval.

Is it possible to adjust time by timestamp from telegram?
Or maybe a setting to fill in the time server?

Hi,

I use a D1 mini clone to run your DSMRloggerAPI. All runs fine for 1 hour but then I get Bailot messages.

Did I use the wrong setting to flash the D1? Or is there something else I could do to make it run stable?

Tnx in advance for any hint :)

[Time----][FreeHeap/mBlck][Function----(line):

[14:44:54][   5320|  4328] processTeleg(  15): Telegram[568]=>DSMRdata.timestamp[200418144455S]
[14:44:55][   5320|  4328] processTeleg(  44): actHour[14] -- newHour[14]
[14:44:55][   5320|  4328] sendMQTTData( 226): ==> Bailout due to low heap (5320 bytes)
[14:45:04][   5064|  4328] processSlimm(  97): telegramCount=[568] telegramErrors=[1]

[Time----][FreeHeap/mBlck][Function----(line):

[14:45:04][   5064|  4328] processTeleg(  15): Telegram[569]=>DSMRdata.timestamp[200418144505S]
[14:45:05][   5064|  4328] processTeleg(  44): actHour[14] -- newHour[14]
[14:45:05][   5064|  4328] sendMQTTData( 226): ==> Bailout due to low heap (5064 bytes)
[14:45:14][   5320|  4328] processSlimm(  97): telegramCount=[569] telegramErrors=[1]

[Time----][FreeHeap/mBlck][Function----(line):

[14:45:14][   5320|  4328] processTeleg(  15): Telegram[570]=>DSMRdata.timestamp[200418144515S]
[14:45:15][   5320|  4328] processTeleg(  44): actHour[14] -- newHour[14]
[14:45:15][   5320|  4328] sendMQTTData( 226): ==> Bailout due to low heap (5320 bytes)
[14:45:15][   5320|  4328] processSlimm( 174): Processed [570] telegrams ([1] errors)

In the blog comments I read that some smart meters output duplicate data every second, at least update their output slower then 1Hz.

Is there more information available?
F.e.

• Which smart meters suffer from this duplication behavior?
• Will even the time stamp be identical to previous telegrams?
• Which values are identical, and which values change between telegrams?

Documentation at https://mrwheel.github.io/DSMRloggerWS/hardware_V4.5/#dsmr-logger-versie-45 is linked from opencircuit.nl

Neither https://opencircuit.nl/product/slimme-meter-uitlezer-v4.5-geassembleerd nor the documentation at github.io lists the dimensions (length, width, height) of the (1) bare and (2) populated PCB.

PS This info helps to purchase a box that fits the board.

In several pages units are not correct.

e.g: power consumption / energy consumption is in Watt-hour

power: in Watt

perhaps a small fix in a table that is reused over the application?

Hi
I come from 1.2.1 and I did the update and have 1 question about the DSMRindex.js

1. backup of RING files OK
2. Upload ino.bin (BEversion) OK
3. Upload spiffs.bin OK
4. Put back the RING files OK
5. Then I downloaded the SOURCE CODE (ZIP) and extracted it and then did an upload of the file DSMRindex.js with FSexplorer

Is step 5 good? Everything seems OK.

Is there a way to backup the system/settings? Because the MQTT and cost settings are always gone when I do a update OTA?

Since 11/12/2020, the display of the logger shows: wait for the first telegram.
restart nothing helps.
is a Belgian digital meter.
any solution for this?

Op het display van de logger komt sinds 11/12/2020 te staan : wacht op eerste telegram.
herstart helpt niets.
is een Belgische digitale meter.
enige oplossing hiervoor?

Eerst "DSMRloggerAPI.ino.bin" uploaden,

of eerst de nieuwe bestanden

• DSMRindex.html
  

• DSMRindex.js
  

• DSMRversion.dat
  

naar het bestandssysteem uploaden en daarna "DSMRloggerAPI.ino.bin" flashen?

In per Uur:

De nieuwe versie van mindergas werkt nog niet helemaal goed.
Mindergas verwerkt de data niet.
Bij device info is de status van :

Mindergas Terugkoppeling: NO_AUTHTOKEN (de token informatie is wel juist ingevoerd en geverifieerd.)

Mindergas Status (@dag | tijd) @15|22:48 -> :0

De URL is veranderd van http(s)://www.mindergas.nl/api/gas_meter_readings naar http(s)://www.mindergas.nl/api/meter_readings. Hierdoor worden geen gegevens meer doorgestuurd.

Compiler arduino stops with error @line 398 restapi
with:
exit status 1
expected primary-expression before ')' token

How do resolf this error, i'am not diehard programmer in arduino

Ik heb gisteren op mijn DSMRlogger V3.0.4 een MQTT broker geconfigureerd. Dat leek niet direct te werken, dus ik heb hem een reboot gegeven vanuit de webinterface.

Hij is helaas hierna niet stabiel terug gekomen. Mijn eerste indicator dat er wat mis is was dit ping resultaat:

PING DSMRlogger (local_subnet.135) 56(84) bytes of data.

From laptop (local_subnet.121) icmp_seq=751 Destination Host Unreachable
From laptop (local_subnet.121) icmp_seq=752 Destination Host Unreachable
From laptop (local_subnet.121) icmp_seq=753 Destination Host Unreachable
64 bytes from DSMRlogger (local_subnet.135): icmp_seq=759 ttl=255 time=139 ms
64 bytes from DSMRlogger (local_subnet.135): icmp_seq=765 ttl=255 time=270 ms
64 bytes from DSMRlogger (local_subnet.135): icmp_seq=775 ttl=255 time=40.0 ms
64 bytes from DSMRlogger (local_subnet.135): icmp_seq=776 ttl=255 time=8.36 ms
From laptop (local_subnet.121) icmp_seq=787 Destination Host Unreachable
From laptop (local_subnet.121) icmp_seq=788 Destination Host Unreachable

--- DSMRlogger ping statistics ---
898 packets transmitted, 66 received, +152 errors, 92.6503% packet loss, time 916576ms
rtt min/avg/max/mdev = 5.686/194.516/2253.284/307.312 ms, pipe 4

Als ik de DSMRlogger reboot door de P1 kabel eruit te halen, en er weer in te steken zie ik dat hij een tijdje goed reageert op ping berichten, en daarna weer hetzelfde gedrag vertoont.

Als ik zo snel mogelijk verbind met de telnet poort, zie ik dat de DSMRlogger wel opstart, maar het lijkt erop dat hij bij het verwerken van het eerse telegram vast loopt:

Connected to WIFI
IP address: local_subnet135
IP gateway: local_subnet254

[21:00:03][ 25272| 24920] startMDNS ( 134): [1] mDNS setup as [DSMR-API.local]
[21:00:03][ 23416| 23376] startMDNS ( 137): [2] mDNS responder started as [DSMR-API.local]
[21:00:05][ 24736| 23256] startNTP ( 44): Starting UDP
[21:00:05][ 23160| 22608] startNTP ( 46): Local port: 8888
[21:00:05][ 23264| 22608] startNTP ( 48): waiting for NTP sync
Transmit NTP Request
nl.pool.ntp.org: 158.101.221.122
Received NTP Response => new time [2023-02-08 21:17:42 (CET)]
Daylight Saving Time
NTP time is [2023-02-08 22:17:42 (CEST)]
Transmit NTP Request
0.nl.pool.ntp.org: 129.250.35.251
Received NTP Response => new time [2023-02-08 21:17:42 (CET)]
Daylight Saving Time
NTP time is [2023-02-08 22:17:42 (CEST)]
[22:17:42][ 23152| 22608] setup ( 341): NTP time is [2023-02-08 22:17:42 (CEST)]
[22:17:43][ 24496| 23256] setup ( 353): Last reset reason: [External System]
[22:17:43][ 23152| 22608] DSMRfileExis( 650): check if [/DSMRindex.html] exists .. Yes! OK!
[22:17:44][ 24496| 23256] DSMRfileExis( 650): check if [/DSMRindex.html] exists .. Yes! OK!
[22:17:44][ 24496| 23256] DSMRfileExis( 650): check if [/DSMRindex.js] exists .. Yes! OK!
[22:17:45][ 24496| 23256] DSMRfileExis( 650): check if [/DSMRindex.css] exists .. Yes! OK!
[22:17:45][ 24496| 23256] DSMRfileExis( 650): check if [/DSMRgraphics.js] exists .. Yes! OK!
[22:17:46][ 24496| 23256] DSMRfileExis( 650): check if [/FSmanager.html] exists .. Yes! OK!
[22:17:47][ 23992| 23256] DSMRfileExis( 650): check if [/FSmanager.css] exists .. Yes! OK!
Daylight Saving Time
[22:17:47][ 22624| 21960] setup ( 417): Time is set to [230208221747S] from NTP
[22:17:50][ 23968| 23256] setup ( 446): FSYS correct populated -> normal operation!
[22:17:53][ 22456| 22256] setup ( 492): HTTP server gestart
[22:17:56][ 22456| 22256] processMinde( 93): Mindergas State: MG_INIT
[22:17:56][ 21112| 20960] processMinde( 121): MinderGas Authtoken is not set, no update can be done.
[22:17:56][ 21112| 20960] setup ( 515): Startup complete! actTimestamp[230208205956W]
[22:17:56][ 21112| 20960] setup ( 524): Last reset reason: [External System]
[22:17:56][ 22032| 21672] setup ( 536): Enable slimmeMeter..
[22:17:56][ 20688| 20376] setup ( 539): Swapping serial port to Smart Meter, debug output will continue on telnet
[22:17:56][ 22032| 21672] setup ( 543): Serial will be set to 115200 baud / 7N1

Commands are:

B - Board Info
*E - erase file from FSYS
L - list Settings
D - Display Day table from FSYS
H - Display Hour table from FSYS
M - Display Month table from FSYS
I - Identify by blinking LED on GPIO[02]
P - No Parsing (show RAW data from Smart Meter)
*W - Force Re-Config WiFi
*R - Reboot
S - File info on FSYS
*U - Update FSYS (save Data-files)
*Z - Zero counters

V - Toggle Verbose 1
T - Force update mindergas.nl
[22:18:07][ 20448| 19696] processSlimm( 83): telegramCount=[101611] telegramErrors=[0]

[Time----][FreeHeap/mBlck][Function----(line):
[22:18:07][ 19488| 19048] modifyMbusDe( 203): mbus1_delivered [2614.036]
[22:18:07][ 19488| 19048] modifyMbusDe( 207): gasDelivered .. [2614.036]
[22:18:07][ 19488| 19048] processTeleg( 15): Telegram[101612]=>DSMRdata.timestamp[230208211840W]
[21:18:40][ 19488| 19048] processTeleg( 44): actHour[20] -- newHour[21]
[20:59:56][ 19488| 19048] writeDataToF( 221): >23020820; waarde; waarde; waarde; waarde; 2614.036; ;[21:18:40][ 20832| 19696] writeLastSta( 69): writeLastStatus() => 230208205956W; 6; 0; 101612;

Door dit alles heb ik het idee dat er iets mis is met mijn MQTT config, en zou deze dus graag ongedaan willen maken. Maar aangezien de webinterface nooit bereikbaar wordt kan ik het niet daar doen, of via de API.

Een factory reset zou kunnen, maar kan nergens in de documentatie vinden hoe dat moet? Wat nu? Misschien is er een andere oplossing om dit toch te fixen?

p.s. Na de installatie van V3.0.4 2 weken geleden had ik ook al wat problemen met opstarten, ik heb het niet echt meer heel helder voor de geest, maar ik denk dat dat voornamelijk was omdat de DSMRLogger geen internet had voor de NTP connectie. Al kan het ook een algemener probleem zijn.

Hi
Is it possible to update for Belgium?
From 01/01/2023 there is a quarterly measurement of peak tariff.

I found some info on GitHub.
https://maakjemeterslim.be/rails/active_storage/blobs/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBZ0lEIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--cdd9b48fd0838e89b177f03b745b23450fd8f53e/e-MUCS_P1_Ed_1_7_1.pdf?disposition=attachment

ndokter/dsmr_parser@d05fe26

Thanks in advance

Een paar dagen terug zijn mijn slimme elektriciteit- en gasmeter vervangen. De meterstand van de nieuwe meters begint weer bij 0 en DSMRloggerAPI laat nu geen meterstand meer zien voor de huidige maand. Hoe kan ik dit in de DSMRlogger het beste corrigeren?

https://mrwheel.github.io/DSMRloggerWS/QenA/ bevat een sectie met de kop "Niet alles DSMR 4 is DSMR 4 ..".

Daar wordt verwezen naar https://willem.aandewiel.nl/index.php/2018/08/28/slimme-meter-uitlezer/#comment-368

In die comment wordt gesuggereerd dat de Kaifa MA304 (=DSMR 4.0.7) P1-poort 250 mA zou moet kunnen leveren.

Volgens mij specificeert DSMR:

• 4.x een 100 mA,
• 5.x pas 250 mA.

Wellicht die (oude) ...WS documentatie nog aanpassen in iets dat de "Slimme meter uitlezer vX.X" tijdens WiFi-communicatie meer dan 100 mA stroom verbruikt en daarom waarschijnlijk P1-poort gevoed kan worden vanaf DSMR 5.X (met een link naar https://mrwheel-docs.gitbook.io/dsmrloggerapi/slimme-meters)

Having solar panels that return energy (no delivery during sunny times) makes HJMindex display "0.000" for all phases.

It would be great if the gauges can go negative.

Trying to fix that myself, I think when delivery is 0, then fetch returned energy. Though nvKW<0 inside the if (nvKW == 0 ) block, and becomes 0 just after it: console.log("nvKW = "+ nvKW.toString()).

I am stuck, possibly due to asynchronous requests. Any help is welcome.

function update()
{
    var phase;
    for( let phase = 1 ; phase <= PHASES ; phase++ )
    {
        fetch(APIGW+"v1/sm/fields/power_delivered_l"+phase)
        .then(response => response.json())
        .then(json => 
          {
            for( let j in json.fields ){
                // console.log(json.fields[j].name+" -- "+ "power_delivered_l"+i.toString())
                if (json.fields[j].name.startsWith("power_delivered_l"))
                {

                    myPhase = Number(json.fields[j].name.replace('power_delivered_l',''));

                    let cvKW=document.getElementById(json.fields[j].name).innerHTML
                    let nvKW=Number(json.fields[j].value)
                    if (nvKW == 0 ) // check if power is generated
                    {
                        //console.log("nvKW = "+nvKW.toString())
                        fetch(APIGW+"v1/sm/fields/power_returned_l"+myPhase)
                        .then(response => response.json())
                        .then(json2 => 
                          {
                            for( let jr in json2.fields ){
                                if (json2.fields[jr].name.startsWith("power_returned_l"))
                                {
                                    let nvKW=-1*Number(json2.fields[jr].value)
                                    console.log(json2.fields[jr].name+" = "+ nvKW.toString())
                                    ˆˆˆˆ<- here nvKW < 0
                                }
                            }
                          }
                        );
                    }

                    console.log("nvKW = "+ nvKW.toString())
                                    ˆˆˆˆ<- here nvKW = 0
                    let nvA=nvKW*1000.0/220.0  // estimated amps using fixed voltage