Tibber Pulse begynner å feile (sender MQTT til egen broker)

[mgartin]

Hei, jeg har to stk strømmålere, og to stk Tibber Pulse. Begge resatt og rekonfigurert til å sende MQTT-meldingene til egen lokal broker.

Dette har fungert strålende i lengre tid, og data har kommet inn i Home Assistant via AMSHAN-integrasjonen. De mar hvert sitt topic (tibber og tibber2).

 

Men - nå har den ene Pulse'en stoppet å fungere. Ligger det noe kode noe sted som lar meg dekode hex-strengen som jeg kan se med f.eks. mosquitto_sub?
I Home Assistant sin logg kommer det melding om

WARNING (MainThread) [custom_components.amshan.sensor] Could not decode meter message: XXX

der XXX er en streng på 958 tegn. Jeg vet ikke om den har sensitive opplysninger, så jeg utelater det her. Alle meldingene starter med samme 14 tegn:

08dcd9........

 

Dersom jeg kobler den fra og til HAN-porten, så har jeg fått den til å blinke blått og fungere i en liten periode, men så begynner den å sende disse meldingene igjen og ikke noe forbruksdata som amshan kan forstå.

 

Ruteren min sier at signalet er "Excellent" for begge Pulse'ene. Begge er befinner seg på samme sted, ca 1 cm fra hverandre.

 

Forslag til videre feisøing? Jeg tenkte jeg skulle prøve å koble til ekstern strømforsyning og se om det løser problemet midlertidig, men jeg vil jo ikke ha en powerbank stående ute (mine målere er i skap utenfor huset - Tibber Pulse'ene er satt i plastboks utenfor metallskapet)

Kan det være firmware? OTA updates? Annet?

 

[stigvi]

mgartin skrev (11 timer siden):

Kan det være firmware? OTA updates? Annet?

Utslitt flashminne, kanskje

[mgartin]

Ja mulig, jeg kjøpte denne brukt på finn... Må vurdere om jeg skal skaffe en ny da.

[Automatisk på nytt]

Har en som knapt er bukt.

 

Interessert?

[mgartin]

22 hours ago, Automatisk på nytt said:

Har en som knapt er bukt.

 

Interessert?

Ja, har sendt deg en PM.

[VidarJ]

Fungerte det å bytte Pulse?
Jeg sliter nemlig med samme problem.
Har to Pulse satt opp med lokal MQTT i hvert sitt hus. Begge med sterkt Wifi signal og blått blinkende lys, men null forbruksdata fra noen av dem.
Dersom jeg resetter ved å trekke ut kabel for så å sette den inn igjen, så sendes forbruksdata i rundt en halvtimes tid før de slutter å oppdatere igjen. 
Når forbruksdataene forsvinner, så sendes det fremdeles ut meldinger hvert 10 sekund (ca), men disse inneholder ikke forbruksdata.
De to ble kjøpt med noen måneders mellomrom, men begynte å feile omtrent på samme tid. Powerbank har ikke løst problemet.
Er det flere som opplever dette? 

[mgartin]

On 09/09/2023 at 08:06, VidarJ said:

Fungerte det å bytte Pulse?
Jeg sliter nemlig med samme problem.
...

Hei, jeg har ikke byttet ennå, for jeg fikk den til å fungere igjen. Men, som du også opplever, så kommer problemet tilbake. Akkurat nå har den fungert i over ett døgn etter at jeg koblet ut og inn RJ45-kabelen. Det ville være interessant å finne ut hva årsaken er.

Jeg har begge koblet på samme nett, og de sender på ulike topics, nemlig "tibber" og "tibber2". Det er tibber2 som feiler hos meg.

Hva får du opp dersom du kjører en kommando tilsvarende denne?:

mosquitto_sub -h 192.168.1.2  -F '@Y-@m-@dT@H:@M:@S@z : %I : %t %x ' -t tibber -t tibber2

Jeg har min mqtt-broker på 192.168.1.2.

 

Som nevnt i første post, så starter meldingene jeg får med '08dcd9', er det samme for deg?

[VidarJ]

mgartin skrev (2 timer siden):

Hei, jeg har ikke byttet ennå, for jeg fikk den til å fungere igjen. Men, som du også opplever, så kommer problemet tilbake. Akkurat nå har den fungert i over ett døgn etter at jeg koblet ut og inn RJ45-kabelen. Det ville være interessant å finne ut hva årsaken er.

Jeg har begge koblet på samme nett, og de sender på ulike topics, nemlig "tibber" og "tibber2". Det er tibber2 som feiler hos meg.

Hva får du opp dersom du kjører en kommando tilsvarende denne?:

mosquitto_sub -h 192.168.1.2  -F '@Y-@m-@dT@H:@M:@S@z : %I : %t %x ' -t tibber -t tibber2

Jeg har min mqtt-broker på 192.168.1.2.

 

Som nevnt i første post, så starter meldingene jeg får med '08dcd9', er det samme for deg?

 

Jeg får ingen respons i terminalvindu, men kan bekrefte at loggen viser 08dcd9 ca hvert 10 sekund. Er det de publiserte meldingene jeg skulle sett i terminalvinduet?
I går resatte jeg Pulse-enheten og satt den opp med standard Tibberkonfigurasjon. Med Tibberoppsettet virket den tilsynelatende som normalt gjennom et døgn, men da jeg på ny satt den opp med lokal MQTT så feilet den etter ca en halvtime igjen. Dvs, den feiler jo ikke fullstendig; Den slutter bare å sende forbruksdata. Statusmeldinger sendes hvert 2. minutt i JSON format. Jeg har satt opp sensorer i config.yaml for å kunne logge statusdata fortløpende.

 

I meldingen som sendes hvert 10s (08dcd9..) sendes informasjon om målerfabrikat, -type og serienummer. Det er altså ikke "søppel", selv om AMS-HAN ikke forstår det.

 

Er det mulig at Tibber sender ut en keep-alive/refresh/"ett_eller_annet" til Pulse-enheten for å holde den i live?

Ellers ser jeg at superkondensatoren i enheten har en begrenset levetid. Kan det være denne som svikter? 

[mgartin]

Jeg har lagt merke til at enheten min som sender 08dcd9... hele tiden, tilsynelatende virker normalt og effektforbruk oppdateres i HA, MEN dersom jeg restarter HA, så må jeg plugge enheten ut og inn (RJ45-kontakten) for at den skal virke igjen. Det er jo litt rart! Har registrert dette ved flere anledninger ifbm installering av nye pakker i HACS som krever restart av HA. Det hjelper f.eks. ikke å tvinge en reconnect av pulse'n i router'n.

Godt mulig det er superkondensatoren, men det virker som om det er noe annet som også spiller inn her. Den har fungert fint i over en uke nå mener jeg, men så kommer den ikke tilbake når jeg restarter HA, selv om jeg kjører mqtt broker på en anne maskin.

 

 

 

[docparody]

Har samme problem, det har visst blitt gjort en endring fra firmware-versjon 1.2.3 som gjør at den etter 15 minutter går over til å "batche", uten at jeg helt vet hva det betyr. Sitat fra Tibber support: "Ingen begrensinger ang. MQTT, men siste firmware gjør at Pulsen batcher etter ca 15 minutter oppetid."

 

Dette er nevnt her: https://github.com/toreamun/amshan-homeassistant/issues/67

 

Inntil Tibber gjør noe med dette har jeg en work-around som restarter Tibber Pulse før det har gått 15 minutter. Sender "reboot" til den topic-en som Pulse-en lytter på.

[VidarJ]

Takk for oppklaring! Batching?
Jeg har også forsøkt "reboot" løsningen, men synes ikke det er helt ideelt. Kunne jo selvfølgelig sende reboot hver 10. minutt, men alt i alt blir det litt nedetid mellom hver gang. Noen som kjenner til om det finnes en "keep-alive" melding vi kan sende? 

Her er mitt reboot oppsett i Home assistant:

alias: Test MQTT sending til Tibber Pulse
description: ""
trigger:
  - platform: time_pattern
    minutes: /14
    enabled: true
    seconds: "15"
  - platform: numeric_state
    entity_id: sensor.effektforbruk
    attribute: pulse_forsinkelse
    above: 60
condition: []
action:
  - service: mqtt.publish
    data:
      qos: "0"
      topic: Tibber/receive
      payload: reboot
mode: single

[docparody]

Enig, på ingen måter optimalt, men ser ut til at det er eneste løsning om man ønsker Tibber Pulse lokalt for øyeblikket. Alternativet er å koble den til Tibber-skyen og bruke Tibber-integrasjonen i HA, men det er jo ikke alltid stabilt heller.

 

Jeg tenker jeg kjører med regelmessig reboot en stund og ser det an. Mulig jeg bytter til noe annet enn Tibber Pulse etter hvert.

[docparody]

Jeg oppdaget i dag at Tibber-appen, når denne starter, slår av batchingen ved å sende melding til Tibber Pulse på receive-topicen: 

batching_disable 900

Det gir mulighet for en mer optimal løsning enn reboot hvert 15 minutt.

[VidarJ]

docparody skrev (1 time siden):

Jeg oppdaget i dag at Tibber-appen, når denne starter, slår av batchingen ved å sende melding til Tibber Pulse på receive-topicen: 

batching_disable 900

Det gir mulighet for en mer optimal løsning enn reboot hvert 15 minutt.

Jeg tror du fant løsningen her 😁
Prøvde å sende "batching_disable 0" for å se om batching ble permanent slått av, men det funket ikke. Deretter prøvde jeg å sende "batching_disable 1800", og den sendte data i en halvtime. Jeg vet ikke hva den øvre grensen er, men nå tester jeg med å sende "batching_disable 3600" hver time. So far so good 👌

[VidarJ]

Liten oppdatering:

Pulseenheten har nå firmware 1.2.5. Jeg sendte "batching_disable -1" til Pulse og fikk følgende svar:
{

"batching": "disabled",

"timeout": -1

}

 

Ingen stans i MQTT-strømmen de siste 4 døgn. Krysser fingrene for at det varer 🤓

[melb_]

VidarJ skrev (På 8.11.2023 den 17.46):

Liten oppdatering:

Pulseenheten har nå firmware 1.2.5. Jeg sendte "batching_disable -1" til Pulse og fikk følgende svar:
{

"batching": "disabled",

"timeout": -1

}

 

Ingen stans i MQTT-strømmen de siste 4 døgn. Krysser fingrene for at det varer 🤓

Jeg sender fortsatt "batching_disable true" til pulse en gang i halvtimen, firmware 1.2.3. Begynte din å batche igjen etter hvert?

I følge de på github issue postet lengre oppe var -1 en midlertidig fiks, men de var kanskje på 1.2.3.

[VidarJ]

Husker ikke helt detaljene, men det fungerte ganske lenge før problemene startet igjen. Når den først startet å tulle seg på nytt så kunne det gå alt fra ti minutter til flere uker mellom hver gang.

I forbindelse med overgang til rpi5 og ssd, så byttet jeg til en Zigbee HAN måler, men frem til da satt jeg opp et Node-Red script som sendte disable melding hvert minutt. Det fungerte for så vidt greit, men kommer nok ikke til å bruke pulseenheten mer. 

[melb_]

Ok, da lar jeg det bare kjøre sånn jeg har det frem til min også evt tar kveld. Spesielt at den er så egenrådig.