I have read the 6 amp comment somewhere as well, but don’t know if it is accurate. We can set min to 6 and see what happens 
Does the API contain information about which RFID-tag is used to start charging? If so, would it be possible to get that info into Homey? A neighbor uses my Homey with an RFID-tag from time to time, and then I could make some logic that automatically calculates the cost of charging, and send it to him.
The API seem to have a report for it, Consumption Report Guide. Not applicable to use in the Homey app though I think.
I don’t use a tag myself but seems like you should see the data here, Easee.no.
There is an action in the Easee Homey app to update the electricity price in Easee, you could use that to have Easee calculate the correct charging cost.
Hi @Richard_B , thank you for new experimental version, however new version got lock / unlock functionality removed? I was using it to authorize charging on my station and it was working fine - was it intentionally please? Thank you.
You are a good tester 
Poor communication from my side, but yes, it was intentional. After some debate between me, myself, and I - I concluded that lock / unlock should be an infrequent setting to change. Typically one would set access to locked and keep it like that. This can be done using the Easee mobile app or web.
The main reason for removing it was the rate limit exceeded errors. Including the access capability forced me to refresh it by invoking another API frequently, which resulted in rate limit exceeded problems with Easee. Not sure I follow your use case for changing access?
The new test version comes with some other changes under the cover.
When using onoff capability or turn on/off actions the app automatically triggers both start and resume or stop and pause. This is to remove problems when charging is started in one app and then you want to start or stop using Homey. Easee has a mess here and this is the only solution I came up with.
All actions performing changes will now trigger the action, and then invoke another API to check if the command is accepted by the charger or not. This command status API is invoked multiple times and the action will not return until success or fail is returned. This means that actions will take slightly longer time than before to invoke, and they are more likely to throw errors. Errors will be displayed when using the capabilities in the app, as well as thrown when using actions in a flow.
You can easily test it by clicking to turn on the charging when no car is connected - you will get an error.
I deprecated the “Control charger” and “Toggle state” actions, just use the new and improved “Turn on / off” actions. Existing flows will continue to work.
Oh, and I also re-implemented the onoff capability to get rid of the click on the device card in the app will turn charging on or off.
Lots of changes to so great with a good tester 
1 Like
I have charger accessible outside, so it’s locked by default, when we are not home and it gets unlocked automatically when we connect car & we are at home - for me it was working pretty well and we didn’t have to use RFID 
(also I’m not able to get working eg NFC via mobile or phone, only on some specific devices, no idea why). Also I set Homey to perform immediately quick charging test, because sometimes the charging failed due to the cable not connected automatically. So actually now both of this got broken for me
Not sure which rate errors you mean, because during the whole period this has been implemented, I didn’t get a single error. At least to have it as optional functionality, for those it’s working fine, would be great.
Actually when checking now, now I’m getting rate limit even we didn’t use charger for last 24 hours (and already had new version auto installed)
2022-10-28T05:40:14.874Z
Error: get ‘/api/chargers/EH2FSDVC/state’ rate limit exceeded (502)
at invoke (/lib/Easee.js:581:35)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
update even later :
2022-10-28T08:20:39.378Z
Error: get ‘/api/sites/95235/circuits/92659/dynamicCurrent’ rate limit exceeded (502)
at invoke (/lib/Easee.js:581:35)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
… and btw I’m not executing any flows even
2022-10-28T13:48:00.441Z
Error: get ‘/api/chargers/EH2FSDVC/state’ failed, HTTP status code ‘504’
at invoke (/lib/Easee.js:583:35)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
Regarding this. Maybe you could mention this in the description for the card “Change charger state”?
I came across a guy using this frequently, I mentioned not recommended. He asked Easee and first line support said “don’t worry, just keep doing it”. But the next day the employee had a change of heart and said “forget what I said, don’t do it”. So it obviously matters. Hence a little warning in the flow card could be a nice gesture?
2 Likes
Btw. With the new “Toggle on or off”. Are these needed anymore? Or are they more confusing than helpful? They only start or stop charging if user have set to locked if I’m correct?
You even set highlight to True on them
I’m that guy looking for a more appropriate way to halt charging while awaiting best grid pricing 
You could keep it locked and simply “Turn on” the charger when you want to charge, no need to unlock it. You shouldn’t change access frequently since it is use the local FLASH storage inside the charger. From my understanding, all settings such as locked, smart charging, led brightness, max charger current (note not dynamic circuit current), idle current, etc uses flash storage on the charger since it is persisted between reboots.
The error message as such is new for this version, I add the text when we get a 502 error from Easee cloud. I have seen these errors on and off for some time. They seem to have escalated lately, thus my fear of loading the API extra with additional settings that don’t seem necessary.
I have added a statistics feature that will show a counter for all API invocations and all errors since the last restart. Implemented as an app “setting”. Coming soon in a new test version.
Great idea, added short descriptions to most actions
Those are also new, linked with the onoff capability. The same actions you can execute manually you can execute in a flow.
Set access to locked in the Easee mobile app or web, and use turn on/off when you want to start/stop charging. Nothing else is needed.
2 Likes
Thank you, based on testing, seems to be working indeed.
1 Like
New test version 1.5.3 released today, new test release new changes
The slider capability for dynamic circuit current is hidden, and instead, a slider is shown for the dynamic charger current. This is a setting that is for the charger, not the entire circuit which could include multiple chargers. Setting the dynamic charger current to greater than ~7A will start charging, and less than ~7A will stop charging. If access is locked then the charger also needs to be turned on to start charging.
1 Like
Today I discovered scheduling was missing in the Easse-app. It has been working earlier this week. I have tried to remove the schedule and set a schedule again, then I restarted the charger and updated from stable to latest beta. Still no luck in setting a charging schedule. I don’t use Tibber and have not set an operator on the Easee charger. Any suggestions for making this working again?
The action is there for me and works, is it missing for you or do you get an error message? If an error message, what message?
I tried to set a schedule again. Found this error in the settings:
2022-11-13T15:16:59.538Z
Error: Invalid Capability: target_charger_current
at ChargerDevice.getCapabilityOptions (/opt/homey-client/system/manager/ManagerApps/AppProcess/node_modules/homey-apps-sdk-v3/lib/Device.js:1:6366)
at /drivers/charger/device.js:343:26
at processTicksAndRejections (node:internal/process/task_queues:96:5)
Don’t know if it’s related to the problem.
This error happens the first time the app starts and upgrades itself to have that new capability (target_charger_current). Added a check for this error that will come in the next release.
Nothing to do with the schedule though.
Not sure how many users use the “schedule” action, if we could get someone else to ship in? I suspect most people turn on/off charging based on the electricity price and don’t use scheduling.
Now it’s back again. Must have been something on the Easee service since I haven’t done anything except posting here in the forum. 
