jkaberg

mroek skrev (17 timer siden):

 

Jeg tipper at de har bestemt seg for å droppe lokalt API, siden det på sett og vis reduserer verdien på skyen deres. Den har jo en opplagt salgsverdi hvis/når de havner i skifteretten, og jeg gjetter på at en tredjepart vil kjøpe hele skytjenesten og deretter innføre abonnement på den.

 

 

Godt poeng. Vi får bare håpe at de leverer på det de sa (den gangen) at de skulle levere, men jeg har heller mine tvil etter så lang tid (uten noe ny informasjon).

Men i tilfelle så vil det du nevner være grunn til og heve kjøpe (mot elektriker) etter min mening, da det i vesentlig grad endrer produktet.

Noen som har hørt noe mer ang lokalt api? Ser at de gamle brukerforumet er tatt ned, samtidig er det varslet oppsigelse på 200 stk og CEO går av/bytter stilling.

GMTrevis skrev (På 21.9.2022 den 6.01):

Til VVB temp.: DS18B20

Til temp overvåkning i rele' box: SKU350234 (10kOhm)

@GMTrevis hvordan kablet du dette? Ser ut som du har DATA på IN1 og GND på 0v, hvor plasserte du VCC? på 0v (parasite modus)? 4,7k motstand mellom DATA og VCC? Tenker på DS18B20 sensoren

stigvi skrev (1 time siden):

Det er ikke helt slik det virker. Hvis vi snakker om AC lading, da. Da "mater" du ikke en strøm. Ladeboksen forteller bilen hvilken strøm den kan lade med maksimalt og så er det laderen i bilen som tilpasser seg. Andre hensyn tas også som feks ladekabel sin maks strømstyrke og ikke minst bilens egen tilstand og maks strømstyrke. Bilen er tilkoblet 230/400V direkte via noen releer og boksen på veggen har som oppgave å koble fra bilen hvis det oppstår en feilsituasjon.

Det er laderen i bilen som sørger for å lade med opptil maks angitt strømstyrke.
Men laderen i bilen har noen begrensinger som varierer mellom bilmodeller. Så da er spørsmålet om du forventer for mye av din bil.

Ser i fra koden din at du også bruker set charger max limit. Dette er det advart mot fordi du vil slite ut Easee boksen sitt flashminne. Du må bruke de service kall som har "dynamic" i navnet.


PS. Advarselen dukker opp hvis du i utviklermiljøet i HA velger denne tjenesten i UI modus

Takk for at du påpekt utfordringen med flash minnet, har ikke kommet over den advarslen tidligere og kommer til at korrigere koden.

Ellers føler jeg at diskusjonen er på vei i feil rettning. I grunn har ikke dette noe med hvilken bil eller ombord laderen sine egenskaper og gjøre, fordi forbruks måling og styring skjer utenfor bilen og "bilen tar det den får". 

Som jeg (kanskje litt klønete) prøver og diskutere/drøfte/spørre om i OP er at prediksjonen er vel "hysterisk" som den er nå (ved at det er mange topper og daler i grafen). Dette fører blant annet til at billaderen justerer styrken ofte opp/ned for og holde seg innenfor tarif nivået. Dette har jeg nå prøvd og fikse med og kjøre prediksjonen mer sjelden (foreløpig hver 5 minutt, fra 1 minutt tidligere). 

stigvi skrev (8 minutter siden):

Da må en også forvente at bilen kan justere trinnløst og raskt sin ladestrøm. Kan den det? Mine to biler kan ikke det.

Litt usikker på om jeg skjønt hva du spurt om, men;

Ombordladeren justerer seg automatisk etter den strømstyrken som mates, dvs mater jeg 32A/~7kw så tar den det eller tilsvarende alt ettersom styring. Bruker da strømstyrke for og justere effekt, se bilde

