EVSE Keba P30 integration

dannerph · November 7, 2021, 9:56am

Hi @vic,
the firmware version is part of report 1, which is already fetched. However, we only take the product value form this report. So technically it is possible, but I do not see the need for that in home assistant (convince me to be wrong ).

The report 1xx that contains the charging session history is not implemented yet. There is no straight forward way to convert this history data in a form so that home assistant can store it conveniently. If you have an idea, feel free to fork and improve the python library

dannerph · November 7, 2021, 10:18am

Hi @stefankns,
I guess you are the first user here with a KEBA charging station without RFID. I quickly checked the documentation and it seems that the RFID is optional, which I used as mandatory in the python library (I was not aware that such a configuration exists).

Solving this issue should be fairly easy. However, I would need some testing with your device. Are you able to run a python script?

stefankns · November 8, 2021, 5:02pm

Hi @dannerph,

thanks for answering. Yes, I can do some testing with the device and I think I can run scripts. I have installed Home Assistant on Hass.IO as a VM and have not run a python script in that environment yet, but I will figure it out. Just tell me what to do.

After my post, I dug a little deeper and it might be worthwhile to share my insights. Upfront, the info about the exact model type of my box: KC-P30-EC2401B2-L00. As stated, no RFID. So I tried to play around with Packet Sender to communicate with UDP packets directly. I got it running and all info and report messages work as expected. But I realized, that with my actual authentification settings, starting a charging session without a valid RFID tag number does not seem to be possible. This left me with the problem, that editing the local RFID whitelist is not possible without a card reader installed. After re-booting the wallbox several times I realized though, that the wallbox seems to take some time to understand, that it is not equipped with a RFID reader. The RFID menu showed up some seconds and I could retrieve the URL ( “http://hostname/whitelist.php” ). Beeing authenticated to the WebGUI, that link is still working even when the RFID menu is disabled/removed from the interface. So, in the end I managed to add an 8 digit RFDI tag number to the whitelist. With Packet Sender and the UDP Start command, I was now able to successfully initiate a charging process and also to stop it again with the UDP Stop command. Nevertheless, the integration is still not working with that RFID number in the `configuration.yaml’ file, but I read from your post, that you might have a solution for this?

dannerph · November 8, 2021, 6:52pm

What I actually wanted to test is, if the wallbox starts charging when sending the start command via udp without RFID number, which does not seem to work if I have not misinterpreted your tests?

According to the UDP programming guide, the RFID tag and RFID classifier are optional. My quick solution would have been to simply not send an RFID tag as part of the start command in case none is configured.
https://www.keba.com/web/downloads/e-mobility/KeContact_P20_P30_UDP_ProgrGuide_en.pdf

Maybe this could help you: According to the manual (page 21) of my BMW Wallbox Plus (which is internally a Keba P30 without display), it is possible to disable RFID using the service button.

stefankns · November 8, 2021, 8:54pm

Hi again,

ok. I understand your thinking. I will try to run an “empty” start command (without any RFID number) tomorrow again, but I will have to do some tests with different authorization settings. Right now Authorization is “on”, Online Authorization is “FirstLocal” and Offline Authorization is “OfflineNoCharging”. Would be helpful to understand more how the different wallbox hardware configurations and authentication settings influence the behaviour with respect to the UDP command protocol.
My intention was, to use the UDP communication (or the keba integration of yours) to be able to lock and unlock the charging station, because the wallbox is located in an semi public space. So I would also like to further investigate, why the integration is not working for me, when UDP command line commands with Packet Sender and a “fake” RFID tag number do the job now. Is there any chance to see the response from the box (detailed logging on home assistant side) to the start command sent by the integration? I cannot see any log entries in the wallbox log about denied commands or similar.

dannerph · November 8, 2021, 9:24pm

To enable debug logging, add the following to your home assistant configuration file:

logger:
  default: warning
  logs:
    homeassistant.components.keba: debug
    # wrong: keba: debug
    keba_kecontact: debug

UDP is stateless, however the box will reply with “TCH-OK :done”, if the command was successful and with “TCH-ERR:(specific error message)” otherwise, if I remember correctly.

stefankns · November 8, 2021, 9:53pm

Thx. Hm. When I copy that into my configuration.yaml and re-start HA i get:

Logger: homeassistant.setup
Source: setup.py:178
First occurred: 22:47:55 (1 occurrences)
Last logged: 22:47:55

Setup failed for keba: Integration failed to initialize.

Seems that I am doing something wrong here.

EDIT: had to restart home-assistant host and the Wallbox. Now logging works.

stefankns · November 8, 2021, 10:26pm

The logs are empty, when executing one of the services of the integration (e.g. keba.set_energy).
When starting the charging process via ocpp or the WebGui and sending a stop by HA, there is the following message in the log

Command rejected: TCH-ERR:nothing to stop
23:04:53 – (WARNUNG) /usr/local/lib/python3.9/site-packages/keba_kecontact/keba_protocol.py

Looks like UDP comm is really working (otherwise all the status would not be updated either, right?)
The „nothing to stop“ might be related to sending a stop with an RFID tag, that was not used to start the charging session would be my explanation.
As said, I will change the authorization settings tomorrow and give feedback, if there is a combo that is working.

stefankns · November 9, 2021, 9:25am

I did some tests now , but the results are rather confusing for me. First of all, changing settings related to authorization in the WebGui of the wallbox without re-starting it (also in case it is not asking for it) sometimes leaves the box in a - for me - non-reproducible state.

About the start command:
It does not matter if authorization is on or off, in both cases, an “empty” start command (e.g. packetsender -u -a <ip> 7090 "start" -w 2000 -b 7090) results into

Response ASCII:TCH-ERR:: wrong parameter count\n

So, in contradiction to the programming guide, the token seems not to be optional. When authorization is off, a start command with an existing or non-existing RFID token (e.g. packetsender -u -a <ip> 7090 "start 12345678" -w 2000 -b 7090) results into

Response ASCII:TCH-ERR:no need for start\n`

which is not surprising.

General behaviour with setting “authorization off”:
With this setting, the through the integration offered services keba.set_energy, keba.set_current are working. For keba.authorize and keba.deauthorize nothing happens (checked by report 2) and nothing shows up in the debug log. The same for keba.enable and keba.disable. Interesting is, that both, enable (ena 1) and disable (ena 0) work flawless from the console with Packet Sender. I can follow these changes also in the status of the wallbox at http://<wallbox-ip>:8080.

What is the exact string, that is sent by keba.enable and keba.disable by the integration? Would it make sense to put the send-string in debug-logging level into the log-file?

Another thought I had is, that I might have a rather unusual setup here:
SmartHome VLAN - DLAN Bridge - Unifi AP 801.11ng → Wallbox WLAN.
This sometimes introduces quite a high latency. This is why I wait at least 2000ms for a reply in Packet Sender. Yes, UDP is stateless, the command should be executed anyway, but the reply might get lost for error handling or logging. What wait time is used in the implementation?

I also forgot to mention the software version of my wallbox in the previous posts. It is release version 1.12.1.

dannerph · November 9, 2021, 6:25pm

The „nothing to stop“ might be related to sending a stop with an RFID tag, that was not used to start the charging session would be my explanation.

that is correct, stop is sending the configured RFID tag. if there is no charging session running with that RFID tag, stopping should not be possible.

dannerph · November 9, 2021, 6:53pm

The string for keba.enable and keba.disable is “ena 1” and “ena 0”, respectively:

github.com

dannerph/keba-kecontact/blob/2c580e160292eec053e22b5688625878e2b54c7e/keba_kecontact/connection.py#L157


      
              await asyncio.sleep(0.1)  # Sleep for 100 ms as given in the manual
          
          async def enable(self, ena):
              """Start a charging process."""
              if not self._setup:
                  await self.setup()
          
              if not isinstance(ena, bool):
                  raise ValueError("Enable parameter must be True or False.")
              param_str = 1 if ena else 0
              self.keba_protocol.send("ena " + str(param_str))
              await asyncio.sleep(0.1)  # Sleep for 100 ms as given in the manual
          
          async def unlock_socket(self):
              """Unlock the socket.
          
              For this command you have to disable the charging process first. Afterwards you can unlock the socket.
              """
              if not self._setup:
                  await self.setup()

All commands are debug logged:

github.com

dannerph/keba-kecontact/blob/2c580e160292eec053e22b5688625878e2b54c7e/keba_kecontact/keba_protocol.py#L129


      
              else:
                  _LOGGER.debug("No ID in response from Keba charging station")
                  return False
          
              # Join data to internal data store and send it to the callback function
              _LOGGER.debug("Execute callback")
              self._callback(self.data)
          
          def send(self, payload):
              """Send data to KEBA charging station."""
              _LOGGER.debug("Send %s", payload)
              self._transport.sendto(payload.encode('cp437', 'ignore'))

The python library uses the suggested 100ms waiting time after each command sending. Replies are handled in an asynchronous way - meaning, once a reply is received on the separate listening socket it is processed.

My wallbox does not have any settings via web interface nor OCPP, so I am not able to test our specific case.

I need to apologize, I mistakenly send you a wrong (old) debug logger config, it should be the following to see the debug messages of the library:

logger:
  default: warning
  logs:
    homeassistant.components.keba: debug
    keba_kecontact: debug

stefankns · November 10, 2021, 9:48am

Thanks for the links and the infos. Now I understand better, how the integrations works. I have changed the logging settings and I am glad to be able to see the debug info now. The picture is as follows:

When I call the service keba.setenergy from the HA interface i get:

2021-11-10 10:04:58 DEBUG (MainThread) [keba_kecontact.keba_protocol] Send setenergy 25000.0
2021-11-10 10:04:58 DEBUG (MainThread) [homeassistant.components.keba] Fast polling enabled
2021-11-10 10:04:58 DEBUG (MainThread) [keba_kecontact.keba_protocol] Send report 1
2021-11-10 10:04:58 DEBUG (MainThread) [keba_kecontact.keba_protocol] Send report 2
2021-11-10 10:04:58 DEBUG (MainThread) [keba_kecontact.keba_protocol] Datagram received.
2021-11-10 10:04:58 DEBUG (MainThread) [keba_kecontact.keba_protocol] Command accepted: TCH-OK :done
2021-11-10 10:04:58 DEBUG (MainThread) [keba_kecontact.keba_protocol] Datagram received.
2021-11-10 10:04:58 DEBUG (MainThread) [keba_kecontact.keba_protocol] Send report 3
2021-11-10 10:04:58 DEBUG (MainThread) [keba_kecontact.keba_protocol] Datagram received.
2021-11-10 10:04:58 DEBUG (MainThread) [keba_kecontact.keba_protocol] Execute callback

Looks expected to me. Especially the Command accepted line is in match with the command being executed by the wallbox properly.

When calling keba.enable the logs look like this:

2021-11-10 10:05:45 DEBUG (MainThread) [keba_kecontact.keba_protocol] Send ena 1
2021-11-10 10:05:45 DEBUG (MainThread) [homeassistant.components.keba] Fast polling enabled
2021-11-10 10:05:45 DEBUG (MainThread) [keba_kecontact.keba_protocol] Send report 1
2021-11-10 10:05:45 DEBUG (MainThread) [keba_kecontact.keba_protocol] Send report 2
2021-11-10 10:05:45 DEBUG (MainThread) [keba_kecontact.keba_protocol] Send report 3
2021-11-10 10:05:45 DEBUG (MainThread) [homeassistant.components.keba] Periodic data request executed, now wait for 2 seconds
2021-11-10 10:05:46 DEBUG (MainThread) [keba_kecontact.keba_protocol] Datagram received.
2021-11-10 10:05:46 DEBUG (MainThread) [keba_kecontact.keba_protocol] Datagram received.
2021-11-10 10:05:46 DEBUG (MainThread) [keba_kecontact.keba_protocol] Execute callback

There is no charging process started on the wallbox, but I can neither see a Command accepted nor Command rejected line as expected from the code that you showed.

Right now, I can only see these reason:

The command is never sent.
Exactly this UDP command is ignored by the wallbox when sent through HA/HA host (but working properly from command line with Packet Sender from another computer).
There is no datagram coming back from the wallbox at all (meaning the datagram received lines are associated with the report requests).
The response is malformed/unexpected, so that the code in keba_protocol.py line #40 and #44 does not output anything.

I personally have the impression, that #1 or #2 might be the hottest candidate, because #3 and #4 would not be an issue in the first place if the command would be executed.

Any ideas how I could test #1 and #2? I am at my limits with HA here but willing to learn. I checked all my wallbox log files, that I can access, and there is nothing in there for the timestamps of the sent commands.

vic · November 10, 2021, 10:18pm

Hi @dannerph,
thanks for the feedback.
Got you point on the FW version
For the report 1xx, what about using the fields as attributes?
I am a bit overloaded in this period. As soon as I have some free time I will make some tests with the Python library.
In the meantime I have found a nice and simple app with a similare scope: Wallbox control (https://play.google.com/store/apps/details?id=com.chk.go_elocal). I’d like to replicate that level of info in HA.

dannerph · November 10, 2021, 10:57pm

The enable command (ena X) should be used to permanently disable the system by using the parameter 0. After receiving ena 0 the device will be disabled until it is rebooted or ena 1 or currtime are used. The execution of ena 0 will take approximately 1 second. If ena 0 is used, then no other command should be sent for 2 seconds to ensure an undisturbed execution of the disable command.

I would not go with a solution to use ena for authentication.

Have you tried to use little-endian hex representation of the RFID tag in the home assistant keba config? E.g. 78 56 34 12 instead of 12 34 56 78? I remember that the RFID tag is stored differently than printed in the manual and on the card.

dannerph · November 10, 2021, 11:10pm

I had a look in the manual again: If I got it correctly the report 101-130 contain historical values which from my point of view do not make sense to push to home assistant (there is no support to store past values). However, report 100 is all zero in case of no active charging process and will be filled with starting parameters (including the RFID tag) once a session starts. So it should be possible to add a sensor(s) or attribute values in home assistant to hold the parameters of the active session (starting time, RFID tag, RFId class, …). If you have influxdb recording, you can calculate the individual energy consumption afterwards.

I have only used one card so far, thus had no need for this feature. Implementation should be straight forward. I might find some time in the next weeks.

vic · November 11, 2021, 8:17pm

This is also my understanding: 100 for current, 1xx for older.
I was looking at the history data, besides the current one, because I log the power consumption of all devices and have some statistics.
I know that I have the total power consumed already now, but then I have no time relation.
I need to have a deeper look at it, as soon as I can.

By the way, I have initialized 1 card as master (and put away for security reasons ) and then 2 other cards. One that I use every day for charging and one for friends or neighbors that may need to charge when I am not there. My wallbox is installed in an underground garage where also other cars are parked.

stefankns · November 25, 2021, 9:12am

I have made some progress and I would like to share my results.

The authentication settings, that proved to work with my wallbox (Vattenfall branded) and this integration are as follows:

Authorization: On

Online Authorization Mode: FirstLocal

Offline Authorization Mode: OfflineNoAuthorization

For me, the RFID number needs to be specified in the HA config file in the same way it is stored in the RFID card database of the wallbox. I have already commented in this thread how to inject a RFID card number into the database even without an integrated RFID card reader present.

Now about another quite interesting part:
Even with these setting, there was still a long delay in the wallbox response (up to 1-2s) or no reaction at all. I tracked it down to the WLAN connection in the end. The OCPP communication is, as far as I know, TCP, which might explain why this was working reliably. For the UDP only protocol there seems to be a quite high packet loss rate, if connected via WLAN. A bit of a disappointment, concerning the price of the wallbox and the fact that an access point is located just some 5m from the box.
I re-cabled the wallbox to use the LSA connector for a wired LAN connection and ever since, UDP is working perfectly with a nearly immediate response.

I still have the issue though, that using the keba.deauthorize service after a keba.authorize, the boxs shows “unknown card”. I will have to look into that later on.

For those interested, I still use the integration in parallel to the OCPP Home Assistant integration (from HACS). Works well and delivers some additional info like serial number and firmware version right now.

grandslam · November 25, 2021, 6:35pm

Hi @stefankns

I’m in the same boat. Just got my Keba X-series without RFID. As you already found out, I made the same observation till now. Can’t test everything, because the Car is not arriving till at Monday
But could already test the authorization stuff.
Not sure if you got that already, but currently have with OnlyLocal and OfflineNoAuthorization and it works without “hacking” an specific RFID.
From my current observations, for me it looks like KEBA is adding every used RFID code into the Whitelist with Status unknown. With with my settings from above, it works with the default integration RFID no. without a problem. I think it should also work with other Authorization settings when the RFID no. Status is changed to accepted. So if the integration would allow to define at runtime the code it would even be possible to use multiple codes, even it probably only makes sense to differentiate the reason for authorization in automations vs. manual.
My goal is to just authorize when low tariff starts. And stop when the car has reached a defined SOC.

@dannerph
Maybe it would be nice to have the possibility to send custom RFID no. at runtime via the services and depending on the testing results without a RFID no. also. Would allow to use a specific RFID no. during automations and i.e. per person also a specific RFID no. when unlocked by hass from a user. With this it would be possible to track who did the authorization.

dannerph · November 25, 2021, 8:48pm

Hi @grandslam,
that should be possible. I will keep it in mind to add optional RFID codes in the service call to replace the default one when I have some time. But anyhow, feel free submit a PR to the home assistant core, the python library already supports this

dannerph · November 30, 2021, 10:11am

FYI: a good friend of mine will install a second keba wallbox soon. Thus I now have both motivation and a testing setup for multiple wallbox support.