Domotica (DSMR, IOT, MQTT, etc.)

[cousin_IT]

Even de balans opmaken. Ik wil graag een load balancer bouwen die de huidige stroomwaardes (hoeveel ampere per fase) uitleest van DSMR Reader (via MQTT of iets anders) en daaropvolgend de Tesla Wall Connector middels RS485 aanstuurt. Dankzij alle tips hier heb ik het volgende gevonden:

• GitHub - RichieB2B/tesla-loadbalancer: Loadbalancer for charging Tesla vehicles at home van @RichieB die DSMR uitleest maar de Tesla API gebruikt voor het bijsturen
• GitHub - RSP267/TWC: Domoticz plugin for the Tesla Wall Connector (dank @xtremerox) die de TWC met RS485 aanstuurt vanuit Domoticz maar ik heb geen oplossing gevonden om daar de stroomwaardes naartoe te sturen (de P1 poort zit fysiek op een andere locatie bij mij)
• GitHub - ngardiner/TWCManager: Control power delivered by a Tesla Wall Charger using two wires screwed into its RS-485 terminals. Die goed de opbrengst van zonnepanelen kan tracken en via RS485 communiceert met de TWC maar niet geschikt is voor load balancing
• En de code van @ramonneke in C# die me helaas boven de pet gaat maar ook gebruik maakt van de API

Rest mij niets anders dan Python te leren en van de eerste 2 een eigen oplossing te maken. Kan wel ff duren

 

[wooter]

En de code van @wooter in C# die me helaas boven de pet gaat maar ook gebruik maakt van de API

Dat was @ramonneke . Ik doe geen C#

Ik gebruik Node-RED om de MQTT-signalen die het verbruik doorgeven, te berekenen en dan door te sturen als MQTT-signalen naar TWCManager.

Die Node-RED kan je op dezelfde Raspberry Pi van je TWCManager draaien.

 

[cousin_IT]

Dat was @ramonneke . Ik doe geen C#

Ik gebruik nodeRED om de MQTT-signalen die het verbruik doorgeven, te berekenen en dan door te sturen als MQTT-signalen naar TWCManager.

Bij deze aangepast Ik zie die mogelijkheid ook wel maar dan wordt het dus DSMR -> MQTT -> NodeRed -> TWCManager. Ik zou het liever met minder stappen doen.

 

[wooter]

TWCManager accepteert zonder plugin enkel MQTT-signalen die TWCManager dirigeren hoeveel ampere ie moet toelaten. Het berekening-component moet je dus inbouwen als een extra plugin voor TWCManager, of ergens anders laten berekenen. Ja, je kan het ook in een apart python-scriptje doen die MQTT-signalen leest, berekent en uitstuurt. Maar ik heb zo een scriptje nooit klaar gekregen en Node-RED is pijltjes trekken en sommen maken.

Ik bekijk welke van de 3 fases de laagste voltage geeft, en berekenen dat met het maximum aan wattage dat er door de fases gaat, om te berekenen hoeveel ampere er nog beschikbaar is. En dat stuur ik dan door naar TWCManager.

 

[RichieB]

@wooter Dat is echt heel omslachtig en onnauwkeurig. Je hoofdzekering reageert op stroomsterkte in Amperes. De TWC vertelt de auto hoeveel Ampere die maximaal mag gebruiken. TWCManager veracht kennelijk vermogen in Watt. Je gaan nu berekeningen doen om van Ampere naar Watt te gaan zodat TWCManager er weer Ampere van maakt om naar de TWC te sturen. Je kan beter je script afmaken.

 

[wooter]

@wooter Dat is echt heel omslachtig en onnauwkeurig. Je hoofdzekering reageert op stroomsterkte in Amperes. De TWC vertelt de auto hoeveel Ampere die maximaal mag gebruiken. TWCManager veracht kennelijk vermogen in Watt. Je gaan nu berekeningen doen om van Ampere naar Watt te gaan zodat TWCManager er weer Ampere van maakt om naar de TWC te sturen. Je kan beter je script afmaken.

Hoofdzekering rekent in stroomsterkte in amperes, ja, maar die amperes hangen af van het wattage dat er gebruikt wordt, en watt = volt * ampere.

