Traagheid na Home Assistant integratie MQTT #2043
Comments
TommiieeSV
changed the title
|
Bedankt voor je melding. Zou je een debug info dump willen delen? Verder zou je in de log van het backend-proces moeten zien wat er allemaal gebeurt en wat er lang duurt: Je kunt voor de logs tijdelijk DEBUG-logging inschakelen, zodat je alles ziet. De exacte meldingen uit de About-pagina zijn ook handig om te delen. Het zou kunnen zijn dat de MQTT-verwerking te traag is en dat dat alles ophoudt. Of dat er teveel MQTT-berichten verstuurd worden, die ophopen en de achterstand niet meer ingehaald wordt. |
|
Dank voor de hulp. Ik heb de MQTT spullenboel weer even aangezet om verder te troubleshooten. De debug info dump: De logs van het backend proces kan ik niet vinden. Mijn docker container heeft onder /var/log geen 'supervisor' folder. De datalogger op de RPi in de meterkast heeft die wel, maar bevat logischerwijs alleen datalogger logs. Mijn docker container bevat onder /var/log een 4-tal folders: dsmr_backend, dsmr_datalogger, dsmr_webinterface en nginx. Alleen die laatste bevat logfiles, de 3 dsmr folders bevatten enkel lege bestanden met de namen 'current', 'lock' en 'state'. Ik heb op de About page nog geen foutmeldingen, maar die komen dadelijk vanzelf terug. Zodra ik ze heb zal ik ze posten. Tot die tijd kunnen we misschien uitzoeken hoe ik aan de logs ga komen als ik geen supervisor folder heb onder /var/log. Edit, eerste 2 meldingen binnen:
En nog een derde:
|
|
De logs waar ik op doel zijn overigens deze: xirixiz/dsmr-reader-docker#338 Ik draai zelf nog geen Docker, maar je zou de logs van de container zelf kunnen bekijken. Als je ze niet kan vinden, dan wellicht met iets als |
|
Ik heb een poging gedaan. Mijn default loglevel staat op ERROR. Ik heb deze eerst op WARNING gezet. Ik krijg dan dit: Ik heb ook DEBUG logging geprobeerd, maar die krijg ik hier moeilijk neergezet ivm max characters. Het werkt dus allemaal wel, maar het is dus een stuk trager dan zonder MQTT. Ik heb nu één alert:
|
|
Voor de debug-logging is het belangrijk dat je kijkt of je ziet of het versturen/verwerken van MQTT-berichten traag gaat. Bij dit voorbeeld gaat het bijvoorbeeld redelijk vlot, elk bericht kost telkens maar paar ms qua tijd, maar de vraag is of je niet meer berichten probeert te versturen dan je MQTT-broker aan kan. Je datalogger sleep staat op 5 seconden, dus DSMR-reader heeft 5 seconden om alle MQTT-berichten voor alle topics voor elk telegram (en wat je ook allemaal aan hebt staan) te versturen. Als dat niet in 5 seconden lukt, raakt die vanzelf steeds verder achter en hoopt het op. Het versturen van de MQTT-berichten gebeurt in hetzelfde proces als de rest, wat een |
|
Dank voor je reactie. Ik heb wat dagen moeten wachten omdat schijven heb vervangen in de Syno, waardoor de RAID moest rebuilden. In die tijd heb ik DSMR Reader maar even uitgeschakeld. Ik heb gekeken in de DEBUG logging die ik bewaard had, het lijkt er toch op dat de MQTT berichten snel verwerkt worden, al zie ik wel steeds 0,3 seconde vertraging na een queue_message: Ik heb MQTT nu weer even uitgezet en alle berichten in de queue verwijderd. Straks ga ik even spelen met de datalogger sleep instellingen. Ik merk dat de traagheid vooral inzet als ik de Telegram split topic en/of Meter statistics split topic enable. |
|
Ik heb zojuist uitgebreid getest. De volgende topics werken prima wanneer enabled:
DSMR Reader blijft snel en pagina's openen instant. De problematiek begint bij deze twee:
De problemen beginnen al als slechts één van deze enabled is. Het laden van pagina's (zowel front-end als back-end) gaat dan richting de 5 à 10 seconden. Ik heb getest met Meter Statistics split topic. Als ik deze enable, dan zie ik de queue oplopen. Als ik het topic weer disable, is de queue binnen no-time leeg. Ik heb daarop de datalogger sleep verhoogt in stappen, maar uiteindelijk naar 99. Hij weet dan de queue in principe leeg te vegen, maar:
Hetzelfde gedrag zie ik bij Telegram split topic. Ongeacht hoeveel berichten er in de queue staan of op welke value datalogger sleep staat, zodra deze is aangevinkt, duurt het laden van pagina's 5 à 10 seconden. Ik zie dus in feite 2 problemen:
|
|
Er zijn meerdere dingen die je kunt proberen:
De split-topics sturen een bericht voor elke regel die je aan hebt staan. Hier regels weghalen scheelt per regel 1 bericht per keer: Dat geldt voor elke split-topic die je aan hebt staan. VacuumDB kan met: |
|
Is de debug log de rauwe debug log? Of doe je een grep op Je zou in principe alles moeten zien wat er gebeurt, ook niet-MQTT-zaken, mits die voorbij komen. De korte vertraging van 0,1s - 0,3s kan meerdere oorzaken hebben:
Ik vermoed dat het het eerste is, gezien het queuen van berichten en het versturen losse acties zouden moeten zijn en ze in de logs als 1 actie lijken. |
|
De debug log was een snippet, ivm max aantal tekens hier. Hier is een wat langere snippet, tussen 2 telegram receives in: Dank voor je tips, mijn volgende bevindingen:
Het minderen van berichten zie ik niet als oplossing maar als workaround. Liefst blijf ik trouw aan de handleiding van de HA integratie. Wellicht dat overblijft dat de DB en/of DSMR-Reader te traag is, maar valt het pas op zodra MQTT werk moet gaan verzetten. Enige oplossing die ik daarvoor kan bedenken is SSD's in de NAS plaatsen (duur) of wellicht de DSMR-DB op de Pi van de datalogger gaan draaien. |
|
Heb je echt alle velden nodig? Want dan is het efficienter om het per type te groeperen met JSON, vooral die van de meter statistieken en telegrammen. Als je alles hebt aanstaan kom ik uit op een kleine 60 (!) topics. Hoewel het technisch moet kunnen, is het ook een kwestie van balanceren wat in de praktijk werkt. En dat verschilt per set-up. En ik zie bijvoorbeeld dat de gaswaardes leeg zijn, dus die zou ik er dan vooral uithalen. En mocht je bijvoorbeeld geen teruglevering hebben, vooral uitzetten. electricity1 = dsmr/day-consumption/electricity1
electricity2 = dsmr/day-consumption/electricity2
electricity1_returned = dsmr/day-consumption/electricity1_returned
electricity2_returned = dsmr/day-consumption/electricity2_returned
electricity_merged = dsmr/day-consumption/electricity_merged
electricity_returned_merged = dsmr/day-consumption/electricity_returned_merged
electricity1_cost = dsmr/day-consumption/electricity1_cost
electricity2_cost = dsmr/day-consumption/electricity2_cost
electricity_cost_merged = dsmr/day-consumption/electricity_cost_merged
gas = dsmr/day-consumption/gas
gas_cost = dsmr/day-consumption/gas_cost
total_cost = dsmr/day-consumption/total_cost
fixed_cost = dsmr/day-consumption/fixed_cost
energy_supplier_price_electricity_delivered_1 = dsmr/day-consumption/energy_supplier_price_electricity_delivered_1
energy_supplier_price_electricity_delivered_2 = dsmr/day-consumption/energy_supplier_price_electricity_delivered_2
energy_supplier_price_electricity_returned_1 = dsmr/day-consumption/energy_supplier_price_electricity_returned_1
energy_supplier_price_electricity_returned_2 = dsmr/day-consumption/energy_supplier_price_electricity_returned_2
energy_supplier_price_gas = dsmr/day-consumption/energy_supplier_price_gas
read_at = dsmr/consumption/gas/read_at
delivered = dsmr/consumption/gas/delivered
currently_delivered = dsmr/consumption/gas/currently_delivered
dsmr_version = dsmr/meter-stats/dsmr_version
electricity_tariff = dsmr/meter-stats/electricity_tariff
power_failure_count = dsmr/meter-stats/power_failure_count
long_power_failure_count = dsmr/meter-stats/long_power_failure_count
voltage_sag_count_l1 = dsmr/meter-stats/voltage_sag_count_l1
voltage_sag_count_l2 = dsmr/meter-stats/voltage_sag_count_l2
voltage_sag_count_l3 = dsmr/meter-stats/voltage_sag_count_l3
voltage_swell_count_l1 = dsmr/meter-stats/voltage_swell_count_l1
voltage_swell_count_l2 = dsmr/meter-stats/voltage_swell_count_l2
voltage_swell_count_l3 = dsmr/meter-stats/voltage_swell_count_l3
rejected_telegrams = dsmr/meter-stats/rejected_telegrams
read_at_start = dsmr/consumption/quarter-hour-peak-electricity/read_at_start
read_at_end = dsmr/consumption/quarter-hour-peak-electricity/read_at_end
average_delivered = dsmr/consumption/quarter-hour-peak-electricity/average_delivered
id = dsmr/reading/id
timestamp = dsmr/reading/timestamp
electricity_delivered_1 = dsmr/reading/electricity_delivered_1
electricity_returned_1 = dsmr/reading/electricity_returned_1
electricity_delivered_2 = dsmr/reading/electricity_delivered_2
electricity_returned_2 = dsmr/reading/electricity_returned_2
electricity_currently_delivered = dsmr/reading/electricity_currently_delivered
electricity_currently_returned = dsmr/reading/electricity_currently_returned
phase_currently_delivered_l1 = dsmr/reading/phase_currently_delivered_l1
phase_currently_delivered_l2 = dsmr/reading/phase_currently_delivered_l2
phase_currently_delivered_l3 = dsmr/reading/phase_currently_delivered_l3
phase_currently_returned_l1 = dsmr/reading/phase_currently_returned_l1
phase_currently_returned_l2 = dsmr/reading/phase_currently_returned_l2
phase_currently_returned_l3 = dsmr/reading/phase_currently_returned_l3
extra_device_timestamp = dsmr/reading/extra_device_timestamp
extra_device_delivered = dsmr/reading/extra_device_delivered
phase_voltage_l1 = dsmr/reading/phase_voltage_l1
phase_voltage_l2 = dsmr/reading/phase_voltage_l2
phase_voltage_l3 = dsmr/reading/phase_voltage_l3
phase_power_current_l1 = dsmr/reading/phase_power_current_l1
phase_power_current_l2 = dsmr/reading/phase_power_current_l2
phase_power_current_l3 = dsmr/reading/phase_power_current_l3 |
|
Lost de |
|
Ik zie dat het gat na elke Als je nog dieper wilt debuggen, zul je denk ik op de database de query log moeten aanzetten en kijken of je daar trage queries tussen ziet staan. De query log kan invloed hebben op de performance, maar het is toch maar even tijdelijk. In de meeste gevallen is de grootte van de database i.c.m. hardware de bottleneck, maar gezien je 1,3 miljoen metingen hebt staat icm retentie, zijn dat geen schokkende cijfers. |
|
Je kunt trouwens deze instelling ook nog proberen: |
Dit lijkt goed te werken! Met deze timeout enabled heb ik met MeterStatistics getest en de interface bleef snel. Met het enablen van Telegrams kwam de traagheid terug, maar wel in veel mindere mate. Ik vind dit aardig acceptabel, al ga ik wel kijken of ik het nog gefinetuned krijg. Voor zover ik weet heb ik al alles van gas uitstaan, want ik heb een gasloze woning. Ik kom ook geen melding tegen van een tabelgrootte > 500MB. Waar heb je die gezien? Als ik naar de size van de hele postgresql folder kijk die bij de container hoort dan is die hele folder zelfs < 500 MB. We zijn al een heel stuk verder, goede tip! Ik heb nu de genoemde topics (behalve gas) enabled en laat hem even een tijdje draaien. |
|
De melding van de grootte van de database staat in de debug dump: #2043 (comment) |
|
En nog voor de volledigheid de info over die caching. In de toekomstige docs is het iets anders verwoord:
|
Sorry, die had ik gemist. Die melding is nu verdwenen inderdaad. So far so good. Nog geen rode meldingen in de About. Performance is "okay", niet instant, maar niet traag genoeg om echt last van te hebben. Thanks! |
|
Mocht je ooit nog verder willen optimaliseren, dan zou je de DB logs erbij kunnen pakken om te zien of daar iets traag is |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Language / Voertaal
🇳🇱 Nederlandstalig
Help yourself
Inquiry
Report a bug
Description
Hallo,
Ik ben eergisteren begonnen met het spelen met Home Assistant. Ik zag dat er ook een integratie is voor DSMR reader, dus ik ben daar mee gaan spelen.
Ik heb in Home Assistant een MQTT broker geïnstalleerd en deze ingesteld in DSMR Reader. Maar zodra ik deze zaken per de instructies enable, is DSMR reader niet meer vooruit te branden:
Het lijkt allemaal juist geconfigureerd, HA krijgt alles netjes binnen. Maar als ik DSMR Reader wil bekijken duurt het secondenlang voordat pagina's laden en bij 'About' krijg ik ook steeds meer meldingen dat hij e.e.a. niet verwerkt krijgt.
Mijn setup is dat DSMR Reader in een Docker container op een Synology draait als API Server en de P1 poort is aangesloten op een RPi3 met API client. Home Assistant draait op een RPi4.
Ik heb nu de MQTT integratie maar weer uitgezet, maar ik zou dit toch wel graag goed werkend krijgen. Graag hulp :)
DSMR-reader version
5.11
DSMR-reader platform
Docker (e.g. Xirixiz's DSMR-reader Docker)
Optional: Debug info dump (of DSMR-reader)
No response
Optional: Smart meter telegram
No response
Edit: RPi3 voor Api Client, RPi4 voor Home Assistant.
The text was updated successfully, but these errors were encountered: