VidarJ

Heisann! Det er flere måter å gjøre dette på. Ett alternativ er å sette opp en automasjon, slik melb_ viser, men jeg har i tillegg satt inn en reboot funksjon i de tilfeller "batching_disable" ikke fungerer. Her er utklipp fra min automasjonskode i yaml-format: alias: MQTT - Holde Tibber Pulse i live description: "" mode: single triggers: - entity_id: - sensor.pulse_forsinkelse above: 40 trigger: numeric_state - entity_id: - sensor.pulse_forsinkelse above: 70 trigger: numeric_state conditions: [] actions: - choose: - conditions: - condition: numeric_state entity_id: sensor.pulse_forsinkelse above: 45 sequence: - data: qos: "0" topic: tibber/receive payload: reboot action: mqtt.publish - data: message: Tibber pulse reboot action: notify.persistent_notification - conditions: - condition: numeric_state entity_id: sensor.pulse_forsinkelse below: 45 sequence: - data: qos: "0" topic: tibber/receive payload: batching_disable -1 action: mqtt.publish I denne automasjonen har jeg satt opp "sensor.pulse_forsinkelse" som en template sensor i configuration.yaml. Du behøver ikke denne for å trigge automasjonen, men den er kjekk å ha. Alternativt bruker du bare en trigger på tid som melb_ viser i sitt inlegg. sensor: - name: "Pulse forsinkelse" state: > {% if is_number(as_timestamp(states.sensor.kaifa_active_power_import.last_updated)) %} {{(now() - states.sensor.kaifa_active_power_import.last_updated).total_seconds() | round(1)}} {% else %} 999 {% endif %} unique_id: "pulse_forsinkelse" unit_of_measurement: "s" Et annet alternativ er å bruke node red: Her har jeg brukt "batching_disable 999" i stedet for "-1", men det hadde ingen praktisk betydning. Kommandoen sendes hver minutt i mitt tilfelle, og dette fungerer greit. Dersom du ikke har installert Node Red, så er en automasjon enklere å starte med. Du kan undersøke om du klarer å kommunisere med pulse via MQTT ved å gå til "Enheter og tjenester->MQTT->Konfigurer". Begynn å lytte og skriv inn topic og kommando. I mitt tilfelle er det tibber/receive og tibber/publish: Dersom du kan kommunisere med pulse enheten, så skal få et svar som vist i bildet ovenfor.

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.

Kjenner ikke til noen norske, dessverre. Selv bestilte jeg fra Geekbord Official Store (Aliexpress). For en bundle med M.2 adapter, powersupply og original aktiv kjøler betalte jeg 42,5 Euro inkl. frakt og moms, men de har også M.2 alternativer. Frakten tar jo litt lenger tid da. For min del gikk det 3 uker fra bestilling til mottak

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 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 👌

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

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?

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?

Kult! Jeg gjør noenlunde det samme i mitt oppsett. Ut fra timeprisene beregnes de billigste 1-10 timene i døgnet. Når jeg plugger elbilen til, så henter jeg ladestatus og beregner hvor lang tid det tar å lade opp til ønsket ladenivå. Tar det 6 timer, så aktiveres lading i de 6 billigste timene. For varmtvannstanken, som er av den "dumme" typen, har jeg funnet ut at forbruket er nokså jevnt. Det holder å "lade" den på de 3 billigste timene. Strømprisen i grafen er inkl. mva, påslag fra leverandør og forbruksledd. Slik ser resultatet ut for de siste 10 dagene: Dagens billigste timer fordelte seg slik:

Takk for godt forum! Har lagt inn et månedlig bidrag

Selv bruker jeg Google Nest hub 2. gen til å vise instrumentbord fra Home Assistant ved hjelp av "casting". Jeg kan veksle mellom ulike instrumentbord direkte fra Google Nest hubben og bildene er dynamiske. Kan også slå av og på brytere, endre temperatursettpunkt, m.m. Det skal være mulig å vise websider, som f.eks T-banetabeller, men har ikke forsøkt å sette opp dette.

Jeg har kun én Mill Sense, og den har virket prikkfritt i ca et år. Kun et halvt års tid med HA, men stabil oppkobling. Før HA brukte jeg Mill API gjennom Integromat, og dette fungerte også greit. Overraskende å høre om problemene dere opplever. Hadde egentlig tenkt å kjøpe en til, men nå vil jeg tenke meg om en gang til. Krysser fingrene for at karma ikke slår til her også 😅

Gratulerer med ny 3D printer! Kjell&Co kjører av og til kampanjer på Addnorth. Har ingen erfaring med E-PLA, så meld gjerne tilbake erfaringer. Når det gjelder vanlig PLA så opplever jeg sjelden utfordringer med resultatet, bortsett fra med Anet sine filamenter. For PETG så har det vært en del prøving og feiling, men opplever minst problemer med PrimaSelect og Addnorth. Kikk også innom PolyAlkemi sitt sortiment