Ilmaisenergia.info

Ilmaisenergia.info - Yleiset keskusteluaiheet => Elektroniikka => Aiheen aloitti: pere - 03.10.18 - klo:07:09

Otsikko: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 03.10.18 - klo:07:09
Aurinkopaneeleiden max teho n. 3000w
LVV myös 3000w ja 160L
3-vaihe invertteri
ei vaihenetotusta

Ajattelin käyttää tuota LVV:tä tuotetun aurinkoenegian käyttöön.
Mutta se on liian tehokas se ei ole päällä kun tunnin ja silloinkin yleensä joutuu ostoenergian käyttöön.
Luulisin että jos sen tehoa voisi säätää aina paneelien tuoton mukaan
niin tulos olisi parempi, myyntiin menisi vähemmän.

Siis millainen säätölaite olisi (triac?) jolla voisi tuota tehoa säätää aina
tuotetun tehon mukaan?
Rasperry kyllä voi hakea paneelien tehotiedot vaikka sekunnin välein ja sitten ohjata säädintä.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: tengu - 03.10.18 - klo:10:44
Tutustuppa tuohon mk2pvrouteriin mistä täälläkin ollut paljon juttua. Optimoi juuri tuon homman ja on diy laite.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: Savonius - 04.10.18 - klo:18:00
Aurinkopaneeleiden max teho n. 3000w
LVV myös 3000w ja 160L
3-vaihe invertteri
ei vaihenetotusta

Ajattelin käyttää tuota LVV:tä tuotetun aurinkoenegian käyttöön.
Mutta se on liian tehokas se ei ole päällä kun tunnin ja silloinkin yleensä joutuu ostoenergian käyttöön.
Luulisin että jos sen tehoa voisi säätää aina paneelien tuoton mukaan
niin tulos olisi parempi, myyntiin menisi vähemmän.

Siis millainen säätölaite olisi (triac?) jolla voisi tuota tehoa säätää aina
tuotetun tehon mukaan?
Rasperry kyllä voi hakea paneelien tehotiedot vaikka sekunnin välein ja sitten ohjata säädintä.

Onko tullut mieleen että voit "vääntää sulakkeet löysälle" varaajan kahdesta vaiheesta jolloin sinulla olisi 220 litran varaaja jossa olisi yksi 1000W vastus. Päivän lyhentyessä toinenkin sulake kiinni niin tehoa on 2000w jne. Kuukauden perästä tarvitset kaikki kolme eikä riitäkään. Temaria ruuvaamalla selviät auringolla pitkään. Kaakkoon kun aurinko paistaa muina aikoina sinne viidenkympin päälle.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 04.10.18 - klo:18:52
Aurinkopaneeleiden max teho n. 3000w
LVV myös 3000w ja 160L
3-vaihe invertteri
ei vaihenetotusta

Ajattelin käyttää tuota LVV:tä tuotetun aurinkoenegian käyttöön.
Mutta se on liian tehokas se ei ole päällä kun tunnin ja silloinkin yleensä joutuu ostoenergian käyttöön.
Luulisin että jos sen tehoa voisi säätää aina paneelien tuoton mukaan
niin tulos olisi parempi, myyntiin menisi vähemmän.

Siis millainen säätölaite olisi (triac?) jolla voisi tuota tehoa säätää aina
tuotetun tehon mukaan?
Rasperry kyllä voi hakea paneelien tehotiedot vaikka sekunnin välein ja sitten ohjata säädintä.

Onko tullut mieleen että voit "vääntää sulakkeet löysälle" varaajan kahdesta vaiheesta jolloin sinulla olisi 220 litran varaaja jossa olisi yksi 1000W vastus. Päivän lyhentyessä toinenkin sulake kiinni niin tehoa on 2000w jne. Kuukauden perästä tarvitset kaikki kolme eikä riitäkään. Temaria ruuvaamalla selviät auringolla pitkään. Kaakkoon kun aurinko paistaa muina aikoina sinne viidenkympin päälle.

Osuitpas kysymään juuri oikeaan aikaan!
Nimittäin tulin ajatelleeksi juuri tuota konstia ja tänään iroitin 2 sulaketta.
Termostaatti 80 astetta.
Huomenna siten kun sähköyhtiön tiedot on päivittyneet katson miten kävi.

Mutta tarkoitus on kuitenkin kokeilla vietä tuota tehonsäätöä.
Tilasin jo 3 triac säädintä, 1 joka vaihelle.
Ensin testailen vain käsisäädöllä ja ehkä myöhemmin yritän ohjata niitä rasperryn avulla.

Ohjelma joka hakee sen hetkisen tuoton invertteriltä (xxx wattia) minulla jo on tehtynä,
vain tuo ohjaus vielä puuttuu.

Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: jolla - 04.10.18 - klo:21:00
inwerttwriltä haettu tuotto ei huomioi kulutusta, jos tuotto on kilowatti ja kulutusta kilowatti ja ohjaat tuoton mukaan kilowatin veteen, niin.......
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: petriojk - 04.10.18 - klo:23:59
Nyt en oikein ymmärrä mitä tuo yhdellä vaiheella lämmittäminen oikein hyödyttää ilman vaihenetotusta ja 3-vaihe invertterillä? Oli sitten 1, 2 tai 3 vaihetta kytkettynä niin yhtä lailla se aurinkoenergian ja ostosähkön jakauma on sama. Jos vastusten tehoa voi säätää niin sitten pienemmällä teholla ja pidemmällä lämmitysajalla saadaan parempi hyöty "ilmaisesta" sähköstä.

Tuoton perusteella tehdyssä ohjauksessa on tosiaan tuo jollan mainitsema haittapuoli jos peruskulutus ei ole kutakuinkin vakio ja sitä ole huomioitu tuossa ohjauksessa. Itse tein päälle-pois ohjauksen tuotannon perusteella siten että varaaja kytketään päälle kun tuotanto ylittää peruskuorman (500w) ja lämminvesivaraajan (3000 w) yhteistehon. Todellisuudessa taisin laittaa 3400 w kytkeytymisrajan ja 2900 w avausrajaksi. Eli ostosähköä menee enimmillään 600 w ennen kuin varaaja kytkeytyy pois.

Laskeskelin tuossa että päivä- ja yösähkön hintaero on 24%. Tämän perusteella varaajan lämmittäminen vajaalla aurinkoteholla yö-sähkön sijaan kannattaa jos auringon osuus on vähintään tuon 24%, eli raja menee 720 w kohdalla. Talon 500w peruskuorma huomioiden raja on käytännössä 1220 w. Nyt lämmityskaudella tuo peruskuorma on tosin ihan jotain muuta kuin 500 w.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 05.10.18 - klo:07:16
Nyt en oikein ymmärrä mitä tuo yhdellä vaiheella lämmittäminen oikein hyödyttää ilman vaihenetotusta ja 3-vaihe invertterillä? Oli sitten 1, 2 tai 3 vaihetta kytkettynä niin yhtä lailla se aurinkoenergian ja ostosähkön jakauma on sama. Jos vastusten tehoa voi säätää niin sitten pienemmällä teholla ja pidemmällä lämmitysajalla saadaan parempi hyöty "ilmaisesta" sähköstä.

Tuoton perusteella tehdyssä ohjauksessa on tosiaan tuo jollan mainitsema haittapuoli jos peruskulutus ei ole kutakuinkin vakio ja sitä ole huomioitu tuossa ohjauksessa. Itse tein päälle-pois ohjauksen tuotannon perusteella siten että varaaja kytketään päälle kun tuotanto ylittää peruskuorman (500w) ja lämminvesivaraajan (3000 w) yhteistehon. Todellisuudessa taisin laittaa 3400 w kytkeytymisrajan ja 2900 w avausrajaksi. Eli ostosähköä menee enimmillään 600 w ennen kuin varaaja kytkeytyy pois.

Laskeskelin tuossa että päivä- ja yösähkön hintaero on 24%. Tämän perusteella varaajan lämmittäminen vajaalla aurinkoteholla yö-sähkön sijaan kannattaa jos auringon osuus on vähintään tuon 24%, eli raja menee 720 w kohdalla. Talon 500w peruskuorma huomioiden raja on käytännössä 1220 w. Nyt lämmityskaudella tuo peruskuorma on tosin ihan jotain muuta kuin 500 w.

Tällähetkellä kun parempaa systeemiä ei vielä ole invertterin tuotannonohjausrele menee päälle kun ylitetään 1000w ja pois kun alitetaan 500w.
Sillä yritettään ohjata varaajaa. Sitten vielä yöllä varaaja kytkeytyy kuten ennenkin. Tuo yhden vaiheen kokeilu on vain "kokeilu".
Pohjakuorma on tähän aikaan vuodesta minullakin  n. 500w, toki olin ajatellut huomioida myös sen.

Olen myös yrittänyt tutustua tuohon MK2pvrouter systeemiin, siinä ymmärtääkseni yhtenä lähtökohtana myös kulutuksen mittaus.
Huonon ulkomaankielen osaamisen takia se on minulle hieman hankalaa google kääntäjä kyllä auttaa mutta se tekee usein aika omituisia käännöksiä.

Arduinon sijaan haluaisin käyttää rasperryä koska sen ohjelmointi on minulle tutumpaa.
Löytyisiköhän jostain ymmärrettävä selitys tuon CT:n kytkennästä ja käytöstä?

t. pere 73v

Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: jolla - 05.10.18 - klo:09:37
itsekin etsin suomen kielellä MK2pvrouter' iin jotain simppeliä opastusta mutta ei siihen ole
se toimii kuitenkin sillä Mk2_PV_Router_mini_3.ino' lla arduinolla, vaatii ainoastaan 5 vastusta ja yhden elkon, ct anturin, ssr releen ja jonkin , vaikkapa vanhan nokian kännykän laturin muuntajan
perustoiminnassaan ei tarvitse mitään virittelyjä, vastuksetkin voivat olla "sinnepäin"
ei tarvitse miettiä peruskulutuksia eikä mitään pienillä virtamäärillä
kuvassa hieman eri muunnos, mutta simppeli sekin
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: tengu - 05.10.18 - klo:10:31
Olen myös yrittänyt tutustua tuohon MK2pvrouter systeemiin, siinä ymmärtääkseni yhtenä lähtökohtana myös kulutuksen mittaus.
Huonon ulkomaankielen osaamisen takia se on minulle hieman hankalaa google kääntäjä kyllä auttaa mutta se tekee usein aika omituisia käännöksiä.

Arduinon sijaan haluaisin käyttää rasperryä koska sen ohjelmointi on minulle tutumpaa.
Löytyisiköhän jostain ymmärrettävä selitys tuon CT:n kytkennästä ja käytöstä?

t. pere 73v

Miten tuo mk2pv toimii niin:
Se mittaa mihin suuntaan virta kulkee keskuksessa olevilla CT antureilla ja tämän perusteella triacilla ajaa pulsseja vastukseen. Mk2 pyrkii pitämään kulutuksen  1Wh sisällä, mitä mk2:sessa kutsutaan "ämpäriksi".  Sähkömittarissa yksi pulssi on ja 1Wh. Niin kauan kun ämpäri ei tulvi yli tai kuivaa niin mittari ei laske pulsseja. Heti kun ämpäri tulvii niin mittari lisää yhden pulssin kulutukseen ja jos ämpäri menee tarpeeksi kuivaksi niin lisätään pulssi tuotannon puolelle.
3~ versiossa vaan:
3 CT anturia keskuksessa. 3 muuntajaa piirikortilla jännitteelle / zero point crossing havainnolle. Arduinossa näppärä algoritmi laskemassa vaiheet yhteen ja sen perusteella ajetaan kuormia päälle.

Omassa 3~ versiossa on 3 kuormaa käytössä.
1. Ensisijainen KV käyttöveden boosteri ajetaan 90+C toisen termarin läpi. Normi termari 55-60C
2. 2kw vastus isoon varaajaan
3. 2kw vastus isoon varaajaan.

Vastuksia ei kannata käyttää liian isoja kun voi tulla tuo valojen vilkkumisongelma triaceilla. Mielummin useampi pienempi vastus ja useampi lähtö kuorman ohjaukseen.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 05.10.18 - klo:12:27
Miten tuo mk2pv toimii niin:
Se mittaa mihin suuntaan virta kulkee keskuksessa olevilla CT antureilla ja tämän perusteella triacilla ajaa pulsseja vastukseen. Mk2 pyrkii pitämään kulutuksen  1Wh sisällä, mitä mk2:sessa kutsutaan "ämpäriksi".  Sähkömittarissa yksi pulssi on ja 1Wh. Niin kauan kun ämpäri ei tulvi yli tai kuivaa niin mittari ei laske pulsseja. Heti kun ämpäri tulvii niin mittari lisää yhden pulssin kulutukseen ja jos ämpäri menee tarpeeksi kuivaksi niin lisätään pulssi tuotannon puolelle.
3~ versiossa vaan:
3 CT anturia keskuksessa. 3 muuntajaa piirikortilla jännitteelle / zero point crossing havainnolle. Arduinossa näppärä algoritmi laskemassa vaiheet yhteen ja sen perusteella ajetaan kuormia päälle.

Omassa 3~ versiossa on 3 kuormaa käytössä.
1. Ensisijainen KV käyttöveden boosteri ajetaan 90+C toisen termarin läpi. Normi termari 55-60C
2. 2kw vastus isoon varaajaan
3. 2kw vastus isoon varaajaan.

Vastuksia ei kannata käyttää liian isoja kun voi tulla tuo valojen vilkkumisongelma triaceilla. Mielummin useampi pienempi vastus ja useampi lähtö kuorman ohjaukseen.

Ymmärsinkö oikein? CT ei mittaa kulutusta vaan sitä kumpaan suuntaan virta kulkee kulutukseen vai myyntiin?
Ja jos myyntiin niin lisätään kulutusta ja päinvastoin.
Eikös tämä pitäisi olla 3~ systeemissäkin vaihekohtaista niin mihin tarvitaa vaiheiden yhteenlaskemista?
Minun KV varaajassa on 3 1000w vastusta joita on tarkoitus käyttää juuri tuohon tarkoitukseen.
Tietenkin jos esim. talvikautena tuotto ei riitä niin pakko käyttää ostosähköä. Jotekinhan tämäkin on huomioitava.

Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: Savonius - 05.10.18 - klo:12:44
Nyt en oikein ymmärrä mitä tuo yhdellä vaiheella lämmittäminen oikein hyödyttää ilman vaihen
Jos tuo varaaja on aamulla 50 astetta  ja termostaatti laitetaan 82 asteeseen niin varaajaan mahtuu n. 6Kwh.  Se on siinä paikkeilla mitä tuosta yhdestä vaiheesta tulee auringosta hyvissä olosuhteissa.  Muuhun kulutukseen jää kaksi kilovattia johon kulutuksen osuminen on satunnaista ilman erityisiä toimia. Normipäivänä kuluisi yhdessä vaiheessa vedenlämmitysaikana kuusi kilovarttituntia + 1/3 muusta kulutuksesta ja muissa vaiheissa 2/3 muusta kulutuksesta. (vähän oikaisten).
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: tengu - 05.10.18 - klo:12:57

Ymmärsinkö oikein? CT ei mittaa kulutusta vaan sitä kumpaan suuntaan virta kulkee kulutukseen vai myyntiin?
Ja jos myyntiin niin lisätään kulutusta ja päinvastoin.
Eikös tämä pitäisi olla 3~ systeemissäkin vaihekohtaista niin mihin tarvitaa vaiheiden yhteenlaskemista?
Minun KV varaajassa on 3 1000w vastusta joita on tarkoitus käyttää juuri tuohon tarkoitukseen.
Tietenkin jos esim. talvikautena tuotto ei riitä niin pakko käyttää ostosähköä. Jotekinhan tämäkin on huomioitava.

CT mittaa juurikin kumpaan suuntaan virta kulkee. Eli periaatteessa juuri kulutusta. Jos virtaa alkaa mennä ulos niin lisätään vastuskuormaa ja toisinpäin.
3~ systeemissä riippuu ihan täysin kenen verkon toimittajan alueella olet. Carunan verkossa netotetaan vaiheet muista en tiedä. Eli Carunalla esim Vaihe 1 ulos 2kw; vaihe 2 kulutus 1kw; vaihe 3 kulutus 1kw. Tällöin mittari näyttää nollaa.
Jos ei vaihenetotusta niin samalla esimerkillä 2kw menee ulos (jos myyt niin myyntiin jos ei niin "hukkaan") ja samaan aikaan maksat noista 1+1kw sähköstä kulutuksen mukaan.

Lisää varaajaan toinen termari minkä kautta aurinkosähkö samaan vastukseen (kunhan katsot ettei mene vaiheet sekasin).

Lyhyesti jos vaihenetotus niin ei väliä missä vaiheessa kuorma. Jos ei vaihenetotusta niin kuormitus optimoitava samalle vaiheelle missä aurinkoinvertteri(t).
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 05.10.18 - klo:17:22
itsekin etsin suomen kielellä MK2pvrouter' iin jotain simppeliä opastusta mutta ei siihen ole
se toimii kuitenkin sillä Mk2_PV_Router_mini_3.ino' lla arduinolla, vaatii ainoastaan 5 vastusta ja yhden elkon, ct anturin, ssr releen ja jonkin , vaikkapa vanhan nokian kännykän laturin muuntajan
perustoiminnassaan ei tarvitse mitään virittelyjä, vastuksetkin voivat olla "sinnepäin"
ei tarvitse miettiä peruskulutuksia eikä mitään pienillä virtamäärillä
kuvassa hieman eri muunnos, mutta simppeli sekin

Onko tuo sinun systeemi 1-vaiheinen? Minulla on 3-vaihe invertteri ja sähkölaitoksella ei ole vaihe netotusta.
Siksi luulisin että sen optimointi on hankalampi. Se tulee tehdä joka vaiheelle erikseen.
Mistä tuon kokonaisuuden voi ostaa vai täytyykö se rakentaa itse hankituista osista?
Löytyykö jostain kytkentäkaavio niiltäosin kun on tarpeen?
Mikä arduino versio?
Siinä muutamia kysymyksiä aluksi.

Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: jolla - 05.10.18 - klo:17:36
on yksivaiheinen
täällä juttua aiheesta
http://ilmaisenergia.info/foorumi/index.php?topic=2119.msg27169;topicseen#msg27169

minulla on käytössä arduino pro mini
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: tengu - 05.10.18 - klo:19:36

Onko tuo sinun systeemi 1-vaiheinen? Minulla on 3-vaihe invertteri ja sähkölaitoksella ei ole vaihe netotusta.
Siksi luulisin että sen optimointi on hankalampi. Se tulee tehdä joka vaiheelle erikseen.
Mistä tuon kokonaisuuden voi ostaa vai täytyykö se rakentaa itse hankituista osista?
Löytyykö jostain kytkentäkaavio niiltäosin kun on tarpeen?


Tuolta voit ostaa valmiit kitit, ei vaadi kuin kasaamisen: http://mk2pvrouter.co.uk/13779.html
Tuolta löytyy vapaasti ladattavana koodi, osalistat, piirikaaviot ym.

Periaatteessa sinun tilanteessa tarvisit 3 kpl yksivaiheyksikköä.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: denzil dexter - 05.10.18 - klo:19:57
Ilmeisesti suomalainen, vaihekohtainen sähkönmyyntihuijaus on maailmalla ainutlaatuinen, koskapa invertterit eivät suoraan tasoita vaiheita.
Muuallahan se menee siten, että sähkölasku tulee vain siitä kulutuksesta, joka näkyy talon ulkopuolelle.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: jolla - 05.10.18 - klo:21:25

Onko tuo sinun systeemi 1-vaiheinen? Minulla on 3-vaihe invertteri ja sähkölaitoksella ei ole vaihe netotusta.
Siksi luulisin että sen optimointi on hankalampi. Se tulee tehdä joka vaiheelle erikseen.
Mistä tuon kokonaisuuden voi ostaa vai täytyykö se rakentaa itse hankituista osista?
Löytyykö jostain kytkentäkaavio niiltäosin kun on tarpeen?


Tuolta voit ostaa valmiit kitit, ei vaadi kuin kasaamisen: http://mk2pvrouter.co.uk/13779.html
Tuolta löytyy vapaasti ladattavana koodi, osalistat, piirikaaviot ym.

Periaatteessa sinun tilanteessa tarvisit 3 kpl yksivaiheyksikköä.

jos ei tarvitse näyttöä eikä noita muita hienouksia, niin sivullani on 4 pelkistettyä mallia schemasta ilman näyttöä ja kulutuksen seurantaa, samanlaisen kuohinnan voi tehdä myös 3-vaiheiselle
http://www.elisanet.fi/korsteeni/mk2pv.shtml

kaikesta vastuusta pakenen
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: tengu - 05.10.18 - klo:22:02

jos ei tarvitse näyttöä eikä noita muita hienouksia, niin sivullani on 4 pelkistettyä mallia schemasta ilman näyttöä ja kulutuksen seurantaa, samanlaisen kuohinnan voi tehdä myös 3-vaiheiselle
http://www.elisanet.fi/korsteeni/mk2pv.shtml

kaikesta vastuusta pakenen

Jos muistan oikein niin 3 vaiheiseen ei taida saada näyttöjä ym hienouksia ollenkaan kun loppuu pinnit kesken.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: ismo67 - 06.10.18 - klo:21:59

