Ui, das sind ja 300Ah Zellen
na da wunderts mich nicht dass du mit 60A nicht viel Temperaturanstieg beobachtest
Ich hab grad mal 2 boxen parallel mit je 8x 105Ah, hab allerdings auch nur ein "balkonkraftwerk" mit ca. 0,9kWp und ca. 400W Wechselrichter Leistung, also in Summe sollte das ganz gut passen (Nulleinspeisung geregelt von FHEM über Ahoy-DTU).
Bezüglich der Firmware ist mir noch eine Kleinigkeit aufgefallen: die Option MIN_PUBLISH_TIME scheint nur für Daten zu greifen, die durch den Parser wandern. Daten wie z.b. der BT connection Status werden nach der konfigurierten Zeit offenbar nicht aktualisiert (sondern nur bei Änderungen).
Bei mir kommt demnächst die Wärmepumpe. Dann der 14a 1+3 Antrag. Da muss ich für Winternächte einen großen Bunker haben. Die 3 Multiplus können mit 6kW laden. Das Niedrigtarif Zeitfenster ist von 0-5 Uhr. Sind also genau 30kWh die ich nachts einlagern und tagsüber mit der WP verballern kann. Die Zoe bzw. demnächst der R5 meiner Frau muss jeden Tag geladen werden. Das passiert im Winter dann im selben Zeitfenster.
Im Sommer scheint uns ja eh die Sonne aus dem Ars… , ist eher langweilig
Korrekt, die beiden flags gelten nur für das was durch den parser läuft. Außer für /device und /config, die kommen eh nur beim Start.
Wenn Du den Gesundheitsstatus haben willst, kannst Du den Status nehmen. Der ist gleichzeitig LWT und wird auf „offline“ gesetzt vom Broker. Oder Du guckst nach dem readcount, ob er noch „flackert“. Der readcount ist nichts was wir zählen, der kommt vom BMS. Die Pakete sind durchnummeriert 0-255 und dann wieder von vorn.
Da ich noch länger mit Gas heize (habe mir gerade einen neuen Brenner angeschafft - frag' nicht, die österreichische Regierung ist/war/wird leider zu blöd zum ) hält sich mein Stromverbrauch derart in Grenzen, dass sich eine große PV-Anlage einfach nicht auszahlt. Ich hatte letztes Jahr (mit 2,5kWh Speicher und 2 PV-Panel) gerade mal 1200kWh Netzbezug.
Tja, unsere Rechten (FPÖ) hätt auch gern wieder 150 auf der Autobahn statt 130 - weil dann ist man ja schneller dort und das Auto läuft weniger lange... was bitte willst als halbwegs vernünftig denkender Mensch gegen solche Argumente vorbringen außer ein resigniertes Kopfschütteln?
Ähm, ich weiß ich bin lästig, aber ich hätte jetzt tatsächlich noch einen Feature Request
Wärs möglich einen virtuellen "Global Alarm State" zu publizieren? Also im Sinne von "wenn der Alarm-uint32 > 0 dann ON"?
Grund: ich will es mir ersparen, jedes einzelne Alarmflag im FHEM abzubilden. Würde da nur auf das globale Flag triggern und die Details dann z.b. per MQTT Explorer "erschnüffeln".
Ich habe noch nicht rausgefunden wofür useralarm1 und 2 stehen. Simuliere doch mal einen Cell UVP und guck ob die Flags sich verändern. Vielleicht sind die genau dafür da. Ansonsten sind die Alarme in eine Bitmaske. Ansonsten publishen wir einfach den uint32_t so wie er ist. Sobald der größer 0 ist, ist irgendwas im Busch.
Edit: 0.1.4 /alarms/alarm_raw
Wenn Du den kleinen debug Parameter auf true setzt kriegst Du die die Bits als String mit published. Ich habe die Alarme noch nie auf Richtigkeit getestet, nur ungeprüft aus der Chinesischen Doku übernommen
Ich meine bei Andy (OffgridGarage) mal gehört zu haben, dass das die 2 benutzerdefinierten relay-Ausgänge darstellt. Auf die kann man ja per App alle möglichen Zustände mappen, und ich würd davon ausgehen, dass der userAlarm "losgeht" wenn das relay geshortet wird.
Ich habe im dualcore Branch mal ein build_flag DUALCORE in der platformio.ini eingebaut. Damit kann man entscheiden, ob Dualcore gebaut werden soll, oder nicht. Eventuell könnte man auch separate build Tasks erstellen. Kann es aber erst morgen auf einem Device testen. Sollte aber lauffähig sein. So wie es aktuell ist, wird default DUALCORE gebaut.
Also bei mir ist gerade "Spitzenleistung" mit ~650W, d.h. pro Akku gut 10A. Bei den Zelltemperaturen macht sich das schon bemerkbar mit ein paar Grad anstieg.
Die Daten kommen jetzt aus meinem ersten Akku mit Daly-BMS und zusätzliche OneWire Temperatursensoren.
Ich habe den Dualcore Branch mittlerweile in den Main gemerged. Einen Fix für den fehlerhaften Balancer Wert habe ich auch committed.
Bin gerade dabei noch 2 berechnete Werte zu erstellen die das BMS leider nicht bereitstellt, mit denen man aber den Wirkungsgrad der Batterie ermitteln kann (zumindest wenn man einen kompletten Zyklus erwischt)
Bin gerade dabei noch 2 berechnete Werte zu erstellen die das BMS leider nicht bereitstellt
Also ganz ehrlich: ich fürcht das ist hoffnungslos ungenau und daher die Arbeit nicht wert
Ohne jetzt genau zu wissen was du machst nehme ich an dass du den Strom verwendest, den dir das BMS liefert --> äusserst ungenau! Also sang ma mal so, es hat schon seinen Grund dass der Victron SmartShunt 100EUR kostet.. der schmarrn den die BMS da zusammenmessen geht auf koa Kuahaut..
Das JK-BMS lässt sich wenigstens kalibrieren, aber ich hab meine Zweifel wie linear die Fehlerkurve ist.
Mein blödes Daly BMS liefert sogar erst einen Stromwert ab 2.5A (!!!), alles darunter bekommt es gar nicht mit
Ja, die Daly sind grauslich. Beim JK ist unter 275mA nix mehr, soweit ich das jetzt beobachten konnte.
Ja klar, ich habe ja nur den Stromwert. Den verwurste ich mit dem deltaT zum letzten Paket. Je nach Vorzeichen zahlt der dann auf den entsprechenden Saldo ein. Ich bin mir nur noch nicht schlüssig, ob man die Werte Mitternacht zurücksetzen oder einfach endlos laufen lassen sollte. Wer die Werte mit NodeRed verwurstet, wird sich eh nur die Differenz zum letzten Wert abgreifen und in die Influx o.ä. schieben. Die Akkumulation übernimmt dann ja ne query
Ja klar, ich habe ja nur den Stromwert. Den verwurste ich mit dem deltaT zum letzten Paket
So in ie Richtung hab ich das in meinen ersten Versuchen auch gemacht, ich habs dann aufgegeben. Neben dem ziemlich ungenauen Stromwert kommt da ja auch noch die Zeitabweichung vom ESP dazu. Also wennst da mit millis() arbeitest ist das auch nochmal ziemlich ungenau, eventuell würds mit NTP+RTC genauer gehen wemmas vielleicht über ein paar Sekunden (oder länger?) mittelt.
Teste die neue Version gerade, ich habe momentan mit DUALCORE laufen, da resettet sich mein ESP nach einiger (zufälliger) Zeit.
Versuche gerade in den Code hier a paar Hilfmittel zum debuggen zu integrieren
EDIT: ich hab den reset über die serielle Konsole protokolliert, siehe Anhang. Trat nach ca. 20min auf (diese mal, hatte ich auch shcon nach deutlich kürzerer uptime) esp32_debug.txt (2,5 KB)
Ich werd mal probieren ob das auch ohne DUALCORE auftritt. Ich vermute fast dass das auch schon früher auftrat und mir nur nicht aufgefallen ist, weil ich den ESP gleich wieder vom PC abgesteckt habe. Fiel mir dieses mal nur auf weil ich das "biding" von WIndows hörte als es beim Reset den COMport kurz verloren hat.
Ich glaube nicht, dass das mit dem DUALCORE in Verbindung steht.
Die BLE Verbindung ist beendet. Der bufferTimeoutCheck() kriegt es zuerst mit, das die Sendung innerhalb eines Paketes gestoppt hat. Der setzt aber nur den Buffer zurück. Kurz darauf scheint im BLE client "onDisconnect" gefeuert zu werden, was den Neustart auslöst (diese Vorgehensweise ist das mittlerweile einzige Überbleibsel aus dem historischen code). Kann ich bei mir nicht reproduzieren. Nach meinere Beobachtung wirft das BMS einen BLE client nach 5h raus. Dafür habe ich das re-send der info Message eingebaut. Wenn das regelmäßig in festen Zeitabständen auftritt, eventuell mal mit dem Wert spielen
Ich kann nur mit millis() arbeiten, da die RTC / time_t keine Millisekunden kann. Die Pakete kommen aber mit unter 1 Sekunde Abstand, deltaT würde also immer 0 sein. Länger abzuwarten würde aber auch keinen Sinn machen, weil das die Werte noch mehr verfälscht. Ich habe es jetzt erstmal auf einfache Art eingebaut. Ein NTP sync wird mittlerweile nach aufbau der Wifi Verbindung gemacht, dIe RTC ist also nach Start "geeicht". Verwenden wollte ich sie eigentlich nur um nach Mitternacht die Werte zu nullen, aber die Idee gefällt mir nicht mehr.
, ist eher langweilig
) hält sich mein Stromverbrauch derart in Grenzen, dass sich eine große PV-Anlage einfach nicht auszahlt. Ich hatte letztes Jahr (mit 2,5kWh Speicher und 2 PV-Panel) gerade mal 1200kWh Netzbezug.
