Hey Philipp,
is it possible, that you post and show us your Templates and your Scripts which are used to set the Charging power? I’m still strugglin around with some Challenges and have not a simple Solution as yours.
Hi Phillip. I need some help 
I started testing the latest Keba Integration of yours but I have accidentally set my Keba P30x to automatically start in failsafe mode on every restart of the box. I5 must have happened when clicked the config button on the device tab. While I was just testing the functionality to see if it could give me some ideas to automate things, I need a way to get the box back to NOT starting in failsafe mode again, before I reinstall the integration and start to build my usecase from scratch. Please assist - how can I make the failsafe setting go back to not starting after box restart? Thank you for assistance in advance!
Hi all, has anyone got a P20 integration up and running? Or is the P20 not supported?
Thank you very much,
Tommy
Hi all
used the keba integration a long time, now wanted to try the new “beta” version.
I don’t get it to work…
I have a Keba P30 x series without rfid.
But I used it anyway with local authorization and a manually added rfid serial.
Now I don’t get the integration to work.
In the old integration, I used authorize and enable for starting charging and deauthorize and disable for stopping.
I can’t get it to work with the new integration. I tested different variation of lock/unlock (regarding the code the same as start/stop) and also enable and disable.
The strange thing is, it works always the first time after keba reboot to use start and stop. But then it stops working. The state shows “authorization rejected”. irrelevant what I try, I only get it to start again if I reboot the keba.
I thought it’s maybe the rfid class, because this shows me sometime a different class than the default from the code, but tried almost all combinations. And I read somewhere, that the class is only relevant for a OCPP backend, which I don’t use.
I also tried different local authorization settings without luck 
After this first time it works, I always get TCH-ERR:no need for start
Anyone which using the “beta” has a working setup while using authorization without an actual rfid reader, and would share the authorization settings and the “actions” to start and stop?
EDIT:
yesterday it worked perfectly with only lock/unlock authentication.
Today it again stopped working. Always no matter what I did, the keba didn’t react audible nor visible to any action. Just showed always “swipe card” in the display. Re-insert the plug in the EV and it started immediately charging.
Not sure if the car is the problem… but I would have expected at least the keba reacts somehow to the commands. The log only stated “no need for start”.
Hi everyone, I am new with my keba P30 and homeassistant. The Keba - integration (beta) is running pretty well. However, I don`t find a solution for setting the target energy for the current session (set-energy). I find the topic in the services.yaml. However among the Keba-entities I can find only a sensor for it (which is working well after sending an UDP-Command by packet sender).
I am not very experienced and obviously I am doing something wrong - can anybody help me and give me a hint?
Thanks a lot, Gerd R.
1 Like
Hi all, I did a simple KEBA P30 integration via Modbus which works nicely with multiple wallboxes. This is rather stress-free and works like a charm for me. I am also able to read all sensors and also am able to write values to all elements that can be controlled.
In my case I have a X-series that works as a master and a C-series that acts as a slave.
I am not sure if I miss somethings which prevents others to not use the Modbus, but if you enable UDP in your stations you automatically enable the Modbus interaction as well.
Check it out: KEBA Wallbox integration via ModBus - also for Master-Slave setups
1 Like
Hi,
I have an problem with integrating my wallbox in home assistant.
I have done the configuration as described in the documentation(see below if ther is an error)
The IP-adress of the wallbox is coorect - I have double checked this in my router as well with calling the keba “website” via ip-adress.
After a restart of HA, i get the following error messages, but I don’t know how to solve this problem 
Logger: homeassistant.setup
Source: setup.py:273
First occurred: 12:02:33 (1 occurrences)
Last logged: 12:02:33
Setup failed for keba: Integration failed to initialize.
and:
Logger: homeassistant.components.keba
Source: components/keba/init.py:68
Integration: keba (documentation, issues)
First occurred: 12:02:33 (1 occurrences)
Last logged: 12:02:33
Could not find a charging station at 192.168.20.161
Can you please be so kind and help me?
Thanks
Hi @hosiz
what is your installation type? Docker, HassOS? Could you enable debug logging and check the logs?
Hi @dannerph
I am trying to install Keba Charging Station directly in HA.
But it keeps giving me an error, no sure what i’m doing wrong.
if i check the logs i only find this:
This error originated from a custom integration.
Logger: custom_components.keba.config_flow
Source: custom_components/keba/__init__.py:229
Integration: Keba Charging Station
First occurred: 20:29:07 (3 occurrences)
Last logged: 20:35:28
Unexpected exception
Traceback (most recent call last):
File "/config/custom_components/keba/config_flow.py", line 128, in async_step_connect
info = await validate_input(self.hass, user_input)
File "/config/custom_components/keba/config_flow.py", line 42, in validate_input
keba = await get_keba_connection(hass)
File "/config/custom_components/keba/__init__.py", line 229, in get_keba_connection
hass.data[DOMAIN][KEBA_CONNECTION] = await create_keba_connection(hass.loop)
File "/usr/local/lib/python3.10/site-packages/keba_kecontact/connection.py", line 385, in create_keba_connection
await keba_connection.init_socket(bind_ip)
File "/usr/local/lib/python3.10/site-packages/keba_kecontact/connection.py", line 128, in init_socket
self._stream = await asyncio_dgram.bind((bind_ip, UDP_PORT))
File "/usr/local/lib/python3.10/site-packages/asyncio_dgram/aio.py", line 239, in bind
transport, protocol = await loop.create_datagram_endpoint(
File "/usr/local/lib/python3.10/asyncio/base_events.py", line 1385, in create_datagram_endpoint
raise exceptions[0]
File "/usr/local/lib/python3.10/asyncio/base_events.py", line 1369, in create_datagram_endpoint
sock.bind(local_address)
OSError: [Errno 98] Address in use
Any idea?
You could try the newest 3.0.3 beta release through HACS if you have more than one charging station (there was an issue in pre 3.0.0). If you only have one charging station, it seems that your port 7090 is already used by another process.
That should be it than, I was using port 7090 in Node Red, port is probably still open.
I will check it tomorrow.
Thanks!
Update: That was the problem
Thanks for reporting back! Unfortunately, this is the limitation of the udp interface: it always answers to port 7090 and only one process can bind this port.
I have it version 3.0.3 working, sort of anyway.
I am have the feeling the pulling rate it to fast for the Keba charging station, or the amount of requests at one go is to much.
You can seen in the log file below, that the Keba charging station only replying to the last request be and than the are already new request made for other reports.
Am not sure if the doble report is because the way the debug logging work,s or if it is send twice to HASSIO. Seems odd. ,(i could hook up wireshark to see what’s happening in real live.)
Is there any way to slow down the request rate?
2023-03-14 12:36:30.116 DEBUG (MainThread) [keba_kecontact.connection] **Send report 2** to 10.0.0.180
2023-03-14 12:36:30.218 DEBUG (MainThread) [keba_kecontact.connection] **Send report 3** to 10.0.0.180
2023-03-14 12:36:30.322 DEBUG (MainThread) [keba_kecontact.connection] **Send report 100** to 10.0.0.180
2023-03-14 12:36:30.424 INFO (MainThread) [keba_kecontact.chargingstation] Periodic data request executed, now wait for 5 seconds
2023-03-14 12:36:30.453 DEBUG (MainThread) [keba_kecontact.connection] Datagram received from 10.0.0.180: {
**"ID": "100",**
"Session ID": 347,
"Curr HW": 16000,
"E start": 83738096,
"E pres": 36374,
"started[s]": 1678787839,
"ended[s]": 0,
"started": "2023-03-14 09:57:19.000",
"ended": "0",
"reason": 5,
"timeQ": 0,
"RFID tag": "XXX",
"RFID class": "XXX",
"Serial": "XXX",
"Sec": 2683197
}
2023-03-14 12:36:30.454 INFO (MainThread) [keba_kecontact.chargingstation] KEBA P30 (XXX - P30 v 3.10.36 (211117-093932)) at 10.0.0.180 datagram received
2023-03-14 12:36:30.454 DEBUG (MainThread) [keba_kecontact.chargingstation] Data: {
**"ID": "100",**
"Session ID": 347,
"Curr HW": 16000,
"E start": 83738096,
"E pres": 36374,
"started[s]": 1678787839,
"ended[s]": 0,
"started": "2023-03-14 09:57:19.000",
"ended": "0",
"reason": 5,
"timeQ": 0,
"RFID tag": "XXX",
"RFID class": "XXX",
"Serial": "XXX",
"Sec": 2683197
}
2023-03-14 12:36:30.462 DEBUG (MainThread) [keba_kecontact.chargingstation] Executed 46 callbacks
2023-03-14 12:36:32.362 DEBUG (MainThread) [keba_kecontact.connection] Datagram received from 10.0.0.180: {"E pres": 36406}
2023-03-14 12:36:32.363 INFO (MainThread) [keba_kecontact.chargingstation] KEBA P30 (XXX - P30 v 3.10.36 (211117-093932)) at 10.0.0.180 datagram received
2023-03-14 12:36:32.363 DEBUG (MainThread) [keba_kecontact.chargingstation] Data: {"E pres": 36406}
2023-03-14 12:36:32.371 DEBUG (MainThread) [keba_kecontact.chargingstation] Executed 46 callbacks
2023-03-14 12:36:35.426 DEBUG (MainThread) [keba_kecontact.chargingstation] Periodic data request rescheduled
2023-03-14 12:36:35.429 DEBUG (MainThread) [keba_kecontact.connection] **Send report 2** to 10.0.0.180
2023-03-14 12:36:35.532 DEBUG (MainThread) [keba_kecontact.connection] **Send report 3** to 10.0.0.180
2023-03-14 12:36:35.635 DEBUG (MainThread) [keba_kecontact.connection] **Send report 100** to 10.0.0.180
2023-03-14 12:36:35.658 DEBUG (MainThread) [keba_kecontact.connection] Datagram received from 10.0.0.180: {
**"ID": "100",**
"Session ID": 347,
"Curr HW": 16000,
"E start": 83738096,
"E pres": 36454,
"started[s]": 1678787839,
"ended[s]": 0,
"started": "2023-03-14 09:57:19.000",
"ended": "0",
"reason": 5,
"timeQ": 0,
"RFID tag": "XXX"",
"RFID class": "XXX",
"Serial": "XXX",
"Sec": 2683202
}
2023-03-14 12:36:35.659 INFO (MainThread) [keba_kecontact.chargingstation] KEBA P30 (XXX - P30 v 3.10.36 (211117-093932)) at 10.0.0.180 datagram received
2023-03-14 12:36:35.659 DEBUG (MainThread) [keba_kecontact.chargingstation] Data: {
**"ID": "100",**
"Session ID": 347,
"Curr HW": 16000,
"E start": 83738096,
"E pres": 36454,
"started[s]": 1678787839,
"ended[s]": 0,
"started": "2023-03-14 09:57:19.000",
"ended": "0",
"reason": 5,
"timeQ": 0,
"RFID tag": "XXX",
"RFID class": "XXX",
"Serial": "XXX"",
"Sec": 2683202
}
2023-03-14 12:36:35.669 DEBUG (MainThread) [keba_kecontact.chargingstation] Executed 46 callbacks
2023-03-14 12:36:35.737 INFO (MainThread) [keba_kecontact.chargingstation] Periodic data request executed, now wait for 5 seconds
2023-03-14 12:36:38.840 DEBUG (MainThread) [keba_kecontact.connection] Datagram received from 10.0.0.180: {"E pres": 36505}
2023-03-14 12:36:38.841 INFO (MainThread) [keba_kecontact.chargingstation] KEBA P30 (XXX - P30 v 3.10.36 (211117-093932)) at 10.0.0.180 datagram received
2023-03-14 12:36:38.841 DEBUG (MainThread) [keba_kecontact.chargingstation] Data: {"E pres": 36505}
2023-03-14 12:36:38.848 DEBUG (MainThread) [keba_kecontact.chargingstation] Executed 46 callbacks
2023-03-14 12:36:40.739 DEBUG (MainThread) [keba_kecontact.chargingstation] Periodic data request rescheduled
2023-03-14 12:36:40.741 DEBUG (MainThread) [keba_kecontact.connection] **Send report 2** to 10.0.0.180
2023-03-14 12:36:40.843 DEBUG (MainThread) [keba_kecontact.connection] **Send report 3** to 10.0.0.180
2023-03-14 12:36:40.866 DEBUG (MainThread) [keba_kecontact.connection] Datagram received from 10.0.0.180: {
**"ID": "3",**
"U1": 228,
"U2": 228,
"U3": 228,
"I1": 8135,
"I2": 8133,
"I3": 8140,
"P": 5557691,
"PF": 997,
"E pres": 36534,
"E total": 83774630,
"Serial": "23510237",
"Sec": 2683208
}
2023-03-14 12:36:40.867 INFO (MainThread) [keba_kecontact.chargingstation] KEBA P30 (XXX - P30 v 3.10.36 (211117-093932)) at 10.0.0.180 datagram received
2023-03-14 12:36:40.867 DEBUG (MainThread) [keba_kecontact.chargingstation] Data: {
**"ID": "3",**
"U1": 228,
"U2": 228,
"U3": 228,
"I1": 8135,
"I2": 8133,
"I3": 8140,
"P": 5557691,
"PF": 997,
"E pres": 36534,
"E total": 83774630,
"Serial": "23510237",
"Sec": 2683208
}
2023-03-14 12:36:40.876 DEBUG (MainThread) [keba_kecontact.chargingstation] Executed 46 callbacks
2023-03-14 12:36:40.947 DEBUG (MainThread) [keba_kecontact.connection] **Send report 100** to 10.0.0.180
2023-03-14 12:36:41.049 INFO (MainThread) [keba_kecontact.chargingstation] Periodic data request executed, now wait for 5 seconds
2023-03-14 12:36:41.903 DEBUG (MainThread) [keba_kecontact.connection] Datagram received from 10.0.0.180: {
**"ID": "100",**
"Session ID": 347,
"Curr HW": 16000,
"E start": 83738096,
"E pres": 36551,
"started[s]": 1678787839,
"ended[s]": 0,
"started": "2023-03-14 09:57:19.000",
"ended": "0",
"reason": 5,
"timeQ": 0,
"RFID tag": "XXX",
"RFID class": "XXX",
"Serial": "XXX",
"Sec": 2683209
}
20
Hi @OttoJager
yes that looks like that your charging station is not able to answer all requests. Do you have NodeRed fetching data as well in parallel?
There is no possibility to reduce the fetching rate yet, however, performance optimization is already on my todo list (e.g. fetching report 100 only if charging status changes or report 3 only if charging is active). I might include a setting of fetching rate as well.
Hi @RoSche
thanks for your hint! Unfortunately, not all Keba P20/P30 support ModbusTCP as far as I know. My BMW Wallbox Plus for example, which is internally a Keba P30 without display, only speaks UDP. Anyhow, ModbusTCP provide a more reliable communication, as packet loss is already tackled on Transport Layer. Using Failsafe mode, UDP is still a feasible option if you want to realise a charging controller. If you just use the integration for monitoring and authorization, UDP is fine as well. So, I would say it is up to the specific use case to decide which protocol to use.
Greetings Philipp
@TommyM
sorry for answering late, have you got it working? I implemented according to the manual, so Keba P20 should be support. Please let me know if something is not working/missing.
No, Node Red was not requesting any reports at the time from the log.
Now however my load shedding is sending an keep alive current setpoint signal. But it is not really influencing it i think.
Good to optimize the performance. I think it would make more sense to use the t_UDP_pause times that kecontactp30udp_pgen manual.
What is triggering the request at this moment? Which file has that part of the code?
As I am relatively new to HA, I came upon this integregration and was able to setup my SolarEdge EV charger, which is basically a P30x in disguise.
The integration works perfectly and I can use the slider to change the charging current when charging.
What I am not able to figure out is how to automate that charging current value. What I would like is to use the excess power from my PV to charge the car. When the power drops from the PV, the charge current (or better the power) should drop and vise versa. That would allow to maximise the use of the PV power. Somehow, I’m not able to send a number value to the current entity.
Edit: I was able to set the number using the ‘set_value’ service in the number domain. This set the value to the wanted current as well as turned on the charging when set to a value between 6 and 32.
Hi @jongbj
Do you also have a SolarEdge inverter for your PV array?
I have a SolarEdge inverter and a Keba P30 X-Series.
My inverter is connected to the network using Ethernet, and I use the SolarEdge Modbus integration for Home Assistant, and also Dannerph’s Keba integration.
I then use a custom automation that I wrote to have the excess solar funneled into the car by increasing/decreasing the MaxChargeCurrent on the EVSE. this automation maintains the MaxChargeCurrent at a minimum of 1.4kw so that the charge session isn’t constantly stopping and starting as the clouds pass.
You could also look into evcc.io which is available as a HomeAssistant add-on (I will probably move to this at some point). It’s just tricky for most as while the UI supports English, all the documentation is in German.
1 Like
@OttoJager
t_UDP pause should be respected if I am not wrong. current update time is 5 seconds, if a command is sent, the update time decreases to 1 second (for faster response) for a while.