Onko tuo sinun systeemi 1-vaiheinen? Minulla on 3-vaihe invertteri ja sähkölaitoksella ei ole vaihe netotusta.
Siksi luulisin että sen optimointi on hankalampi. Se tulee tehdä joka vaiheelle erikseen.
Mistä tuon kokonaisuuden voi ostaa vai täytyykö se rakentaa itse hankituista osista?
Löytyykö jostain kytkentäkaavio niiltäosin kun on tarpeen?


Tuolta voit ostaa valmiit kitit, ei vaadi kuin kasaamisen: http://mk2pvrouter.co.uk/13779.html
Tuolta löytyy vapaasti ladattavana koodi, osalistat, piirikaaviot ym.

Periaatteessa sinun tilanteessa tarvisit 3 kpl yksivaiheyksikköä.
Onko MK2PVRouter "valtakunnan verkkoon" hyväksytty laite?
Wattrouter MX on ks. käyttöohjeesta sertifikaatit.

https://solarcontrols.cz/en/wattrouter_mx.html
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: jolla - 07.10.18 - klo:08:59

Onko tuo sinun systeemi 1-vaiheinen? Minulla on 3-vaihe invertteri ja sähkölaitoksella ei ole vaihe netotusta.
Siksi luulisin että sen optimointi on hankalampi. Se tulee tehdä joka vaiheelle erikseen.
Mistä tuon kokonaisuuden voi ostaa vai täytyykö se rakentaa itse hankituista osista?
Löytyykö jostain kytkentäkaavio niiltäosin kun on tarpeen?


Tuolta voit ostaa valmiit kitit, ei vaadi kuin kasaamisen: http://mk2pvrouter.co.uk/13779.html
Tuolta löytyy vapaasti ladattavana koodi, osalistat, piirikaaviot ym.

Periaatteessa sinun tilanteessa tarvisit 3 kpl yksivaiheyksikköä.
Onko MK2PVRouter "valtakunnan verkkoon" hyväksytty laite?
Wattrouter MX on ks. käyttöohjeesta sertifikaatit.

https://solarcontrols.cz/en/wattrouter_mx.html


muuntaja ce hyväksytty ja ssr ce hyväksynnällä, ct ei ole kytketty verkkoon, loput jännitteet ohjausvirtoja alle 11v
tuon muuntajankin voi korvata joten verkkoon on kytketty ainoastaan ce hyväksytty ssr
verkkoyhtiö voi tietysti käyttää samanlaista mielivaltaa kuin rahastaessaakin
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 07.10.18 - klo:12:30
Mikä on ssr, ja mihin sitä tarvitaan?
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: jolla - 07.10.18 - klo:15:07
Mikä on ssr, ja mihin sitä tarvitaan?

se on ensimmäisen viestisi triac valmiissa paketissa zero-crossing tunnistuksella

kuukkelilla ssr relay

Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 07.10.18 - klo:17:10
Mikä on ssr, ja mihin sitä tarvitaan?

se on ensimmäisen viestisi triac valmiissa paketissa zero-crossing tunnistuksella

kuukkelilla ssr relay

Oi kiitos! Tämähän selvitti asiaa huomattavasti.
Tuolla tarvitavaa tehoa ohjataan varmaakin ohjauspulssin pituudella?
Mitähän suuruusluokkaa tuo ohjauspulsitaajuus tulisi olla varaajan vastuksen tehoa säädettäessä 0 - 1000w?
Tietysti jos maksimi niin kokoajan ylhäällä mutta nuo pienemmät tehot?
Kuvitelisin että jos liian pieni taajuus niin se mokoma kerkiää jo hakea mahdollisesti maksullista sähköä avuksi!!
 
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: tengu - 07.10.18 - klo:22:17
Samaa sanon että Googlella vähän tutustuu ssr ja sen ohjaus ac lle. Jos ajaa pwm signaalia suoraan ssr:ään niin kaipa tuo jotenkin toimii mutta riippuen ssrn tyypistä ulos tuleva teho voi olla kovin satunnaista. Siksi esim mk2 ssa on zero point crossing mittaus että ohjaus signaalin ajoitus osuu oikein ac taajuuteen. Jos et ole varma niin en suosittele kytkemään kilowattiluokan tehoja testailuun...
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 08.10.18 - klo:02:14
Samaa sanon että Googlella vähän tutustuu ssr ja sen ohjaus ac lle. Jos ajaa pwm signaalia suoraan ssr:ään niin kaipa tuo jotenkin toimii mutta riippuen ssrn tyypistä ulos tuleva teho voi olla kovin satunnaista. Siksi esim mk2 ssa on zero point crossing mittaus että ohjaus signaalin ajoitus osuu oikein ac taajuuteen. Jos et ole varma niin en suosittele kytkemään kilowattiluokan tehoja testailuun...
Minulla taisi olla tuossa edellisessä tehonsäätö kysymyksessä ajatusvirhe.
Laskutushan toimii kulutetun energian mukaan eikä hetkellisen tehon ja mittausjakso on vissiinkin 1 tunti.
Eli 1000w vastuksella päästään 500w kulutukseen vaikka siten että vastus on kytkettynä 1 sek ja pois 1 sek.
Onkohan tuo ajatus nyt oiken?
Kun käytetään tuota nolla piste ssr:ää niin ohjaus voidaan tehdä pulssisuhdetta muuttamalla ja pwm ei tarvita?
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 08.10.18 - klo:06:20
Ja taas tuli virhe. pwm onkin juuri sitä pulssinleveysmodulaatiota!

Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: tengu - 08.10.18 - klo:08:27
Sähkömittari toimii niin että 1000 pulssia per kWh. Eli jos 1000w kuorma tunnin niin joka 3.6sekuntti mittari laskee pulssin. Aina kun Pulssi on vilahtanut niin se on kulutus rekisterissä ja sitä ei saa enää pois.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 10.10.18 - klo:09:35
Kun nyt sitten ssr:llä ohjataa sitä 1000w vastusta osateholla esim. 100w niin kuinka pitkä ajallisesti yksi säätöjakso tulisi olla?
Jos jakso olisi vaikka 10 sekunttia niin ymmärtääkseni tuohon haluttuun tehoon päästään 9s pois ja 1s päällä.
Vai täytyisikö sen jakso jostain syystä olla lyhyenpi?
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: tengu - 10.10.18 - klo:18:54
Kun nyt sitten ssr:llä ohjataa sitä 1000w vastusta osateholla esim. 100w niin kuinka pitkä ajallisesti yksi säätöjakso tulisi olla?
Jos jakso olisi vaikka 10 sekunttia niin ymmärtääkseni tuohon haluttuun tehoon päästään 9s pois ja 1s päällä.
Vai täytyisikö sen jakso jostain syystä olla lyhyenpi?

Ja mitenkäs ajat sitä vastusta 1/10 teholla? Triacciahan käytetään himmentimissä esim ja jossain muistan nähneeni jopa kWh luokan himmentimiä. Miten sitä ssr:ää nyt olet ajatellut ohjata? pelkällä pwm:llä voit saada vähän satunnaisen kuormituksen.  Tässä tapauksessa mitä tarkoitat 10 sekunnin jaksolla? Jos ajattelet että se sähkömittari laskee 1kWn kuormalla noin 3.6 sekunttia ja pulssi. Lisäksi jos sattuu samalle vaiheelle kahvinkeitin ja mikro vaikka niin äkkiä se 2000w menee tovin. Tällöin alta 2s ja pulssi. Kyllä mittaus ja säätö pitää toimia ihan reaaliajassa jos haluaa kulutuksen kompensoida mahdollisimman tehokkaasti.



Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 10.10.18 - klo:21:25
Kun nyt sitten ssr:llä ohjataa sitä 1000w vastusta osateholla esim. 100w niin kuinka pitkä ajallisesti yksi säätöjakso tulisi olla?
Jos jakso olisi vaikka 10 sekunttia niin ymmärtääkseni tuohon haluttuun tehoon päästään 9s pois ja 1s päällä.
Vai täytyisikö sen jakso jostain syystä olla lyhyenpi?

Ja mitenkäs ajat sitä vastusta 1/10 teholla? Triacciahan käytetään himmentimissä esim ja jossain muistan nähneeni jopa kWh luokan himmentimiä. Miten sitä ssr:ää nyt olet ajatellut ohjata? pelkällä pwm:llä voit saada vähän satunnaisen kuormituksen.  Tässä tapauksessa mitä tarkoitat 10 sekunnin jaksolla? Jos ajattelet että se sähkömittari laskee 1kWn kuormalla noin 3.6 sekunttia ja pulssi. Lisäksi jos sattuu samalle vaiheelle kahvinkeitin ja mikro vaikka niin äkkiä se 2000w menee tovin. Tällöin alta 2s ja pulssi. Kyllä mittaus ja säätö pitää toimia ihan reaaliajassa jos haluaa kulutuksen kompensoida mahdollisimman tehokkaasti.

No siksi kysyin kun en oikein tiedä. Tuo esimerkkini tuotanee lämpötehoa sen 1/10 osan mutta sen soveltuvuus laskutuksen kannalta ei sitten kai toimikkaan.
Kuitenkin aurinkojärjestelmissä käytetään ssr:ää. Voisiko joku vähän selvittää että miten se on mahdollista.

ssr:llä lyhin mahdollinen päälläoloaika lienee 50hz tapauksessa 10ms .
Omassa esimerkissä 10 sekunnin jakso tarkoitti sitä että vastus on kytkettynä 1s ja pois 9s ja sitä toistettaan niin kauan kunnes halutaan muttaa tuota nimellistä tehoa.

Toimisiko tuo jos säätöjakso olisi alle 3,6s? Eli mitä reaaliaika tarkoittaa tässä tapauksessa?
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: tengu - 10.10.18 - klo:23:02
ssr toimii siis ihan ok tuossa vaan ongelmana on enempi sen ohjaus.

Periaatteessa yksi tapa jotenkin näin sinne päin:
CT anturi keskuksessa mittaa kuormitettavaa vaihetta. Kun virtaa alkaa mennä ulos aletaan ajamaan ssr:ää esim joka 100:s puolijakso ja tätä nostetaan kunnes virran suunta keskuksessa muuttuu. Kun virta alkaa uudestaan mennä kulutukselle vähennetään taas puolijaksoja kunnes virta alkaa liikkua ulos. Taas lisätään puolijaksoja jne jne. Toki voidaan käyttää myös sitä vaihekulmasiirtoa eli ajetaan vaan x osa joka puolijaksosta vastukselle ja sitä säädetään tehon mukaan. Näin nuo himmentimet isosti toimivat.
Tämä tarkoittaa että tarvitsee ajoituksen ohjaukselle, mikä kertoo tuon zero point crossinging eli koska puolijakso alkaa. Tämän perusteella ohjauspulssin ajoitus taas onnistuisi oikein.

Jos olisi tasavirtaa niin läjä konkkia ja pwm:llä vaan suoraan vastukselle. 
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: VesA - 11.10.18 - klo:00:53
ssr toimii siis ihan ok tuossa vaan ongelmana on enempi sen ohjaus.

Periaatteessa yksi tapa jotenkin näin sinne päin:
CT anturi keskuksessa mittaa kuormitettavaa vaihetta. Kun virtaa alkaa mennä ulos aletaan ajamaan ssr:ää esim joka 100:s puolijakso ja tätä nostetaan kunnes virran suunta keskuksessa muuttuu. Kun virta alkaa uudestaan mennä kulutukselle vähennetään taas puolijaksoja kunnes virta alkaa liikkua ulos. Taas lisätään puolijaksoja jne jne. Toki voidaan käyttää myös sitä vaihekulmasiirtoa eli ajetaan vaan x osa joka puolijaksosta vastukselle ja sitä säädetään tehon mukaan. Näin nuo himmentimet isosti toimivat.
Tämä tarkoittaa että tarvitsee ajoituksen ohjaukselle, mikä kertoo tuon zero point crossinging eli koska puolijakso alkaa. Tämän perusteella ohjauspulssin ajoitus taas onnistuisi oikein.

Jos olisi tasavirtaa niin läjä konkkia ja pwm:llä vaan suoraan vastukselle.

Tässä lasketaan aika paljon sen varaan, että kWh-mittari mittaa tuolla tavalla käpistellyn sähkön ns oikein - edes tilastollisesti. Niiden ei kuitenkaan speksin puolesta tarvitse mitata oikein kuin suunnilleen siistiä siniaaltoa resistiiviseen kuormaan - eli virran ja jännitteen samplaus saa olla melko lepsua ja harvaa - erilaisissa demoissa mittarit onkin saatu aika helposti näyttämään pahasti pieleen. Niinpä tätäkin puolta pitäisi vähän koittaa seurailla - ja taatusti tämäkin riippuu mittarin merkistä..
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 11.10.18 - klo:07:49
ssr toimii siis ihan ok tuossa vaan ongelmana on enempi sen ohjaus.

Periaatteessa yksi tapa jotenkin näin sinne päin:
CT anturi keskuksessa mittaa kuormitettavaa vaihetta. Kun virtaa alkaa mennä ulos aletaan ajamaan ssr:ää esim joka 100:s puolijakso ja tätä nostetaan kunnes virran suunta keskuksessa muuttuu. Kun virta alkaa uudestaan mennä kulutukselle vähennetään taas puolijaksoja kunnes virta alkaa liikkua ulos. Taas lisätään puolijaksoja jne jne. Toki voidaan käyttää myös sitä vaihekulmasiirtoa eli ajetaan vaan x osa joka puolijaksosta vastukselle ja sitä säädetään tehon mukaan. Näin nuo himmentimet isosti toimivat.
Tämä tarkoittaa että tarvitsee ajoituksen ohjaukselle, mikä kertoo tuon zero point crossinging eli koska puolijakso alkaa. Tämän perusteella ohjauspulssin ajoitus taas onnistuisi oikein.

Jos olisi tasavirtaa niin läjä konkkia ja pwm:llä vaan suoraan vastukselle.

Kysymyshän on ollut kokoajan vain varaajan tehonsäädöstä.
Jokaiseen vaiheeseen on kytketty 1000w vastus johon mahdollista PV:n tuottamaa ylimääräistä energiaa ajetaan.
Sen mittaus kuinka paljon ja milloin on minulla vielä kokonaan tutkimatta.
Tiedossa on nyt vain invertterin ilmoitus sen hetkisestä tehosta.

SSR tietääkseni kytkeytyy päälle ja pois aina vain nollakohdassa joten sitä ei tarvitse erikseen mitata.
Voisiko siten pwm säätö olla seuraavanlainen :
säätöjakson pituus 1000ms (50hz = 20ms yksi siniaalto)
pwm pulssia säätämällä saadaa 51 eri porrasta (0 - 50 siniaaltoa ei puoliaaltoa)

Tätä systeemä sitten testaisin aluksi ihan käsisäädöllä, raspberry tekee sen pwm pulssin.

Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: unga - 11.10.18 - klo:13:24
Hei, keskustelu on mielenkiintoinen, vaikka menee minulta osin yli hilseen. Eikö tämä ole valmis ratkaisu: immersun.uk ? Tällä foorumillakin  on ollut aiemmin juttua tuosta. Ei tietenkään ole diy ratkaisu.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: tengu - 11.10.18 - klo:17:29

Tässä lasketaan aika paljon sen varaan, että kWh-mittari mittaa tuolla tavalla käpistellyn sähkön ns oikein - edes tilastollisesti. Niiden ei kuitenkaan speksin puolesta tarvitse mitata oikein kuin suunnilleen siistiä siniaaltoa resistiiviseen kuormaan - eli virran ja jännitteen samplaus saa olla melko lepsua ja harvaa - erilaisissa demoissa mittarit onkin saatu aika helposti näyttämään pahasti pieleen. Niinpä tätäkin puolta pitäisi vähän koittaa seurailla - ja taatusti tämäkin riippuu mittarin merkistä..

Oma mk2routeri on aika hyvin pitänyt kutinsa. Jos vertaan Carunan seurantaa ja omaa vattenfallilta hommaamaa energywatchia (se mikä laskee niitä pulsseja mittarin silmästä) niin ero on 0.01 kWh luokkaa. Aika hyvin pitää mittarin nollissa aurinkoisena päivänä, kun ketään ei kotona( lukema siinä 0.01 -0.02 kWh).

SSR tietääkseni kytkeytyy päälle ja pois aina vain nollakohdassa joten sitä ei tarvitse erikseen mitata.
Voisiko siten pwm säätö olla seuraavanlainen :
säätöjakson pituus 1000ms (50hz = 20ms yksi siniaalto)
pwm pulssia säätämällä saadaa 51 eri porrasta (0 - 50 siniaaltoa ei puoliaaltoa)

Tätä systeemä sitten testaisin aluksi ihan käsisäädöllä, raspberry tekee sen pwm pulssin.



Triac kytkeytyy päälle ihan missä kohdassa puolijaksoa vain mutta ei katkea ennen kuin 0 ylitetään. Tämän takia jos ohjaat sitä ihan sokkona pwm:llä niin pulssien mitat voi olla ihan satunnaisia riippuen ihan mihin kohtaan ohjauspulssi sattuu osumaan. Ei muuta kun testailemaan niin selviää.Pientä varovaisuutta vaan mukaan jos kilowattien tehoilla testailet...

 
Hei, keskustelu on mielenkiintoinen, vaikka menee minulta osin yli hilseen. Eikö tämä ole valmis ratkaisu: immersun.uk ? Tällä foorumillakin  on ollut aiemmin juttua tuosta. Ei tietenkään ole diy ratkaisu.


On noita engelsmanneilla monia valmistajia. Tekee saman kun mk2pvrouter ja toinen foorumilla mainittu wattrouter.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 11.10.18 - klo:19:14
Triac kytkeytyy päälle ihan missä kohdassa puolijaksoa vain mutta ei katkea ennen kuin 0 ylitetään. Tämän takia jos ohjaat sitä ihan sokkona pwm:llä niin pulssien mitat voi olla ihan satunnaisia riippuen ihan mihin kohtaan ohjauspulssi sattuu osumaan. Ei muuta kun testailemaan niin selviää.Pientä varovaisuutta vaan mukaan jos kilowattien tehoilla testailet...

Luulin kyllä tilanneeni sellaisen SSR:n jossa on Zero Cross Trigger
FOTEK SSR-10DA
Saapa sitten nähdä miten on.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: tengu - 11.10.18 - klo:19:41

Luulin kyllä tilanneeni sellaisen SSR:n jossa on Zero Cross Trigger
FOTEK SSR-10DA
Saapa sitten nähdä miten on.

No niimpä tuon spekseissä lukee. Tuo helpottaa hommaa tässä kohtaa isosti. Pistä kirjoitellen tänne testien tuloksia.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: jolla - 11.10.18 - klo:20:33
Triac kytkeytyy päälle ihan missä kohdassa puolijaksoa vain mutta ei katkea ennen kuin 0 ylitetään. Tämän takia jos ohjaat sitä ihan sokkona pwm:llä niin pulssien mitat voi olla ihan satunnaisia riippuen ihan mihin kohtaan ohjauspulssi sattuu osumaan. Ei muuta kun testailemaan niin selviää.Pientä varovaisuutta vaan mukaan jos kilowattien tehoilla testailet...

Luulin kyllä tilanneeni sellaisen SSR:n jossa on Zero Cross Trigger
FOTEK SSR-10DA
Saapa sitten nähdä miten on.

minulla on noita kymmenkunta käytössä, 25, 40 versioina myös...tähän mennessä toimineet moitteetta pwm' ällä sekä kytkiminä
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: mktutsi - 16.10.18 - klo:10:46
Pieni varoituksen sana, myöhempien pettymysten hillitsemiseksi.

Ainakaan omaani en saanut toimimaan SSR zero corssing releillä. Tai siis joo toimii, mutta sähkömittari (Landis Gyr E350) ei tykännyt. Eli kannattaa suhtautua pienellä varauksella tuohon "bucket" periaatteeseen. Testailin 1Wh (1000 pulssia) ja 0,1Wh (10 000 pulssia) koodeilla ja kummallakaan sähkömittari ei yrittänytkään lähelle nollaa. Eli ainakin oma sähkömittarini laskutti ihan samalla lailla oli säätö loopin kierto aika 10sekuntia tai 0,3sekuntia.

Nyt triacit-himmentimet joilla tuotannon ja kulutuksen tasaaminen onnistuu nollaan.

Tuolla on samanlaisia näkemyksiä:
https://forums.whirlpool.net.au/archive/2467104 (https://forums.whirlpool.net.au/archive/2467104)

"Electronic meters (which includes Smart Meters) do perform sampling at a high rate, but the actual energy flow is integrated over a half cycle (10 millisecs). So you can effectively use triac switching for balancing import / export flow over a sub-half cycle, but it will not work for time periods greater than that (ie. cycle-by-cycle switching)"
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 31.10.18 - klo:09:15
Nyt olen saanut oman LVV tehonsäätö systeemin toimimaan.

Mittari LandisGyr E450
SSR    Zero Cross Trigger Method
raspberry pi tuottaa pwm signaalin halutun tehon mukaan.

