Gebruikers Home Assistant melden crashes door wintertijd

Gebruikers van Home Assistant melden op Tweakers en Github dat zij last hebben van crashes na de overgang van zomer- naar wintertijd zaterdagnacht. Home Assistant heeft sindsdien een uitzonderlijk hoog cpu- en geheugenverbruik, waardoor het systeem vastloopt.

Gebruikers zeggen op Github dat er verschillende problemen zijn met Home Assistant Core en Blue, onder meer dat het cpu-verbruik tot boven de 100 procent stijgt, en ook het geheugengebruik neemt snel toe. Ook melden gebruikers op Gathering of Tweakers dat het besturingssysteem stopte met het verwerken van berichten, het energiedashboard leeg is en er geen data meer opgeslagen wordt. De problemen zorgen er onder meer voor dat systemen waar Home Assistant op draait vastlopen en crashen. De problemen begonnen rond de overgang van de zomer- naar de wintertijd.

De oplossing lijkt in veel gevallen het systeem opnieuw opstarten. In de meeste gevallen is wel de data weg die verzameld is gedurende de nacht. Gebruikers zien vervolgens alle data geregistreerd op het moment van de reset, waardoor onder meer een verbruikspiek te zien is in het energieverbruik, die er in werkelijkheid niet was.

Volgens hoofdontwikkelaar Franck Nijhof van Home Assistant is het 'jammer dat dit gebeurd is' en had het niet moeten mogen gebeuren. "Op dit moment zijn we nog op zoek naar de oorzaak van het probleem", zegt hij. "We hebben een mogelijke wijzigingsset in onze code geïdentificeerd die dit veroorzaakt zou kunnen hebben, dat onderzoeken we nu. Dit in combinatie met onze testsuite, die om onduidelijke oorzaak deze issue niet eerder heeft opgepakt."

Nijhof raadt gebruikers aan de Home Assistant opnieuw op te starten om het probleem op te lossen. Hij hoopt dat de problemen komende week verholpen zijn, als andere delen van de wereld overstappen op de wintertijd en dat het probleem in de toekomst niet opnieuw optreedt. "We zijn blij dat zoveel mensen proberen bij te dragen aan de oplossing door ervaringen en logs te delen en te helpen met het debuggen van de situatie."

Dat er softwareproblemen ontstaan rond de overgang naar de wintertijd is niets nieuws. Het is jaarlijks een terugkerend probleem, onder meer in databases. In 2018 zat er bijvoorbeeld een bug in de Apple Watch die zorgde voor een crash na het instellen van de zomertijd.

Reacties (153)

Het lijkt er sterk op dat een stuk code verantwoordelijk voor de automations niet helemaal goed kon omgaan met de time change, waardoor diverse automations in erg hoog tempo afgevuurd werden. Dit had dan weer tot gevolg dat de recorder (de verbinding met de database) de backlog aan events niet meer verwerkt kreeg, en uiteindelijk stopte met vastleggen van gegevens (crashed). Beide issues droegen ook bij aan de hoge CPU en memory load, waardoor vooral de minder krachtige systemen ook daadwerkelijk geheel onderuit gingen.

Edit: inmiddels is er een fix gepubliceerd:

We encountered a daylight savings bug last weekend when Europe transitioned last weekend. A restart will resolve the issue. If you are yet to transition to a new summer/winter time, update to 2021.10.7.

https://twitter.com/home_...tatus/1455381542784552961

[Reactie gewijzigd door Hmmbob op 2 november 2021 06:49]

Toch wel een klassieker in dit soort code / software. Zelf ook lang mee gestoeid. Aangezien we in open source geen concurrenten zijn ben ik benieuwd of dat wat de oplossing in pilight was ook bij HA gaat werken:
https://github.com/home-a...83#issuecomment-956194910

Er zijn vast kundige Tweakers hier die op github mee kunnen denken.

pilight had er dus geen last van, voor wie dat naast mezelf nog mocht gebruiken

HA is een vrij actieve open-source community, waarin je bijdrage vast gewaardeerd wordt! Denk vooral mee @ https://github.com/home-assistant/core/issues/58783

edit: ik zie dat je dat al gedaan hebt, tof! https://github.com/home-a...83#issuecomment-956194910

[Reactie gewijzigd door Hmmbob op 1 november 2021 15:05]

Dat zou me verbazen, want ik heb het hele 'automations' deel niet aanstaan in mijn configuratie en het ging toch stuk

Uit nieuwsgierigheid, wat is voor jou dan de use-case van Home Assistant, als je geen automations gebruikt? Puur één plek voor bediening van je hele huis?

Alle automations lopen via NodeRED. Home Assistant is mijn ‘hub’ en een klein beetje frontend. Die gebruiken we nauwelijks, want als je continu je telefoon/tablet nodig hebt om het licht aan te doen automatiseer je niet, in mijn ogen

Dat was precies mijn punt, zonder automations automatiseer je niet
Maar via NodeRED kan ook inderdaad, had ik even niet aan gedacht.

"automation:" wordt geladen door de "default_config:", dus enkel als je die laatste actief uitgezet hebt wordt die code inderdaad niet geladen

En dat heb ik, uiteraard

