kjetilsn

Jah, så var det å lese litt før en spør forumet. Har satt opp entur, alt på plass.

Gammel tråd, men dette har funket veldig bra frem til nå. Ser ut som skyss har gjort endringer på sin side. Noen som har merket noe?

Etter å kjørt zoneminder lenge i docker uten å være veldig fornøyd, samt at docker versjon ikke lenger vedlikeholdes var det på tide å teste noe annet. Angrer på at jeg ikke fulgte rådet ditt for et år siden. Frigate er jo en drøm sammenlignet med zomeminder, deteksjon fungere veldig bra og det integrerer veldig bra mot home assistant. Var ikke klar over Coral prosjektet en gang, det er jo kjempetøft. Eneste problemet er at det er 42 uker leveringstid på Coral TPU fra Mouser, så foreløpid er det CPU deteksjon, som ser ut til å gå helt ok, da jeg bare har et kamera. Så takk for tips iblis, et år senere:)

Har lest litt, og det er flere som rapporterer at disse blir brent selv om det ikke er koblet en stor last på de. for eksempel her: https://forum.fibaro.com/topic/26375-solvedfibaro-wall-plug-burn-5pcs/page/2/ Kan jo ha skjedd en god del forbedringer på produktet siden 2017 selvfølgelig, men jeg forblir skeptisk til dette produktet. Det er nok mange som vil bruke denne pluggen på store laster uten å tenke seg om, hvorfor skulle de ikke? da det ikke er noe som hindrer de, og produktet jo oppgitt for bruk opp til 11A / 2500W.

Hei @Moskus Jeg ser logikken at disse små veggpluggene til Fibaro blir i minste laget for VVB. Har et par slike for å styre panelovner fra 500W til 1500W, (hadde tre men en sluttet å virke, som ble erstattet av en Nexa, da ute energimåling). Liker ikke å høre at de har en "undocumented feature" som er at de velger på plutselig ta fyr. kommer nok til å bytte de ut så snart som mulig. Kanskje du kunne lagt en advarsel for dette produktet på forsiden av forumet?

Sjekket litt til på dette, ser ut som du kan sette gruppe assosiasjon så lenge du kjører zwavejs2mqtt, men ikke i hass sin integrasjon. Om du har førstnevnte så kan du se hva du finner under "groups" i web Interface til wavejs. Under ser du hva jeg mener, on/off control fra termostat er assosiert med NodeID_1 som er gateway.

Hei, Jeg valgte å ikke oppgradere igjen til 1.92 da jeg med gamle openwave integrasjonen ikke ble fornøyd. Kan hende at dette er bedre nå med wavejs integrasjonen. Ergo så har jeg ikke den switch entity. Det er mulig at grunnen til at du ikke får verdi '255' på number entity når releet er på at du ikke har assosiert termostaten med Gateway på gruppe 0. Det vil si kontroll assosiasjon. Dette er der for å kunne styre andre zwave enheter fra termostaten, for eksempel kan du ha en termostat som ikke er koblet til varmekabel, kun styrer noen veggplugger tilkoblet panelovner. Poenget er at om du da assosierer Gateway (zwave stick) på denne måte får Gateway informasjon om termostaten sin tilstand. Ser at zwavejs ikke har funksjonalitet enda for å sette gruppe assosiasjon. https://community.home-assistant.io/t/is-setting-associations-planned-for-z-wave-js/369575 Hos meg var assosieringen allerede satt fra den gamle ozwave integrasjonen. Du kan jo logge med zwavejs og se om den plukker opp denne informasjonen. her er noen som diskuterer lignende: https://community.home-assistant.io/t/zwave-js-and-associations/305259

Ser at enheter som rapporterer dette direkte, feks heatit z-relay og noen fibaro releer bruker "state_class: total_increasing" ja så det er nok riktig. state_class: total_increasing meter_type: 1 meter_type_name: ELECTRIC unit_of_measurement: kWh device_class: energy friendly_name: AC