Säätö tapahtuu vaihekohtaisesti.
Tehonsäätö katkomis menetelmällä toimii ihan hyvin kun on kyse vain verkosta tulevasta sähköstä.
Ja toimiihan se silloinkin kun sähköä tulee sekä verkosta että paneeleista.

Mutta miten sähkönmittari selviää tapauksesta kun sähköa tulee sekä verkosta että paneeleista?
Onko kenelläkään tietoa asiasta?
Olen yrittänyt selvittää sitä mittarin dokumentista, luulen että toimii mutta en ole varma
koska selitys on niin tekninen etten sitä oikein ymmärrä.
Koska katkomis systeemissä virta voi kulkee sekä sisään että ulos ja mittarin tulisi osata laskea
summatieto kumpaan suuntaan sitä nyt oikeasti menee.

Minulla ei ole vielä kaikkia mahdollisesti tarvittavia mittauksia.
Sähkölaitoksen sivulta saan kulutuksen ja myyntiin menneen sähkön tunnin tarkuudella
mutta vuorokauden viiveellä.

Invertteristä saan tuotetun sähkön tiedot reaaliaikaisesti.
Tätä tietoa käytän nyt LVV tehonsäätöön. vaihekohtainen teho - oletettu peruskuorma.
Ei tarkka mutta jotain sentään!
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: kotte - 31.10.18 - klo:12:40
Säätö tapahtuu vaihekohtaisesti.
Tehonsäätö katkomis menetelmällä toimii ihan hyvin kun on kyse vain verkosta tulevasta sähköstä.
Ja toimiihan se silloinkin kun sähköä tulee sekä verkosta että paneeleista.

Mutta miten sähkönmittari selviää tapauksesta kun sähköa tulee sekä verkosta että paneeleista?
Eikös tuossa vaihenetotus-säikeessä viitattu ihan kokemuspohjaankin, eli zero-crossing-tyyppinen katkonta ei toimi toivotulla tavalla (eikä itse asiassa auta asiaa yhtään). Alan standardien mukaan toimiva sähkömittari osaa suurinpiirtein integroida kunkin puolivaiheen aikana tapahtuneen kulutuksen ja tuoton. Jos kulutuslaitteen tehoa säätää nollapistekytkennällä, on lopputulos +-0 tavoitteen kannalta.

Pitäisi käyttää vaihekulmasäätöä, jotta päästään puolijakson sisälle. Puolijaksosäätimet ovat niin runsaasti käytössä erilaisten kotilatalouskoneiden, valaisinten ja sähkötyökalujen säädössä, että sähkömittaristandardien on pakko osata mitata kulutus suurinpiirtein oikein noita käytettäessäkin. Toki tällöinkin verkkoinvertteri syöttää puolijakson alkuvaiheen aikana tehoa verkkoon ja imee sitä takaisin puolijakson lopulla, mutta mittarin on osattava mitata oikein tässäkin tilanteessa, sillä vaihtovirtasähkömoottorit (jollaisia suurehkoja on kotitalouskoneissa, kiinteistötekniikassa ja ON/OFF-lämpöpumpuissa esimerkiksi) tekevät aivan samaa. Jokin sähkömittarin loistehovalo saattaa samalla vilkkua, mutta kotitalouksien ei tarvitse maksaa loistehosta eikä loistehoa ole sen takia pakko kompensoida (säädettävillä kondensaattoroiparistoilla esimerkiksi).
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 31.10.18 - klo:13:59
Siispä tuo säätö on ajateltava vielä uudelleen. Onneksi ei ole kiirettä kun tähänaikaan vuodesta ei ole juuri mitä säätäisi.
Onko olemassa sellaisia SSR releitä tai ohjauspiirejä jotka helposti osaavat mennä "vaiheen sisälle"?
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: mktutsi - 31.10.18 - klo:15:05
Nyt olen saanut oman LVV tehonsäätö systeemin toimimaan.


Mutta miten sähkönmittari selviää tapauksesta kun sähköa tulee sekä verkosta että paneeleista?
Onko kenelläkään tietoa asiasta?
Olen yrittänyt selvittää sitä mittarin dokumentista, luulen että toimii mutta en ole varma
koska selitys on niin tekninen etten sitä oikein ymmärrä.
Koska katkomis systeemissä virta voi kulkee sekä sisään että ulos ja mittarin tulisi osata laskea
summatieto kumpaan suuntaan sitä nyt oikeasti menee.


Nyt on epävarmoja kommentteja, mutta kirjottelenpa kuitenki. Korjatkaa jos tulee puuta-heinää.

Vastaus kai riippuu mittarin asetuksista. Niin kuin netotus keskustelussa on jo sivuttu. Eli jos verkkoyhtiö on valinnut mittariin netottavan softan niin, pystyt noilla zero crossing releillä homman hoitamaan, ja säätöväli voi olla esim kymmeniä sekunteja.

Todennäköisempää on että mittarissa on ei netottava softa. Ja uusi mittari, niin todennäköisesti myös integroi puolivaihe kerrallaan, niinkuin tuossa aiemmin joku jo sanoikin. Taisi olla netotus ketju missä tätä mittaus asiaa käytiin jo läpi.

Mittarissa on kuusi muistirekisteriä, kaksi jokaiselle vaiheelle. Kunkin vaiheen, kunkin puolijakson keskimääräinen kulutus/tuotanto tallenetaan näihin reksitereihin. Jos puolijakson  keskiarvo oli kulutuksella niin tallenetaan ko. +rekisteriin ja jos se oli tuotannolla niin tallennetaan ko. - rekisteriin. Ja sitten verkkoyhtiö summaa ja keskiarvottaa näiden reskisterien arvot laskutukseen tunti kerrallaan..

Eli jos ajaa paneelien tuotannon perusteella vaikka 25% pulssisuhteella. yksi puolijakso oli kulutuksella ja kolme puolijaksoa tuotannolla. Niin laskulle nämä menee suoraan 1 yksikkö (vastuksenteho-sen vaiheen teho) kulutusta ja 3 yksikköä tuotantoa (vaihe kohtainen paneeliteho). Eli tämän tyyppisellä mittarilla ja Zero crossing releillä säädetyllä pulssisuhteella ei koskaan päästä nolla kulutukseen, vaan aina kertyy sekä tuotantoa että kulutusta.  Ärsyttävää....tiedän. Been there done that.

Jos systeemissä on jo älyä ja mittarointi ja logiikka on olemassa, niin ehkä suoraviivaisin tapa olisi korvata zerocrossing releet valmiilla dimmerillä? Esim. https://www.ebay.co.uk/itm/Digital-Dimmer-Module-AC-Dimmer-For-Arudino-Raspberry-PI-110-220V-16-Level-SSR/173326390694?hash=item285b0ed5a6:g:K4AAAOSw7UJbALfc:rk:1:pf:0 (https://www.ebay.co.uk/itm/Digital-Dimmer-Module-AC-Dimmer-For-Arudino-Raspberry-PI-110-220V-16-Level-SSR/173326390694?hash=item285b0ed5a6:g:K4AAAOSw7UJbALfc:rk:1:pf:0).

Sen verran isoja tehoja, että riskinä on välkyntää ja muita häiriöitä. Tai ainkin sellaisista noi viisaammat varottelee.

Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 31.10.18 - klo:16:42
Tuo dimmer vaikuttaisi olevan juuri se joka sopisi minun tarkoitukseeni.
Katselin vain eBay:n kuvasta että miten tuo voi kestää 1kw tehon virtaa kuumenematta liikaa, ei oiken  mitään jäähdytystä?
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: kotte - 01.11.18 - klo:13:12
Vastaus kai riippuu mittarin asetuksista. Niin kuin netotus keskustelussa on jo sivuttu. Eli jos verkkoyhtiö on valinnut mittariin netottavan softan niin, pystyt noilla zero crossing releillä homman hoitamaan, ja säätöväli voi olla esim kymmeniä sekunteja.
Puhun nyt asiasta, jonka yksityiskohtia en tiedä, mutta suhtaudun suurella varauksella väitteeseen, että ns. netottava mittariohjelmisto laskisi keskiarvoja kulutuksesta tai kulutuksen suunnasta tavalla, joka eroaa yhtään siitä, miten ns. ei-netottava ohjelmisto tekee. Eli jos kulutusta on yhden puolijakson aikana ja tuottoa toisen aikana (yhdestä vaiheesta mitattuna), nuo todellakin lasketaan kulutukseksi ja tuotoksi.

Sen sijaan siinä on eroa, että netottava mittari laskee ensin kunkin vaiheen tuotot ja kulutukset yhteen ja vasta sen jälkeen päättelee, ollaanko tuoton vain kulutuksen puolella ja kasvattaa sen perusteella jomman kumman energialaskurin lukemaa. Ei-netottava mittari taas päättelee kustakin vaiheesta erikseen, ollaanko tuoton vai kulutuksen puolella ja lisää sitten päätöksen perusteella lukeman jompaan kumpaan. Uskoakseni tuotto ja kulutus rekisteröidään auttamatta erikseen myös netottavalla mittarilla ainakin, jos yhdestä vaiheesta otettu energiamäärä syötetään toiseen vaiheeseen yhden vaihtovirran jakson ylittävän ajan kuluttua (eli kahden puolijakson viiveellä), mutta voi sallittu maksimiviive olla tuota lyhyempikin (siis puolijakson luokkaa).
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: kotte - 01.11.18 - klo:13:38
Tuo dimmer vaikuttaisi olevan juuri se joka sopisi minun tarkoitukseeni.
Katselin vain eBay:n kuvasta että miten tuo voi kestää 1kw tehon virtaa kuumenematta liikaa, ei oiken  mitään jäähdytystä?
Jos tuo kestää 12A / 220V (mikä muuten ei periaatteessa ihan riitä Suomessa jännitteen osalta), niin laitehan pystyy ohjaamaan tehoa yli 2,6kW:n edestä. Jos virta on 12A ja kyseessä olevan ohjauskomponentin jännitehäviöksi oletaan n. 1,5V, jää hukkatehon tuotoksi alle 20W, mutta jonkinlaisen kunnollisen jäähdytyssiilin tuo silti vaatisi. Taitaa tuo 12A olla venttiilikomponentin maksimivirta ja ongelmia tulee alta aikayksikön, jos yrittää ohjata enemmän kuin muutaman sadan watin kulutuslaitetta. Tuollaisia tehojahan valokytkimen paikalla tarkoitetut vastaavantasoisesti jäähdytetyt himmenninkojeet tyypillisesti korkeintaan kestävät.

Tuolta linkin sivulta muuten löytyy linkki dokumenttiin, jossa on useampikanavaisiakin vaihekulmasäätimiä. Noissa näkyy jo olevan ihan asiallisia jäähdytyssiilejä.

Toisaalta vastaavista vaihekulmasäätimistä on paljonkin valmista tarjontaa erilaisilla ohjaustavoilla, niin analogisilla kuin digitaalisillakin.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 02.11.18 - klo:11:44
Jollalle kysymys.
Aikaisemmista viesteistäsi ja "korsteeni" kuvista päättelin että sinulla on säädössä SSR.
Kun nyt täällä ollaan sitämieltä että se ei oikein toimi niin miten sinulla toimii?
Vai olenko käsittänyt väärin?
Jotenkin tuo tehon ohjaaminen ssr/pwm tuntuu "tyylikkäämmältä"!
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: jolla - 02.11.18 - klo:14:19
Jollalle kysymys.
Aikaisemmista viesteistäsi ja "korsteeni" kuvista päättelin että sinulla on säädössä SSR.
Kun nyt täällä ollaan sitämieltä että se ei oikein toimi niin miten sinulla toimii?
Vai olenko käsittänyt väärin?
Jotenkin tuo tehon ohjaaminen ssr/pwm tuntuu "tyylikkäämmältä"!

kyllä se toimii SSR/pwm, ongelmia oli saada tarpeeksi stabilia ja luotettavaa ohjausdataa ja yli 2kW alkoivat tuottaa ongelmia kuten myös tällä mk2pv'llä mikä nyt on käytössä
ongelma ratkesi toisella arduinolla mikä ei tee muuta kun kytkee SSR kanssa lisäkuormaa kiinetästi tarvittaessa, uskoisin että ssr/pwm toimisi myös tällä logiikalla

nyt on käytössä linkin http://www.elisanet.fi/korsteeni/mk2pv.shtml toiseksi alimman kuvan mukainen kytkentä millä toimii moitteetta 1,6kW vastuksen kanssa ja lisäkuormilla (se toinen arduino) 7kW saakka on toimiminut saumattomasti

pwm'ällä eikä pulssilla yli 2kW kuomilla ei saa toimimaan näillä linjoilla tässä taloudessa

ihan rautalankana
- kun tuotto ( panelien tuotto - kulutus) on 0-1,6 kW mk2pv hoitaa säädön 1,6kw vastuksella
- yli 1,6kW toinen arduino kytkee 1,6 kw vastuksen kiinteästi
- yli 3,2 kw kytkee 2,5kw ja 1,6kW irti
- jne

Koodia: [Valitse]
// EmonLibrary examples openenergymonitor.org, Licence GNU GPL V3

#include "EmonLib.h"             // Include Emon Library
EnergyMonitor emon1;             // Create an instance
int upPin7 = 7;
int upPin8 = 8;
int upPin9 = 9;

void setup()
{
  pinMode(upPin7,OUTPUT);
  pinMode(upPin8,OUTPUT);
  pinMode(upPin9,OUTPUT); 
  Serial.begin(9600);
 
  emon1.voltage(2, 150, 1.7);  // Voltage: input pin, calibration, phase_shift
  emon1.current(1, 12.7);       // Current: input pin, calibration.
}

void loop()
{
  emon1.calcVI(20,2000);         // Calculate all. No.of half wavelengths (crossings), time-out
  emon1.serialprint();           // Print out all variables (realpower, apparent power, Vrms, Irms, power factor)
 
  float realPower       = emon1.realPower;        //extract Real Power into variable
  float apparentPower   = emon1.apparentPower;    //extract Apparent Power into variable
  float powerFActor     = emon1.powerFactor;      //extract Power Factor into Variable
  float supplyVoltage   = emon1.Vrms;             //extract Vrms into Variable
  float Irms            = emon1.Irms;             //extract Irms into Variable
 
    if ((realPower >= 1600) && (realPower < 3200)) //170W tullut yli 28 p�iv�n�
    {
    digitalWrite(upPin7, HIGH);
    digitalWrite(upPin8, LOW);
    digitalWrite(upPin9, LOW);
    }
    else if ((realPower >= 3200) && (realPower < 4100))
    {
    digitalWrite(upPin8, HIGH);
    digitalWrite(upPin7, LOW);
    digitalWrite(upPin9, LOW);
    }
    else if ((realPower >= 4100) && (realPower < 5400))
    {
    digitalWrite(upPin8, HIGH);
    digitalWrite(upPin7, HIGH);
    digitalWrite(upPin9, LOW);
    }
    else if ((realPower >= 5400) && (realPower < 8200))
    {
    digitalWrite(upPin8, HIGH);
    digitalWrite(upPin9, HIGH);
    digitalWrite(upPin7, LOW);
    }
    else
    {
    digitalWrite(upPin7, LOW);
    digitalWrite(upPin8, LOW);
    digitalWrite(upPin9, LOW);
    } 
}


käytössä oleva mk2pv koodi

Koodia: [Valitse]
// Mk2a is a revised version of my stand-alone sketch for diverting suplus
// PV power to a dump load using a triac.  The original Mk2 version, which includes
// more explanation and 'debug' code to support off-line working, may be found at
// http://openenergymonitor.org/emon/node/841
//
// General aspects of Mk2a:
// The Mk2a code is suitable for hardware that has multiple voltage references, such
// as emonTx.  Mk2a uses integer maths for improved speed.  It also uses low-level
// instructions for ADC operations which 'frees up' time that was previously unavailable
// for general processing activities.  Further information about this enhancement may be
// found immediately before loop().
//
// Specific releases of Mk2a:
// The initial release of Mk2a had twin high-pass filters, as used in the standard OEM
// V&I sketch.  Due to a couple of minor bugs, it was soon replaced by the _rev2 version.
//
// The _rev3 version marks a further change to the way that the raw sample streams are
// processed.  This has come about because, for the purpose of calculating "real power",
// there is no need for DC offset to be pre-removed from the raw current samples. The
// standard calculation for real power does this automatically when applied over each whole
// cycle of the mains.  Half-cycle processing of power has been discontinued.
//   A single LPF, which is updated just once per mains cycle, has been introduced for
// the purpose of determining the DC offset of the voltage waveform.  This value is then
// subtracted from each raw voltage sample.  A nominal value of 512 is subtracted from
// each current sample, this being to prevent the system becoming over-sensitive to any
// imbalance conditions or random noise; the actual value is unimportant.
//
// The ANTI_FLICKER option was also introduced in _rev3.  This mode uses two thresholds
// for the energy bucket rather than just one.  When surplus power is available,
// the power-diversion logic operates the triac between these two limits on a hysteresis
// basis.  To ensure that the anti-flicker requirement is always met, a minimum amount of
// time has to elapse between consecutive activations of the triac.  Under certain
// conditions, this may cause a small amount of surplus power to be lost when the bucket
// overflows.  The on-board LED (pin 13) shows whenever then this occurs. Accurate
// calibration of the system is essential when operating in this mode.
// 
// TALLYMODE is a #define option which allows energy data to be collected for
// subsequent display.  In _rev2, energy values in positive and negative half-cycles was
// recorded separately.  From _rev3 onwards, energy is recorded for whole cycles only.
//   While running in TALLYMODE, the code is fully functional.  It pauses after a
// user-selectable period so that stored data can be retrieved.  To avoid overflow, the
// maximum recommended duration is 10 minutes.  To start again, press the 'g' key, then
// carriage-return.
//   TALLYMODE provides a very easy way to calibrate the system.  Clip the CT around
// one core of a cable that supplies a known load, and do a short run with appropriate
// Min and Max values.  If the peak distribution (in Watts) is not where you expect it
// to be, then just change the value of powerCal until it is. 
//   Full details about calibration are provided just before setup().
//
// SPEEDCHECK is another #define option.  When #included, the results of a built-in
// checker facility are displayed.  This facility keeps track of the number of times
// that general processing fails to complete within the duration of the associated
// ADC conversion.  SPEEDCHECK may be left on permanently, if desired.
//   If additional workload is ever to be added, SPEEDCHECK will provide a sensitive
// indication of any undesirable effect on the underlying code.  Any value other than
// zero will reduce the accuracy of power/energy calculations.
//
// Mk2a_rev3a.  This corrects a minor but long-standing error in the data produced by
// Tallymode.  Tallymode data is now displayed in Watts, rather than in Tally numbers.
//
//                  Robin Emley (calypso_rae on Open Energy Monitor Forum)
//                  June 2013


/*
Circuit for monitoring pulses from a supply meter using checkLedStatus():
 
                  ----------------> +5V
                  |
                  /
                  \ 8K2
                  /
                  |
             ---------------------> dig 2
             |       |
        -->  /       |
        -->  \       _
        LDR  /       -  0.01uF
             |       |
             ----------------------> GND
*/

// There are two #define options which may be activiated independently
//
//#define TALLYMODE // for recording energy data.  Comment out for normal operation
//#define SPEEDCHECK // to display the results of a built-in checker every few seconds

enum operatingModes {NORMAL, ANTI_FLICKER};
enum operatingModes operatingMode = NORMAL; // <-- select the desired mode here

#define CYCLES_PER_SECOND 50
#define JOULES_PER_WATT_HOUR 3600 // 0.001 kWh = 3600 Joules
enum polarities {NEGATIVE, POSITIVE};
enum triacStates {ON, OFF}; // the external trigger device is active low

// general global variables
const byte outputPinForLed = 13;  // digital
const byte outputPinForTrigger = 9; // digital
const byte ledDetectorPin = 2;  // digital
const byte ledRepeaterPin = 10;  // digital
const byte voltageSensorPin = 2;  // analogue
const byte currentSensorPin = 1;   // analogue
const byte startUpPeriod = 5; // in seconds, to allow HP filters to settle
const int DCoffset_I = 512; // for calculating "real power", a nominal value is fine

long cycleCount = 0;
long cycleCountAtLastActivation = 0;
int samplesDuringThisCycle;
enum triacStates nextStateOfTriac;
enum triacStates triacState;
boolean triggerNeedsToBeArmed;
boolean beyondStartUpPhase = false;
float safetyMargin_WattsPerHalfCycle;
long triggerThreshold_long;
long energyInBucket_long = 0; // for integer maths
int phaseCal_int; // for integer maths
long capacityOfEnergyBucket_long;  // for integer maths
long energyThreshold_long;  // for integer maths
long antiFlicker_lowerEnergyThreshold;
long antiFlicker_upperEnergyThreshold;
long sumP;// for integer maths
long DCoffset_V_long = 512L * 256; // nominal mid-point value of ADC @ x256 scale
long DCoffset_V_min;
long DCoffset_V_max;

float minTimeBetweenActivations = 3; // <-- anti-flicker requirement (seconds)
int minCycleCountsBetweenActivations;

// items to allow general processing tasks to be efficiently partitioned.
boolean newHalfCycleFlag;
boolean voltageOKToArmTriggerFlag;
enum polarities polarityNow;
long instP;
long sampleVminusDC_long;

