What happened?

openDTU hangs when Solar Passthrough is enabled with the empty at Night option set. I looked through the code but cannot make much sense out of it.

I think that the code stays in the while(true) loop forever without reaching a return statement. I marked the conditions below that trigger this in my mind (without debugging further)

Now my main reason for this ticket is that I don't understand what the strategies "Empty at Night" and "Empty when Full" are supposed to do. This is also not really clear to me from looking at the code. From my perspective it would make sense to have a strategy that performs solar power passthrough independent of the current battery state and another strategy that does this only when the battery is fully charged.

Can somebody enlighten me?

           case STATE_CONSUME_SOLAR_POWER_ONLY: {
                int32_t newPowerLimit = calcPowerLimit(inverter, true);
                if (isStopThresholdReached(inverter)) {
                    _plState = STATE_OFF;
                    break;
                }
always true-> if (isStartThresholdReached(inverter)) {
                    _plState = STATE_NORMAL_OPERATION;
                    break;
                }
                if (!canUseDirectSolarPower()) {
                    if (config.PowerLimiter_BatteryDrainStategy == EMPTY_AT_NIGHT)
                        _plState = STATE_NORMAL_OPERATION;
                    else
                        _plState = STATE_OFF;
                    break;
                }
            case STATE_NORMAL_OPERATION: {
                int32_t newPowerLimit = calcPowerLimit(inverter, false);
                if (isStopThresholdReached(inverter)) {
                    _plState = STATE_OFF;
                    break;
                }
always true->if (canUseDirectSolarPower() && (config.PowerLimiter_BatteryDrainStategy == EMPTY_AT_NIGHT)) {
                    _plState = STATE_CONSUME_SOLAR_POWER_ONLY;
                    break;
                }

To Reproduce Bug

Full battery, solar passthrough enabled with empty at night

Expected Behavior

it should not hang

Install Method

Self-Compiled

What git-hash/version of OpenDTU?

6f2901b

Relevant log/trace output

No response

Anything else?

No response

I know, it's not the right place for a question like that. But can you explain how to connect to a victron system with your software extension? I want to integrate the solar values of the hoymiles inverters into the vrm portal. Is this possible over the air without a cable connection? Do i need further wiring or dongles for the microcontroller?

What happened?

Got Lint error in but don't know what's wrong here?

To Reproduce Bug

See actions in GitHub

Expected Behavior

no lint error

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

4eec055

Relevant log/trace output

/home/runner/work/OpenDTU-OnBattery/OpenDTU-OnBattery/webapp/src/views/PowerMeterAdminView.vue
[8](https://github.com/helgeerbe/OpenDTU-OnBattery/actions/runs/4627787519/jobs/8186115950#step:5:9)
  226:34  error  Parsing error: Expression expected

Anything else?

No response

What happened?

I've place the DTU next to the inverter to test if there is a stable wifi connection.

MQTT is enabled and delivers data

But the Web GUi is not opening

To Reproduce Bug

I didn't had any issues testing it on the desk so it might be related to the low wifi signal.
But my Ahoy DTU is working om the same dictance perfect

Expected Behavior

GUI available

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

newest build from yeterday

Relevant log/trace output

No response

Anything else?

Looks like the AP is turning on and off, my phone shows the AP everys minute or so.

No NRF module connected so far
no inverter configured so far

OK, ich glaube zu verstehen, warum der ESP abstürzt, wenn er die Nachrichten für den Huawei empfängt.

Ich vermute du hast für MQTT das Retain flag gesetzt? OpenDTU subscribt sich auf das topic und anscheinend legt der IO Broker das an. Da das retain flag gesetzt ist, sendet er komischerweise 0 auf dem topic (das macht anscheinend Mosquitto nicht???).

Da jetzt eine Nachricht empfangen wird, versucht der ESP den Wert auf eine nicht initialisierte Struktur zu setzen.

Lösung sollte relativ einfach sein. Alle Nachrichten ignorieren, wenn die Komponente disabled ist.

Originally posted by @helgeerbe in #183 (reply in thread)

Is your feature request related to a problem? Please describe.

No response

Describe the solution you'd like

Hi, it would make sense to integrate VeDirect to main OpenDTU repository.
But not every one needs VeDirect. Idee: Disable/Don't show any Victron related UI elements if VE Support is not enabled in the settings.

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

I notice that sometimes, the inverter will get "stuck" producing with efficiency of only 50% percent (normal is somewhere between 94% and 95% percent).
The only way to get the inverter out of this loop is by re-starting it.

I can not reproduce the effect. It usually happens sometime during the day when:

1. Using two 25V batteries connected at 50V
2. the batteries are "drained out" from the previous night and did not have time to recharge itself.
3. The VICTRON is charging the batteries thus delivering high voltage (which the OpenDTU without CANbus interprets as "battery fully charged").
4. There is high electricity consumption in the house thus, OpenDTU gives the command to the inverter to start producing electricity at max.
5. The electricity provided my VICTRON is lower than the electricity the inverter is trying to deliver thus the (empty) batteries is further drained... even below the DC Voltage - Stop threshold.
6. The BMS of the batteries stops them (to protect them), usually this means one battery will stop earlier than the other thus voltage drops suddenly from 48V down to 24V
7. OpenDTU stops the inverter (DC Voltage - Stop threshold reached)
8. With Inverter stopped, VICTRON continues to produce, thus the situation goes back to point 3 and the vicious "loop" starts again.

Describe the solution you'd like

Proposed solution:

1. Add the option to "restart the inverted" at a selected time, once per day. This will get the inverter out of the loop if it has happened.

2. Have an option to monitor the efficiency % of the inverter and if it identifies that over a longer period the inverter is:

   • producing electricity (i.e. inverter is not idle)
   • with efficiency below 70%
     restart the inverter

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

There are a couple of devices (power meter, battery charger, bus) which requires serial interfaces. Each device has to be configured at compile time, or separately via the device manger (pin mapping).

I would like to make ist a little bit more manageable and easier to configure.

Describe the solution you'd like

I propose to create an abstract serial device, which contains all serial interface pins.

• Pin setting is loaded via device map.
• It should only be possible to select two HW (1,2) serial interfaces at max.
• maximum number of interfaces should be defined at compile time

So at the device manger you will get a list of pins for the serial interfaces.

To configure the serial devices you have to choose the interface by id/label to get the pins to initialize the device.

Describe alternatives you've considered

No response

Additional context

No response

What happened?

If Hoymiles is connected to PV, there is no voltage in the night and Hoymiles reboots each night: yield today will be reseted
With the battery connected the Hoymiles does'n reboot at all, so the yield today couns more than "today":

To Reproduce Bug

Connect Hoymiles to the battery (0 Watt Limit = StandBy is enogh) and wait over the night

Expected Behavior

yield is reseted every night (if on battery = at 0:00)

Install Method

Self-Compiled

What git-hash/version of OpenDTU?

b00ca02

Relevant log/trace output

No response

Anything else?

No response

What happened?

Der Inverter (HM-600) und openDTU (onBattery) läuft zunächst einwandfrei und wie konfiguriert.
Nachts (0:00) wird der Inverter über die DTU neu gestartet, was auch im Log vermerkt ist.
Danach treten zeitlich versetzt lt.. Log Fehler (DTU command failed / Error 2) auf (15x)
Am nächsten Morgen, genügend Ladung ist bereits im Akku, startet, trotz entsprechender Anforderung (480W), der Inverter nicht.

Um wieder normalen Betrieb zu erreichen muss sowohl der Inverter, wie auch openDTU, über die Oberfläche neu gestartet werden.
Der Neustart nur einer der beiden Komponente löst das Problem nicht.

To Reproduce Bug

Tritt nicht jeden Tag auf, daher eher schlecht zu reproduzieren.

Expected Behavior

event eine Art Watchdog implementieren?

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

fd58ad2

Relevant log/trace output

No response

Anything else?

No response

Is your feature request related to a problem? Please describe.

since yesterday Victron was off because of no solar and empty battery (bms turned off)
whole night, MQTT had (retained) H20=1,2 kWh ("kWh today" from yesterday).
Since this morging around 6:00 Victron is up and running an produced 20+ Wh
Telegraf saved this from MQTT to InfluxDB and Grafana shows 1,2 kWh today (max()).
last() has some troubles on last days that's why I'm using max().
Nevertheless, 1.2 kWh should be reseted an 0:00 if Victron is not available, so that values does make sense again.

Describe the solution you'd like

H20 (or better all) should be reseted an 0:00 if Victron is not avaliable (e.g. last seen more then 10(?) minutes),
so that values does make sense again.
0 Values an 0:00 make more sense than "old" values from the day before.

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

When you connected a 24V battery to Hoymiles inverter, you can easily exceed the Ampere limit of 10.5A / 11.5 / 12.25 that is different for Hoymiles models. When you exceed the limit you would run the inverter outside of the specifications of the manufacturer.

Exceeding the limit can cause overheating of the inverter and let the inverter report invalid values because they are not measured correctly anymore. --> Fire risk 🔥

Also See discussion in: #156

Update: This issue maybe applies to HM-1000, HM-1200, HM-1500 only, because those models have 4 DC inputs, but only 2 MPPT. We don't know if over-current is harmful in this case.

Describe the solution you'd like

While the user should be aware of this when he connects a 24V battery (documentation needed) and set this Upper power limit accordingly, it would also be good if we prevent exceeding the Ampere limit in the code with a safety mechanism.

Proposal:
New configuration option: Max Ampere per channel (Default 10.5A).

Formula for maximum power limiter per channel based on P = U * I:

Total power limit: current_voltage x ampere_limit x num_dc_channels
Example: 24V * 10.5A * 2 = 504W

Describe alternatives you've considered

What do you think?

Additional context

No response

What happened?

Das Verhalten ist nun das zweite Mal dasselbe und persistiert offenbar:
neueste Firmware in PlatformIO (VS, vorher ge"cleant") kompiliert und OTA versucht.
Blieb wieder bei 35% hängen und es passierte nichts weiter.
Neustart per UI angeschubst und den Hinweis auf Bugreport gelesen.
Auch Hart-Reset durch vom Strom trennen ändert nichts, das Ergebnis im OTA bleibt bestehen.
Deshalb nun dieser Bericht.
Auch Holen der neuesten "opendtu-onbattery-generic.bin" und Einspielen via OTA bleibt an derselben Stelle hängen.
Mir bleibt nichts anderes übrig, als den ESP32 komplett zu löschen und per VS neu zu flashen.
Das ist doch bestimmt nicht Sinn des OTA.

To Reproduce Bug

Try to flash new version via OTA stucks at 35%.

Expected Behavior

Working firmware update over OTA

Install Method

Self-Compiled

What git-hash/version of OpenDTU?

83b42a3

Relevant log/trace output

nothing to find

Anything else?

No response

Is your feature request related to a problem? Please describe.

Based on the discussion #247 the Power Meter Module has to be extended to support beside basic authentication also digest authentication, to support the new Shelly pro 3em.

Describe the solution you'd like

extend the http + json Konfiguration to use digest authentication if it receives a 401 error.

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

Right now, the versioning tags from the original openDTU are used and releases are build using this tags.
This may confuse normal users.

Describe the solution you'd like

I propose to use date based release numbers like 2023.04.27 for a release published on 27.04.2024 following PEP440

Describe alternatives you've considered

No response

Additional context

No response

What happened?

I use telegram to poll the prometheus api every 5 seconds. After a while OpenDTU reboots.

To Reproduce Bug

I use telegram to poll prometheus api every 5 seconds

Expected Behavior

Don't crash.

Install Method

Self-Compiled

What git-hash/version of OpenDTU?

09942e8

Relevant log/trace output

14:23:23.000 > abort() was called at PC 0x40198987 on core 1
14:23:23.005 > 
14:23:23.005 > 
14:23:23.005 > Backtrace: 0x4008391d:0x3ffddf80 0x4008e0f1:0x3ffddfa0 0x400939f1:0x3ffddfc0 0x40198987:0x3ffde040 0x401989ce:0x3ffde060 0x401984c7:0x3ffde080 0x401985ee:0x3ffde0a0 0x40197ea5:0x3ffde0c0 0x4010ec95:0x3ffde0e0 0x40100f6d:0x3ffde100 0x400fe9ad:0x3ffde140 0x400f1cc7:0x3ffde160 0x401b5321:0x3ffde1f0 0x40101ca1:0x3ffde210 0x400ff209:0x3ffde260 0x400ff539:0x3ffde2b0 0x400ff749:0x3ffde310 0x4019ad41:0x3ffde330 0x4019adb9:0x3ffde360 0x4019b572:0x3ffde380
14:23:23.603 > 
14:23:23.603 >   #0  0x4008391d:0x3ffddf80 in panic_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/panic.c:402
14:23:23.603 >   #1  0x4008e0f1:0x3ffddfa0 in esp_system_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/esp_system.c:128
14:23:23.603 >   #2  0x400939f1:0x3ffddfc0 in abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/newlib/abort.c:46
14:23:23.603 >   #3  0x40198987:0x3ffde040 in __cxxabiv1::__terminate(void (*)()) at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/0/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47
14:23:23.603 >   #4  0x401989ce:0x3ffde060 in std::terminate() at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/0/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:57
14:23:23.603 >   #5  0x401984c7:0x3ffde080 in __cxa_throw at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/0/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:95
14:23:23.603 >   #6  0x401985ee:0x3ffde0a0 in operator new(unsigned int) at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/0/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/new_op.cc:54
14:23:23.603 >   #7  0x40197ea5:0x3ffde0c0 in operator new[](unsigned int) at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/0/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/new_opv.cc:32
14:23:23.603 >   #8  0x4010ec95:0x3ffde0e0 in cbuf::cbuf(unsigned int) at /Users/herbe/.platformio/packages/framework-arduinoespressif32/cores/esp32/cbuf.cpp:24
14:23:23.603 >   #9  0x40100f6d:0x3ffde100 in AsyncResponseStream::AsyncResponseStream(String const&, unsigned int) at .pio/libdeps/d1 mini esp32/ESP Async WebServer/src/WebResponses.cpp:680
14:23:23.603 >   #10 0x400fe9ad:0x3ffde140 in AsyncWebServerRequest::beginResponseStream(String const&, unsigned int) at .pio/libdeps/d1 mini esp32/ESP Async WebServer/src/WebRequest.cpp:777
14:23:23.603 >   #11 0x400f1cc7:0x3ffde160 in WebApiPrometheusClass::onPrometheusMetricsGet(AsyncWebServerRequest*) at src/WebApi_prometheus.cpp:26
14:23:23.603 >   #12 0x401b5321:0x3ffde1f0 in void std::__invoke_impl<void, void (WebApiPrometheusClass::*&)(AsyncWebServerRequest*), WebApiPrometheusClass*&, AsyncWebServerRequest*>(std::__invoke_memfun_deref, void (WebApiPrometheusClass::*&)(AsyncWebServerRequest*), WebApiPrometheusClass*&, AsyncWebServerRequest*&&) at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/bits/invoke.h:73
14:23:23.603 >       (inlined by) std::__invoke_result<void (WebApiPrometheusClass::*&)(AsyncWebServerRequest*), WebApiPrometheusClass*&, AsyncWebServerRequest*>::type std::__invoke<void (WebApiPrometheusClass::*&)(AsyncWebServerRequest*), WebApiPrometheusClass*&, AsyncWebServerRequest*>(void (WebApiPrometheusClass::*&)(AsyncWebServerRequest*), WebApiPrometheusClass*&, AsyncWebServerRequest*&&) at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/bits/invoke.h:95
14:23:23.603 >       (inlined by) void std::_Bind<void (WebApiPrometheusClass::*(WebApiPrometheusClass*, std::_Placeholder<1>))(AsyncWebServerRequest*)>::__call<void, AsyncWebServerRequest*&&, 0u, 1u>(std::tuple<AsyncWebServerRequest*&&>&&, std::_Index_tuple<0u, 1u>) at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/functional:400
14:23:23.603 >       (inlined by) void std::_Bind<void (WebApiPrometheusClass::*(WebApiPrometheusClass*, std::_Placeholder<1>))(AsyncWebServerRequest*)>::operator()<AsyncWebServerRequest*, void>(AsyncWebServerRequest*&&) at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/functional:484
14:23:23.603 >       (inlined by) std::_Function_handler<void (AsyncWebServerRequest*), std::_Bind<void (WebApiPrometheusClass::*(WebApiPrometheusClass*, std::_Placeholder<1>))(AsyncWebServerRequest*)> >::_M_invoke(std::_Any_data const&, AsyncWebServerRequest*&&) at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/bits/std_function.h:297
14:23:23.603 >   #13 0x40101ca1:0x3ffde210 in std::function<void (AsyncWebServerRequest*)>::operator()(AsyncWebServerRequest*) const at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/bits/std_function.h:687
14:23:23.603 >       (inlined by) AsyncCallbackWebHandler::handleRequest(AsyncWebServerRequest*) at .pio/libdeps/d1 mini esp32/ESP Async WebServer/src/WebHandlerImpl.h:132
14:23:23.603 >   #14 0x400ff209:0x3ffde260 in AsyncWebServerRequest::_parseLine() at .pio/libdeps/d1 mini esp32/ESP Async WebServer/src/WebRequest.cpp:603 (discriminator 1)
14:23:23.603 >   #15 0x400ff539:0x3ffde2b0 in AsyncWebServerRequest::_onData(void*, unsigned int) at .pio/libdeps/d1 mini esp32/ESP Async WebServer/src/WebRequest.cpp:124
14:23:23.603 >   #16 0x400ff749:0x3ffde310 in std::_Function_handler<void (void*, AsyncClient*, void*, unsigned int), AsyncWebServerRequest::AsyncWebServerRequest(AsyncWebServer*, AsyncClient*)::{lambda(void*, AsyncClient*, void*, unsigned int)#6}>::_M_invoke(std::_Any_data const&, void*&&, AsyncClient*&&, std::_Any_data const&, unsigned int&&) at .pio/libdeps/d1 mini esp32/ESP Async WebServer/src/WebRequest.cpp:72
14:23:23.603 >       (inlined by) _M_invoke at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/bits/std_function.h:297
14:23:23.603 >   #17 0x4019ad41:0x3ffde330 in std::function<void (void*, AsyncClient*, void*, unsigned int)>::operator()(void*, AsyncClient*, void*, unsigned int) const at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/bits/std_function.h:687
14:23:23.603 >       (inlined by) AsyncClient::_recv(tcp_pcb*, pbuf*, signed char) at .pio/libdeps/d1 mini esp32/AsyncTCP/src/AsyncTCP.cpp:915
14:23:23.603 >   #18 0x4019adb9:0x3ffde360 in AsyncClient::_s_recv(void*, tcp_pcb*, pbuf*, signed char) at .pio/libdeps/d1 mini esp32/AsyncTCP/src/AsyncTCP.cpp:1191
14:23:23.603 >   #19 0x4019b572:0x3ffde380 in _async_service_task(void*) at .pio/libdeps/d1 mini esp32/AsyncTCP/src/AsyncTCP.cpp:159
14:23:23.603 >       (inlined by) _async_service_task at .pio/libdeps/d1 mini esp32/AsyncTCP/src/AsyncTCP.cpp:194
14:23:23.603 > 
14:23:23.603 > 
14:23:23.603 > 

or

14:37:26.140 > Success
14:37:26.929 > 
14:37:26.930 > abort() was called at PC 0x40198987 on core 1
14:37:26.934 > 
14:37:26.934 > 
14:37:26.934 > Backtrace: 0x4008391d:0x3ffddfa0 0x4008e0f1:0x3ffddfc0 0x400939f1:0x3ffddfe0 0x40198987:0x3ffde060 0x401989ce:0x3ffde080 0x401984c7:0x3ffde0a0 0x401985ee:0x3ffde0c0 0x40197ea5:0x3ffde0e0 0x4010ec95:0x3ffde100 0x40100f6d:0x3ffde120 0x400fe9ad:0x3ffde160 0x400f1cc7:0x3ffde180 0x401b5321:0x3ffde210 0x40101ca1:0x3ffde230 0x400ff209:0x3ffde280 0x400ff539:0x3ffde2d0 0x400ff749:0x3ffde330 0x4019ad41:0x3ffde350 0x4019adb9:0x3ffde380 0x4019b572:0x3ffde3a0
14:37:27.447 > 
14:37:27.447 >   #0  0x4008391d:0x3ffddfa0 in panic_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/panic.c:402
14:37:27.447 >   #1  0x4008e0f1:0x3ffddfc0 in esp_system_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/esp_system.c:128
14:37:27.447 >   #2  0x400939f1:0x3ffddfe0 in abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/newlib/abort.c:46
14:37:27.447 >   #3  0x40198987:0x3ffde060 in __cxxabiv1::__terminate(void (*)()) at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/0/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47
14:37:27.447 >   #4  0x401989ce:0x3ffde080 in std::terminate() at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/0/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:57
14:37:27.447 >   #5  0x401984c7:0x3ffde0a0 in __cxa_throw at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/0/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:95
14:37:27.447 >   #6  0x401985ee:0x3ffde0c0 in operator new(unsigned int) at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/0/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/new_op.cc:54
14:37:27.447 >   #7  0x40197ea5:0x3ffde0e0 in operator new[](unsigned int) at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/0/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/new_opv.cc:32
14:37:27.447 >   #8  0x4010ec95:0x3ffde100 in cbuf::cbuf(unsigned int) at /Users/herbe/.platformio/packages/framework-arduinoespressif32/cores/esp32/cbuf.cpp:24
14:37:27.447 >   #9  0x40100f6d:0x3ffde120 in AsyncResponseStream::AsyncResponseStream(String const&, unsigned int) at .pio/libdeps/d1 mini esp32/ESP Async WebServer/src/WebResponses.cpp:680
14:37:27.447 >   #10 0x400fe9ad:0x3ffde160 in AsyncWebServerRequest::beginResponseStream(String const&, unsigned int) at .pio/libdeps/d1 mini esp32/ESP Async WebServer/src/WebRequest.cpp:777
14:37:27.447 >   #11 0x400f1cc7:0x3ffde180 in WebApiPrometheusClass::onPrometheusMetricsGet(AsyncWebServerRequest*) at src/WebApi_prometheus.cpp:26
14:37:27.447 >   #12 0x401b5321:0x3ffde210 in void std::__invoke_impl<void, void (WebApiPrometheusClass::*&)(AsyncWebServerRequest*), WebApiPrometheusClass*&, AsyncWebServerRequest*>(std::__invoke_memfun_deref, void (WebApiPrometheusClass::*&)(AsyncWebServerRequest*), WebApiPrometheusClass*&, AsyncWebServerRequest*&&) at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/bits/invoke.h:73
14:37:27.447 >       (inlined by) std::__invoke_result<void (WebApiPrometheusClass::*&)(AsyncWebServerRequest*), WebApiPrometheusClass*&, AsyncWebServerRequest*>::type std::__invoke<void (WebApiPrometheusClass::*&)(AsyncWebServerRequest*), WebApiPrometheusClass*&, AsyncWebServerRequest*>(void (WebApiPrometheusClass::*&)(AsyncWebServerRequest*), WebApiPrometheusClass*&, AsyncWebServerRequest*&&) at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/bits/invoke.h:95
14:37:27.447 >       (inlined by) void std::_Bind<void (WebApiPrometheusClass::*(WebApiPrometheusClass*, std::_Placeholder<1>))(AsyncWebServerRequest*)>::__call<void, AsyncWebServerRequest*&&, 0u, 1u>(std::tuple<AsyncWebServerRequest*&&>&&, std::_Index_tuple<0u, 1u>) at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/functional:400
14:37:27.447 >       (inlined by) void std::_Bind<void (WebApiPrometheusClass::*(WebApiPrometheusClass*, std::_Placeholder<1>))(AsyncWebServerRequest*)>::operator()<AsyncWebServerRequest*, void>(AsyncWebServerRequest*&&) at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/functional:484
14:37:27.447 >       (inlined by) std::_Function_handler<void (AsyncWebServerRequest*), std::_Bind<void (WebApiPrometheusClass::*(WebApiPrometheusClass*, std::_Placeholder<1>))(AsyncWebServerRequest*)> >::_M_invoke(std::_Any_data const&, AsyncWebServerRequest*&&) at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/bits/std_function.h:297
14:37:27.447 >   #13 0x40101ca1:0x3ffde230 in std::function<void (AsyncWebServerRequest*)>::operator()(AsyncWebServerRequest*) const at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/bits/std_function.h:687
14:37:27.447 >       (inlined by) AsyncCallbackWebHandler::handleRequest(AsyncWebServerRequest*) at .pio/libdeps/d1 mini esp32/ESP Async WebServer/src/WebHandlerImpl.h:132
14:37:27.447 >   #14 0x400ff209:0x3ffde280 in AsyncWebServerRequest::_parseLine() at .pio/libdeps/d1 mini esp32/ESP Async WebServer/src/WebRequest.cpp:603 (discriminator 1)
14:37:27.447 >   #15 0x400ff539:0x3ffde2d0 in AsyncWebServerRequest::_onData(void*, unsigned int) at .pio/libdeps/d1 mini esp32/ESP Async WebServer/src/WebRequest.cpp:124
14:37:27.447 >   #16 0x400ff749:0x3ffde330 in std::_Function_handler<void (void*, AsyncClient*, void*, unsigned int), AsyncWebServerRequest::AsyncWebServerRequest(AsyncWebServer*, AsyncClient*)::{lambda(void*, AsyncClient*, void*, unsigned int)#6}>::_M_invoke(std::_Any_data const&, void*&&, AsyncClient*&&, std::_Any_data const&, unsigned int&&) at .pio/libdeps/d1 mini esp32/ESP Async WebServer/src/WebRequest.cpp:72
14:37:27.447 >       (inlined by) _M_invoke at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/bits/std_function.h:297
14:37:27.447 >   #17 0x4019ad41:0x3ffde350 in std::function<void (void*, AsyncClient*, void*, unsigned int)>::operator()(void*, AsyncClient*, void*, unsigned int) const at /Users/herbe/.platformio/packages/[email protected]+2021r2-patch5/xtensa-esp32-elf/include/c++/8.4.0/bits/std_function.h:687
14:37:27.447 >       (inlined by) AsyncClient::_recv(tcp_pcb*, pbuf*, signed char) at .pio/libdeps/d1 mini esp32/AsyncTCP/src/AsyncTCP.cpp:915
14:37:27.447 >   #18 0x4019adb9:0x3ffde380 in AsyncClient::_s_recv(void*, tcp_pcb*, pbuf*, signed char) at .pio/libdeps/d1 mini esp32/AsyncTCP/src/AsyncTCP.cpp:1191
14:37:27.447 >   #19 0x4019b572:0x3ffde3a0 in _async_service_task(void*) at .pio/libdeps/d1 mini esp32/AsyncTCP/src/AsyncTCP.cpp:159
14:37:27.447 >       (inlined by) _async_service_task at .pio/libdeps/d1 mini esp32/AsyncTCP/src/AsyncTCP.cpp:194
14:37:27.447 > 
14:37:27.448 > 

Anything else?

No response

Is your feature request related to a problem? Please describe.

(Pylontech)-Battery is not shown with Home Assistant MQTT-Auto-Discovery

Describe the solution you'd like

Add Battery support to Home Assistant MQTT-Auto-Discovery

I am working on a PR for this.

Describe alternatives you've considered

No response

Additional context

No response

What happened?

if i what to switch off "Welchselrichter ist hinter Leistungsmesser" in menue mowerlimiter and press the "speichern" button I get the following "error message": "Bitte klicken Sei diese Kästchen um fortfahren zu können".
changes will be not saved. if i reload menue mowerlimiter swithc is still enabled.
have you got a wiring diagramm how power meter is connected at default settings?
for me zero consumtion regulation only works if i place shelly 3em after hoymiles connection point?

Thank you

To Reproduce Bug

try to switch off "Welchselrichter ist hinter Leistungsmesser" in menue mowerlimiter and press the "speichern" button

Expected Behavior

switch work

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

f018a01

Relevant log/trace output

RX Period End
13:51:09.100 > Success
13:51:09.100 > Fetch inverter: 116484424196
13:51:09.205 > TX RealTimeRunData 865.00 MHz --> 15 84 42 41 96 80 12 06 72 80 0B 00 64 96 D8 AD 00 00 00 00 00 00 00 00 DB 16 23 
13:51:09.317 > Interrupt received
13:51:09.420 > RX 865.00 MHz --> 95 84 42 41 96 80 12 06 72 01 00 01 00 0C 00 0C 00 01 00 00 00 00 00 00 00 00 63 | -33 dBm
13:51:09.523 > Interrupt received
13:51:09.615 > RX 865.00 MHz --> 95 84 42 41 96 80 12 06 72 03 02 08 0A AA 0A BC 00 00 02 F4 00 00 02 46 01 53 9D | -33 dBm
13:51:09.715 > Interrupt received
13:51:09.766 > RX 865.00 MHz --> 95 84 42 41 96 80 12 06 72 04 01 54 09 56 13 89 14 55 00 00 00 D9 03 E8 01 6A EE | -34 dBm
13:51:09.832 > Interrupt received
13:51:09.894 > RX 865.00 MHz --> 95 84 42 41 96 80 12 06 72 85 00 1F F6 D9 D7 | -34 dBm
13:51:10.025 > RX Period End
13:51:10.025 > Middle missing
13:51:10.025 > Request retransmit: 2
13:51:10.025 > TX RequestFrame 865.00 MHz --> 15 84 42 41 96 80 12 06 72 82 60 
13:51:10.144 > Interrupt received
13:51:10.230 > RX 865.00 MHz --> 95 84 42 41 96 80 12 06 72 02 00 00 00 00 00 00 00 00 00 00 02 10 02 11 02 05 66 | -34 dBm
13:51:10.301 > RX Period End
13:51:10.301 > Success
13:51:14.108 > Fetch inverter: 116484424196
13:51:14.220 > TX RealTimeRunData 865.00 MHz --> 15 84 42 41 96 80 12 06 72 80 0B 00 64 96 D8 B2 00 00 00 00 00 00 00 00 EB 9A 80 
13:51:14.292 > Interrupt received
13:51:14.426 > RX 865.00 MHz --> 95 84 42 41 96 80 12 06 72 01 00 01 00 0C 00 0C 00 01 00 00 00 00 00 00 00 00 63 | -34 dBm
13:51:14.497 > Interrupt received
13:51:14.660 > RX 865.00 MHz --> 95 84 42 41 96 80 12 06 72 02 00 00 00 00 00 00 00 00 00 00 02 10 02 11 02 05 66 | -33 dBm
13:51:14.748 > Interrupt received
13:51:14.830 > RX 865.00 MHz --> 95 84 42 41 96 80 12 06 72 03 02 08 0A AA 0A BC 00 00 02 F4 00 00 02 47 01 53 9C | -34 dBm
13:51:14.895 > Interrupt received
13:51:15.041 > RX 865.00 MHz --> 95 84 42 41 96 80 12 06 72 04 01 55 09 55 13 89 14 55 00 00 00 D9 03 E8 01 6A EC | -33 dBm
13:51:15.155 > Interrupt received
13:51:15.246 > RX 865.00 MHz --> 95 84 42 41 96 80 12 06 72 85 00 1F B6 DB 95 | -34 dBm
13:51:15.365 > RX Period End
13:51:15.365 > Success
13:51:17.338 > PowerMeterClass: TotalPower: 523.71
13:51:17.338 > [PowerLimiterClass::loop] ******************* ENTER **********************
13:51:17.338 > [PowerLimiterClass::loop] dcVoltage: 52.80 Voltage Start Threshold: 25.00 Voltage Stop Threshold: 24.00 inverter->isProducing(): 1
13:51:17.338 > [PowerLimiterClass::loop] newPowerLimit: 514
13:51:17.338 > [PowerLimiterClass::loop] Limit Non-Persistent: 514 W
13:51:17.338 > [PowerLimiterClass::loop] Status: SolarPT enabled 0, Drain Strategy: 0, canUseDirectSolarPower: 0, Batt discharge: 1
13:51:17.338 > [PowerLimiterClass::loop] Status: StInterrupt received
13:51:17.499 > RX 865.00 MHz --> D1 84 42 41 96 80 12 06 72 81 00 00 0B 00 14 07 BF | -34 dBm
13:51:19.343 > RX Period End
13:51:19.343 > Success
13:51:19.343 > Fetch inverter: 116484424196
13:51:19.453 > TX RealTimeRunData 865.00 MHz --> 15 84 42 41 96 80 12 06 72 80 0B 00 64 96 D8 B7 00 00 00 00 00 00 00 00 BB A5 EA 
13:51:19.561 > Interrupt received
13:51:19.649 > RX 865.00 MHz --> 95 84 42 41 96 80 12 06 72 01 00 01 00 0C 00 0C 00 01 00 00 00 00 00 00 00 00 63 | -34 dBm
13:51:19.720 > Interrupt received
13:51:19.777 > RX 865.00 MHz --> 95 84 42 41 96 80 12 06 72 02 00 00 00 00 00 00 00 00 00 00 02 10 02 11 02 09 6A | -33 dBm
13:51:19.868 > Interrupt received
13:51:19.926 > RX 865.00 MHz --> 95 84 42 41 96 80 12 06 72 03 02 0C 0A BF 0A D2 00 00 02 F4 00 00 02 47 01 53 E3 | -33 dBm
13:51:20.073 > Interrupt received
13:51:20.161 > RX 865.00 MHz --> 95 84 42 41 96 80 12 06 72 04 01 55 09 55 13 89 14 7D 00 04 00 DB 03 E7 01 6B CC | -34 dBm
13:51:20.277 > Interrupt received
13:51:20.366 > RX 865.00 MHz --> 95 84 42 41 96 80 12 06 72 85 00 1F 9E 72 14 | -34 dBm
13:51:20.436 > RX Period End
13:51:20.436 > Success

Anything else?

great project !!"

Is your feature request related to a problem? Please describe.

No response

Describe the solution you'd like

Hi,

Not sure how how to best get in contact, hence the issue...

I started to integrate a Huawei AC PSU as an AC based charging source into openDTU. Not fully ready yet but I'm on a good trajectory to complete this soon. Is there interest in a PR?

BTW: I have a pending PR on openDTU that adds two battery related safety features for the inverter. It may be better suited for this project though

BTW2: I realized yesterday that my intended setup is similar to what you're using (Victron MPPT / pylontech) so I'll be using your project as a basis going forward

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

No response

Describe the solution you'd like

It would be great if someone could add support for Renogy MPPTs, just like the Victron support.
They are also connected via serial interface (Modbus) and there is documentation available:
https://github.com/mickwheelz/NodeRenogy
I lack the programming knowledge to do this, but I think it seems not to be too difficult.
I am happy to do the testing if someone can do the programming!

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

For non-Victron users, it would be really helpful if there was a way to somehow inject the MPPT charger live data into
OpenDTU-OnBattery every few seconds in order to be able to use solar passthrough.

I would also love to be able to remotely (via web API) configure and turn the dynamic power inverter on/off, so I could have Home Assistant turn it off and manually set the power limit on the inverter for a few hours for whatever reasons (or change settings from time to time based on the weather forecast)...

Describe the solution you'd like

for the MPPT data: an API call that could easily be made by some esphome or Home Assistant installation would be great. I assume the only relevant values needed would be "V" and "I" as shown by /api/vedirectlivedata/status, so if a new API POST call would allow only to update those two fields, the whole existing logic would "just work" like it does with Victrons. Is that assumption correct?

for the dynamic power limiter, the api call to /api/powerlimiter/status should just be writable

Describe alternatives you've considered

No response

Additional context

No response

What happened?

If you use dynamic power limiter without battery it stops the inverter after a few seconds. You can manually restart the inverter but it gets stops shortly after.

To Reproduce Bug

Setup Dynamic power limiting without connected battery

Expected Behavior

Ignore or opt out battery to limit power that gets feed in to the grid.

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

1c7b7d3

Relevant log/trace output

No response

Anything else?

I use MQTT topic to get the power of the grid tied meter. Lower inverter limit to 150 and upper to 600, allowed grid meter to -50, hysteresis to 10.

It starts with something 50W above my actual consumption, which is fine. Shortly after it limits to lowest limit (150) and than stops the inverter completely.

edit:
today i tested again. this time i set all battery values to zero (SoC start and stop, DC voltage start and stop) and it looks like it is working.
so, i guess, one could change the label from bug to enhancement, to maybe create a toggle switch to opt-out (or opt-in) a battery at all. (or maybe move dynamic power limit settings to power meter tab as it could be used, regardless of whether a battery is used or not)

Is your feature request related to a problem? Please describe.

No response

Describe the solution you'd like

Hi,
I currently have 2 HM-600 installed. It would be great if it's possible to add multiple inverters to the dynamic power limiter.

Regards

Describe alternatives you've considered

No response

Additional context

Thanks for such a helpful project!

What happened?

My Hoymiles HM-600 with DynamicPowerLimiter enabled keeps turning off and on when the battery is low, even though the restart voltage is set at 49V, and the restart SOC is set at 20%.
I only noticed this behavior with the latest "master version" - it worked with the previous ones.

The SOC of the battery at that time was constant at 11% and US2000c is connected to DTU..
At 5:52h, I disabled the DPL and switeched off the Hoymiles manually

To Reproduce Bug

• Enable DPL
• wait until "DC Voltage - Stop threshold" is reached

Expected Behavior

The HM-600 should shut down when the voltage drops below 47.5V or 10% SOC, and turn back on when the voltage exceeds 49V or 20% SOC.

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

83b42a3

Relevant log/trace output

No response

Anything else?

No response

Is your feature request related to a problem? Please describe.

Feature Request:
I shared my finding in #185 and suggest to look into adding support for at least one dedicated Smartshunt through Ve.Direct.

Describe the solution you'd like

The Shunt should use dedicated GPIO Pins (needs 2) to interface with the ESP board. I didn't look into whether with the current setup GPIO Pins are still available.
This development should also consider the potential future support for a second MPPT, hence the "PIN Strategy" should be set up carefully.

The Webinterface should allow to switch between CAN Bus and VE.Direct SOC reading.

Describe alternatives you've considered

Alternative (cheaper, a little bit less accurate) to read the SOC from Batteries who do not provide a CAN Bus interface would be the Support for Shelly UNI.

Additional context

No response

Is your feature request related to a problem? Please describe.

It is absolutely not clear what is meant with that field (unless reading #169 (comment))

Describe the solution you'd like

Rename the field to a better describing text. Ideally add an "Info" hint popup

Describe alternatives you've considered

No response

Additional context

No response

What happened?

I set the limit to 600W and my HM-1500 only allows 300W. As soon as I set the limit to 1200W it goes up to 520W, which are the peak atm. How can I change this ? Modules are at input 1 and 2.

To Reproduce Bug

Set limit to 600W and only 300W will be there, even if the Modules create more power. Occurs if Modules are at input 1 and 2.

Expected Behavior

At the moment there should be 520W, if I set the limit to 600W.

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

569edbe

Relevant log/trace output

No response

Anything else?

No response

What happened?

Ich habe das File pin_mapping.json mit anderen Ports gefüllt als 21 und 22
Wenn diese beiden verwendet werden, geht es wenn ich aber andere eingebe führt dazu das es schlicht nicht mehr funktioniert
Sprich hier fehlt wohl im code noch eine Weiche das auf die anderen Ports geschaltet wird

To Reproduce Bug

pin_mapping.json hochladen mit anderen Ports als 21/22 konfiguriert, an diese Ports anstecken.
Geht nicht

Expected Behavior

Verwendung der angegeben Ports

Install Method

Self-Compiled

What git-hash/version of OpenDTU?

Aktuelle

Relevant log/trace output

No response

Anything else?

No response

What happened?

I noticed (in the code) that if the DPL is set into mode PL_MODE_SOLAR_PT_ONLY using MQTT, the power limit is unconditionally matched to the solar charger's output power. That's full solar passthrough.

I do not use the feature, but this implementation is surprising and I am guessing that it is a bug? If not, the documentation could be updated to explain that this mode really makes all solar energy disappear into the grid 😉

To Reproduce Bug

Set DPL into mode PL_MODE_SOLAR_PT_ONLY using MQTT -- or look at the code.

Expected Behavior

Non-full battery may still charge even when PL_MODE_SOLAR_PT_ONLY is set using MQTT.

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

2223afa

Relevant log/trace output

No response

Anything else?

No response

Is your feature request related to a problem? Please describe.

Erst einmal vielen vielen Dank für das großartige Projekt!

Die Anzeige "Inverter Gesamtertrag Heute" beeinhaltet den Tagesertrag des WR an der Batterie aus der vorangenagenen Nachteinspeisung.

Describe the solution you'd like

Ich hätte gerne einen automatischen Neustart des Wechselrichters an der Batterie zu einer konfigurierbaren oder festen Zeit (z.B. 12 Uhr), damit sich der Tagesertrag des WR an der Batterie auf 0 setzt und damit der Wert "Inverter Gesamtertrag Heute" in der Übersicht aktualisiert und der Ertrag aus der Nacht nicht mehr hinzu addiert wird.

Describe alternatives you've considered

No response

Additional context

No response

What happened?

installed dev branch from today on factory resetted esp32.
only WiFi and MQTT are set.
MQTT connects and disconnects, see log

Tested with two different MQTT Servers (2x separate RasPis)

To Reproduce Bug

enable MQTT (with credentials)

Expected Behavior

MQTT stays connected

Install Method

Self-Compiled

What git-hash/version of OpenDTU?

7d48e42

Relevant log/trace output

--- Terminal on COM6 | 115200 8-N-1
--- Available filters and text transformations: colorize, debug, default, direct, esp32_exception_decoder, hexlify, log2file, nocontrol, printable, send_on_enter, time
--- More details at https://bit.ly/pio-monitor-filters
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H
22:03:23.776 > ets Jun  8 2016 00:22:57
22:03:23.776 > 
22:03:23.776 > rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
22:03:23.776 > configsip: 0, SPIWP:0xee
22:03:23.776 > clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
22:03:23.776 > mode:DIO, clock div:2
22:03:23.776 > load:0x3fff0030,len:1184
22:03:23.776 > load:0x40078000,len:13192
22:03:23.776 > load:0x40080400,len:3028
22:03:23.776 > entry 0x400805e4
22:03:23.776 > E (633) esp_core_dump_flash: No core du=�partition found!
22:03:23.776 > E (633) esp_core_dump_flash: No core dump partition found!
22:03:23.776 >
22:03:23.776 > Starting OpenDTU
22:03:23.776 > Initialize FS... done
22:03:23.776 > Reading configuration... done
22:03:23.776 > Reading PinMapping... [   164][E][vfs_api.cpp:105] open(): /littlefs/pin_mapping.json does not exist, no permits for creation
22:03:23.776 > using default config done
22:03:23.776 > Initialize Network... done
22:03:23.776 > Setting Hostname... Configuring WiFi STA using new credentials... done
22:03:23.776 > Initialize NTP... done
22:03:23.776 > Initialize SunPosition... done
22:03:23.776 > Initialize MqTT... done
22:03:23.776 > Initialize WebApi... done
22:03:23.776 > Initialize Display... done
22:03:23.776 > Check for default DTU serial... done
22:03:23.776 > Initialize Hoymiles interface... Connection successfull
22:03:23.776 >   Setting radio PA level...
22:03:23.776 >   Setting DTU serial...
22:03:23.776 >   Setting poll interval...
22:03:23.776 > done
22:03:23.776 > Initialize ve.direct interface...
22:03:23.776 > ve.direct rx = 16, tx = 17
22:03:23.776 > done
22:03:23.776 > Initialize Pylontech battery interface...
22:03:23.776 > Pylontech Battery rx = 27, tx = 14
22:03:23.776 > done
22:03:23.776 > Switch to WiFi mode
22:03:23.776 > Setting Hostname... done
22:03:23.776 > Configuring WiFi STA using new credentials... WiFi disconnected
22:03:23.776 > Try reconnecting
22:03:23.776 > [  1477][E][WiFiGeneric.cpp:113] set_esp_interface_ip(): Netif Set IP Failed! 0x5007
22:03:23.776 > done
22:03:23.776 > ConfiguringNetwork lost connection
22:03:23.776 >  WiFi STA DHCP IP... done
22:03:23.776 > E (6780) wifi:Association refused temporarily, comeback time 1022 mSec
22:03:23.776 > E (7824) wifi:Set status to INIT
22:03:23.776 > WiFi disconnected
22:03:23.776 > Try reconnecting
22:03:23.776 > Network lost connection
22:03:23.776 > WiFi connected
22:03:23.776 > WiFi got ip: 192.168.178.101
22:03:23.776 > Network connected
22:03:23.776 > Connecting to MQTT...
22:03:23.776 > Disconnected from MQTT.
22:03:23.776 > Disconnect reason:MQTT_NOT_AUTHORIZED
22:03:23.776 > Connecting to MQTT...
22:03:50.612 > Disconnected from MQTT.
22:03:50.614 > Disconnect reason:TCP_DISCONNECTED
22:03:52.611 > Connecting to MQTT...
22:04:22.643 > Disconnected from MQTT.
22:04:22.644 > Disconnect reason:TCP_DISCONNECTED
22:04:24.641 > Connecting to MQTT...
22:04:54.669 > Disconnected from MQTT.
22:04:54.671 > Disconnect reason:TCP_DISCONNECTED
22:04:56.670 > Connecting to MQTT...
22:05:26.695 > Disconnected from MQTT.
22:05:26.702 > Disconnect reason:TCP_DISCONNECTED
22:05:28.699 > Connecting to MQTT...
22:05:58.729 > Disconnected from MQTT.
22:05:58.732 > Disconnect reason:TCP_DISCONNECTED
22:06:00.728 > Connecting to MQTT...
22:06:18.732 > Admin mode disabled
22:06:30.755 > Disconnected from MQTT.
22:06:30.757 > Disconnect reason:TCP_DISCONNECTED
22:06:32.754 > Connecting to MQTT...
22:07:02.785 > Disconnected from MQTT.
22:07:02.785 > Disconnect reason:TCP_DISCONNECTED
22:07:04.770 > Connecting to MQTT...
22:07:34.801 > Disconnected from MQTT.
22:07:34.801 > Disconnect reason:TCP_DISCONNECTED
22:07:36.798 > Connecting to MQTT...
22:08:06.833 > Disconnected from MQTT.
22:08:06.848 > Disconnect reason:TCP_DISCONNECTED
22:08:08.832 > Connecting to MQTT...
22:08:38.864 > Disconnected from MQTT.
22:08:38.879 > Disconnect reason:TCP_DISCONNECTED
22:08:40.874 > Connecting to MQTT...
22:09:10.911 > Disconnected from MQTT.
22:09:10.911 > Disconnect reason:TCP_DISCONNECTED
22:09:12.913 > Connecting to MQTT...
22:09:42.948 > Disconnected from MQTT.
22:09:42.949 > Disconnect reason:TCP_DISCONNECTED
22:09:44.945 > Connecting to MQTT...

Anything else?

No response

Is your feature request related to a problem? Please describe.

No response

Describe the solution you'd like

It would be great if you could activate and deactivate the "Dynamic Power Limiter" externally via MQTT.
This would enable you to specify other values in Home Assistant, for example, without having to deactivate the DPL via the OpenDTU first.

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

Actual there is no feedback in which state the power limiter is. This might be helpful for diagnostic purposes.

Describe the solution you'd like

Extend MPPT live view with the power limiter state:

• disabled
• off
• normal operation
• solar passthrough

Describe alternatives you've considered

No response

Additional context

No response

What happened?

Due to pr #172 the indication in live view that solarpasstrhough is active doesn't exist anymore.

To Reproduce Bug

If voltage is below start threshold and above stop threshold and solar passthrough is activated just the battery icon is shown on live view.

Expected Behavior

if solar passthrough is active, a sun icon should indicate this state in live view.

Install Method

Self-Compiled

What git-hash/version of OpenDTU?

89209b6

Relevant log/trace output

No response

Anything else?

No response

Is your feature request related to a problem? Please describe.

As allready known, if connecting Hoymils inverters to battery inrush current can set BMS to "overcurrent protection state".
The simplest solution is to precharge Hoymiles with a resitor in series and after some time connect Hoymiles directly to the battery.
Using big conntactors for this pupose is very inefficient, because of big coil power counsuption

Describe the solution you'd like

Given situation:
BMS is turned off (the reason is mostly not relevant)
Inverter is turned off = not available because there is no DC voltage
BMS can't turn on because of inrush current.

Pre requirement:
Victron should work, that means, if there is no BMS Voltage, PV should produce enough power to turn Victron on (downside: we have to wait after sun is rising if BMS turned off in the night)
Connect a diode and a big resistor (for 48V Battery around 30 Ohm, it would limit the current to ~2A that Victron 48V can handle on LOAD output).

Idea:

1. Turn on LOAD output on victron: up to 2A@48V are going directly to inverter and it turns on.
2. Inverter is availble, no inrush current any more, BMS can turn on (some BMS do it automaticaly, some must be turned onmanually or via UART/CAN/RS485)
3. BMS turned on = victron sences battery voltage
4. turn off victron load output

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

Hallo,

gibt es die Möglichkeit, beim Victron Smartsolar auch neben Spannung und Strom auch die Batterie Temperatur ausgeben zu lassen?

Describe the solution you'd like

Im Ve. Direct Protokoll werden die Werte mit übertragen

Describe alternatives you've considered

No response

Additional context

No response

What happened?

I want to set the voltage of the Huawei AC Charger via MQTT (same in webinterface) to e.g. 53.3 V. Unfortunately only integer numbers (like 53 or 54) are accepted an transmitted. Why is that and could it be possible to transfer a number with at least one decimal place?

To Reproduce Bug

Same behaviour whether I try it via mqtt or via web interface...

Expected Behavior

I want to set voltage values with at least one decimal place.

Thanks for the project! I just start using opendtu on battery for controlling my Huawei charger and my hoymiles inverter to charge/discharge my battery :-)

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

a6f5e8a

Relevant log/trace output

No response

Anything else?

No response

What happened?

not a bug - but suggestion to improve/simplify the GUI.

The Settings menu is a bit redundant & inconsistent in terms of using of the word "settings".

To Reproduce Bug

click on settings

Expected Behavior

Since the menu is already named "Settings" the sub items can be listed by their names without showing the word settings. Like for AC Charger or Dynamic Power Limiter.

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

7006055

Relevant log/trace output

No response

Anything else?

No response

What happened?

Hi! My configuration is a HM-1500 + Shelly 3EM + OpenDTU-OnBattery Version 616d042.

My real limited power mesured with a Shelly 3EM is always between 20 and 30 Watt, i am not able to come to round about 0 Watt.

As you can see in screenshot 1 with LiveData, i have a difference between the non persistant power limit and the real value of the produced power of the HM-1500. Maybe the real power is used for the calculation of the new value of the non persistant limit.

Screenshot 2 show the debug console output, with the difference between non persistant power limit and the real value of the produced power.

In Screenshot 3 i tried to set the wanted power to "-30" to shift the offset, but i am not able to set a value below "0".

To Reproduce Bug

Every time the power limit is set automaticly, the mesured value at the powermeter is 20 to 30 Watts away (to high) from zero. The power output of the Hoymiles Inverter is lower than the limit set.

Expected Behavior

It would be great to be able to set the wanted power to a value below 0 (for example to -30 Watt), so i can make a manual calibration of false mesured values from the Hoymiles-inverter. My electricity grid operator allows a minimal amount of electricity to be fed into the grid.

Thanks for your great work! I love it! :-)

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

616d042

Relevant log/trace output

No response

Anything else?

No response

What happened?

People that use our project are maybe not aware that working with batteries can be highly dangerous and burn down your hose.
Especially when they don't have any knowledge about electrical engineering or electronics.

To Reproduce Bug

Reproduce: Take a 1,00 mm2 cable and let 30 Ampere flow over it for an hour.

Expected Behavior

The user should be aware that working with batteries can be highly dangerous. --> Fire

It's absolutely necessary that the README contains safety instructions at the top.

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

any

Relevant log/trace output

No response

Anything else?

No response

Is your feature request related to a problem? Please describe.

While using Solar Passthrough the calculated power limit is a little bit too high.

Describe the solution you'd like

The inverter has an efficiency of around 95% converting dc to ac. This has to be taken into account while setting the new power limit to the actual viltron power delivery.

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

Hallo,

ersteinmal vielen Dank für das tolle opendDTU on Battery Projekt. Ist es möglich einen Ausgang am esp zu schalten und damit in Folge ein Relais wenn eine bestimmte Spannung vom mppt unter bzw überschritten ist ?

Describe the solution you'd like

Menü mit Option für Ausgang ein bei Spannung > xxV Ausgang aus bei <xxV

Ähnlich dem virtuellen lastausgang am victron mppt !

Describe alternatives you've considered

No response

Additional context

No response

What happened?

In Home Assistant, when Home Assistant MQTT-Auto-Discovery is active, almost all Sensors of the auto-discovered Victron device in Home Assistant become "unavailable" after a short time - except those Sensors with frequent changes like battery voltage or panel voltage.

To Reproduce Bug

Set the following configuration:

MQTT Settings:

• Home Assistant MQTT-Auto-Discovery -> active
• Enable expiration -> active

Ve.direct Settings:

• Enable Ve.direct -> active
• Send only updates -> active

Expected Behavior

All sensors belonging to auto-discovered Victron chargers should show their values instead of "unavailable", as long as OpenDTU-OnBattery is running and Ve.Direct connection is enabled.

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

n/a

Relevant log/trace output

No response

Anything else?

I am working on a PR for this.

Is your feature request related to a problem? Please describe.

No response

Describe the solution you'd like

Use color scheme of Homilies inverters, to keep same look and feel.

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

Hallo, ist es möglich die Ladereglerdaten über vedirect über das api auszulesen ?

Describe the solution you'd like

ich bekomme sie nicht angezeigt. kann mir einer sagen wo mein Fehler liegt ?

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

Battery was yesterday nearly full. Today my solar system produces more energy, than I can consume. So MPPT goes into absorption and reduces the charge current.

Actual strategy is to charge battery until start threshold is reached and then empty battery.
This is fine as long you don't have additional unbuffered solar systems.

Describe the solution you'd like

I would like to have a new strategy.

If system is in state solarPassthrough and panelPower drops below lowerPowerLimit the inverter shouldn't be switched off. Instead the powerLimiter should switch in state normal_operations.

So when the sun is not shining, battery should be used and empty the battery over night. Each morning maximum battery capacity is available to store unconsumable energy.

This code be realized as an option if solar passthrough is enabled.

Describe alternatives you've considered

No response

Additional context

No response

What happened?

System configured in evening, VE.Direct cable connected to MPPT 450/100 with standard pin out, directly received data with correct Serial Number, Battery Voltage, Yield today and further.
In the morning, system stopped updating values. Data Age continually increasing. Despite any fault finding on cables. No change.
System started working again after complete sunset in evening. Fault reproduced itself following two days.

To Reproduce Bug

Connect MPPT 450/100 through VE.Direct cable, while system is producing power.

Expected Behavior

Data should continue to be updated when MPPT producing power.

Install Method

Self-Compiled

What git-hash/version of OpenDTU?

1a0f44d

Relevant log/trace output

No output from VE.Direct is given to virtual console  :(

Anything else?

Suspecting data format not handled correctly when certain values != 0.
Would be good if Virtual Console included Data Stream from VE.Direct similar to Fetch Inverter data.