The GD - ESP32 communication needs to make sure that the commands are successful

The ack responses should be checked.

Solution I'd like

The least that should come out of this is a warning in the log if the GD is not reacting (correctly) to our commands.

Additional context

The GD chip is in charge if the jumper CN7 is in the non default position.
In this situation our firmware on the ESP32 is not able to fulfil its purpose and therefore we should detect this and issue a warning/error message.

It would be cool to have an easy way to backup and restore the config of a WARP charger.

The Config is basically already available via the /debug_report json blob, but not everything in there is config and the restore part is completely missing.

Solution I'd like

I'd like to have a command line tool to fetch a config and make a backup, as well as a convenient way to push it back to the box.

The restore could be done via curl calls with the appropriate HTTP-API parameters (see: https://www.warp-charger.com/api.html?v=2#http_section) generated from the /debug_report json backup.

Migrate the already happened releases.

Probably this is a low priority task, but it might be a plus to migrate the old releases for historical purposes.

• enter STA mode without password (within first minutes) with HW button
• web interface
  • reset configuration
  • factory reset

Fehlerbeschreibung

Folgenden Fehler kann ich bei meiner Wallbox mit zwei Autos (Ford Kuga Hybrid + VW e-Up!) reproduzieren:

1. Ladekabel wird angeschlossen
2. "Start" im Webinterface drücken
3. Fahrzeugstatus bleibt bei "Ladebereit" und der Ladevorgang startet nicht 💩
4. "Stop" im Webinterface drücken und kurz warten
5. "Start" im Webinterface drücken
6. Fahrzeugstatus ist nur kurz "Ladebereit" und springt dann auf "Lädt" ⚡

Wenn das Ladekabel nicht entfernt wurde, dann klappt es direkt.
Das führt auch dazu, dass meine manuelle EVCC-Integration in Home Assistant nicht ohne Workaround funktioniert (siehe unten).

Log

evse-debug-log-AC011K-10052110232864-2023-04-22T09-36-32-396.txt

Versions:

• Firmware version: warpAC011K_firmware_2_0_12_642fc3b9_eb3a3c721bbaf51_cranky16_merged.bin.zip

EVCC Workaround

Ich habe in Home Assistant das EVCC Addon installiert und übersetze per Node-RED die MQTT-Befehle von EVCC in die Sprache der Wallbox und umgekehrt. Für das oben beschriebene Problem habe ich in Node-RED einen Workaround gebaut. Ich habe meine Lösung (die bisher nur rudimentär getestet wurde) hier angefügt. Vielleicht hilft es ja jemanden 🤝

Wallbox-Node-RED-Flow.json.txt
evcc.yaml.txt
(Achtung: Ich musste jeweils die Dateiendung ändern, damit ich die Dateien hier hochladen konnte)

The old place had a wiki describing the purpose and stuff, it's needed here too

Please migrate the old wiki into the warp-more-hardware project.

There is a negative value for the charged energy tracked

Presumably the reason is that the was ESP restarted during a charging session.

To Reproduce

As this is only an assumption, the reproducer would be to restart the ESP deliberately during a charging session and investigate.

Expected behaviour

The tracked values should not be harmed by a restart.

Debug Log

   "ac011k_hardware/meter": {
     "energy_rel": 143.998,
     "energy_rel_raw": 10.263,
     "energy_rel_delta": 133.735,
     "energy_abs": 206.825,
     "energy_abs_raw": 10.263,
     "energy_abs_delta": 196.562
   },
   "charge_tracker/last_charges": [
     {
       "timestamp_minutes": 27935256,
       "charge_duration": 6301,
       "user_id": 0,
       "energy_charged": 9.286999
     },
     {
       "timestamp_minutes": 27936748,
       "charge_duration": 65614,
       "user_id": 0,
       "energy_charged": 6.735001
     },
     {
       "timestamp_minutes": 27941344,
       "charge_duration": 51021,
       "user_id": 0,
       "energy_charged": 64.466
     },
     {
       "timestamp_minutes": 27951021,
       "charge_duration": 22972,
       "user_id": 0,
       "energy_charged": 33.76999
     },
     {
       "timestamp_minutes": 27952544,
       "charge_duration": 0,
       "user_id": 0,
       "energy_charged": -186.907
     }
   ],
   "charge_tracker/current_charge": {
     "user_id": 0,
     "meter_start": 204.064,
     "evse_uptime_start": 4988,
     "timestamp_minutes": 27952740,
     "authorization_type": 0,
     "authorization_info": null
   },
   "charge_tracker/state": {
     "tracked_charges": 5,
     "first_charge_timestamp": 27935256
   },

Versions:

• Firmware version: 2.0.11-63e3f5c9

Additional context

The MQTT settings where altered just before the wrongfully tracked charge session.
That leads to the assumption that the ESP restarted (as all config changes lead to a suggested restart in the UI).

The charge manager may benefit from a status light.

In a load managed scenario, a status light can give visual indication regarding the current situation to users.

There are four (or five) states that would be interesting to know about.

1. There is enough headroom to not being limited while charging. (green)
2. Load management measures are in place, charging may be limited or delayed. (blue)
3. Charging is forbidden at all. (red)
4. The load management setup is in an error state (i.e. not all to be managed wallboxes are responding). (pink)
5. The charge manager is off. (off)

Solution I'd like

There are smart color bulbs available that can easily show the states described above (and more).

I'd wish for a Module that fetches the status of the charge manager periodically and sets the color of a light bulb accordingly.

Alternatives

A full blown display to tell about the status seems too much for the purpose.

Additional context

The Shelly Duo RGBW is widely available and has an easy to use HTTP-API to control it.

The discussion area for this project would help.
Thank you for your efforts.

I've followed the wiki and made a backup for the two chips.

The GD backup is:
esp - bin file 8.4 MB
gd - bin file - 524 KB
gd - hex file - 1.2 MB

For GD I've used the app, not the script

Is this correct?

AC011K-AE-25_V1.2.460.hex is just 539 KB

The absolute energy consumed shall be ever growing

At the moment the energy_abs value is reset on power cycling the AC011K.
This value should be persisted and survive reboots of the GD chip.

Solution I'd like

Just save energy_abs onto flash.

Additional context

If this value is not persisted, and the ESP32 reboots during charging, the values are off and lead to wrong tracked charges with negative energy_charged values:

{
  "uptime": 88201,
  "charge_tracker/last_charges": [
    {
      "timestamp_minutes": 27895007,
      "charge_duration": 7017,
      "user_id": 0,
      "energy_charged": 6.389
    },
    {
      "timestamp_minutes": 27895448,
      "charge_duration": 37447,
      "user_id": 0,
      "energy_charged": 22.305
    },
    {
      "timestamp_minutes": 27896166,
      "charge_duration": 81505,
      "user_id": 0,
      "energy_charged": -42.179
    },
    {
      "timestamp_minutes": 27897664,
      "charge_duration": 11529,
      "user_id": 0,
      "energy_charged": 10.253
    },
    {
      "timestamp_minutes": 27898210,
      "charge_duration": 44995,
      "user_id": 0,
      "energy_charged": 11.208
    },
    {
      "timestamp_minutes": 27899007,
      "charge_duration": 85317,
      "user_id": 0,
      "energy_charged": 5.302
    },
    {
      "timestamp_minutes": 27900528,
      "charge_duration": 19032,
      "user_id": 0,
      "energy_charged": 12.205
    },
    {
      "timestamp_minutes": 27901055,
      "charge_duration": 226663,
      "user_id": 0,
      "energy_charged": 11.623
    },
    {
      "timestamp_minutes": 27905615,
      "charge_duration": 123212,
      "user_id": 0,
      "energy_charged": -49.621
    },
    {
      "timestamp_minutes": 27908051,
      "charge_duration": 64970,
      "user_id": 0,
      "energy_charged": 7.753
    },
    {
      "timestamp_minutes": 27909434,
      "charge_duration": 68372,
      "user_id": 0,
      "energy_charged": 7.208001
    },
    {
      "timestamp_minutes": 27910732,
      "charge_duration": 6994,
      "user_id": 0,
      "energy_charged": 6.317001
    },
    {
      "timestamp_minutes": 27910895,
      "charge_duration": 1383,
      "user_id": 0,
      "energy_charged": 1.261
    },
    {
      "timestamp_minutes": 27910957,
      "charge_duration": 5497,
      "user_id": 0,
      "energy_charged": 5.063002
    },
    {
      "timestamp_minutes": 27911087,
      "charge_duration": 158319,
      "user_id": 0,
      "energy_charged": 21.696
    },
    {
      "timestamp_minutes": 27914047,
      "charge_duration": 46965,
      "user_id": 0,
      "energy_charged": 9.857002
    },
    {
      "timestamp_minutes": 27915181,
      "charge_duration": 13072,
      "user_id": 0,
      "energy_charged": -55.055
    },
    {
      "timestamp_minutes": 27915481,
      "charge_duration": 131027,
      "user_id": 0,
      "energy_charged": 8.351001
    },
    {
      "timestamp_minutes": 27917952,
      "charge_duration": 14623,
      "user_id": 0,
      "energy_charged": 13.365
    },
    {
      "timestamp_minutes": 27918367,
      "charge_duration": 43023,
      "user_id": 0,
      "energy_charged": 8.618
    },
    {
      "timestamp_minutes": 27919131,
      "charge_duration": 7037,
      "user_id": 0,
      "energy_charged": 6.389
    },
    {
      "timestamp_minutes": 27919273,
      "charge_duration": 19035,
      "user_id": 0,
      "energy_charged": 5.140999
    },
    {
      "timestamp_minutes": 27919671,
      "charge_duration": 60580,
      "user_id": 0,
      "energy_charged": 11.702
    },
    {
      "timestamp_minutes": 27921227,
      "charge_duration": 0,
      "user_id": 0,
      "energy_charged": -64.128
    },
    {
      "timestamp_minutes": 27921524,
      "charge_duration": 32660,
      "user_id": 0,
      "energy_charged": 0
    },
    {
      "timestamp_minutes": 27922284,
      "charge_duration": 12417,
      "user_id": 0,
      "energy_charged": 6.632
    },
    {
      "timestamp_minutes": 27922670,
      "charge_duration": 51697,
      "user_id": 0,
      "energy_charged": 6.146
    },
    {
      "timestamp_minutes": 27923633,
      "charge_duration": 23200,
      "user_id": 0,
      "energy_charged": 17.869
    },
    {
      "timestamp_minutes": 27924231,
      "charge_duration": 0,
      "user_id": 0,
      "energy_charged": -46.626
    },
    {
      "timestamp_minutes": 27925007,
      "charge_duration": 56,
      "user_id": 0,
      "energy_charged": 0.208
    }
  ],
  "charge_tracker/current_charge": {
    "user_id": -1,
    "meter_start": 0,
    "evse_uptime_start": 0,
    "timestamp_minutes": 0,
    "authorization_type": 0,
    "authorization_info": null
  },
  "charge_tracker/state": {
    "tracked_charges": 60,
    "first_charge_timestamp": 0
  }
}

Describe the bug

I start charging the car and configure for example 12 A as load current.
In the web interface, everything looks fine, but the power meter still just shows 1,4 kW (car only supports 1 phase loading = 6 A).

Expected behavior

The car should be charged with 2,7 kW when the load current is set to 12 A.

Versions:

• Firmware version: warpAC011K-2.0.12
• Make and model of the car do you want to charge: Ford Kuga Hybrid

Additional context

Before I flashed the firmware, I have used the ChargeIn App and there it was also not possible to raise the current over 6A (even though the app reported success on changing the load current).
Maybe the GD chip is hung-up somewhere and power on and off does not reset this.
Is it possible to reset the GD chip to factory defaults, or is it recommended flashing the GD firmware?

The PlatformIO upload target for the warpAC011K build environment is broken

% pio run -e warpAC011K --upload-port /dev/ttyUSB0 -t upload

builds the right firmware, but the upload is (probably due to the not properly working pio extra_script.py) not working properly.

To Reproduce

Steps to reproduce the behavior:

1. run % pio run -e warpAC011K --upload-port /dev/ttyUSB0 -t upload with no OTA target reachable via 10.0.0.1

Expected behaviour

Successful uploaded firmware via serial.

Screenshots & Logfiles

interesting lines:

Uploading .pio/build/warpAC011K/firmware.bin
There is no AC011K WARP at 10.0.0.1, skip OTA flashing "/home/michelepa/draft/warp/esp32-firmware/software/build/warpAC011K_firmware_2_0_11_63d78fd5_merged.bin"

Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [==        ]  20.2% (used 66228 bytes from 327680 bytes)
Flash: [=====     ]  47.3% (used 1797529 bytes from 3801088 bytes)
Building .pio/build/warpAC011K/firmware.bin
esptool.py v4.4
Creating esp32 image...
Merged 25 ELF sections
Successfully created esp32 image.
Copying /home/michelepa/draft/warp/esp32-firmware/software/.pio/build/warpAC011K/firmware.bin
Merging firmware.bin
esptool.py v4.4
Wrote 0x1c7410 bytes to file build/warpAC011K_firmware_2_0_11_63d78fd5_merged.bin, ready to flash to offset 0x1000
Configuring upload protocol...
AVAILABLE: cmsis-dap, custom, esp-bridge, esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa
CURRENT: upload_protocol = custom
Uploading .pio/build/warpAC011K/firmware.bin
There is no AC011K WARP at 10.0.0.1, skip OTA flashing "/home/michelepa/draft/warp/esp32-firmware/software/build/warpAC011K_firmware_2_0_11_63d78fd5_merged.bin"
========================================================= [SUCCESS] Took 32.90 seconds =========================================================

Environment    Status    Duration
-------------  --------  ------------
warpAC011K     SUCCESS   00:00:32.905
========================================================== 1 succeeded in 00:00:32.905 ==========================================================

Additional context

PlatformIO extra scripts

I'd like to have mesh networking for the ESP32 WiFi.
Less infrastructure is less maintenance and a lower investment in the first place.
Therefore I'd like to have the capability of a bunch of WARP chargers to form a WiFi mesh network and utilise that to do load management.

The solution I'd like
I'd like to have the ESP32 run in AP+STA mode and build a WiFi MESH to form a load management setup that spans a bigger area easily.
https://www.espressif.com/en/products/sdks/esp-wifi-mesh/overview

Alternatives
More hardware. I.e. WiFi access points.
Obviously possible, but not desirable.

Additional context
The ESP32 in Access point mode by default can have only 4 WiFi clients. This limit can be upped to 10 at compile time. That is not enough and does not scale in two dimensions.

1. Number of WIFI devices obviously. If, in addition to multiple WARP chargers, mobile devices as clients to access the web ui come into play, 4-10 is surely enough for one charger, but not a load management setup.
2. Geographical expanse. The WiFi range of the ESP32 is limited and a parking lot can easily span a larger area and therefore extending the WiFi coverage would be a big plus as well.

Describe the bug

Charging starts in spite of Autostart = off when plugging car in. (No start button pressed)

To Reproduce

Steps to reproduce the behavior:

1. The LED stripe on the charger where blinking green.
2. I plugged the charge cable into the car.
3. The car started to charge and
4. hitting Stop did not work either, I had to stop the charge by using the cars app

Expected behavior

If autocharge is of the car shouldn't start charging by itself.

Versions:

• Firmware version: 2.0.11-63e237d2
• Make and model of the car do you want to charge: MG4 electric

debug-report-AC011K-10052201194085-2023-02-07T14-27-58-429.txt

• remove dependencies in call hirachie
• call all from ac011k.cpp

Make the 4MB build working.

The 4MB build is too big at the moment to be flashable onto 4MB hardware.

Solution I think is most likely

Probably the project does not fit into 4MB twice (for OTA falshing) so the OTA part could be taken out to make it work.
For that there should be a no_ota_4MB_coredump.csv and maybe the OTA flashing disabled in the backend.

see: https://github.com/warp-more-hardware/esp32-firmware/blob/master/software/warpAC011K.ini#L87

[env:warpAC011K4mb]
extends = env:warpAC011K
board_build.partitions = default_4MB_coredump.csv

The firmware info feature should be enabled

To make sure nobody flashes wrong versions of the firmware onto the right device, the require_firmware_info feature should be enabled.

Describe alternatives you've considered

Probably we want to postpone this to the point where we are confident that nobody wants to go back to prior firmwares (as those had that feature disabled).

Additional context

https://github.com/warp-more-hardware/esp32-firmware/blob/master/software/warpAC011K.ini#L26

Describe the bug

Today i have overwritten my AC011K-AE-25 with this firmware, i could not read the ESP32 internal memory maybe they blocked via flags. Flashed everything according the documentation, thank you for this amazing port.

So i got in troubles because it did not communicate with the GD Chip, i also upgraded the GD firmware, nothing changed, now after 3 hours, i found the problem, latest code saw good for me and than i found out, the support for AC011K-AE-25-STL was added after the release, so i build it locally by myself and now it's working. Maybe would be good to create a new release?

The build is broken by esphome/issues#5258, a little change need be done, that the build ends successful.

Logfile
2024-01-01 14:39:05,858 EVSE serial: SN10052204053161 hw: AC011K-AE-25-STL fw: 1.2.653
2024-01-01 14:39:05,859 EN+ GD EVSE Firmware Version or Hardware is not supported.

No communication with the GD Chip

To Reproduce

Flash AC011K-AE-25-STL with latest esp32-firmware 2.0.12-64033399 from release page / documentation

Expected behavior

Should communicate with GD Chip

Versions:

• Firmware version: 2.0.12-64033399 from release page / documentation

Fix

The fix was supplied with 3218cbb build locally and upload it by OTA

On the AC011K hardware, the RTC is not set when NTP syncs.

The RTC on the AC011K hardware should be set on NTP sync just like on the original TF hardware, but due to the ifdef it is not.

Best would be to find a solution that TinkerForge is willing to merge.
Or something that does not involve changing the NTP module.

https://github.com/warp-more-hardware/esp32-firmware/blob/master/software/src/modules/ntp/ntp.cpp#L62-L71

• generating files for hex data
• documentation to get firmware (supported versions)
• adjustment of compileroptions

• extend firmware upload from web interface
• when not esp32 FW check for GD firmware
• flash GD firmware interface

I'd like to have an EVSE mockup module.

The module should provide the functionality to simulate a charge cycle without any hardware (EVSE, car) so we can test the software.

Solution I'd like

I think the best would be to have a drop in replacement to emulate the serial communication with the GD chip on the AC011K hardware.
That would enable us to develop for the AC011K without having the hardware available.

But that would put the additional burden on us to emulate that thing.

Alternatives I've considered

The second possibility would be to copy the evse_v2 module and strip it down to just work in software and trigger state changes via the HTTP/MQTT api.

This is probably more easy.

MQTT: Not Authorized, but correct Username/Password

MQTT: Keine Verbindung möglich, trotz Username/Passwort korrekt

Describe the bug

No Connection to my MQTT Broker (Mosquitto on HA) due to failed Authorization.
Log from MQTT Broker:
2024-01-05 11:32:35: New connection from 192.168.0.93:53706 on port 1883.
error: received null username or password for unpwd check
2024-01-05 11:32:35: Client Wallbox disconnected, not authorised.
2024-01-05 11:32:50: New connection from 192.168.0.93:53707 on port 1883.
error: received null username or password for unpwd check
2024-01-05 11:32:50: Client Wallbox disconnected, not authorised.
2024-01-05 11:33:05: New connection from 192.168.0.93:53708 on port 1883.
error: received null username or password for unpwd check
2024-01-05 11:33:05: Client Wallbox disconnected, not authorised.

To Reproduce

Steps to reproduce the behavior:

1. Enter MQTT Credentials
2. Activate MQTT in Webserver
3. Wallbox reported "connected to Broker"
4. See in Logfile: Password for MQTT User is always "null", but entered many times.

Expected behavior

MQTT authorization and auto-discovery

Screenshots & Logfiles

debug-report-AC011K-10052109275264-2024-01-05T11-40-41-156.txt
debug-report-AC011K-10052109275264-2024-01-05T11-39-16-334.txt

Versions:

• Firmware version: <2.0.12-64033399>
• Make and model of the car do you want to charge:

Additional context

It seems the MQTT password entered on the Webinterface couldn't be saved successfully. So my MQTT Broker denies the Authorization.

There are a few pointers in the Web User Interface that originally link to warp-charger.com for more info. This needs to point to somewhere in the warp-more-hardware project.

1. We have to make sure we do not put any burden on the TinkerForge people by linking to their site and let users of our port end up seeking out for help to them.
2. We need some helpful documentation for our port without duplicating the documentation that is already available from TinkerForge.

I'm talking about:
https://github.com/warp-more-hardware/esp32-firmware/blob/master/software/warp2.ini#L20
https://github.com/warp-more-hardware/esp32-firmware/blob/master/software/warpAC011K.ini#L22
and alike.

I'd like to have a batch config tool for load management setups.

When you have to configure a bunch of wallboxes in a load management scenario, it will be handy to describe the config of all of the WARP chargers in a single .csv file and apply the configs semi-automatically in n easy way.

Solution I'd like

I'd like to have a tool that takes the info from a table (.csv) and generates the configs that can be applied via the restore process from #20.

Format of the .csv file

TBD

Describe the bug

Nach Einspielen der 2.0.12 blinkt die Wallbox bei verbundenem Fahrzeug nur noch gelb.
Statusseite zeigt keine Änderung - dauerhaft getrennt - MQTT evse/state -

{"iec61851_state":0,"charger_state":0,"GD_state":0,"contactor_state":0,"contactor_error":0,"allowed_charging_current":16000,"error_state":0,"lock_state":0,"dc_fault_current_state":0,"time_since_state_change":155123,"last_state_change":0}

1.2.99 funktioniert.

To Reproduce

Hab jetzt mehrere Versuche durch:
EN+ von Entratek (DOT Eco)
ausgeliefert mit GD-Version 1.1.888

1.2.99 geflashed - läuft wie gedacht.
OTAUpdate auf 2.0.12 - Fehler wie oben beschrieben.

Zurück auf Herstellerfirmware - läuft. Schnell noch eine RFID-Karte gelöscht, da vergessen.
Werksreset in Herstellerfirmware
1.2.99 geflashed - läuft.
2.0.12 geflashed - Fehler wie oben beschrieben. Zeigt Konfigversion 1.2.99. Zurückgesetzt. Zeigt Konfigversion 1.0.0
OTA-GD-Firmware-Update auf 1.2.460. Warten das geflashed. 100% - reboot - sicherheitshalber noch mal Powercycle - Fehler wie oben beschrieben.

Zurückgeflashed auf Herstellerversion.
Noch mal auf Werkseinstellungen gesetzt.
2.0.12 geflashed - Zeigt Konfigversion 1.0.0 - Fehler wie oben beschrieben
Einfach mal probehalber cranky16 OTA drübergebügelt - Fehler wie oben beschrieben

OTADowngrade auf 2.0.8 - Status wird wieder richtig dargestellt - gelb blinkend = wartend - Laden lässt sich aber nicht starten.

OTADowngrade auf 1.2.99 - Alles funktioniert wieder

Expected behavior

Funktion wie 1.2.99

Screenshots & Logfiles

debug-report2_0_12-AC011K-10052205315112-2023-04-07T11-49-13-232.txt
debug-report2_0_8-AC011K-10052205315112-2023-04-07T12-10-10-645.txt
debug-report1_2_99-2023-04-07T10-56-32-478Z.txt

The AC011K has a TF-card.

The original firmware uses that to store logs.

It would be nice to have that capability as well in our project.

To not wear out the TF-card, daily rotation would be nice.

The build is suffixed with the timestamp in hex format, but the git commit hash may be more helpful.

Using the build timestamp as defining fact to identify a build is probably less desirable than something that can point to the used code.

Solution I'd like

• Using the git commit hash on a clean git tree,
• but using the timestamp on a unclean working tree (and indicating an unclean build in the filename)

Additional context

We have to make sure this does not interfere with the build timestamp that is used in the code to make sure the RTC clock is fine.

rtc auto sync is not connected

Hi,
first of all: Nice project! I really like the idea of getting the wallbox out of that cloud-nonsense.

In the flash manual in the wiki is a link to a released firmware as a bin file, but that is not available anymore (there are absolutly no releases).

Therefore I tried to build the firmware myself (from warp2-2.0.11):
platformio run -e warp2

and flashed it:
esptool.py --chip esp32 --port /dev/ttyUSB0 write_flash -z --flash_size detect 0x1000 warp2_firmware_2_0_11_63f7358a_merged.bin

After this the ESP hangs in an boot loop:
rst:0x3 (SW_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0030,len:1184 load:0x40078000,len:13132 load:0x40080400,len:3036 entry 0x400805e4 ets Jul 29 2019 12:21:46

Did I build the firmware correctly? I have an older Evsedo branded box, the ESP reports to be an 8 MB version.

Thank you in advance!

It may be cool to use the proximity of nearby bluetooth devices as a way to authorise charging.

I'm not sure if this is in any way secure, but that is not an important point, because nobody has to use such a feature.

Solution in mind

It should be quite easy to scan for bluetooth devices nearby periodically and inject device IDs nearby just like RFID IDs into the RFID- / user- modules.

Maybe this is not feasible at all

I've not done any research on how often i.e. a smartphone sends a bluetooth ID or if there are any other blockers that make this idea totally not worth it.
If you know any blockers for this, please comment.

Mehr Dokumentation wäre Hilfreich.

Die Wiki Dokumentation könnte für die V2 Firmware mehr Inhalt und eine Abgrenzung zum TinkerForge Projekt vertragen.

Wo sind wir gleich, und wo sind Unterschiede?

Kontext
Die drei Seiten

• Dokumentation
• Firmware und
• MQTT und HTTP API

dürfen nicht umbenannt werden, da von der Firmware darauf verwiesen wird.

Wenn es hier Bedarf für eine andere Nomenklatur gibt, wäre es sinnvoll das vor dem Release zu klären.

Using the AC011K board as the dev platform is sub optimal.

The entry level to join the project is probably too high.
It would be desirable to be able to compile the project for more widely available hardware to begin with.

Probably the most ESP32s out there have 4MB of flash.

The solution I'd like
There should be a configuration that compiles for the 4MB boards and includes a mocked EVSE module to test the project without having an electric vehicle nor a wallbox.

We already have parts of that but it's not working out of the box right now.

Missing parts are:

• a stripped down version of the build (see: #14)
• the EVSE mockup module (see: #15)
• some beginners onboarding documentation to get a newcomer started