Go-E Charger Wallbox Binding

Rangarid · June 16, 2020, 11:13am

Here is a sample of how well PV charging works:

Orange is max power of goecharger, blue is total power of the house, green is pv power, red is power from grid.

Works quite well, however sometimes when power changes very fast, the power adjustments are a bit chaotic if the power changes too fast. that has two reasons:

frequency of pv power is only every 5s
car adoptions to max wallbox power have some latency

Overall i’m quite happy as the grid load is minimal, but you can also set more buffer so grid loads are kept to a minimum.

Here is my rule:

rule "PV Charging"
when 
    Item Grid_Power changed // value from PV system
then
    // maximum allowed power of wallbox
    val currentMaxPower3P = (GoEChargerMaxCurrent.state as Number) * 230 * (GoEChargerPhases.state as Number)
    // available power that is currently fed to grid
    var availablePower3P = ((Grid_Power.state as Number) * -1)

    // buffer to reduce grid load in case power changes fast
    var buffer = 200  

    var newPower = ((currentMaxPower3P + availablePower3P)-buffer)
    GoEChargerMaxCurrent.sendCommand(newPower/230)
end

stephen_winnall · August 3, 2020, 10:43pm

That’s pretty cool. I wanted to do something similar, but then my provider offered to install a nifty product called “Solar Manager” (https://www.solarmanager.ch) which does the same, so I didn’t bother.

But I use MQTT and OpenHAB to get messages on my phone when the charging has finished.

camillo · August 8, 2020, 8:35am

Hi Samuel, due to your binding I decided to buy a go-e charger in order to do the same (control the charging automatically based on the solar power and the house batery status). Everithing worked well … for less than 12 hours. Then I lost the connection to the charger. No way to reconnect. Actually the charger lost connection to everything.
Did anyone else encounter such problems?
Menawhile I switched to mosquitto and mqtt. It’s not as easy and comfortable as your binding (BTW: ty for the job!) but works well (meanwhile for almost a week) for me.

Rangarid · August 21, 2020, 7:20am

Hi @camillo,
if mqtt works, the binding should also work. I once had a problem, where openhab for some reason could not execute http calls anymore but with a restart everything worked again and since then i did not experience that problem again. Goecharger has problems with wifi sometimes, the reception is not very strong, so maybe mqtt works better on a bad connection? Try to improve wifi at your chargers location and try it again please.

Mads_Bloch · November 17, 2020, 9:42am

I trying to decide if I should buy the Go-E charger, there many other options out there, but I want one that able to “talk” to openhab.

Is this charger a good choice and are the binding stable ?

Thanks Mads

andreasdk · November 17, 2020, 11:25am

I use the go-eCharger now for 2 years without the binding. I think it is easier with binding. So even the binding should be unstable there are other options to communicate with the go-eCharger as part of openHAB.
If you understand German, you could take a look here: https://www.goingelectric.de/forum/viewtopic.php?f=34&t=24234&start=1430#p771777

Rangarid · November 20, 2020, 7:33pm

The binding works very well and it is easy to setup. I have a PV charging rule that works perfectly for charging with solar energy alone. So if you have openhab already setup the goecharger definitely is a good choice.

Goe is a bit picky about wifi though. Reception is not very good so if your router is too far away you might need a repeater.

Mads_Bloch · November 21, 2020, 6:26am

Nice i have also been looking at KEBA ev chargers but its only the more expensive models that have the necessary spec that enables them to talk to openhab.

I will buy a Go-echarger

Thanks

chilobo · January 4, 2021, 8:09pm

Hello!

I am currently waiting for my GO-E homefix to be installed. We have ~6 kWp solar panels, a Fronius Symo 6.0-3-M and a Powerwall 2. My goal is to charge our EVs (e-up 16 kWh and Ioniq 28 kWh). A Raspi 4 will be arriving soon.

Years (20) ago I had lots of experience programming Turbo-Pascal and Delphi and configuring early Linux-based Servers for schools.

I am willing to invest some time (because I loved programming). So now I have not decided if it would be easier participating in your project or in OpenWB.

So what do you recommend, Openhab or OpenWB?

What do I have to read and how can I get aquainted with Openhab - any recommendation?

Rangarid · January 5, 2021, 1:22pm

Openhab is recommended if you want to put different smart home systems under one roof. If you just need the PV charge logic, I guess openWB suits better.

Bernd2310 · January 11, 2021, 5:53am

Hello Christian,
during the last weeks I have setup my eGo Charger in Openhab and made this comparison, too. Beyond Samuels remark, for me it was easier to setup options for charging, that anyone in the houshold can manage. My example considers

Option1: PV-Charing only.
Option2: As I have HT/NT power and sometimes the demand to charge fast.
Option3: Utilization of any available PV power.

Hope this helps… I am still improving my logic… but it already works reasonabily.

chilobo · January 15, 2021, 8:11pm

Thanks for the encouragement. I started with playing around with my receiver and am learning how to manage openhabian, making progress step by step.

FeliciaRS · January 31, 2021, 11:35pm

Hello,

thank you very much for the binding. Is there a possibility to control the cable lock via the binding as well.
Usually the cable is locked permanently. Only when the car drives a long distance is the cable unlocked and packed in the trunk. Controlling that directly via Openhab would be a good option.

matzeZE · February 1, 2021, 7:59am

This is how I solved this issue:

Sitemap:
Switch item=GoEUnlockState label=“Lock State” mappings=[0=“Normal”, 1=“Charging”, 2=“Always”]

Rule:
val UnlockState_url = “http://192.168.178.xx/mqtt?payload=ust=”

rule “GoELock”
when
Item GoEUnlockState changed
then
var url = UnlockState_url + “” + GoEUnlockState.state
sendHttpGetRequest(url)
end

FeliciaRS · February 1, 2021, 11:18am

Thanks that works fine for me.

Martin_Fischer · February 24, 2021, 8:55am

hello,
has anybody a working and flexible rule which works for cars charging with 1 phase, 2 phases and 3 phases?

chilobo · March 20, 2021, 5:21pm

Charging our Ioniq28 is working, I had to use the output of the powerwall binding because just using the grid power value is not meaningful if the Powerwall battery is still charging. Well, it works!
So when solar power due to a cloud goes down charging of the Ioniq is stopped and resumed when solar power is back again.

A week ago I got my VW e-up back from my daugther.
In the above mentioned case the e-up does not start charging again. It obviously goes sleeping an doesn’ awake when power is back. It doesn’t matter if I use GoeCharger_AllowCharging.sendCommand(OFF) / GoeCharger_AllowCharging.sendCommand(ON)
or just drop the current below 6 A and raise it to 6 A or above - e-up is not starting to charge afterwards.

Any suggestions?

chilobo · April 4, 2021, 5:35pm

I guess I need help!

Sometimes my Ioniq doesn’t start to charge when PV power is going up again. I am using the following code:

// Regelung über aktuell genutzte Leistung 

// Verfügbare Leistung erfragen, 

var int availablePower = ((GoeCharger_PowerL1.state as Number) - (PW_Battery.state as Number) - (PW_Grid.state as Number)).intValue  + 100 

// Berechne Strom  

var int newCurrent = (availablePower / 230).intValue

logInfo("GOE", "GOE Modus " +GOE_Modus.state)
  
try {
  if (GOE_Modus.state==0) { newCurrent = 0}
  if (GOE_Modus.state==1) { newCurrent = 16}
  if (GOE_Modus.state==2) 
    // Ioniq
    { if (newCurrent < 8) 
      { logInfo("GOE", "Ioniq Abgeschaltet wegen " +newCurrent + " A")
        newCurrent = 0
      }
    }
  if (GOE_Modus.state==3)
    // e-up  
    { if (newCurrent < 6) {
        newCurrent = 6
        logInfo("GOE", "Verfügbare Leistung, aber Rest aus PW " +availablePower+ " W")
        }
    }
  }
 finally {logInfo("GOE", "Verfügbare Leistung " +availablePower+ " W")}
        
if (newCurrent > 16   ) {
   newCurrent = 16 
   }
   
// Strom an Go-E übertragen
 
if (newCurrent > 5) {
    GoeCharger_MaximumCurrent.sendCommand(newCurrent)
    logInfo("GOE", "Neuer Strom " +newCurrent + " A_____")
    if (GoeCharger_AllowCharging.state == OFF) {
         // WB is still switched off, switch to ON
          GoeCharger_AllowCharging.sendCommand(ON)
          logInfo("GOE", "Angeschaltet, Strom " +newCurrent + " A_____")

        }
    }
   else {
    if (GoeCharger_AllowCharging.state == ON) {
         // WB is still switched on, switch to OFF
      GoeCharger_AllowCharging.sendCommand(OFF)
      logInfo("GOE", "ABgeschaltet, Strom " +newCurrent + " A_____")
      }
   }

The problem seems to occur when I find occurences of the Wallbox switching OFF and ON without the code changing it.
Excerpt of events.log:

2021-04-04 15:45:57.861 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'GoeCharger_MaximumCurrent' received command 9
2021-04-04 15:45:57.903 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'GoeCharger_MaximumCurrent' predicted to become 9
2021-04-04 15:45:57.906 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'GoeCharger_AllowCharging' received command ON
2021-04-04 15:45:57.942 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'GoeCharger_AllowCharging' predicted to become ON
2021-04-04 15:45:57.957 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'GoeCharger_MaximumCurrent' changed from 8 A to 9
2021-04-04 15:45:57.960 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'GoeCharger_AllowCharging' changed from OFF to ON
2021-04-04 15:45:58.153 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'GoeCharger_MaximumCurrent' changed from 9 to 9 A
2021-04-04 15:45:58.193 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'GoeCharger_AllowCharging' changed from ON to OFF
2021-04-04 15:45:58.335 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'GoeCharger_AllowCharging' changed from OFF to ON

It seems that the GO-E switches from ON to OFF and back from OFF to ON when MaximumCurrent is changed.

robbelt · May 7, 2021, 7:58am

Hi! I like this bidning very much and my PV-depending charging is working well. But I often get these communication errors:

2021-05-07 09:51:27.532 [hingStatusInfoChangedEvent] - 'goecharger:goe:5cbf77fe' changed from OFFLINE (COMMUNICATION_ERROR): Total timeout 5000 ms elapsed to OFFLINE (COMMUNICATION_ERROR): java.net.NoRouteToHostException: No route to host

2021-05-07 09:55:36.361 [hingStatusInfoChangedEvent] - 'goecharger:goe:45afb647' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Total timeout 5000 ms elapsed

2021-05-07 09:55:36.611 [hingStatusInfoChangedEvent] - 'goecharger:goe:45afb647' changed from OFFLINE (COMMUNICATION_ERROR): Total timeout 5000 ms elapsed to ONLINE

2021-05-07 09:55:39.778 [hingStatusInfoChangedEvent] - 'goecharger:goe:5cbf77fe' changed from OFFLINE (COMMUNICATION_ERROR): java.net.NoRouteToHostException: No route to host to OFFLINE (COMMUNICATION_ERROR): Total timeout 5000 ms elapsed

2021-05-07 09:55:47.778 [hingStatusInfoChangedEvent] - 'goecharger:goe:5cbf77fe' changed from OFFLINE (COMMUNICATION_ERROR): Total timeout 5000 ms elapsed to OFFLINE (COMMUNICATION_ERROR): java.net.NoRouteToHostException: No route to host

I have two go-echargers installed and get these errors with both. Ping answers reliably. Does anybody also experience this? Any ideas for a solution or troubleshooting?

Bernd2310 · May 7, 2021, 8:44am

Hi, have the same issue… and only a workaround. So a “real” solution would help. I have implemented into my rule this:

//goECharger OFFLINE = AUSSTEIGEN
if (GoEChargerPowerL1.state == UNDEF) {
    logInfo("eGo", "Exit SET CHARGING weil Power1 UNDEF und eGo Charger offline") 
    return
}