Good practices voor loggen van domotica?

[Gwaihir]

Bezig met inrichting van een stuk domotica in huis, met name de verwarmingsinstallatie moet er momenteel aan geloven. Om deze te optimaliseren (mede op verschillende weersomstandigheden door het jaar heen), wil ik uitgebreid loggen. Het systeem (Loxone) kan dat, het gooit zoveel UDP berichtjes naar m'n NAS als ik maar wil. Daar wil ik de logfiles bewaren, om ze op verschillende manieren nader te verwerken. Die analyse inrichten komt dus nog en zal vast nog wel een aantal iteraties doormaken (daarom bewaar ik dus de ruwe logfiles).

Om te logging zelf in te richten mag ik dus allerlei namen verzinnen voor te loggen dingen en eventuele toelichtende teksten. En dan vraag ik mij af: zitten daar nog mogelijke (on)handigheden in? Iets wat ik juist wel / niet in de naamgeving wil verwerken. Iets wat ik juist wel / niet wil loggen?

(Google levert me resultaten over tools en hoe logging aan te zetten in X, maar eigenlijk niets over hoe er vervolgens mee om te gaan..)

[Gwaihir]

't is wat stil hier..

Ik zal 't niet blijven doen, beloofd. Toch eenmalig ff proberen of er deze week meer input te vinden is..

[Gomez12]

Tja, wat is het doel van je logging?

Daar hangt het voornamelijk vanaf...

Wil je het gebruiken voor troubleshooting van je devices dan is aanpak a makkelijk.
Wil je het echter gebruiken voor het tonen van metrics getrokken uit je logs dan is aanpak b makkelijker (waarbij simpelweg metrics / time-series uitspugen nog makkelijker is)

Definieer eerst gewoon eens het doel van je logging.

[Gwaihir]

Beide. Zeker ook troubleshooting, maar uiteindelijk vooral metrics voor steeds verdergaande optimalisaties.

Bijvoorbeeld (a): ik ontdekte dat de vloerverwarming soms een véél te hoge aanvoertemperatuur had. Daarop heb ik de mengklep opnieuw geïnstalleerd (de hardware), omdat deze kennelijk niet helemaal de juiste 90 graden draaide. Nu wil ik zeker op 'rare' waarden monitoren. Waarschijnlijk maak ik hierop in Loxone een waarschuwingsmelding. Om vervolgens te troubleshooten wat er aan de hand zou kunnen zijn heb ik omliggende meetwaarden van dat (dan al voorbije) moment nodig.

Bijvoorbeeld (b): om het verbruik te minimaliseren (bij goed comfort) wil ik kunnen analyseren wat verschillende nachtverlagingen en stooklijnen voor resultaten geven. Aangezien dit weersafhankelijk zal zijn, heb ik hier een ruime, over langere tijd verzamelde set meetwaarden voor nodig. Dat wordt vervolgens doorkruist door andere aanpassingen aan bijv. de ventilatie, isolatie, en kierdichtheid van de woning.

Al met al verwacht ik nog al eens terug te willen grijpen naar (historische) data op een manier die ik nu op voorhand nog niet voorzie. Daarom wil ik 'kale feiten' loggen op een stabiele manier in de tijd. Alle kale feiten - zo'n mooie gebruikersbehoefte die nog praktisch gemaakt moet worden. Elke sensor elke seconde?

[Tsurany]

Lijkt mij een typische usecase voor InfluxDB met bijvoorbeeld Grafana.

Dan een lijst maken van alle sensoren en welke waarden er uit komen. Die kan je dan grouperen in measurements met wat metadata.

[Gwaihir]

Klopt, maar hoe die logs te verwerken is niet mijn vraag. Zijn er nog dingen om rekening te houden bij het loggen zelf?

[ThinkPad]

Wat bedoel/zoek je precies? Wellicht iets concreter zijn? Men reageert op je vragen, maar je geeft aan dat dat niet je vraag is. Wat is dan wél je vraag ?

