Hi guys,
I also have the problem with “expected an int” with OH3.3.
Can someone provide a JAR-file with the fix?
I think the binding for OH3.3 does not support it…
Thank you very much!
Hi guys,
I also have the problem with “expected an int” with OH3.3.
Can someone provide a JAR-file with the fix?
I think the binding for OH3.3 does not support it…
Thank you very much!
Hi
I have a go-e gemini flex that I can control with the binding. I am using OH 4.1.1 with the go-e binding 4.1.1 on a raspberry pi.
I can set the current values, phases, read temperature etc. . The only thing that I cannot do is starting the charging. I tried to use forceState but this isn’t working. I can see allowCharge going from off to on when I start the charging via the app. The forceState then is going from 1 to 0. When I switch charging off in the app allowCharging goes to off and forceState goes to 1. In neither state of allowCharging I can set the forceState value via OpenHab (slider).
Does anyone has a solution for this problem?
You need to send a command to Transaction Item, e.g. 0.
ForceState ist used to Stop, continue or “Auto” the Connection
My GO-E Homefix had some temperature-related problems (oxidized Pin of one plug, overheated pin-case smoldered). I send the box to GO-E, they offered to send me a new Gemini for an interesting price.
In https://github.com/openhab/openhab-addons/issues/15075 a problem with decimal instead of integer values is stated. I didn’t have this problem with my old box although it had the newest firmware version.
I had to switch from API version 1.0 to 2.0. This solved the integer / decimal problem.
Hi @Isbjoern, quick question, since I’m getting the java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $
error as well. Can you confirm that you’re using a go-e Gemini flex on OH 4.x? Did you do anything special, so you’re not getting the error above (which appears to be common if I read this thread or this one here). Or are you going via MQTT (which probably works but is more cumbersome)?
I am using a Go-E charger Gemini flex 22 kw Hardware Version 4 with OH 4.1.3.
I upgraded from a Hardware Version 1 which was only capable of using protocol V1. Tried to do so by only changing protocol to V2 at the old thing. Did end in some errors.
So I created a new thing and it workes fine so far. I am able to use my old self created rules. I just remapped the items to the new thing channels.
The only thing that was different for me was that I have to use the force state instead of allow charging switch. Which was different in protocol V1.
If I can support you in testing something plz let me know.
Yes, I can confirm it is a Go-e gemini flex (11kW) on an openhab 4.x .
It works fine.
Very odd.
I just re-installed the binding, same error.
If someone else has an idea, let me know.
Hi all, I had to switch from Home+ 22kW to Gemini flex 22kW the last days and the behaviour I found was as described by @chrode . As the Gemini supports dynamic phase change between 1 and 3 phases, I adapted my excess charging rules to make use of this.
Btw: Although my Home+ was nearly exactly 3 years old already and charged nearly 10.000kWh to our two electric cars, the go-e support was very generous.
What I can tell:
{"alw":true,"acu":8,"cll":{"cableCurrentLimit":32,"currentLimitMax":32,
@Wolfgang1966
As I use the flex as well, could you maybe check a behavior I am seeing in my setup:
if I set the phase to automatically in go-e app, I do not receive a feedback from the interface if there are currently 1 or 3 phases used. In my old setup I built my calculations on that.
Are using the rule example from the binding? I had the feeling that I ended up often in switching back and forth when I try that (I know it depends on the PV Setup as well)
@chrode Phases was set to automatically in my app. Currently, the app shows what the excess charging script has set. So the local API modifies the setting I see in the app.
My script is far more complex than the one shown in the binding description. e.g. after a phase switch it waits for one minute before taking over control again, as the switch itself and the cars take some time to adapt. As I already thought of posting the script in the examples section of the forum, I take your question as trigger to do this now. Give me a couple of minutes, I will then link the article here.
Find the article here: Excess charging Tesla and Zoe with Go-e charger Gemini flex
For some strange reason, I had to activate „local HTTP API v1“ in the Go-e App and set the API Version in OpenHAB to 2 to get it to work. Does this make any sense? If I find some time, I’ll contribute some additions to the Binding documentation, as the documentation is completely useless in that aspect.
For me adding the GoE Gemini worked fine, when first turning on the local HTTP API v2 support, then adding the thing with correct v2 configuration (apiVersion=2). Switched to ONLINE within some seconds. Running on a OH 4.1.1.
I edited the binding‘s manual in the meantime (though not yet shown online), with instructions on what needs to be done (for people who don’t seem to get it (like me )).