Het lijkt er sterk op dat ze in de database gebruik hebben gemaakt van de datum en tijd velden die sql biedt. Die missen de tijdzone informatie zodat ze de zomertijd/wintertijd wisseling missen.

Eind vorige eeuw heb ik gewerkt aan een wereld-omspannend monitor systeem waarbij alle log-gegevens in een centrale database werden opgeslagen. Daarbij is toen het gebruik van de sql datum en tijd notatie expliciet verboden. Datum en tijd moest in secondes-sinds-1-jan-1970 en in UTC gedaan worden. Niet geheel toevallig de interne datum/tijd notatie van unix en het ntp-protocol. Omzetten naar een leesbare datum en/of tijd moest altijd in de gebruikersinterface gebeuren.

De achtergrond was dat in het datum en tijd formaat in de database de tijdzone informatie niet wordt meegenomen. Daarmee dus ook niet de 'DST" zoals ze dat in de US noemen: Zomertijd of wintertijd.

Daarnaast heb ik later ondervonden dat als je op een msWindows machine met mssql database de representatie van de datum aanpast van US (mm/dd/yyyy) naar NL (dd-mm-yyyy) dat de interne verwerking en sortering redelijk om zeep gaat. Deze ervaring is uit 2005/2006 en ik heb ze niet meer herhaald. Maar het is goed mogelijk dat dit nog steeds een issue is. Ook leuk met cluster-nodes met verschillende datum/tijd-representaties in 1 cluster.

[aanvulling]; Of was het een over-ijverige programmeur die een unix/linux systeem 'netjes' door de zomertijd-wintertijd wisseling heen wilde laten gaan? Dat hoeft niet, een unix/linux systeem heeft geen weet van zomertijd/wintertijd. Voor een unix/linux systeem is het altijd 'utc', vroeger 'gmt' genoemd, de wintertijd in Londen, UK.

De overige reacties, vooral de beschrijvingen wat er fout ging, doen mij er meer en meer aan denken dat er op het unix/linx systeem de klok blind is teruggezet. Dat is 1 van de zaken waar een unix/linux systeem niet tegen kan. Als de tijd moet worden teruggezet, dan kan ze (veel) langzamer gaan lopen of moet het systeem na de tijd-aanpassing direct worden herstart waarbij de boot met een foutmelding kan/zal gaan komen dat de tijd is teruggezet.

[Reactie gewijzigd door beerse op 1 november 2021 15:07]