Ik log hier de CV-installatie ook (temperatuursensor op aanvoer- en retourleiding), om hem zo efficiënt mogelijk te kunnen afstellen. ESP8266 leest de sensoren uit, ik haal elke minuut de waarden op via Node-RED, deze schrijft het weg in InfluxDB en met Grafana maak ik er grafieken van.

Redelijk eenvoudig op te zetten als je wat feeling voor IT hebt.

Elke seconde alles loggen lijkt mij overdreven, zo snel veranderen waardes in het systeem toch niet.

[Gwaihir]

Eén van mijn vragen is dus hoe vaak log je wat (en waarom)? ("Alles elke seconde" had zeer bewust een cursief en een .)

Een andere vraag is: zijn er nog bepaalde (naming) conventies aan of af te raden, scheidingstekens waar je super blij van wordt of juist niet, etc.

En misschien maak ik mij druk om (bijna) niets en is waar ik naar zoek daarom zo lastig voor anderen te (be)grijpen. Dat is op zich ook een prima antwoord; wordt ik ook wijzer van.


Per minuut is op dit moment de frequentie waar ik voor de meeste zaken aan denk. Maar rondom dat gekke probleem met die menger zou dat bijv. niet fijnmazig genoeg zijn. Sensor en regelaar draaien daar op een 10s cycle. Dus ik vraag me af of ik die straffeloos ook voor logging aan kan houden. UDP is een fire & forget maar maakt dat 't all-round 'spotgoedkoop', of loop je toch vrij snel tegen grenzen? Totale ordegrootte lijkt nu pakweg 40 logregels per minuut, op individuele freqenties van per 10s tot per (wellicht) 10 minuten. (Van zo'n regelklep die ik nog niet helemaal vertrouw tot weersinfo als zonintensiteit, windsnelheid, regenval.)

[ Voor 3% gewijzigd door Gwaihir op 19-03-2020 15:42 ]

[Tsurany]

Gwaihir schreef op donderdag 19 maart 2020 @ 15:13:
Klopt, maar hoe die logs te verwerken is niet mijn vraag. Zijn er nog dingen om rekening te houden bij het loggen zelf?

Dat is zeer afhankelijk van de methode die je gebruikt om te loggen. Ik vind zelf InfluxDB met Grafana heel fijn en dan moet je dus begrijpen hoe InfluxDB werkt en hoe je een vertaling maakt van data naar measurements.

Zo heb ik een measurement "energy" waar ik current, volt en power als fields heb gedefinieerd. Vervolgens heb ik tags gedefinieerd waar mijn metadata in staat zoals direction, device en orientation. Hierdoor heb ik een enkele measurement waar ik alles in kwijt kan wat met energie verbruik of opwekking te maken heeft.

Daarnaast heb ik nog een measurement voor energy consumption waar om de zoveel seconden de actuele meterstanden van diverse apparaten opgeslagen wordt.

Datzelfde kan je doen voor temperatuur. De vraag is dan of je elk type temperatuur in dezelfde measurement kwijt wilt of dat je water en lucht gescheiden wilt. Dan heb je een aparte measurement voor water hebt waarbij je ook druk bijhoud en een aparte measurement voor lucht waarbij je ook de luchtvochtigheid netjes opslaat.

Gwaihir schreef op donderdag 19 maart 2020 @ 15:41:
Een andere vraag is: zijn er nog bepaalde (naming) conventies aan of af te raden, scheidingstekens waar je super blij van wordt of juist niet, etc.

Dat is volledig afhankelijk van je logging methode. Ik vind log to file verschrikkelijk, dan veel liever een database als InfluxDB wat juist voor dit soort doeleinden ontwikkeld is.

