prettig
Active Member
ok... die IEC 61851-1 standaard had ik nog niet aan gedacht, al zouden ze het kunnen, kan/mag nog niet.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Domotica (DSMR, IOT, MQTT, etc.)
- Thread starter Ger356
- Start date
Gisteren gemerkt waarom zelfbouw zijn voor- en nadelen heeft.
Via Ansible deed ik een update van de Raspberry Pi's die aan mekaar hangen om mijn fasen te meten en de TWC's te beheren.
Python 2.7 werd daarbij verwijderd ofzo, en aan de ene kant kon TWCManager niet meer starten, en aan de andere kant kon ik de fasen niet meer uitlezen. Het laden van mijn auto was onderbroken, gelukkig maar een beetje lager dan ik had gewenst te laden.
En oh ja, ook Homebridge kon niet meer starten, dus ging de garagepoort ook niet meer open
Via Ansible deed ik een update van de Raspberry Pi's die aan mekaar hangen om mijn fasen te meten en de TWC's te beheren.
Python 2.7 werd daarbij verwijderd ofzo, en aan de ene kant kon TWCManager niet meer starten, en aan de andere kant kon ik de fasen niet meer uitlezen. Het laden van mijn auto was onderbroken, gelukkig maar een beetje lager dan ik had gewenst te laden.
En oh ja, ook Homebridge kon niet meer starten, dus ging de garagepoort ook niet meer open
RichieB
Collaborator
Python 2.7 is inderdaad niet standaard meer aanwezig in Raspbian Bullseye. TWCManager en Homebridge gebruiken Python 3 dus die zouden gewoon moeten blijven werken. Eventueel moet je de scripts even aanpassen om python3 aan te roepen ipv python2.
Ik ben mis, TWCManager bleef lekker werken maar kreeg geen updates meer van de CT die wel nog op Python 2.7 werkte. De Homebridge module voor mijn garagepoort kon dan weer niet overweg met een nieuwe versie van NodeJS. Het script om de CT uit te lezen heb ik aangepast en compatibel gemaakt met Python3, en update van NodeJS.
RichieB
Collaborator
Javascript is voor browsers, IMHO moet je dat niet willen draaien op een server. Nee, ook niet voor NodeRed.
Javascript is een interpreted taal net als java, .net, en weet ik wat voor talen. Het is de grootste taal in gebruik. Waarom zou je dat niet willen draaien op een server?
Ik zie het probleem niet. Ik zelf zou het niet willen onderhouden want ik ben allergisch voor javascript maar ik zie de toegevoegde waarde wel.
RichieB
Collaborator
Omdat NPM en de bijbehorende dependencies een heel slecht idee is. Je loopt veel meer risico dan bij andere talen/frameworks.
prettig
Active Member
Heeft ook voordelen, je hoeft een hoop niet meer zelf te maken. NPM's werken vaak meerdere ontwikkelaars aan (vaak ervaren ontwikkelaars). Als jezelf codeert...... ben je fijn van jezelf afhankelijk. Dus ik probeer zo weinig mogelijk zelf te coderen
In al dit geweld van professionele automatiseerders, even een update van een onervaren hobbyist. Ben wel technisch, maar mijn programmeerervaring is blijven steken bij Algol met ponskaarten en assembler op een PDP11. Recent wel wat met Python geknoeid, maar ik moet echt alles opzoeken. Gelukkig speelt tijd geen rol (meer).
Door jullie adviezen heb ik gekozen voor Home assistant en heb dat op een raspberry Pi 3 gezet die nog in een la lag. (Anekdote: Ik dacht die pi moet je programmeren, dus je hebt een toetsenbord, een muis en een scherm nodig. Nou had ik geen HDMI scherm meer liggen en om steeds het scherm aan mn Mac te schakelen tussen de Mac en de Pi was ook zo onhandig. Dus een knap scherm gescoord op Marktplaats voor 20,— om er vervolgens achter te komen dat je een SD kaartje moet maken op de Mac en als je dat in de Pi stopt heb je geen scherm en toetsenbord enz nodig, want je benadert Homeassistant via de webbrowser.)
Intussen ontvang ik de elektrameter in homeassistant (kabeltje kopen en DSMR reader installeren). Ook voor de SMA omvormer van mn zonnepanelen was er een integratie in homeassistant en ook die gegevens komen keurig binnen. De verbinding met de auto koste iets meer moeite omdat de Tesla custom integratie niet een officiele homeassistant integratie is en je via een ander pakketje (Hacs) de spullen van Github moet halen. Maar er staan een paar documentjes en You tube filmpjes op het net die het wel uitleggen. Vervolgens een dashboardje in Homeassistant bij elkaar gesleept waarin de elektrameter (output van en naar het net), de Zonnepanelen (output) en de auto (laadstroom, State of Charge en laadpoort) onder elkaar staan. Voor de volledigheid heb ik ook de verwachting van de zonneopbrengst erbij gehaald. Ook dat is een paar klikken. De volgende stap is de boel aan elkaar te knopen.
Maar ik heb toch een paar vraagjes voor de experts:
Ik las dat het geen goed idee is om alle data op het sd kaartjes op te slaan want die dingen schijnen dat niet aan te kunnen. Waar moet ik aan denken, begeeft zo’n kaartje het na een paar dagen, weken, maanden of pas na jaren? Ritchie schreef dat hij de data naar een netwerkschijf schrijft, dat zou ik ook kunnen doen naar mn Synology NAS, maar dan gaat dat ding nooit meer slapen. Vind ik ook weer zonde van de energie. Is een SSD aan de Pi (kan dat) een alternatief?
Ik worstel nog met het pollen van de auto. Het hele circus (programma, scene, script,..) hoeft natuurlijk alleen te draaien als de auto aan de laadpaal (TWC) hangt, maar hoe weet ik dat. Er zijn geen events uit de auto naar Homeassistant, je kunt de auto alleen pollen en de status van de laadpoort controleren. Ik kan het pollen aan en uit zetten, maar heb nog niet gevonden of je de pollrate in kunt stellen. Bovendien blijft het zonde om, zelfs al doe je het elk kwartier, oneindig te pollen. Of moet ik me daar niet zo druk om maken?
Last edited:
prettig
Active Member
Zie @ramonneke post 46, doet het via MQTT.
Zelf nog bezig om het via de lader te achterhalen. Maar nu afhankelijk van hun API support......want, as usual, niet alles is gedocumenteerd
P.s. voor hobbyist ben je aardig bezig ....... als je Algol kunt coderen (was al structured), dan zal Phyton ook wel gaan lukken.
Last edited:
Mijn eerste setje SD kaarten gaven het na een jaar op.
Ik heb vervolgens SanDisk Max Endurance kaartjes gekocht, die worden gemarketed als geschikt voor dash cams en andere schrijf-intensieve toepassingen.
En vervolgens heb ik Log2Ram geïnstalleerd, dat ervoor moet zorgen dat de /var/log locatie als een aparte partitie in RAM wordt gepresenteerd en het aantal fysieke schrijf-acties op de SD kaartjes beperkt wordt.
SD kaartjes die corrupt geraken door teveel schrijfacties is vergelijkbaar met het eMMC-probleem bij Tesla's, waarbij de chip dus voorbij zijn maximum aantal schrijfacties gaat per sector en dus corrupties begint te vertonen.
Uiteindelijk moet er ergens gepolld worden en dat is bij mij TeslaMate. Deze maakt van veel data dan weer MQTT topics waar je op kunt subscriben.
Je wilt ook zo min mogelijk pollende services omdat anders je auto niet meer slaapt. Bij mij staat zowel Teslafi als TeslaMate vrij aggressief afgesteld maar ik ga denk ik niet meer m'n Teslafi subscription verlengen als deze komende zomer afloopt. Zo heb ik echt maar 1 service en zo min mogelijk conflicten. Helaas is het niet mogelijk b.v. Teslafi als gateway voor TeslaMate te configuren of vice versa. Dan zou je van 1 service een poll based routine kunnen maken en de data die dan terugkomt naar andere services pushen. Feitelijk wat TeslaMate nu doet maar dan gewoon met de hele JSON response die Tesla retour geeft.
SpeedyEddy
Active Member
Log2ram is inderdaad heel erg SD-kaart sparend. Ik heb in mijn leven nog minder geprogrammeerd dan @prettig en kreeg dat met veel zoeken ook voor elkaar. Log2Ram: Extending SD Card Lifetime for Raspberry Pi LoRaWAN Gateway
En ik had ook eerst een scherm aangesloten op mijn Pi totdat ik SSH ontdekte (echt geen verstand van Linux, dus ik google me gek)
Verder werk ik met domoticz en heb ik eerdaags heel veel tijd om het eens echt uit te zoeken allemaal. Overigens gebruik ik SocketXP om mijn domoticz via internet te kunnen bekijken Teslamate draait ook op diezelfde Raspberry. Maar ik moet weer eens de Api sleutel ophalen, want ik heb 'm met experimenteren vernaggeld. Oh ja, meteen maar even doen, want nu leest -ie de Tesla ook niet uit uiteraard.
prettig
Active Member
Ik wil ook zo min mogelijk pollen (gewoon stom en verbruikt veel cpu aan beide kanten, zeker als iedereen dat gaat doen). Ideaal pollen is om de paar seconden, terwijl je eens in de paar dagen maar een push bericht nodig hebt. Verschil in cycles is enorm.
Nu loop ik bij Easee ook tegen zoiets aan. Pollen kan/moet, want ze hebben nog geen webhooks ! (staat wel op de agenda) Maar met een SignalR stream kan dat wel, dus daar maar eens induiken (nog nooit gedaan). Wil gewoon event driven werken ipv pollen (wie dat ooit bedacht heeft...... ).
RichieB
Collaborator
@Ger356 Goed bezig! Een SD kaart is heel goed voor het (vaak) lezen van bestanden maar heeft een zeer beperkte capaciteit voor het aantal schrijfacties. Log2ram is een goede manier om de schijfacties te beperken, maar als je Home Assistent gaat draaien zullen de gegevens daarvoor in een database moeten. Dat zijn schrijfacties die je echt niet op je SD kaart wilt doen. Een database server op je NAS draaien klinkt al een stuk beter. Dan moet je die inderdaad wel 24x7 aan willen laten. Een SSD is een USB enclosure is ook een oplossing. Het OS zet je dan op de SD kaart maar alle data (oa database) zet je dan op de SSD.
Of, ga de profi route: lees je P1 poort uit met een ESP8266 en draai Home Assistent in een docker container op je NAS.
De Tesla API heeft een vehicle_data call met daarin een charging_state object. Als daarin de charging_state member op "Charging" staat is de Tesla aan het laden. Zie State And Settings - Tesla API en tesla-loadbalancer/tesla-mqtt-loadbalancer.py at main · RichieB2B/tesla-loadbalancer
Of, ga de profi route: lees je P1 poort uit met een ESP8266 en draai Home Assistent in een docker container op je NAS.
De Tesla API heeft een vehicle_data call met daarin een charging_state object. Als daarin de charging_state member op "Charging" staat is de Tesla aan het laden. Zie State And Settings - Tesla API en tesla-loadbalancer/tesla-mqtt-loadbalancer.py at main · RichieB2B/tesla-loadbalancer
Last edited:
shoot72
Member
@Ger356 Als je home assistant supervised gebruikt is het redelijk eenvoudig om dit binnen home assistant te brengen via add-ons:
GitHub - matt-FFFFFF/hassio-addon-teslamate: Teslamate addon for Home Assistant
Dan kun je zonder de auto te benaderen via MQTT de laatste status van de auto uitlezen, o.a is de auto thuis en aangesloten aan het oplaadpunt. Dan zou je binnen HA kunnen bepalen of en met hoeveel Ampere(via de custom integratie van Tesla) je je auto gaat laden.
aantal automatisering voorbeelden kun je hier vinden:
Optimizing use of unused Solar Power to charge a Tesla
Last edited:
prettig
Active Member
Vandaag maar eens het proces gemaakt. Loop je toch tegen nieuwe dingen aan.
Waardes p1 (kan via Easee API): heb ik niks aan, om de 10 seconden forse schommelingen (1-3 kw). Vandaag getest met half bewolkt (dan varieert je PV ombrengst per minuut diverse keren fors).
Dan loop ik telkens de lader in stomme waardes in te stellen, is echt momentopname.
10 seconden interval: lader wordt denk ik gek .....flipperkast. Heb waardes even gelogd (veel te grillig).
Dus nu neem ik de "lopende" laatste 15-30 minuten gemiddeld (kw's) pv opbrengst en dat telkens om de 5 minuten: geeft een heel stabiel productiecijfer van je PV opbrengst.
Enphase neemt zelf al een 15 minuten interval.
Nu volgt die de opbrengst in de Enpase app vrij nauwkeurig (ik laad nagenoeg exact wat ik opwek per uur).
Ik kan ook hoger gaan zitten als het dat uur toch goedkoop is (questie van de EPEX logica erin plakken).
Werk nu dus met Kw's ipv amp per fase.
Als je 100% gratis wil laden dat moet je om de 10 seconden of realtime je amp's aanpassen per fase.
Mijn aanpak vlakt dat uit en gemiddeld laad ik wat ik produceer, maar lever dus ook terug en neem ook af tijdens de laadsessie (zal dus iets duurder zijn).
EPEX aansturing is makkelijk. Kijk nu 12 uur vooruit en laden hervatten als laag tarief in het huidige uur. Duur uur: laden pauzeren. EPEX is golfpatroon, maakt het eenvoudiger.
Maximaal (normaal) laden ook eenvoudig gemaakt (gewoon button op de telefoon indrukken en hij gaat gewoon max laden en negeert de logica). Die reset ik daarna automatisch.
Waar ik nog mee bezig ben:
- zodra de auto gaat laden zit je laadsessie in de consumptiewaarde (is namelijk een verbruiker)
- dus moet nog even de lader waardes meenemen in de logica (vandaag getest met vaste waardes)
- EPEX logica aan PV laden toevoegen (waarom langzamer laden als de stroom toch nul of negatief is qua prijs)
- en dan loggen, hoeveel geladen per sessie aan welke prijs totaal
- nu voor een lader, maar is een stapje aan het begin en hij doet het automatisch voor alle laders per site
Minimaal amp's: nog niet echt getest hoe laag ik de amp's kan zetten met de Tesla (5A was laagste wat ik gezien heb).
Max nog even testen...... wat doet die als ik geen 3x16A heb omdat er verbruikers aanstaan en ik toch de lader in 16A zet (volgens support moet die dat beperken). Schakelt verder automatisch naar 1 of 3 fase (zo te zien bepaald die dat aan het begin van de sessie), maar ook dat kan ik omzetten in de API (nog niks mee gedaan, lijkt me nog niet zinvol). Voor de logica maakt het niks uit.
Na de sessie zie je dat die voltooid is en de volgende sessie start weer op maximale waardes.
Wat wel leuk is, ik kan het hele process zien en aanpassen in de Tesla browser
Zoiets wordt het dan...... versie 1 (zal nog wel wijzigen)
Waardes p1 (kan via Easee API): heb ik niks aan, om de 10 seconden forse schommelingen (1-3 kw). Vandaag getest met half bewolkt (dan varieert je PV ombrengst per minuut diverse keren fors).
Dan loop ik telkens de lader in stomme waardes in te stellen, is echt momentopname.
10 seconden interval: lader wordt denk ik gek .....flipperkast. Heb waardes even gelogd (veel te grillig).
Dus nu neem ik de "lopende" laatste 15-30 minuten gemiddeld (kw's) pv opbrengst en dat telkens om de 5 minuten: geeft een heel stabiel productiecijfer van je PV opbrengst.
Enphase neemt zelf al een 15 minuten interval.
Nu volgt die de opbrengst in de Enpase app vrij nauwkeurig (ik laad nagenoeg exact wat ik opwek per uur).
Ik kan ook hoger gaan zitten als het dat uur toch goedkoop is (questie van de EPEX logica erin plakken).
Werk nu dus met Kw's ipv amp per fase.
Als je 100% gratis wil laden dat moet je om de 10 seconden of realtime je amp's aanpassen per fase.
Mijn aanpak vlakt dat uit en gemiddeld laad ik wat ik produceer, maar lever dus ook terug en neem ook af tijdens de laadsessie (zal dus iets duurder zijn).
EPEX aansturing is makkelijk. Kijk nu 12 uur vooruit en laden hervatten als laag tarief in het huidige uur. Duur uur: laden pauzeren. EPEX is golfpatroon, maakt het eenvoudiger.
Maximaal (normaal) laden ook eenvoudig gemaakt (gewoon button op de telefoon indrukken en hij gaat gewoon max laden en negeert de logica). Die reset ik daarna automatisch.
Waar ik nog mee bezig ben:
- zodra de auto gaat laden zit je laadsessie in de consumptiewaarde (is namelijk een verbruiker)
- dus moet nog even de lader waardes meenemen in de logica (vandaag getest met vaste waardes)
- EPEX logica aan PV laden toevoegen (waarom langzamer laden als de stroom toch nul of negatief is qua prijs)
- en dan loggen, hoeveel geladen per sessie aan welke prijs totaal
- nu voor een lader, maar is een stapje aan het begin en hij doet het automatisch voor alle laders per site
Minimaal amp's: nog niet echt getest hoe laag ik de amp's kan zetten met de Tesla (5A was laagste wat ik gezien heb).
Max nog even testen...... wat doet die als ik geen 3x16A heb omdat er verbruikers aanstaan en ik toch de lader in 16A zet (volgens support moet die dat beperken). Schakelt verder automatisch naar 1 of 3 fase (zo te zien bepaald die dat aan het begin van de sessie), maar ook dat kan ik omzetten in de API (nog niks mee gedaan, lijkt me nog niet zinvol). Voor de logica maakt het niks uit.
Na de sessie zie je dat die voltooid is en de volgende sessie start weer op maximale waardes.
Wat wel leuk is, ik kan het hele process zien en aanpassen in de Tesla browser
Zoiets wordt het dan...... versie 1 (zal nog wel wijzigen)
Last edited:
Similar threads
