Hi Alex, not sure if you’re aware but looks like they have added another operation mode 7. I have never seen the mode before, usually when I connect to my Tesla it changes from 1 to 2 (waiting for authorisation), I then have an automation that when it’s 2 and I’m at home, it automatically authorise the charge. Need to dig deeper and find what it means by 7 and if there is other implications to the change.
Hi Hendrik, looks like there has been some recent changes to Op_modes, I see mode 7 which was not there before. Also looks like mode 4 is no longer completed. Can you point me where did you find the description of the modes (tried google without luck). Many thanks in advance!
Edit: found it: {
///
/// Offline
///
Offline = 0,
///
/// No car connected.
///
Disconnected = 1,
///
/// Car connected, charger is waiting for load balancer or remote authorization. SuspendedEVSE.
///
AwaitingStart = 2,
///
/// Charging.
///
Charging = 3,
///
/// Car has paused/stopped charging.
///
Completed = 4,
///
/// Error in charger.
///
Error = 5,
///
/// Charger is waiting for car to take energy. SuspendedEV.
///
ReadyToCharge = 6,
///
/// Charger is waiting for authentication.
///
AwaitingAuthentication = 7,
///
/// Charger is deauthenticating.
///
Deauthenticating = 8
}
1 Like
Hi Somy,
thank you very much for bringing that up. I noticed a problem with my auto charging set-up a couple of days ago but didn’t had the time to investigate it yet. Can you please share the link where you found that describtion that I will update it also in my initial post.
Best regards,
Hendrik
regarding link: Take a look here:
“OpMode”
3 Likes
Thanks, this really helps.
I had found many values for opMode, reasonForNoCurrent or ledMode just by testing. This makes life easier.
New status values 7+8 for opMode will help a lot. Before I had to consider resonForNoCurrent in addition to opMode to have a clue what is going on when charger was is mode “2”.
Sorry for late reply but I think you have already figured out 
In my history I think they stopped using value 2 - in my automation I now treat 7 the same way as 2.
Hi all, just want to share some more findings.
- With old behaviour, when authorisation is needed the op_mode is 2 when the cable is connected. And a simple start charge command will authorise and start charging
- With recent change, when authorisation is needed the op_mode is 7 when the cable is connected. However a simple start charge command can no longer authorise charging, so maybe Easee has introduced another command just for authorisation purpose.
According to the documentation it should still work that way:
But I had to implement some checks against opMode and RFNC to implement the convenient start-stop switch channel. That will most likely be broken because it relies on opMode = 2. I will check this.
Hi, thanks for pointing out! I think I need to check my automation then, maybe I missed something there to capture new op_mode.
Hi all,
When charging I can either stop_charging or pause_charging. In the app I can only pause I think.
Is there any difference between them? I’m thinking whether in my rules I should implement pause/resume or just use start/stop for simplicity. Thank you in advance!
It depends. If you have authorization required you need “start” to authenticate/authorize.
I guess the app simplifies this, there is just one button which does the right thing…
I use authentication feature to make sure the car is not charged immediately when plug-in, and I have some rules in OH to schedule charging when EL is cheap.
I use authentication via hardware Token. In openhab I only use pause/unpause on already authenticated sessions. This works fine for me.
Hi Alex, thanks for a great binding as I had said before, using it on a daily basis
This refers to version 4.02 of openHAB.
Some small things:
-
As stated before it seems like the reaction on Easee’s side for commands is very slow, like consistently 2 minutes. It just hit me - is it possible that we don’t send TTL to Easee when sending commands and that is the reason for slow response times…? Just an idea.
https://developer.easee.cloud/docs/amqp-commands -
I read on Easees site that they are changing domain, maybe your binding is using it already, I don’t know. Just for your information:
"Important information for developers and integration partners
We are implementing a series of internal modifications to enhance performance and reliability. As part of this process, we have updated the base API URL from api.easee.cloud to api.easee.com.The api.easee.cloud domain will reach its end of life on October 3rd 2023. The api.easee.com domain is already active and we recommend users to update the URL at the earliest convenience.
Please note that this change primarily affects our internal systems, so the only modification required on your end is to update the URL used to connect to our APIs. The endpoints on this page will soon be updated to mirror the modifications."
-
I think you very gracefully updated the api with a setting of Smart charging - but I don’t think the doc on the binding is updated. Maybe my eyes are missing it though…
https://www.openhab.org/addons/bindings/easee/[https://www.openhab.org/addons/bindings/easee/](https://www.openhab.org/addons/bindings/easee/) -
A very minor detail: in the docs, there are several references to “Charing” - I think it is meant to be Charging.
That’s it for now - have a good one
EDIT 2023-09-19
I wrote to Easee and got response from them regarding the slow response times. This is the answer from them:
We’ve done some testing on this and the change takes place within a few seconds on our test chargers connected to a tester. Do you get the same result on all charge devices? I’m asking if we hold any data in regards to latency on requests that come in via the API to see if we can figure out where the ball is being dropped.
How is the connection on these devices and do other commands start quickly? i.e. start/stop calls?
So according to them everything is fast but that is not really my feeling. And it applies to all commands. I only have one charger so I cannot test it on more. And the charger is connected to a Wifi AP just a few meters away, other stuff connected to the same AP is working very well so I don’t think that is the problem. And the delay is very consistent.
Important: this is not a complaint on the binding, I am super happy with it. This is meant as a possible improvement suggestion (if this is even the case) - nothing else. I am well aware of how the community works (I think…) and I am amazed every time that openHAB works fantastically well since it is a non commercial product and free. Actually, I would say it works much better than many commercial products in general.
Thanks again for all the efforts from everybody involved in making this product so fantastic!
EDIT 2023-09-22: When stopping (for example) Easee through there app, the response i basically immediate which actually corresponds to what Easee say themselves about their api.
I am using a different API which does not have a TTL. In addition TTL refers to a time how long the change should be applied before changing back to the original value. Thus, TTL makes not much sense for most commands.
This is already integrated in 4.0.0 and also backported to 3.4.5.
Well this is weird. The 4.0.3 docs do not contain the update. 4.1.0 partly contains the update. The channel itself is updated but there are a few other fixes in the doc which are missing even there. As you can see PR contains it: https://github.com/openhab/openhab-addons/pull/14866/files
I could not find such spelling errors.
For me the speed via app and binding is quite fast. At least something like starting the charging process takes place within a few seconds. It takes a little bit longer until this is updated in the binding because data is polled via different API calls periodically. Thus it could take up to 1 minute until everything is updated in openhab.
Hi Alex, thanks for coming back to me with answers.
This is for the version of 4.03 of openHAB and the binding (upgraded a day ago).
For me the speed via app and binding is quite fast. At least something like starting the charging process takes place within a few seconds. It takes a little bit longer until this is updated in the binding because data is polled via different API calls periodically. Thus it could take up to 1 minute until everything is updated in openHAB.
I have now done some tests:
- Uninstalled the charger, site and binding, restarted the server/openHAB, reinstalled binding, site and charger and made all the setup. Just for safety.
- Remmed ALL code I have for controlling the charger and reducing/increasing current etc. The ONLY code remaining is the following (bound to some switches):
Starting charging:
Easee_Master_Charger_Dynamic_Currents.sendCommand("6;6;6")
Easee_Master_Charger_StartStop_Charging.sendCommand(ON)
Stopping charging:
Easee_Master_Charger_Dynamic_Currents.sendCommand("0;0;0")
Easee_Master_Charger_StartStop_Charging.sendCommand(OFF)
Increasing power:
Easee_Master_Charger_Dynamic_Currents.sendCommand("12;12;12")
Decreasing the power:
Easee_Master_Charger_Dynamic_Currents.sendCommand("9;9;9")
I was standing next to the charger and the car to see exactly when things happened. I clearly saw when things started/increased or decreased the power/stopped. It never took shorter than 90 seconds and never longer than 120 seconds.
When the car was not charging after the tests, I tried to start it with the Easee app. Not surprisingly, it did not work - the app said “Waiting for smart charging”. Smart charging is not activated and I have no supplier connected to Easee charger (not Tibber and not Easee).
EDIT 2023-09-25: since I did not have Easee as the provider, this would maybe be normal. But when I connected Easee as the provider, I still can’t start charging from the app. But this is not the issue here, this was just for testing. Stopping however works and is instant.
So, I started it via the binding instead, waited about 90-120 seconds and the car started to charge. Then I stopped it via Easee app and that was instant (2-3 seconds).
So these are my findings. I don’t (from what I see in the log) get any errors but I have not done any DEBUG logging yet. If that helps, I will of course do that.
Funny thing: since a couple of days, the Start/Stop parameter always comes on within a few seconds even if I SET it to be OFF. It does not start to charge since the dynamic currents are still 0. But this is a new behavior.
EDIT 2023-09-25: now this behavior is back to normal again. When switched to OFF it stays off. It really feels not so stable at Easees end.
If there is anything I am doing wrong, it would be very appreciated to be pointed in the right direction. I use this binding very often and I have written a lot of rules to take in consideration of the two minutes response time. But two minutes when overloading the fuse is a bit long, that is why I am trying to find the reason for this behavior.
I could not find such spelling errors.
This is where at least I think they are:
I tested it several times. For me it is always between 10 and 30 seconds. As I mentioned commands are put into a queue and therefore there might be up to 3 or 4 polling commands which will be processed before the “change” command is executed. In addition the command queue is only checked once every 5 seconds.
Maybe your hardware is not as fast as mine (I am using a Raspberry Pi 4)? I was using a Pi 3 before and it openhab was quite slow there I had a lot of timing/timeout issues in general on that model.
In general it would be an option to prioritize write commands over regular polling and maybe reduce the check interval.
Thanks for the info. Very strange. The machine I am running openHAB on is quite fast (Windows10 with a lot of memory and SSD). Everything else running in openHAB is very fast.
Then there is nothing we can do about it, I just have to live with the delays.
Thank you very much for your input, much appreciated!
Hi @Samir.E
I can echo the issue. In the past couple of months I have also experienced significant delay when sending commands to EaseeHome API. I have a rule that schedule start_charging command during the night when electricity is cheap, however I have experienced the command simply takes no effect, or take effect after long delay (1 minute or 2). To cater for this I have made some retry logic so it will send start_charging 3 times. Even with retry it’s a hit or miss (80% works 20% misses). This used to work very reliably with minimal delay, and I’m not sure if it’s something to do with the upgrade to OH 4.0. Yesterday the charging failed and on my log I can only see what I output from rules:
2023-10-04 03:00:01.946 [INFO ] [g.openhab.core.model.script.EaseeBox] - The charging has been changed to ON, and the operation mode is AwaitingAuthentication
2023-10-04 03:00:01.952 [INFO ] [org.openhab.core.model.script.Easee ] - Received start charging command
2023-10-04 03:00:01.982 [INFO ] [org.openhab.core.model.script.Easee ] - Attempt 1 to instruct EaseeHome to start charging, sleep for 60 seconds
2023-10-04 03:01:01.998 [INFO ] [org.openhab.core.model.script.Easee ] - Attempt 2 to instruct EaseeHome to start charging, sleep for 60 seconds
2023-10-04 03:02:02.044 [INFO ] [org.openhab.core.model.script.Easee ] - Attempt 3 to instruct EaseeHome to start charging, sleep for 60 seconds
2023-10-04 03:04:02.051 [ERROR] [org.openhab.core.model.script.Easee ] - Start charging failed, EaseeHome OperationMode is AwaitingAuthentication and Tesla Charging is OFF
I think something is wrong somewhere, and if I use EaseeHome app to start_charging it literally takes a couple of seconds. So my question to @AlexF
- I read the command are queued first, is it possible to know what’s the queue size and the delay of commands from the queue?
- Anyway to troubleshoot the issue like this (maybe enable debugging log etc.)?
- Does EaseeHome iOS app use some local protocol so it’s much faster than the cloud version?
Many thanks in advance for any suggestion!
Edit: just want to add it also affect stop_charging command.