// values that need to be stored from one loop to the next
long lastSampleVminusDC_long;  //    for phaseCal algorithm
enum polarities polarityOfLastSampleV; // for zero-crossing detection
long cumVdeltasThisCycle_long;   // <<--- for LPF
int sampleV_forNextLoop; // for deferred processing
int sampleI_forNextLoop; // for deferred processing

// items for LED monitoring
byte ledState, prevLedState;
boolean ledRecentlyOnFlag = false;
unsigned long ledOnAt;
long energyInBucket_4led_long = 0;

// for the in-built mechanism to check whether the ADC conversion time is ever exceeded
boolean speedFlag;
long FlagNotClearedCounter = 0;
long loopCountForSpeedChecker = 0;
long maxLoopCountForSpeedChecker = 20000; // how often to display results (~ 4500 loops/sec)

#ifdef TALLYMODE
#define NUMBER_OF_TALLIES 100
unsigned int tally[NUMBER_OF_TALLIES + 2]; // For recording the energy content in whole mains cycles.
unsigned int tallymode_maxCycleCount;  // the cycleCount value when recording should cease
int tallymode_maxVal; // the maximum power to be recorded (Watts)
int tallymode_minVal; // the minimum power to be recorded (Watts)
//long tallymode_minVal_long; // x256 version for integer maths
float tallymode_stepVal; // the power increment between consecutive tallies (Watts)
//long tallymode_stepVal_long; // x256 version for integer maths
boolean tallymode_firstLoop = true;
unsigned int tallymode_noOfValuesTallied; // overflows after 10.9 minutes
unsigned long tallymode_noOfSamplePairs; // to show the average samples-per-mains-cycle rate
int tallymode_durationOfRecording; // in seconds
#endif

// Calibration values
//-------------------
// Three calibration values are required: powerCal, voltageCal and phaseCal.
// With most hardware, the default values are likely to work fine without
// need for change.  A full explanation of each of these values now follows:
//   
// powerCal is a floating point variable which is used for converting the
// product of voltage and current samples into Watts.
//
// The correct value of powerCal is entirely dependent on the hardware that is
// in use.  For best resolution, the hardware should be configured so that the
// voltage and current waveforms each span most of the ADC's usable range.  For
// many systems, the maximum power that will need to be measured is around 3kW.
//
// My sketch "MinAndMaxValues.ino" provides a good starting point ideal for
// system setup.  First arrange for the CT to be clipped around either core of a 
// cable which supplies a suitable load; then run the tool.  The resulting values
// should sit nicely within the range 0-1023.  To allow some room for safety,
// a margin of around 100 levels should be left at either end.  This gives a
// output range of around 800 ADC levels, which is 80% of its usable range.
//
// My sketch "RawSamplesTool.ino" provides a one-shot visual display of the
// voltage and current waveforms.  This provides an easy way for the user to be
// confident that their system has been set up correctly for the power levels
// that are to be measured.
//
// The ADC has an input range of 0-5V and an output range of 0-1023 levels.
// The purpose of each input sensor is to convert the measured parameter into a
// low-voltage signal which fits nicely within the ADC's input range.
//
// In the case of 240V mains voltage, the numerical value of the input signal
// in Volts is likely to be fairly similar to the output signal in ADC levels. 
// 240V AC has a peak-to-peak amplitude of 679V, which is not far from the ideal
// output range.  Stated more formally, the conversion rate of the overall system
// for measuring VOLTAGE is likely to be around 1 ADC-step per Volt (RMS).
//
// In the case of AC current, however, the situation is very different.  At
// mains voltage, a power of 3kW corresponds to an RMS current of 12.5A which
// has a peak-to-peak range of 35A.  This is smaller than the output signal by
// around a factor of twenty.  The conversion rate of the overall system for
// measuring CURRENT is therefore likely to be around 20 ADC-steps per Amp.
//
// When measuring power, which is what this code does, the individual
// conversion rates for voltage and current are not of importance.  It is
// only the conversion rate for POWER which is important.  This is the
// product of the individual conversion rates for voltage and current.  It
// therefore has the units of ADC-steps squared per Watt.  Most systems will
// have a power conversion rate of around 20 (ADC-steps squared per Watt), so
// is a good default value to start with.
//
// powerCal is the RECIPR0CAL of the power conversion rate.  A good value
// to start with is therefore 1/20 = 0.05 (Watts per ADC-step squared)
//
const float powerCal = 0.067;  // <---- powerCal value
 
// As mentioned above, the conversion rate for AC voltage has units of 
// ADC-steps per Volt.  Athough not required for measuring power, this
// conversion rate does need to be known in order to determine when the
// voltage level is suitable for arming the external trigger device.
//
// To determine the voltage conversion rate, note the Min and Max values that
// are seen when measuring 240Vac via the voltage sensor.  Subtract one from
// the other to find the range.  Then put that value into the voltageCal formula
// below.  voltageCal has units of ADC-steps per Volt.
//
// 679 is the peak-to-peak range of a 240V RMS signal.  The (float) typecast
// is to prevent integer rounding
//
const float voltageCal = 656 / (float)679; // <-- the first number is the output range of
                               //     your ADC when 240V AC is being measured
                       
// phaseCal is used to alter the phase of the voltage waveform relative to the
// current waveform.  The algorithm interpolates between the most recent pair
// of voltage samples according to the value of phaseCal.
//
//    With phaseCal = 1, the most recent sample is used. 
//    With phaseCal = 0, the previous sample is used
//    With phaseCal = 0.5, the mid-point (average) value in used
//
// Values ouside the 0 to 1 range involve extrapolation, rather than interpolation
// and are not recommended.  By altering the order in which V and I samples are
// taken, and for how many loops they are stored, it should always be possible to
// arrange for the optimal value of phaseCal to lie within the range 0 to 1.  When
// measuring a resistive load, the voltage and current waveforms should be perfectly
// aligned.  In this situation, the Power Factor will be 1.
//
// My sketch "PhasecalChecker.ino" provides an easy way to determine the correct
// value of phaseCal for any hardware configuration. 
//
const float  phaseCal = 1.0;


void setup()

  Serial.begin(9600);
  pinMode(outputPinForTrigger, OUTPUT); 
  pinMode(outputPinForLed, OUTPUT); 
  Serial.println();
  Serial.println("starting new run ...");
  Serial.println(); 
  Serial.print("DCoffset_V_long = "); 
  Serial.println(DCoffset_V_long); 
 
   
  // When using integer maths, calibration values that have supplied in floating point
  // form need to be rescaled. 
  //
  phaseCal_int = phaseCal * 256; // for integer maths
 
  // When using integer maths, the SIZE of the ENERGY BUCKET is altered to match the
  // voltage conversion rate that is in use.  This avoids the need to re-scale every
  // energy contribution, thus saving processing time.  To avoid integer rounding,
  // energy is also recorded at x50 scale. 
  //   This process is described in more detail in the function, processAllOtherTasks(),
  // just before the bucket is updated at the start of each new whole-cycle of the mains.
  // 
  capacityOfEnergyBucket_long = (JOULES_PER_WATT_HOUR * 50L) * (1/powerCal);
 
  Serial.print("powerCal = ");
  Serial.print(powerCal,4);
  Serial.println(" Watts per ADCstep^2");
  Serial.print("energy bucket = 3600 * 50 * (1/");
  Serial.print(powerCal,4);
  Serial.print(") = ");
  Serial.print(capacityOfEnergyBucket_long);
  Serial.println(" energy measurement units");
  Serial.println(); 
                                               
  energyThreshold_long = capacityOfEnergyBucket_long * 0.5; // for normal operation
  antiFlicker_lowerEnergyThreshold = capacityOfEnergyBucket_long * 0.1; // for anti-flicker mode
  antiFlicker_upperEnergyThreshold = capacityOfEnergyBucket_long * 0.9; // for anti-flicker mode 
  minCycleCountsBetweenActivations =
       minTimeBetweenActivations * 50; // cycleCount increments every 20mS

  if (operatingMode == NORMAL) {
    energyInBucket_long = 0.8 * energyThreshold_long; } // for faster start-up 
 
  triggerThreshold_long = 50 * 256L / voltageCal;
    // +50V is a suitable point in the rising waveform to arm the zero-crossing trigger.
    // The 256 is because filteredV is scaled at x256 when integer maths is used.
    // The reciprocal of voltageCal converts ADClevels into Volts, as described above.
   
  DCoffset_V_min = (long)(512L - 100) * 256; // mid-point of ADC minus a working margin
  DCoffset_V_max = (long)(512L + 100) * 256; // mid-point of ADC plus a working margin
}

// --------------------------------------------------------------------------------------
// Each time around loop(), a new pair of V & I samples is taken.  Rather than using the
// normal analogRead() statement, the ADC is instructed using low-level instructions. 
// By this means, the ADC's conversion time can be used to process data that was collected
// during the >>PREVIOUS<< iteration of loop(). 
//
// Thanks to the use of integer maths, general processing has been greatly speeded up.
// General processing has also been split into two sections, each of which can fit nicely
// into one of the periods while ADC conversions are taking place. The ADC pre-processor
// is now spending all of its time doing back-to-back V and I conversions, and the main
// Arduino is comfortably able to do all of its processing activities during these
// 'hidden' ADC conversion periods.  The amount of delay that can be attributed to
// general processing activities is now ...  NIL  :-)
//
// The first ADC conversion is for current, that's because the phase of this waveform is
// generally slightly advanced relative to the voltage.  While this first ADC conversion
// is taking place, all of the standard per-loop processing activities are done.
//
// The second ADC conversion is for voltage, that's because this waveform is generally
// slightly retarded relative to the current.  While this second ADC conversion is taking
// place, all of the other general processing activities are done.  This includes the
// updating of the energy bucket, which now occurs twice per mains cycle, and also the
// arming of the zero-crossing trigger.
//
// While restructuring the general processing code, some additional flags have been devised
// so that the overall workload can be partitioned more effectively.  Some variables that
// were previously defined as 'locals' within loop() have now become globals.
//
void loop()             
{
  speedFlag = true;
  ADMUX = 0x40 + currentSensorPin;
  ADCSRA |= (1<<ADSC); // instruct ADC to read the sensor for CURRENT
  {
    processPerLoopTasks(); // all general per-loop processing
    delayMicroseconds(10); // for speed checks only
  }
  while(bit_is_set(ADCSRA, ADSC)) {speedFlag = false;};  // wait for ADC to complete
  sampleI_forNextLoop = ADC;
  FlagNotClearedCounter+= speedFlag; // if the ADC conversion time has been exceeded, it's noted
 
  speedFlag = true;
  ADMUX = 0x40 + voltageSensorPin;
  ADCSRA |= (1<<ADSC); // instruct ADC to read the sensor for VOLTAGE
  {
    processAllOtherTasks(); // all other processing activities
    delayMicroseconds(10); // for speed checks only
  }
  while(bit_is_set(ADCSRA, ADSC)) {speedFlag = false;};  // wait for ADC to complete
  sampleV_forNextLoop = ADC;
  FlagNotClearedCounter+= speedFlag; // if the ADC conversion time has been exceeded, it's noted
 
#ifdef SPEEDCHECK  // this is only processed if needed
  loopCountForSpeedChecker++;
  if (loopCountForSpeedChecker == maxLoopCountForSpeedChecker)
  {
    Serial.println(FlagNotClearedCounter);
    loopCountForSpeedChecker = 0;
    FlagNotClearedCounter = 0;
  }
#endif
} // end of loop()


void processPerLoopTasks()
{
  // all tasks that are required for each loop have been grouped into this routine
#ifdef TALLYMODE
  tallymode_checks();
#endif

  int sampleI = sampleI_forNextLoop; // extract samples taken on previous loop.  This is for clarity
  int sampleV = sampleV_forNextLoop; // only; the stored values won't change during this routine.
 
  // remove DC offset from the raw voltage sample by subtracting the accurate value as determined by a LP filter.
  sampleVminusDC_long = ((long)sampleV<<8) - DCoffset_V_long;

  // remove most of the DC offset from the current sample (the precise value does not matter)
  long sampleIminusDC_long = ((long)(sampleI-DCoffset_I))<<8;
 
  // phase-shift the voltage waveform to align with the current(when a resistive load is used)
  long  phaseShiftedSampleVminusDC_long = lastSampleVminusDC_long
         + (((sampleVminusDC_long - lastSampleVminusDC_long)*phaseCal_int)>>8); 

  // determine the instantaneous power content, for use later
  long filtV_div4 = phaseShiftedSampleVminusDC_long>>2;  // reduce to 16-bits (now x64, or 2^6)
  long filtI_div4 = sampleIminusDC_long>>2; // reduce to 16-bits (now x64, or 2^6)
       instP = filtV_div4 * filtI_div4;  // 32-bits (now x4096, or 2^12)
       instP = instP>>12;     // scaling is now x1, as for Mk2 (V_ADC x I_ADC)
       
   // determine polarity, to save time later
  if(sampleVminusDC_long > 0) {
    polarityNow = POSITIVE; }
  else {
    polarityNow = NEGATIVE; }
 
   // Check for the start of a new mains cycle
  if (polarityNow != polarityOfLastSampleV) {
    newHalfCycleFlag = true; }
  else { 
    newHalfCycleFlag = false; }

  if(sampleVminusDC_long > triggerThreshold_long) {
     voltageOKToArmTriggerFlag = true; }
  else {
    voltageOKToArmTriggerFlag = false; }   
   
  // store items that need to be carried over to the next loop
//  lastSampleV = sampleV;  // required for HPF
//  lastSampleI = sampleI;  // required for HPF
//  lastFilteredV_long = filteredV_long;  // required for HPF
  lastSampleVminusDC_long = sampleVminusDC_long;  // required for phaseCal algorithm
//  lastFilteredI_long = filteredI_long;  // required for HPF
  polarityOfLastSampleV = polarityNow;  // for identification of half cycle boundaries
}


void processAllOtherTasks()
{
  if (newHalfCycleFlag == true)
  {
    if (polarityNow == POSITIVE)
    {                           
      // This is the start of a new +ve half cycle (just after the zero-crossing point)
      cycleCount++; 
      triggerNeedsToBeArmed = true;   
      // If required, this is a good place from which to call checkLedStatus()     
   
      // Calculate the real power and energy during the last whole mains cycle.
      //
      // sumP contains the product of filtered V_ADC and I_ADC samples, just as for Mk2 and
      // many other sketches.  Because only integer maths is being used for Mk2a, things have
      // to be scaled differently from this point.
      //
      // sumP contains the sum of many individual calculations of instant power.  In order
      // to obtain the average power during the relevant period, sumP must first be divided
      // by the number of samples that have contributed to its value.
      //
      // The next stage would normally be to apply a calibration factor so that real power
      // can be expressed in Watts.  That's fine for floating point maths, but it's not such
      // a good idea when integer maths is being used.  To keep the numbers large, and also
      // to save time, calibration of power is omitted at this stage.  realPower_long is
      // therefore (1/powerCal) times larger than the actual power in Watts.
      //
      long realPower_long = sumP / samplesDuringThisCycle; // proportional to Watts
   
      // Next, the energy content of this power rating needs to be determined.  Energy is
      // power divided by time, so the next step is normally to divide by the time over which
      // the power was measured.  For the _rev3 version, power is measured every whole
      // mains cycle, so that's 50 times per second.  When integer maths is being used, this
      // stage seems unnecessary.  As all sampling periods are of similar duration (20mS), it
      // is more efficient simply to add all the power samples together, and note that their
      // sum is actually 50 times greater than it would otherwise be.
      //
      // Although the numerical value itself does not change, I think a new name would be
      // helpful so as to avoid any confusion.  The'energy' variable below is 50 * (1/powerCal)
      // times larger than the actual energy in Joules.
      //
      long realEnergy_long = realPower_long;
   
      // Energy contributions are summed in an accumulator which is generally known as the
      // energy bucket.  The purpose of the energy bucket is to mimic the operation of the
      // supply meter.  Most supply meters have a range of 0.001kWh within which energy can
      // pass to and fro without loss or charge to the user.  The energy bucket in the Mk2
      // Power Router was therefore to 0.001kWh, or 3600 Joules.  Moreover, its contents
      // were correctly pre-scaled to be in Joules.
      //
      // As described above, energy contributions for the Mk2a version are scaled somewhat
      // higher that for its floating point predecessor.  The capacity of the energy bucket for
      // Mk2a _rev3 thereore needs to be 3600J * 50 * (1/powerCal).  This is the value that
      // appears in setup().
   
   
      //----------------------------------------------------------------------------------
      // WARNING - Serial statements can interfere with time-critical code, use with care!
      //----------------------------------------------------------------------------------
/*     
      if(((cycleCount % 50) == 5) && polarityNow == POSITIVE) // display once per second
      {
        Serial.print(realPower_long);
        Serial.print(", ");
        Serial.print(energyInBucket_long);
        Serial.print(", ");
        Serial.println(energyInBucket_4led_long); // has no upper or lower limits
        energyInBucket_4led_long = 0; // useful for calibration/test purposes
      }
*/
      if (beyondStartUpPhase)
      { 
        // Providing that the initial settling time has passed,   
        // add this latest contribution to the energy bucket
        energyInBucket_long += realEnergy_long;   
        energyInBucket_4led_long += realEnergy_long;   
         
        // Apply max and min limits to bucket's level.  This is to ensure correct operation
        // when conditions change, i.e. when import changes to export, and vici versa
        //
        if (energyInBucket_long > capacityOfEnergyBucket_long)
        {
          energyInBucket_long = capacityOfEnergyBucket_long;
          digitalWrite(outputPinForLed, 1); // illuminate the on-board LED if bucket overflows
        }
        else
        {
          digitalWrite(outputPinForLed, 0); // clear the on-board LED if bucket is not overflowing
          if (energyInBucket_long < 0)
          {
            energyInBucket_long = 0;
          } 
        }
 
#ifdef TALLYMODE
        tallymode_updateData(realPower_long); // update the relevant tally
#endif
      }
      else
      { 
        // check whether the system had time to settle
        if(cycleCount > (startUpPeriod * CYCLES_PER_SECOND))
        {
          beyondStartUpPhase = true;
//        Serial.println ("go!");
        }
      }   
     
      // clear the per-cycle accumulators for use in this new mains cycle. 
      samplesDuringThisCycle = 0;
      sumP = 0;

    } // end of processing that is specific to the first Vsample in each +ve half cycle   
    else
    {     
      // This is the start of a new -ve half cycle (just after the zero-crossing point)
      //
      // This is a convenient point to update the Low Pass Filter for DC-offset removal ...
      long previousOffset = DCoffset_V_long;
      DCoffset_V_long = previousOffset + (0.01 * cumVdeltasThisCycle_long);
      cumVdeltasThisCycle_long = 0;
     
      // ... and prevent the LPF's output from drifting beyond the likely range of the voltage signal
      if (DCoffset_V_long < DCoffset_V_min) {
        DCoffset_V_long = DCoffset_V_min; }
      else 
      if (DCoffset_V_long > DCoffset_V_max) {
        DCoffset_V_long = DCoffset_V_max; }
           
      // The triac can change state at each -ve going zero crossing.  Update the state of a
      // flag which shows the current state of the triac (for anti-flicker mode logic)
      //     
      if (nextStateOfTriac == ON) {
        triacState = ON; }
      else { 
        triacState = OFF; }   
    } // end of processing that is specific to the first Vsample in each -ve half cycle
  }
 
  if (polarityNow == POSITIVE)
  {
    // for whole-cycle operation, the trigger is only armed during +ve half cycles
    if (triggerNeedsToBeArmed == true)
    {
      // check to see whether the trigger device can now be reliably armed
      if(voltageOKToArmTriggerFlag == true) 
      {
        if (operatingMode == NORMAL)
        {
          // check to see whether the energy threshold has been reached
          if (energyInBucket_long > energyThreshold_long)
          {
            nextStateOfTriac = ON; 
          }
          else
          {
            nextStateOfTriac = OFF;
          }
        }
        else
        {
          // We're in anti-flicker mode, so different logic applies ...
          //
          if (energyInBucket_long < antiFlicker_lowerEnergyThreshold)       
          {
            // when below the lower threshold, always turn the triac off
            nextStateOfTriac = OFF; 
          }
          else
          if (energyInBucket_long > antiFlicker_upperEnergyThreshold) // upper threshold     
          {
            // when above the upper threshold, ensure that the triac is on if permitted
            if (triacState != ON)
            {
              if (cycleCount > cycleCountAtLastActivation + minCycleCountsBetweenActivations)
              {
                nextStateOfTriac = ON;  // the external trigger device is active low
                cycleCountAtLastActivation = cycleCount;
              }
            }
          }
          else
          {
            // the energy level is between the upper and lower thresholds, so
            // leave the triac's state unchanged (anti-flicker measure)
          }         
        } // end of anti-flcker mode logic
                 
        // set the Arduino's output pin accordingly, and clear the flag
        digitalWrite(outputPinForTrigger, nextStateOfTriac);   
        triggerNeedsToBeArmed = false;     
      }
    }
  }
  else
  {
    // When the voltage polarity is negative, no special processing is needed.
  }

  // Rest of processing for ALL Vsamples
  //  (this has to go here because the counters / accumulators may have just been cleared)
  sumP +=instP; // cumulative power, scaling as for Mk2 (V_ADC x I_ADC)
  cumVdeltasThisCycle_long += sampleVminusDC_long; // for use with LP filter
  samplesDuringThisCycle++;
}
//  ----- end of main Mk2a code -----


