Easee binding

@Phuong The error is a result of using an incompatible openhab Version. The binding was compiled against openhab 3.3.0 and for me it works fine with openhab 3.3.0. With openhab 3.2.0 I had the same errors. I guess that using 3.4.0 SNAPSHOT versions should also be ok but I did not try this.

@somy It is just a wrong description, the parameter should be interpreted as seconds. I thought that this is already fixed…

Thank you! I cannot find any trace in log so wasn’t sure how often it pulls. However I noticed I could set interval to 1, in which case does the plugin use the minimal 20 seconds interval or default 1 minute interval?

@AlexF Thanks for your reply.
Yes it’s correct that I’m running on OH 3.2
I also tried to install the 3.4.0 snapshot but got same error
https://openhab.jfrog.io/artifactory/libs-pullrequest-local/org/openhab/addons/bundles/org.openhab.binding.easee/3.4.0-SNAPSHOT/org.openhab.binding.easee-3.4.0-SNAPSHOT.jar

I just updated OH to 3.3 and confirm it works fine now :slight_smile:

@AlexF great work and thanks for sharing, binding works fine for me.
Just one issue, not sure if it is related to my system, but after setting Circuit_Dynamic_Phases to any new value, it takes minutes before Circuit_Phase1,2,3 getting updated with new currents (while the wallbox updates within seconds).
Do you see same behaviour?

Maybe you are using an outdated version of the binding where polling interval is configured in minutes. If you set polling interval to 20 it means it is updated once in 20 minutes.
At least for me I can see values are updated in a few seconds (I have set the interval to 30 seconds).

I’m using OH 3.3 along with your 3.3.0 binding version: org.openhab.binding.easee-3.3.0-SNAPSHOT.jar from 2022-07-08 17:04.
Do I need to update OH & binding to 3.4 to have the polling interval in seconds? as this is how it look today (with polling interval 1), about 15min delay:

2022-08-24 10:24:33.019 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘Easee_Circuit_Dynamic_Phases’ received command 9;9;9
2022-08-24 10:24:33.030 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘Easee_Circuit_Dynamic_Phases’ predicted to become 9;9;9
2022-08-24 10:24:33.035 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘Easee_Circuit_Dynamic_Phases’ changed from 10;10;10 to 9;9;9

2022-08-24 10:39:36.049 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘Easee_Circuit_Phase1’ changed from 10 A to 9 A
2022-08-24 10:39:36.051 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘Easee_Circuit_Phase2’ changed from 10 A to 9 A
2022-08-24 10:39:36.056 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘Easee_Circuit_Phase3’ changed from 10 A to 9 A

This is weird. One minute should be more or less one minute.

The 3.4.0-SNAPSHOT version is built against openhab 3.3.0 and works fine for me.

I would suggest to try the latest binding version. If there are still huge delays you should set the logging to debug this will give a lot more details.

Alright, 3.4.0-SNAPSHOT works much better and polling interval is in seconds now.
Evenso it still takes up to 2 minutes to feedback the current (maybe it’s an issue with my system load or so…). I leave it like this for the moment.

Then just one other points, whats the difference between these channels?

  • state#dynamicCircuitCurrentP1 and
  • dynamic_current#phase1

I use both to see if any of it reacts faster but it’s about same…

This channel is readonly and available for all chargers.

This channel is read-write but only available for type mastercharger. In fact both channels will have the same value (assuming you are on the same circuit).

Hi

I’m about to change my method for pause and resumeing my charging session. I try to use the sendcommand channrl but get an error back when sending pause_charging or resume_charging. I hav a string item holding the link to thr channel anf my rules sets the state to it. In the log output I can see the url endpoint and it looks right. I read above that it was an issue about this function but that it should work frome somewhere in june, is there sny builf number to look for or is there still a issue?

It seems like bindning sends command seversl times or until respns is 200, is that right?

I also missing this “feature” to be able to pause&resume charging.
I see the latest snapshot the sendcommand channel is removed.

This should work in general but the channel was renamed. It is now “commands#genericCommand”. I am using the “commands#startStop” which uses the same API endpoint and it works very well for me.
In case you receive any error please provide some more details otherwise I will not be able to help.

The binding will repeat the API call if the response is not HTTP 200 or HTTP 202. There will be at max 5 retries send.

Binding is now part of openhab and will appear in the next milestone.

3 Likes

Lovely, really good job!
What actions do we have to take to merge to the official release?

Since mid of July I have made only a few changes mainly code style which does not affect functionality at all. A few channels were added that will also ot break anything.
The last breaking change was changing the polling interval from minutes to seconds. If you already have this in place you are ready for the official version. If not you coul update to the latest 3.4.0 SNAPSHOT version (which is in fact built against the 3.3.0 openhab version). This has the same functionality as the official version.

Milestone 2 including easee was just released, see here: Release openHAB 3.4.0 Milestone 2 · openhab/openhab-distro · GitHub

1 Like

@AlexF
for me the channel commands#startStop seems to be not “Writable”.
Even if I try to change it. The status just changed back to the orginal state.

Hey @AlexF,

thank you for the great work!

Currently, i face the following issue:

// easee.items
Number:ElectricCurrent Easee_Charger_Current "Current" (Easee_Wallbox) ["Setpoint"] { channel="easee:charger:home:wallbox:state#dynamicChargerCurrent" [ min="6", max="16" , step="1"] }

// easee.things
Bridge easee:site:home [ username="user", password="secret", siteId="123456", dataPollingInterval=60 ] {
        Thing charger wallbox [ id="EHXXXXXX" ]
}

This configuration leads to a regularly warning in the log:

2022-10-05 09:03:33.890 [WARN ] [nal.model.GenericResponseTransformer] - caught exception while parsing data for channel state#dynamicChargerCurrent (value '16.0'). Exception: For input string: "16.0"

Is there something I can do about it?

can you add timeToLive to the dynamicCurrent as an failsafe option if binding fails, so that if phases is set to 0 amps, it resets to max amps after a period you can set via a number item

url = "https://api.easee.cloud/api/sites/XXXXXX/circuits/XXXXXX/dynamicCurrent"
payload = '{{"phase1":{},"phase2":{},"phase3":{},"timeToLive": 60}}'.format(unicode(phaseOne),unicode(phaseTwo),unicode(phaseThree))

I get the exact same exception. I have value ‘4.0’, but rest is same. There seems to be some issue with the parsing of something, the question is what?