Esp32 restart by activating VE direkt option #481
Comments
|
Did it work before upgrading? And did you correctly define the GPIO Pins for your Victron devices? Could you share your pin mapping here? |
|
Also please capture the device's UART output (using USB and your computer) when the device starts or when it produces the error and share the output. |
|
I use the version from 21.6.2023 because the GPIO for the victron is correctly specified there. I cannot edit the old PinMapping.json file because something is wrong with the formatting. I don't know how to create a new PinMapping.json, I'm not that experienced. Is there a PinMapping.json file somewhere for download? Sorry for the long text |
|
You could go to Settings -> Config Management with the newest version and select pin_mapping.json at the top from the drop-down list. You can download a working file with Backup then. Then try to edit this file and restore it. |
|
Ok thanks for the info. Does the esp32 crash because no GPIO pins are assigned for the victron? |
|
I have tried it with the latest firmware , there is no PinMapping.json to find only a config.jason I use a ESP32-WROOM-32 board from AZ-Delivery with the yellow headerpins...so far without problems have 3 pieces with all the same problem... Oh I used the opendtu on battery generic.bin |
|
With the previous version 2023.09.28 ( f0a55ea). |
|
The version from 2023.09.19 (ae39232) runs without crashing when activating the VE.direct function... Nu unfortunately I am missing the pinmapping.jason...It does not exist in any of the 3 last version...only the config.jason |
|
Are you sure? Please see the following screenshot on how to select the pin_mapping.json to backup: |
|
Yes i am sure |
|
This is my ESP32 Board |
|
This board is the same problem it crash wenn activat VE.direct option..and the pin mapping is also missing |
|
Some clarification: The Two things should happen: |
|
Ok thanks for the info The current firmware crashes as soon as I enable VE.direct option, after the ESP32 is rebooted this function is disabled again, so there seems to be an error I will have a look at creating a PinMapping.json file then the victron should run again. |
|
Ah, thanks @schlimmchen . Honestly I was not aware that the pin_mapping.json is not created on a fresh install. But this also means that that the default the default setting is indeed -1 for the Victron rx and tx. This can very well lead to a crash when initialising the VE.Direct option (for a MPPT Charger). Activating VE.Direct without specifying the correct GPIO-Pins (or at least the rx pin) makes no sense at moment. You have to define it by uploading a corresponding pin_mapping.json file. |
|
Ok guys problem solved it was fact of not existing PinMapping.jason that's why the new firmware crashes. I was just too stupid to create the pinmapping :-) Topic can be closed Thanks for your great help |
|
Nice that you got it working again.
You're welcome. However, please re-open the issue. The software must not crash if the |
|
Ok have opened it again. Am so happy that I got it done thanks to your help...Was forever on the version of 21.6.2023 because of the PinMapping.json did not know how to create it;-) Theme is open again |
|
I was able to reproduce this:
It seems to be a The problem is this: VE.Direct MPPT controller is not initialized as the pin config is invalid. However, as soon as VE.Direct is enabled, the MPPT controller In my opinion, this should be solved like this: Similar to Let's see if this works out, I'll start working on this and I'll open a pull request. |
|
A alternative quick fix would be to add something like this at the beginning of But your solution is obviously much cleaner and provides a good basis for multiple instances of |
|
Yes, that would probably be sufficient. Such a patch, however, ignores that the design is broken, only addressing symptoms. I have a draft ready, I know that it solves the issue at hand, and it prepares for support of multiple MPPT, but I have to test it thoroughly. |
|
Same problem for me... |
this solves a design issue where the loop() method of a static instance of VeDirectMpptController, which is part of library code, is called as part of the main loop() implementation. that is a problem because the call to this loop() must be handled differently from all other calls: the lib does not know whether or not the feature is enabled at all. also, the instance would not be initialized when enabling the feature during normal operation. that would even lead to a nullptr exception since the pointer to the serial implementation is still uninitialized. this new intermediate class is implemented with the support for multiple Victron charge controllers in mind. adding support for more charge controllers should be more viable than ever. fixes hoylabs#481. related to hoylabs#397 hoylabs#129.
this solves a design issue where the loop() method of a static instance of VeDirectMpptController, which is part of library code, is called as part of the main loop() implementation. that is a problem because the call to this loop() must be handled differently from all other calls: the lib does not know whether or not the feature is enabled at all. also, the instance would not be initialized when enabling the feature during normal operation. that would even lead to a nullptr exception since the pointer to the serial implementation is still uninitialized. this new intermediate class is implemented with the support for multiple Victron charge controllers in mind. adding support for more charge controllers should be more viable than ever. fixes hoylabs#481. related to hoylabs#397 hoylabs#129.
this solves a design issue where the loop() method of a static instance of VeDirectMpptController, which is part of library code, is called as part of the main loop() implementation. that is a problem because the call to this loop() must be handled differently from all other calls: the lib does not know whether or not the feature is enabled at all. also, the instance would not be initialized when enabling the feature during normal operation. that would even lead to a nullptr exception since the pointer to the serial implementation is still uninitialized. this new intermediate class is implemented with the support for multiple Victron charge controllers in mind. adding support for more charge controllers should be more viable than ever. fixes hoylabs#481. related to hoylabs#397 hoylabs#129.
this solves a design issue where the loop() method of a static instance of VeDirectMpptController, which is part of library code, is called as part of the main loop() implementation. that is a problem because the call to this loop() must be handled differently from all other calls: the lib does not know whether or not the feature is enabled at all. also, the instance would not be initialized when enabling the feature during normal operation. that would even lead to a nullptr exception since the pointer to the serial implementation is still uninitialized. this new intermediate class is implemented with the support for multiple Victron charge controllers in mind. adding support for more charge controllers should be more viable than ever. fixes hoylabs#481. related to hoylabs#397 hoylabs#129.
|
See #505 (one aspect of that PR is fixing this issue by addressing the underlying design issue). |
…es (#505) * introduce VictronMpptClass this solves a design issue where the loop() method of a static instance of VeDirectMpptController, which is part of library code, is called as part of the main loop() implementation. that is a problem because the call to this loop() must be handled differently from all other calls: the lib does not know whether or not the feature is enabled at all. also, the instance would not be initialized when enabling the feature during normal operation. that would even lead to a nullptr exception since the pointer to the serial implementation is still uninitialized. this new intermediate class is implemented with the support for multiple Victron charge controllers in mind. adding support for more charge controllers should be more viable than ever. fixes #481. related to #397 #129. * VE.Direct: move get.*AsString methods to respective structs those structs, which hold the data to be translated into strings, know best how to translate them. this change also simplifies access to those translation, as no parameter must be handed to the respective methods: they now act upon the data of the instance they are called for. adds constness to those methods. * VE.Direct: simplify and clean up get.*AsString methods use a map, which is much easier to maintain and which reads much easier. move the strings to flash memory to save RAM. * DPL: use VictronMpptClass::getPowerOutputWatts method remove redundant calculation of output power from DPL. consider separation of concern: VictronMpptClass will provide the total solar output power. the DPL shall not concern itself about how that value is calculated and it certainly should be unaware about how many MPPT charge controllers there actually are. * VE.Direct: avoid shadowing struct member "P" P was part of the base struct for both MPPT and SmartShunt controller. however, P was also part of the SmartShunt controller data struct, shadowing the member in the base struct. since P has slightly different meaning in MPPT versus SmartShunt, and since P is calculated for MPPT controllers but read from SmartShunts, P now lives in both derived structs, but not in the base struct. * VE.Direct: isDataValid(): avoid copying data structs pass a const reference to the base class implementation of isDataValid() rather than a copy of the whole struct. * VE.Direct: unify logging of text events * VE.Direct: stop processing text event if handled by base in case the base class processed a text event, do not try to match it against values that are only valid in the derived class -- none will match. * VE.Direct MPPT: manage data in a shared_ptr instead of handing out a reference to a struct which is part of a class instance that may disappear, e.g., on a config change, we now manage the lifetime of said data structure using a shared_ptr and hand out copies of that shared_ptr. this makes sure that users have a valid copy of the data as long as they hold the shared_ptr. * VE.Direct MPPT: implement getDataAgeMillis() this works even if millis() wraps around. * VE.Direct: process frame end event only for valid frames save a parameters, save a level of indention, save a function call for invalid frames.
…es (hoylabs#505) * introduce VictronMpptClass this solves a design issue where the loop() method of a static instance of VeDirectMpptController, which is part of library code, is called as part of the main loop() implementation. that is a problem because the call to this loop() must be handled differently from all other calls: the lib does not know whether or not the feature is enabled at all. also, the instance would not be initialized when enabling the feature during normal operation. that would even lead to a nullptr exception since the pointer to the serial implementation is still uninitialized. this new intermediate class is implemented with the support for multiple Victron charge controllers in mind. adding support for more charge controllers should be more viable than ever. fixes hoylabs#481. related to hoylabs#397 hoylabs#129. * VE.Direct: move get.*AsString methods to respective structs those structs, which hold the data to be translated into strings, know best how to translate them. this change also simplifies access to those translation, as no parameter must be handed to the respective methods: they now act upon the data of the instance they are called for. adds constness to those methods. * VE.Direct: simplify and clean up get.*AsString methods use a map, which is much easier to maintain and which reads much easier. move the strings to flash memory to save RAM. * DPL: use VictronMpptClass::getPowerOutputWatts method remove redundant calculation of output power from DPL. consider separation of concern: VictronMpptClass will provide the total solar output power. the DPL shall not concern itself about how that value is calculated and it certainly should be unaware about how many MPPT charge controllers there actually are. * VE.Direct: avoid shadowing struct member "P" P was part of the base struct for both MPPT and SmartShunt controller. however, P was also part of the SmartShunt controller data struct, shadowing the member in the base struct. since P has slightly different meaning in MPPT versus SmartShunt, and since P is calculated for MPPT controllers but read from SmartShunts, P now lives in both derived structs, but not in the base struct. * VE.Direct: isDataValid(): avoid copying data structs pass a const reference to the base class implementation of isDataValid() rather than a copy of the whole struct. * VE.Direct: unify logging of text events * VE.Direct: stop processing text event if handled by base in case the base class processed a text event, do not try to match it against values that are only valid in the derived class -- none will match. * VE.Direct MPPT: manage data in a shared_ptr instead of handing out a reference to a struct which is part of a class instance that may disappear, e.g., on a config change, we now manage the lifetime of said data structure using a shared_ptr and hand out copies of that shared_ptr. this makes sure that users have a valid copy of the data as long as they hold the shared_ptr. * VE.Direct MPPT: implement getDataAgeMillis() this works even if millis() wraps around. * VE.Direct: process frame end event only for valid frames save a parameters, save a level of indention, save a function call for invalid frames.
…es (hoylabs#505) * introduce VictronMpptClass this solves a design issue where the loop() method of a static instance of VeDirectMpptController, which is part of library code, is called as part of the main loop() implementation. that is a problem because the call to this loop() must be handled differently from all other calls: the lib does not know whether or not the feature is enabled at all. also, the instance would not be initialized when enabling the feature during normal operation. that would even lead to a nullptr exception since the pointer to the serial implementation is still uninitialized. this new intermediate class is implemented with the support for multiple Victron charge controllers in mind. adding support for more charge controllers should be more viable than ever. fixes hoylabs#481. related to hoylabs#397 hoylabs#129. * VE.Direct: move get.*AsString methods to respective structs those structs, which hold the data to be translated into strings, know best how to translate them. this change also simplifies access to those translation, as no parameter must be handed to the respective methods: they now act upon the data of the instance they are called for. adds constness to those methods. * VE.Direct: simplify and clean up get.*AsString methods use a map, which is much easier to maintain and which reads much easier. move the strings to flash memory to save RAM. * DPL: use VictronMpptClass::getPowerOutputWatts method remove redundant calculation of output power from DPL. consider separation of concern: VictronMpptClass will provide the total solar output power. the DPL shall not concern itself about how that value is calculated and it certainly should be unaware about how many MPPT charge controllers there actually are. * VE.Direct: avoid shadowing struct member "P" P was part of the base struct for both MPPT and SmartShunt controller. however, P was also part of the SmartShunt controller data struct, shadowing the member in the base struct. since P has slightly different meaning in MPPT versus SmartShunt, and since P is calculated for MPPT controllers but read from SmartShunts, P now lives in both derived structs, but not in the base struct. * VE.Direct: isDataValid(): avoid copying data structs pass a const reference to the base class implementation of isDataValid() rather than a copy of the whole struct. * VE.Direct: unify logging of text events * VE.Direct: stop processing text event if handled by base in case the base class processed a text event, do not try to match it against values that are only valid in the derived class -- none will match. * VE.Direct MPPT: manage data in a shared_ptr instead of handing out a reference to a struct which is part of a class instance that may disappear, e.g., on a config change, we now manage the lifetime of said data structure using a shared_ptr and hand out copies of that shared_ptr. this makes sure that users have a valid copy of the data as long as they hold the shared_ptr. * VE.Direct MPPT: implement getDataAgeMillis() this works even if millis() wraps around. * VE.Direct: process frame end event only for valid frames save a parameters, save a level of indention, save a function call for invalid frames.
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns. |
What happened?
With the new firmware my ESP32 BOARD restart (reset) when activated the VE direkt option ...i canot activat this funktion.
To Reproduce Bug
Activate VEDirekt option
Expected Behavior
No resett device by activating VE direkt option
Install Method
Pre-Compiled binary from GitHub
What git-hash/version of OpenDTU?
4324ae3
Relevant log/trace output
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: