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.
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.
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.
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.
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.
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
I have finally looked at your implementation (very good indeed!) and I have made some tests to retrieve the history data, but it is still not working as I expected.
In the meantime I have cleaned up my interface, adding some extra info from the wallbox and now it looks much nicer
I think it would be nice to be able to use different keys to unlock the wallbox, beside the one in the configuration file.
As soon as I have a good idea on how to manage the history data I will ping you. But it could take a while. My job is not leaving me any free time in this period.
I was wondering how precisely I can configure the maximum current used by the P30. Is it possible to set the current every 5 seconds to exactly match* the amount of returned power to the grid read from my P1 meter? Does it accept all values as floats, or maybe only ints, which would get me pretty far, or only a predefined set of values such as 8, 16, 22 etc.?
I obviously need to do some calculations and know the power factor, but that’s all doable.
the extra info is already polled, so I have slightly modified the Keba binary sensor file to have extra attributes. Then I have defined sensors to show these attributes.
I am not the creator/owner of the binary sensor file though.
@dannerph is it OK to share the changes to the original file?
I got time to intergrate your card, I adjust sensor template and removed data missing from keba driver.
It seems that there is a error on the max charging rate because it is not a pourcentage (there is as well a max charging rate poucentage on the UDP API) but it is a value in mA.
See Keba Doc :
See below new sensor definition (it seems that charging rate is Max curr)
Hi @bobkersten,
I have an automation that sends new charging rates once a new meter reading is received. My meter updates every 3-4 seconds, so 5 seconds should work as well.
It should accecpt float values (will be parsed to int), however the communication between every wallbox and every car is limited to integer steps (6A - 63A). This is limited by the PWM “communication” over the charging cable. Depending on how many phases your car is charging, you can control between 1.38kW - 7.36 kW (single phase) and 4.14 kW - 22 kW (three phase). If you own an older VW/Skoda (two phase charging), it is somewhere in between (I observed that depending on the SoC either single or two-phase charging is used).
I was already thinking of integrating a new command so that power in kW could be set. By using the internal measurements of current it would be possible to identify the number of phases that are used to charge and using the measured voltage it would be possible to set a charging current as near as possible to the given charging power (maximum gap depending on the number of phases and in the range of ~230 W - 690 W).
What do you think, is that helpful? (Planning to do a re-design of the integration in near future anyhow)
) 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.
the 60Ah battery (~18kWh usable) is enough to reach most destinations (>98% for me). For the remaining, I have the range extender.
