Jag får återkommande spikar som jag undrar hur jag kan felsöka. En dator ligger och loggar EventSource data med förhoppningen att jag ska kunna rapportera lite mer exakt vad som händer.
Du tycks ha prickat en bugg i systemet.
Orsaken är att du kör i BLINK-mode, och då börjar Currently One rapportera förbrukad energi (Wh) från 0 efter boot, vilket ger många specialfall att hantera på servern.
Kl 16:00 stod räknaren på 50316 Wh.
Successivt räknade den upp till 51259 Wh kl 16:23, då den startade om.
Kl 17:00 hade den hunnit upp till 1476 Wh när timman 16-17 stängdes.
Det borde betyda (51259-50316) + 1476 = 2419 Wh, men jag noterar att det blev 53619 Wh vilket är uppenbart felaktigt.
Buggrapport skapad!
Hälsningar
Ola på Currently
1 Like
Nu på version 2.3.1 av firmware men problemet med spikar kvarstår. Jag får en ny elmätare inom närtid men tills dess kan jag bidra med mer info om det behövs
1 Like
Hej Björn, är det t.ex. 2024-01-01 kl 17-18 som är senaste spiken? Kan jag använda den i felsökningen?
Har du nån spik som inträffade mer nyligen? Realtidsdatan lagras i en vecka, så 1 januari kan jag inte längre se.
Hälsningar
Ola på Currently
Utöver den du nämnde hade jag även en 48.84 kWh 24-01-03 12-13 men sen har det varit lugnt.
Oklart för mej vad du frågar om “kan jag använda den i felsökningen” men min förbrukning ser jag inte som känslig om det är det du menar.
1 Like
FWIW, två nya spikar:
- 20240131 17-18 20.46 kWh (3.57 enligt tibber)
- 20240201 12-13 61.75 kWh
Jag kör BLINK-HAN och har ett par “hål” i timdatan den 20:e, 21:a och 23:e jan. När väl rapporteringen dyker upp igen så tycks föregående timme/timmars förbrukning landa/summeras på timmen för återkontakt/återetablering av rapporteringen.
Om jag kan utesluta att det är wifi-relaterat och hittar färskare case/datum, önskas det felrapport och/eller uppdatering här i denna tråd?
Detta är specat beteende, för att inte “högre ordningens aggregat” (dygn, månad, år) ska bli felaktiga. Det är väl det bästa man kan göra i brist på data från perioden med nedtid?
Nej, det är snarare de WiFi-relaterade problemen som ska felsökas IMHO! 
Tack, jag ska försöka fånga denna i ett unit test, tar lite anteckningar här.
Timaggregat (felaktigt kl 12-13)
dWh är förbrukade Wh för respektive timma.
lC-kolumnen visar när enheten senast bootade vid respektive rapportering.
| Document ID | Wh | dWh | lC | t | |
|---|---|---|---|---|---|
| 1706781600000 | 55981 | 3213 | January 31, 2024 at 5:14:09 PM UTC+1 | February 1, 2024 at 11:00:00 AM UTC+1 | |
| 1706785200000 | 26 | 61750 | February 1, 2024 at 12:59:32 PM UTC+1 | February 1, 2024 at 12:00:00 PM UTC+1 | |
| 1706788800000 | 3127 | 3101 | February 1, 2024 at 12:59:32 PM UTC+1 | February 1, 2024 at 1:00:00 PM UTC+1 |
Avläsningar
bWh är antalet blink sedan boot.
| Document ID | Wh | bWh | lC | t | |
|---|---|---|---|---|---|
| 1706785224000 | 56011 | 56011 | (long time ago) | February 1, 2024 at 12:00:24 PM UTC+1 | |
| … | … | … | … | … | |
| 1706788693000 | 58823 | 58823 | February 1, 2024 at 12:58:13 PM UTC+1 | ||
| 1706788694000 | 2 | 2 | February 1, 2024 at 12:59:32 PM UTC+1 | February 1, 2024 at 12:58:14 PM UTC+1 | |
| 1706788762000 | 58882 | 58882 | February 1, 2024 at 12:59:22 PM UTC+1 | ||
| 1706788786000 | 14 | 14 | February 1, 2024 at 12:59:46 PM UTC+1 | ||
| 1706788800000 | 26 | 26 | February 1, 2024 at 12:59:32 PM UTC+1 | February 1, 2024 at 1:00:00 PM UTC+1 | |
| 1706788803000 | 29 | 29 | February 1, 2024 at 1:00:03 PM UTC+1 |
Om “bästa” likställs med “enda möjliga” eller “minst dåliga” så kan vi kalla det bästa.
Mycket möjligt (men försiktigt skeptisk) att nedtiden korrelerar med lite patchpanelsbyten, byten av samtliga AP´s, en av switcharna och inmontering av ny brandvägg. För att avgränsa det detektivarbetet skrev jag “om jag kan utesluta att det är wifi-relaterat” och därefter hur ev findings framöver önskades komma till er kännedom. Enheten är den enda klient som dyker upp i larmloggarna om att den bytt AP irrationellt, den behöver inte sitta där den sitter (men “ngn” hetsade om BLINK-HAN 
). Jag har bara prokratstinerat flytt pga kabeldragning i kylan, låsning till en AP etc då jag aldrig har problem att nå den inom rimlig tid via APP eller att surfa till den. Men det är glasklart, ser jag ngt fel och kommunikationen inte är orsaken så skriver jag ändå ingen felrapport.
Hej Björn,
efter mycket grävande kom vi fram till att dessa spikar orsakas av en bugg i enhetens firmware.
När enheten bootar och fått uppkoppling till WiFi, så begär den att stämpelklockan ska synkas.
Tanken var att den skulle invänta synk innan den börjar rapportera data, men där var buggen.
Buggfixad version
Om det är okej med dig @Bjoern lägger jag gärna din enhet i gruppen som får firmware 2.4.5 innan allmänheten? Vill du själv ha kontrollen kan du uppdatera manuellt.
Detaljer
Buggen medförde att första datapunkten efter omstart rapporterades som om den hade hänt för en minut sedan, vilket gjorde att din Wh-sekvens blev ..., 58820, 58823, 2, 58882, 14, 26, 29, ...
När sedan servern ska räkna upp din timförbrukning för 12-13, så ser det ut som om enheten startat om två ggr; mellan 58823, 2 och sedan mellan 58882, 14 eftersom Wh ska vara strängt ökande förutom vid restart.
1 Like
Go right ahead sir
1 Like
Bra, nu ska den uppdatera sig själv vid hel timme eller vid omstart, det som inträffar först.
Jag kan inte hitta några spikar sen 20240201 så jag föreslår den issue är resolved. Och jag får en ny mätare i veckan så jag återkommer med nya frågor 
1 Like