#ifdef TALLYMODE
void tallymode_checks()
{
  if (tallymode_firstLoop) {
    tallymode_setup(); } // user-dialogue for recording energy data
  else
  if (cycleCount >= tallymode_maxCycleCount) {
    tallymode_dispatchData(); // send recorded energy data to the Serial monitor 
//    cycleCount = 0;
    tallymode_firstLoop = true;  // get ready for another run
    pause(); } // so that user can access data from the Serial monitor

  else
  if (beyondStartUpPhase) {
      tallymode_noOfSamplePairs++; }
}


void  tallymode_setup()
{
  char inbuf[10];
  int tempInt;
  byte noOfBytes;
  boolean done;

 // <-- start of commented out section to save on RAM space.
 /*
   Serial.println ("WELCOME TO TALLYMODE ");
  Serial.println ("This mode of operation allows the energy content of individual mains cycles");
  Serial.println ("to be analysed.  For nomal operation, the #define TALLYMODE statement");
  Serial.println ("should be commented out. ");
*/
   // <-- end of commented out section to save on RAM space.

  Serial.println (); 
  Serial.println ("Tallymode setup:"); 
  Serial.print ("Time to run (secs)? ");
  done = false;
  while (!done) {
    noOfBytes = Serial.available();
    if (noOfBytes > 0) { done = true; } else { delay(100); }}
  for (tempInt = 0; tempInt < 10; tempInt++) { inbuf[tempInt] = 0; }
  Serial.readBytes(inbuf, noOfBytes);
  tempInt = atoi(inbuf);  Serial.println (tempInt);
  tallymode_maxCycleCount = tempInt * CYCLES_PER_SECOND;
  tallymode_durationOfRecording = tempInt;
 
  Serial.print ("Min value (Watts)? ");
  done = false;
  while (!done) {
    noOfBytes = Serial.available();
    if (noOfBytes > 0) { done = true; } else { delay(100); }}
  for (tempInt = 0; tempInt < 10; tempInt++) { inbuf[tempInt] = 0; }
  Serial.readBytes(inbuf, noOfBytes);
  tempInt = atoi(inbuf);  Serial.println (tempInt);
  tallymode_minVal = tempInt;
//  Serial.print(" tallymode_minVal = "); Serial.println(tallymode_minVal);   
//  tallymode_minVal_long = tallymode_minVal * (1/powerCal); // used for power, not energy,
                                                           // hence there's no x100 term.
 
  Serial.print ("Max value (Watts)? ");
  done = false;
  while (!done) {
    noOfBytes = Serial.available();
    if (noOfBytes > 0) { done = true; } else { delay(100); }}
  for (tempInt = 0; tempInt < 10; tempInt++) { inbuf[tempInt] = 0; }
  Serial.readBytes(inbuf, noOfBytes);
  tempInt = atoi(inbuf);  Serial.println (tempInt);
  tallymode_maxVal = tempInt;
//  Serial.print(" tallymode_maxVal = "); Serial.println(tallymode_maxVal);   

  if (tallymode_maxVal <= tallymode_minVal) {
    Serial.print(7); // beep
    Serial.println ("ERROR!"); }
 
  tallymode_stepVal = (float)(tallymode_maxVal - tallymode_minVal) / NUMBER_OF_TALLIES;
//  Serial.print(" tallymode_stepVal = "); Serial.println(tallymode_stepVal);   
/*
  tallymode_stepVal_long = tallymode_stepVal * (1/powerCal); // used for power, not energy,
                                                             // hence there's no x50 term.
  tallymode_halfStep = (tallymode_stepVal_long / 2); // to avoid integer-rounding
*/

  for (tempInt = 0; tempInt < NUMBER_OF_TALLIES + 2; tempInt++) {
    tally[tempInt] = 0; }
   
  energyInBucket_long = (capacityOfEnergyBucket_long / 2); // for rapid startup of power distribution
  cycleCount = 0;
  tallymode_noOfValuesTallied = 0;
  tallymode_noOfSamplePairs = 0;
  beyondStartUpPhase = false; // to allow LPF to re-settle for next run
  tallymode_firstLoop = false;

  Serial.print(" Recording will start in ");
  Serial.print(startUpPeriod);   
  Serial.println(" seconds ... ");
 
 // startTime = millis();
};


void  tallymode_updateData(long power_long)
{
  float powerInWatts = power_long * powerCal;
  int index;
 
  if (powerInWatts < tallymode_minVal)
  {
    index = 0; // tally[0] is for underflow
  }
  else
  if (powerInWatts > tallymode_maxVal)
  {
    index = NUMBER_OF_TALLIES + 1; // tally[N+1] is for overflow
  }
  else
  {
    index = (powerInWatts - tallymode_minVal) / tallymode_stepVal;
    index += 1; // because the linear tallies run from 1 to N, not from 0
  }
 
  tally[index]++; // increment the relevant tally   
  tallymode_noOfValuesTallied++;
}


void  tallymode_dispatchData()
{
 
//   <<- start of commented out section, to save on RAM space!
/*   
  Serial.println ();
  Serial.println ("Format of results: ");
  Serial.print ("Sorted data runs from tally[1] (min) to tally[");
  Serial.print (NUMBER_OF_TALLIES);
  Serial.println ("] (max).");
  Serial.print ("tally[0] is below range; tally[ ");
  Serial.print (NUMBER_OF_TALLIES + 1);
  Serial.println ("] is above range.");
  Serial.println("Tally results are displayed with max power first. For each one:");
  Serial.println("  mid-range power of tally (Watts), number of times recorded.");
  Serial.println();
*/   
//   <<- end of commented out section, to save on RAM space!
 
  Serial.println("Results for this run:");
  Serial.print (tallymode_minVal);
  Serial.println (", <- min value of tally range (W)");
  Serial.print (tallymode_maxVal);
  Serial.println (", <- max value of tally range (W)");
  Serial.print (tallymode_stepVal);
  Serial.println (", <- step value between tallies (W)");
  Serial.print (NUMBER_OF_TALLIES);
  Serial.println (", <- No. of tallies");
  Serial.print (tallymode_durationOfRecording);
  Serial.println (", <- duration (secs)");
  Serial.print (tallymode_noOfValuesTallied);
  Serial.println (", <- no of values tallied");
  Serial.print ( tallymode_noOfSamplePairs /
    ((float)tallymode_durationOfRecording * CYCLES_PER_SECOND), 1);
  Serial.println (", <- loops per mains cycle (av)");
  Serial.println("***");
 
  float powerVal;
  for (int index = NUMBER_OF_TALLIES + 1; index >= 0; index--)
  {
/* 
    // display the index value for this tally
    Serial.print (index);
    Serial.print (", ");
*/   
    // display the power value for this tally
    if (index == NUMBER_OF_TALLIES + 1)
    {
      Serial.print (">");
      Serial.print (tallymode_maxVal);
    }
    else
    if (index == 0)
    {
      Serial.print ("<");
      Serial.print (tallymode_minVal);
    }
    else 
    {
      if (index == NUMBER_OF_TALLIES)
      {
        powerVal = tallymode_maxVal - (tallymode_stepVal / 2);
      }
      else
      {
        powerVal -= tallymode_stepVal;
      }
     
      if ((int)powerVal == powerVal)
      {
        Serial.print (powerVal, 0); // to suppress the decimal part for integers
      }
      else
      {
        Serial.print (powerVal);  // non-integers are displayed to 2 dec places
      }
    } 
    Serial.print ("W");

    // display the number of hits for this tally
    Serial.print (", ");
    Serial.println (tally[index]); 
  }
};


void pause()
{
  byte done = false;
  byte dummyByte;
   
  while (done != true)
  {
    if (Serial.available() > 0) {
      dummyByte = Serial.read(); // to 'consume' the incoming byte
      if (dummyByte == 'g') done++; }
  }   
}
#endif


// helper function, to process LED events, can be conveniently called once per mains cycle
void checkLedStatus()
{
  ledState = digitalRead (ledDetectorPin);

  if (ledState != prevLedState)
  {
    // led has changed state
    if (ledState == ON)
    {
      // led has just gone on
      ledOnAt = millis();
      ledRecentlyOnFlag = true;
    }
    else
    {
      // led has just gone off   
      if (ledRecentlyOnFlag == true)
      {
        ledRecentlyOnFlag = false;       
        Serial.print ("** LED PULSE ** "); // this is a chargeable event 
      }
      else
      {
        Serial.print ("** LED OFF ** "); // 'no longer exporting' is also a chargeable event
      }
      Serial.println(millis()/1000);
    }   
  }
  else
  {
    // the LED state has not changed
    if (ledState == ON)
    {
      if (ledRecentlyOnFlag == true)
      {
        // check to see if the known duration of a pulse has been exceeded   
        unsigned long timeNow = millis();     
        if ((timeNow - ledOnAt) > 50)
        {
          Serial.print ("** LED ON **");  // 'exporting' is a non-chargeable state     
          Serial.print (",  energy in bucket = ");
          Serial.println((long)(energyInBucket_4led_long));
          ledRecentlyOnFlag = false;   
        }     
      }
    }
  }
  prevLedState = ledState;   
}
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: mktutsi - 02.11.18 - klo:15:26
Eli mk2pv ajaa "NORMAL" modessa kokonaisia syklejä päälle/pois? Ja silti sähkömittarilla tuotanto ja kulutus tasapainottuu? Höh, mun mittari kiukutteli niin kauan kunnes vaihdoin vaihekulmasäätöön.

Oletko kokeillut "ANTI FLICKER", toimiiko sähkömittari silläkin? Mikä mittari sulla on? Voiko noissa mittareissa olla noin oleellisia eroja.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: jolla - 02.11.18 - klo:15:31
toimii molemmilla, minulla ei ole mittari kiukutellut yhtään, invertterit ajaa alas jos yrittää yli 2kw säätää

tässä kuva hyvin 'haastavista' olosuhteista kun kirkkaalla säällä pilviä tulee ja menee, näkyy skaalautuvuus

hyvin näkyy kun tiski/pyykkikone olleet 'vika' aikaan päällä ja vimonen kulutuspiikki on sauna
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: tengu - 02.11.18 - klo:15:54
Täällä mk2 ja 3 ulostuloa käytössä. 1 1+kw   2 2kw 3 2kw.  Aina kun yksi pykälä on 100% ja silti yrittää mennä ulos niin edellinen pysyy täysin auki ja aletaan seuraavaa pulssittamaan. Toimii samoin kun jollalla mutta ihan vain yhdellä arduinopohjaisella härvelillä. Hyvin pitää Carunan mittarin nollilla päivisin vaikka ajan täysiä puolijaksoja. Kaikki pykälät taitaa olla vielä eri vaiheissa.

Miten olen itse antanut itseni ymmärtää tuon sähkömittarin noin toimintaperiaatteen:

Mittari 1000 pulssia kWh.
1 pulssi on 1 Ws.
Mittari laskee tulevan ja lähtevän sähkön erikseen. Niin kauan kun sähköä kuluu lisätään pykäliä "käyttörekisteriin"  ja kun käyttörekisteri tulvii (yli 1 Ws)  niin se nollataan ja lisätään kulutusrekisteriin (tai tuotto) pulssi. Käyttörekisteri lisääntyy kun sähköä kuluu ja vähenee kun tuotetaan. Niin kauan kun ei mennä rajojen yli, että rekisteri nollaantuu, ei mitään lasketa. Pulssi mikä menee kulutusrekisteriin on siellä ja pysyy.

Teknisesti miten se mittaus sitten tuolla käyttörekisterin sisällä käytönnössä toimii niin se onkin varmaan valmistajan teollisuussalaisuus.

Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 02.11.18 - klo:16:58
Mielenkiintoisia vastauksia!
Enpä taida omaa ssr/pwm systeemiä vielä purkaa vaan odottelen että olisi jotain säädettävää (ja testattavaa)
Tällä hetkellä kaikki mikä tulee menee kulutukseen eikä edes riitä.
Säätövaranahan minulla on vain lvv:n 3kpl 1kw vastusta ja jokainen eri vaiheessa.
Eilen tuli paneeleista 1.03 kwh ja tänään hiukan vähemmän.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: kotte - 02.11.18 - klo:17:21
Moniportainen nollapistekytkin/SSR tietenkin toimii ihan hyvin, jos on riittävästi tehoportaita ja valitsee aina sopivan vastuskombinaation. Voi esimerkiksi hommata 1kW, 500W, 250W ja 125W vastukset. Noista saa kytkemällä 0W, 125W, 250W, 375W, 500W, 625W, 750W, 875W, 1kW, ... , 1875W tehovastukset ja noillahan saa joko verkosta imetyn tai sinne turhaan uhratun tehon +-78W tarkkuusrajoissa nollaan lähes 2kW:n tehoon asti. Tuo lienee moniin käytännön tuloksiin riittävä tarkkuustaso, teknisesti ongelmaton ja melko helppo toteuttaa.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 02.11.18 - klo:18:08
Moniportainen nollapistekytkin/SSR tietenkin toimii ihan hyvin, jos on riittävästi tehoportaita ja valitsee aina sopivan vastuskombinaation. Voi esimerkiksi hommata 1kW, 500W, 250W ja 125W vastukset. Noista saa kytkemällä 0W, 125W, 250W, 375W, 500W, 625W, 750W, 875W, 1kW, ... , 1875W tehovastukset ja noillahan saa joko verkosta imetyn tai sinne turhaan uhratun tehon +-78W tarkkuusrajoissa nollaan lähes 2kW:n tehoon asti. Tuo lienee moniin käytännön tuloksiin riittävä tarkkuustaso, teknisesti ongelmaton ja melko helppo toteuttaa.
Kyllä kyllä mutta 3~ tapauksessa tuo vastusten määrä tulee kertoa kolmella, koska tasaus tulee suoritta jokaiselle vaiheelle.
Ja kun sitä yritetää käyttää vedenlämmitykseen niin eipä se ihan helppoa olekkaan, mistä voi löytää varaajan jossa olisi noin paljon vastuksia?
Luulisin että ainoa realistinen vaihtoehto on toimiva tehonsäätö. Miten se pitäisi tehdä,siitä tässä on kysymys, ainakin minulla.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: kotte - 02.11.18 - klo:18:58
Jollalle kysymys.
Aikaisemmista viesteistäsi ja "korsteeni" kuvista päättelin että sinulla on säädössä SSR.
Kun nyt täällä ollaan sitämieltä että se ei oikein toimi niin miten sinulla toimii?
Vai olenko käsittänyt väärin?
Jotenkin tuo tehon ohjaaminen ssr/pwm tuntuu "tyylikkäämmältä"!

kyllä se toimii SSR/pwm, ongelmia oli saada tarpeeksi stabilia ja luotettavaa ohjausdataa ja yli 2kW alkoivat tuottaa ongelmia kuten myös tällä mk2pv'llä mikä nyt on käytössä
ongelma ratkesi toisella arduinolla mikä ei tee muuta kun kytkee SSR kanssa lisäkuormaa kiinetästi tarvittaessa, uskoisin että ssr/pwm toimisi myös tällä logiikalla

nyt on käytössä linkin http://www.elisanet.fi/korsteeni/mk2pv.shtml toiseksi alimman kuvan mukainen kytkentä millä toimii moitteetta 1,6kW vastuksen kanssa ja lisäkuormilla (se toinen arduino) 7kW saakka on toimiminut saumattomasti

pwm'ällä eikä pulssilla yli 2kW kuomilla ei saa toimimaan näillä linjoilla tässä taloudessa

ihan rautalankana
- kun tuotto ( panelien tuotto - kulutus) on 0-1,6 kW mk2pv hoitaa säädön 1,6kw vastuksella
- yli 1,6kW toinen arduino kytkee 1,6 kw vastuksen kiinteästi
- yli 3,2 kw kytkee 2,5kw ja 1,6kW irti
- jne

Koodia: [Valitse]
// EmonLibrary examples openenergymonitor.org, Licence GNU GPL V3

#include "EmonLib.h"             // Include Emon Library
EnergyMonitor emon1;             // Create an instance
int upPin7 = 7;
int upPin8 = 8;
int upPin9 = 9;

void setup()
{
  pinMode(upPin7,OUTPUT);
  pinMode(upPin8,OUTPUT);
  pinMode(upPin9,OUTPUT); 
  Serial.begin(9600);
 
  emon1.voltage(2, 150, 1.7);  // Voltage: input pin, calibration, phase_shift
  emon1.current(1, 12.7);       // Current: input pin, calibration.
}

void loop()
{
  emon1.calcVI(20,2000);         // Calculate all. No.of half wavelengths (crossings), time-out
  emon1.serialprint();           // Print out all variables (realpower, apparent power, Vrms, Irms, power factor)
 
  float realPower       = emon1.realPower;        //extract Real Power into variable
  float apparentPower   = emon1.apparentPower;    //extract Apparent Power into variable
  float powerFActor     = emon1.powerFactor;      //extract Power Factor into Variable
  float supplyVoltage   = emon1.Vrms;             //extract Vrms into Variable
  float Irms            = emon1.Irms;             //extract Irms into Variable
 
    if ((realPower >= 1600) && (realPower < 3200)) //170W tullut yli 28 p�iv�n�
    {
    digitalWrite(upPin7, HIGH);
    digitalWrite(upPin8, LOW);
    digitalWrite(upPin9, LOW);
    }
    else if ((realPower >= 3200) && (realPower < 4100))
    {
    digitalWrite(upPin8, HIGH);
    digitalWrite(upPin7, LOW);
    digitalWrite(upPin9, LOW);
    }
    else if ((realPower >= 4100) && (realPower < 5400))
    {
    digitalWrite(upPin8, HIGH);
    digitalWrite(upPin7, HIGH);
    digitalWrite(upPin9, LOW);
    }
    else if ((realPower >= 5400) && (realPower < 8200))
    {
    digitalWrite(upPin8, HIGH);
    digitalWrite(upPin9, HIGH);
    digitalWrite(upPin7, LOW);
    }
    else
    {
    digitalWrite(upPin7, LOW);
    digitalWrite(upPin8, LOW);
    digitalWrite(upPin9, LOW);
    } 
}


käytössä oleva mk2pv koodi

Koodia: [Valitse]
// Mk2a is a revised version of my stand-alone sketch for diverting suplus
// PV power to a dump load using a triac.  The original Mk2 version, which includes
// more explanation and 'debug' code to support off-line working, may be found at
// http://openenergymonitor.org/emon/node/841
//
// General aspects of Mk2a:
// The Mk2a code is suitable for hardware that has multiple voltage references, such
// as emonTx.  Mk2a uses integer maths for improved speed.  It also uses low-level
// instructions for ADC operations which 'frees up' time that was previously unavailable
// for general processing activities.  Further information about this enhancement may be
// found immediately before loop().
//
// Specific releases of Mk2a:
// The initial release of Mk2a had twin high-pass filters, as used in the standard OEM
// V&I sketch.  Due to a couple of minor bugs, it was soon replaced by the _rev2 version.
//
// The _rev3 version marks a further change to the way that the raw sample streams are
// processed.  This has come about because, for the purpose of calculating "real power",
// there is no need for DC offset to be pre-removed from the raw current samples. The
// standard calculation for real power does this automatically when applied over each whole
// cycle of the mains.  Half-cycle processing of power has been discontinued.
//   A single LPF, which is updated just once per mains cycle, has been introduced for
// the purpose of determining the DC offset of the voltage waveform.  This value is then
// subtracted from each raw voltage sample.  A nominal value of 512 is subtracted from
// each current sample, this being to prevent the system becoming over-sensitive to any
// imbalance conditions or random noise; the actual value is unimportant.
//
// The ANTI_FLICKER option was also introduced in _rev3.  This mode uses two thresholds
// for the energy bucket rather than just one.  When surplus power is available,
// the power-diversion logic operates the triac between these two limits on a hysteresis
// basis.  To ensure that the anti-flicker requirement is always met, a minimum amount of
// time has to elapse between consecutive activations of the triac.  Under certain
// conditions, this may cause a small amount of surplus power to be lost when the bucket
// overflows.  The on-board LED (pin 13) shows whenever then this occurs. Accurate
// calibration of the system is essential when operating in this mode.
// 
// TALLYMODE is a #define option which allows energy data to be collected for
// subsequent display.  In _rev2, energy values in positive and negative half-cycles was
// recorded separately.  From _rev3 onwards, energy is recorded for whole cycles only.
//   While running in TALLYMODE, the code is fully functional.  It pauses after a
// user-selectable period so that stored data can be retrieved.  To avoid overflow, the
// maximum recommended duration is 10 minutes.  To start again, press the 'g' key, then
// carriage-return.
//   TALLYMODE provides a very easy way to calibrate the system.  Clip the CT around
// one core of a cable that supplies a known load, and do a short run with appropriate
// Min and Max values.  If the peak distribution (in Watts) is not where you expect it
// to be, then just change the value of powerCal until it is. 
//   Full details about calibration are provided just before setup().
//
// SPEEDCHECK is another #define option.  When #included, the results of a built-in
// checker facility are displayed.  This facility keeps track of the number of times
// that general processing fails to complete within the duration of the associated
// ADC conversion.  SPEEDCHECK may be left on permanently, if desired.
//   If additional workload is ever to be added, SPEEDCHECK will provide a sensitive
// indication of any undesirable effect on the underlying code.  Any value other than
// zero will reduce the accuracy of power/energy calculations.
//
// Mk2a_rev3a.  This corrects a minor but long-standing error in the data produced by
// Tallymode.  Tallymode data is now displayed in Watts, rather than in Tally numbers.
//
//                  Robin Emley (calypso_rae on Open Energy Monitor Forum)
//                  June 2013