De meting van de CT sensoren is in watt, dus moet ik ook het voltage weten om te weten hoeveel ampere er beschikbaar is. Ik weet namelijk niet hoeveel 'watt' mijn zekering trekt, maar wel hoeveel ampere.

TWC input is in max. ampere.

usedAmpere = usedPower/Vrms;
freeAmpere = maxAmpere - usedAmpere - marginAmpere;

switch (true) {
    case (assignedAmpere < 0): assignedAmpere = 0;break;
    case (freeAmpere < 1): assignedAmpere = assignedAmpere-1;break;
    case (freeAmpere > marginAmpere&&assignedAmpere<(maxAmpere-marginAmpere)): assignedAmpere = assignedAmpere+1;break;
}

usedPower is hoogste van de 3 fases in watt. Vrms is laagste voltage van de 3 fases.
maxAmpere is maximum ampere van de zekering. marginAmpere is een in te stellen marge, in mijn geval 1 ampere.
freeAmpere is het resultaat dat naar TWCManager wordt gestuurd.
En dan 3 cases, om te voelen of ie moet verminderen of vermeerderen, naar gelang hoe het verbruik verandert.

Idee is dat het aantal ampere van de TWCManager gradueel verhoogt tot ie aan de limiet zit, en dan verlaagt. Werkt snel genoeg om problemen te voorkomen.

Je kan nl. niet van je originele berekening af gaan en dan vermogen aan je TWC toevoegen, want dat gebruikte vermogen zit in de volgende meting. Elke ~5 seconden is er een nieuwe meting en moet je kijken hoeveel capaciteit er nog over schiet op de zekering, en daarop aanpassen.

Dit werkt nu al pakweg zo anderhalf jaar.

 

[RichieB]

@wooter Ook CT-spoelen meten Amperes, die kunnen daar vermogen van maken als ze ook het Voltage meten. Beetje onzin om daarvan de Watt uit te lezen om daar dan weer Amperes van te maken, zie ook RPICT4V3 v2.0 - lechacal

@cousin_IT Mijn script heeft nu een web interface waarmee je kan kiezen tussen normaal laden op het volgen van de PV opbrengst. Bij normaal laden kan je daarmee nu ook instellen hoe snel (hoeveel Ampere) je mee wilt laden. GitHub - RichieB2B/tesla-loadbalancer: Loadbalancer for charging Tesla vehicles at home
Ik zal normaliter dit op PV laten staan zodat ik overdag teruglevering kan voorkomen maar ook gewoon 's avonds normaal kan laden (via de timer in de Tesla). Als ik een keer zo snel mogelijk wil laden kan ik dat dan via de webinterface aangeven.

Todo:

1. Opslaan van de keuzes in de webinterface zodat ze bij een herstart van het script worden bewaard
2. Automatisch start/stop laden bij volgen van PV opbrengst

 

[wooter]

@wooter Ook CT-spoelen meten Amperes, die kunnen daar vermogen van maken als ze ook het Voltage meten. Beetje onzin om daarvan de Watt uit te lezen om daar dan weer Amperes van te maken, zie ook RPICT4V3 v2.0 - lechacal

Een update van de firmware... Ding staat al een hele tijd te draaien dus heb nog geen update gedaan.

Kan inderdaad ook gebruik maken van Irms, maar stel ik me de vraag of iets repareren dat goed werkt een goed idee is. Ik heb vanavond al mijn TeslaUSB moeten opnieuw flashes omdat ik apt update apt upgrade deed en het ding niet meer wou booten.

 

[RichieB]

@wooter Ik heb even gekeken in de TWCManager code en je moet die aansturen met Amperes, dus je laat nu je CT-spoelen V * I = P doen om dan in node red weer P / V = I uit te rekenen. Niet heel zinnig natuurlijk, maar het werkt uiteraard wel.

Ik vind MQTT stand-alone gebruiken en aansturen via MQTT berichten best wel een goed idee. Dan heb ik de integratie met mijn script ook zo voor elkaar. Ik zal eerst maar eens die seriële draadjes in de TWC aansluiten dan.

 

[cousin_IT]

