Zelfbouw Laadpaal ervaringen

[mukky]

rene037 schreef op vrijdag 19 juli 2024 @ 19:00:
Ja, daltarief zou kunnen, maar alles was 0. In middels zie ik wel iets, dus ik denk idd dat het even duurde voor hij begon. Op zich wel balen want ik loop zo (een beetje) geld mis.
Overigens heb ik ze teruggeroepen toen ze klaar waren, want hij maakte zoemend geluid. Was alleen bij belasting op fase 2. Weer omgeruild en toen ok.

Heeft bij mij bijna een maand geduurd en heb dynamisch dus aanzienlijk verlies maarja…

[rene037]

Inmiddels komen er getallen op het display anders dan 0.
Dank voor reacties. Sensorbpx nog te koop.

[rene037]

Ik zit nu naar de datagrammen te kijken en de stroom wordt wel per fase gerapporteerd, maar in hele amperes.
De SmartEVSE wil ze in tienden. Nu heb ik even de stroom *10 gedaan (Eigenlijk een '0' aan te tekst geplakt) maar ik kan ook de stroom berekenen uit het vermogen en de spanning en op 1 decimaal afronden (en dan *10). In de praktijk maakt het denk ik niet uit, maar op het display staat het wat leuker...

Iemand dezelfde gedachte gehad?

[Proton_]

@rene037 Terugrekenen uit vermogen onderschat de stroom omdat de power factor altijd kleiner dan 1 is. De werkelijke stroom zal dus iets hoger zijn dan berekend.
In de praktijk zal je er wel mee wegkomen

[Hmmbob]

rene037 schreef op zaterdag 20 juli 2024 @ 15:45:
Ik zit nu naar de datagrammen te kijken en de stroom wordt wel per fase gerapporteerd, maar in hele amperes.
De SmartEVSE wil ze in tienden. Nu heb ik even de stroom *10 gedaan (Eigenlijk een '0' aan te tekst geplakt) maar ik kan ook de stroom berekenen uit het vermogen en de spanning en op 1 decimaal afronden (en dan *10). In de praktijk maakt het denk ik niet uit, maar op het display staat het wat leuker...

Iemand dezelfde gedachte gehad?

Nope, ik doe gewoon de stroom per fase *10 voordat ik hem via de api naar de SmartEVSE stuur

YAML:

  - interval: 2sec
    then:
      - http_request.post:
          url: !lambda |-
            std::string url;

            float l1 = id(template_current_l1).state;
            float l2 = id(template_current_l2).state;
            float l3 = id(template_current_l3).state;

            url.append("http://192.168.88.216/currents?L1=");
            url.append(to_string(l1*10));
            url.append("&L2=");
            url.append(to_string(l2*10));
            url.append("&L3=");
            url.append(to_string(l3*10));
            return url.c_str();

[ Voor 31% gewijzigd door Hmmbob op 20-07-2024 16:24 ]

[rene037]

Proton_ schreef op zaterdag 20 juli 2024 @ 16:02:
@rene037 Terugrekenen uit vermogen onderschat de stroom omdat de power factor altijd kleiner dan 1 is. De werkelijke stroom zal dus iets hoger zijn dan berekend.
In de praktijk zal je er wel mee wegkomen

Dat denk ik ook, maar het is een beetje gek dat spanning en vermogen wel in decimalen is en de stroom, die toch de basis is om het vermogen uit te rekenen, niet. Nu is het vermogen wel in hele Watts (Het decimale getal is immers kW), maar het aantal decimalen moet toch 1 zijn zou ik zeggen, aangezien de spanning 1 decimaal heeft. Tenminste, volgens mij heb ik het zo geleerd...

[KoBolD54]

Vandaag geupdate naar 3.6.6. Helaas wilde hij na de updaten niet meer verbinden met mijn wifi. Om die reden heb ik de ESPtouch App geprobeerd.

Het was wat onduidelijk hoe deze nu gebruikt moet worden maar na het doorlezen van de broncode dien je v2 te selecteren in de ESPtouch App en bij de AES veld de cijfers die verschijnen op je display onderin bij key in te vullen.

Ondanks diverse pogingen lukt het mij niet om verbinding te maken met mijn wifi. Ik heb het access point al en keer herstart, de configuratie aangepast zodat hij enkel op 2.4Ghz zend en de SmartEVSE al meerdere keren gereboot. Helaas allemaal zonder succes. Heeft er iemand nog suggesties?

[dingo35]

Zet op het LCD scherm je wifi eens op Disabled, dan Exit selecteren, en dan weer WiFi Enabled selecteren.
Dat geeft doorgaans weer verbinding, als je met voorgaande acties je ssid/wachtwoord niet overschreven hebt.

By the way, je hebt de handleiding nog niet ontdekt?
https://github.com/dingo3...ter/docs/configuration.md

Zie ook de links onderaan de github hoofdpagina....

[ Voor 30% gewijzigd door dingo35 op 21-07-2024 08:05 ]

[Stefannn]

In de Apple appstore staan 2 Esptouch apps.
Ik gok zo dat je de “espressive Esptouch” moet hebben aangezien de andere geen v2 heeft.
Ik heb het nog niet getest, ik durf eigenlijk even niet te upgraden aangezien ik even niet echt tijd heb voor troubleshoot als er iets mis gaat.
Ik heb de apps wel beiden op phone gehad. De “Esptouch” (zonder espressive) heeft een vast ssid: “Wi-Fi”. Dat werkt denk ik niet.

Suggestie om in de manual duidelijk te zetten welke van de 2 apps je moet hebben.

[dingo35]

Goed plan.

Hoewel ik denk dat als je de keuze hebt uit deze twee apps:


...hoe je dan besluit de onderste te kiezen?!?

Maar laten we dit positief oppakken: @Stefannn doe even een PR met de juiste links naar de apps, dan kan ik mijn tijd besteden aan uitbreiden van de functionaliteit en fixen van bugs.

Op die manier gebruiken we de kracht van de community optimaal..

[KoBolD54]

dingo35 schreef op zondag 21 juli 2024 @ 08:02:
Zet op het LCD scherm je wifi eens op Disabled, dan Exit selecteren, en dan weer WiFi Enabled selecteren.
Dat geeft doorgaans weer verbinding, als je met voorgaande acties je ssid/wachtwoord niet overschreven hebt.

By the way, je hebt de handleiding nog niet ontdekt?
https://github.com/dingo3...ter/docs/configuration.md

Zie ook de links onderaan de github hoofdpagina....

Helaas geen succes met uitschakelen en inschakelen van de wifi via de SmartEVSE. Ik heb ook geprobeerd wifi op Disable te zetten, dan Exit en vervolgens de SmartEVSE helemaal uit en weer aan. Wanneer ik WifiSetup selecteer zie ik trouwens ook nog een SSID smartevse-xxxx verschijnen. Iets doet mij vermoeden dat de update van 3.6.5 naar 3.6.6 niet helemaal lekker is gegaan aangezien wifi in 3.6.5 nog wel werkte.

Wat betreft de handleiding, het was wat laat gisteren en ik was er daardoor niet vanuit gegaan dat de info stond onder "All menu options on the LCD screen" en was daardoor onterecht opzoek naar een vergelijkbaar kopje "Connecting the SmartESVE to WiFi" zoals de die oorspronkelijke firmware. Het staat inderdaad goed uitgelegd in je handleiding en gelukkig is de code ook goed gedocumenteerd, waarvoor dank!

Zijn er nog andere opties die ik kan proberen nu het nog niet werkt?

[bbbrumbrum]

KoBolD54 schreef op zondag 21 juli 2024 @ 12:10:
[...]

Helaas geen succes met uitschakelen en inschakelen van de wifi via de SmartEVSE. Ik heb ook geprobeerd wifi op Disable te zetten, dan Exit en vervolgens de SmartEVSE helemaal uit en weer aan. Wanneer ik WifiSetup selecteer zie ik trouwens ook nog een SSID smartevse-xxxx verschijnen. Iets doet mij vermoeden dat de update van 3.6.5 naar 3.6.6 niet helemaal lekker is gegaan aangezien wifi in 3.6.5 nog wel werkte.

Wat betreft de handleiding, het was wat laat gisteren en ik was er daardoor niet vanuit gegaan dat de info stond onder "All menu options on the LCD screen" en was daardoor onterecht opzoek naar een vergelijkbaar kopje "Connecting the SmartESVE to WiFi" zoals de die oorspronkelijke firmware. Het staat inderdaad goed uitgelegd in je handleiding en gelukkig is de code ook goed gedocumenteerd, waarvoor dank!

Zijn er nog andere opties die ik kan proberen nu het nog niet werkt?

Vond het initieel ook een beetje vaag en moest ff om het feit heenwerken dat mijn IOT netwerk obv MAC whitelist (waar mn telefoon niet inzit) werkt.

Paar keer geprobeerd, frustratie begon te stijgen, en ineens werkte het toch…. Geduld is wel een schone zaak.

[KoBolD54]

bbbrumbrum schreef op zondag 21 juli 2024 @ 13:17:
[...]

Vond het initieel ook een beetje vaag en moest ff om het feit heenwerken dat mijn IOT netwerk obv MAC whitelist (waar mn telefoon niet inzit) werkt.

Paar keer geprobeerd, frustratie begon te stijgen, en ineens werkte het toch…. Geduld is wel een schone zaak.

Heb er nu de nodige tijd inzitten en al van alles geprobeerd, maar het lijkt niet te werken. Heb zelfs het SSID al een keer verwijderd en opnieuw aangemaakt in de hoop dat het werkt. Ook heb ik de oude DHCP lease van mijn lader verwijderd. Helaas allemaal zonder resultaat.

[dingo35]

Als je nog een smartevse-xxxx ssid ziet verschijnen, zit je gewoon nog op een oude versie; dus gewoon de oude procedure volgen, zie de handleiding: connecten, http://192.168.4.1, en invullen maar....

[dingo35]

...en zoals de handleiding vermeldt, kan het wel 20 seconden duren voordat de ESPtouchV2 procedure beëindigd wordt. Dus idd, geduld...

[dingo35]

KoBolD54 schreef op zondag 21 juli 2024 @ 12:10:
[...]
Iets doet mij vermoeden dat de update van 3.6.5 naar 3.6.6 niet helemaal lekker is gegaan aangezien wifi in 3.6.5 nog wel werkte.

Onderin je LCD scherm staat het versienummer dat je draait.....

[KoBolD54]

dingo35 schreef op zondag 21 juli 2024 @ 13:51:
[...]


Onderin je LCD scherm staat het versienummer dat je draait.....

Versienummer is 3.6.6 (aldus het display), voor de update gisteren draaide ik 3.6.5. De oude procedure werkt niet omdat er geen wifi wachtwoord wordt weergegeven maar een key voor de ESPtouch procedure.

Zelfs naar meer dan 1.5 minuten te wachten krijg ik geen verbinden en geeft de app aan dat hij geen devices kan vinden. Ook met een andere telefoon lukt het niet om verbinding te maken. Ik vermoed nog steeds dat er iets niet helemaal goed gegaan is met de update omdat ik dus ook nog steeds smartevse-xxxx te zien krijg zodra ik WifiSetup start.

[dingo35]

Weet je zeker dat die smartevse-xxxx "vers" is, dwz na een wifi-scan van je telefoon verschijnt?

In v3.6.6 is de library die het smartevse-xxxx AP opzet, niet meer aanwezig, dus het is eigenlijk onmogelijk wat je beschrijft....

Je hebt niet nog een andere smartevse in de buurt in setup staan?

De ESPtouch app die je moet hebben heeft het rode logo, zie eerder deze thread.

Als het niet werkt kun je _altijd_ nog de backup procedure via de USB kabel volgen, zie de handleiding.

[KoBolD54]

dingo35 schreef op zondag 21 juli 2024 @ 14:24:
Weet je zeker dat die smartevse-xxxx "vers" is, dwz na een wifi-scan van je telefoon verschijnt?

In v3.6.6 is de library die het smartevse-xxxx AP opzet, niet meer aanwezig, dus het is eigenlijk onmogelijk wat je beschrijft....
Je hebt niet nog een andere smartevse in de buurt in setup staan?

Dat ben ik helemaal met je eens maar toch verschijnt er een smartevese-xxxx netwerk op het moment dat ik WifiSetup aan zet. Niet alleen op mijn telefoon maar ook op die van andere en mijn laptop. Ook is er een andere SmartEVSE in de buurt.

De ESPtouch app die je moet hebben heeft het rode logo, zie eerder deze thread.

Als het niet werkt kun je _altijd_ nog de backup procedure via de USB kabel volgen, zie de handleiding.

Ik gebruik inderdaad de juiste app. Ook de backup procedure lijkt voor mij niet te werken, ik krijg geen enkele output, al kan dat nog aan mijn liggen. Als ik mijn Mac verbind met de SmartEVSE dan verschijnt er in mijn /dev lijst een usbserial-xxxx. De x'en zijn gelijk aan het nummer wat ik zie op het moment dat ik WifiSetup start.

Als ik vervolgens WifiSetup start, 120 seconden wacht en dan op enter druk gebeurt er niets. Wanneer ik de ESP32 drivers voor Mac installeer verschijnt er een SLAB_USBtoUART bij. Ook deze lijkt niet te werken. Nu maak ik voor mijn serial connection gebruik van OS X Terminal met screen. Ik heb daarbij diverse baudrates geprobeerd.

[dingo35]

En wat gebeurt er als je contact maakt met de smartevse-xxxx AP en naar http://192.168.4.1 surft?

EDIT: alles wijst er nl. op dat je helenaal niet op v3.6.6 zit....

EDIT2: ...of je flashed je favoriete firmware.bin met een van de vele flashtools die er zijn voor de ESP32, zie bijvoorbeeld deze post:
Phantone in "Zelfbouw Laadpaal ervaringen"

Baudrate 115200.

[ Voor 66% gewijzigd door dingo35 op 23-07-2024 06:30 ]

[KoBolD54]

dingo35 schreef op dinsdag 23 juli 2024 @ 05:56:
En wat gebeurt er als je contact maakt met de smartevse-xxxx AP en naar http://192.168.4.1 surft?

EDIT: alles wijst er nl. op dat je helenaal niet op v3.6.6 zit....

Als ik met smartevse-xxxx contact maakt vraagt hij om het wifi wachtwoord. Echter heb ik deze niet en wordt ook niet op het scherm weergegeven. Ik ben het helemaal met je eens dat het er niet op lijkt dat ik op 3.6.6. maar volgens het display is dat wel de versie die draait.

EDIT2: ...of je flashed je favoriete firmware.bin met een van de vele flashtools die er zijn voor de ESP32, zie bijvoorbeeld deze post:
Phantone in "Zelfbouw Laadpaal ervaringen"

Baudrate 115200.

Zojuist geflashed via USB en daarna werkte alles vlekkeloos. Helaas niet kunnen achterhalen waar het nu aan lag. Ik kwam van 3.6.4 waar een wifi bug in zat, toen geupgrade naar 3.6.5 om vervolgens te upgrade naar 3.6.6. Tot aan de laatste versie werkte alles (met uitzondering van de wifi bug) zoals verwacht. Vanaf de upgrade naar 3.6.6. is het fout gegaan.

Anyway nu werkt het weer, heel erg bedankt voor je hulp

[Hmmbob]

Ik heb de laatste paar dagen last van WiFi drops op de smartevse, waarmee het laden ook stopt (want geen P1 info via de API). Ik heb de indruk dat het sinds de laatste (of voorlaatste) versie pas gebeurd, kan me niet herinneren dat ik het eerder heb gezien. WiFi hangt er zowat naast, en is niet eerder een probleem geweest. Software van de WiFi geeft ook aan dat de SmartEVSE met dit AP verbonden is, en al heel lang verbonden is geweest.

Herkent iemand dit?

[dingo35]

Upgraden naar v3.6.6, zover bekend zitten daar geen wifi-quirks meer in...

[w00Dy]

Hmmbob schreef op dinsdag 23 juli 2024 @ 14:45:
Ik heb de laatste paar dagen last van WiFi drops op de smartevse, waarmee het laden ook stopt (want geen P1 info via de API). Ik heb de indruk dat het sinds de laatste (of voorlaatste) versie pas gebeurd, kan me niet herinneren dat ik het eerder heb gezien. WiFi hangt er zowat naast, en is niet eerder een probleem geweest. Software van de WiFi geeft ook aan dat de SmartEVSE met dit AP verbonden is, en al heel lang verbonden is geweest.

Herkent iemand dit?

[Afbeelding]

Ja, ik had hetzelfde. Ik dacht eerst dat Domoticz de schuldige was, die event scripts zijn niet altijd even makkelijk te timen ivm het doorsturen van L1/L2/L3 data.

Bedoeling was om eindelijk maar eens om te schakelen naar MQTT, maar tijd -en kennis gebrek blokkeren me voorlopig

[Hmmbob]

dingo35 schreef op dinsdag 23 juli 2024 @ 15:01:
Upgraden naar v3.6.6, zover bekend zitten daar geen wifi-quirks meer in...

Daar zit ik al op....

[mukky]

Hmmbob schreef op woensdag 17 juli 2024 @ 09:45:
Dat moet daarmee wel lukken.

Poging 2 is gelukt

Samenvattend voor nieuwe lezers die Home Assistant, DSMR Reader en een Smart EVSE gebruiken:

1. Koop een SlimmeLezer+ van Marcel Zuidwijk (link)
2. Installeer de plug-in ESPHome in je Home Assistant omgeving en "adopteer" de SlimmeLezer+
3. Pas de YAML code aan van de SlimmeLezer+ zodat die overeenkomt met die van @Hmmbob (link)

Ik krijg wel onderstaande melding in mijn console, jij ook?

[Hmmbob]

mukky schreef op woensdag 24 juli 2024 @ 18:06:

Ik krijg wel onderstaande melding in mijn console, jij ook?

[Afbeelding]

Ja, maar die negeer ik. Wat slow is voor esphome, is prima voor mijn doeleinde.

[dingo35]

