Hi community,
I just finalized my integration of the go-eCharger as a evcharger into the Victron OS. You can find my project on github with all you need to setup: https://github.com/vikt0rm/dbus-goecharger
This site is now in read-only archive mode. Please move all discussion, and create a new account at the new Victron Community site.
Hi community,
I just finalized my integration of the go-eCharger as a evcharger into the Victron OS. You can find my project on github with all you need to setup: https://github.com/vikt0rm/dbus-goecharger
Great. Super simple and it works!
Controlling the maximum would be great.
Does someone install this directly on Multiplus-II GX? As this device is missing CONFIGPARSER from python. I tried everything to install it, but didn't succeed.
Any help is much appreciated, as so many of those nice add-on are based on the same software, and all require it.
Hi, I've now installed the dbus script and I already can see the go-e in my VRM surface, but it won't update the status. So my status field doesn't say "disconnected" like in the upper picture, instead this field stays completely empty. Can somebody help me with this issue?
The total energy is updated if I have charged my EV and reboot the system, but it seems like all other data is not transmitted.
Thanks,
Rudi
Installed it, and works quite fine :) Thanks for that.
But I have a UI problem:
"EV Ladestation" is my Go-e charger and connected to "Kritische Lasten", but it isn't. It is a normally connected to our house grid. Any solution to solve that?
Hi,
yes the position can be changed.
In the script under /data/dbus-goecharger/dbus-goecharger.py you have to change the line:
self._dbusservice.add_path('/Position', 0)
to the correct one. Its documented in the modbus excel sheet which position is which (Seems to be wrong in the document !!!).
According to the EVChharger Path it is:
0 = AC Input 1
1 = AC Output 1
2= AC Input 2
For me its:
0=AC out 1
1= AC IN 1
I didnt test 2.
Hope this helps,
Dierk
Thanks for the great integration of the go-echarger.
Unfortunately, I cannot see the charger in the overview page on the cerbo gx website but only on the VRM Portal. I already changed the position id in the python script but nothings changes.
Is there anything else I could do to fix it?
Hi,
credits go to @vikt0rm ;-)
No, unfortunately not.
As far as i know also the official charging station is not shown on the cerbo direct but only on the vrm.
The position parameter only controls on which output of the multi the charger is connected (AS In, Ac out 1, Ac out 2).
It does not change any of the functionality.
Kind regards,
Dierk
enable the apis on the go-echarger, set the ip in you ini file, done.
Hi Community,
seems that my Logfile is full of Temperatur foults. Ini file is correct updated and works
Did somebody have the same foults?
KeyError: 'tmp'
2023-08-19 15:19:32,408 root CRITICAL Error at _update
Traceback (most recent call last):
File "/data/dbus-goecharger/dbus-goecharger.py", line 189, in _update
self._dbusservice['/MCU/Temperature'] = int(data['tmp'])
Thanks Chris
Hey Chris,
it seems that you have a newer gen goe charger that uses api version 2.
According to their documentation there is no tmp field anymore:
https://github.com/goecharger/go-eCharger-API-v2/blob/main/apikeys-en.md#api-keys
At least that explains the error.
There is a array of temperature sensors tma. But since they dont document that array and since i also do not have such a newer charger i cant tell which sensors and data is in there.
Maybe you can simple hashmark (#) that line that tries to add the dbus path and live without having the temp of the charger ?
Hope that helps,
Dierk
Hi Dierk,
your right! But ists the gen. of the Go-E, not the Api. I use the API 1
tmp | uint8_t | Temperatur des controller in °C (nur bis GO-E V2) |
tma | array[1] | Temperaturen des Controllers in °C, ersetzt ab V3 tmp |
Im not a pro to fix it.
Maybe the ini file can fix that Problem in the future !?!
The generation is already specified in the .ini from V1 - V3.
However, i have V4. :)
Maybe I´ll test it with the V3 setting. the generation is already specified there from V1 -V3.
Thanks!
Chris
Hey Chris,
sorry, yes, thats what i meant.
That Version of the goe charger uses another "topic" for the temps and afaik it has more than one temp sensor.
It could we solvable via Ini File to use either tmp for v1/2 or tma from v3 on.
But as said: they dont document the structure of the tma array (before it was simple int) and what sensors and values are in there.
Personally I have a v1 revision of the charger and therefore cannot tell whats inside.
Maybe you can give an example dataset via http://<ip of the charger>/status ?
Kind regards,
Dierk
EDIT:
I just looked into the repo and in may there was a change in the code to reflect those hardware versions.
See: https://github.com/vikt0rm/dbus-goecharger/commit/c3e88ca45a610fae6eb6cb33dd4313cf90216f36
Maybe youre using an older version ?
Hi Dierk,
sorry for my late Answer.
I Updatet the newer ini File but the Same Problem like before. Also i changed the the .ini in V3.
File "/data/dbus-goecharger/dbus-goecharger.py", line 189, in _update
self._dbusservice['/MCU/Temperature'] = int(data['tmp'])
The Go e Charger V4 Status:
{"version":"B","tme":"0409231303","rbc":"82","rbt":"892567374","car":"1","amx":"0","amp":"8","err":"0","ast":"1","alw":"0","stp":"0","cbl":"0","pha":"56","fsp":"0","dws":"0","dwo":"180","adi":"1","uby":"0","eto":"351","wst":"3","fwv":"055.7","nrg":[227.23,228.47,230.02,1.55,0,0,0,0,0,0,0,0,0,0,0,0],"sse":"******","wss":"******","wke":"********","wen":"1","cdi":"0","tof":"101","tds":"1","lbr":"255","aho":"0","afi":"6","azo":"222","ama":"16","al1":"6","al2":"8","al3":"9","al4":"10","al5":"16","cid":"255","cch":"16711680","cfi":"65280","lse":"1","ust":"0","wak":"********","r1x":"2","dto":"0","nmo":"0","sch":"AAAAAAAAAAAAAAAA","sdp":"0","eca":"0","ecr":"0","ecd":"0","ec4":"0","ec5":"0","ec6":"0","ec7":"0","ec8":"0","ec9":"0","ec1":"0","rca":"1","rcr":"","rcd":"","rc4":"","rc5":"","rc6":"","rc7":"","rc8":"","rc9":"","rc1":"","rna":"********","rnm":"n/a","rne":"n/a","rn4":"n/a","rn5":"n/a","rn6":"n/a","rn7":"n/a","rn8":"n/a","rn9":"n/a","rn1":"n/a","loe":0,"lot":32,"lom":6,"lop":50,"log":"","lof":0,"loa":0,"lch":0}
Thanks a lot
Chris
Hi Chris,
As a fast fix, just comment the 4 lines in the main script around the temperature readout.
Like
# self._dbusservice['/MCU/Temperature'] = int(data['tma'][0])
The script should start successfully afterwards. For me the temperature is not really important to show up in VRM.
BR
Chris
Hi all :)
I changed personally some stuff in the script to test out how the system behaves in the different MODES.
So where is the control logic in this setup that changes the charging Amperage.
Reason for that is:
I want to be able to set it either on automatic, so the charging and power and start/stop of the charging should do everything without user interaction or to set it to manual and start/stop and change power manually.
After some testing in Automatic:
The logic is clearly NOT in the cerbo but in the charger.
At least for the official one.
So i changed the script to have the mode parameter modifyable (for now: auto and manual) and haveing some node red flows for starting and stopping and changeing the power.
Charging 2 Renault Zoes with this setup with up to 11kW in a 3 phase setup for quite a while now and works like a charm without depleting the battery.
The Zoe is kind of special when it comes to starting stopping and needs quite some attention to prevent the red nose of "i dont wanna charge".
If wanted i can add some more details here but i dont wanna highjack this thread for a different purpose.....
Kind regards,
Dierk
Hi Dierk,
is node red absolutely necessary for surplus charging?
Thanks Chris
you can use also something else to control that.
But the goe does not have any internal logics for changing the charge power.
Also the goe official equipment has a controller that does this.
You could also charge manually with a fixed amperage and change it by yourself.
But for real surplus charging with automatic choosen amperage there has to be some instance that implements that logic.
So sorry, no real answer.
No, it isnt absolutely necessary since there are other software solutions to do it.
Yes, if you want to do it with the venus OS, then you need node red.
Kind regards,
Dierk
After some testing in Automatic: The logic is clearly NOT in the cerbo but in the charger. At least for the official one.
Did you try out DYNAMIC ESS? The issue I see is, that this integration does NOT allow changing the charge mode - it shows them, but you can't select them.
No, I am not using dynamic ess.
And yes, thats due to the driver. It does not implement the mode datapoint.
Hallo,
ich habe eine Heidelberg Wallbox mit WBEC.https://github.com/steff393/wbec
Ich habe um die im Victron Portal zu sehen, den Go-E Charger in Victron implementiert gemäß dieser Anleitung hier => https://community.victronenergy.com/questions/181804/victron-cerbo-via-modbus-mit-einer-heidelberg-wall.html
Das hat auch funktioniert wie man hier sehen kann, allerdings habe ich dasselbe Problem wie der User Naiki,nämlich dass die EV Charging Station in der graphischen Darstellung an den Critical Loads hängt. Es müsste links an Grid/PV Inverter/ACLoads also an AC_in dranhängen.
Es wurde ja erklärt man müsse die Codezeile
self._dbusservice.add_path('/Position', 0) in dbus-goecharger.py ändern aber diese Zeile gibt es im aktuellen Code nicht.
#!/usr/bin/env python # import normal packages import platform import logging import sys import os import sys if sys.version_info.major == 2: import gobject else: from gi.repository import GLib as gobject import sys import time import requests # for http GET import configparser # for config/ini file # our own packages from victron sys.path.insert(1, os.path.join(os.path.dirname(__file__), '/opt/victronenergy/dbus-systemcalc-py/ext/velib_python')) from vedbus import VeDbusService class DbusGoeChargerService: def __init__(self, servicename, paths, productname='go-eCharger', connection='go-eCharger HTTP JSON service'): config = self._getConfig() deviceinstance = int(config['DEFAULT']['Deviceinstance']) hardwareVersion = int(config['DEFAULT']['HardwareVersion']) self._dbusservice = VeDbusService("{}.http_{:02d}".format(servicename, deviceinstance)) self._paths = paths logging.debug("%s /DeviceInstance = %d" % (servicename, deviceinstance)) paths_wo_unit = [ '/Status', # value 'car' 1: charging station ready, no vehicle 2: vehicle loads 3: Waiting for vehicle 4: Charge finished, vehicle still connected '/Mode' ] #get data from go-eCharger data = self._getGoeChargerData() # Create the management objects, as specified in the ccgx dbus-api document self._dbusservice.add_path('/Mgmt/ProcessName', __file__) self._dbusservice.add_path('/Mgmt/ProcessVersion', 'Unkown version, and running on Python ' + platform.python_version()) self._dbusservice.add_path('/Mgmt/Connection', connection) # Create the mandatory objects self._dbusservice.add_path('/DeviceInstance', deviceinstance) self._dbusservice.add_path('/ProductId', 0xFFFF) # self._dbusservice.add_path('/ProductName', productname) self._dbusservice.add_path('/CustomName', productname) if data: self._dbusservice.add_path('/FirmwareVersion', int(data['fwv'].replace('.', ''))) self._dbusservice.add_path('/Serial', data['sse']) self._dbusservice.add_path('/HardwareVersion', hardwareVersion) self._dbusservice.add_path('/Connected', 1) self._dbusservice.add_path('/UpdateIndex', 0) # add paths without units for path in paths_wo_unit: self._dbusservice.add_path(path, None) # add path values to dbus for path, settings in self._paths.items(): self._dbusservice.add_path( path, settings['initial'], gettextcallback=settings['textformat'], writeable=True, onchangecallback=self._handlechangedvalue) # last update self._lastUpdate = 0 # charging time in float self._chargingTime = 0.0 # add _update function 'timer' gobject.timeout_add(250, self._update) # pause 250ms before the next request # add _signOfLife 'timer' to get feedback in log every 5minutes gobject.timeout_add(self._getSignOfLifeInterval()*60*1000, self._signOfLife) def _getConfig(self): config = configparser.ConfigParser() config.read("%s/config.ini" % (os.path.dirname(os.path.realpath(__file__)))) return config def _getSignOfLifeInterval(self): config = self._getConfig() value = config['DEFAULT']['SignOfLifeLog'] if not value: value = 0 return int(value) def _getGoeChargerStatusUrl(self): config = self._getConfig() accessType = config['DEFAULT']['AccessType'] if accessType == 'OnPremise': URL = "http://%s/status" % (config['ONPREMISE']['Host']) else: raise ValueError("AccessType %s is not supported" % (config['DEFAULT']['AccessType'])) return URL def _getGoeChargerMqttPayloadUrl(self, parameter, value): config = self._getConfig() accessType = config['DEFAULT']['AccessType'] if accessType == 'OnPremise': URL = "http://%s/mqtt?payload=%s=%s" % (config['ONPREMISE']['Host'], parameter, value) else: raise ValueError("AccessType %s is not supported" % (config['DEFAULT']['AccessType'])) return URL def _setGoeChargerValue(self, parameter, value): URL = self._getGoeChargerMqttPayloadUrl(parameter, str(value)) request_data = requests.get(url = URL) # check for response if not request_data: raise ConnectionError("No response from go-eCharger - %s" % (URL)) json_data = request_data.json() # check for Json if not json_data: raise ValueError("Converting response to JSON failed") if json_data[parameter] == str(value): return True else: logging.warning("go-eCharger parameter %s not set to %s" % (parameter, str(value))) return False def _getGoeChargerData(self): URL = self._getGoeChargerStatusUrl() try: request_data = requests.get(url = URL, timeout=5) except Exception: return None # check for response if not request_data: raise ConnectionError("No response from go-eCharger - %s" % (URL)) json_data = request_data.json() # check for Json if not json_data: raise ValueError("Converting response to JSON failed") return json_data def _signOfLife(self): logging.info("--- Start: sign of life ---") logging.info("Last _update() call: %s" % (self._lastUpdate)) logging.info("Last '/Ac/Power': %s" % (self._dbusservice['/Ac/Power'])) logging.info("--- End: sign of life ---") return True def _update(self): try: #get data from go-eCharger data = self._getGoeChargerData() if data is not None: #send data to DBus self._dbusservice['/Ac/L1/Power'] = int(data['nrg'][7] * 0.1 * 1000) self._dbusservice['/Ac/L2/Power'] = int(data['nrg'][8] * 0.1 * 1000) self._dbusservice['/Ac/L3/Power'] = int(data['nrg'][9] * 0.1 * 1000) self._dbusservice['/Ac/Power'] = int(data['nrg'][11] * 0.01 * 1000) self._dbusservice['/Ac/Voltage'] = int(data['nrg'][0]) self._dbusservice['/Current'] = max(data['nrg'][4] * 0.1, data['nrg'][5] * 0.1, data['nrg'][6] * 0.1) self._dbusservice['/Ac/Energy/Forward'] = int(float(data['eto']) / 10.0) self._dbusservice['/StartStop'] = int(data['alw']) self._dbusservice['/SetCurrent'] = int(data['amp']) self._dbusservice['/MaxCurrent'] = int(data['ama']) # update chargingTime, increment charge time only on active charging (2), reset when no car connected (1) timeDelta = time.time() - self._lastUpdate if int(data['car']) == 2 and self._lastUpdate > 0: # vehicle loads self._chargingTime += timeDelta elif int(data['car']) == 1: # charging station ready, no vehicle self._chargingTime = 0 self._dbusservice['/ChargingTime'] = int(self._chargingTime) self._dbusservice['/Mode'] = 0 # Manual, no control config = self._getConfig() hardwareVersion = int(config['DEFAULT']['HardwareVersion']) if hardwareVersion == 3: self._dbusservice['/MCU/Temperature'] = int(data['tma'][0]) else: self._dbusservice['/MCU/Temperature'] = int(data['tmp']) # value 'car' 1: charging station ready, no vehicle 2: vehicle loads 3: Waiting for vehicle 4: Charge finished, vehicle still connected status = 0 if int(data['car']) == 1: status = 0 elif int(data['car']) == 2: status = 2 elif int(data['car']) == 3: status = 6 elif int(data['car']) == 4: status = 3 self._dbusservice['/Status'] = status #logging logging.debug("Wallbox Consumption (/Ac/Power): %s" % (self._dbusservice['/Ac/Power'])) logging.debug("Wallbox Forward (/Ac/Energy/Forward): %s" % (self._dbusservice['/Ac/Energy/Forward'])) logging.debug("---") # increment UpdateIndex - to show that new data is available index = self._dbusservice['/UpdateIndex'] + 1 # increment index if index > 255: # maximum value of the index index = 0 # overflow from 255 to 0 self._dbusservice['/UpdateIndex'] = index #update lastupdate vars self._lastUpdate = time.time() else: logging.debug("Wallbox is not available") except Exception as e: logging.critical('Error at %s', '_update', exc_info=e) # return true, otherwise add_timeout will be removed from GObject - see docs http://library.isr.ist.utl.pt/docs/pygtk2reference/gobject-functions.html#function-gobject--timeout-add return True def _handlechangedvalue(self, path, value): logging.info("someone else updated %s to %s" % (path, value)) if path == '/SetCurrent': return self._setGoeChargerValue('amp', value) elif path == '/StartStop': return self._setGoeChargerValue('alw', value) elif path == '/MaxCurrent': return self._setGoeChargerValue('ama', value) else: logging.info("mapping for evcharger path %s does not exist" % (path)) return False def main(): #configure logging logging.basicConfig( format='%(asctime)s,%(msecs)d %(name)s %(levelname)s %(message)s', datefmt='%Y-%m-%d %H:%M:%S', level=logging.INFO, handlers=[ logging.FileHandler("%s/current.log" % (os.path.dirname(os.path.realpath(__file__)))), logging.StreamHandler() ]) try: logging.info("Start") from dbus.mainloop.glib import DBusGMainLoop # Have a mainloop, so we can send/receive asynchronous calls to and from dbus DBusGMainLoop(set_as_default=True) #formatting _kwh = lambda p, v: (str(round(v, 2)) + 'kWh') _a = lambda p, v: (str(round(v, 1)) + 'A') _w = lambda p, v: (str(round(v, 1)) + 'W') _v = lambda p, v: (str(round(v, 1)) + 'V') _degC = lambda p, v: (str(v) + '°C') _s = lambda p, v: (str(v) + 's') #start our main-service pvac_output = DbusGoeChargerService( servicename='com.victronenergy.evcharger', paths={ '/Ac/Power': {'initial': 0, 'textformat': _w}, '/Ac/L1/Power': {'initial': 0, 'textformat': _w}, '/Ac/L2/Power': {'initial': 0, 'textformat': _w}, '/Ac/L3/Power': {'initial': 0, 'textformat': _w}, '/Ac/Energy/Forward': {'initial': 0, 'textformat': _kwh}, '/ChargingTime': {'initial': 0, 'textformat': _s}, '/Ac/Voltage': {'initial': 0, 'textformat': _v}, '/Current': {'initial': 0, 'textformat': _a}, '/SetCurrent': {'initial': 0, 'textformat': _a}, '/MaxCurrent': {'initial': 0, 'textformat': _a}, '/MCU/Temperature': {'initial': 0, 'textformat': _degC}, '/StartStop': {'initial': 0, 'textformat': lambda p, v: (str(v))} } ) logging.info('Connected to dbus, and switching over to gobject.MainLoop() (= event based)') mainloop = gobject.MainLoop() mainloop.run() except Exception as e: logging.critical('Error at %s', 'main', exc_info=e) if __name__ == "__main__": main()
Welche Zeile muss man da ändern ? Oder bin ich komplett auf dem falschen Dampfer ???
VIele Grüße
Ralf
Okay,
scheint also in der offiziellen auf github so nicht drin zu sein.
das kommt ans ende von:
self._dbusservice.add_path('/Position', 1)
Diesen Wert kannst du verändern.
0 = AC Out
1 = AC IN
Hast du einen Quattro, geht auch noch 2 = AC IN 2
Hallo Dierk,
vielen Dank für deine Antwort. Leider funktioniert das bei mir nicht.
Wenn ich diese eine Zeile einfüge dann führt das dazu dass das Device gar nicht mehr in Victron zu sehen ist.Nehme ich die Zeile raus, läuft es wieder wie vorher.
Ich hab mir mal den log angeschaut in /data/dbus-goecharger aber nichts passenendes gefunden bis auf dieses hier :
2023-12-09 15:46:16,755 root CRITICAL Error at _update Traceback (most recent call last): File "/data/dbus-goecharger/dbus-goecharger.py", line 199, in _update self._dbusservice['/MCU/Temperature'] = int(data['tma'][0]) KeyError: 'tma'
Nur das kommt immer egal ob mit oder ohne eingefügte neue Codezeile.
Das gesamte Log wenn du mal reinschauen willst habe ich mal hochgeladen https://we.tl/t-NDfAHrLZRS
Viele Grüße
Ralf
Kurzes Update :
1) die Fehlermeldungen im log mit der Temp sind weg, habe in der Config.ini auf HardwareVersion = 2 umgestellt. Nun wird auch der Charging Status angezeigt. Das scheint also die richtige oder bessere Einstellung für wbec/Heidelberg zu sein
2) das Programm ist nun auch mit der Zusatzzeile self._dbusservice.add_path('/Position', 1) ausführbar, Problem war dass ich noch eine Leerzeile Abstand zum Restcode hatte, die Leerzeile rausgenommen, Programm läuft. Allerdings hat das die Position in der UI nicht geändert, also selbes Problem wie vorher....
Ich hab grade nochmal in die Modbus Register geschaut.
Die kann man bei Victron ja runterladen...
Dort steht drin:
com.victronenergy.evcharger | Position | 3827 | uint16 | 1 | 0 to 65535 | /Position | yes | 0=AC input 1;1=AC output;2=AC input 2 |
Also mein Fehler.
Ich habs genau falschrum im Kopf gehabt.
0 = AC IN 1
1 = AC OUT
2 = AC IN 2
Hallo Dierk,
danke dir aber das habe ich auch schon vorher ausprobiert ....geht nicht.
Also nochmal, hier das entsprechende Codesegement
# Create the mandatory objects self._dbusservice.add_path('/DeviceInstance', deviceinstance) self._dbusservice.add_path('/ProductId', 0xFFFF) # self._dbusservice.add_path('/ProductName', productname) self._dbusservice.add_path('/CustomName', productname) if data: self._dbusservice.add_path('/FirmwareVersion', int(data['fwv'].replace('.', ''))) self._dbusservice.add_path('/Serial', data['sse']) self._dbusservice.add_path('/HardwareVersion', hardwareVersion) self._dbusservice.add_path('/Connected', 1) self._dbusservice.add_path('/UpdateIndex', 0) self._dbusservice.add_path('/Position', 0)
Auch so wird es wie gehabt im Victron Portal angezeigt. Es ist völlig egal, ob ich da
self._dbusservice.add_path('/Position', 0) ODER self._dbusservice.add_path('/Position', 1)
reinschreibe, angezeigt wird es immer als ob es an den kritischen Lasten,also AC_out hängt.
Ich habe auch probiert, per sh.restart in der Telnet/SSH Konsole das Skript neu zu starten und auch den ganzen Cerbo neu zu booten. Bleibt immer gleich falsch angeschlossen in der UI....
Viele Grüße
Ralf
Strange....
Ich kann das grade nicht wirklich nachvollziehen......
Position 0:
Position 1:
Bin grade ein wenig überfragt.
Dauert zwar doch ein paar Sekunden bis das Changed, auch wenn echtzeit daten aktiviert sind, aber wechselt......
Ich habe das Problem mit der Position auch nicht wegbekommen... habe dann irgendwann die Ladestation wieder ausm VRM geschmissen. Vor einigen Tagen habe ich durch Zufall gesehen, dass jemand direkt EVCC als Ladestation eingebunden hat:
https://github.com/SamuelBrucksch/dbus-evcc
Das funktioniert auch mit der Position im VRM super - ich hatte jetzt nicht die Muße mich damit auseinander zu setzen, da mir die Lösung gefällt, aber vielleicht probierst du das mal aus oder findest den Unterschied.
Das will ich auch so haben :=)
Ich hab bei meinem Victron noch die Firmware 2.89 aus Mitte 2022.
Könnte das ein Problem sein ?
Ich bin mir Grade nicht sicher was und wo und wie es da schon gab.
Kann schon sein das es die da erst in Entwicklung gab.
Moin moin,
ich hab leider etwas das Gefühl total falsch zu sein. Hab alles wie in der Anleitung gemacht, jedoch wollte schon auf dem PI der Service sich so nicht installieren lassen. Nach dem ich dann noch die Pfade angepasst habe das es mit "/opt/victronenergy/dbus-systemcalc-py/ext/velib_python" klappte.
Bekomme ich nun leider nur noch Fehlermeldungen.
Dec 27 13:23:04 raspberrypi python3[20550]: File "/opt/victronenergy/dbus-systemcalc-py/ext/velib_python/vedbus.py", line 78, in __init__
Dec 27 13:23:04 raspberrypi python3[20550]: self._dbusname = dbus.service.BusName(servicename, self._dbusconn, do_not_queue=True)
Dec 27 13:23:04 raspberrypi python3[20550]: File "/usr/lib/python3/dist-packages/dbus/service.py", line 131, in __new__
Dec 27 13:23:04 raspberrypi python3[20550]: retval = bus.request_name(name, name_flags)
Dec 27 13:23:04 raspberrypi python3[20550]: File "/usr/lib/python3/dist-packages/dbus/bus.py", line 303, in request_name
Dec 27 13:23:04 raspberrypi python3[20550]: 'su', (name, flags))
Dec 27 13:23:04 raspberrypi python3[20550]: File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in call_blocking
Dec 27 13:23:04 raspberrypi python3[20550]: message, timeout)
Dec 27 13:23:04 raspberrypi python3[20550]: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.74" is not allow
Dec 27 13:23:04 raspberrypi systemd[1]: victron.service: Succeeded.
Hat jemand eine idee was ich falschgemacht hab?
Besten dank für die Arbeit und beste Grüße
Casi
Das Problem ist eher:
Ich selbst hab z.b. einen relativ alten goe aus 2018.
Da war die API noch ein klein wenig anders als bei den moderneren und scheint offentsichtlich auch nicht so zu sein wie in der Spezifikation.
Was genau funktioniert denn nicht ?
Charger generell wird angezeigt und ausgelesen, bleibt also nur der Temperaturfehler ?
API V1 im Charger ist aktiviert ?
Normal sollte ein V4 Charger funktionieren sofern du HardwareVersion auf 3 setzt in der Config und im Charger die V1 API aktivierst über die APP.
Das andere Temperaturflag ist an und für sich eingebaut im Code:
https://github.com/vikt0rm/dbus-goecharger/blob/2cc09daa94f465bd1cf37bb8b993eb63245101f5/dbus-goecharger.py#L198
Moin, mit meinem v4 gibt er den gleichen Fehler. Der v4 gibt unter tma zwei Werte bekannt.
tma
[ 7.5, 3 ]
vllt liegt es daran?
Gruß Christian
API V1 ist an
das ist der Fehler:
2024-01-16 19:44:11,343 root CRITICAL Error at _update
Traceback (most recent call last):
File "/data/dbus-goecharger/dbus-goecharger.py", line 199, in _update
self._dbusservice['/MCU/Temperature'] = int(data['tma'][0])
KeyError: 'tma'
Kann man den Log ausschalten? denn der schreibt die paar Zeilen 4x pro Sekunde
Key Error.
Okay. Scheinbar ist das json was zurück kommt also doch anders.
Kannst du Mal auf die ip vom charger gehen mit
http://<IP>/status gehen und den Output Posten ?
Dann steht halt keine Temperatur drin.
hatte den Status weiter oben schon geteilt.
Gruß
Christian
Scheinbar wurde das komplett entfernt.
Einfach
self._dbusservice['/MCU/Temperature'] = int(data['tma'][0])
durch
self._dbusservice['/MCU/Temperature'] = 0
ersetzen.
scheint so zu funktionieren.
Besten Dank
Gruß Chris
Top :D
Dann steht halt nur im VRM und in der Cerbo bei Temperatur 0°C.
Imho ist das verschmerzbar.
Trotzdem komisch.
Eigentlich ist in der json response der tma key mit zwei werten belegt (wie oben gepostet).
Dann sollte aber
self._dbusservice['/MCU/Temperature'] = int(data['tma'][0])
eigentlich passen.
Ausser, das steht ausserhalb der Struktur.
Solange es nun funktioniert.....
Hello,
does anyone know, if this VRM integration would also work with KEBA P30 X-Series Wallboxes?
i found the Keba-ModusTCP-Manual here:
https://www.keba.com/download/x/dea7ae6b84/kecontactp30modbustcp_pgen.pdf
Really would like to have this also shown in VRM like you did.
thank you!
anyone, any ideas?!
Or let me ask in a different way:
Does this wallbox-integration work with GO-E only, or could also any other Modbus-Wallbox be integrated by this approach?
The go-E has an http rest api that is used for this driver and polls the go-E with those calls directly.
I dont know that Keba wallboxes.
Are they go-E based ?
thank you, but that does not sound good...
I have not found anything about rest API or similar.
I found, that KEBA supports UDP/ModbusTCP/X1/X2/OCPP:
https://www.keba.com/download/x/cfb8f30e78/integratorenliste_de.PDF
with Google i find some thread and infos about Rest-API on KEBA, but not in any KEBA Manuals so far...?!
Theorhetisch gehts, wenn man den Treiber unterschiedlich konfiguriert (IP und Instanznummer) und in zwei unterschiedliche Verzeichnisse unter /data legt.
Ob die Cerbo und das VRM damit umgehen kann ist die Frage.
Vermutlich schon.
Ich denke Victron wird durchaus auch selber Fälle haben wo sie mehrere ihrer eigenen Wallboxen an einer Cerbo haben.
Hallo zusammen,
ich habe letztes Wochenende meine Go-echarger (Hardwareversion 4) angeschlossen, eingrichtet und mit Hilfe des Treibers mit dem Cerbo verbunden.
Die Verbindung scheint auch erstmal zu funktionieren, ich kann die akutelle Ladeleistung sehen, den Ladestrom ebenso und diesen auch ändern. Allerdings kann ich weder über das VRM Portal noch über die Remote Konsle den Modus des Chargers ändern und auch nicht einstellen wo dieser am ESS angeschlossen ist (AC-In oder AC-Out) im VRM Portal erhalte ich eine Fehlermeldung zur Kommunikation, in der Remote Konsole wird die Einstellung nicht übernommen.
Im Treiber an sich habe ich HW Version 3 ausgewählt, weil es 4 dort nicht gibt.
Grüße Jonas
Hello @Dierk Grossfeld ,
I installed the script today and it works fine.The connection to AC-IN is also displayed correctly.
Thank you for your work :-)
I have two questions:
1. is there a way to shrink the view at VRM? I want to show 3 chargers and so i don't want to show so much information and I want changed the name:
Where does the code need to be modified?
2. is there a way also to show the charger at the web-interface/remote-console?
Thank you
Hey,
actually the work has been done by @vikt0rm ;-)
I am also only using it.
Actually it seems to be the same with the victron chargers as well.
Mine has a different name in the cerbo and its nevertheless shown as ev charging station in the vrm.
So i fear its not possible to change the name right now. Maybe Victron can change the vrm to also use the name from the cerbo.
Also the local remote console does not show the charger. i guess its due to space requirements for the gui (if you have ac and dc coupled pv the gui is "full").
Its also possible that this gets changed when the gui-v2 becomes production ready.....
I have now registered all 3 chargers. The VRM dashboard packs all 3 into one display.
That's great, as the display doesn't take up much more space than when displaying just one charger
Looks good, but the missing display in the remote console is a pity. I hope there will be an extension from Victron.
Hello @Dierk Grossfeld
thank you for your support
How did you change the mode from manual to automatic.
If I choose automatic, it jumps out of the menu again and it stays at manual.
What does automatic do?
youre welcome :)
To answer that in short: NOTHING in our case.
Long answer:
The EV Charging Facility in Venus OS is made for the official EV Charging Station from Victron so we are only "backpacking" on it and make use of an already existing facility.
After some research i found that the automatic/manual/time based charging modes are not controlled via the cerbo. It only passes that information on the dbus->modbus to the official charging station that has the logic for the pv surplus charging.
So actually, there is no logic on the cerbo itself to do something automatic.
Since the goe also cant do it by itself, you have to self implement something like this.
I beta changed the goe-integration to support setting that mode and do the logic in node red by "not so simply" changing the amps setting on the goe up and down.
But that more a convenience setting for me to distinguish between:
Automatic = Self ramp up and down
and
Manual = Setting a fixed amperage to charge with and also drain the battery.
hi, sorry I´m a noob but I have a go-e charger and a multiplus with a cerbo Gx, to install in the cerbo GX witch are the procedures? thanks
Hi @Joaquim Pedro ,
Additional resources still need to be added for this topic
Victron Venus OS Open Source intro page
Venus OS GitHub (please do not post to this)
68 People are following this question.
Feature request: Venus OS linkage to weather forecast to enable charging
Lektri.co Charging station integration in Venus OS
OS Releases: Where are they? Supported vs non-supported? Normal vs Large?
Recommended resource to look at for adding to the Venus GUI?
Looking for old Doc "VE - Interfacing with the Phoenix Product Range”.