/*
Circuit for monitoring pulses from a supply meter using checkLedStatus():
 
                  ----------------> +5V
                  |
                  /
                  \ 8K2
                  /
                  |
             ---------------------> dig 2
             |       |
        -->  /       |
        -->  \       _
        LDR  /       -  0.01uF
             |       |
             ----------------------> GND
*/

// There are two #define options which may be activiated independently
//
//#define TALLYMODE // for recording energy data.  Comment out for normal operation
//#define SPEEDCHECK // to display the results of a built-in checker every few seconds

enum operatingModes {NORMAL, ANTI_FLICKER};
enum operatingModes operatingMode = NORMAL; // <-- select the desired mode here

#define CYCLES_PER_SECOND 50
#define JOULES_PER_WATT_HOUR 3600 // 0.001 kWh = 3600 Joules
enum polarities {NEGATIVE, POSITIVE};
enum triacStates {ON, OFF}; // the external trigger device is active low

// general global variables
const byte outputPinForLed = 13;  // digital
const byte outputPinForTrigger = 9; // digital
const byte ledDetectorPin = 2;  // digital
const byte ledRepeaterPin = 10;  // digital
const byte voltageSensorPin = 2;  // analogue
const byte currentSensorPin = 1;   // analogue
const byte startUpPeriod = 5; // in seconds, to allow HP filters to settle
const int DCoffset_I = 512; // for calculating "real power", a nominal value is fine

long cycleCount = 0;
long cycleCountAtLastActivation = 0;
int samplesDuringThisCycle;
enum triacStates nextStateOfTriac;
enum triacStates triacState;
boolean triggerNeedsToBeArmed;
boolean beyondStartUpPhase = false;
float safetyMargin_WattsPerHalfCycle;
long triggerThreshold_long;
long energyInBucket_long = 0; // for integer maths
int phaseCal_int; // for integer maths
long capacityOfEnergyBucket_long;  // for integer maths
long energyThreshold_long;  // for integer maths
long antiFlicker_lowerEnergyThreshold;
long antiFlicker_upperEnergyThreshold;
long sumP;// for integer maths
long DCoffset_V_long = 512L * 256; // nominal mid-point value of ADC @ x256 scale
long DCoffset_V_min;
long DCoffset_V_max;

float minTimeBetweenActivations = 3; // <-- anti-flicker requirement (seconds)
int minCycleCountsBetweenActivations;

// items to allow general processing tasks to be efficiently partitioned.
boolean newHalfCycleFlag;
boolean voltageOKToArmTriggerFlag;
enum polarities polarityNow;
long instP;
long sampleVminusDC_long;

// values that need to be stored from one loop to the next
long lastSampleVminusDC_long;  //    for phaseCal algorithm
enum polarities polarityOfLastSampleV; // for zero-crossing detection
long cumVdeltasThisCycle_long;   // <<--- for LPF
int sampleV_forNextLoop; // for deferred processing
int sampleI_forNextLoop; // for deferred processing

// items for LED monitoring
byte ledState, prevLedState;
boolean ledRecentlyOnFlag = false;
unsigned long ledOnAt;
long energyInBucket_4led_long = 0;

// for the in-built mechanism to check whether the ADC conversion time is ever exceeded
boolean speedFlag;
long FlagNotClearedCounter = 0;
long loopCountForSpeedChecker = 0;
long maxLoopCountForSpeedChecker = 20000; // how often to display results (~ 4500 loops/sec)

#ifdef TALLYMODE
#define NUMBER_OF_TALLIES 100
unsigned int tally[NUMBER_OF_TALLIES + 2]; // For recording the energy content in whole mains cycles.
unsigned int tallymode_maxCycleCount;  // the cycleCount value when recording should cease
int tallymode_maxVal; // the maximum power to be recorded (Watts)
int tallymode_minVal; // the minimum power to be recorded (Watts)
//long tallymode_minVal_long; // x256 version for integer maths
float tallymode_stepVal; // the power increment between consecutive tallies (Watts)
//long tallymode_stepVal_long; // x256 version for integer maths
boolean tallymode_firstLoop = true;
unsigned int tallymode_noOfValuesTallied; // overflows after 10.9 minutes
unsigned long tallymode_noOfSamplePairs; // to show the average samples-per-mains-cycle rate
int tallymode_durationOfRecording; // in seconds
#endif

// Calibration values
//-------------------
// Three calibration values are required: powerCal, voltageCal and phaseCal.
// With most hardware, the default values are likely to work fine without
// need for change.  A full explanation of each of these values now follows:
//   
// powerCal is a floating point variable which is used for converting the
// product of voltage and current samples into Watts.
//
// The correct value of powerCal is entirely dependent on the hardware that is
// in use.  For best resolution, the hardware should be configured so that the
// voltage and current waveforms each span most of the ADC's usable range.  For
// many systems, the maximum power that will need to be measured is around 3kW.
//
// My sketch "MinAndMaxValues.ino" provides a good starting point ideal for
// system setup.  First arrange for the CT to be clipped around either core of a 
// cable which supplies a suitable load; then run the tool.  The resulting values
// should sit nicely within the range 0-1023.  To allow some room for safety,
// a margin of around 100 levels should be left at either end.  This gives a
// output range of around 800 ADC levels, which is 80% of its usable range.
//
// My sketch "RawSamplesTool.ino" provides a one-shot visual display of the
// voltage and current waveforms.  This provides an easy way for the user to be
// confident that their system has been set up correctly for the power levels
// that are to be measured.
//
// The ADC has an input range of 0-5V and an output range of 0-1023 levels.
// The purpose of each input sensor is to convert the measured parameter into a
// low-voltage signal which fits nicely within the ADC's input range.
//
// In the case of 240V mains voltage, the numerical value of the input signal
// in Volts is likely to be fairly similar to the output signal in ADC levels. 
// 240V AC has a peak-to-peak amplitude of 679V, which is not far from the ideal
// output range.  Stated more formally, the conversion rate of the overall system
// for measuring VOLTAGE is likely to be around 1 ADC-step per Volt (RMS).
//
// In the case of AC current, however, the situation is very different.  At
// mains voltage, a power of 3kW corresponds to an RMS current of 12.5A which
// has a peak-to-peak range of 35A.  This is smaller than the output signal by
// around a factor of twenty.  The conversion rate of the overall system for
// measuring CURRENT is therefore likely to be around 20 ADC-steps per Amp.
//
// When measuring power, which is what this code does, the individual
// conversion rates for voltage and current are not of importance.  It is
// only the conversion rate for POWER which is important.  This is the
// product of the individual conversion rates for voltage and current.  It
// therefore has the units of ADC-steps squared per Watt.  Most systems will
// have a power conversion rate of around 20 (ADC-steps squared per Watt), so
// is a good default value to start with.
//
// powerCal is the RECIPR0CAL of the power conversion rate.  A good value
// to start with is therefore 1/20 = 0.05 (Watts per ADC-step squared)
//
const float powerCal = 0.067;  // <---- powerCal value
 
// As mentioned above, the conversion rate for AC voltage has units of 
// ADC-steps per Volt.  Athough not required for measuring power, this
// conversion rate does need to be known in order to determine when the
// voltage level is suitable for arming the external trigger device.
//
// To determine the voltage conversion rate, note the Min and Max values that
// are seen when measuring 240Vac via the voltage sensor.  Subtract one from
// the other to find the range.  Then put that value into the voltageCal formula
// below.  voltageCal has units of ADC-steps per Volt.
//
// 679 is the peak-to-peak range of a 240V RMS signal.  The (float) typecast
// is to prevent integer rounding
//
const float voltageCal = 656 / (float)679; // <-- the first number is the output range of
                               //     your ADC when 240V AC is being measured
                       
// phaseCal is used to alter the phase of the voltage waveform relative to the
// current waveform.  The algorithm interpolates between the most recent pair
// of voltage samples according to the value of phaseCal.
//
//    With phaseCal = 1, the most recent sample is used. 
//    With phaseCal = 0, the previous sample is used
//    With phaseCal = 0.5, the mid-point (average) value in used
//
// Values ouside the 0 to 1 range involve extrapolation, rather than interpolation
// and are not recommended.  By altering the order in which V and I samples are
// taken, and for how many loops they are stored, it should always be possible to
// arrange for the optimal value of phaseCal to lie within the range 0 to 1.  When
// measuring a resistive load, the voltage and current waveforms should be perfectly
// aligned.  In this situation, the Power Factor will be 1.
//
// My sketch "PhasecalChecker.ino" provides an easy way to determine the correct
// value of phaseCal for any hardware configuration. 
//
const float  phaseCal = 1.0;


void setup()

  Serial.begin(9600);
  pinMode(outputPinForTrigger, OUTPUT); 
  pinMode(outputPinForLed, OUTPUT); 
  Serial.println();
  Serial.println("starting new run ...");
  Serial.println(); 
  Serial.print("DCoffset_V_long = "); 
  Serial.println(DCoffset_V_long); 
 
   
  // When using integer maths, calibration values that have supplied in floating point
  // form need to be rescaled. 
  //
  phaseCal_int = phaseCal * 256; // for integer maths
 
  // When using integer maths, the SIZE of the ENERGY BUCKET is altered to match the
  // voltage conversion rate that is in use.  This avoids the need to re-scale every
  // energy contribution, thus saving processing time.  To avoid integer rounding,
  // energy is also recorded at x50 scale. 
  //   This process is described in more detail in the function, processAllOtherTasks(),
  // just before the bucket is updated at the start of each new whole-cycle of the mains.
  // 
  capacityOfEnergyBucket_long = (JOULES_PER_WATT_HOUR * 50L) * (1/powerCal);
 
  Serial.print("powerCal = ");
  Serial.print(powerCal,4);
  Serial.println(" Watts per ADCstep^2");
  Serial.print("energy bucket = 3600 * 50 * (1/");
  Serial.print(powerCal,4);
  Serial.print(") = ");
  Serial.print(capacityOfEnergyBucket_long);
  Serial.println(" energy measurement units");
  Serial.println(); 
                                               
  energyThreshold_long = capacityOfEnergyBucket_long * 0.5; // for normal operation
  antiFlicker_lowerEnergyThreshold = capacityOfEnergyBucket_long * 0.1; // for anti-flicker mode
  antiFlicker_upperEnergyThreshold = capacityOfEnergyBucket_long * 0.9; // for anti-flicker mode 
  minCycleCountsBetweenActivations =
       minTimeBetweenActivations * 50; // cycleCount increments every 20mS

  if (operatingMode == NORMAL) {
    energyInBucket_long = 0.8 * energyThreshold_long; } // for faster start-up 
 
  triggerThreshold_long = 50 * 256L / voltageCal;
    // +50V is a suitable point in the rising waveform to arm the zero-crossing trigger.
    // The 256 is because filteredV is scaled at x256 when integer maths is used.
    // The reciprocal of voltageCal converts ADClevels into Volts, as described above.
   
  DCoffset_V_min = (long)(512L - 100) * 256; // mid-point of ADC minus a working margin
  DCoffset_V_max = (long)(512L + 100) * 256; // mid-point of ADC plus a working margin
}

// --------------------------------------------------------------------------------------
// Each time around loop(), a new pair of V & I samples is taken.  Rather than using the
// normal analogRead() statement, the ADC is instructed using low-level instructions. 
// By this means, the ADC's conversion time can be used to process data that was collected
// during the >>PREVIOUS<< iteration of loop(). 
//
// Thanks to the use of integer maths, general processing has been greatly speeded up.
// General processing has also been split into two sections, each of which can fit nicely
// into one of the periods while ADC conversions are taking place. The ADC pre-processor
// is now spending all of its time doing back-to-back V and I conversions, and the main
// Arduino is comfortably able to do all of its processing activities during these
// 'hidden' ADC conversion periods.  The amount of delay that can be attributed to
// general processing activities is now ...  NIL  :-)
//
// The first ADC conversion is for current, that's because the phase of this waveform is
// generally slightly advanced relative to the voltage.  While this first ADC conversion
// is taking place, all of the standard per-loop processing activities are done.
//
// The second ADC conversion is for voltage, that's because this waveform is generally
// slightly retarded relative to the current.  While this second ADC conversion is taking
// place, all of the other general processing activities are done.  This includes the
// updating of the energy bucket, which now occurs twice per mains cycle, and also the
// arming of the zero-crossing trigger.
//
// While restructuring the general processing code, some additional flags have been devised
// so that the overall workload can be partitioned more effectively.  Some variables that
// were previously defined as 'locals' within loop() have now become globals.
//
void loop()             
{
  speedFlag = true;
  ADMUX = 0x40 + currentSensorPin;
  ADCSRA |= (1<<ADSC); // instruct ADC to read the sensor for CURRENT
  {
    processPerLoopTasks(); // all general per-loop processing
    delayMicroseconds(10); // for speed checks only
  }
  while(bit_is_set(ADCSRA, ADSC)) {speedFlag = false;};  // wait for ADC to complete
  sampleI_forNextLoop = ADC;
  FlagNotClearedCounter+= speedFlag; // if the ADC conversion time has been exceeded, it's noted
 
  speedFlag = true;
  ADMUX = 0x40 + voltageSensorPin;
  ADCSRA |= (1<<ADSC); // instruct ADC to read the sensor for VOLTAGE
  {
    processAllOtherTasks(); // all other processing activities
    delayMicroseconds(10); // for speed checks only
  }
  while(bit_is_set(ADCSRA, ADSC)) {speedFlag = false;};  // wait for ADC to complete
  sampleV_forNextLoop = ADC;
  FlagNotClearedCounter+= speedFlag; // if the ADC conversion time has been exceeded, it's noted
 
#ifdef SPEEDCHECK  // this is only processed if needed
  loopCountForSpeedChecker++;
  if (loopCountForSpeedChecker == maxLoopCountForSpeedChecker)
  {
    Serial.println(FlagNotClearedCounter);
    loopCountForSpeedChecker = 0;
    FlagNotClearedCounter = 0;
  }
#endif
} // end of loop()


void processPerLoopTasks()
{
  // all tasks that are required for each loop have been grouped into this routine
#ifdef TALLYMODE
  tallymode_checks();
#endif

  int sampleI = sampleI_forNextLoop; // extract samples taken on previous loop.  This is for clarity
  int sampleV = sampleV_forNextLoop; // only; the stored values won't change during this routine.
 
  // remove DC offset from the raw voltage sample by subtracting the accurate value as determined by a LP filter.
  sampleVminusDC_long = ((long)sampleV<<8) - DCoffset_V_long;

  // remove most of the DC offset from the current sample (the precise value does not matter)
  long sampleIminusDC_long = ((long)(sampleI-DCoffset_I))<<8;
 
  // phase-shift the voltage waveform to align with the current(when a resistive load is used)
  long  phaseShiftedSampleVminusDC_long = lastSampleVminusDC_long
         + (((sampleVminusDC_long - lastSampleVminusDC_long)*phaseCal_int)>>8); 

  // determine the instantaneous power content, for use later
  long filtV_div4 = phaseShiftedSampleVminusDC_long>>2;  // reduce to 16-bits (now x64, or 2^6)
  long filtI_div4 = sampleIminusDC_long>>2; // reduce to 16-bits (now x64, or 2^6)
       instP = filtV_div4 * filtI_div4;  // 32-bits (now x4096, or 2^12)
       instP = instP>>12;     // scaling is now x1, as for Mk2 (V_ADC x I_ADC)
       
   // determine polarity, to save time later
  if(sampleVminusDC_long > 0) {
    polarityNow = POSITIVE; }
  else {
    polarityNow = NEGATIVE; }
 
   // Check for the start of a new mains cycle
  if (polarityNow != polarityOfLastSampleV) {
    newHalfCycleFlag = true; }
  else { 
    newHalfCycleFlag = false; }

  if(sampleVminusDC_long > triggerThreshold_long) {
     voltageOKToArmTriggerFlag = true; }
  else {
    voltageOKToArmTriggerFlag = false; }   
   
  // store items that need to be carried over to the next loop
//  lastSampleV = sampleV;  // required for HPF
//  lastSampleI = sampleI;  // required for HPF
//  lastFilteredV_long = filteredV_long;  // required for HPF
  lastSampleVminusDC_long = sampleVminusDC_long;  // required for phaseCal algorithm
//  lastFilteredI_long = filteredI_long;  // required for HPF
  polarityOfLastSampleV = polarityNow;  // for identification of half cycle boundaries
}


void processAllOtherTasks()
{
  if (newHalfCycleFlag == true)
  {
    if (polarityNow == POSITIVE)
    {                           
      // This is the start of a new +ve half cycle (just after the zero-crossing point)
      cycleCount++; 
      triggerNeedsToBeArmed = true;   
      // If required, this is a good place from which to call checkLedStatus()     
   
      // Calculate the real power and energy during the last whole mains cycle.
      //
      // sumP contains the product of filtered V_ADC and I_ADC samples, just as for Mk2 and
      // many other sketches.  Because only integer maths is being used for Mk2a, things have
      // to be scaled differently from this point.
      //
      // sumP contains the sum of many individual calculations of instant power.  In order
      // to obtain the average power during the relevant period, sumP must first be divided
      // by the number of samples that have contributed to its value.
      //
      // The next stage would normally be to apply a calibration factor so that real power
      // can be expressed in Watts.  That's fine for floating point maths, but it's not such
      // a good idea when integer maths is being used.  To keep the numbers large, and also
      // to save time, calibration of power is omitted at this stage.  realPower_long is
      // therefore (1/powerCal) times larger than the actual power in Watts.
      //
      long realPower_long = sumP / samplesDuringThisCycle; // proportional to Watts
   
      // Next, the energy content of this power rating needs to be determined.  Energy is
      // power divided by time, so the next step is normally to divide by the time over which
      // the power was measured.  For the _rev3 version, power is measured every whole
      // mains cycle, so that's 50 times per second.  When integer maths is being used, this
      // stage seems unnecessary.  As all sampling periods are of similar duration (20mS), it
      // is more efficient simply to add all the power samples together, and note that their
      // sum is actually 50 times greater than it would otherwise be.
      //
      // Although the numerical value itself does not change, I think a new name would be
      // helpful so as to avoid any confusion.  The'energy' variable below is 50 * (1/powerCal)
      // times larger than the actual energy in Joules.
      //
      long realEnergy_long = realPower_long;
   
      // Energy contributions are summed in an accumulator which is generally known as the
      // energy bucket.  The purpose of the energy bucket is to mimic the operation of the
      // supply meter.  Most supply meters have a range of 0.001kWh within which energy can
      // pass to and fro without loss or charge to the user.  The energy bucket in the Mk2
      // Power Router was therefore to 0.001kWh, or 3600 Joules.  Moreover, its contents
      // were correctly pre-scaled to be in Joules.
      //
      // As described above, energy contributions for the Mk2a version are scaled somewhat
      // higher that for its floating point predecessor.  The capacity of the energy bucket for
      // Mk2a _rev3 thereore needs to be 3600J * 50 * (1/powerCal).  This is the value that
      // appears in setup().
   
   
      //----------------------------------------------------------------------------------
      // WARNING - Serial statements can interfere with time-critical code, use with care!
      //----------------------------------------------------------------------------------
/*     
      if(((cycleCount % 50) == 5) && polarityNow == POSITIVE) // display once per second
      {
        Serial.print(realPower_long);
        Serial.print(", ");
        Serial.print(energyInBucket_long);
        Serial.print(", ");
        Serial.println(energyInBucket_4led_long); // has no upper or lower limits
        energyInBucket_4led_long = 0; // useful for calibration/test purposes
      }
*/
      if (beyondStartUpPhase)
      { 
        // Providing that the initial settling time has passed,   
        // add this latest contribution to the energy bucket
        energyInBucket_long += realEnergy_long;   
        energyInBucket_4led_long += realEnergy_long;   
         
        // Apply max and min limits to bucket's level.  This is to ensure correct operation
        // when conditions change, i.e. when import changes to export, and vici versa
        //
        if (energyInBucket_long > capacityOfEnergyBucket_long)
        {
          energyInBucket_long = capacityOfEnergyBucket_long;
          digitalWrite(outputPinForLed, 1); // illuminate the on-board LED if bucket overflows
        }
        else
        {
          digitalWrite(outputPinForLed, 0); // clear the on-board LED if bucket is not overflowing
          if (energyInBucket_long < 0)
          {
            energyInBucket_long = 0;
          } 
        }
 
#ifdef TALLYMODE
        tallymode_updateData(realPower_long); // update the relevant tally
#endif
      }
      else
      { 
        // check whether the system had time to settle
        if(cycleCount > (startUpPeriod * CYCLES_PER_SECOND))
        {
          beyondStartUpPhase = true;
//        Serial.println ("go!");
        }
      }   
     
      // clear the per-cycle accumulators for use in this new mains cycle. 
      samplesDuringThisCycle = 0;
      sumP = 0;

    } // end of processing that is specific to the first Vsample in each +ve half cycle   
    else
    {     
      // This is the start of a new -ve half cycle (just after the zero-crossing point)
      //
      // This is a convenient point to update the Low Pass Filter for DC-offset removal ...
      long previousOffset = DCoffset_V_long;
      DCoffset_V_long = previousOffset + (0.01 * cumVdeltasThisCycle_long);
      cumVdeltasThisCycle_long = 0;
     
      // ... and prevent the LPF's output from drifting beyond the likely range of the voltage signal
      if (DCoffset_V_long < DCoffset_V_min) {
        DCoffset_V_long = DCoffset_V_min; }
      else 
      if (DCoffset_V_long > DCoffset_V_max) {
        DCoffset_V_long = DCoffset_V_max; }
           
      // The triac can change state at each -ve going zero crossing.  Update the state of a
      // flag which shows the current state of the triac (for anti-flicker mode logic)
      //     
      if (nextStateOfTriac == ON) {
        triacState = ON; }
      else { 
        triacState = OFF; }   
    } // end of processing that is specific to the first Vsample in each -ve half cycle
  }
 
  if (polarityNow == POSITIVE)
  {
    // for whole-cycle operation, the trigger is only armed during +ve half cycles
    if (triggerNeedsToBeArmed == true)
    {
      // check to see whether the trigger device can now be reliably armed
      if(voltageOKToArmTriggerFlag == true) 
      {
        if (operatingMode == NORMAL)
        {
          // check to see whether the energy threshold has been reached
          if (energyInBucket_long > energyThreshold_long)
          {
            nextStateOfTriac = ON; 
          }
          else
          {
            nextStateOfTriac = OFF;
          }
        }
        else
        {
          // We're in anti-flicker mode, so different logic applies ...
          //
          if (energyInBucket_long < antiFlicker_lowerEnergyThreshold)       
          {
            // when below the lower threshold, always turn the triac off
            nextStateOfTriac = OFF; 
          }
          else
          if (energyInBucket_long > antiFlicker_upperEnergyThreshold) // upper threshold     
          {
            // when above the upper threshold, ensure that the triac is on if permitted
            if (triacState != ON)
            {
              if (cycleCount > cycleCountAtLastActivation + minCycleCountsBetweenActivations)
              {
                nextStateOfTriac = ON;  // the external trigger device is active low
                cycleCountAtLastActivation = cycleCount;
              }
            }
          }
          else
          {
            // the energy level is between the upper and lower thresholds, so
            // leave the triac's state unchanged (anti-flicker measure)
          }         
        } // end of anti-flcker mode logic
                 
        // set the Arduino's output pin accordingly, and clear the flag
        digitalWrite(outputPinForTrigger, nextStateOfTriac);   
        triggerNeedsToBeArmed = false;     
      }
    }
  }
  else
  {
    // When the voltage polarity is negative, no special processing is needed.
  }

  // Rest of processing for ALL Vsamples
  //  (this has to go here because the counters / accumulators may have just been cleared)
  sumP +=instP; // cumulative power, scaling as for Mk2 (V_ADC x I_ADC)
  cumVdeltasThisCycle_long += sampleVminusDC_long; // for use with LP filter
  samplesDuringThisCycle++;
}
//  ----- end of main Mk2a code -----