Seconden-sinds-1-jan-1970 lijkt me niet zo belangrijk want dat is slechts een formaat (correct me if I'm wrong), het gaat om een eenduidige definitie van datum/tijd waarbij UTC eigenlijk het enige stabiele, universele formaat is om op te slaan, eventueel in combinatie met de gebruikte TZ offset om bij weergave te gebruiken. Op die manier kun je iig de weergave in de originele tijdzone correct reconstrueren.

Voor weergave in meerdere tijdzone's lijkt UTC (of een offset naar een fixed tijdzone) het meest bruikbaar. 1 van mijn oude klanten rekende de tijd van hun wereldwijde operatie om naar CST/CDT. Per slot was het hoofdkantoor het centrum van hun universum.... Overigens gebeurde opslag wel in UTC.

Het ding van Unixtime is dat het geen fluit uit maakt of het winter- of zomertijd is. Die teller loopt rustig door. Die teller is de backend. De 'frontend', het klokje of je kalender bv, die zorgt er vervolgens voor dat die seconden omgezet wordt in iets leesbaars,waar dan rekening gehouden wordt met zomer/wintertijd of tijdzones bv.

Seconden-sinds-1-jan-1970 lijkt me niet zo belangrijk want dat is slechts een formaat (correct me if I'm wrong)

Correctie: het is niet slechts een formaat, maar een gestandaardiseerd formaat (POSIX), waarbij de epoch is vastgesteld op 1 januari 1970, 00:00:00 UTC. Grappige daarbij is dat UTC op 1 januari 1970 nog helemaal niet gedefinieerd was.

waarbij UTC eigenlijk het enige stabiele, universele formaat is om op te slaan

Maar wat sla je dan op? jaar/maand/dag-uren:minuten:seconden UTC? Of dag/maand/jaar-uren:minuten:seconden UTC? Vandaar dat er voor Unix/Linux gestandaardiseerd is op seconden sinds de epoch, waar bij UTC leap-seconds gewoon dezelfde seconde (de leap-second) twee keer geteld word.

[...]Correctie: het is niet slechts een formaat, maar een gestandaardiseerd formaat (POSIX), waarbij de epoch is vastgesteld op 1 januari 1970, 00:00:00 UTC. Grappige daarbij is dat UTC op 1 januari 1970 nog helemaal niet gedefinieerd was.

Groot gelijk, utc is pas later gedefinieerd, toen ze bedachten dat het wel handig was om in de ruimte ook een vaste klok te hebben. Het is wel retro-fit gedefinieerd: globaal in sync met gmt. In detail zouden er wat verschillen kunnen zijn in verband met schrikkel seconden en zo.

[...]
Maar wat sla je dan op? jaar/maand/dag-uren:minuten:seconden UTC? Of dag/maand/jaar-uren:minuten:seconden UTC? Vandaar dat er voor Unix/Linux gestandaardiseerd is op seconden sinds de epoch, waar bij UTC leap-seconds gewoon dezelfde seconde (de leap-second) twee keer geteld word.

UTC is de definitie van het tijdstip. De representatie kan verschillen: seconden sinds 1 januari 1970 (unix, ntp en zo) of seconden sinds 1980 (sommige plaatsen in microsoft systemen). Het gaat er bij het gebruik van utc vooral om dat ze continu vooruit gaat en geen 'last' heeft van locatie veranderingen, zomertijd, wintertijd, politiek en wat dan ook.

Zal nog steeds hetzelfde zijn. Jaar of 5 geleden nog met tijd aan het knutselen geweest. Kwam er op neer dat ik beter phps time() in een kolom kan kwakken, dan dat ik MySQLs tijdsnotering gebruikte. Voor intern gebruik is die sql tijd prima. Maar gebruik je het ook om bepaalde tijdsperiode of timers aan gebruikers weer te geven. Loop je constant tegen grenzen en beperkingen aan.

Inderdaad, mijn instatie waren er heleboel fullbackups gemaakt, via automation.. Die maar 1x had moeten draaien.
Gevolg, disk full en stilstand in docker container.

Even backups opschonen en rebooten was voldoende.

Ik had er ook last van dat het 'Energy' component niet meer werkte. De kWh standen werden niet meer verwerkt totdat ik HA ging restarten. Toen kwam ineens al het verbruik (en opwekking en accu, etc) in 1 uur erbij.

Zou het niet kunnen komen door de Last_reset die aan de kWh entiteiten hangt?

Mogelijk, ik heb geen idee. Ik heb die 'datarecorder' uit staan, dus ik had geen logging meer

Ah vandaar, ik heb nergens last van gehad, enige wat gefaald heeft is Authelia, maar dat heeft weinig van doen met Home Assistant.

Ik maak alle automations voor Home Assistant in Node Red. Vraag me af of er users zijn die ook NR gebruiken met HA en of zij er dan wel last van hebben gehad.

Ook geen verhoogde CPU? Als ik me niet vergis had jij een behoorlijk sterk systeem wat HA draait, kan goed zijn dat hij daarom niet onderuit is gegaan maar dat je wel een verhoogde CPU ziet.

[Reactie gewijzigd door Hmmbob op 2 november 2021 06:55]

Nee had er nog specifiek naar gekeken, maar 1,3% stond ie op. Authelia daarentegen is wel down gegaan, maar een restart had dat ook weer gefixed (goed onthouden trouwens 🤣). Draai inmiddels bijna 70 containers.

Ik verbaas me nog steeds over hoeveel code NIET UTC gebruikt voor alle interne processen.

Alle programmeer talen ondersteunen "locale weergave" vanaf UTC. Wat veel flexibeler is dan locale tijd.

Code/computers moeten ook helemaal niet met zomer/winter/DST (daylight saving time) tijden werken en rekenen. Dat is een representatie van de tijd die wij mensen 'observeren' én die kan nog wel eens naar voren of naar achteren gaan. Wij 'wonen in UTC+1', maar soms 'observeren we de tijd van UTC+2'.

Voor het apparaat en berekeningen werkt het allemaal het best als er met een 'dst'-vrije tijdzone wordt gewerkt. Meestal (iig et de Software waar ik mee werk), is een tijdzone als 'UTC, UTC+1' etc DST vrij. Pas als je iets als 'Europe/Amsterdam' kiest, dán gaat er met DST rekening worden gehouden.

De zg. schrikkelseconde is weer wat anders, die worden wél op UTC en dergelijke toegepast, maar die zou je kunnen zien als, 'de tijd staat een seconde stil' en niet, 'we gaan een seconde terug'.

[Reactie gewijzigd door airell op 1 november 2021 14:00]

Code/computers moeten ook helemaal niet met zomer/winter/DST (daylight saving time) tijden werken en rekenen. Dat is een representatie van de tijd die wij mensen 'observeren' én die kan nog wel eens naar voren of naar achteren gaan. Wij 'wonen in UTC+1', maar soms 'observeren we de tijd van UTC+2'.

Voor het apparaat en berekeningen werkt het allemaal het best als er met een 'dst'-vrije tijdzone wordt gewerkt. Meestal (iig et de Software waar ik mee werk), is een tijdzone als 'UTC, UTC+1' etc DST vrij. Pas als je iets als 'Europe/Amsterdam' kiest, dán gaat er met DST rekening worden gehouden.

De zg. schrikkelseconde is weer wat anders, die worden wél op UTC en dergelijke toegepast, maar die zou je kunnen zien als, 'de tijd staat een seconde stil' en niet, 'we gaan een seconde terug'.

Bijna goed. Wij leven hier in NL, Amsterdam en omstreken, inderdaad in UTC+1. De zomertijd heet UST+1-DST. Daar zijn al jaren aardige libraries voor om daar netjes mee om te gaan. Los van aanpassingen aan de definities (dat is politiek) zijn die libraries al sinds 1990 stabiel, of anders al veel langer.
Het beste kan je die omrekening doen op het moment van representatie. Dan kan je onder water makkelijker rekenen en vergelijken.

Dat van die schrikkelseconde is inderdaad iets anders. Voor de meeste implementaties is die niet echt relevant. Als er een schrikkelseconde plaats vind op de tijd-server, zullen de betere clients daar naar toe 'glijden' door de secondes wat langer of korter te maken. Alleen voor wetenschappelijke doeleinden waarbij tijd synchronisatie tot op de milliseconde relevant is, zijn er speciale afspraken/implementaties voor de schrikkelseconde nodig.

[...]

Bijna goed. Wij leven hier in NL, Amsterdam en omstreken, inderdaad in UTC+1. De zomertijd heet UST+1-DST.

Ik heb nog nooit van UST+1-DST gehoord (Universal Summer Time?!). UST levert ook niet veel op in Google. Kan je het toelichten?

Ik zou ook eerder zeggen dat wij in Nederland in CET leven (CEsT in de zomer als je specifiek wilt zijn, maar CET in de zomer is ook prima, iedereen snapt wat je bedoelt). Iets gemakkelijker dan GMT/UTC+1 in de winter en GMT/UTC+2 in de zomer.

[...]
Ik heb nog nooit van UST+1-DST gehoord (Universal Summer Time?!). UST levert ook niet veel op in Google. Kan je het toelichten?

type foutje, daar had ik 'utc+1-DST' willen aangeven: NL/Amsterdam zomertijd.

Ik zou ook eerder zeggen dat wij in Nederland in CET leven (CEsT in de zomer als je specifiek wilt zijn, maar CET in de zomer is ook prima, iedereen snapt wat je bedoelt). Iets gemakkelijker dan GMT/UTC+1 in de winter en GMT/UTC+2 in de zomer.

Door aan te geven dat CET == UTC+1 geef je aan dat de tijdzone CET een uur verschilt met UTC. Door met DST (of een andere marker) aan te geven dat het om zomertijd gaat weet je ook dat de tijd 2 keer per jaar aangepast gaat worden.
Daarmee: CET == UTC+1, CEsT == UTC +1 DST.
Het gaat er niet om dat je snapt wat er wordt bedoelt, het gaat er om dat alles netjes wordt ingesteld. Computers snappen niets, die moeten worden geprogrammeerd.

Da's leuk, maar als ik vul mijn automatiseringen niet in UTC in. Als ik om 12 uur 's middags op vrijdag een actie wil uitvoeren, ga ik niet de tijdzone reverse engineeren en een tweede automation maken voor de wintertijd, ik wil gewoon dat de software het doet.

De translatie van gewonemensentijd naar een timestamp is uiteindelijk altijd nodig. Helemaal bij dingen als arbitraire, gebruikersinstelbare schema's wordt het snel noodzakelijk om die translatie iedere keer uit te voeren. Als "tijd" gewoon een vast punt is dat wordt opgeslagen, is dit inderdaad simpel te voorkomen. Bij iets als dit waar in essentie cron/systemd-timers zijn nagebouwd in Python, werkt dat niet zo makkelijk.

In die logica kan exact dezelfde fout zitten als in de logica die niet via een UTC timestamp gaat. Iedere implementatie van lokale tijd naar echte tijd is complex, er is helaas geen simpele oplossing voor.

Da's leuk, maar als ik vul mijn automatiseringen niet in UTC in. Als ik om 12 uur 's middags op vrijdag een actie wil uitvoeren, ga ik niet de tijdzone reverse engineeren en een tweede automation maken voor de wintertijd, ik wil gewoon dat de software het doet.

Wat @airell terecht op doelt is dat de opslag van de tijd te allen tijde in UTC dient te zijn. De in- en uitvoer voor de gebruiker kan dan wel in zijn of haar lokale tijdzone weergegeven te worden. Het zou dus geen probleem zijn voor jou als gebruiker om een tijd in de Amsterdam tijdzone in te voeren, zolang deze maar als UTC wordt opgeslagen.

Oke, dus ik heb nu een zwik meterstanden in UTC+1 of welk universeel formaat je dan ook maar wenst.

Hoe toon ik dat nu in een grafiekje? En dan specifiek de periode tussen 2 en 3 uur in de nacht, als we overgaan van tijdzone? We hebben in 1 nacht immers 2x de tijd tussen 2 en 3 uur gehad.

Lijkt mij wel nog steeds een lastige uitdaging.

Met terugrekenen van non-DST naar DST kom je alsnog uit op 2x 2 uur, dus verbruik bij elkaar optellen en heb je dubbel verbruik (1e 2-3 uur verbruik en daarna nog een keer 2-3 uur verbruik). Je grafiek zal dan ook een piek hebben, of lig hoger dan je verwacht.

Als de zomer tijd in gaat wordt er een uur overgeslagen, dan zal je een uur '0' verbruik hebben dus een dip in je grafiek.

Mijn punt is meer dat ondanks dat je al je data in een universele data hebt staan je alsnog wel tegen praktische problemen aan zult lopen in de implementatie bij het werken met tijdzones.

Bij jou grafiekje zal langs de tijd as de tijd staan zoals die geld. Daar bij zal voor de nacht waarin de tijd van 03:00-dst naar 02:00 terug gaat de tijd notatie dat aangeven als ze daarbij 'dst' respecteert. Anders zal langs de tijd as de tijden tussen 02:00 en 03:00 gewoon 2 keer voorkomen.

Ook is het goed mogelijk dat jou grafiekje begint op een bepaald tijdstip en gewoon de uren doornummert en aan het einde gewoon het verkeerde uur aangeven.

Eet het en je weet het. Het is maar net hoe 'netjes' de programmeur het heeft opgezet. Het zou mij zomaar kunnen overkomen dat de nummering gewoon doorloopt. Als ik er tijdig aan denk, zal de tijd een markering mee krijgen dat het om zomertijd of wintertijd gaat.

Reden zoveel om zomeruur af te schaffen, maar het is geen prioriteit voor de EU. Ondanks dat dit voor elk (software) bedrijf voor de nodige uitdagingen zorgt.

Los van software, het is gewoon niet nuttig meer om het te doen. En het zorgt voor veel mensen voor slaapproblemen, ongelukken op de weg. Gewoon afschaffen.

En doe dan maar altijd zomertijd, dan is het altijd lekker weer

Echt gek hoe mensen zich dat zo inbeelden he.

“Ja maar, dan is het langer licht”

Euh, nee. Het is later licht.
De oriëntatie van de aarde tov de zon tijdens de zomer zelf zorgt dan voor langere dagen.

Maar net als tijdzones is dat moeilijk te vatten of in hoofd nee te rekenen.

Winteruur graag, wat mij (o.a.) voor de veiligheid op de weg smorgens. Specifieke sectoren kunnen dan nog een ‘zomerregime’ invoeren desgewenst.

Sochtends zijn we gewoon minder productief, dus wat is dan het nut van sochtends eerder licht?

Je kan beter savonds langer licht houden want dan zit je niet om 4 uur smiddags al in het donker.

Ook wel zo fijn voor mensen die bv. tot 5 uur buiten werken.

Het zou kunnen, maar dan moet je er wel rekening mee houden dat het in de winter pas tegen kwart voor 10 licht is. Iets waar bijvoorbeeld de bouwwereld weer last van heeft.

In de bouw kunnen ze ook leren tot 17:00 door te werken ipv 16:00 zoals nog steeds de norm lijkt te zijn.

Precies, en dan niet van 7.00u tot 7.30u naast je huis gaan heien en dan van 7.30u tot 8.30u koffie gaan drinken. Scheelt als eenvoudige burger toch weer een uurtje slaap als ze pas om 8.00u een half uurtje gaan heien...

Aha, je kent het probleem!
Klopt helemaal, doen ze hier ook om 07:00 dichtbij een bouwterrein bouwklaar maken met graafmachines en daarna de grond gaan aantrillen zodat je hele huis mee trilt.

We zitten hier in NL sowieso altijd al op +45 minuten tov de zon, door de indeling van de tijdszone. Oftewel, de wintertijd is al bijna zomertijd, de zomertijd is dubbelop.

Hier in NL is qua zonnetijd een breed begrip: Tussen de oost en de west grens van Nederland zit zo'n 10 minuten. De weerman van omroep West (Den Haag) vertelde vanmorgen dat de zon hier in Den Haag ongeveer om 12:40 op haar hoogste punt staat. Dat zal aan de NL-oostgrens ongeveer 12:30 zijn.

Volgens mij is de 'ideale' grens van de tijdzone ongeveer op de westelijke grens van Duitsland, dus de grens NL-DE, BE-DE, LUX-DE, FR-DE, FR-CH en FR-IT. Dat loopt aardig noord-zuid en is qua zonnetijd ongeveer een half uur voor op Londen, aka GMT. Zie ook de kaart op https://nl.wikipedia.org/wiki/Tijdzone

Volgens mij is het aan de Duitsers in de tweede wereldoorlog dat wij qua tijd aan Duitsland gekoppeld zijn. Maar het kan ook door de (internationale) spoorwegen komen. Die hadden een grote hand in het vast zetten van de tijd-zone en dergelijke in West Europa. Zie ook https://www.ensie.nl/vandale1898/spoortijd en https://nueens.nl/nationale-spoortijd

Uiteraard veranderd het niet hoeveel daglicht er uiteindelijk is in Nederland. Het is wel zo dat met normale ritme van de gemiddelde Nederlander, je met zomertijd meer daglicht hebt terwijl je wakker bent dan met wintertijd.

En ja, wintertijd zorgt voor meer veiligheid op de weg 's ochtends. Zomertijd voor meer veiligheid 's avonds. Dat is natuurlijk beetje lood om oud ijzer. (Sterker nog, uit mijn hoofd is de avondspits gevaarlijker dan de ochtendspits).

(Sterker nog, uit mijn hoofd is de avondspits gevaarlijker dan de ochtendspits).

Schijnbaar hebben mensen minder haast om op het werk te komen, meer geduld en aandacht in de ochtend, als na een dag werken en haast om op tijd thuis te zijn voor het eten.

's ochtends heb je ook viel scholieren op de fiets, welke je vaak tegen de avond niet meer hebt (of in elk geval een stuk minder). Mindere gevaarzetting zorgt ervoor dat mensen dan toch weer harder gaan rijden, want men voelt zich veiliger...

Dit. ^ Bovendien is het met wintertijd in de zomer ook niet om 18:00 donker, dus het is niet alsof je nooit meer een lichte zomeravond hebt.

Eigenlijk komt onze tijdszone beter overeen met die van Engeland (UTC+0), maar wegens praktische redenen volgen we die van Duitsland (UTC+1), maar als het zomer is dan volgen we die van Oekraïne (UTC+2), daarom dat de zon op de middag nooit op zijn hoogste punt staat en in de zomer zelfs pas rond 2 uur.

Ter illustratie: https://upload.wikimedia..../World_Time_Zones_Map.png

[Reactie gewijzigd door IStealYourGun op 1 november 2021 14:30]

Waarom dan niet gewoon UTC+0:30? :-)

Een behoorlijk aantal landen doet ook zoiets:
https://en.wikipedia.org/...:World_Time_Zones_Map.png

Zomertijd is dan weer niet goed voor de globale warming

Juist wel! In plaats van om 21:30 uur, gaat de verlichting pas om 22:30 uur aan. Door de zomertijd doet iedereen het licht een uurtje later aan.

Behalve boeren en bakkers welke voor de dageraad opstaan, zullen er weinig mensen erop zitten te wachten dat het 's nachts al om 03:40 uur licht begint te worden. Zonlicht betekende altijd dat het feest bijna ten einde is en we strakjes weer op zoek moeten naar de party travel bussen welke nooit op numerieke volgorde waren geparkeerd ;-(

In de winter is het uurtje eerder licht (einde zomertijd) weer belangrijk ivm met fietsende scholieren. Je wilt niet dat het dan pas op 09:30 uur licht is, maar al om 08:30 uur...

De meeste mensen hebben niet zoveel problemen met de wintertijd (omdat je een uurtje langer kunt slapen), maar wel met de zomertijd vanwege het uurtje korter slapen. Dat verstoort het bioritme veel meer...

Gelukkig maar dat het geen prioriteit heeft, je gaat een soort mini Y2K scenario creëren. De hoeveelheid plekken waar datum/tijd wordt verwerkt zijn echt ontelbaar. Als je dat allemaal moet gaan aanpassen en gaan testen ben je echt miljarden kwijt en jaren verder.

Dat is kwestie van uitschakelen, er zijn genoeg landen die géén zomertijd gebruiken. Meer nog, er zijn meer landen die geen zomertijd gebruiken en er zijn voor het gemak 15 verschillende momenten dat, afhankelijk van de regio, de tijd met een uur, of een half uur kan veranderen. En voor de fun durven sommige landen (USA in 2005) dat momenten nog eens te veranderen. Dus software kan in dat geval:

• gebruik maken van een centrale (online) database die dat moment bijhoudt en dan is het kwestie van die aan te passen
• gewoon overweg met veranderende uren (bv: maakt gebruik van Unix time en past enkel de notatie aan)
• er niet mee overweg of heeft het hardcoded staan, wat dus een slechte oplossing is

Helaas komt dat laatste optie wel vaker voor dan je zou willen en dat heeft een enorme impact op industrieën waarbij bedrijven hun systemen tijdens de overgang soms uitschakelen.

Zelfs Apple, Google en Microsoft hebben al te maken gehad met DST Bugs

Ik snap de ophef niet zo: dit hebben we toch al jaren elke herfst? Hoe ging het dan vorig jaar?

Bijkbaar zijn er softwareontwikkelaars, die nog steeds niet doorhebben dat dit elk jaar gebeurt.
Op mijn werk draaien de applicaties die in GMT/UTC werken, gewoon door, de applicaties die in Local Time draaien, leggen we een uur stil. Dan heb je een normaal doorlopende activiteit van 01:00-02:00-03:00 en geen transacties die bijv. bijna een uur eerder stoppen dan ze gestart zijn.
Dit doen we al jaaaaaren zo, nix nieuws.

tja er zijn ook gewoon landen die geen wintertijd of daylights savings kennen.... Wellicht kwam een van de programmeurs daar vandaan.

En als je denkt dat het een kwestie van geld is. Zoek dan even Apple's geschiedenis op met tijd problemen. Die kregen het voor elkaar om meerdere jaren achter elkaar oud en nieuw te verprutsen in hun wekker app.

En toch...
Wij zijn afgelopen maand bezig geweest met testen ivm de overgang. Net zoals bij de overgang naar de zomertijd. En dat hebben we vorig jaar ook gedaan en het jaar daarvoor ook.
Je zou denken dat al die bugs en foutjes eruit zijn. Maar nog steeds krijgen we niet alle verwachtte data binnen van onze externe partij en zijn er fixes of work-arounds nodig of "known problems".

En wij hebben niet de luxe om ons systeem een uur stil te leggen. (dat geeft toch ook aan dat die systemen niet goed ermee om kunnen gaan?)
Dus er zijn nog genoeg ontwikkelaars die extra scholing nodig hebben.

Als software intern gewoon altijd met UTC werkt is er ook geen probleem. In de lokale tijdszone iets weergeven kan altijd nog.

Hmm. Is dit serieus? Nog even en je gaat decimalen verbieden want floating point berekeningen zijn onnauwkeurig op een computer.

Ja stel je voor dat programmeurs fouten maken of wat over 't hoofd zien. Moet niet gekker worden.

Dat programmeurs fouten maken die niet altijd worden afgevangen door QA, test suites en dergelijke is vervelend, maar volkomen te begrijpen. Dat is echter niet een "reden om zomertijd af te schaffen". Die uitspraak is van de zotten.

Vind ik ook hoor, was puur op @icecreamfarmer's formulering gericht.

Klopt. Er zijn prima biologische redenen om zomertijd af te schaffen en onze tijdzones opnieuw in te delen op basis van wanneer de zon écht opkomt.
Er is veel onderzoek naar gedaan, maar de politieke wil is er niet.

Niet alleen de politieke wil is er niet. De wil bij de bevolking is er ook niet. En al helemaal niet als je de zonsopkomst tijd gaat gebruiken. Dan veranderen dus je tijden door het hele jaar door. En dan denk je dat een uurtje zomertijd naar wintertijd omslaan al problematisch is voor software .

Het gaat er altijd om dat mensen op het omschakelmoment even van slag zijn. Als we geen klok zouden hebben zou het bioritme van de mens zich ook aanpassen aan het daglicht. In de zomer zouden we vroeger opstaan en in de winter later. In de zomer blijf je geen vier uur in bed liggen als het buiten al klaarlichte dag is en in de winter zou je niet actief worden als het nog uren donker is. Wintertijd in de zomer gaat juist tegen de biologische klok in.
Met wintertijd in de zomer komen ook de dieren in de problemen. Die komen in de avondschemering uit hun holen. In de zomer is er dan een stuk minder menselijke activiteit als de schemering een uur later valt. In de nacht zoeken dan de dieren om. 3:00 uur hun hol weer op omdat het dan licht wordt terwijl de menselijke activiteit nog uren uitblijft. Voor de dieren is het wel goed om het te verschuiven. Ook voor de veiligheid van vrouwen en kinderen is het ook beter om de schemering later in te laten vallen als er in de zomer buitenactiviteiten plaatsvinden.

Inderdaad, wat voor een softwarebedrijf ben je dan nog:
https://9to5mac.com/2021/...s-to-show-the-wrong-time/
https://9to5google.com/20...xel-daylight-saving-time/
https://support.microsoft...b1-7e96-9cf2-268dd12ba464

Niet alleen voor een software bedrijf.
Toen ik nog werkte, had ik toch een weekje bioritme aanpassingstijd nodig om terug helemaal op volle productiviteit te komen.
Nu ik op pensioen ben maakt het me eigenlijk niet zo uit, ik sta op en ga slapen wanneer ik er zin in heb, al is er toch wel een voorkeur voor het zomeruur, het blijft dan lekker laat licht, en ik ben nu eenmaal geen ochtendmens.

Met wintertijd in de zomer is je slaapkamer om 3:00 uur in de nacht volledig verlicht. Dan is je bioritme enkele maanden van slag. Als we geen klok zouden hebben zou je bioritme zich ook aanpassen aan de verschuiving van het daglicht. Dat is precies wat we met de zomertijd ook doen.

Het is ook lastig om bij te werken in je statistieken. Een uur die in dezelfde nacht 2 keer voor komt. Ga je de oude waarden dan overschrijven of ga je ze bij elkaar optellen? Mijn Domoticz installatie geeft ook hele rare waarden tussen 2:00 en 3:00 voor het geregistreerde energieverbruik. Hij crasht gelukkig niet.

[Reactie gewijzigd door 3raser op 1 november 2021 13:41]

Bij elkaar optellen en het gemiddelde gebruiken. Dat is over dat uur dan een iets hoger verbruik. Omdat het nacht is zal het wel meevallen.

Met de wissel naar zomertijd moet een ander trucje worden bedacht. Dan 'ontbreekt' er een uur. Je zou het verbruik van 0200-0300 kunnen uitstrijken over 0200-0400 uur. Dan is het per uur weer wat lager dan gemiddeld en compenseer je het 'extra' verbruik bij de wissel naar wintertijd.

[Reactie gewijzigd door Titan_Fox op 1 november 2021 14:52]

Je zou hem ook in UTC kunnen zetten. Dan heb je het hele probleem niet

Hetzelfde zag ik inderdaad ook (P1 poort uitlezen in Domoticz), ik schrok al heel even dat ik daadwerkelijk 400 kW verbruikt leek te hebben in dat uurtje. Bij mij kwam dat uur alleen wel 2x voor (in de Domoticz lite app).

[Reactie gewijzigd door Gosse_W op 2 november 2021 12:50]

Gebruikers zeggen op Github dat er verschillende problemen zijn met Home Assistant Core en Blue, onder meer dat het cpu-verbruik tot boven de 100 procent stijgt

Dat is knap, maar wel mogelijk:

n UK 2021/10/31, at 01:59:59, time got back to 01:00:00 (summer to winter, Daylight saving), since then (it's 01:08) home-assistant has a high CPU usage, using a core at 100%.

CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
42985e0497d4 hass 104.53% 251.7MiB / 7.658GiB 3.21% 0B / 0B 103MB / 1.77MB 15

[Reactie gewijzigd door metalmania_666 op 1 november 2021 13:03]

Een CPU gebruik van (iets) meer dan 100% betekent meestal toch gewoon dat er één core volledig wordt gebruikt, en daarnaast nog iets van een tweede core wordt gebruikt?

Het volledige gebruik lijtk in deze context "gewoon" een proces dat hangt.

Dat zou kunnen, maar dan nog hoort dat proces niet te hangen.

Dat is precies waar ik naar refereerde inderdaad.

Vond dit duidelijker

Ik ben benieuwd naar de oorzaak, zelf gelukkig geen last van gehad in home assistant in een dockercontainer.

Mijn docker kon een herstart gebruiken anders grafieken met flat line 🙈

Nu je het zegt inderdaad, ik had vooral het cpu-gebruik in t nieuws gezien, en dat lijkt geen ding te zijn bij mij (draait op pc met fan maar die is niet aangegaan, gaat aan bij ~20%+ cpu). Restart fixt de logging lijkt t .

Niet? Als ik op mijn host (NUC met Ubuntu) een top-command invoer stond er toch 100% CPU gebruik bij python3. Ik draai HA Core via docker.

Hier ook HA Core in een docker container (op een NUC met Ubuntu server). Ik merkte zondag dat er 's nachts ineens geen data meer was weggeschreven.

Ik heb niet naar het CPU verbruik gekeken, en ik heb het nooit gelinkt aan het ingaan van de wintertijd. Ik heb min of meer blind HA opnieuw gestart en toen was het weer OK.

Weer een reden er bij om zomertijd af te schaffen 😇
Verklaart wel de flatline in mijn PM2.5 grafiek die ik gister zag ontstaan. Even restarten dus

Wat gebruik je om pm2.5 te meten?

https://www.ikea.com/nl/n...kwaliteitsensor-70498242/

Deze kun je makkelijk modificeren door een ESP toe te voegen. Daar is hier een mooie guide voor:
https://style.oversubstan...e-assistant-with-esphome/

Dank je wel, ziet er interessant uit!

Die sensor met een wemos d1 mini dus.
€15, 15 minuten knutselen.

Alleen heb ik nog een issue met Esphome over mqtt en meerdere sensors 🙈

Die sensor met een wemos d1 mini dus.
€15, 15 minuten knutselen.

Ja inderdaad. Leuk klein projectje, werkt perfect.

Alleen heb ik nog een issue met Esphome over mqtt en meerdere sensors 🙈

Voor ESPHome heb je geen MQTT nodig. ESPHome kan rechtstreeks de HA API gebruiken. Dat werkt ook een stuk beter dan met MQTT

Nadeel van HA is de database. Als ik het mqtt op die kan ik het via Telegraf zo influxdb in mikken en met grafana dashboards maken.

Als ik het HA in Postgres’s laat opslaan kan ik er niets meer mee, dus als het half kan doe ik voor historische data altijd mqtt. 😉

Bijkomend voordeel: 1 integratie met devices en integrations. Niet per api een integratie 😇

[Reactie gewijzigd door pOZORjED op 1 november 2021 15:38]

Als ik het HA in Postgres’s laat opslaan kan ik er niets meer mee, dus als het half kan doe ik voor historische data altijd mqtt. 😉

Dat eeste snap ik niet. Ik gebruik zelf influxDB met grafana naast HA en dat werkt perfect samen. Mijn ESPHome sensor data kan ik zo ook visualiseren.

Bijkomend voordeel: 1 integratie met devices en integrations. Niet per api een integratie 😇

En 1 nadeel, je hebt een single point of failure. Is je broker plat dan is alles plat. Bij ESPHome is ieder device een eigen server dus gaat er iets plat dan is er geen enkel probleem. Integratie en discovery gaan volledig automatisch, pas je je device aan dan weet HA dat ook meteen. Geen YAML of topics meer om aan te passen, gaat allemaal vanzelf. Voeg je een device toe dan krijg je meteen een melding etc.

Lees ook eens hier: https://esphome.io/components/api.html#advantages-over-mqtt

[Reactie gewijzigd door StefanSL op 1 november 2021 16:12]

De mqtt doet dezelfde discovery, zelfs zonder eenmalig in te stellen. En mqtt, die is hier nog nooit (onbedoeld) plat gegaan. (Zou ook redundant kunnen) en dat euvel heb je ook als HA plat gaat…

Oke, maar alsnog word het wel sterk aangeraden om over te stappen op HA API. MQTT heb je gewoon niet meer nodig

Toch altijd weer een gedoe hè. Hier draait zigbee2mqtt met een custom nodejs controller en die is afgelopen weekend ook stevig over zijn nek gegaan. Ben toch wel enkele uren bezig geweest voordat de boel weer aan de praat kwam.

Ik heb "pas" 35 Zigbee devices maar die draaien op m'n Pi4 onder HassOS binnen Phoscon/Deconz. Heerlijk. Niks meer aan veranderen, werkt altijd. Echt een verademing toen ik die IKEA Tradfri hub eruit gehaald had..

Inderdaad deed [docker restart homeassistant] 'the trick'

Ik zie bij mij dat een aantal uren niet goed electriciteit gemeten is en dat ik na een piek (om pakweg 6u 's ochtends) weer een normaal verbruik heb. Verder heb ik niets gemerkt van de "downtime" aangezien ik een weekendje weg was en wat een reset dus niet nodig: geduld is blijkbaar een tweede trick (indien ie niet volledig vastgelopen is).

Hier stopte Home Assistant met het loggen van events naar de database. Een restart van de core loste dat op. Verder geen problemen ervaren.