@Hmmbob Ik ken je setup niet precies, maar het esphome installatie script is zojuist aangepast, thx rhannink.

[ Voor 3% gewijzigd door dingo35 op 26-07-2024 11:31 ]

[dingo35]

@bbbrumbrum , @kuhlivisj

Ik heb een testversie voor jullie probleem met power-weergave van ABB en andere meters klaarstaan, maar kan hier helaas geen files uploaden:

https://github.com/dingo35/SmartEVSE-3.5/discussions/111

Ik kan dit momenteel niet zelf testen, graag jullie hulp!

[Hmmbob]

dingo35 schreef op vrijdag 26 juli 2024 @ 11:22:
@Hmmbob Ik ken je setup niet precies, maar het esphome installatie script is zojuist aangepast, thx rhannink.

Oh nice, die error had ik ook wel eens gezien maar niet ingedoken waar het door kwam (kwam maar af en toe voor, SmartEVSE deed het verder prima). Ik zal hem zo eens opnieuw flashen. Tx!

[mukky]

Hmmbob schreef op vrijdag 26 juli 2024 @ 11:37:
[...]

Oh nice, die error had ik ook wel eens gezien maar niet ingedoken waar het door kwam (kwam maar af en toe voor, SmartEVSE deed het verder prima). Ik zal hem zo eens opnieuw flashen. Tx!

Ik had 'm ook gezien maar slechts een enkele keer. Update van het script werkt hier goed

[chasinbe]

Hoi,

Zijn er mensen met suggesties voor laadzuil/montagepaal die gebruikt worden als laadpaal voor zelf 32A buitenstopcontact (CEE inbouw 230V IP44) aan te sluiten om gecontroleerd 3,7 - 7,4kW te kunnen laden mbt capaciteitstarief in België.

Kwam er enkele tegen online tussen 150-200 euro, hoopte dat er mensen hier zijn met kennis/ervaring die misschien hun ervaring willen delen

Horti-Laadzuil
Bevestigingspaal voor Besen wallbox
Niko 761-36810: Spuitwaterdichte tuinpaal met grondpin voor één Niko Hydro functie, black
EV-Go Single | Universele Metalen Montagepaal


Grtz

[Devil]

dingo35 schreef op vrijdag 26 juli 2024 @ 11:30:
@bbbrumbrum , @kuhlivisj

Ik heb een testversie voor jullie probleem met power-weergave van ABB en andere meters klaarstaan, maar kan hier helaas geen files uploaden:

https://github.com/dingo35/SmartEVSE-3.5/discussions/111

Ik kan dit momenteel niet zelf testen, graag jullie hulp!

Ik heb een ABB meter die ook gestopt is met power laten zien (stond altijd op 0). Met deze firmware spuugt hij random (want ik kan er geen patroon in herkennen) positieve en negatieve getallen uit.
Charged kWh lijkt gek genoeg wel te kloppen.

Update: laden is klaar en 'power' blijft nu steken op 31kW
En na een reboot op -31

[ Voor 5% gewijzigd door Devil op 26-07-2024 21:44 ]

[HaTe]

mukky schreef op woensdag 24 juli 2024 @ 18:06:
[...]

Poging 2 is gelukt

Samenvattend voor nieuwe lezers die Home Assistant, DSMR Reader en een Smart EVSE gebruiken:

1. Koop een SlimmeLezer+ van Marcel Zuidwijk (link)
2. Installeer de plug-in ESPHome in je Home Assistant omgeving en "adopteer" de SlimmeLezer+
3. Pas de YAML code aan van de SlimmeLezer+ zodat die overeenkomt met die van @Hmmbob (link)

Ik krijg wel onderstaande melding in mijn console, jij ook?

[Afbeelding]

Mijn variant is op een vlak wat beter, namelijk dat hij bij elke update waarbij de amperages zijn veranderd, de waardes naar de SmartEVSE stuurt. Zo kan hij sneller reageren op piekbelastingen. De Hmmbob versie update elke 10s.

HaTe in "Zelfbouw Laadpaal ervaringen"

Wellicht dat Hmmbob dit ook kan toevoegen

[dingo35]

Zo te zien ontbreekt de "content 0" header in dat script?

[Hmmbob]

HaTe schreef op vrijdag 26 juli 2024 @ 22:08:
[...]

Mijn variant is op een vlak wat beter, namelijk dat hij bij elke update waarbij de amperages zijn veranderd, de waardes naar de SmartEVSE stuurt. Zo kan hij sneller reageren op piekbelastingen. De Hmmbob versie update elke 10s.

Beter kijken: er gaat iedere 10sec een push naar DSMR-reader, en die staat helemaal los van de laadpaal.

De SmartEVSE krijgt iedere 2sec een nieuwe waarde en dat doe ik bewust niet als het amperage wijzigt, want je krijgt met DSMR5 meters iedere seconde een update en zo snel is niet nodig/wordt het niet verwerkt.

HaTe in "Zelfbouw Laadpaal ervaringen"

Wellicht dat Hmmbob dit ook kan toevoegen

Oh, ik zal mn lokale commit even pushen.

[ Voor 99% gewijzigd door Hmmbob op 27-07-2024 13:21 ]

[HaTe]

Hmmbob schreef op zaterdag 27 juli 2024 @ 13:17:
[...]

Beter kijken: er gaat iedere 10sec een push naar DSMR-reader, en die staat helemaal los van de laadpaal.

De SmartEVSE krijgt iedere 2sec een nieuwe waarde en dat doe ik bewust niet als het amperage wijzigt, want je krijgt met DSMR5 meters iedere seconde een update en zo snel is niet nodig/wordt het niet verwerkt.

Excuses, iedere 2 seconden dan. Bij mijn script wordt er gekeken of de waarde ook echt anders is, dus er wordt niet elke keer dat er een update van de amperages komt, wat geupdatet. Op deze manier wordt de ESP/SmartEVSE ook ontlast. Hij krijgt dus tussen de 1 en 9 seconden een nieuwe waarde. Zie in de code hieronder regel 281 t/m 288 en 100 t/m 107

dingo35 schreef op zaterdag 27 juli 2024 @ 06:19:
Zo te zien ontbreekt de "content 0" header in dat script?

Ik weet niet wat je bedoelt. Ik moest laatst wel wat aanpassen omdat er een breaking change was in ESPHome. Dit is mijn huidige code:

YAML:

---
substitutions:
  device_name: slimmelezer
    
esphome:
  name: ${device_name}
  platform: ESP8266
  esp8266_restore_from_flash: true
  board: d1_mini
  name_add_mac_suffix: false
  project:
    name: zuidwijk.slimmelezer
    version: "1.2"
  on_boot:
    then:
      - if:
          condition:
            lambda: return id(has_key);
          then:
            - lambda: |-
                std::string key(id(stored_decryption_key), 32);
                id(dsmr_instance).set_decryption_key(key);
          else:
            - logger.log:
                level: info
                format: "Not using decryption key. If you need to set a key use Home Assistant service 'ESPHome:  ${device_name}_set_dsmr_key'"

wifi:
  # remove leading '#' and fill in your wifi details
#  ssid: !secret wifi_ssid 
#  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: ${device_name}

captive_portal:

# Enable logging
logger:
  baud_rate: 0

# Enable Home Assistant API
api:
  services:
    service: set_dsmr_key
    variables:
      private_key: string
    then:
      - logger.log:
          format: Setting private key %s. Set to empty string to disable
          args: [private_key.c_str()]
      - globals.set:
          id: has_key
          value: !lambda "return private_key.length() == 32;"
      - lambda: |-
          if (private_key.length() == 32)
            private_key.copy(id(stored_decryption_key), 32);
          id(dsmr_instance).set_decryption_key(private_key);

ota: 
  platform: esphome
  password: !secret ota_password

dashboard_import:
  package_import_url: github://zuidwijk/dsmr/slimmelezer.yaml@main
  import_full_config: true

web_server:
  port: 80

http_request:
  verify_ssl: false
  
globals:
  - id: last_evse_update
    type: int
    restore_value: no
    initial_value: '0'
  - id: has_key
    type: bool
    restore_value: yes
    initial_value: "false"
  - id: stored_decryption_key
    type: char[32]
    restore_value: yes


uart:
  baud_rate: 115200
  rx_pin: D7
  rx_buffer_size: 1700

dsmr:
  id: dsmr_instance
  max_telegram_length: 1700
  # For Luxembourg users set here your decryption key
  #decryption_key: !secret decryption_key // enable this when using decryption for Luxembourg; key like '00112233445566778899AABBCCDDEEFF'

script:
  - id: update_evse
    then:
    - http_request.post:
        url: !lambda |-
          return ((std::string) id(http_request_url).state);
    - lambda: |-
        id(last_evse_update) = id(now).state; 

switch:
 - platform: safe_mode
   name: "Restart In Safe Mode"

sensor:
  - platform: dsmr
    energy_delivered_tariff1:
      id: energy_delivered_tariff1
      name: "Energy Consumed Tariff 1"
    energy_delivered_tariff2:
      id: energy_delivered_tariff2
      name: "Energy Consumed Tariff 2"
    energy_returned_tariff1:
      id: energy_returned_tariff1
      name: "Energy Produced Tariff 1"
    energy_returned_tariff2:
      id: energy_returned_tariff2
      name: "Energy Produced Tariff 2"
    power_delivered:
      id: power_delivered
      name: "Power Consumed"
      accuracy_decimals: 3
    power_returned:
      id: power_returned
      name: "Power Produced"
      accuracy_decimals: 3
    electricity_failures:
      name: "Electricity Failures"
      icon: mdi:alert
      entity_category: diagnostic
    electricity_long_failures:
      name: "Long Electricity Failures"
      icon: mdi:alert
      entity_category: diagnostic
    voltage_l1:
      id: voltage_l1
      name: "Voltage Phase 1"
      accuracy_decimals: 0
    voltage_l2:
      name: "Voltage Phase 2"
      accuracy_decimals: 0
      id: voltage_l2
    voltage_l3:
      name: "Voltage Phase 3"
      accuracy_decimals: 0
      id: voltage_l3
    # current_l1:
    #   name: "Current Phase 1"
    # current_l2:
    #   name: "Current Phase 2"
    # current_l3:
    #   name: "Current Phase 3"
    power_delivered_l1:
      id: power_delivered_l1
      name: "Power Consumed Phase 1"
      accuracy_decimals: 3
    power_delivered_l2:
      id: power_delivered_l2
      name: "Power Consumed Phase 2"
      accuracy_decimals: 3
    power_delivered_l3:
      id: power_delivered_l3
      name: "Power Consumed Phase 3"
      accuracy_decimals: 3
    power_returned_l1:
      id: power_returned_l1
      name: "Power Produced Phase 1"
      accuracy_decimals: 3
    power_returned_l2:
      id: power_returned_l2
      name: "Power Produced Phase 2"
      accuracy_decimals: 3
    power_returned_l3:
      id: power_returned_l3
      name: "Power Produced Phase 3"
      accuracy_decimals: 3
  - platform: wifi_signal
    name: "Wi-Fi Signal"
    update_interval: 60s
  - platform: template
    id: current_l1
    device_class: "current"
    state_class: "measurement"
    accuracy_decimals: 1
    unit_of_measurement: A
    name: "Current Phase 1"
    lambda: |-
      return (id(power_delivered_l1).state - id(power_returned_l1).state)*1000 / id(voltage_l1).state;
    update_interval: 10s
  - platform: template
    id: current_l2
    device_class: "current"
    state_class: "measurement"
    accuracy_decimals: 1
    unit_of_measurement: A
    name: "Current Phase 2"
    lambda: |-
      return (id(power_delivered_l2).state - id(power_returned_l2).state)*1000 / id(voltage_l2).state;
    update_interval: 10s
  - platform: template
    id: current_l3
    device_class: "current"
    state_class: "measurement"
    accuracy_decimals: 1
    unit_of_measurement: A
    name: "Current Phase 3"
    lambda: |-
      return (id(power_delivered_l3).state - id(power_returned_l3).state)*1000 / id(voltage_l3).state;
    update_interval: 10s
  # - platform: template
  #   device_class: "power"
  #   state_class: "measurement"
  #   accuracy_decimals: 1
  #   name: "Power"
  #   lambda: |-
  #     return (id(power_delivered).state - id(power_returned).state)*1000;
  #   update_interval: 10s
  - platform: template
    name: Total Energy Consumed
    device_class: energy
    state_class: total_increasing
    accuracy_decimals: 3
    unit_of_measurement: kWh
    lambda: |-
      return id(energy_delivered_tariff1).state + id(energy_delivered_tariff2).state;
  - platform: template
    name: Total Energy Produced
    device_class: energy
    state_class: total_increasing
    accuracy_decimals: 3
    unit_of_measurement: kWh
    lambda: |-
      return id(energy_returned_tariff1).state + id(energy_returned_tariff2).state;
  - platform: uptime
    id: now
    update_interval: 1s

  
text_sensor:
  - platform: dsmr
    electricity_tariff:
      id: electricity_tariff
      #name: "Electricity tariff"
  #   identification:
  #     name: "DSMR Identification"
  #     entity_category: diagnostic
  #   p1_version:
  #     name: "DSMR Version"
  #     entity_category: diagnostic
  - platform: wifi_info
    ip_address:
      name: "Slimmelezer IP Address"
  - platform: template
    id: http_request_url
    update_interval: 1s
    lambda: |-
      int current_l1 = ((id(power_delivered_l1).state - id(power_returned_l1).state)*1000 / id(voltage_l1).state) * 10;
      int current_l2 = ((id(power_delivered_l2).state - id(power_returned_l2).state)*1000 / id(voltage_l2).state) * 10;
      int current_l3 = ((id(power_delivered_l3).state - id(power_returned_l3).state)*1000 / id(voltage_l3).state) * 10;
      char url[60];
      sprintf(url, "http://10.10.10.40/currents?L1=%d&L2=%d&L3=%d", current_l1, current_l2, current_l3);
      return (std::string) url;
    on_value:
    - script.execute: update_evse
  - platform: template
    name: Stroomtarief
    lambda: |-
      if (id(electricity_tariff).state == "0001")
        return {"Dal"};
      else
        return {"Piek"};

interval:
  - interval: 9s
    then:
    - if:
        condition:
          lambda: 'return (id(now).state - id(last_evse_update)) > 8;'
        then:
         - script.execute: update_evse

[bbbrumbrum]

dingo35 schreef op vrijdag 26 juli 2024 @ 11:30:
@bbbrumbrum , @kuhlivisj

Ik heb een testversie voor jullie probleem met power-weergave van ABB en andere meters klaarstaan, maar kan hier helaas geen files uploaden:

https://github.com/dingo35/SmartEVSE-3.5/discussions/111

Ik kan dit momenteel niet zelf testen, graag jullie hulp!

Heeft even geduurd, maar kan helaas de bevindingen van @Devil bevestigen.

[ Voor 18% gewijzigd door bbbrumbrum op 28-07-2024 10:26 ]

[ronv]

Ik probeer al een tijdlang om mijn smartevse serkri 3.6.3 via mqtt te koppelen aan domoticz. Als ik mosquitto_sub -v -h 172.18.10.xx -u username -P password -t '#' krijg ik de melding connection refused, er is geen user en wachtwoord ingesteld.
Maak ik verbinding met de rest api gaat het wel goed en krijg ik netjes respons.
Via mqtt explorer krijg ik wel response echter geen topic. Kan iemand mij verder helpen?

[TorpedoX_88]

Ik heb mijn SmartEVSE v3 (normale modus, alleen EV kWh meter) vorige week geupdated van 3.6.0 naar 3.6.6 en sindsdien laadt mijn Seat Mii Electric nog maar op 6A. Ik maak gebruik van de SEAT CONNECT app om met een geplande eindtijd op maximaal 13A en tot 90% SoC te laden, wat prima werkte met de vorige versie maar nu niet meer lijkt het. Iemand enig idee waar dit aan kan liggen en hoe het op te lossen?

[bbbrumbrum]

TorpedoX_88 schreef op dinsdag 30 juli 2024 @ 13:38:
Ik heb mijn SmartEVSE v3 (normale modus, alleen EV kWh meter) vorige week geupdated van 3.6.0 naar 3.6.6 en sindsdien laadt mijn Seat Mii Electric nog maar op 6A. Ik maak gebruik van de SEAT CONNECT app om met een geplande eindtijd op maximaal 13A en tot 90% SoC te laden, wat prima werkte met de vorige versie maar nu niet meer lijkt het. Iemand enig idee waar dit aan kan liggen en hoe het op te lossen?

Kun je wellicht wat meer details delen hoe en met wat je dit voorheen voor elkaar kreeg? Je stuurt dus niets aan via de SmartEVSE? Wat zijn de verschillende stroominstellingen momenteel?

[TorpedoX_88]

bbbrumbrum schreef op dinsdag 30 juli 2024 @ 14:14:
[...]

Kun je wellicht wat meer details delen hoe en met wat je dit voorheen voor elkaar kreeg? Je stuurt dus niets aan via de SmartEVSE? Wat zijn de verschillende stroominstellingen momenteel?

Zover ik weet doe ik weinig bijzonders; de SmartEVSE staat in "Normal" modus met de Max Current op 16A (enige stroominstelling) en die stuurt dus inderdaad niks aan. Dit was voorheen ook zo en dan gaat de SmartEVSE in "Charging" mode wanneer je de auto verbind, maar gaat de auto pas stroom vragen volgens het ingestelde schema aan het ingestelde amperage en tot de maximale SoC. Dat eerste gebeurd nu ook, maar de SmartEVSE geeft dan als "Charge" 0 A alleen gaat ie wel laden met 6A...

[dingo35]

@bbbrumbrum , @kuhlivisj In de discussions thread van de repo staat een nieuwe test versie klaar voor de ABB meter, graag in die thread de testresultaten melden, dan vallen we de rest hier niet lastig mee....

[dingo35]

@TorpedoX_88 Ik heb een soortgelijke melding gehad, volgens mij is dit opgelost in de repository, maar nog niet in 3.6.6; je kunt een testversie hier vinden:
https://github.com/dingo35/SmartEVSE-3.5/discussions/111

[TorpedoX_88]

dingo35 schreef op dinsdag 30 juli 2024 @ 15:49:
@TorpedoX_88 Ik heb een soortgelijke melding gehad, volgens mij is dit opgelost in de repository, maar nog niet in 3.6.6; je kunt een testversie hier vinden:
https://github.com/dingo35/SmartEVSE-3.5/discussions/111

Heb de testversie erop staan en het lijkt weer te werken als vanouds, dankjewel!

[Hvdbnl]

Hoi,

Ik heb al een poosje een smartevese setup en dat werkte prima.
Maar nu is de stroom eraf geweest en de SmartEVSE start niet meer op.

Het scherm brand maar flikkert, soort bootloop oid.
Iemand eerder dat gezien, maar vooral heeft iemand een idee wat ik eraan kan doen ?

(Zie dus geen tekst en hij komt ook niet meer online)

[dingo35]

Voor alle SmartEVSE gebruikers, zojuist release v3.6.7 uitgebracht.
https://github.com/dingo35/SmartEVSE-3.5/releases

Changes:

• eliminate strange rebooting behaviour when changing MQTT password
• disabling MQTT by emptying MQTT host field works now
• Fix Power measurement for modbus meters
• Remove unused Calibration option from code
• fix Normal mode charging bug introduced in 15aec8ca9bc6c
• prevent slave from waking up from OFF mode when Masters' solarstoptimer starts to count
• esphome: fix API return code 411, see issue #109
• OCPP: Allow using SmartEVSE local RFID storage with OCPP
• remove OCPP from LCD menu since it is configured on the webserver
• platformio.ini: update OCPP commit hashes

[jopie841]

Hallo, ik heb een vraag:

ik heb een powerdip gehad en sindsdien is mijn EVSE de wifi verbinding kwijt.
Ik heb nog 3.6.2 draaien dus de oude wifi setup procedure
Als ik setupwifi selecteer krijg ik een local hotspot smartevse-xxxx waarmee ik kan verbinden met wifi vanaf mijn telefoon.
Maar als ik vervolgens naar 192.168.4.1 browse krijg ik "this site cannot be reached"
Andere browser, ander device helpt ook niet.
Ik heb een power reset gedaan maar dat helpt ook niet.
(Ik heb ook al eens de nieuwe setup procedure geprobeerd maar krijg niet de juiste output op het scherm dus dat is niet aan de orde)

In de documentatie staat een USB herstel procedure vanaf 3.6.4.
Is er ook zoiets voor oudere releases?
Ik vind het niet erg om op een nieuwere versie over te gaan.

[dingo35]

In v3.6.2 wil het helpen om Wifi op Disabled te zetten in het LCD menu, Exit menu, en dan weer op Enabled.

Zodra je verbinding hebt upgraden naar v3.6.6 of hoger.

Je kunt _altijd_ een nieuwere versie flashen via de USB kabel, zie iets terug in deze thread; de wifi-credentials blijven behouden, zolang je die niet overschrijft met een nieuwe setup.

[ Voor 18% gewijzigd door dingo35 op 01-08-2024 15:42 ]

[dingo35]

Vraag aan SmartEVSE gebruikers die een SolarEdge inverter hebben:

Ik zie in de code dat deze meter NIET geschikt is om als EVMeter te configureren, en het lijkt me dat deze zeker niet geschikt is om als MainsMeter te configureren. Hij is blijkbaar ooit toegevoegd als PV Meter maar dat bleek nutteloze functionaliteit (omdat in de MainsMeter al de PV component verwerkt zit).

Kan de SolarEdge uit de code verwijderd worden of mis ik dan een use case?

[THM0]

dingo35 schreef op dinsdag 6 augustus 2024 @ 10:53:
Vraag aan SmartEVSE gebruikers die een SolarEdge inverter hebben:

Ik zie in de code dat deze meter NIET geschikt is om als EVMeter te configureren, en het lijkt me dat deze zeker niet geschikt is om als MainsMeter te configureren. Hij is blijkbaar ooit toegevoegd als PV Meter maar dat bleek nutteloze functionaliteit (omdat in de MainsMeter al de PV component verwerkt zit).

Kan de SolarEdge uit de code verwijderd worden of mis ik dan een use case?

Je hebt de 'oude' meter met CT klemmen, dat is dacht ik een rebranded Wattnode meter. De nieuwe is draadloos en heeft modbus. Beide zijn bedoeld om direct op een SolarEdge inverter aan te sluiten om oftewel mains te meten oftewel de productie van de omvormer zelf te meten.
Ik kan me niet voorstellen dat je zo'n meter in zou zetten als EVMeter op je SmartEVSE, tenzij je er nog eentje hebt liggen in de la zeg maar. Niemand koopt dit ding specifiek als EVMeter op een SmartEVSE.

[dingo35]

Maar hij is wel als MainsMeter in te zetten, begrijp ik?

[THM0]

dingo35 schreef op dinsdag 6 augustus 2024 @ 16:43:
Maar hij is wel als MainsMeter in te zetten, begrijp ik?

Ja maar bedoeld om de inverter van Mains info te voorzien (voor monitoring portaal, accu sturing en als je de SolarEdge laadpaal of andere SE ‘slimme’ devices hebt die % PV self-consumption kunnen verhogen).
Niet als general purpose mains meter waarvan je de data uitleest en publiceert. Ja het kan, maar dan neem je m.i. eerder een Eastron oid.

[mukky]

Ik heb inmiddels ook Home Assistant draaien en wil van mijn SmartEVSE een slimmer laadsysteem maken dat o.a. de volgende regels in acht neemt:

• Standaard laden op zonne energie indien beschikbaar
• Naar 90% als ik ergens naartoe moet, met een voorkeur voor laden in het weekend in de daluren via Tibber
• Minimale SoC van 50%

Wie heeft er al iets soortgelijks gebouwd?

[Ferrox1]

mukky schreef op woensdag 7 augustus 2024 @ 08:38:
Ik heb inmiddels ook Home Assistant draaien en wil van mijn SmartEVSE een slimmer laadsysteem maken dat o.a. de volgende regels in acht neemt:

• Standaard laden op zonne energie indien beschikbaar
• Naar 90% als ik ergens naartoe moet, met een voorkeur voor laden in het weekend in de daluren via Tibber
• Minimale SoC van 50%

Wie heeft er al iets soortgelijks gebouwd?

https://github.com/jonasbkarlsson/ev_smart_charging

Deze gebruik ik hiervoor. Werkt top! Kan ook met variabele tarieven overweg. Je moet wel de soc van je auto weten in hass.

Ik heb wat ik nog miste als automation gebouwd, met dit als basis input.

[ Voor 5% gewijzigd door Ferrox1 op 07-08-2024 09:57 ]

[ruubert]

Heb je dit bekeken om de geladen energy te meten in HA : https://community.home-as...-software-ev-meter/756936

[jopie841]

In v3.6.2 wil het helpen om Wifi op Disabled te zetten in het LCD menu, Exit menu, en dan weer op Enabled.

Zodra je verbinding hebt upgraden naar v3.6.6 of hoger.

Je kunt _altijd_ een nieuwere versie flashen via de USB kabel, zie iets terug in deze thread; de wifi-credentials blijven behouden, zolang je die niet overschrijft met een nieuwe setup.

Het vreemde is dat de EVSE gewoon lijkt te werken. De wifi is verbonden, ik zie hem in mijn router en hij ontvangt ook MQTT messages. Alleen als ik de webpage probeer te openen krijg ik "connection refused"

Andere route, nieuwe versie flashen via USB:
Ik heb platformio geinstalleerd en ben zover gekomen dat hij probeert iets te uploaden maar dan loop ik vast dat hij geen upload-port kan vinden.
Ik heb gekeken in de Arduino IDE maar die ziet ook geen port. De kabel is goed want die gebruik ik altijd om arduinos te flashen.
Heb ik een speciale USB driver nodig?

[dingo35]

Windows heeft idd een usb driver nodig; het is lang geleden dat ik onder Windows gecompileerd heb, maar volgens mij is het deze driver:

https://www.silabs.com/de...o-uart-bridge-vcp-drivers

[adjego]

Ik gebruik mijn smartevse in samenwerking met Home assistant en ik heb de koppeling gemaakt via de standaard Smartevse integratie. Deze verloopt via MQTT.

Nu zie ik dat sommige entities ineens "unavailable" worden en meteen daarna weer hun vorige status aannemen. Ik heb dit met een collega gecheckt die dezelfde koppeling heeft met Smartevse + Home Assistant en bij hem zie ik ditzelfde gedrag.

Een voorbeeld:



Doordat de mode veranderd wordt er bij mij een automation getriggerd. Daar kan ik natuurlijk wel omheen werken, maar even "unavailable" is toch gek. Ik gebruik meerdere MQTT integraties en alleen bij de SmartEvse zie ik dit gedrag.

Is dit een bekend probleem, of zien meerdere mensen dit?

CC: @dingo35

[HaTe]