@wooter Ook CT-spoelen meten Amperes, die kunnen daar vermogen van maken als ze ook het Voltage meten. Beetje onzin om daarvan de Watt uit te lezen om daar dan weer Amperes van te maken, zie ook RPICT4V3 v2.0 - lechacal

@cousin_IT Mijn script heeft nu een web interface waarmee je kan kiezen tussen normaal laden op het volgen van de PV opbrengst. Bij normaal laden kan je daarmee nu ook instellen hoe snel (hoeveel Ampere) je mee wilt laden. GitHub - RichieB2B/tesla-loadbalancer: Loadbalancer for charging Tesla vehicles at home
Ik zal normaliter dit op PV laten staan zodat ik overdag teruglevering kan voorkomen maar ook gewoon 's avonds normaal kan laden (via de timer in de Tesla). Als ik een keer zo snel mogelijk wil laden kan ik dat dan via de webinterface aangeven.

Todo:

1. Opslaan van de keuzes in de webinterface zodat ze bij een herstart van het script worden bewaard
2. Automatisch start/stop laden bij volgen van PV opbrengst

Wat ik denk ik moet maken is een variant op jouw script die niet de API aanroept maar TWCManager met de juiste waarden. Ben er naar aan het kijken, leuke zondagavondklus

 

[wooter]

@wooter Ik heb even gekeken in de TWCManager code en je moet die aansturen met Amperes, dus je laat nu je CT-spoelen V * I = P doen om dan in node red weer P / V = I uit te rekenen. Niet heel zinnig natuurlijk, maar het werkt uiteraard wel.

De eerste velden die eruit komen zijn RealPower, en gemeten in watt. In retrospect had ik ook Irms kunnen gebruiken, maar ik gebruik RealPower ook om wijzertjes aan te drijven om verbruik te meten.

 

[Phil V]

Als je stuurt op kW en de spanning daalt, wat op piekmomenten wel eens gebeurt, dan moeten jouw ampères omhoog en gaan je zekeringen springen.

 

[ramonneke]

Tijd om een GitHub account te maken, @ramonneke

Die heb ik natuurlijk al lang ;-)

Realiseer me dat ik die code daar al een keer gedumpt heb: Tesla charging load balancer based on events from DSMR Reader and TeslaMate

 

[ramonneke]

• En de code van @ramonneke in C# die me helaas boven de pet gaat maar ook gebruik maakt van de API

Ja, ik gebruik de API, maar die call kun je ook gebruiken om TWC Manager aan te sturen. Het is feitelijk precies hetzelfde. Ook met dezelfde vertraging overigens omdat de update snelheid afhankelijk is van de DSMR updates en dat is circa elke 5 seconden. Althans, voor mijn slimme meter. Misschien dat andere slimme meters een hogere frequentie hebben.

Maar wat uitleg van mijn scriptje:

- Checked of de auto thuis aangesloten staat op basis van TeslaMate events
- Berekent steeds de huidige hoogste amps op de 3 fases (bv. 18A)
- Berekend hoeveel headroom er is (aansluiting is 24A, dus 25-18=7A)
- Indien positief, dan elke 5 seconden 1A omhoog,
- Indien negatief, dan dat aantal Amps naar beneden.

Verder zit er een kleine historie meting in. Ik merk b.v. dan sommige apparaten in korte tijd een aantal keer kort flink verbruiken. Dit zorgt ervoor dat ik niet enkel naar de laatste meting kijk maar naar alle metingen van de laatste minuut.

Met TWCManager kun je de eerste overslaan want het kan feitelijk elke auto zijn en je wilt gewoon de max amps pushen naar de TWC's.

 

[JanHerman]

Ik heb een paar dingen geautomatiseerd met Home Assistant.

