Autor Thema: Modul für Victron Batteriemonitor BMV600 / BMV602  (Gelesen 1946 mal)

Offline Bob19

  • New Member
  • *
  • Beiträge: 8
Antw:Modul für Victron Batteriemonitor BMV600 / BMV602
« Antwort #15 am: 07 Juli 2017, 22:26:49 »
Push

Keiner eine Lösung?
Ober bin ich hier falsch?

Offline Askie

  • New Member
  • *
  • Beiträge: 8
Antw:Modul für Victron Batteriemonitor BMV600 / BMV602
« Antwort #16 am: 07 Juli 2017, 23:21:15 »
Moin Bob19,
Wenn dein blauzahn dongel als serielle Schnittstelle fungiert sollte das recht einfach gehen... falls nicht wird das Modul nicht so ohne weiteres funktionieren - d.h. es müsste auf das blauzahn Protokoll umgeschrieben werden. Allerdings weiß ich nicht wie das arbeitet, von daher ist eine Antwort relativ schwierig...
Gruß Askie

Offline Bob19

  • New Member
  • *
  • Beiträge: 8
Antw:Modul für Victron Batteriemonitor BMV600 / BMV602
« Antwort #17 am: 22 Juli 2017, 14:46:30 »
@ Askie

Schade das es da keine Lösung gibt, aber danke für die Hilfe

Offline duke-f

  • Full Member
  • ***
  • Beiträge: 411
Antw:Modul für Victron Batteriemonitor BMV600 / BMV602
« Antwort #18 am: 11 Oktober 2017, 08:28:03 »
Ich danke den Autoren dieses Modul. Habe das ganze auch in einer etwas angepassten Variante orientiert an den Beiträgen von @ducati748sp für einen mppt 75/15 jetzt im Einsatz. Das Modul läuft dabei auf einem besonderen FHEM auf einem Spar-Debian auf meinem NAS und ist per FHEM2FHEM an das Haupt-System auf dem Cubie eingebunden.

Für die, die es interessiert:
Das hatte folgenden Grund. Mein mppt 75/15 ist außerhalb des Hauses im Gartenhaus. Daher kann er nicht direkt an einem vorhandenen Kleinstrechner mit FHEM eingebunden werden. Abhilfe schuf hier ein seh myUTN-55, der den USB-Anschluss des mppt 75/15 per WLAN weiterleiten kann. Klar ist das nicht die kostengünstigste Lösung, aber davon soll hier nicht die Rede sein. Vorteil des myUTN-55: Es gibt Linux-Treiber. Leider aber nicht für die ARM-Prozessoren der Raspberries und des Cubie - zumindest habe ich es nicht geschafft, sie dort zum Laufen zu bringen. Daher dann die Lösung des Spar-Debian als VM auf dem NAS. Das FHEM dort bedient nun ausschließlich den mppt 75/15. Ein Vorteil dieses vom Hauptsystem abgetrennten Systems ist, dass das Hauptsystem weniger belastet wird. Der mppt 57/15 liefert nämlich Daten im Abstand weniger Sekunden und die Lösung in der hier vorliegenden Variante schreibt erst mal sehr viel in die Log-Dateien. Das könnte man zwar besser organisieren, denke ich, aber gerade in der Anfangsphase will ich doch diese Information erst mal möglichst komplett haben. Daher wird jetzt auf dem mppt-FHEM alle 5 Minuten eine gewisse Auswertung der Unmenge an Daten vorgenommen, ohne das Hauptsystem zu belasten. Hier bin ich aber noch nicht fertig, bisher wird erst mal der Ladestrom über 5 Minuten gemittelt. Gleiches sollte noch mit dem Ladestrom vorgenommen, für andere Größen ist vielleicht eher der Spitzenwert innerhalb 5 Minten interessant. Für den Ladezustand sollte hingegen auf jeden Fall ein eventuell auftretender Fehler gemeldet werden. Und alle 5 Minuten werden dann ausgewählte Daten in einen Dummy geschrieben, der dann im Hauptsystem über FHEM2FHEM landet und dort weiter integriert wird in form eines Dummies mit den Readings:

Ladestrom_5Min
-0.19
2017-10-11 08:18:41
Ladezustand
0
2017-10-11 08:18:41
Laststrom
0.10
2017-10-11 08:18:41
Max_Tagesleistung
0.00
2017-10-11 08:18:41
Panelleistung
0.00
2017-10-11 08:18:41
Panelspannung
13.00
2017-10-11 08:18:41
Power
-2.48
2017-10-11 08:18:41
Spannung_B
13.05
2017-10-11 08:18:41
Tagesertrag
0.00
2017-10-11 08:18:41
Tagesverbrauch
-28.4
2017-10-11 08:18:41
state
Spannung_B: 13.05 Ladestrom_5Min: -0.187966666666682 Tagesertrag: 0.00 Tagesverbrauch: -28.3950879722659 Laststrom: 0.10 Max._Tagesleistung: 0.00 Ladezustand: 0 Panelspannung: 13.00 Paneleistung: 0.00 Power: -2.48
Cubietruck, 3 Raspberry Pis,
CUL868, RFXtrx433, CUL433, SCC868, HM-USB,
IRTrans, EZcontrol XS1, IguanaWorks USB IR Transceiver
AVR-NET-IO, Fritz!Box, Samsung TV+BD, LMS, Squeezelite