Det som skjer her er at alle entities som slutter på _energy vil få de tre attributtene vi snakker om. Jeg har selv en del "gamle" heatit termostater som ikke gir med energimåling, der jeg regner dette for å få en kWh teller, som igjen trenger disse attributtene for å "virke" i energi dashboardet: Det er mer ryddig å gjøre det i en template, men som stigvi er inne på så er det kanskje ikke rett frem. customize er mer en "nødløsning" men det funker.

Jeg løste det med "customize" prøv å legg til dette i configuration.yaml customize_glob: sensor.*_energy: last_reset: '1970-01-01T00:00:00+00:00' device_class: energy state_class: measurement

Hva ser du som "attributes" på entity? Tror du må ha med: 'state_class' 'device_class' 'last_reset'

He he, Godt sagt! Hvilke kort anbefaler du? har noen gamle NodeMCU liggende, og noen nyere ESP32 baserte jeg ikke husker navnet på.

Ikke dumt, har ikke fått testet noe med ESPHome enda, men ser jo ut som det er noe som skal på 2do listen.

Hei, Har som mål å gjøre noe av det samme etter hvert med vår gamle Panasonic pumpe. Planen er å bruke denne oppskriften: https://community.home-assistant.io/t/automated-heat-pump/24220

Så må du sørge for at energy entity har 'device_class: energy' og 'state_class: measurement', det finner du også i dev tools om stigvi viste deg. Vil tro de ikke har det, da kan du feks legge dette i configuration.yaml merk at da må du sørge for at entity slutter med '_energy' customize_glob: sensor.*_energy: last_reset: '1970-01-01T00:00:00+00:00' device_class: energy state_class: measurement

Den trigger på endringer, så når attributt "hvac_action" forsvinner grunnet oppdatering fra hass så kjører den og pusher tilbake denne attributten.

Hei, Endelig har mine TF016 termostater tilstandsinfo i climate entity: For å få "heating" og "idle" kommer fra attribute "hvac_action". Fant et script som setter attribute basert på andre entities: https://community.home-assistant.io/t/how-to-manually-set-state-value-of-sensor/43975/2 Automasjon som setter input_boolean bassert på releets tistand fra number entity: (grunnen til at jeg ikke bruker number entity direkte i neste automasjon er at den veksler mellom '0' som er av, '99' som jeg ikke hvet hva betyr, og '255' som betyr på.) ## Stue - alias: Ovens on stue trigger: entity_id: number.stue_basic platform: numeric_state above: '200' action: service: input_boolean.turn_on target: entity_id: input_boolean.heating_stue id: b2481b651f2d4e22a53dbf787ba61dd9 - alias: Ovens off stue trigger: entity_id: number.stue_basic platform: numeric_state below: '10' action: service: input_boolean.turn_off target: entity_id: input_boolean.heating_stue id: f1f928cac90a4573878d5344a0de716f Og så automasjon som setter attribute ved hjelp av scriptet: ## Heating_stue - id: set attribute thermostat stue alias: 'set attribute thermostat stue' trigger: platform: state entity_id: - climate.stue - input_boolean.heating_stue condition: condition: template value_template: >- {% if state_attr('climate.stue', 'hvac_action') == none %} true {% elif "input_boolean" in trigger.entity_id %} true {% else %} false {% endif %} action: service: python_script.set_state data_template: entity_id: 'climate.stue' hvac_action: >- {% if is_state('input_boolean.heating_stue', 'on') %}heating{% else %}idle{% endif %}

Hei, Noen som bruker TF016 termostatene med FW1.92 og zwavejs integrasjonen her? Jeg endte med å gå tilbake til FW1.8 på disse da det var en dårlig kombo med ozwave integrasjonen. Vurdere å flashe en av de til FW1.92 for å teste.