Ik heb een automatisering geschreven waarbij de modbus van de SolarEdge Inverter doorgeeft hoeveel stroom er op dat moment geleverd wordt. Als deze boven een bepaalde grens komt (bij te lage stroom levert het niets op, want dan gaat alle stroom in het opwarmen van de accu) dan start de Tesla met laden via de custom API (deze komt met een integratie die je kan installeren via HACS). Dit natuurlijk alleen als deze thuis aangesloten is. Het amperage van de Tesla wordt aangepast op de hoeveelheid stroom die geleverd wordt. Ik heb een max van 95% en daar weer de integer van genomen, zodat de rest van het huis ook nog wat overhoudt. Deze laadstroom past zich steeds aan aan de hoeveelheid stroom die opgewekt wordt. In het energiedashboard kan ik dan mooi zien dat zo goed als alle stroom van de zonnepanelen rechtstreeks de auto in gaat. Is de accu vol, af wordt de lader ontkoppeld, dan stopt alles en wordt de laadstroom weer op max gezet.

Doordat deze op de SolarEdge Modbus zit, zit er geen vertraging in. Met de P1-meter kan ik in de gaten houden hoeveel stroom er nog actueel verbruikt wordt/teruggeleverd wordt. Ik gebruik het nu alleen voor overtollige zonnenergie. Met salderen nu nog niet echt nodig, maar alleen voor het milieu zinvol (niet onbelangrijk). Bij minder salderen wordt dit nog interessanten. Ik heb nog geen loadbalancing nodig. Dat zou pas bij een tweede auto het geval zijn. Tegen die tijd zie ik wel of ik het script daarop aanpas en of dat werkt.

Het tweede dat ik geautomatiseerd hebt is het opwarmen/koelen van de auto voor vertrek. Ik heb een aparte agenda in Google gemaakt voor de Tesla. Daar kopieer ik de afspraken naar toe waar ik met de auto heen ga. Met een paar integraties en scripts/sensoren bepaal ik wat de eerstvolgende locatie is en wanneer deze is. Met Waze bepaal ik wat de reistijd is en wat dus de vertrektijd is. Is deze binnen 20 uur, dan zet ik klaarmaken voor vertrek in de Tesla aan samen met temperatuurinstelling. Zo niet dan alleen opladen voor vertrek 's ochtends, zodat de auto wel 's ochtends geladen is, maar de temperatuurvoorverwarming niet aan gaat.

 

[wooter]

Het tweede dat ik geautomatiseerd hebt is het opwarmen/koelen van de auto voor vertrek. Ik heb een aparte agenda in Google gemaakt voor de Tesla. Daar kopieer ik de afspraken naar toe waar ik met de auto heen ga. Met een paar integraties en scripts/sensoren bepaal ik wat de eerstvolgende locatie is en wanneer deze is. Met Waze bepaal ik wat de reistijd is en wat dus de vertrektijd is. Is deze binnen 20 uur, dan zet ik klaarmaken voor vertrek in de Tesla aan samen met temperatuurinstelling. Zo niet dan alleen opladen voor vertrek 's ochtends, zodat de auto wel 's ochtends geladen is, maar de temperatuurvoorverwarming niet aan gaat.

Dat staat bij mij ook heel lang in de planning

En ook eentje om automatisch Sentry Model thuis tijdelijk aan te zetten om de Teslacam te uploaden.

 

[JanHerman]

Dat staat bij mij ook heel lang in de planning

En ook eentje om automatisch Sentry Model thuis tijdelijk aan te zetten om de Teslacam te uploaden.

Laatste moet ook goed te doen zijn. Dit doet bij mij de een Pi Zero met TeslaUSB erop trouwens al uit zichzelf

 

[wooter]

Dit doet bij mij de een Pi Zero met TeslaUSB erop trouwens al uit zichzelf

Niet met de nieuwe Tesla authenticatie.

 

[RichieB]

Niet met de nieuwe Tesla authenticatie.

TeslaUSB hoeft niet in te loggen op je Tesla account. Je kan de RPi ook onder stroom houden via de 5V van de OBD-II connector.

 

[wooter]

TeslaUSB hoeft niet in te loggen op je Tesla account. Je kan de RPi ook onder stroom houden via de 5V van de OBD-II connector.

Hij krijgt nu stroom via de USB-aansluiting van de wagen omdat ie zich moet voordoen als USB drive. 5V via ODB-II is leuk, maar wil ook niet constant 5V want dan zie je phantom drain werken. En krijgt ODB-II nog wel stroom zonder Sentry Mode? Met Sentry Mode krijgt de USB stroom, nl.