Jeg har implementert en estimering av strømforbruk (som i sin tur bruker en integral sensor hvor jeg henter historiske verdier utefra et 15 minutters vindu) vha pyscript som brukes for og justere Easee laderen slik at jeg holder meg innenfor gjeldene tarif mål. Men sliter fælt med at prediksjonen bommer og resulterer i følgende ladekurve (visst vha strømstyrke sensoren til Easee'n)

Ideelt sett så skulle denne kurven vært mye mer jevn og justere seg minimalt etter forbruket ellers i huset, samtidig som den utnytter nåværende tarif mål maksimalt

Noen som sitt på forslag eller tanker ifht hvordan jeg kan forbedre dette? 🙂

Edit: Jeg har etter disse bildene vært tatt som en test justert oppdaterings frekvens på estimerings sensoren fra 1 minutt til 5, for og se hvilken forskjell det gjør (estimatene reagerer for kjapt på endringer?)

Etter at jeg fikk reklamert så virker det nå som relet fungerer bra. Som flere har nevnt så måler relet feil, og etter litt testing har jeg endt med følgende mal sensorer basert på det relet gir meg av informasjon. Absolutt ikke ideelt, men bedre enn ingenting.

vaskerom_vvb_temp_corrected - min VVB (OSO Saga 300L) kan stilles etter temperatur, og her tar jeg rett og slett utgangspunkt i hva den indre termostaten i VVB er stilt på (i mitt tilfelle 80C) og korrigerer sensoren iht det. Plassering av ds18b20 sensoren er mot stålkaret rett ved siden av VVB sin egen sensor.

vaskerom_vvb_watt_corrected - som nevnt måles det feil, etter litt frem og tilbake endt jeg på malen under. Her korrigerer jeg etter om relet er på, og i tilegg fjerner jeg feil målinger.

vaskerom_vvb_consumption_kwh_corrected - riemann sum sensor for ihv korrigering av kWh med utgangspunkt i vaskerom_vvb_watt_corrected

Følgende er for Home Assistant:

- platform: template
  sensors:
    vaskerom_vvb_temp_corrected:
      friendly_name: "VVB temperatur justert"
      icon_template: mdi:coolant-temperature
      unit_of_measurement: '°C'
      value_template: "{{ (states('sensor.vaskerom_vvb_air_temperature_2') | float(0) + 26.0)  | round(1) }}" # vvb er satt til 80 grader.
    vaskerom_vvb_watt_corrected:
      unit_of_measurement: 'W'
      friendly_name: 'VVB effekt justert'  
      icon_template: mdi:sine-wave  
      value_template: >-
        {% if is_state('switch.vaskerom_vvb', 'on') %}
          {% set corrected_watt = states('sensor.vaskerom_vvb_electric_consumption_w') | float(0) - 354.0 %}
          {% if corrected_watt > 25.0 %}
            {{ corrected_watt }}
          {% else %}
            0.0
          {% endif %}
        {% else %}
          0.0
        {% endif %}
 
- platform: integration
  name: vaskerom_vvb_consumption_kwh_corrected
  unique_id: vaskerom_vvb_consumption_kwh_corrected
  source: sensor.vaskerom_vvb_watt_corrected
  unit_prefix: k
  method: left

Da opplever jeg også at relet tar kveld (Dvs ikke nåbar via z-wave) etter kort tid (ca døgn), tar man sikkringen så kommer den tilbake men dør som sagt etter et døgn igjen. Også et summende lyd i det som virker være frakoblet/deaktivert (altså ikke noen strøm videre til VVB), trykker jeg inn reset knappen så aktiveres VVB og lyden forsvinner

Reklamasjon som er eneste alternativet eller? Kjører FW 2.1

@GMTrevishar du gjort noe med configurasjonen til relet? Ser at det er negativ verdi på ampere målinga

Kjørte temporært tidligere med et Heatit 16A rele og snittet på rundt 3-5kwh/dag - med dette relet ligger jeg nå +/- på 12kwh/dag, kjører da med den oppdateringen du postet

OlavT skrev (Akkurat nå):

 

Hvilken firmware versjon er dette? Manualen på nett er for "Firmware version: 0.12" og der er ikke parameter 19 beskrevet. Kommer nye enheter som er i salg med den nye formware versjonen eller må de oppgraderes?

Se innlegget til @GMTrevis på første side av tråden her

Da har jeg omsider fått montert denne i bunn i lag med resten av det elektriske på min OSO Saga 300. Ser at jeg jevnt over ligger på ca 47 grader uten særlig tapping av vann enda, og dette er når VVB ikke varmer. Så her mangler jeg et par 10 grader før vi er i nærheten.

Hvordan løste du dette @GMTrevis?

Tenker samtidig på om dette er ideel plassering? Ser at beredern er forberedt for ekstern styring med hull i toppen som er plugget (1/2"?), men det viser seg at OSO Charge som denne løsningen heter da kommer med et rør som man fører inn i beredern og da vil tempføler være ca i midten. 

PS: Stort takk for informasjonen du delte @GMTrevis, var til stor hjelp (spesielt zwave gruppe instillingene)

GMTrevis skrev (På 14.1.2022 den 14.13):

Hei, 

Deler min erfaring med dette rele'et vedr. temp måling.

Var i dialog med Heatit support hvor de informerte om at man må opprette multichannel assosiasjoner for at data fra temp ch.1, 2 og 3 skal sende data til gateway/master node.

Etter å ha opprettet gruppe for "Sensor Report IN1" (temp sensor ch.1) og "Sensor Report IN2" (temp sensor ch.2) mot gateway/master (Z-stick GEN5 i mitt tilfelle) ) oppdateres temp verdier for begge temp kanaler automatisk. 

 

Det har også kommet en ny firmware, hvor man ved å trykke på lokal "bind" knapp, toggler rele' av/på + ny parameter (nr.19) som skal huske siste tilstand ved strømbrudd.

 

Får ikke limt inn bilde her av ukjent årsak så legger til link med figur til assosiasjon lagt til i Z-wave JS to MQTT.

Håper det kan komme til nytte for andre!

 

https://community.home-assistant.io/t/z-wave-js-to-mqtt-how-to-enable-multichannel-heatit-z-relay-25a-solved/378996

 

 

Takk for god informasjon @GMTrevis, hvilke sensorer brukt du med denne?

@Truls ja det er en mulighet og 🙂 Endte opp med og kjøre på en magnetkontakt som følger skinnen i taket og får da kontakt i enden (dermed vet jeg at porten er åpen, og antar at all den tid magnetkontakten ikke har kontakt så er porten lukket) - satte den på INN2

På INN1 kjørte jeg en en vanlig bryter med impulsfjær, og OUT1 går da som illustrert på inngangene til motoren

Dette er godt testet i dag og fungerer veldig bra (med zwavejs2mqtt og HASS) og dekker behovet 🙂

Moskus skrev (14 timer siden):

Ja, det ser omtrent ut som det jeg har postet tidligere.  

 

 

Ja se der, det var ganske likt 😄 Takk for bekreftelsen!

Kom frem til at følgende tegning fungerer? 

Jeg er på halveis dypt vann her, men ser at flere har brukt Fibaro smart implant for og åpne/lukke garasjeporter.

Jeg lurte på om noen allerede har gjort tilsvarende med Hørmann Supramatic E4?

Ideelt sett hadde det vært trevlig og samtidig fått med om porten er åpen/lukket - kanskje via en grensebryter og IN1/2 på implanten?

Dokumentasjonen på selve motoren er her, slik jeg ser det er vel siden 27 mest intressant https://www.ligaard.net/sites/default/files/2021-06/Supramatic-4_NO.pdf

Jeg har en takvifte med RF styring som bruker chip fra Microchip (MRF89XAM8A) - ser ut som dette er 868 mhz. Samtidig har jeg en komfyr vakt fra Micromatic (Microsense) som jeg ser (fra FDV dokumentasjonen) operere på 433 mhz. 

Hadde en ide om og få skrudd på/av takviften i takt med platetoppen (idag brukes en fjernkontroll til dette). Men jeg er usikker på om komfyrvakten faktisk gir fra seg et signal når platetoppen skrur seg av/på - dette skal jeg prøve og finne utav (har en RTL-SDR og en Sonoff RF bridge) vha sniffing. 

Men er det noen som har prøvd seg på noe lignende? Eller evt kan dele tips/tanker om hva jeg bør være obs på 🙂

Selve automasjonen vil jeg mest sannsynlig gjøre med Sonoff RF bridgen og/eller en Raspberry PI med GPIO (pin 7?)

Før jeg går i gang med dette selv tenkte jeg høre om noen annen her har laget et dashboard for overvåkning av strøm inkl forbruk og pris per dag/mnd/år (inkl nettleie) og kunne tenkt seg dele dette? Er spesielt interessert i det og regne ut prisen fordelt på dag/mnd/år

I mitt hode ville dette blitt gjort med utgangspunkt i Nordpool og Tibber integrasjonen, med faste (oppdater bare) variabler for nettleie? Det som kan bli en utfordring er og kalkulere prisen da denne endrer seg hyppig utover døgnet?

På 27.9.2020 den 3.24, henrikhoe skrev:

Lagde en ny xml fil med en del endringer, virker å fungere greit nå, god natt

@henrikhoe Kunne du ha delt dine endringer? Har selv dette problemet

Noen som faktisk har fått dette til med OpenZwave og firmware 3.06? Har testet flere konfigurasjoner postet her... Rapporter stadig 0 som temperatur og får ikke overstyrt fra ekstern sensor til gulvsensor (som jeg bruker)