Per minuut is op dit moment de frequentie waar ik voor de meeste zaken aan denk. Maar rondom dat gekke probleem met die menger zou dat bijv. niet fijnmazig genoeg zijn. Sensor en regelaar draaien daar op een 10s cycle. Dus ik vraag me af of ik die straffeloos ook voor logging aan kan houden. UDP is een fire & forget maar maakt dat 't all-round 'spotgoedkoop', of loop je toch vrij snel tegen grenzen? Totale ordegrootte lijkt nu pakweg 40 logregels per minuut, op individuele freqenties van per 10s tot per (wellicht) 10 minuten. (Van zo'n regelklep die ik nog niet helemaal vertrouw tot weersinfo als zonintensiteit, windsnelheid, regenval.)

De vraag is wat je wilt loggen en wat je echt nodig hebt. Ik log mijn stroomverbruik elke 10 seconden zodat ik pieken op kan vangen en omdat opslag praktisch gratis is tegenwoordig. Echter log ik ook temperatuur, dat elke 10 seconden loggen heeft echt geen zin in de meeste gevallen dus daar houd ik elke vijf minuten voor aan.

Daarnaast heb je in InfluxDB te mogelijkheid tot retentiebeleid en downsampling. Zo kan je aangeven dat data die je elke 10 seconden verzamelt hooguit een uur, dag, week of maand bewaar wordt. Daarnaast draai je een aparte query waarbij je elke 30 minuten een gemiddelde neemt van de afgelopen minuten en die opslaat in een downsampled measurement.

Je logt dus zo vaak als nodig en neemt achteraf maatregelen om data geautomatiseerd op te schonen waar nodig.

[Gwaihir]

Hmm.. dat is verrekte interessant én geeft me mogelijk diverse uitdagingen:

• Ik geloof niet dat ik waarden van verschillende sensoren in één logmelding kan uitsturen. Of stel je zo'n measurement net zo makkelijk samen uit meerdere regels?
• Mijn NAS neemt UDP berichten in ontvangst, maar schrijft ze dan naar file. Deze NAS is niet sterk genoeg voor (een) Docker container(s) met o.a. InfluxDB. Dat wil ik dus eerst maar 'ns op m'n desktop PC zetten, die niet altijd aan staat. Gaat dan dus elke keer (stukken van) de logfile inlezen.
• Hoewel de time-series van InfluxDB hiervoor geknipt lijken, lees ook over diverse beperkingen in (de analysecapaciteiten via) InfluxDB + Grafana waardoor er mogelijk nog ElasticSearch bij moet óf het toch op de ELK-stack moet gebeuren. Dat geeft mij een sterke voorkeur files aan te leggen als bron, daar eigenlijk elke verdere oplossing die wel in kan lezen. Of lijkt dat alleen zo?

[jobr]

Bij influxdb is de opzet van de tags,measurements en fields erg van belang voor hoe gemakkelijk je er iets kan uittrekken. Ondanks dat je queries kan gebruiken werkt het echt heel anders dan bijv mysql.
Als je het wil gebruiken dan zou ik eerste wat testdata erin stoppen en proberen datgene eruit te halen wat je wilt. Vooral iets met minimale verschillende timestamps.
Ook het er in delen instoppen of alles in 1 melding heeft zijn consequenties.
Voorbeeld wat niet kan is bijv een totaal van een kalendermaand.Wel van een week of 4 weken.

Je zou eerst kunnen loggen naar files en dan eens daar mee experimenteren wat je het beste bevalt.

[Gwaihir]

Dat is inderdaad mijn gedachte: logs als files bewaren zodat ik als iets me niet bevalt een andere indeling kan maken van die dingen, en de logs opnieuw laat inlezen in die nieuwe indeling.

Niet in de laatste plaats omdat ik niet op voorhand (alles) weet wat ik wil. Vroeg of laat ga ik mij (nieuwe / andere) zaken afvragen en dan hoop ik dat ik stiekem de (ruwe) historische data voor de betreffende analyse al heb, i.p.v. dat ik die eerst enkele weken zal moeten verzamelen.