Replies: 7 comments 13 replies
-
I believe the wallbox pulsar plus only supports specific values for the maximum current. |
Beta Was this translation helpful? Give feedback.
-
@lbbrhzn Thank you for responding. I am afraid the specific current is not the problem since it does work most of the time. When it goes wrong I send the same value trough the wallbox integration and that does work. Leave this work around in there for now and check after a Wallbox SW update. |
Beta Was this translation helpful? Give feedback.
-
@rbb-dev Thank you, I double checked but I am only sending integer numbers. I can reproduce relative easy by using actions in the development menu. I did test with send the maximum current to 10 amps which shows up in the logs as 10.0 At line 56 you see the current offered is 32 A which is again updated to 23 A after 20s by my automation. |
Beta Was this translation helpful? Give feedback.
-
@rbb-dev I know I did it to fast, this was just a way to easy reproduce. In my standard automation I do it every 60s it still happens but far less frequent so more difficult the get the exact logging. The effect however is the same. |
Beta Was this translation helpful? Give feedback.
-
@rbb-dev Thank you, this could for sure be the cause of my problem. If it jumped to 32A it did not help to send the correct value again it had to be a different value. This probably means the charger received the right value but somehow got confused and did not write the correct value to VN-storage. It did detect there was no update if I resend the value and therefore did not write again. Still a bug but with you suggestion above easier to avoid and it avoids my charger gets broken. I will try and let you know the result! |
Beta Was this translation helpful? Give feedback.
-
@rbb-dev This is the output from the trace I fixed the current to 7 for my test it is set to 10 in the ChargePointMaxProfile
|
Beta Was this translation helpful? Give feedback.
-
If I may suggest, move the calculation of final_amps into a separate template sensor in Helpers. This way, the set_charge_rate automation only needs to track that sensor and the connector state, keeping it independent of the calculation. It also allows you to use a slider to adjust the charging rate whenever needed, which keeps the setup nice and clean. |
Beta Was this translation helpful? Give feedback.
-
I have this strange bug for which I do not know if this is my Wallbox OCPP behavior of part of this integration.
I adjust the charge current regularly based of the total power entering my home. The charger can do 32A maximum, my main fuse is 35A so this is important. Initially I was updating the current every minute and ran into the problem it sometimes jumped to 32A current offered while maximum current was still set to a much lower value. Resending the same value did not fix the problem it needed to be something different.
I changed to only send a new value if it was at least 2A different than the old one which reduced the problem a lot but it is still there. I now added the Wallbox integration and are also sending the max charge current trough that control, 15s after I did send it through OCPP. It still happens but the high current is now limited to 20s so the Wallbox integration gets it right, as you can see on the graph below:
I do not like doing through a cloud connected service since it is an additional failuremode for it to not work. Is there a way to see in logging what OCPP is actually sending to the Walbox? If this is right I guess I need to file a bug at Wallbox but I would be surprised I am the only one suffering from it. I am running firmware 6.4.14 on a Wallbox Pulsar Plus
Beta Was this translation helpful? Give feedback.
All reactions