adjego schreef op vrijdag 9 augustus 2024 @ 09:40:
Ik gebruik mijn smartevse in samenwerking met Home assistant en ik heb de koppeling gemaakt via de standaard Smartevse integratie. Deze verloopt via MQTT.

Nu zie ik dat sommige entities ineens "unavailable" worden en meteen daarna weer hun vorige status aannemen. Ik heb dit met een collega gecheckt die dezelfde koppeling heeft met Smartevse + Home Assistant en bij hem zie ik ditzelfde gedrag.

Een voorbeeld:

[Afbeelding]

Doordat de mode veranderd wordt er bij mij een automation getriggerd. Daar kan ik natuurlijk wel omheen werken, maar even "unavailable" is toch gek. Ik gebruik meerdere MQTT integraties en alleen bij de SmartEvse zie ik dit gedrag.

Is dit een bekend probleem, of zien meerdere mensen dit?

CC: @dingo35

Hier zie ik dit niet, maar gebruik geen mqtt op de SmartEVSE

[Hmmbob]

Ik zie dit ook, maar niet alle dagen. Gebruik wel MQTT, en het is geen WiFi dekkings-probleem.

[ Voor 28% gewijzigd door Hmmbob op 09-08-2024 11:01 ]

[dingo35]

adjego schreef op vrijdag 9 augustus 2024 @ 09:40:
Ik gebruik mijn smartevse in samenwerking met Home assistant en ik heb de koppeling gemaakt via de standaard Smartevse integratie. Deze verloopt via MQTT.

De SmartEVSE integratie werkt via de REST (http) API. Dat is dus niet via MQTT?

Ik heb zelf beide interfaces met HA draaien en kan dit niet reproduceren, dus als we dit willen oplossen zal er wat meer info moeten komen: welke versies draai je van de firmware, van HA, treedt het bij alle versies op of alleen specifieke...

[dingo35]

@Hmmbob Als je het topic SmartEVSE-6360/connected volgt, gaat die dan offline tijdens zo'n unavailable melding, of blijft die online?

[Sicco92]

Ik gebruik ook beide. De integratie geeft geen probleem:


De MQTT sensors gaan inderdaad soms op unavailable:


Ik zal dat connected topic ook eens in de gaten houden.

[adjego]

dingo35 schreef op vrijdag 9 augustus 2024 @ 13:19:
[...]


De SmartEVSE integratie werkt via de REST (http) API. Dat is dus niet via MQTT?

Ik heb zelf beide interfaces met HA draaien en kan dit niet reproduceren, dus als we dit willen oplossen zal er wat meer info moeten komen: welke versies draai je van de firmware, van HA, treedt het bij alle versies op of alleen specifieke...

Ik heb hem toegevoegd toen Home Assistant hem zelf had "gevonden" in mijn netwerk. Dit is bij mij toch wel echt via MQTT.

Ik draai Home Assistant als docker: Core 2024.6.0 en Frontend 20240605.0
Daarnaast draai ik een mosquito service los op mijn raspberry pi. Versie van mijn Smartevse is gebouwd op 25 juni, toen de master. Maar dit gedrag heb ik altijd gehad. Ik zal komende dagen in ieder geval even updaten naar de meest recente versie.

[Hmmbob]

dingo35 schreef op vrijdag 9 augustus 2024 @ 13:22:
@Hmmbob Als je het topic SmartEVSE-6360/connected volgt, gaat die dan offline tijdens zo'n unavailable melding, of blijft die online?

Heb even een MQTT sensor aangemaakt zodat ik daar de geschiedenis/logboeken van kan zien. Kom erop terug!

[Sicco92]

Ik had ook een sensor aangemaakt, en kreeg een uurtje later alweer een 'unavailable'. Het connected topic gaat dus ook daadwerkelijk offline bij mij:


Wel iets eerder dan de 'Mode' sensor, maar ik weet niet of die vertraging in Home Assistant zit:

[dingo35]

Nu ontbreekt nou juist de "connect" sensor die offline gaat in je log; ik wil de timing graag zien van het offline / online van zowel de connect sensor als de mode; enne, jullie draaien wel de laatste versie v3.6.7?

[dingo35]

Ter toelichting:
Als je SmartEVSE uit staat, en je zet hem aan, krijg je vrijwel onmiddellijk:
Connected online.

Als je daarna de power ruw uitschakelt, duurt het ca. 18-20s voor dat je krijgt:
Connected offline.

Je zou nooit "Connected unavailable" (of "became unknown") moeten krijgen.

Misschien iets met de configuratie van de mqtt server of met HA?

[ Voor 3% gewijzigd door dingo35 op 09-08-2024 17:18 ]

[dingo35]

adjego schreef op vrijdag 9 augustus 2024 @ 15:23:
[...]


[Afbeelding]

Ik heb hem toegevoegd toen Home Assistant hem zelf had "gevonden" in mijn netwerk. Dit is bij mij toch wel echt via MQTT.

Dat is dus NIET via de SmartEVSE integratie, zoals je eerder rapporteerde:
https://github.com/dingo35/ha-SmartEVSEv3

[maarten_NL]

ruubert schreef op woensdag 7 augustus 2024 @ 16:20:
Heb je dit bekeken om de geladen energy te meten in HA : https://community.home-as...-software-ev-meter/756936

Het beschikbare vermogen is niet gelijk aan het feitelijk afgenomen vermogen, bij mijn Hyundai Kona is het structureel een halve A minder dan beschikbaar dus zet ik het circuit op 17A zodat er ook op 16A geladen kan worde. Daarnaast bouwt de lader in de hogere SoC regionen het vermogen af, terwijl er gewoon max A beschikbaar blijft.

[Hmmbob]

dingo35 schreef op vrijdag 9 augustus 2024 @ 17:12:
Nu ontbreekt nou juist de "connect" sensor die offline gaat in je log; ik wil de timing graag zien van het offline / online van zowel de connect sensor als de mode; enne, jullie draaien wel de laatste versie v3.6.7?

3.6.7 ja, en het is nog niet voorgevallen dus kan je nog geen log/screenshots sturen

edit: ik heb nog veel meer apparaten op MQTT, zal eens kijken of er iets anders ook offline duikelt (dat zou op de MQTT server duiden)

[ Voor 14% gewijzigd door Hmmbob op 09-08-2024 19:03 ]

[Hieke]

Voornemens ook een slimme laadpaal te bouwen voor mijn EV op basis van Smart EVSE v3. Als ik de bestelling samenstel op de site van Stegen is deze wat vaag over de keuze van de contactors..

Er staat:
For three phase systems this can either be one 4 pole contactor (IKA432-40), or two 2 pole (IKA232-20) contactors.

Daarbij de volgende afwegingen:

Tesla kan max 11 kW op 3 fases laden.
Ik wil graag in de Solar-modus (on the fly) willen laten schakelen tussen 1 fase en 3 fases. Mijn PV kan max 9 kW leveren.
De behuizing heeft DIN-rail voor 10 eenheden:
- EVSE (3 eenheden)
- Eastron kWh meter 3 fase (4 eenheden)
- 2 contactors (2 eenheden)

Is het mogelijk om te schakelen bij wisselende zonneopbrengst met 2 stuks Iskra 2 polige 32A contactors van 1 naar 3 fases en terug?

In het aansluitschema staat weer een 4-polige met daarachter een 2-polige contactor..

Gezien de ruimte in de kast zou ik graag 2 stuks 2-polige inzetten..

Wat zijn de ervaringen hierover?

[adjego]

dingo35 schreef op vrijdag 9 augustus 2024 @ 17:43:
[...]


Dat is dus NIET via de SmartEVSE integratie, zoals je eerder rapporteerde:
https://github.com/dingo35/ha-SmartEVSEv3

Excuus! Ik was in de veronderstelling dat automatisch gedetecteerde devices via integraties ging 🙂

[ruubert]

maarten_NL schreef op vrijdag 9 augustus 2024 @ 18:49:
[...]


Het beschikbare vermogen is niet gelijk aan het feitelijk afgenomen vermogen, bij mijn Hyundai Kona is het structureel een halve A minder dan beschikbaar dus zet ik het circuit op 17A zodat er ook op 16A geladen kan worde. Daarnaast bouwt de lader in de hogere SoC regionen het vermogen af, terwijl er gewoon max A beschikbaar blijft.

Ik heb inmiddels deze sensors zelf ook gebouwd. Nu kan ik de laadstroom/energy mooi volgen in het Energy dashboard zonder een extra meter te moeten kopen. De Charge Current is zo te zien de actuele stroom die naar de EV gaat. Een andere sensor geeft de maximaal toelaatbare stroom aan.

[dingo35]

Nee, charge current is de stroom die de EVSE ter beschikking stelt aan het EV. Het EV neemt dit als maximum, en bepaalt zelf of, en via hoeveel fasen de stroom afgenomen wordt.
In het algemeen ligt die stroom zo'n 5% onder charge curre t, maar kan ook veel lager zijn. Bijvoorbeeld Tesla start op 1 fase en schakelt dan later de andere fasen bij.

