Tatsächlich hat das jetzt auch geklappt. Es hatte bei meinen Einträgen dort nur die Adressen zerrissen, keine Ahnung warum. Nach der Korrektur hat es dann auch mit dem Befüllen der Objekte geklappt
Ok, soweit alles in Ordnung, aber jetzt kommt der schwierige Teil. Meine Batterie läuft ja nicht als offizielles Victron-BMS, sondern wird der Venus von dbus-serialbattery als gefaktes com.victronenergy.battery BMS untergeschoben. Das wird zwar ebenfalls als Modbus Unit angezeigt, aber wie finde ich jetzt heraus, welche Adressen/Register womit belegt sind?
Einerseits sind vielleicht ein paar Register analog zu der Liste von Victron belegt, aber ich will natürlich an Sachen rankommen, die nicht Standard sind (Spannungen der einzelnen Zellen z.B.) Gibt es irgendeine Methode, um die Adressen der Register irgendwie abzuscannen?
Holdingregister verwenden … in den anderen sind keine oder nur wenige Register
Und bei iobroker unter allgemeines KEINE geräte-ID eingeben..
sondern bei Holding Register die Slave-ID .. bei Dir wohl die 1
Schon klar, dass ich für SerialBattery die Holdingregister nehme. Die Geräte-ID in den allgemeinen Einstellungen spielt keine Rolle, solange man zusätzlich das Häkchen für mehrere IDs setzt. Dann kannst du beliebig viele verschiedene IDs bei den Registern verwenden.
Wird leider nur mit Fehlermeldungen quittiert. Vermutlich werden die dbus Werte der einzelnen Zellen nicht auf modbus umgesetzt. Schade, aber einen Versuch wert.
hallo,
ich habe bei einem test mit iobroker den abruf einmal ueber node-red von iobrocker gemacht und die daten konvertiert. aber alle daten zu uebertragen kostet da sehr viel rechenzeit.
wenn man sich aber auf die benoetigten daten beschraenkt, sollte das kein problem sein.
selbst fuer den abruf fuer meine datenbank musste ich inzwischen die datenmenge einschraenken, weil ich alle 30s alle daten bekam und die bearbeitung dafuer ca. 25s brauchte. dieses problem konnte ich zwar inzwischen loesen oder besser gesagt, da die daten auch in dieser menge ans vrm gesendet wurden, wurde automatisch ein wert gesetzt, dass die nicht mehr alle 30 s uebertragen werden. leider werden beim verbindungsaufbau aber auch nicht mehr alle daten gesendet ich musste sie explizit anfordern!
Und ehrlich gesagt möchte ich mich nicht auch noch mit nodered auf dem Raspi herumschlagen, nur um die keep-alive Problematik und ständig neu komplett übertragene topics, die nicht mehr als retained markiert werden, zu umgehen. Eine simplere Lösung, die die dbus-Werte direkt selektiv abgreift und per mqtt überträgt, wäre mir wirklich lieb. Prinzipiell ginge das ja über das dbus-mqtt-flashmq-plugin, aber mein Python ist deutlich zu unterentwickelt, um das selber umzusetzen.
Ich hoffe immer noch auf das es-ESS von @dognose
hallo,
du kannst einzelwerte auch einfach mit node-red auf dem gx an den mqtt-server vom iobrocker senden, dann hast du diese problematik nicht.
wenn du den victron-nodes entsprechende namen gibt, kannst du die ueber ein funktion-node und ein mqtt-node an den server schicken. ich mache das, um daten im globalen kontext zu speichern, weil es einfach viel zu aufwendig ist, fuer jeden einzelnen wert ein function-node anzulegen oder alle daten an das function-node zu senden und dann dort zu speichern.
[DEFAULT]
devComment1 = Comments in this file have been ommited for 2 reasons:
devComment2 = 1 The config file is quite huge - without comments it stays somewhat readable.
devComment3 = On https://github.com/realdognose/esESS/blob/main/README.md youll find a full documentation.
devComment4 = 2 Version upgrades will automatically update existing config files - and this process will remove any comment anyway.
[Common]
LogLevel = INFO
NumberOfThreads = 3
ServiceMessageCount = 50
ConfigVersion = 6
VRMPortalID = b827ebf45cff
BatteryCapacityInWh = 7700
BatteryMaxChargeInWh = 1380
DefaultPowerSetPoint = 40
[Mqtt]
Host = 192.168.18.25
User =
Password =
Port = 1883
SslEnabled = false
LocalSslEnabled = false
[Services]
SolarOverheadDistributor = false
TimeToGoCalculator = false
FroniusWattpilot = false
MqttExporter = true
MqttTemperature = false
NoBatToEV = false
Shelly3EMGrid = false
ShellyPMInverter = false
Grid2Bat = false
FroniusSmartmeterJSON = false
MqttPVInverter = false
[FroniusSmartmeterJSON]
VRMInstanceID = 40
CustomName = Fronius Smartmeter (JSON)
PollFrequencyMs = 500
Host = 10.10.20.46
MeterID = 0
[TimeToGoCalculator]
UpdateInterval = 1000
[SolarOverheadDistributor]
VRMInstanceID = 1000
VRMInstanceID_ReservationMonitor = 1001
MinBatteryCharge = (5750/(min(SOC,99)-100)+5750) + 250
UpdateInterval = 45000
[FroniusWattpilot]
VRMInstanceID = 1007
VRMInstanceID_OverheadRequest = 1006
MinPhaseSwitchSeconds = 300
MinOnOffSeconds = 300
OverheadPriority = 35
ResetChargedEnergyCounter = OnDisconnect
Position = 0
Host = 10.10.20.47
Username = admin
Password = password
HibernateMode = true
[MqttExporter:xport_bms_total_current]
Service = com.victronenergy.battery.ttyUSB0
DbusKey = /Dc/0/Current
MqttTopic = Venus/bms/total/strom
[MqttExporter:xport_bms_total_voltage]
Service = com.victronenergy.battery.ttyUSB0
DbusKey = /Dc/0/Voltage
MqttTopic = Venus/bms/total/spannung
Das sind jetzt noch nicht die Topics, die ich eigentlich abfragen will, aber ich dachte das ist besser zum Testen. Ein bisschen unglücklich ist, dass der Service hinten noch den aktuell genutzten USB-Port dranhängt. Bei mir ändert sich der Port aber hin und wieder nach einem Neustart. Keine Ahnung, ob das normal ist, aber ich habe drauf geachtet, dass es übereinstimmt.
Thx, schau mir das mal übers Wochenende an. Sieht auf den ersten Blick stimmig aus, aber Wenn ich genau die config teste, sollte ich den Fehler finden.
Ja, das mit den usb ports ist leider raspberry pi bedingt, liegt iirc daran, dass das pi selbst auf betriebssystemebene die ports nicht in identischer Reihenfolge verbindet.
Lösung / Workaround soweit ich mich erinnere ist nur einen usb port mit switch zu verwenden, wenn man mehrere Geräte braucht. (Nur aus dem Gedächtnis raus, is schon seeehr alt das Problem)
Hab auch überlegt, ob es daran liegt, dass der MQTT-Broker auf meinem ioBroker ohne credentials läuft. Und ich bin mir nicht sicher, ob der Raspi-Broker wirklich ohne SSL läuft. Ich hatte im Kopf, dass man das einstellen kann, aber das hab ich wohl nur geträumt
Habe auch mal mit dem MQTT-Explorer versucht, direkt auf den Venus Broker zu schauen. Das geht auch ohne SSL. Wird dann wohl ausgestellt sein. Ich sehe auch nur den Port 1883 auf der Venus offen. MQTT über SSL würde auf Port 8883 horchen, oder?
Sorry, der letzte Absatz war Quatsch. Beide Ports sind auf “listen”. Verstehe ich zwar nicht aber egal, mein Network Security Profile sagt “unsecured”
auf den vom Raspi? Doch schon, aber ohne keep-alive Krams sehe ich nur die serial unter dem N-Topic und irgendwelchen $Sys-Krams, aber nicht die R und W Topics
Also, hab das Problem gefunden - du hast Venus 3.58? Da ist noch der Paho-Mqtt 1.5 installiert, seit Venus 3.60 haben wir paho 2.x - der braucht einen weiteren Parameter im Konstruktor, hab ich vor paar Wochen bedenkenlos hinzugefügt, aber damit natürlich die 3.58 Kompatibilität “gebrochen”.
Ist nun gefixt und gepusht, kannst also nochmal installieren
Und bezüglich deiner USB-Port Problematik: Hab das angepasst, es sollte nun reichen, wenn du das weglässt - solange es in deinem system nur einen com.victronenergy.battery service gibt, nimmt der Exporter dann einfach jeden “Beliebigen”.
[MqttExporter:xport_bms_total_current]
Service = com.victronenergy.battery
DbusKey = /Dc/0/Current
MqttTopic = Venus/bms/total/strom
[MqttExporter:xport_bms_total_voltage]
Service = com.victronenergy.battery
DbusKey = /Dc/0/Voltage
MqttTopic = Venus/bms/total/spannung
Alternativ - so mach ich das auch - kannst du dir viele Werte aus dem .system service fischen, ohne über den genauen Namen nachzudenken:
z.b.
[MqttExporter:xport_bms_total_voltage]
Service = com.victronenergy.system
DbusKey = /Dc/Battery/Voltage
MqttTopic = Venus/bms/total/spannung
I Ich dachte, ich hätte es uptodate, weil mir der online check nichts besseres anzeigt. Liegt es daran, dass ich das kleine image habe?
