Stadswarmte via (tweede) P1-poort

[wtreur]

Sinds enkele tijd levert onder andere vattenfall een slimme meter met p1-poort bij de stadswarmteset. Het lukte me vrij eenvoudig om deze data uit te lezen en is conform DSMR-spec (in ieder geval voor de meter die ik heb). Bijvoorbeeld:

/AUR2NWA-MYRSKY

1-3:0.2.8(50)
0-0:1.0.0(210211165255W)
0-0:96.1.1(0)
0-1:24.1.0(004)
0-1:96.1.0(xxxxxxxxxxxxxxxx)
0-1:24.2.1(210211165255W)(24.466*GJ)
!D549

Het zou denk ik een mooie aanvulling zijn om hier ondersteuning voor in te bouwen. Zeker gezien er steeds meer wijken op stadswarmte worden aangesloten.

Wat hier wel speelt is dat er dan wel wel twee p1-poorten uitgelezen moeten worden als je het wilt combineren met elektra (en/of gas natuurlijk) De data gaat nml niet zoals bijvoorbeeld met gas via de p1-poort van de elektra-meter.

Ik ken de dsmr-reader functionaliteit voor gas niet zo goed, maar ik vermoed zo dat het er voor stadswarmte erg op kan lijken. Verbruik en prijs is per Gigajoule (in plaats van m3), voor de rest komen er geen andere getallen uit het telegram bericht. (en de DSMR-spec heeft er voor stadwarmte ook niet meer dan dat dacht ik)

Zelf ben ik niet echt een python-held, anders had ik wel een poging gedaan er in een eigen fork wat mee te proberen. Desondanks vind ik het wel leuk hier tijd in te steken. (misschien eerst maar is beginnen met een crash-course python/django voor roestige java(script)-engineers 😅)

[dennissiemensma]

Bedankt voor je verzoek! Je bent eigenlijk de eerste die zich hiervoor meld en ik denk dat dit zeker een goede toevoeging is, omdat het idd onderdeel is van het DSMR-protocol.

Dat zeggende hebben is het inderdaad nog een uitdaging om meerdere P1-poorten te ondersteunen. Helaas heb ik dat niet meegenomen in de architectuur van DSMR-reader.
Ik denk dat je dan eigenlijk niet ontkomt aan twee remote dataloggers die via de API de telegrammen sturen + forceren dat DSMR-reader de tijd in het telegram moet overschrijven (= een feature). Of het groeperen van telegrammen moet uitgezet worden.

Hoe dan ook moet er uiteraard ook nog een hoop in DSMR-reader gebeuren, dus het zal wel even duren voordat ik hier inhoudelijk wat voor oplever.

[dennissiemensma]

Zou je nog kunnen aangeven wat de interval van de telegrammen is? Toevallig ook ongeveer elke seconde eentje?

[wtreur]

Ik heb hem met cu even laten lopen. Dit was het resultaat:

/AUR2NWA-MYRSKY

1-3:0.2.8(50)
0-0:1.0.0(210212110144W)
0-0:96.1.1(0)
0-1:24.1.0(004)
0-1:96.1.0(xxxxxxxxxxxxxxxx)
0-1:24.2.1(210212110144W)(24.689*GJ)
!7BA6

/AUR2NWA-MYRSKY

1-3:0.2.8(50)
0-0:1.0.0(210212110155W)
0-0:96.1.1(0)
0-1:24.1.0(004)
0-1:96.1.0(xxxxxxxxxxxxxxxx)
0-1:24.2.1(210212110155W)(24.689*GJ)
!B7F6

/AUR2NWA-MYRSKY

1-3:0.2.8(50)
0-0:1.0.0(210212110206W)
0-0:96.1.1(0)
0-1:24.1.0(004)
0-1:96.1.0(xxxxxxxxxxxxxxxx)
0-1:24.2.1(210212110206W)(24.689*GJ)
!43C8

/AUR2NWA-MYRSKY

1-3:0.2.8(50)
0-0:1.0.0(210212110217W)
0-0:96.1.1(0)
0-1:24.1.0(004)
0-1:96.1.0(xxxxxxxxxxxxxxxx)
0-1:24.2.1(210212110217W)(24.689*GJ)
!8F98