#ifdef TALLYMODE
void tallymode_checks()
{
  if (tallymode_firstLoop) {
    tallymode_setup(); } // user-dialogue for recording energy data
  else
  if (cycleCount >= tallymode_maxCycleCount) {
    tallymode_dispatchData(); // send recorded energy data to the Serial monitor 
//    cycleCount = 0;
    tallymode_firstLoop = true;  // get ready for another run
    pause(); } // so that user can access data from the Serial monitor

  else
  if (beyondStartUpPhase) {
      tallymode_noOfSamplePairs++; }
}


void  tallymode_setup()
{
  char inbuf[10];
  int tempInt;
  byte noOfBytes;
  boolean done;

 // <-- start of commented out section to save on RAM space.
 /*
   Serial.println ("WELCOME TO TALLYMODE ");
  Serial.println ("This mode of operation allows the energy content of individual mains cycles");
  Serial.println ("to be analysed.  For nomal operation, the #define TALLYMODE statement");
  Serial.println ("should be commented out. ");
*/
   // <-- end of commented out section to save on RAM space.

  Serial.println (); 
  Serial.println ("Tallymode setup:"); 
  Serial.print ("Time to run (secs)? ");
  done = false;
  while (!done) {
    noOfBytes = Serial.available();
    if (noOfBytes > 0) { done = true; } else { delay(100); }}
  for (tempInt = 0; tempInt < 10; tempInt++) { inbuf[tempInt] = 0; }
  Serial.readBytes(inbuf, noOfBytes);
  tempInt = atoi(inbuf);  Serial.println (tempInt);
  tallymode_maxCycleCount = tempInt * CYCLES_PER_SECOND;
  tallymode_durationOfRecording = tempInt;
 
  Serial.print ("Min value (Watts)? ");
  done = false;
  while (!done) {
    noOfBytes = Serial.available();
    if (noOfBytes > 0) { done = true; } else { delay(100); }}
  for (tempInt = 0; tempInt < 10; tempInt++) { inbuf[tempInt] = 0; }
  Serial.readBytes(inbuf, noOfBytes);
  tempInt = atoi(inbuf);  Serial.println (tempInt);
  tallymode_minVal = tempInt;
//  Serial.print(" tallymode_minVal = "); Serial.println(tallymode_minVal);   
//  tallymode_minVal_long = tallymode_minVal * (1/powerCal); // used for power, not energy,
                                                           // hence there's no x100 term.
 
  Serial.print ("Max value (Watts)? ");
  done = false;
  while (!done) {
    noOfBytes = Serial.available();
    if (noOfBytes > 0) { done = true; } else { delay(100); }}
  for (tempInt = 0; tempInt < 10; tempInt++) { inbuf[tempInt] = 0; }
  Serial.readBytes(inbuf, noOfBytes);
  tempInt = atoi(inbuf);  Serial.println (tempInt);
  tallymode_maxVal = tempInt;
//  Serial.print(" tallymode_maxVal = "); Serial.println(tallymode_maxVal);   

  if (tallymode_maxVal <= tallymode_minVal) {
    Serial.print(7); // beep
    Serial.println ("ERROR!"); }
 
  tallymode_stepVal = (float)(tallymode_maxVal - tallymode_minVal) / NUMBER_OF_TALLIES;
//  Serial.print(" tallymode_stepVal = "); Serial.println(tallymode_stepVal);   
/*
  tallymode_stepVal_long = tallymode_stepVal * (1/powerCal); // used for power, not energy,
                                                             // hence there's no x50 term.
  tallymode_halfStep = (tallymode_stepVal_long / 2); // to avoid integer-rounding
*/

  for (tempInt = 0; tempInt < NUMBER_OF_TALLIES + 2; tempInt++) {
    tally[tempInt] = 0; }
   
  energyInBucket_long = (capacityOfEnergyBucket_long / 2); // for rapid startup of power distribution
  cycleCount = 0;
  tallymode_noOfValuesTallied = 0;
  tallymode_noOfSamplePairs = 0;
  beyondStartUpPhase = false; // to allow LPF to re-settle for next run
  tallymode_firstLoop = false;

  Serial.print(" Recording will start in ");
  Serial.print(startUpPeriod);   
  Serial.println(" seconds ... ");
 
 // startTime = millis();
};


void  tallymode_updateData(long power_long)
{
  float powerInWatts = power_long * powerCal;
  int index;
 
  if (powerInWatts < tallymode_minVal)
  {
    index = 0; // tally[0] is for underflow
  }
  else
  if (powerInWatts > tallymode_maxVal)
  {
    index = NUMBER_OF_TALLIES + 1; // tally[N+1] is for overflow
  }
  else
  {
    index = (powerInWatts - tallymode_minVal) / tallymode_stepVal;
    index += 1; // because the linear tallies run from 1 to N, not from 0
  }
 
  tally[index]++; // increment the relevant tally   
  tallymode_noOfValuesTallied++;
}


void  tallymode_dispatchData()
{
 
//   <<- start of commented out section, to save on RAM space!
/*   
  Serial.println ();
  Serial.println ("Format of results: ");
  Serial.print ("Sorted data runs from tally[1] (min) to tally[");
  Serial.print (NUMBER_OF_TALLIES);
  Serial.println ("] (max).");
  Serial.print ("tally[0] is below range; tally[ ");
  Serial.print (NUMBER_OF_TALLIES + 1);
  Serial.println ("] is above range.");
  Serial.println("Tally results are displayed with max power first. For each one:");
  Serial.println("  mid-range power of tally (Watts), number of times recorded.");
  Serial.println();
*/   
//   <<- end of commented out section, to save on RAM space!
 
  Serial.println("Results for this run:");
  Serial.print (tallymode_minVal);
  Serial.println (", <- min value of tally range (W)");
  Serial.print (tallymode_maxVal);
  Serial.println (", <- max value of tally range (W)");
  Serial.print (tallymode_stepVal);
  Serial.println (", <- step value between tallies (W)");
  Serial.print (NUMBER_OF_TALLIES);
  Serial.println (", <- No. of tallies");
  Serial.print (tallymode_durationOfRecording);
  Serial.println (", <- duration (secs)");
  Serial.print (tallymode_noOfValuesTallied);
  Serial.println (", <- no of values tallied");
  Serial.print ( tallymode_noOfSamplePairs /
    ((float)tallymode_durationOfRecording * CYCLES_PER_SECOND), 1);
  Serial.println (", <- loops per mains cycle (av)");
  Serial.println("***");
 
  float powerVal;
  for (int index = NUMBER_OF_TALLIES + 1; index >= 0; index--)
  {
/* 
    // display the index value for this tally
    Serial.print (index);
    Serial.print (", ");
*/   
    // display the power value for this tally
    if (index == NUMBER_OF_TALLIES + 1)
    {
      Serial.print (">");
      Serial.print (tallymode_maxVal);
    }
    else
    if (index == 0)
    {
      Serial.print ("<");
      Serial.print (tallymode_minVal);
    }
    else 
    {
      if (index == NUMBER_OF_TALLIES)
      {
        powerVal = tallymode_maxVal - (tallymode_stepVal / 2);
      }
      else
      {
        powerVal -= tallymode_stepVal;
      }
     
      if ((int)powerVal == powerVal)
      {
        Serial.print (powerVal, 0); // to suppress the decimal part for integers
      }
      else
      {
        Serial.print (powerVal);  // non-integers are displayed to 2 dec places
      }
    } 
    Serial.print ("W");

    // display the number of hits for this tally
    Serial.print (", ");
    Serial.println (tally[index]); 
  }
};


void pause()
{
  byte done = false;
  byte dummyByte;
   
  while (done != true)
  {
    if (Serial.available() > 0) {
      dummyByte = Serial.read(); // to 'consume' the incoming byte
      if (dummyByte == 'g') done++; }
  }   
}
#endif


// helper function, to process LED events, can be conveniently called once per mains cycle
void checkLedStatus()
{
  ledState = digitalRead (ledDetectorPin);

  if (ledState != prevLedState)
  {
    // led has changed state
    if (ledState == ON)
    {
      // led has just gone on
      ledOnAt = millis();
      ledRecentlyOnFlag = true;
    }
    else
    {
      // led has just gone off   
      if (ledRecentlyOnFlag == true)
      {
        ledRecentlyOnFlag = false;       
        Serial.print ("** LED PULSE ** "); // this is a chargeable event 
      }
      else
      {
        Serial.print ("** LED OFF ** "); // 'no longer exporting' is also a chargeable event
      }
      Serial.println(millis()/1000);
    }   
  }
  else
  {
    // the LED state has not changed
    if (ledState == ON)
    {
      if (ledRecentlyOnFlag == true)
      {
        // check to see if the known duration of a pulse has been exceeded   
        unsigned long timeNow = millis();     
        if ((timeNow - ledOnAt) > 50)
        {
          Serial.print ("** LED ON **");  // 'exporting' is a non-chargeable state     
          Serial.print (",  energy in bucket = ");
          Serial.println((long)(energyInBucket_4led_long));
          ledRecentlyOnFlag = false;   
        }     
      }
    }
  }
  prevLedState = ledState;   
}
Onko sinulla netottava sähkömittari/siirto-operaattori ja jollei ole, onko operaattorin kirjaamat tuntilukemat kulutuksen ja tuoton osalta linjassa mittaamiesi käyrien kanssa? Toisekseen, millainen on puolijohdereleesi? Olen nähnyt sekä nollapistekytkimellä että vaihekulmasäädöllä toimivia "portaattomia" relehybridipiirejä. Voisi jopa ajatella sähkövastuksen ohjaamista IGBT:llä huomattavasti verkkotaajuutta suuremmalla taajuudella (luokkaa kilohertzejä). Kaksi viimeksi mainittua ratkaisua toimisivat myös ei-netotetulla sähkömittarilla toivotulla tavalla.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: jolla - 02.11.18 - klo:20:54
^

tuollaisia
http://www.fotek.com.hk/solid/SSR-1.htm

sähkön siirrosta vastaava operaattori lukee vain kulutuksen, ei ole netotusta....mittari, E450 lukee kylläkin kulutuksen/tuoton eri rekistereihin muttei vaiheittain

operaattorin lukemat ovat täysin linjassa inverttereiden lukemien kanssa, myös omien mittausten, menee kaheden oman erillisen mittarin läpi, landis gyr ja em111

niin, ja yksivaiheisena kaikki 'toiminta'.....3*25 päänallit nyt
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: Harpi - 02.11.18 - klo:21:01
Ompa hyvä ketju tässä.

Oma järjestelmä on laajentunut tässä vuosien myötä ja alkaa olla aika monimutkainen eri variaatioilla.
Puukattila pellettipolttimolla, 1200L päävaraaja, 300L käyttövesivaraaja joka lämpenee kesäisin sähköllä.
Päävaraaja lämpenee pelletillä, tuulivoimalla tai varalla verkkosähkö. Käyttövesivaraajan tulo on päävaraajan
kautta, vastus toimii tuulivoimalla tai verkkosähköllä. Koko pakettia ohjaa logiikka eri variaatioilla.
Verkkoonsyöttävät aurinkopaneelit tuli asennettua kesällä ja nyt on aurinko-optimointi rakenteilla.
Pelletti jää kohta pois ja tilalle ehkä ilma/vesi pumppu joka pitää olla ulkoisesti ohjattavissa optimoinnin takia.
Täällä on Wattenfall/Elenia ISKRA:n mittari ja data tuosta on olematonta. Onko kukaan kokeillut ssr/pwm ohjausta tuolle?
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: kotte - 02.11.18 - klo:23:20
sähkön siirrosta vastaava operaattori lukee vain kulutuksen, ei ole netotusta....mittari, E450 lukee kylläkin kulutuksen/tuoton eri rekistereihin muttei vaiheittain

operaattorin lukemat ovat täysin linjassa inverttereiden lukemien kanssa, myös omien mittausten, menee kaheden oman erillisen mittarin läpi, landis gyr ja em111

niin, ja yksivaiheisena kaikki 'toiminta'.....3*25 päänallit nyt
Ovatko nuo omat mittarisi elektronisia vai mekaanisia? Mekaaninenhan vähentää tuoton kulutuksesta. Mietin sellaistakin mahdollisuutta, että jotkin mittarit saattaisivat todellakin sisältää sellaisen laitteiston ja ohjelmiston, joka ikään kuin emuloi tuollaista mekaanista mittaria, eli tuossa olisi jonkinlaista kulutuksen ja tuoton integrointia useamman vaiheen ylitse. Ratkaisu voisi olla esimerkiksi sellainen, että tehon laskenta ja integrointi (lyhyehkön jakson ylitse) tehdään analogiapiireillä ja vain kulutuksen kvantisointi ja laskenta digitaalisesti. Vedän tässä siis hiukan takaisin aikaisempien viestieni näkemystä.

En kyllä menisi luottamaan tuollaisiin ominaisuuksiin, eli jonkin toisen mittarin kohdalla tilanne saattaa olla ihan erilainen ja laskenta tehdään digitaalisesti suoraan näytteistämällä hetkittäistä jännitettä ja virtaa (tai ainakin aikavakiot ovat lyhyempiä). Jonkin uuden mittarisukupolven tapauksessa jopa saattaa kulutuksen ja tuoton netotus eri vaiheiden välillä tulla käyttöön, mutta nollapistekytkennän edellyttämällä matalalla taajuudella tehty pulssinleveysmoduloitu tehon säätö rupeaakin erottelemaan kulutukset ja tuotot puolijaksokohtaisten mittausten mukaisesti.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: tengu - 03.11.18 - klo:07:42

En kyllä menisi luottamaan tuollaisiin ominaisuuksiin, eli jonkin toisen mittarin kohdalla tilanne saattaa olla ihan erilainen ja laskenta tehdään digitaalisesti suoraan näytteistämällä hetkittäistä jännitettä ja virtaa (tai ainakin aikavakiot ovat lyhyempiä). Jonkin uuden mittarisukupolven tapauksessa jopa saattaa kulutuksen ja tuoton netotus eri vaiheiden välillä tulla käyttöön, mutta nollapistekytkennän edellyttämällä matalalla taajuudella tehty pulssinleveysmoduloitu tehon säätö rupeaakin erottelemaan kulutukset ja tuotot puolijaksokohtaisten mittausten mukaisesti.

Eihän tuolla ole väliä jos mittari laskee tuolla ns "energybucket" periaatteella? Ämpärissä pinta laskee ja nousee vaan vasta kun tyhjä tai tulvii niin menee mittapulssi rekisteriin.

Mahtaako olla paljonkin erilaisia sähkömittareita asennettuna eri alueille? Täällä Carunan alueella mittari ainakin pysyy hyvin nollilla, vaikka ajan täysiä puolijaksoja. Vattenfallin energywatch lukee mittarin silmää ja tuo lukee kulutukseksi niin kulutuksen kuin tuoton (jos menee verkkoon). Kun vertaan Carunan seurantaa ja energywatchia niin 0.01-0.02 kWh sisällä on samat lukemat.

Ainakin 2kWn kuormalla toimii vielä hyvin mutta en ole testannut isommalla.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: jolla - 03.11.18 - klo:10:48

Ovatko nuo omat mittarisi elektronisia vai mekaanisia? Mekaaninenhan vähentää tuoton kulutuksesta. Mietin sellaistakin mahdollisuutta, että jotkin mittarit saattaisivat todellakin sisältää sellaisen laitteiston ja ohjelmiston, joka ikään kuin emuloi tuollaista mekaanista mittaria, eli tuossa olisi jonkinlaista kulutuksen ja tuoton integrointia useamman vaiheen ylitse. Ratkaisu voisi olla esimerkiksi sellainen, että tehon laskenta ja integrointi (lyhyehkön jakson ylitse) tehdään analogiapiireillä ja vain kulutuksen kvantisointi ja laskenta digitaalisesti. Vedän tässä siis hiukan takaisin aikaisempien viestieni näkemystä.

En kyllä menisi luottamaan tuollaisiin ominaisuuksiin, eli jonkin toisen mittarin kohdalla tilanne saattaa olla ihan erilainen ja laskenta tehdään digitaalisesti suoraan näytteistämällä hetkittäistä jännitettä ja virtaa (tai ainakin aikavakiot ovat lyhyempiä). Jonkin uuden mittarisukupolven tapauksessa jopa saattaa kulutuksen ja tuoton netotus eri vaiheiden välillä tulla käyttöön, mutta nollapistekytkennän edellyttämällä matalalla taajuudella tehty pulssinleveysmoduloitu tehon säätö rupeaakin erottelemaan kulutukset ja tuotot puolijaksokohtaisten mittausten mukaisesti.