Die integratie is dus hooguit indicatief, als je het gedrag van je EV kent. En daar kom je eigenlijke alleen achter met een kWh meter...

[Stefannn]

Hieke schreef op vrijdag 9 augustus 2024 @ 19:21:

Gezien de ruimte in de kast zou ik graag 2 stuks 2-polige inzetten..

Wat zijn de ervaringen hierover?

Dat is niet de bedoeling.
De reden is dat je met 2x2 in gevaarlijke toestand kan komen als er een relais in een foutmodus terecht komt. Als het relais dat je gedacht had de N+L1 te schakelen niet opkomt en het relais dat L2+L3 schakelt wel dan stuur je spanning zonder N naar de auto en dat is heel erg verkeerd.

Nb, ik weet niet sinds wanneer de text dat het met 2x2 kan in de info staat. Bovenstaande heb ik in een vorige versie eens uit de documentatie gevist (en vond ik er verstandig om op te volgen).

[ Voor 15% gewijzigd door Stefannn op 10-08-2024 06:30 ]

[jopie841]

Windows heeft idd een usb driver nodig; het is lang geleden dat ik onder Windows gecompileerd heb, maar volgens mij is het deze driver:

https://www.silabs.com/de...o-uart-bridge-vcp-drivers

dit deed het hem
Bedankt!

[Hmmbob]

dingo35 schreef op vrijdag 9 augustus 2024 @ 13:22:
@Hmmbob Als je het topic SmartEVSE-6360/connected volgt, gaat die dan offline tijdens zo'n unavailable melding, of blijft die online?

1:1 correlatie

[Kerte]

Hieke schreef op vrijdag 9 augustus 2024 @ 19:21:

Ik wil graag in de Solar-modus (on the fly) willen laten schakelen tussen 1 fase en 3 fases.

Is het mogelijk om te schakelen bij wisselende zonneopbrengst met 2 stuks Iskra 2 polige 32A contactors van 1 naar 3 fases en terug?

In het aansluitschema staat weer een 4-polige met daarachter een 2-polige contactor..

Moet een 4polige en 2polige contactor zijn volgens het schema. Alle andere opstellingen zijn niet veilig!
De smart evse heeft in solar mode (nog) geen werkende AUTO functionaliteit die schakelt tussen 1fasig en 3fasig laden.
Je kan wel solar charging instellen op 1F en smart op 3F laden. Eventueel kan je tussen beide wisselen via een automation in HA

[rene037]

Ik weet niet of het gerelateerd is aan het probleem hierboven, maar ik zag gisteren ineens 'communication error' op het display. Op de website zag ik ook dat de stromen niet meer bijgewerkt werden, terwijl ik met mqttexplorer zie dat de update keurig elke seconde gepublished wordt. Na een reset start de auto met laden maar valt dan na een paar seconde weer af.
Heb wat zitten rommelen en uiteindelijk de mode van SMART op NORMAL gezet en nu staat hij al een tijdje te laden.
Misschien een RTFM, maar als ik op het datumveld klik, kan ik begin en einddatum invullen, daarna zie ik alleen de begintijd, maar wat is het doel daarvan?
Ook de dropdown list daaronder, ik kan een stroom kiezen, maar daarna staat er weer 'Ampere (press normal/smart to set)' Onthoudt hij de instelling wel?

[Hieke]

Beide tweakers dank voor info. Sterkt mijn aanname dat de opstelling bij falen niet veilig is. Anderzijds wat ruimte tussen componenten kan verkoeling geven.
Overigens kleine domper dat er (nog) niet automatisch tussen 1 en 3 fases geschakeld kan worden. Hopelijk komt dat snel beschikbaar. Waarbij mij ook niet helder is of voertuig daar mee om kan gaan.

Voor de zekerheid de vraag:

Mag ik veronderstellen dat de smart evse wel automatisch het amperage op- omlaag regelt? Afhankelijk van aangeboden hoeveelheid beschikbare zonnestroom? Ik wil graag naar nul op de meter..

[Kerte]

Hieke schreef op zaterdag 10 augustus 2024 @ 15:56:
Beide tweakers dank voor info. Sterkt mijn aanname dat de opstelling bij falen niet veilig is. Anderzijds wat ruimte tussen componenten kan verkoeling geven.
Overigens kleine domper dat er (nog) niet automatisch tussen 1 en 3 fases geschakeld kan worden. Hopelijk komt dat snel beschikbaar. Waarbij mij ook niet helder is of voertuig daar mee om kan gaan.

Voor de zekerheid de vraag:

Mag ik veronderstellen dat de smart evse wel automatisch het amperage op- omlaag regelt? Afhankelijk van aangeboden hoeveelheid beschikbare zonnestroom? Ik wil graag naar nul op de meter..

Ja dat kan: je kan bepalen hoeveel stroom er wordt geïmporteerd van het net in solar mode (dus waarde=0 voor wat jij wilt).
De tesla kan ermee om om te switchen 1f-3f.. het laden stopt dan even en herneemt dan met de wijzigingen.
Inderdaad jammer dat de AUTO functionaliteit niet werkt , maar kan gesimuleerd worden in HA .

[Hieke]

@Kerte dank voor toelichting.

Als het zover is kom ik nog met de vraag hoe die simulatie gebouwd kan worden.🤓

[dingo35]

@Hmmbob zou je eens een ping mee kunnen laten lopen bij die connected/online connected/offline transities?

Ik kan alleen een offline forceren door de wifi te disconnecten, een ping zou aan kunnen tonen of er nog andere triggers kunnen zijn....

@rene037 Inderdaad, RTFM.

[dingo35]

@Hieke en @Kerte : C2 Auto werkt inderdaad nog beperkt: hij schakelt wel terug van 3 fasen naar 1 fase, maar (nog) niet van 1 fase terug naar 3 fasen.

[Hmmbob]

dingo35 schreef op zondag 11 augustus 2024 @ 08:53:
@Hmmbob zou je eens een ping mee kunnen laten lopen bij die connected/online connected/offline transities?

Ik kan alleen een offline forceren door de wifi te disconnecten, een ping zou aan kunnen tonen of er nog andere triggers kunnen zijn....

Heb een ping sensor aangemaakt in HA, maar die geeft geen disconnects weer. Kan ook zijn dat die resolutie te laag is....

edit: Je hebt ook code in evse.cpp die dit topic zelf op "offline" zet.

https://github.com/dingo3.../src/evse.cpp#L4356-L4379

edit2: en volgens mij werkt een "Last Will Testament" niet zo zoals die nu geimplementeerd is. Nu zet je zelf dat topic op offline, maar het idee is dat de MQTT broker dat voor je doet zodra die een disconnect gedetecteerd heeft.
https://www.hivemq.com/bl...-last-will-and-testament/

Geen idee hoe je dat in Mongoose doet

edit 3:

Nou, misschien toch een idee....

https://github.com/mongoo...gos_mqtt_conn.c#L205-L209

code:

      opts.will_topic = cfg->will_topic;
      opts.will_message = cfg->will_message;
      if (cfg->will_retain) {
        opts.flags |= MG_MQTT_WILL_RETAIN;
      }

[ Voor 51% gewijzigd door Hmmbob op 11-08-2024 20:09 ]

[dingo35]

@Hmmbob : wat je aanhaalt is een stukje code van mongoose OS; als je mongoose.c bekijkt zie je dat daar noch will_topic, noch wil_message gedefinieerd zijn.

Ik hou me aanbevolen voor verbeteringen, maar ik kan geen betere code voorbeelden vinden van mongoose WebServer waar de will anders behandeld wordt; en, ook niet onbelangrijk, deze code lijkt verder prima te werken; als je de code bekijkt zie je dat de "offline" message bij het starten van de MQTT client verbinding meegegeven wordt aan de server; het is dus de MQTT server die de "offline" message genereert, en niet de SmartEVSE.

Dat leidt me terug naar je "unavailable" probleem: dat lijkt er dus alles mee te maken te hebben dat de MQTT server om één of andere reden denkt dat de SmartEVSE offline geraakt is, terwijl die dat (volgens jou) niet is; dat zou je kunnen bevestigen door een ping mee te laten lopen, ik zou dat persoonlijk niet in HA doen maar gewoon in een terminal venster, al dan niet voorzien van timestamps zodat je ze kunt relateren aan je HA log.

Het zou een configuratie kwestie van je MQTT server kunnen zijn, kijk eens daar in de logs wat die meldt dat er gebeurt op het moment van "unavailable"; misschien staat er een timeout net iets te kort gedefinieerd?

[mukky]

dingo35 schreef op zondag 11 augustus 2024 @ 08:56:
@Hieke en @Kerte : C2 Auto werkt inderdaad nog beperkt: hij schakelt wel terug van 3 fasen naar 1 fase, maar (nog) niet van 1 fase terug naar 3 fasen.

Zit dat in de pijplijn? Ik was me er niet bewust van (maar heb ook nog geen panelen)

[adjego]

dingo35 schreef op maandag 12 augustus 2024 @ 09:15:
@Hmmbob : wat je aanhaalt is een stukje code van mongoose OS; als je mongoose.c bekijkt zie je dat daar noch will_topic, noch wil_message gedefinieerd zijn.

