[Ovmsdev] Time for 3.2.003? / Issue #241

[Michael Balzer]

Ooops, the toolkit link hash got lost: https://github.com/espressif/esp-idf/issues/2892#issuecomment-525286663


Am 04.09.19 um 11:47 schrieb Michael Balzer:
> Steve,
>
> I meanwhile use toolkit -98 along with the new libs provided here:  https://github.com/espressif/esp-idf/issues/2892
>
> …plus the (not yet checked in) volatile patch described here: https://github.com/espressif/esp-idf/issues/2892#issuecomment-525697255
>
> To use the new libs I replaced (symlinked) the respective files in xtensa-esp32-elf/sysroot/lib/esp32-psram by those from the zip.
>
> Then checkout and build on our branch "spiram-fix-test".
>
> Regards,
> Michael
>
>
> Am 04.09.19 um 07:04 schrieb Stephen Casner:
>> Michael,
>>
>> I have not built the OVMS software in a while, so I need to update to
>> the current esp-idf, which I have done by the steps you prescribed a
>> while back.  But you also recommend the -93 toolchain; I currently
>> have -80 installed.  Where can I find the -93 tarball?  Google didn't
>> answer that question.
>>
>>                                                         -- Steve
>>
>> On Tue, 3 Sep 2019, Michael Balzer wrote:
>>
>>> Everyone,
>>>
>>> I've pushed a change that needs some testing.
>>>
>>> I had the issue myself now parking at a certain distance from my garage wifi AP, i.e. on the edge of "in", after wifi had been disconnected for some hours, and
>>> with the module still connected via modem. The wifi blob had been trying to connect to the AP for about two hours.
>>>
>>> As seen before, the module saw no error, just the server responses and commands stopped coming in. I noticed the default interface was still "st1" despite wifi
>>> having been disconnected and modem connected. The DNS was also still configured for my wifi network, and the interface seemed to have an IP address -- but
>>> wasn't pingable from the wifi network.
>>>
>>> A power cycle of the modem solved the issue without reboot. So the cause may be in the modem/ppp subsystem, or it may be related (in some weird way) to the
>>> default interface / DNS setup.
>>>
>>> More tests showed the default interface again/still got set by the wifi blob itself at some point, overriding our modem prioritization. The events we didn't
>>> handle up to now were "sta.connected" and "sta.lostip", so I added these, and the bug didn't show up again since then. That doesn't mean anything, so we need to
>>> test this.
>>>
>>> The default interface really shouldn't affect inbound packet routing of an established connection, but there always may be strange bugs lurking in those libs.
>>>
>>> The change also reimplements the wifi signal strength reading, as the tests also showed that still wasn't working well using the CSI callback. It now seems to
>>> be much more reliable.
>>>
>>> Please test & report. The single module will be hard to test, as the bug isn't reproducable easily, but you can still try if wifi / modem transitions work well.
>>>
>>> Mark, you can check your server logs for history messages with ridiculous time offsets:
>>>
>>>     [sddexter at ns27 server]$ cat log-20190903 | egrep "rx msg h [0-9]+,-[0-9]{4}" | wc -l
>>>     455283
>>>
>>> The bug now severely affects the V2 server performance, as the server is single threaded and doesn't scale very well to this kind of bulk data bursts,
>>> especially when coming from multiple modules in parallel. So we really need to solve this now. Slow reactions or connection drops from my server lately have
>>> been due to this bug. If this change doesn't solve it, we'll need to add some reboot trigger on "too many server v2 notification retransmissions" -- or maybe a
>>> modem power cycle will do, that wouldn't discard the data.
>>>
>>> Thanks,
>>> Michael
>>>
>>>
>>> Am 03.09.19 um 07:46 schrieb Mark Webb-Johnson:
>>>> No problem. We can hold. I won't commit anything for the next few days (and agree to hold-off on Markos's pull). Let me know when you are ready.
>>>>
>>>> Regards, Mark.
>>>>
>>>>> On 3 Sep 2019, at 1:58 AM, Michael Balzer <dexter at expeedo.de> wrote:
>>>>>
>>>>> Mark, please wait.
>>>>>
>>>>> I may just have found the cause for issue #241, or at least something I need to investigate before releasing.
>>>>>
>>>>> I need to dig into my logs first, and try something.
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> Am 02.09.19 um 12:23 schrieb Michael Balzer:
>>>>>> Nothing open from my side at the moment.
>>>>>>
>>>>>> I haven't had the time to look in to Markos pull request, but from a first check also think that's going too deep to be included in this release.
>>>>>>
>>>>>> Regards,
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>> Am 02.09.19 um 04:15 schrieb Mark Webb-Johnson:
>>>>>>> I think it is well past time for a 3.2.003 release. Things seems table in edge (although some things only partially implemented).
>>>>>>>
>>>>>>> Anything people want to include at the last minute, or can we go ahead and build?
>>>>>>>
>>>>>>> Regards, Mark.
>>>>>>>


-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26