Utålmodig som jeg er så postet jeg samme spørsmålet på Home Assistant forumet, og som det ofte er så viste det seg at dette er enklere en først antatt. Viser seg at det blir generert en disablet number entity for hver climate entity. denne enity korresponderer med 'Basic set' og gir info som trengs direkte. https://community.home-assistant.io/t/zwavejs-automation-trigger-on-node-event/376267 Så da er alt i orden. Det hadde vert veldig kjekt å få denne tilstandsinformasjonen inn i climate entity slik at den kan rapportere 'heating' og 'idle' samt endre farge bassert på tilstand slik som andre termostater som faktisk rapportere dette tilbake eller for eksempel generic thermostat gjør. Noen som vet hvordan dette kan gjøres? Første tanke er å modifisere zwave config fil i zwavejs.

Hei, Da var tiden inne for zwavejs Siden jeg kjører Home Assistant i docker gikk jeg for zwavejs2mqtt docker installasjon. Deaktivert MQTT delen og snakker med home assistant over Z-Wave JS websocket server. Har prøvd å lytte etter "zwave_js_notification", "zwave_js_value_notification" og " zwave_js_value_updated" gjennom "devtools" -> "Events" uten å få noe som helst. Har sjekket i logge til zwave2mqtt at info blir motatt: 2022-01-06T19:37:52.574Z DRIVER « [Node 005] [REQ] [ApplicationCommand] └─[BasicCCSet] target value: 0 2022-01-06T19:37:52.577Z CNTRLR [Node 005] treating BasicCC::Set as a report 2022-01-06T19:37:52.577Z CNTRLR [Node 005] [~] [Basic] currentValue: 255 => 0 [Endpoint 0] 2022-01-06T19:37:07.831Z DRIVER « [Node 005] [REQ] [ApplicationCommand] └─[BasicCCSet] target value: 255 2022-01-06T19:37:07.834Z CNTRLR [Node 005] treating BasicCC::Set as a report 2022-01-06T19:37:07.834Z CNTRLR [Node 005] [~] [Basic] currentValue: 0 => 255 [Endpoint 0] CurrentValue til 0 er rele av og 255 er rele på. Lurer på om dett blir sendt som event delen i home assistant i det hele tatt?.

Hei, emonEVSE er OpenEVSE i EU utgave, har selv et kit av OpenEVSE og er godt fornøyd med det. Lett å integrere da det har eget API og også MQTT støtte. Kildekode er selvfølgelig åpen, så her kan du da også gjøre endringer om du vil det. Nå er det vel bare WIFI støtte på disse, men du kan installere eget kort for å få Ethernet: https://shop.openenergymonitor.com/openevse-etherent-gateway-esp32/

Noen som har oversikt på hvor mye tap det er i disse kablene? Vil tro det er betydelig mengde energi som går tapt over dammen, ca. 30% kanskje? I dag handler jo ting om å være kortreist, det gjelder jo for energi også. Lurt med solceller på taket osv, problemet er da lagring, der det ikke finnes noen god løsning (og nei litium batteripakker er ikke løsningen). Med vannkraft er ikke dette et problem, dammene er batterier som vi kan bruke til å "lagre strøm" til den kalde vinteren kommer, men ikke når dammene begynner å bli tomme på vei in i vinteren for noen har solgt strømmen. Helt enig med deg SveinHa, dette er forkastelig. At vi finner oss i det uten kamp er også nesten litt uforståelig, men vi som folk har det vel kanskje litt for godt, og finner oss i det meste. Noen mener det er helt ok at vi skal ha en strømpris lik den i EU, det er feil. Vi kan ikke som resten av EU velge om vi skal varme opp med gass eller elektrisitet, de aller fleste av oss er låst på sistnevnte, mange har ikke engang mulighet til å fyre med ved.

Ikke dumt, tenker du selv eier en del skog også da:)? Vi lurer på å gå for denne: https://www.hetastoves.com/scanlineaqua Sammen med en 600 - 1000 liter tank og radiatorer, slik det er i dag ville det fort ha lønnet seg, selv med kjøpt ved.

Ble nesten litt skuffet nå.. Men men, tror ikke det i praksis var så mye en hadde klart å spare i forhold til dagens tariff. Det som er helt sikkert er at det skal hogges mye ved fremover:)

Takk stigvi, Det er supert, da slipper jeg tydeligvis å bruke første delen av templaten som "sjekker" om state er "unknown"