Ik hou me aanbevolen voor verbeteringen, maar ik kan geen betere code voorbeelden vinden van mongoose WebServer waar de will anders behandeld wordt; en, ook niet onbelangrijk, deze code lijkt verder prima te werken; als je de code bekijkt zie je dat de "offline" message bij het starten van de MQTT client verbinding meegegeven wordt aan de server; het is dus de MQTT server die de "offline" message genereert, en niet de SmartEVSE.

Dat leidt me terug naar je "unavailable" probleem: dat lijkt er dus alles mee te maken te hebben dat de MQTT server om één of andere reden denkt dat de SmartEVSE offline geraakt is, terwijl die dat (volgens jou) niet is; dat zou je kunnen bevestigen door een ping mee te laten lopen, ik zou dat persoonlijk niet in HA doen maar gewoon in een terminal venster, al dan niet voorzien van timestamps zodat je ze kunt relateren aan je HA log.

Het zou een configuratie kwestie van je MQTT server kunnen zijn, kijk eens daar in de logs wat die meldt dat er gebeurt op het moment van "unavailable"; misschien staat er een timeout net iets te kort gedefinieerd?

Ik heb iets interessants gevonden in mijn Mosquito logging:

1723432913: Client SmartEVSE disconnected due to protocol error.
1723432914: New connection from 192.168.1.147:56388 on port 1883.
1723432914: New client connected from 192.168.1.147:56388 as SmartEVSE (p2, c0, k15).

Deze timestamp komt exact overeen met in Home assistant unavailable melding:

[Hmmbob]

dingo35 schreef op maandag 12 augustus 2024 @ 09:15:
Het zou een configuratie kwestie van je MQTT server kunnen zijn, kijk eens daar in de logs wat die meldt dat er gebeurt op het moment van "unavailable"; misschien staat er een timeout net iets te kort gedefinieerd?

Ik heb een logtrace in EMQX (MQTT broker) aangemaakt, kijken of dat wat oplevert.

Ik zie in het Dashboard van EMQX wel dat de SmartEVSE net wat andere waardes hanteert dan de andere clients:



Weet niet of daar nog verschil in zit.

edit: ik zie ook dat de SmartEVSE alle topics steeds update, ook als er geen change is. Dat is misschien nog een optimalisatie die gedaan kan worden: enkel gewijzigde waardes sturen. Kan me voorstellen dat dat ook een beetje processorbits op de EVSE kan schelen.

Note over PR gezien, maar weet niet of mij dit gaat lukken

[ Voor 14% gewijzigd door Hmmbob op 12-08-2024 11:18 ]

[dingo35]

mukky schreef op maandag 12 augustus 2024 @ 09:26:
[...]

Zit dat in de pijplijn? Ik was me er niet bewust van (maar heb ook nog geen panelen)

Het staat op mijn lijstje, maar het is een complex gebeuren waar al meerderen hun tanden op stuk gebeten hebben, dus ik kan weinig zeggen over óf en zo ja wanneer dit gerealiseerd kan worden.

[mukky]

dingo35 schreef op maandag 12 augustus 2024 @ 12:47:
[...]


Het staat op mijn lijstje, maar het is een complex gebeuren waar al meerderen hun tanden op stuk gebeten hebben, dus ik kan weinig zeggen over óf en zo ja wanneer dit gerealiseerd kan worden.

Klinkt als een interessant probleem, is er ergens een overzicht van de huidige stand van zaken en uitdagingen te vinden? Ik denk graag mee.

[dingo35]

Hmmbob schreef op maandag 12 augustus 2024 @ 11:01:
[...]

Ik heb een logtrace in EMQX (MQTT broker) aangemaakt, kijken of dat wat oplevert.

Ik zie in het Dashboard van EMQX wel dat de SmartEVSE net wat andere waardes hanteert dan de andere clients:

[Afbeelding]

Weet niet of daar nog verschil in zit.

edit: ik zie ook dat de SmartEVSE alle topics steeds update, ook als er geen change is. Dat is misschien nog een optimalisatie die gedaan kan worden: enkel gewijzigde waardes sturen. Kan me voorstellen dat dat ook een beetje processorbits op de EVSE kan schelen.

Dat is toch n beetje een probleem van MQTT, dat het zelf niet filtert op wijzigende waardes.
Het bijhouden van alle te publiceren variabelen kost véél meer dan het aanroepen van de (vrij lichte) publish routine....

[dingo35]

@mukky: we proberen de source code zo goed mogelijk inline te documenteren. grep -ir nr_of_phases src/evse.cpp brengt je bij de relevante stukjes code.

[Hieke]

dingo35 schreef op maandag 12 augustus 2024 @ 12:47:
[...]


Het staat op mijn lijstje, maar het is een complex gebeuren waar al meerderen hun tanden op stuk gebeten hebben, dus ik kan weinig zeggen over óf en zo ja wanneer dit gerealiseerd kan worden.

Ik heb er vertrouwen in.
Als terug schakelen lukt is de stap naar opschakelen nabij, zou ik denken. En is het een echt smart device geworden.😎

Zo te merken ben ik niet de enige die er naar uitziet.
Temeer nu energieboeren het verbruik van nul op de meter een financiële prikkel hebben gegeven.
Maar ook het idee om met eigen elektronen in de accu te rijden.🤠
Alvast veel dank voor uw inspanningen er een mooier produkt van te maken!

[Hmmbob]

@dingo35 Heb de logs vanuit de broker in een issue op je repo geplaatst, dat is makkelijker opvolgen dan hier in het topic: https://github.com/dingo35/SmartEVSE-3.5/issues/115

/cc @adjego

[Hmmbob]

adjego schreef op maandag 12 augustus 2024 @ 09:53:
[...]


Ik heb iets interessants gevonden in mijn Mosquito logging:


[...]

Bij mij gaat het ook over een fout in de verbinding inderdaad. De oude socket wordt dichtgegooid, en er komt een nieuwe connectie vanaf de SmartEVSE:

[MQTT] SmartEVSE-6360@192.168.88.216:59592 msg: mqtt_packet_received, packet: {frame_error,#{cause => zero_remaining_len,header_type => 0}}, username: smartevse
[SOCKET] SmartEVSE-6360@192.168.88.216:59592 msg: socket_force_closed, reason: [cause: zero_remaining_len, header_type: 0], username: smartevse
[PUBLISH] SmartEVSE-6360@192.168.88.216:59592 msg: publish_to, topic: SmartEVSE-6360/connected, username: smartevse, payload: offline
[MQTT] SmartEVSE-6360@192.168.88.216:59593 msg: mqtt_packet_received, packet: CONNECT(Q0, R0, D0, ClientId=SmartEVSE-6360, ProtoName=MQTT, ProtoVsn=4, CleanStart=false, KeepAlive=15, Username=smartevse, Password=******, Will(Q0, R1, Topic=SmartEVSE-6360/connected Payload=offline)), username: smartevse
[SUBSCRIBE] SmartEVSE-6360@192.168.88.216:59593 msg: subscribe, sub_id: SmartEVSE-6360, sub_opts: [nl: 0, qos: 1, rap: 0, rh: 0, sub_props: []], topic: SmartEVSE-6360/Set/#, username: smartevse
[UNSUBSCRIBE] SmartEVSE-6360@192.168.88.216:59592 msg: unsubscribe, sub_opts: [nl: 0, qos: 1, subid: SmartEVSE-6360, rap: 0, rh: 0, sub_props: []], topic: SmartEVSE-6360/Set/#, username: smartevse
[MQTT] SmartEVSE-6360@192.168.88.216:59593 msg: mqtt_packet_sent, packet: CONNACK(Q0, R0, D0, AckFlags=1, ReasonCode=0), username: smartevse
[SOCKET] SmartEVSE-6360@192.168.88.216:59592 msg: emqx_connection_terminated, reason: {shutdown,takenover}, username: smartevse
[MQTT] SmartEVSE-6360@192.168.88.216:59593 msg: mqtt_packet_received, packet: SUBSCRIBE(Q1, R0, D0, PacketId=36 TopicFilters=[SmartEVSE-6360/Set/#(#{nl => 0,qos => 1,rap => 0,rh => 0})]), username: smartevse
[SUBSCRIBE] SmartEVSE-6360@192.168.88.216:59593 msg: subscribe, sub_id: SmartEVSE-6360, sub_opts: [nl: 0, qos: 1, rap: 0, rh: 0, sub_props: []], topic: SmartEVSE-6360/Set/#, username: smartevse

Zie de verschillende clients: SmartEVSE-6360@192.168.88.216:59592 en SmartEVSE-6360@192.168.88.216:59593

[mukky]

Kwam op een camping een VEVOR lader tegen met een print zoals in bijlage. Hij “hangt”, de rechter LED moet een heartbeat laten zien maar brandt solide. Iemand een idee hoe een rest uit te voeren? De handleiding (link) spreekt over een emergency stop die er niet op zit en de knop die er wel op zit heeft geen effect. Scherm gaat wel aan maar reageert nergens op. Tips welkom 🙂

[Hmmbob]

Groep afschakelen in de meterkast?