/AUR2NWA-MYRSKY

1-3:0.2.8(50)
0-0:1.0.0(210212110228W)
0-0:96.1.1(0)
0-1:24.1.0(004)
0-1:96.1.0(xxxxxxxxxxxxxxxx)
0-1:24.2.1(210212110228W)(24.689*GJ)
!578

/AUR2NWA-MYRSKY

1-3:0.2.8(50)
0-0:1.0.0(210212110239W)
0-0:96.1.1(0)
0-1:24.1.0(004)
0-1:96.1.0(xxxxxxxxxxxxxxxx)
0-1:24.2.1(210212110239W)(24.689*GJ)
!C928

/AUR2NWA-MYRSKY

1-3:0.2.8(50)
0-0:1.0.0(210212110250W)
0-0:96.1.1(0)
0-1:24.1.0(004)
0-1:96.1.0(xxxxxxxxxxxxxxxx)
0-1:24.2.1(210212110250W)(24.689*GJ)
!959

/AUR2NWA-MYRSKY

1-3:0.2.8(50)
0-0:1.0.0(210212110301W)
0-0:96.1.1(0)
0-1:24.1.0(004)
0-1:96.1.0(xxxxxxxxxxxxxxxx)
0-1:24.2.1(210212110301W)(24.689*GJ)

Met deze meter krijg ik dus om de 11 seconden een bericht. Overigens wordt de meetwaarde in GJ volgens de DSMR-5 spec maar om de 5 minuten geupdate. (bij mij lijkt dat wat onregelmatiger, maar dat zal wel door mijn verbruik komen) Daarnaast zie ik in de spec ook staan dat het bericht om de seconde gestuurd mag(moet?) worden.

Ik kan me voorstellen dat het relatief makkelijk is om meerdere (remote) loggers te draaien, maar dat het inderdaad vooral lastig is om die data/berichten goed samen te voegen.

[dennissiemensma]

Bedankt voor je aanvulling. Dat lijkt dat erg op DSMR-v5-meters met gas. Die updaten ook elke 5 minuten dacht ik. De inhoudelijk interval maakt dan wat minder uit en dat scheelt weer later.

[extera-nl]

Hier wil ik mij wel bij aansluiten!
Eventueel wil ik ook best een 2e instance draaien, met een 2e datalogger en het zo (voorlopig) van elkaar scheiden.

Alles in 1 (reader) zou perfect zijn! Maar enkel support voor stadswarmte zou al een enorme toevoeging zijn!

[dennissiemensma]

Bedankt voor je aanvulling! Ter transparantie, het zal wel even duren voordat deze feature in beeld komt. Andere zaken, zoals #1084, hebben komende tijd (als in maanden) meer prio. Mede door de grootte van de doelgroep.

[extera-nl]

begrijpelijk! In de tussentijd ga ik knutselen om de waardes via MQTT in HAS te krijgen, en daar om te zetten naar 'gas' verbruik

[JeroenHaringman]

Ik wil me hier ook graag bij aansluiten. Ik heb op dit moment nog geen meter met een P1-poort, maar die ga ik wel aanvragen. Het zou mooi zijn als DSMR-reader dit (met een tweede kabel) zou kunnen uitlezen.

Ik begrijp dat dit momenteel geen hoge prio heeft, maar zoals wtreur al aangaf zullen steeds meer wijken op warmtenetten worden aangesloten, dus deze wens kon wel eens bij steeds meer mensen opkomen.

[dennissiemensma]

Bedankt voor je aanvulling, staat genoteerd!

[JeroenHaringman]

Ik ben er inmiddels achter dat de stadswarmte leveranciers niet alleen qua techniek en businessmodel in de 19e eeuw leven, maar met hun meters ook nog (lang) niet bij zijn. Een meter die à la een gasmeter op de slimme elektriciteitsmeter kan worden aangesloten kunnen ze niet leveren.

Ik heb dus maar een IRDA adapter besteld (serieel over USB DMV een CP2102 chip) en ga wel kijken of zelf iets in python kan knutselen. Misschien kan ik de meetdata wel omrekenen naar gasverbruik en in de DSMR reader database zetten 😉 (denk niet dat ik daar daadwerkelijk aan begin). Ik heb een Kamstrup Multical 403 meter.

