Closed braham2019 closed 4 years ago
Bedankt voor je vraag. Als je binnen de applicatie deze URL opent: /admin/dsmr_datalogger/meterstatistics/1/change/
, dan zie je onderaan de pagina als het goed is het telegram. Je zou even een telegram kunnen bekijken van voor 15:00 en eentje van na 15:00 om te zien wat het verschil is.
Je ziet dan waarschijnlijk een verschil in het cijfer van vlaggetje 96.14.0
, wat het huidige tarief aangeeft.
Je kunt hier de DSMR (NL) specs zien op pagina 20 en 21 van:
De huidige mapping binnen de applicatie staat hier:
Het lijkt overeen te komen, afgezien van de naamgeving.
Het lijkt er inderdaad op dat het omgedraaid is. Hier is hoogtarief 2
.
Bedankt voor je antwoord. Enige optie om in een toekomstige versie rekening te houden met deze speciale Belgische situatie ?
In de applicatie zelf kan ik niets voor je betekenen.
Maar ik denk dat ik wel een instelling kan maken die de mapping omdraait bij het inlezen van de gegevens. Dus dat het systeem van dagtarief hoogtarief maakt en vice versa voor nachttarief.
Als je het ergens kan meenemen in de roadmap, zou dat perfect zijn voor de Belgische Fluvius klanten. Ik weet niet hoe het zit met andere energietransporteurs (intercommunales) in België.
Ik zal kijken hoe ik dit kan realiseren op termijn.
@floyson-reference hoe zit het bij jou qua tarieven?
Ik besef me net dat ik in je ticket #697 alleen heb gehoord over gas dat niet verwerkt werd, maar niet over de naamgeving van de tarieven.
@braham2019 als ik de tarieven omdraai, dan heeft dat ook gevolgen voor iedereen en bestaande data. Dus wellicht is het achteraf niet zo handig om te doen.
Edit: ik bedoelde hierboven niet @MarbBram, excuus.
Had idd ook al opgemerkt dat niet klopt (in België toch)
Mvg Frederic Loyson
Bedankt voor de input. Ik denk dat ik de tarieven dan niet ga omdraaien. Ze zijn namelijk qua naamgeving nog steeds incorrect en het zijn technisch gezien tarief 1 en 2. Alleen heten ze anders in Nederland.
Ik zal in ieder geval de wijzigingen voor gasmeters doorpushen. Mochten er later meer verschillen zijn met Belgische meters, kan ik dat vrij eenvoudig rechttrekken.
Ik heb in DSMR.py deze omgedraaid. Dat werkt toch wel ? Wat bedoel je met dat je de tarieven niet gaat omdraaien ?
'1-0:1.8.1': 'electricity_delivered_2',
'1-0:2.8.1': 'electricity_returned_2',
'1-0:1.8.2': 'electricity_delivered_1',
'1-0:2.8.2': 'electricity_returned_1',
In de eerste instantie dacht ik dat de tarieven omgedraaid waren, maar ze kloppen wel. Het is puur de naamgeving die afwijkt in België. En in bijvoorbeeld Luxemburg is het wederom anders.
Er is namelijk nog een vijfde veld die het huidige tarief aangeeft en het is onlogisch als de applicatie de meterstanden wegschrijft op tarief 2, terwijl het eigenlijk tarief 1 is. Bijkomend nadeel is dat wanneer ik de tarieven nu omdraai, het bij alle andere gebruikers ook omgedraaid wordt.
Het kan zijn dat er ooit een instelling komt voor de naamgeving van de tarieven, maar dat is aardig wat werk om te realiseren.
Uitgebracht in v2.10
Ik heb gisteren geüpgraded naar deze versie. Ik merk nu echter twee problemen die de statuspagina aangeeft: gasmeting en statistieken
Daarnaast: piek- en dal zijn omgedraaid voor België en dus nog steeds niet correct. Is dat wat je bedoelt met de tarieven niet omdraaien? Want als ik de wijziging deed in DSMR.py zoals eerder vermeld, geeft hij wel alles goed weer.
Hoogtarief is bij ons 1, en daltarief is 2. Dit is bijvoorbeeld de huidige telegram. De gegevens worden wel correct ingelezen.
0-0:96.1.4(50213) 0-0:96.1.1(3153414731313030303339313932) 0-0:1.0.0(191106064458W) 1-0:1.8.1(000078.748kWh) 1-0:1.8.2(000105.187kWh) 1-0:2.8.1(000027.575kWh) 1-0:2.8.2(000007.706kWh) 0-0:96.14.0(0002) 1-0:1.7.0(00.456kW) 1-0:2.7.0(00.000kW) 1-0:32.7.0(231.9V) 1-0:31.7.0(002A) 0-0:96.3.10(1) 0-0:17.0.0(999.9kW) 1-0:31.4.0(999A) 0-0:96.13.0() 0-1:24.1.0(003) 0-1:96.1.1(37464C4F32313139303433323239) 0-1:24.4.0(1) 0-1:24.2.3(191106064003W)(00088.062*m3) !9136
Enig idee ?
Je kunt debug logging tijdelijk aanzetten en kijken in de backend log wat de reden is. https://dsmr-reader.readthedocs.io/nl/latest/troubleshooting.html#logging
Ik had niet gezien dat je in de configuratie Belgie-Fluvius moest selecteren; dus dat heb ik nu gedaan. Data van gisteren is ondertussen wel geprocessed en de gasmetingen komen nu ook door.
Wat is er nu eigenlijk precies geïmplementeerd in v2.10?
@braham2019 excuus, dat is wat slordig van mij. Ik had in mijn hoofd er (automatisch)melding van te maken maar ik heb dat blijkbaar niet gedaan.
@MarbBram er is ondersteuning voor Belgische meter en Luxemburgse meter. Echter, de tarieven zijn niet omgedraaid zoals eerder gemeld was. De tarieven hebben dezelfde tariefnummers als uit de slimme meter. De naamgeving van een tarief is namelijk het grootste verschil tussen NL en BE.
@braham2019 @MarbBram @floyson-reference
Ter info, in release v3.4 komt ondersteuning om zelf de namen in te stellen voor de tarieven (#858)
Hoi,
Vraagje. Bij mij (belgie) zijn ze ook omgedraaid. In de instelling heb ik belgie-fluvies (gas correctie) ingesteld. Maar de meter is idd omgedraaid.
Als ik het zo hier lees, moet ik gewoon die naamgeving veranderen? En wat dan met de MQTT berichten, moet ik ze na de naamgeving ook daar wijzigen of gaat dat mee?
@skank01 onderwater gaat het over "tarief 1" en "tarief 2", ook in MQTT.
De betekenis van deze tarieven verschilt tussen NL en BE, dus je zult daar inderdaad zelf de juiste naam aan moeten geven als het niet klopt met je eigen situatie. En dus ook in MQTT een andere betekenis moeten hangen aan de ontvangende zijde van de MQTT-berichten.
ok top dus in het dashboard van dsmr reader aanpassen , en dan in home assistant aanpassen? in de mqtt settings zelf niet he?
Ff offtopic, daarna zwijg ik De berekening van kosten, best in dsmrreader? of in home assistant? Top applicatie trouwens !! Bedankt daarvoor
Ik weet niet hoe het in HA werkt, maar ik kan me voorstellen dat een standaard DSMR MQTT ontvanger/dashboard in HA ook een tariefnaam toont ipv "tarief 1" of "tarief 2". Als dat het geval is, zul je ze daar moeten omdraaien. Als je in HA alleen tarief 1/2 ziet, zul je zelf moeten onthouden welke tariefnummer wat is. Als alternatief kun je in DSMR-reader ook nog de MQTT-mapping aanpassen en tarief 1 laten uitzenden op tarief 2 topic en andersom. Net wat je voorkeur heeft.
De "kosten" zoals in DSMR-reader zijn puur bedoeld voor een benadering/gevoel van wat een dag kost. Als dat afdoende is kun je het via DSMR-reader doen. Als je exact je leverancier wilt narekenen dan kun je dat het beste buiten DSMR-reader doen.
Hallo, ik gebruik sinds vanochtend v2.7 via een Raspberry Pi 3B+. De applicatie werkt uitstekend. De RPI is gekoppeld aan een Belgische digitale meter van Fluvius.
Op mijn dashboard zie ik echter dat momenteel (overdag om 15u) de metingen worden weergegeven van het daltarief, ipv het piektarief.
In België zijn OBIS codes 1.8.1 Totale afname van energie in kWh dagtarief 1.8.2 Totale afname van energie in kWh nachttarief 2.8.1 Totale injectie van energie in kWh dagtarief 2.8.2 Totale injectie van energie in kWh nachttarief
Wij noemen dat trouwens dag- en nachttarief ipv piek- en daltarief, maar dat terzijde. Zie ook: https://www.fluvius.be/sites/fluvius/files/2019-04/Technische-info-Displays-digitale-elektriciteitsmeter.pdf
Zijn deze OBIS codes anders in België dan in Nederland ?
kudos trouwens voor een mooie applicatie :-)