tuota, tuota...enhän olekaan kokeillut tulemaa, kun irrotan säätimet, elikkä sammutan arduinot, ja annan panelien tuottaa ylimääräistä vaiheeseen ja kuormitan, vaikkapa kokeeksi manuaalisesti, kun on noita portaattomasti säädettäviä testi laitteita, toista vaihetta.....en todellakaan tiedä jospa se vaikka netottaa....kuten vanhat kiekkomittarit......no en usko mutta kokeilen
landiksen e450 välly mittaa kylläkin pulssit identtisesti molempiin suuntiin kun taasen em111 kulutuksessa välkkyy mutta toiseen suuntaan palaa koko ajan, ~10v ikäinen landis kiekko pyörii todellakin molempiin suuntiin, se olisi ollut 'kova sana' päämittarina
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: jolla - 05.11.18 - klo:16:02
kyllä mittari ainakin reagoi kun yhdestä vaiheestä tuotto ja toisesta kulutus
kun käänsin potikasta kuormaa alle tuoton, nuoli näytti kiinteästi tuottoa
kun käänsin kuorman yli tuoton, nuoli alkoi vilkkumaan
huomenna näkee ehkä, kun tuotto on vain puolen kilowatin luokkaa, jäänee tarkempi analysointi kunnes aurinko taasen läkättää
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: jolla - 06.11.18 - klo:09:54
hiukan hatarilla mittauksilla, mutta kuitenkin näyttäyttäisi että landiksen e450 "kiekko" pyörisi operaattorin mittausrekistereissä molempiin suuntiin, elikkä netottaisi tuntilukeman vaiheiden kesken
helppo tuo on todeta kunhan kelit sallii
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 13.03.19 - klo:19:20
Nyt kun alkaa taas olla jotain säädettävää niin kyselin omalta sähköyhtiöltä tuota netotus asiaa ja vastaus oli.
"Mittari osaa myös netottaa, mutta netotusta ei tällä hetkellä ole käytössä."
Eli SSR ja pulssinleveys tehonsäätö ei toimi laskutuksen kannalta.
Täytynee miettiä jotain muuta.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: Sähköala - 07.07.19 - klo:12:49
Tätä keskustelua seuranneena herää kysymys että onko tärkeämpää saada tehtyä laitteita itse harrastusmielessä vai saada sähkönkulutus hallittua. Rakentelu on varmasti hyvä harrastus ja sopii niille kellä tietotaito ja aika riittää. Sähkönkulutuksen hallintaan sen sijaan on invertterivalmistajilla valmiit ja toimivat ratkaisut olemassa, joten miksi ei käyttäisi niitä?
Esim. Froniuksen invertterin kaveriksi saa saman tehtaan SmartMeterin ja Ohmpilotin jotka hoitavat mittaukset, kuormien tehonsäädöt ja tapahtumien seurannan sekä raportoinnit yhteensopivasti ja ilman tuskailuja. Ei myöskään tule ongelmia taloa myydessä.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: rotzi - 07.07.19 - klo:13:12
Tätä keskustelua seuranneena herää kysymys että onko tärkeämpää saada tehtyä laitteita itse harrastusmielessä vai saada sähkönkulutus hallittua. Rakentelu on varmasti hyvä harrastus ja sopii niille kellä tietotaito ja aika riittää. Sähkönkulutuksen hallintaan sen sijaan on invertterivalmistajilla valmiit ja toimivat ratkaisut olemassa, joten miksi ei käyttäisi niitä?
Esim. Froniuksen invertterin kaveriksi saa saman tehtaan SmartMeterin ja Ohmpilotin jotka hoitavat mittaukset, kuormien tehonsäädöt ja tapahtumien seurannan sekä raportoinnit yhteensopivasti ja ilman tuskailuja. Ei myöskään tule ongelmia taloa myydessä.
Niin kauan kun netotus ei pelaa noista oikein ole hyötyä, saattaa kääntyä jopa lisääntyvän kulutuksen puolelle...
Ellei ole sitten ihan järin suuri systeemi kyseessä.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: Sähköala - 07.07.19 - klo:18:47
Kuitenkin tässä puhutaan samoista tehonsäädöistä, jotka voisi hoitaa ymmärtääksei näin?
https://www.fronius.com/~/downloads/Solar%20Energy/Whitepaper/SE_WP_Energy_flow_management_using_the_four_digital_outputs_EN.pdf
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 08.07.19 - klo:06:21
Kuitenkin tässä puhutaan samoista tehonsäädöistä, jotka voisi hoitaa ymmärtääksei näin?
https://www.fronius.com/~/downloads/Solar%20Energy/Whitepaper/SE_WP_Energy_flow_management_using_the_four_digital_outputs_EN.pdf
Voisiko joku suomentaa mitä tuossa dokumentissa oikein selitetään?
Ainakin minun huonolla englannin taidolla en saa tuosta mitään tolkkua.
Jotenkin minulle kuitenkin jäi mielikuva että ei tuossa mitään todellista säätöä ole, vain on/off kytkentöjä.
Ja se invertterin ominaisuus minulla jo on käytössä, rele ON 2000w, OFF 1500w.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: Sähköala - 08.07.19 - klo:10:58
Kyllä siinä on portaaton säätö 0-9 kw välille, siten että 0-3 kw on säädettävää ja kun rajat ylittyy niin kytkee aina 3kw kiinteää lisää pohjakuormaksi. Esim jos tehoa käytössä 4,16kw niin kytkee 3kw releellä ja 1,16 säätimellä.
Tässä animaationa https://m.youtube.com/watch?v=y3-ZabgaRnw

Tuon saa skaalattua 18kw asti jos on järeämpi panelisto.
Kytkentä
https://www.fronius.com/~/downloads/Solar%20Energy/Whitepaper/SE_WP_Fronius_Ohmpilot-Continuous_Control_up_to_18kW_EN.pdf

Joissain maissa ei saa/kannata työntää verkkoon päin mitään joten nämä osaavat säätää tarvittaessa kuorman ja tuotannon toisiaan vastaavaksi.

Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: rotzi - 08.07.19 - klo:12:07
Kyllä siinä on portaaton säätö 0-9 kw välille, siten että 0-3 kw on säädettävää ja kun rajat ylittyy niin kytkee aina 3kw kiinteää lisää pohjakuormaksi. Esim jos tehoa käytössä 4,16kw niin kytkee 3kw releellä ja 1,16 säätimellä.
Tässä animaationa https://m.youtube.com/watch?v=y3-ZabgaRnw

Tuon saa skaalattua 18kw asti jos on järeämpi panelisto.
Kytkentä
https://www.fronius.com/~/downloads/Solar%20Energy/Whitepaper/SE_WP_Fronius_Ohmpilot-Continuous_Control_up_to_18kW_EN.pdf

Joissain maissa ei saa/kannata työntää verkkoon päin mitään joten nämä osaavat säätää tarvittaessa kuorman ja tuotannon toisiaan vastaavaksi.
Netottavassa portaaton mutta ei portaaton ei nettottavassa systeemissä...oikeastaan myrkkyä ei netottavaan tai vaatii tarkkaa syyniä kuinka laittelee minkäkin mihin vaiheeseen...
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 08.07.19 - klo:15:58
Kyllä siinä on portaaton säätö 0-9 kw välille, siten että 0-3 kw on säädettävää ja kun rajat ylittyy niin kytkee aina 3kw kiinteää lisää pohjakuormaksi. Esim jos tehoa käytössä 4,16kw niin kytkee 3kw releellä ja 1,16 säätimellä.
Tässä animaationa https://m.youtube.com/watch?v=y3-ZabgaRnw

Tuon saa skaalattua 18kw asti jos on järeämpi panelisto.
Kytkentä
https://www.fronius.com/~/downloads/Solar%20Energy/Whitepaper/SE_WP_Fronius_Ohmpilot-Continuous_Control_up_to_18kW_EN.pdf

Joissain maissa ei saa/kannata työntää verkkoon päin mitään joten nämä osaavat säätää tarvittaessa kuorman ja tuotannon toisiaan vastaavaksi.

Onkohan tuossa kuitenkin portaaton säätö vain yhdelle vaiheelle? 3 vaihe systeemissä se ei riitä,
vaan säätö täytyy olla jokaiselle vaiheelle erikseen.
Niin ja onko tietoa millaista tekniikkaa tuohon säätöön on käytetty?
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: rotzi - 08.07.19 - klo:16:34
Kyllä siinä on portaaton säätö 0-9 kw välille, siten että 0-3 kw on säädettävää ja kun rajat ylittyy niin kytkee aina 3kw kiinteää lisää pohjakuormaksi. Esim jos tehoa käytössä 4,16kw niin kytkee 3kw releellä ja 1,16 säätimellä.
Tässä animaationa https://m.youtube.com/watch?v=y3-ZabgaRnw

Tuon saa skaalattua 18kw asti jos on järeämpi panelisto.
Kytkentä
https://www.fronius.com/~/downloads/Solar%20Energy/Whitepaper/SE_WP_Fronius_Ohmpilot-Continuous_Control_up_to_18kW_EN.pdf

Joissain maissa ei saa/kannata työntää verkkoon päin mitään joten nämä osaavat säätää tarvittaessa kuorman ja tuotannon toisiaan vastaavaksi.

Onkohan tuossa kuitenkin portaaton säätö vain yhdelle vaiheelle? 3 vaihe systeemissä se ei riitä,
vaan säätö täytyy olla jokaiselle vaiheelle erikseen.
Niin ja onko tietoa millaista tekniikkaa tuohon säätöön on käytetty?
Mielestäni joku tuota selvitti että toimii esim niin että (vaiheista en tiedä mikä säätyy)
L1: säätyy 0-3kW portaattomasti, kun Fronius yrittäisi syöttää tuota verkkoon 3 vaiheisesti, eli se verkkoon muka 'menevä' 3~0-3kW muuntuu yksivaihe tehoksi 0-3kW.
L2: Hyppää 0>3kW kun L1 on > 3kW ja yhdessä L1&L2 säätyvät välin 3-6kW portaattomasti, eli tuona aikana L2 kuorma vakio 3kW.
L3: Hyppää 0>3kW kun L1+L2 >6kW ja yhdessä L1&L2L3 säätyvät välin 6-9kW portaattomasti, eli tuona aikana L2 kuorma vakio 3kW samaten L3 kuorma vakio 3kW.
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 09.07.19 - klo:06:28
Kyllä siinä on portaaton säätö 0-9 kw välille, siten että 0-3 kw on säädettävää ja kun rajat ylittyy niin kytkee aina 3kw kiinteää lisää pohjakuormaksi. Esim jos tehoa käytössä 4,16kw niin kytkee 3kw releellä ja 1,16 säätimellä.
Tässä animaationa https://m.youtube.com/watch?v=y3-ZabgaRnw

Tuon saa skaalattua 18kw asti jos on järeämpi panelisto.
Kytkentä
https://www.fronius.com/~/downloads/Solar%20Energy/Whitepaper/SE_WP_Fronius_Ohmpilot-Continuous_Control_up_to_18kW_EN.pdf

Joissain maissa ei saa/kannata työntää verkkoon päin mitään joten nämä osaavat säätää tarvittaessa kuorman ja tuotannon toisiaan vastaavaksi.

Onkohan tuossa kuitenkin portaaton säätö vain yhdelle vaiheelle? 3 vaihe systeemissä se ei riitä,
vaan säätö täytyy olla jokaiselle vaiheelle erikseen.
Niin ja onko tietoa millaista tekniikkaa tuohon säätöön on käytetty?
Mielestäni joku tuota selvitti että toimii esim niin että (vaiheista en tiedä mikä säätyy)
L1: säätyy 0-3kW portaattomasti, kun Fronius yrittäisi syöttää tuota verkkoon 3 vaiheisesti, eli se verkkoon muka 'menevä' 3~0-3kW muuntuu yksivaihe tehoksi 0-3kW.
L2: Hyppää 0>3kW kun L1 on > 3kW ja yhdessä L1&L2 säätyvät välin 3-6kW portaattomasti, eli tuona aikana L2 kuorma vakio 3kW.
L3: Hyppää 0>3kW kun L1+L2 >6kW ja yhdessä L1&L2L3 säätyvät välin 6-9kW portaattomasti, eli tuona aikana L2 kuorma vakio 3kW samaten L3 kuorma vakio 3kW.
Fronius invertteri tuottaa aina jokaiselle vaiheelle samanverran. Mikä palikka tuossa OhmPilotissa on se joka osaa ohjata muiden vaiheiden ylimäärän yhdelle vaiheelle?
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: rotzi - 09.07.19 - klo:06:54
Kyllä siinä on portaaton säätö 0-9 kw välille, siten että 0-3 kw on säädettävää ja kun rajat ylittyy niin kytkee aina 3kw kiinteää lisää pohjakuormaksi. Esim jos tehoa käytössä 4,16kw niin kytkee 3kw releellä ja 1,16 säätimellä.
Tässä animaationa https://m.youtube.com/watch?v=y3-ZabgaRnw

Tuon saa skaalattua 18kw asti jos on järeämpi panelisto.
Kytkentä
https://www.fronius.com/~/downloads/Solar%20Energy/Whitepaper/SE_WP_Fronius_Ohmpilot-Continuous_Control_up_to_18kW_EN.pdf

Joissain maissa ei saa/kannata työntää verkkoon päin mitään joten nämä osaavat säätää tarvittaessa kuorman ja tuotannon toisiaan vastaavaksi.

Onkohan tuossa kuitenkin portaaton säätö vain yhdelle vaiheelle? 3 vaihe systeemissä se ei riitä,
vaan säätö täytyy olla jokaiselle vaiheelle erikseen.
Niin ja onko tietoa millaista tekniikkaa tuohon säätöön on käytetty?
Mielestäni joku tuota selvitti että toimii esim niin että (vaiheista en tiedä mikä säätyy)
L1: säätyy 0-3kW portaattomasti, kun Fronius yrittäisi syöttää tuota verkkoon 3 vaiheisesti, eli se verkkoon muka 'menevä' 3~0-3kW muuntuu yksivaihe tehoksi 0-3kW.
L2: Hyppää 0>3kW kun L1 on > 3kW ja yhdessä L1&L2 säätyvät välin 3-6kW portaattomasti, eli tuona aikana L2 kuorma vakio 3kW.
L3: Hyppää 0>3kW kun L1+L2 >6kW ja yhdessä L1&L2L3 säätyvät välin 6-9kW portaattomasti, eli tuona aikana L2 kuorma vakio 3kW samaten L3 kuorma vakio 3kW.
Fronius invertteri tuottaa aina jokaiselle vaiheelle samanverran. Mikä palikka tuossa OhmPilotissa on se joka osaa ohjata muiden vaiheiden ylimäärän yhdelle vaiheelle?
Smart meter mittaa ja Ohmpilot kytkee sähköä/vaiheita edellä kuvatusti lämmitysvastukseen...
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: pere - 09.07.19 - klo:07:58
Kyllä siinä on portaaton säätö 0-9 kw välille, siten että 0-3 kw on säädettävää ja kun rajat ylittyy niin kytkee aina 3kw kiinteää lisää pohjakuormaksi. Esim jos tehoa käytössä 4,16kw niin kytkee 3kw releellä ja 1,16 säätimellä.
Tässä animaationa https://m.youtube.com/watch?v=y3-ZabgaRnw

Tuon saa skaalattua 18kw asti jos on järeämpi panelisto.
Kytkentä
https://www.fronius.com/~/downloads/Solar%20Energy/Whitepaper/SE_WP_Fronius_Ohmpilot-Continuous_Control_up_to_18kW_EN.pdf

Joissain maissa ei saa/kannata työntää verkkoon päin mitään joten nämä osaavat säätää tarvittaessa kuorman ja tuotannon toisiaan vastaavaksi.

Onkohan tuossa kuitenkin portaaton säätö vain yhdelle vaiheelle? 3 vaihe systeemissä se ei riitä,
vaan säätö täytyy olla jokaiselle vaiheelle erikseen.
Niin ja onko tietoa millaista tekniikkaa tuohon säätöön on käytetty?
Mielestäni joku tuota selvitti että toimii esim niin että (vaiheista en tiedä mikä säätyy)
L1: säätyy 0-3kW portaattomasti, kun Fronius yrittäisi syöttää tuota verkkoon 3 vaiheisesti, eli se verkkoon muka 'menevä' 3~0-3kW muuntuu yksivaihe tehoksi 0-3kW.
L2: Hyppää 0>3kW kun L1 on > 3kW ja yhdessä L1&L2 säätyvät välin 3-6kW portaattomasti, eli tuona aikana L2 kuorma vakio 3kW.
L3: Hyppää 0>3kW kun L1+L2 >6kW ja yhdessä L1&L2L3 säätyvät välin 6-9kW portaattomasti, eli tuona aikana L2 kuorma vakio 3kW samaten L3 kuorma vakio 3kW.
Fronius invertteri tuottaa aina jokaiselle vaiheelle samanverran. Mikä palikka tuossa OhmPilotissa on se joka osaa ohjata muiden vaiheiden ylimäärän yhdelle vaiheelle?
Smart meter mittaa ja Ohmpilot kytkee sähköä/vaiheita edellä kuvatusti lämmitysvastukseen...
Mutta sittenkään en ymmärrä paitsi jos invertterissä on kuitenkin salainen ominaisuus jolla mittauksen perusteella voidaankin erivaiheille ohjata enemmän tai vähemmän tarpeen mukaan. Tai sitten oletetaan että vaihenetotus on käytössä.
Tai vielä että minä olen ihan pihalla koko asiasta!
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: rotzi - 09.07.19 - klo:10:27
Kyllä siinä on portaaton säätö 0-9 kw välille, siten että 0-3 kw on säädettävää ja kun rajat ylittyy niin kytkee aina 3kw kiinteää lisää pohjakuormaksi. Esim jos tehoa käytössä 4,16kw niin kytkee 3kw releellä ja 1,16 säätimellä.
Tässä animaationa https://m.youtube.com/watch?v=y3-ZabgaRnw

Tuon saa skaalattua 18kw asti jos on järeämpi panelisto.
Kytkentä
https://www.fronius.com/~/downloads/Solar%20Energy/Whitepaper/SE_WP_Fronius_Ohmpilot-Continuous_Control_up_to_18kW_EN.pdf

Joissain maissa ei saa/kannata työntää verkkoon päin mitään joten nämä osaavat säätää tarvittaessa kuorman ja tuotannon toisiaan vastaavaksi.

Onkohan tuossa kuitenkin portaaton säätö vain yhdelle vaiheelle? 3 vaihe systeemissä se ei riitä,
vaan säätö täytyy olla jokaiselle vaiheelle erikseen.
Niin ja onko tietoa millaista tekniikkaa tuohon säätöön on käytetty?
Mielestäni joku tuota selvitti että toimii esim niin että (vaiheista en tiedä mikä säätyy)
L1: säätyy 0-3kW portaattomasti, kun Fronius yrittäisi syöttää tuota verkkoon 3 vaiheisesti, eli se verkkoon muka 'menevä' 3~0-3kW muuntuu yksivaihe tehoksi 0-3kW.
L2: Hyppää 0>3kW kun L1 on > 3kW ja yhdessä L1&L2 säätyvät välin 3-6kW portaattomasti, eli tuona aikana L2 kuorma vakio 3kW.
L3: Hyppää 0>3kW kun L1+L2 >6kW ja yhdessä L1&L2L3 säätyvät välin 6-9kW portaattomasti, eli tuona aikana L2 kuorma vakio 3kW samaten L3 kuorma vakio 3kW.
Fronius invertteri tuottaa aina jokaiselle vaiheelle samanverran. Mikä palikka tuossa OhmPilotissa on se joka osaa ohjata muiden vaiheiden ylimäärän yhdelle vaiheelle?
Smart meter mittaa ja Ohmpilot kytkee sähköä/vaiheita edellä kuvatusti lämmitysvastukseen...
Mutta sittenkään en ymmärrä paitsi jos invertterissä on kuitenkin salainen ominaisuus jolla mittauksen perusteella voidaankin erivaiheille ohjata enemmän tai vähemmän tarpeen mukaan. Tai sitten oletetaan että vaihenetotus on käytössä.
Tai vielä että minä olen ihan pihalla koko asiasta!
Nyt en niin tarkkaa tiedä Froniusta missä tuo äly on mutta luulen että invertterissä ja Ohmpilot on vain toteuttava HW porrasta  'duunariosastoa' tuolle toiminnallisuudelle.
Luulen että tässä pohjimmainen lähtökohta Froniuksella on ollut että missään ei voi olla niin tyhmiä ihmisiä että netottamaton systeemi saadaan menemään läpi, ylläri pylläri Suomessa on  ;)
Otsikko: Vs: lämminvesivaraajan tehonsäätö
Kirjoitti: kotte - 09.07.19 - klo:14:13
Ei-netottavaan järjestelmään ei ikinä kannattaisi kytkeä kolmivaiheinvertteriä muutenkaan (kolmivaiheinvertteri työntää aina saman tehon eri vaiheisiin), vaan kuhunkin vaiheeseen oma yksivaiheinvertteri (jolloin toki paneeleiden jakokytkentäperiaatteet voisivat olla hankala ratkaista hyvin tai tyydyttävästi). Tuo Froniuksen edellä esillä ollut kytkentäratkaisu olisi ihan käyttökelpoinen yksivaiheinvertterin tapauksessa, vaikka sitten vaihekohtaisesti monistettuna. Kolmivaiheista varaajaahan voisi mainiosti syöttää niin, että joka vaihetta syötetään eri lähteestä, kunhan nollajohto korvataan 3-kertaa paksummalla ja joka vastuselementiltä ja ohjaimelta vedetään oma 0-johto yhteiseen tähtipisteeseen (tai sitten eri vaiheiden johditukset pidetään kokonaan erillisinä, mikä on ehkä helpompi hallita ja dokumentoida).

Toinen vaihtoehto olisi kolmivaiheisesti toimiva oman tuotannon ohjaus (Froniuksen tapaan kolmivaiheisena), tarvittaessa myös tasasuunnattuna niin, että ohjattu teho voidaan syöttää myös yksivaihekuumentimeen tasavirtana. Tuo sitten edellyttää, että laitteessa on aidot tasavirtatermostaatit ylikuumenemissuojana, koska kolmivaiheinen tasasuuntaustulos ei välttämättä käy jaksojen aikana lainkaan nollassa. Hankalaa ja kallista tuo joka tapauksessa olisi. Siis jos on ei-netotus ja kolmivaiheverkkoinvertteri, suo siellä, vetelä täällä.