Mocht je ooit bezig gaan met het toevoegen van warmtenetten aan DSMR reader, en je wil meer gegevens, iets testen, etc please let me know. Ik kijk hier op GitHub niet vaak, mail me dan op [email protected].

[dennissiemensma]

@JeroenHaringman bedankt voor je aanvulling!

In dat geval denk ik dat het laat voor wat het is, als het niet via het DSMR-protocol gaat. Je suggestie om zelf een script te maken kan prima werken. Je hoeft het niet eens direct in de database te zetten, je kunt gewoon de API van DSMR-reader gebruiken.

Zie bijvoorbeeld dit plugin voorbeeld.
Je kunt dit niet 1-op-1 gebruiken, maar wel het stukje voor het aanroepen van de API. In dit geval wordt een heel telegram doorgestuurd, maar gezien je die niet hebt, kun je ook het andere (v2) endpoint gebruiken waar je de losse velden heen kan sturen, zoals een gasstand.

[extera-nl]

Je laatste opmerking is wel interessant...

Ik heb sinds kort een ESP met esp-link om stadswarmte uit te lezen. Dit werkt prima met de DSMR integratie van HAS. Die maakt gebruik van deze DSMR Parser.

Vervolgens zit ik de uitgelezen waarde in GJ om naar kubieke meters equivalent gasverbruik met een sensor template.
city_heating_gas_equivalent_consumption: friendly_name: City Heating - Gas equivalent device_class: gas unit_of_measurement: m³ value_template: "{{ (states('sensor.city_heating_energy_consumption') | float (0) * 32.68 ) | round(2) }}"

Nu nog iemand vinden die kan helpen om deze data in dsmr-reader te krijgen (die ik op een separate docker host draai).
@dennissiemensma zou jij hier nog wat extra handvatten voor kunnen geven?
Biedt DSMR reader bijvoorbeeld de mogelijkheid om de gasstand via de API binnen te krijgen? Dus zonder telegram?

[dennissiemensma]

Als je het op een aparte instantie draait, zou je de v2 datalogger API kunnen gebruiken. Zie /docs/api/redoc#tag/api/operation/Create DSMR reading op je installatie.

Je kunt dan denk ik alle verplichte elektravelden als 0-waarde meegeven en voor "gas" extra_device_timestamp en extra_device_delivered (= absolute meterstand). Wellicht werkt dat, nooit geprobeerd.

[extera-nl]

Thanks a lot!

I just spun up a new DSMR-Reading instance in docker, and let it connect to my ser2net P1 reader.
After running for a while so it has some data, I started posting to the instance with postman. Just one manually added gas meter value per minute.

Reading are showing just fine at the DSMR-Reading view in the admin dashboard, and are processed like other readings.
Data is showing in all statistics after that.

See example CURL command

 curl --location --request POST '{{DSMR-reader-API-host}}/api/v2/datalogger/dsmrreading' \
 --header 'Content-Type: application/x-www-form-urlencoded' \
 --header 'Authorization: Token {{DSMR-reader-API-key}}' \
 --data-urlencode 'timestamp=2022-08-28T23:45:00' \
 --data-urlencode 'electricity_currently_delivered=0' \
 --data-urlencode 'electricity_currently_returned=0' \
 --data-urlencode 'electricity_delivered_1=0' \
 --data-urlencode 'electricity_delivered_2=0' \
 --data-urlencode 'electricity_returned_1=0' \
 --data-urlencode 'electricity_returned_2=0' \
 --data-urlencode 'extra_device_timestamp=2022-08-28T23:45:00' \
 --data-urlencode 'extra_device_delivered=1594.150'

All thats left to do now, is get Home Assistant update the readings to DSMR-Reader using an automation / script

[BSandman]

Goed topic, jammer dat DSMR-reader nog niet met Warmtelink over weg kan.

Tipje: je kunt meerdere P1 poorten uitlezen met 1 P! uitlezer, moet je wel zorgen dat je geen dubbele 5V krijgt maar daarvoor kun je een RJ11 splitter aanpassen, meen dat ze zelfs te koop zijn. Scheelt een extra instance draaien....