Domotica (DSMR, IOT, MQTT, etc.)

[prettig]

Wat wil je met deze data doen? 15 minuten is niet interessant voor load-balancing.

Wat is nou eigenlijk je doel?

- Wil je zo goedkoop mogelijk van het net trekken (EPEX)
- Wil je zo duur mogelijk je PV opbrengst terugleveren (EPEX + PV)

Zou leuk zijn, maar niet echt de doelstelling. En als er veel zon is, is het toch al goedkoop.

- Wil je loadbalancen en je Tesla puur met je PV laden (PV + P10 + Tesla API)? (Volgens mij niet, want je hebt heb steeds over 's nachts)

15 min is niet voor EPEX maar voor PV. De laatste 15 min opbrengst wil ik gebruiken om laadstroom te bepalen (dan vlak ik pieken en dalen uit en hoef ik niet constant bij te sturen). EPEX als er geen PV opbrengst is die "over" is, dat is het gewoon de goedkoopste uren nemen en max laden.
Dus zodra er stekker in gaat, dan gaat die kijken wat slim is (PV, net en straks ook accu).

Wat is onbruikbaar? Tesla API werkt hier anders prima om m'n Amps terug te brengen als ik via P10/DSMR reader boven de 25A kom.

Ik bedoel de Tesla auto app die is niet officieel (die hebben ze al 3 keer gewijzigd). Tesla lader weet ik niet (heb ik niet). Maar via OCPP moet ik wel de state of charge van de auto kunnen ophalen via een API (alleen nog niet uitgezocht).

Of bedoel je wat anders ? Kan de P10/DSMR op de auto zelf, dat is wel handig als ik die kan gebruiken via een API.


Gewoon leuk projectje en zal niet mega veel opleveren. Leuk om eens uit te werken.

 

[ramonneke]

Ik bedoel de Tesla auto app die is niet officieel (die hebben ze al 3 keer gewijzigd).

Nee, het is feitelijk een undocumented api door de community gedocumenteer (Introduction - Tesla JSON API (Unofficial)) maar in de 2.5 jaar dat ik de API gebruik werkt deze nog praktisch hetzelfde qua data. Enig is de authenticatie die een paar keer bijgewerkt moest worden.

SoC via Tesla API is kinderlijk eenvoudig maar natuurlijk niet handig als je echt voor elke auto die je inplugd moet werken.

Charge State | Tesla JSON API (Unofficial)

tesla-api.timdorr.com

Kan de P10/DSMR op de auto zelf, dat is wel handig als ik die kan gebruiken via een API.

Sorry, ik heb dat verkeerd getikt. Het is P1.
Ik gebruik DSMR Reader icm een P1 poort/USB kabeltje en deze stuurt voor elke P1 fragment een MQTT event. TeslaMate publiceert ook diverse events via MQTT. Zo heb ik dan een subscriber die weet wanneer de auto is ingeplugd en hoeveel Amps over zijn en vervolgens de Tesla API aanroept om het aantal Amps bij te stellen:

Charging | Tesla JSON API (Unofficial)

tesla-api.timdorr.com

Logica is nu vrij simpel, DSMR amps diff met MAX amp indien positief verlaag charge amps via Tesla API op basis van de, indien negatief dan langer negatief dan 1 minuut dan 3 amp erbij tot tenzij de amps berekening aangeeft dat ik over de 25 amp ga.

Indien Tesla amps minder dan ik dacht 8, stop dan met laden en stuur bericht via PushOver. Onder 8 amps is het vrij zinloos om te laden omdat er dan veel efficiency loss is.

Laden is tot op heden nooit gestopt maar het is wel een prettige gedachte.

Zo voorkom ik dat ik continue de Tesla API aan het spammen ben.

 

[wooter]

Als je continu wil wijzigen, is de API misschien niet zo leuk. Maar als je 1 keer per kwartier gaat wijzigen, kan de API perfect werken.

Maar goed, je hebt je al ingekocht in een slimme laadpaal.

 

[prettig]

Nee, het is feitelijk een undocumented api door de community gedocumenteer (Introduction - Tesla JSON API (Unofficial)) maar in de 2.5 jaar dat ik de API gebruik werkt deze nog praktisch hetzelfde qua data. Enig is de authenticatie die een paar keer bijgewerkt moest worden.

SoC via Tesla API is kinderlijk eenvoudig maar natuurlijk niet handig als je echt voor elke auto die je inplugd moet werken.

Charge State | Tesla JSON API (Unofficial)

tesla-api.timdorr.com

Sorry, ik heb dat verkeerd getikt. Het is P1.
Ik gebruik DSMR Reader icm een P1 poort/USB kabeltje en deze stuurt voor elke P1 fragment een MQTT event. TeslaMate publiceert ook diverse events via MQTT. Zo heb ik dan een subscriber die weet wanneer de auto is ingeplugd en hoeveel Amps over zijn en vervolgens de Tesla API aanroept om het aantal Amps bij te stellen:

Charging | Tesla JSON API (Unofficial)

tesla-api.timdorr.com

Logica is nu vrij simpel, DSMR amps diff met MAX amp indien positief verlaag charge amps via Tesla API op basis van de, indien negatief dan langer negatief dan 1 minuut dan 3 amp erbij tot tenzij de amps berekening aangeeft dat ik over de 25 amp ga.

Indien Tesla amps minder dan ik dacht 8, stop dan met laden en stuur bericht via PushOver. Onder 8 amps is het vrij zinloos om te laden omdat er dan veel efficiency loss is.

Laden is tot op heden nooit gestopt maar het is wel een prettige gedachte.

Zo voorkom ik dat ik continue de Tesla API aan het spammen ben.

Zal nog eens naar de Tesla API kijken (had ik al, maar niet meer aangepast, omdat ik er toch niks mee deed). Maar ik vraag me af wat ik met de SOC kan? Heb ik dat nodig, ik denk niet.

Amps aanpassen via de laadpaal kan ook. Dan werkt het voor elke auto en staat die auto altijd op max., maar ook dat is niet nodig bij ons. Maar beide werken.

MQTT via Teslamate, wist ik niet...... dank, kan ik wat mee.

Die 8 amps... totaal of per fase ?

Logica hoeft volgens mij ook niet echt ingewikkeld te zijn. P=U x I..... U is vast (bijna) , P variabel.

 

[wooter]

U is vast (bijna)

Haha mijn zekering is eens gesprongen omdat ik domweg U als vaste waarde in de formule had, en het een keer niet voldoende was

U fluctueert hier tussen de 210 en 255. Scheelt wel wat als je maar 20A beschikbaar hebt op je zekering.

Niet voor niks dat ik van alle fasen de U meet

 

[prettig]

De easee meet die automatisch en gaat nooit hoger dan beschikbaar, maar wel iets waar ik over ga nadenken (beetje lastig testen of die dat ook echt doet, als het fout gaat ligt de hoofdzekering eruit !).

Hier 3x25A, dus wat meer ruimte. Moet wel even de fases nog nameten en zorgen dat ze gelijkmatig belast worden. Moet ook nog de verbruiksmeter aansluiten van de Enphase (die hangt 30-40m van de meterkast) dan kan ik dat gaan loggen.

 

[ramonneke]

Maar ik vraag me af wat ik met de SOC kan? Heb ik dat nodig, ik denk niet.

Ik heb geen idee waarp, je dat wilt doen maar het is je eigen vraag/opmerking:

"Maar via OCPP moet ik wel de state of charge van de auto kunnen ophalen via een API (alleen nog niet uitgezocht)."

Dus mijn antwoord is hoe je dat via de Tesla API eenvoudig kunt doen.

Die 8 amps... totaal of per fase ?

Goede vraag eigenlijk... Toen ik het ooit las ging het over het laden van je auto op een Schuko dus zal specifiek gegaan zijn over 1 fase. 3 fase 8 amp zal wellicht stukken efficiënter zijn dus wellicht helemaal niet relevant met 3 fase laden.

Logica hoeft volgens mij ook niet echt ingewikkeld te zijn. P=U x I..... U is vast (bijna) , P variabel.

Het fragment van de P1 poort rapporteert per fase het amperage. Ik hoef dus niks om te rekenen met vermogens en voltages en gewoon een max(f1,f2,f3) doen en ik heb de max. Het feit dat het voltage hier soms rond de 240V schommelt is gratissssss extra laadvermogen.

De P1 poort rapporteert dacht ik om de 5 seconden. Iets sneller zou fijn zijn maar een gemiddelde reactietijd van 2.5s is snel zat. Het totale vermogen op een fase zal nooit boven 30A continu uitkomen.

 

[prettig]

Easee ondersteund dus ook MQTT ....... eens induiken (werk eigenlijk nooit met MQTT, even collega vragen die doet dit vaker). Maar of ik daarmee kan zien of er kabel aangesloten ?

En via openhab kan dus ook: Easee Home Wallbox – Überschussladen mit der Solaranlage (easee en solaredge, met accu). Maar dat kan dus ook met Enphase (of ander door openhab ondersteund systeem).

 

[RichieB]

@prettig Je spreekt jezelf steeds tegen. Het is goedkoop, want gratis services maar je werkt met test accounts die gelimiteerd zijn. Het is in de cloud want dat werkt altijd, maar het kan ook lokaal doordraaien. Ik heb diverse domotica in “de cloud” zoals Netatmo en Evohome maar die servers liggen er regelmatig (1 a 2 keer per maand) een paar uur lang uit. Dat weet ik omdat ik ze elke minuut poll. Daarom ben ik heel blij dat ik bij het uitzoeken van cruciale diensten voor mezelf de eis heb gesteld dat het ook zonder cloud connectie moet blijven werken. Ik moet er niet aan denken dat mijn CV niet aan wil omdat er een Tado server down is.

Maak voor jezelf eerst eens een fatsoenlijk functioneel ontwerp. Ga daarna pas de techniek invullen met wat het beste bij je functionele eisen past. Je bent nu in API’s aan het duiken en dingen aan elkaar aan het knopen zonder dat je weet waar je naar toe werkt.

Er zit hier genoeg kennis en ervaring om je te helpen maar dan moet je wel geholpen willen worden.

 

[prettig]

@prettig Je spreekt jezelf steeds tegen. Het is goedkoop, want gratis services maar je werkt met test accounts die gelimiteerd zijn. Het is in de cloud want dat werkt altijd, maar het kan ook lokaal doordraaien. Ik heb diverse domotica in “de cloud” zoals Netatmo en Evohome maar die servers liggen er regelmatig (1 a 2 keer per maand) een paar uur lang uit. Dat weet ik omdat ik ze elke minuut poll. Daarom ben ik heel blij dat ik bij het uitzoeken van cruciale diensten voor mezelf de eis heb gesteld dat het ook zonder cloud connectie moet blijven werken. Ik moet er niet aan denken dat mijn CV niet aan wil omdat er een Tado server down is.

Maak voor jezelf eerst eens een fatsoenlijk functioneel ontwerp. Ga daarna pas de techniek invullen met wat het beste bij je functionele eisen past. Je bent nu in API’s aan het duiken en dingen aan elkaar aan het knopen zonder dat je weet waar je naar toe werkt.

Er zit hier genoeg kennis en ervaring om je te helpen maar dan moet je wel geholpen willen worden.

Als iets lokaal kan doordraaien maar ook in de cloud, betekend dat niet dat ik mezelf tegenspreek (het systeem is dan zo ontworpen, Tado voor je CV ook, Easee ook). Geen test accounts (gratis is geen test, alleen limieten en minder functionaliteit). Easee API is gratis omdat ze een publieke API hebben voor iedereen (betekend niet dat die niet goed is of niet stabiel).

Integromat/Make (hoogste level account zakelijk). Dat is geen speelgoed (staat in magic quadrant van Gartner), ligt er nooit uit. We zijn Integromat/Make ontwikkel en Beta Partner en bouwen commercielle apps op het platform (tot aan PSD2 koppelingen met banken). Wil je het eens proberen: gratis full functional account (met task limit), 100% dezelfde uptime (geen test account).

En nu ben ik lekker aan het spelen, niks ontwerp. Gewoon wat ideeen (in mij hoofd zit dan het globale ontwerp) en kijken wat ik ermee kan. Gewoon prototypen, is geen rocket-sciences. Ik bouw die koppelingen in no-time tijdens de koffie (zijn er wel meer hier die dat ook kunnen). Ik zoek gewoon ideeen van anderen. Al leuke dingen gezien en goede input. En als het anders moet dan bouw ik het gewoon om.

Dit is een hobby project dat ik hier deel (kan zelfs de apps beschikbaar stellen aan iedereen die dat wil), dit is geen bedrijfskritisch process/opdracht

 

[RichieB]

@prettig Integromat/Make klinkt interessant maar is niet mijn cup-of-tea. Ik ben meer van zelf code schrijven en zelf draaien op een vm of docker.

Deze API integraties zijn inderdaad niet moeilijk. Ik heb mijn eigen loadbalancer ook in een paar uur geschreven en daarna langzaam verfijnd tot hij perfect draait voor mij. Als mijn PV wordt geplaatst zal ik ook de optimalisatie voor zo weinig mogelijk terugleveren erin bouwen.

GitHub - RichieB2B/tesla-loadbalancer: Loadbalancer for charging Tesla vehicles at home

Loadbalancer for charging Tesla vehicles at home. Contribute to RichieB2B/tesla-loadbalancer development by creating an account on GitHub.

github.com

 

[prettig]

@prettig Integromat/Make klinkt interessant maar is niet mijn cup-of-tea. Ik ben meer van zelf code schrijven en zelf draaien op een vm of docker.

Deze API integraties zijn inderdaad niet moeilijk. Ik heb mijn eigen loadbalancer ook in een paar uur geschreven en daarna langzaam verfijnd tot hij perfect draait voor mij. Als mijn PV wordt geplaatst zal ik ook de optimalisatie voor zo weinig mogelijk terugleveren erin bouwen.

GitHub - RichieB2B/tesla-loadbalancer: Loadbalancer for charging Tesla vehicles at home

Loadbalancer for charging Tesla vehicles at home. Contribute to RichieB2B/tesla-loadbalancer development by creating an account on GitHub.

github.com

Integromat/Make is ook meer voor B2B processen (maar snel zat voor deze case). Zie wel dat veel oplossingen MQTT of AMQP gebruiken.

Even jouw project bekeken, onderstaande tekst zette me aan het denken.......

"In this example the charge is started at 24A but midway L3 is being used for other purposes as well. The load balancer scaled the Tesla back so the maximum current of L3 stays at 25A which is the maximum for this power circuit. As the consumption on L3 decreases the Tesla is scaled back up until it is charging at 24A again."

We kunnen de laders instellen op een amperage: maar dat is dan bv. 12 amp en dan is het 3x12 amp. Maar het kan dus makkelijk dat er 20A over is op de andere fases. En daar kunnen we eigenlijk niks mee.

Iemand al nagedacht hoe je dat kan oplossen ? (fases goed verdelen qua belasting uiteraard)
Doen laders dit dynamisch per fase (laden met: L1:16A, L2:12A en L3:10A) ? (eigenlijk nog nooit naar gekeken)
Kan een auto lader dat wel aan ?

In theorie zou 1-fase laden dus sneller kunnen zijn tov 3-fases. Als 2-fases flink belast worden en 1 niet, dan kan 1-fase sneller zijn (kijken of ik dat kan meenemen in de logica).

 

[ramonneke]

We kunnen de laders instellen op een amperage: maar dat is dan bv. 12 amp en dan is het 3x12 amp. Maar het kan dus makkelijk dat er 20A over is op de andere fases. En daar kunnen we eigenlijk niks mee.

Klopt, maar de Tesla lader doet hier niks mee zo ver ik weet.

Belang om je belasting dus goed te verdelen over de fases

 

[RichieB]

@prettig Een EV 3-fasen lader belast voor zover ik weet de fases even veel. Je hebt daar geen invloed op. De enige uitzondering die ik bij mijn Tesla zie is boven de 95% SOC. Dan wordt er een balancering van de cellen gedaan waar maar 1 fase voor wordt gebruikt.

 

[Mark67]

Iemand al nagedacht hoe je dat kan oplossen ? (fases goed verdelen qua belasting uiteraard)
Doen laders dit dynamisch per fase (laden met: L1:16A, L2:12A en L3:10A) ? (eigenlijk nog nooit naar gekeken)
Kan een auto lader dat wel aan ?

Type 2 laadpunt communiceert met de auto via een control-signal (pilot-signal; je ziet in de stekker naast de grote contactpunten ook twee extra contactpunten, dat is voor het pilot-signaal). Dat signaal geeft de maximale stroomsterkte (in Amps) het laadpunt maximaal kan leveren. De lader - die zich in de auto bevindt - past daarop onmiddellijk de vraag aan (dat moet heel snel, om overbelasting van laadpunt te voorkomen). Daarom kun je een EV niet zomaar in het stopcontact steken, er moet een circuit zijn die deze communicatie regelt.

Zover ik weet is er één controle-signaal voor alle fases en niet per-fase en is er dus geen manier voor de lader (in de auto) om te differentiëren per fase.

 

[RichieB]

Ik denk dat de lader in de auto prima kan differentiëren per fase (zie Tesla boven 95% SOC) maar er is geen manier voor de Type-2 lader om de per fase verschillende beschikbare amperage’s te communiceren aan de auto.

 

[Ger356]

Ik denk dat de lader in de auto prima kan differentiëren per fase (zie Tesla boven 95% SOC) maar er is geen manier voor de Type-2 lader om de per fase verschillende beschikbare amperage’s te communiceren aan de auto.

En als je per fase de stroomsterkte zou kunnen knijpen? Dit is allemaal nogal academisch omdat er geen lader is die je per fase kunt aansturen, toch? NB. Waarschijnlijk is het helemaal onzin, want als de auto 16 amp vraagt en de lader levert maar 10 zal de auto wel gaan klagen.

 

[bartdv]

Werkt de tesla link al terug in homeassistant met 2fa. Weet iemand dit. Had een oplossing gevonden via Hacks maar vind dit onbetrouwbaar om mijn gegeven in te geven.

Ook nog iemand in geslaagd in home assistant de juiste tijd te hebben in de browser van de wagen. Ik volg via de browser een aantal statistieken waaronder energy maar het lijkt alsof de originele browser in de tesla over een vpn gaat gezien de statistieken in screen op pst tijd staan iplv gmt +1

 

[prettig]

En als je per fase de stroomsterkte zou kunnen knijpen? Dit is allemaal nogal academisch omdat er geen lader is die je per fase kunt aansturen, toch? NB. Waarschijnlijk is het helemaal onzin, want als de auto 16 amp vraagt en de lader levert maar 10 zal de auto wel gaan klagen.

Kan dus wel......https://developer.easee.cloud/docs/load-balancing, is de current per installatie (dat is dan voor alle chargers).

Dacht dat kan vast niet toen ik de vraag hier stelde. Maar dacht ga toch maar eens spitten in de doc. En ja hoor het schijnt te kunnen, eens testen of die dan ook verschillende waardes neemt bij het laden (amps per fase kun je aflezen in de app of uiteraard de API). Bij 1-fase laden neemt die overigens automatisch de mist belaste fase.

 

[RichieB]

En als je per fase de stroomsterkte zou kunnen knijpen? Dit is allemaal nogal academisch omdat er geen lader is die je per fase kunt aansturen, toch? NB. Waarschijnlijk is het helemaal onzin, want als de auto 16 amp vraagt en de lader levert maar 10 zal de auto wel gaan klagen.

Geen enkele EV AC lader knijpt de stroom. Hoe zou dat technisch moeten werken? Een lader vertelt alleen aan de auto hoeveel deze mag gebruiken. De auto zal er dan voor zorgen niet meer te gebruiken dan wordt geadverteerd. Een lader kan hooguit het laden stoppen als de auto er over heen gaat (geen idee of dat ook zo werkt). In de IEC 61851-1 standaard is gedefinieerd dat de "available current" wordt gecommuniceerd door de lader aan de auto via een PWM signaal. De breedte van de puls geeft aan hoeveel Ampère er beschikbaar is. Zie bijv. pagina 12 en 27 van deze PDF. Er is in het protocol niet voorzien om dit per fase aan te geven.

Kan dus wel......https://developer.easee.cloud/docs/load-balancing, is de current per installatie (dat is dan voor alle chargers).

In een multi-lader setup is het denkbaar om elke lader slechts op 1 fase stroom aan te bieden aan de auto. Door tussen de laders te communiceren welke fase hoeveel Ampère beschikbaar heeft kan een lader de beste fase gebruiken. In een 3-fase lader heeft dit echter weinig zin: de fase met de minst beschikbare Ampère zal worden geadverteerd als beschikbare stroom.