From kommykt at gmail.com  Mon Jun  1 23:30:22 2020
From: kommykt at gmail.com (=?UTF-8?B?VGFtw6FzIEtvdsOhY3M=?=)
Date: Mon, 1 Jun 2020 17:30:22 +0200
Subject: [Ovmsdev] Save Status
Message-ID: <CAGpaXUt_zdGjTLecuq+w5EVeG-JPMecFr3g8c8Hvo2vMvPOaTg@mail.gmail.com>

I would like to implement Save status to save / load value when module
crash. I copy kia_common.h/cpp and remove all code not relevant, added code
to vehicle_mitsubishi.h/cpp same as kia, but not restore the soc value.
If i check the saved file at web interface / editor has size 4, and if i
open it is empty.

Last time i saw the Trip power plugin do the same at my module, if
module restart no data in web interface. I think Trip power chart plugin
overwrite the datafile after reboot. Save data to SD card.

Any idea?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200601/47768bc9/attachment.html>

From egon at heuer-humfeld.de  Tue Jun  2 00:54:42 2020
From: egon at heuer-humfeld.de (Thomas Heuer)
Date: Mon, 01 Jun 2020 18:54:42 +0200
Subject: [Ovmsdev] Save Status
References: <CAGpaXUt_zdGjTLecuq+w5EVeG-JPMecFr3g8c8Hvo2vMvPOaTg@mail.gmail.com>
Message-ID: <31zq6x-xuiabq-r5kug56qo9dsnwsk0l309poo-h0n37t-syaiklhhx2mt81xbold276ln-68b9oi-l02l3g-4kod03-dh1jo7-quowgsjah2vu-tk4yeywpsf6idxjs43tqjnhe-u513syrerssq26289.1591030482404@email.android.com>

An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200601/56d8db97/attachment.html>

From shamziman at gmail.com  Tue Jun  2 01:58:40 2020
From: shamziman at gmail.com (Shaun Jurrens)
Date: Mon, 1 Jun 2020 19:58:40 +0200
Subject: [Ovmsdev] UserTrust/AddTrust/Comodo root CA expiration
In-Reply-To: <CC50B134-C817-469D-AFCA-4CB8E3929B3B@webb-johnson.net>
References: <CC50B134-C817-469D-AFCA-4CB8E3929B3B@webb-johnson.net>
Message-ID: <E905A327-6044-46D1-A3C7-1FCAB26D122D@gmail.com>

Hi,

I finally got my module in these Covid times (took 2 shipments and almost 3 months) and got it set up for the first time and after I got logged in via ssh, I also got the new certificate installed after a few minutes of orienting myself with the file system commands.  It might be worth mentioning that the ?trustedca? directory doesn?t actually exist by default.  So basically, you need to do:

OVMS# vfs mkdir /store/trustedca 

and then from a laptop terminal prompt:
scp -c aes128-cbc usertrust.crt omvs at 192.168.4.1:/store/trustedca/usertrust.crt 

I?m not sure if the cipher needs to be specified and the module seemed to need a reboot to read the certificate, but I then finally did get a connection.

There was still some noise from mongoose about SSL, but it didn?t seem to affect the v2 server connection.

Overall, it was pretty easy to setup and much more transparent than my old V2 module. I guess I should start looking at the Volt/Ampere code to see if this pre-heat option is real and app accessible.

Yada, yada,
Shaun
(via the iPad thingamajigg)

> On 31 May 2020, at 02:45, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> ?
> 
> The AddTrust root CA certificate that our api.openvehicles.com is signed by has expired (last night). This will impact TLS connections to api.openvehicles.com. Our certificate itself is fine (and doesn?t expire until Feb 2022), but the root cert is was signed by (via intermediaries) has expired.
> 
> Pretty irresponsible for AddTrust/UserTrust/Comodo to sign a certificate with a later expiration date than their own CA, imho. Also irresponsible for them not to inform the customers. Everybody can be expected to monitor their own certificate expiration date, but not that of their certificate authority.
> 
> I?ve been up most of the night dealing with fallout from this (in other work and customer related systems), so not happy.
> 
> Anyway, I?ve updated the trusted root certificate in edge now, and released that. AddTrust has become UserTrust.
> 
> To connect via tls to api.openvehicles.com now, you will either need to firmware update, or manually add the trusted ca to /store/trustedca/usertrust.crt (I have attached it here, for convenience).
> 
> I have also taken this opportunity to change the server v2 and v3 backoff retry times to 60 seconds (was 20 or 30).
> 
> Regards, Mark.
> 
> <usertrust.crt>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200601/1a5e87f3/attachment.html>

From kommykt at gmail.com  Fri Jun  5 11:25:15 2020
From: kommykt at gmail.com (=?UTF-8?B?VGFtw6FzIEtvdsOhY3M=?=)
Date: Fri, 5 Jun 2020 05:25:15 +0200
Subject: [Ovmsdev] Save Status
In-Reply-To: <31zq6x-xuiabq-r5kug56qo9dsnwsk0l309poo-h0n37t-syaiklhhx2mt81xbold276ln-68b9oi-l02l3g-4kod03-dh1jo7-quowgsjah2vu-tk4yeywpsf6idxjs43tqjnhe-u513syrerssq26289.1591030482404@email.android.com>
References: <CAGpaXUt_zdGjTLecuq+w5EVeG-JPMecFr3g8c8Hvo2vMvPOaTg@mail.gmail.com>
 <31zq6x-xuiabq-r5kug56qo9dsnwsk0l309poo-h0n37t-syaiklhhx2mt81xbold276ln-68b9oi-l02l3g-4kod03-dh1jo7-quowgsjah2vu-tk4yeywpsf6idxjs43tqjnhe-u513syrerssq26289.1591030482404@email.android.com>
Message-ID: <CAGpaXUsa=JpvPVrBToDUEb4X2SKF18r4Om8URtj19MvUaXkaHA@mail.gmail.com>

Thanks ! SmartED code works very well.

Thomas Heuer <egon at heuer-humfeld.de> ezt ?rta (id?pont: 2020. j?n. 1., H,
18:55):

> Look at the Smarted code vor save and restore status.
> The problem is, that the SD is mounted to late.
>
> Von meinem Huawei-Telefon gesendet
>
>
> -------- Urspr?ngliche Nachricht --------
> Von: Tam?s Kov?cs <kommykt at gmail.com>
> Datum: Mo., 1. Juni 2020, 17:30
> An: OVMS Developers <ovmsdev at lists.openvehicles.com>
> Betreff: [Ovmsdev] Save Status
>
> I would like to implement Save status to save / load value when module
> crash. I copy kia_common.h/cpp and remove all code not relevant, added code
> to vehicle_mitsubishi.h/cpp same as kia, but not restore the soc value.
> If i check the saved file at web interface / editor has size 4, and if i
> open it is empty.
>
> Last time i saw the Trip power plugin do the same at my module, if
> module restart no data in web interface. I think Trip power chart plugin
> overwrite the datafile after reboot. Save data to SD card.
>
> Any idea?
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>


-- 
?dv?zlettel:
Kov?cs Tam?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200605/6d857948/attachment.html>

From kommykt at gmail.com  Fri Jun  5 11:29:35 2020
From: kommykt at gmail.com (=?UTF-8?B?VGFtw6FzIEtvdsOhY3M=?=)
Date: Fri, 5 Jun 2020 05:29:35 +0200
Subject: [Ovmsdev] Random crash if enable notifications
Message-ID: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>

Some day's ago i enabled Pushover notifications and i get some crash after
that.

The crash backtrase is:
Backtrace: 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361
0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4
0x400f0db4 0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545
0x400f375e 0x400f37d5 0x400f37e5

a2l output is:

kommykt at MacBook-Air OVMS.V3 % a2l 0x4008b75f 0x4008b9f9 0x4010b253
0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1
0x400f0dbb 0x400f0db4 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109
0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5

Using elf file:
/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf


0x4008b75f is in invoke_abort
(/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).

151 #endif

152     while (1) {

153         if (esp_cpu_in_ocd_debug_mode()) {

154             __asm__ ("break 0,0");

155         }

156         *((int *) 0) = 0;

157     }

158 }

159

160 void abort()


0x4008b9f9 is in abort
(/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).

166     * don't overwrite that.

167     */

168     if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {

169         esp_reset_reason_set_hint(ESP_RST_PANIC);

170     }

171     invoke_abort();

172 }

173

174

175 static const char *edesc[] = {


0x4010b253 is in __assert_func
(../../../.././newlib/libc/stdlib/assert.c:63).


0x40098c5f is in multi_heap_free
(/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).

209         return;

210     }

211     multi_heap_internal_lock(heap);

212

213     poison_head_t *head = verify_allocated_region(p, true);

214     assert(head != NULL);

215

216     #ifdef SLOW

217     /* replace everything with FREE_FILL_PATTERN, including the poison
head/tail */

218     memset(head, FREE_FILL_PATTERN,


0x40084361 is in heap_caps_free
(/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).

263         ptr = (void *)dramAddrPtr[-1];

264     }

265

266     heap_t *heap = find_containing_heap(ptr);

267     assert(heap != NULL && "free() target pointer is outside heap
areas");

268     multi_heap_free(heap->heap, ptr);

269 }

270

271 IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)

272 {


0x40084945 is in _free_r
(/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).

37     return heap_caps_malloc_default( size );

38 }

39

40 void IRAM_ATTR _free_r(struct _reent *r, void* ptr)

41 {

42     heap_caps_free( ptr );

43 }

44

45 void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)

46 {


0x401c1181 is in operator delete(void*)
(/Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/del_op.cc:46).


0x400f01e1 is in std::_Rb_tree<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::_Select1st<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >
>::_M_drop_node(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >*)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110).

105       }

106

107       // __p is not permitted to be a null pointer.

108       void

109       deallocate(pointer __p, size_type)

110       { ::operator delete(__p); }

111

112       size_type

113       max_size() const _GLIBCXX_USE_NOEXCEPT

114       { return size_t(-1) / sizeof(_Tp); }


0x400f0dbb is in std::_Rb_tree<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::_Select1st<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >
>::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >*)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1614).

1609       // Erase without rebalancing.

1610       while (__x != 0)

1611 {

1612   _M_erase(_S_right(__x));

1613   _Link_type __y = _S_left(__x);

1614   _M_drop_node(__x);

1615   __x = __y;

1616 }

1617     }

1618


0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::_Select1st<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >
>::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >*)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).

1607     _M_erase(_Link_type __x)

1608     {

1609       // Erase without rebalancing.

1610       while (__x != 0)

1611 {

1612   _M_erase(_S_right(__x));

1613   _Link_type __y = _S_left(__x);

1614   _M_drop_node(__x);

1615   __x = __y;

1616 }


0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::_Select1st<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >
>::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >*)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).

1607     _M_erase(_Link_type __x)

1608     {

1609       // Erase without rebalancing.

1610       while (__x != 0)

1611 {

1612   _M_erase(_S_right(__x));

1613   _Link_type __y = _S_left(__x);

1614   _M_drop_node(__x);

1615   __x = __y;

1616 }


0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::_Select1st<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >
>::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >*)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).

1607     _M_erase(_Link_type __x)

1608     {

1609       // Erase without rebalancing.

1610       while (__x != 0)

1611 {

1612   _M_erase(_S_right(__x));

1613   _Link_type __y = _S_left(__x);

1614   _M_drop_node(__x);

1615   __x = __y;

1616 }


0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::_Select1st<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >
>::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >*)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).

1607     _M_erase(_Link_type __x)

1608     {

1609       // Erase without rebalancing.

1610       while (__x != 0)

1611 {

1612   _M_erase(_S_right(__x));

1613   _Link_type __y = _S_left(__x);

1614   _M_drop_node(__x);

1615   __x = __y;

1616 }


0x40156109 is in Pushover::EventListener(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, void*)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:858).

853

854       _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a);

855 #endif

856

857       ~_Rb_tree() _GLIBCXX_NOEXCEPT

858       { _M_erase(_M_begin()); }

859

860       _Rb_tree&

861       operator=(const _Rb_tree& __x);

862


0x401550da is in std::_Function_handler<void
(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, void*), std::_Bind<std::_Mem_fn<void
(Pushover::*)(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, void*)> (Pushover*, std::_Placeholder<1>,
std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >&&, void*&&)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600).

595       template<typename... _Args, typename _Req

596               = _Require<typename _Traits::__lvalue,

597                           _CheckArgs<_Pack<_Args...>>>>

598 result_type

599 operator()(_Class* __object, _Args&&... __args) const

600 { return (__object->*_M_pmf)(std::forward<_Args>(__args)...); }

601

602       // Handle smart pointers, references and pointers to derived

603       template<typename _Tp, typename... _Args, typename _Req

604               = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*, _Tp>,


0x400f3545 is in std::function<void (std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
void*)>::operator()(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, void*) const
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271).

2266     function<_Res(_ArgTypes...)>::

2267     operator()(_ArgTypes... __args) const

2268     {

2269       if (_M_empty())

2270 __throw_bad_function_call();

2271       return _M_invoker(_M_functor,
std::forward<_ArgTypes>(__args)...);

2272     }

2273

2274 #if __cpp_rtti

2275   template<typename _Res, typename... _ArgTypes>


0x400f375e is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*)
(/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:234).

229       {

230       for (EventCallbackList::iterator itc=el->begin(); itc!=el->end();
++itc)

231         {

232         m_current_started = monotonictime;

233         m_current_callback = *itc;

234         m_current_callback->m_callback(m_current_event,
msg->body.signal.data);

235         m_current_callback = NULL;

236         }

237       }

238     }


0x400f37d5 is in OvmsEvents::EventTask()
(/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:185).

180       switch(msg.type)

181         {

182         case EVENT_none:

183           break;

184         case EVENT_signal:

185           HandleQueueSignalEvent(&msg);

186           break;

187         default:

188           break;

189         }


0x400f37e5 is in EventLaunchTask(void*)
(/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:56).

51

52 void EventLaunchTask(void *pvParameters)

53   {

54   OvmsEvents* me = (OvmsEvents*)pvParameters;

55

56   me->EventTask();

57   }

58

59 void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand* cmd,
int argc, const char* const* argv)

60   {

-- 
?dv?zlettel:
Kov?cs Tam?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200605/3d5ead2b/attachment-0001.html>

From dexter at expeedo.de  Fri Jun  5 12:57:10 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Fri, 5 Jun 2020 06:57:10 +0200
Subject: [Ovmsdev] Random crash if enable notifications
In-Reply-To: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>
References: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>
Message-ID: <3ce6a6e3-8119-f123-296c-653ba3e258b4@expeedo.de>

Tam?s,

that doesn't need to be related to the pushover code. Do you run the spiram fix? I had this kind of heap corruption crashes frequently on builds without the
spiram fix but not once with the fix.

Regards,
Michael


Am 05.06.20 um 05:29 schrieb Tam?s Kov?cs:
> Some day's ago i enabled Pushover notifications and i get some crash after that.
>
> The crash backtrase?is:?
> Backtrace: 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4 0x400f0db4 0x400f0db4
> 0x400f0db4 0x40156109 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
> a2l output is:
>
> kommykt at MacBook-Air OVMS.V3 % a2l 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4
> 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>
> Using elf file: /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>
>
> 0x4008b75f is in invoke_abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>
> 151#endif
>
> 152? ? while (1) {
>
> 153? ? ? ? if (esp_cpu_in_ocd_debug_mode()) {
>
> 154? ? ? ? ? ? __asm__ ("break 0,0");
>
> 155? ? ? ? }
>
> 156? ? ? ? *((int *) 0) = 0;
>
> 157? ? }
>
> 158}
>
> 159
>
> 160void abort()
>
>
> 0x4008b9f9 is in abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>
> 166? ? * don't overwrite that.
>
> 167? ? */
>
> 168? ? if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>
> 169? ? ? ? esp_reset_reason_set_hint(ESP_RST_PANIC);
>
> 170? ? }
>
> 171? ? invoke_abort();
>
> 172}
>
> 173
>
> 174
>
> 175static const char *edesc[] = {
>
>
> 0x4010b253 is in __assert_func (../../../.././newlib/libc/stdlib/assert.c:63).
>
>
> 0x40098c5f is in multi_heap_free (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>
> 209? ? ? ? return;
>
> 210? ? }
>
> 211? ? multi_heap_internal_lock(heap);
>
> 212
>
> 213? ? poison_head_t *head = verify_allocated_region(p, true);
>
> 214? ? assert(head != NULL);
>
> 215
>
> 216? ? #ifdef SLOW
>
> 217? ? /* replace everything with FREE_FILL_PATTERN, including the poison head/tail */
>
> 218? ? memset(head, FREE_FILL_PATTERN,
>
>
> 0x40084361 is in heap_caps_free (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>
> 263? ? ? ? ptr = (void *)dramAddrPtr[-1];
>
> 264? ? }
>
> 265
>
> 266? ? heap_t *heap = find_containing_heap(ptr);
>
> 267? ? assert(heap != NULL && "free() target pointer is outside heap areas");
>
> 268? ? multi_heap_free(heap->heap, ptr);
>
> 269}
>
> 270
>
> 271IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>
> 272{
>
>
> 0x40084945 is in _free_r (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>
> 37? ? return heap_caps_malloc_default( size );
>
> 38}
>
> 39
>
> 40void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>
> 41{
>
> 42? ? heap_caps_free( ptr );
>
> 43}
>
> 44
>
> 45void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>
> 46{
>
>
> 0x401c1181 is in operator delete(void*) (/Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/del_op.cc:46).
>
>
> 0x400f01e1 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > >::_M_drop_node(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110).
>
> 105? ? ? }
>
> 106
>
> 107? ? ? // __p is not permitted to be a null pointer.
>
> 108? ? ? void
>
> 109? ? ? deallocate(pointer __p, size_type)
>
> 110? ? ? { ::operator delete(__p); }
>
> 111
>
> 112? ? ? size_type
>
> 113? ? ? max_size() const _GLIBCXX_USE_NOEXCEPT
>
> 114? ? ? { return size_t(-1) / sizeof(_Tp); }
>
>
> 0x400f0dbb is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1614).
>
> 1609? ? ? // Erase without rebalancing.
>
> 1610? ? ? while (__x != 0)
>
> 1611{
>
> 1612? _M_erase(_S_right(__x));
>
> 1613? _Link_type __y = _S_left(__x);
>
> 1614? _M_drop_node(__x);
>
> 1615? __x = __y;
>
> 1616}
>
> 1617? ? }
>
> 1618
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607? ? _M_erase(_Link_type __x)
>
> 1608? ? {
>
> 1609? ? ? // Erase without rebalancing.
>
> 1610? ? ? while (__x != 0)
>
> 1611{
>
> 1612? _M_erase(_S_right(__x));
>
> 1613? _Link_type __y = _S_left(__x);
>
> 1614? _M_drop_node(__x);
>
> 1615? __x = __y;
>
> 1616}
>
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607? ? _M_erase(_Link_type __x)
>
> 1608? ? {
>
> 1609? ? ? // Erase without rebalancing.
>
> 1610? ? ? while (__x != 0)
>
> 1611{
>
> 1612? _M_erase(_S_right(__x));
>
> 1613? _Link_type __y = _S_left(__x);
>
> 1614? _M_drop_node(__x);
>
> 1615? __x = __y;
>
> 1616}
>
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607? ? _M_erase(_Link_type __x)
>
> 1608? ? {
>
> 1609? ? ? // Erase without rebalancing.
>
> 1610? ? ? while (__x != 0)
>
> 1611{
>
> 1612? _M_erase(_S_right(__x));
>
> 1613? _Link_type __y = _S_left(__x);
>
> 1614? _M_drop_node(__x);
>
> 1615? __x = __y;
>
> 1616}
>
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607? ? _M_erase(_Link_type __x)
>
> 1608? ? {
>
> 1609? ? ? // Erase without rebalancing.
>
> 1610? ? ? while (__x != 0)
>
> 1611{
>
> 1612? _M_erase(_S_right(__x));
>
> 1613? _Link_type __y = _S_left(__x);
>
> 1614? _M_drop_node(__x);
>
> 1615? __x = __y;
>
> 1616}
>
>
> 0x40156109 is in Pushover::EventListener(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:858).
>
> 853
>
> 854? ? ? _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a);
>
> 855#endif
>
> 856
>
> 857? ? ? ~_Rb_tree() _GLIBCXX_NOEXCEPT
>
> 858? ? ? { _M_erase(_M_begin()); }
>
> 859
>
> 860? ? ? _Rb_tree&
>
> 861? ? ? operator=(const _Rb_tree& __x);
>
> 862
>
> 0x401550da is in std::_Function_handler<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*),
> std::_Bind<std::_Mem_fn<void (Pushover::*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)> (Pushover*,
> std::_Placeholder<1>, std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>
> >&&, void*&&) (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600).
>
> 595? ? ? template<typename... _Args, typename _Req
>
> 596? ? ? ? ? ? ? = _Require<typename _Traits::__lvalue,
>
> 597? ? ? ? ? ? ? ? ? ? ? ? ? _CheckArgs<_Pack<_Args...>>>>
>
> 598result_type
>
> 599operator()(_Class* __object, _Args&&... __args) const
>
> 600{ return (__object->*_M_pmf)(std::forward<_Args>(__args)...); }
>
> 601
>
> 602? ? ? // Handle smart pointers, references and pointers to derived
>
> 603? ? ? template<typename _Tp, typename... _Args, typename _Req
>
> 604? ? ? ? ? ? ? = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*, _Tp>,
>
>
> 0x400f3545 is in std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
> void*)>::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) const
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271).
>
> 2266? ? function<_Res(_ArgTypes...)>::
>
> 2267? ? operator()(_ArgTypes... __args) const
>
> 2268? ? {
>
> 2269? ? ? if (_M_empty())
>
> 2270__throw_bad_function_call();
>
> 2271? ? ? return _M_invoker(_M_functor, std::forward<_ArgTypes>(__args)...);
>
> 2272? ? }
>
> 2273
>
> 2274#if __cpp_rtti
>
> 2275? template<typename _Res, typename... _ArgTypes>
>
>
> 0x400f375e is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*)
> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:234).
>
> 229? ? ? {
>
> 230? ? ? for (EventCallbackList::iterator itc=el->begin(); itc!=el->end(); ++itc)
>
> 231? ? ? ? {
>
> 232? ? ? ? m_current_started = monotonictime;
>
> 233? ? ? ? m_current_callback = *itc;
>
> 234? ? ? ? m_current_callback->m_callback(m_current_event, msg->body.signal.data);
>
> 235? ? ? ? m_current_callback = NULL;
>
> 236? ? ? ? }
>
> 237? ? ? }
>
> 238? ? }
>
>
> 0x400f37d5 is in OvmsEvents::EventTask() (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:185).
>
> 180? ? ? switch(msg.type)
>
> 181? ? ? ? {
>
> 182? ? ? ? case EVENT_none:
>
> 183? ? ? ? ? break;
>
> 184? ? ? ? case EVENT_signal:
>
> 185? ? ? ? ? HandleQueueSignalEvent(&msg);
>
> 186? ? ? ? ? break;
>
> 187? ? ? ? default:
>
> 188? ? ? ? ? break;
>
> 189? ? ? ? }
>
>
> 0x400f37e5 is in EventLaunchTask(void*) (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:56).
>
> 51
>
> 52void EventLaunchTask(void *pvParameters)
>
> 53? {
>
> 54? OvmsEvents* me = (OvmsEvents*)pvParameters;
>
> 55
>
> 56? me->EventTask();
>
> 57? }
>
> 58
>
> 59void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv)
>
> 60? {
>
>
> -- 
> ?dv?zlettel:
> Kov?cs Tam?s
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200605/345c162e/attachment-0001.html>

From mark at webb-johnson.net  Fri Jun  5 13:06:39 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Fri, 5 Jun 2020 13:06:39 +0800
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <97B46650-871C-40FF-B10E-A016963E0096@webb-johnson.net>
References: <97B46650-871C-40FF-B10E-A016963E0096@webb-johnson.net>
Message-ID: <2BC4ED11-7D86-4AB2-87AB-71D648318A3A@webb-johnson.net>

I have release this 3.2.013 to EAP.

Regards, Mark.

> On 31 May 2020, at 5:34 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> 
> Getting ready to release 3.2.013. I?ve tagged it, and built for api.openvehicles.com <http://api.openvehicles.com/> edge.
> 
> The main changes here are:
> 
> TPMS subsystem (including Tesla Roadster support with new optional K-line expansion board)
> Change to config for server.v2
> 
> For #2, I moved the server password from server.v2/password to password/server.v2, and made the server.v2 config parameter read-write. That better matches how server.v3 does it. The change is done via a config migration, so should be transparent.
> 
> Absent any issues, I plan to move to EAP early in the coming week.
> 
> Regards, Mark
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200605/f6576749/attachment.html>

From dexter at expeedo.de  Fri Jun  5 13:15:05 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Fri, 5 Jun 2020 07:15:05 +0200
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <2BC4ED11-7D86-4AB2-87AB-71D648318A3A@webb-johnson.net>
References: <97B46650-871C-40FF-B10E-A016963E0096@webb-johnson.net>
 <2BC4ED11-7D86-4AB2-87AB-71D648318A3A@webb-johnson.net>
Message-ID: <ae250edd-441b-a6a2-feb7-2871984ad940@expeedo.de>

Followed.

Regards,
Michael


Am 05.06.20 um 07:06 schrieb Mark Webb-Johnson:
> I have release this?3.2.013 to EAP.
>
> Regards, Mark.
>
>> On 31 May 2020, at 5:34 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>
>>
>> Getting ready to release 3.2.013. I?ve tagged it, and built for api.openvehicles.com <http://api.openvehicles.com/>?edge.
>>
>> The main changes here are:
>>
>>  1. TPMS subsystem (including Tesla Roadster support with new optional K-line expansion board)
>>  2. Change to config for server.v2
>>
>>
>> For #2, I moved the server password from server.v2/password to password/server.v2, and made the server.v2 config parameter read-write. That better matches
>> how server.v3 does it. The change is done via a config migration, so should be transparent.
>>
>> Absent any issues, I plan to move to EAP early in the coming week.
>>
>> Regards, Mark
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200605/56688b6a/attachment.html>

From casner at acm.org  Fri Jun  5 14:18:27 2020
From: casner at acm.org (Stephen Casner)
Date: Thu, 4 Jun 2020 23:18:27 -0700 (PDT)
Subject: [Ovmsdev] UserTrust/AddTrust/Comodo root CA expiration
In-Reply-To: <CC50B134-C817-469D-AFCA-4CB8E3929B3B@webb-johnson.net>
References: <CC50B134-C817-469D-AFCA-4CB8E3929B3B@webb-johnson.net>
Message-ID: <alpine.OSX.2.21.9999.2006042316290.59343@auge.attlocal.net>

Mark,

It appears that my email host, imap.sonic.net, was bit by the same
AddTrust root CA certificate expiration.  My email application just
complained.

                                                        -- Steve

On Sun, 31 May 2020, Mark Webb-Johnson wrote:

>
> The AddTrust root CA certificate that our api.openvehicles.com <http://api.openvehicles.com/> is signed by has expired (last night). This will impact TLS connections to api.openvehicles.com <http://api.openvehicles.com/>. Our certificate itself is fine (and doesn?t expire until Feb 2022), but the root cert is was signed by (via intermediaries) has expired.
>
> Pretty irresponsible for AddTrust/UserTrust/Comodo to sign a certificate with a later expiration date than their own CA, imho. Also irresponsible for them not to inform the customers. Everybody can be expected to monitor their own certificate expiration date, but not that of their certificate authority.
>
> I?ve been up most of the night dealing with fallout from this (in other work and customer related systems), so not happy.
>
> Anyway, I?ve updated the trusted root certificate in edge now, and released that. AddTrust has become UserTrust.
>
> To connect via tls to api.openvehicles.com <http://api.openvehicles.com/> now, you will either need to firmware update, or manually add the trusted ca to /store/trustedca/usertrust.crt (I have attached it here, for convenience).
>
> I have also taken this opportunity to change the server v2 and v3 backoff retry times to 60 seconds (was 20 or 30).
>
> Regards, Mark.

From kommykt at gmail.com  Sat Jun  6 02:04:09 2020
From: kommykt at gmail.com (=?UTF-8?B?VGFtw6FzIEtvdsOhY3M=?=)
Date: Fri, 5 Jun 2020 20:04:09 +0200
Subject: [Ovmsdev] Random crash if enable notifications
In-Reply-To: <3ce6a6e3-8119-f123-296c-653ba3e258b4@expeedo.de>
References: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>
 <3ce6a6e3-8119-f123-296c-653ba3e258b4@expeedo.de>
Message-ID: <CAGpaXUt0C_rv992y+bg7-wmD8wBZ_8g+hFoVndo7YL-xG8L3+A@mail.gmail.com>

i think i don't run spiram fix. How can i use it. I must check out branch
"spiram-fix-test"  to run spiram fix?

Michael Balzer <dexter at expeedo.de> ezt ?rta (id?pont: 2020. j?n. 5., P,
6:58):

> Tam?s,
>
> that doesn't need to be related to the pushover code. Do you run the
> spiram fix? I had this kind of heap corruption crashes frequently on builds
> without the spiram fix but not once with the fix.
>
> Regards,
> Michael
>
>
> Am 05.06.20 um 05:29 schrieb Tam?s Kov?cs:
>
> Some day's ago i enabled Pushover notifications and i get some crash after
> that.
>
> The crash backtrase is:
> Backtrace: 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361
> 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4
> 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545
> 0x400f375e 0x400f37d5 0x400f37e5
> a2l output is:
>
> kommykt at MacBook-Air OVMS.V3 % a2l 0x4008b75f 0x4008b9f9 0x4010b253
> 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1
> 0x400f0dbb 0x400f0db4 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109
> 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>
> Using elf file:
> /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>
>
> 0x4008b75f is in invoke_abort
> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>
> 151 #endif
>
> 152     while (1) {
>
> 153         if (esp_cpu_in_ocd_debug_mode()) {
>
> 154             __asm__ ("break 0,0");
>
> 155         }
>
> 156         *((int *) 0) = 0;
>
> 157     }
>
> 158 }
>
> 159
>
> 160 void abort()
>
>
> 0x4008b9f9 is in abort
> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>
> 166     * don't overwrite that.
>
> 167     */
>
> 168     if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>
> 169         esp_reset_reason_set_hint(ESP_RST_PANIC);
>
> 170     }
>
> 171     invoke_abort();
>
> 172 }
>
> 173
>
> 174
>
> 175 static const char *edesc[] = {
>
>
> 0x4010b253 is in __assert_func
> (../../../.././newlib/libc/stdlib/assert.c:63).
>
>
> 0x40098c5f is in multi_heap_free
> (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>
> 209         return;
>
> 210     }
>
> 211     multi_heap_internal_lock(heap);
>
> 212
>
> 213     poison_head_t *head = verify_allocated_region(p, true);
>
> 214     assert(head != NULL);
>
> 215
>
> 216     #ifdef SLOW
>
> 217     /* replace everything with FREE_FILL_PATTERN, including the
> poison head/tail */
>
> 218     memset(head, FREE_FILL_PATTERN,
>
>
> 0x40084361 is in heap_caps_free
> (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>
> 263         ptr = (void *)dramAddrPtr[-1];
>
> 264     }
>
> 265
>
> 266     heap_t *heap = find_containing_heap(ptr);
>
> 267     assert(heap != NULL && "free() target pointer is outside heap
> areas");
>
> 268     multi_heap_free(heap->heap, ptr);
>
> 269 }
>
> 270
>
> 271 IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>
> 272 {
>
>
> 0x40084945 is in _free_r
> (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>
> 37     return heap_caps_malloc_default( size );
>
> 38 }
>
> 39
>
> 40 void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>
> 41 {
>
> 42     heap_caps_free( ptr );
>
> 43 }
>
> 44
>
> 45 void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>
> 46 {
>
>
> 0x401c1181 is in operator delete(void*)
> (/Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/del_op.cc:46).
>
>
> 0x400f01e1 is in std::_Rb_tree<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >,
> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >
> >::_M_drop_node(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110).
>
> 105       }
>
> 106
>
> 107       // __p is not permitted to be a null pointer.
>
> 108       void
>
> 109       deallocate(pointer __p, size_type)
>
> 110       { ::operator delete(__p); }
>
> 111
>
> 112       size_type
>
> 113       max_size() const _GLIBCXX_USE_NOEXCEPT
>
> 114       { return size_t(-1) / sizeof(_Tp); }
>
>
> 0x400f0dbb is in std::_Rb_tree<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >,
> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >
> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1614).
>
> 1609       // Erase without rebalancing.
>
> 1610       while (__x != 0)
>
> 1611 {
>
> 1612   _M_erase(_S_right(__x));
>
> 1613   _Link_type __y = _S_left(__x);
>
> 1614   _M_drop_node(__x);
>
> 1615   __x = __y;
>
> 1616 }
>
> 1617     }
>
> 1618
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >,
> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >
> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607     _M_erase(_Link_type __x)
>
> 1608     {
>
> 1609       // Erase without rebalancing.
>
> 1610       while (__x != 0)
>
> 1611 {
>
> 1612   _M_erase(_S_right(__x));
>
> 1613   _Link_type __y = _S_left(__x);
>
> 1614   _M_drop_node(__x);
>
> 1615   __x = __y;
>
> 1616 }
>
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >,
> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >
> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607     _M_erase(_Link_type __x)
>
> 1608     {
>
> 1609       // Erase without rebalancing.
>
> 1610       while (__x != 0)
>
> 1611 {
>
> 1612   _M_erase(_S_right(__x));
>
> 1613   _Link_type __y = _S_left(__x);
>
> 1614   _M_drop_node(__x);
>
> 1615   __x = __y;
>
> 1616 }
>
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >,
> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >
> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607     _M_erase(_Link_type __x)
>
> 1608     {
>
> 1609       // Erase without rebalancing.
>
> 1610       while (__x != 0)
>
> 1611 {
>
> 1612   _M_erase(_S_right(__x));
>
> 1613   _Link_type __y = _S_left(__x);
>
> 1614   _M_drop_node(__x);
>
> 1615   __x = __y;
>
> 1616 }
>
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >,
> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >
> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607     _M_erase(_Link_type __x)
>
> 1608     {
>
> 1609       // Erase without rebalancing.
>
> 1610       while (__x != 0)
>
> 1611 {
>
> 1612   _M_erase(_S_right(__x));
>
> 1613   _Link_type __y = _S_left(__x);
>
> 1614   _M_drop_node(__x);
>
> 1615   __x = __y;
>
> 1616 }
>
>
> 0x40156109 is in Pushover::EventListener(std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >, void*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:858).
>
> 853
>
> 854       _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a);
>
> 855 #endif
>
> 856
>
> 857       ~_Rb_tree() _GLIBCXX_NOEXCEPT
>
> 858       { _M_erase(_M_begin()); }
>
> 859
>
> 860       _Rb_tree&
>
> 861       operator=(const _Rb_tree& __x);
>
> 862
>
> 0x401550da is in std::_Function_handler<void
> (std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >, void*), std::_Bind<std::_Mem_fn<void
> (Pushover::*)(std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >, void*)> (Pushover*, std::_Placeholder<1>,
> std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >&&, void*&&)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600).
>
> 595       template<typename... _Args, typename _Req
>
> 596               = _Require<typename _Traits::__lvalue,
>
> 597                           _CheckArgs<_Pack<_Args...>>>>
>
> 598 result_type
>
> 599 operator()(_Class* __object, _Args&&... __args) const
>
> 600 { return (__object->*_M_pmf)(std::forward<_Args>(__args)...); }
>
> 601
>
> 602       // Handle smart pointers, references and pointers to derived
>
> 603       template<typename _Tp, typename... _Args, typename _Req
>
> 604               = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*,
> _Tp>,
>
>
> 0x400f3545 is in std::function<void (std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >,
> void*)>::operator()(std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >, void*) const
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271).
>
> 2266     function<_Res(_ArgTypes...)>::
>
> 2267     operator()(_ArgTypes... __args) const
>
> 2268     {
>
> 2269       if (_M_empty())
>
> 2270 __throw_bad_function_call();
>
> 2271       return _M_invoker(_M_functor,
> std::forward<_ArgTypes>(__args)...);
>
> 2272     }
>
> 2273
>
> 2274 #if __cpp_rtti
>
> 2275   template<typename _Res, typename... _ArgTypes>
>
>
> 0x400f375e is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*)
> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:234).
>
> 229       {
>
> 230       for (EventCallbackList::iterator itc=el->begin();
> itc!=el->end(); ++itc)
>
> 231         {
>
> 232         m_current_started = monotonictime;
>
> 233         m_current_callback = *itc;
>
> 234         m_current_callback->m_callback(m_current_event,
> msg->body.signal.data);
>
> 235         m_current_callback = NULL;
>
> 236         }
>
> 237       }
>
> 238     }
>
>
> 0x400f37d5 is in OvmsEvents::EventTask()
> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:185).
>
> 180       switch(msg.type)
>
> 181         {
>
> 182         case EVENT_none:
>
> 183           break;
>
> 184         case EVENT_signal:
>
> 185           HandleQueueSignalEvent(&msg);
>
> 186           break;
>
> 187         default:
>
> 188           break;
>
> 189         }
>
>
> 0x400f37e5 is in EventLaunchTask(void*)
> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:56).
>
> 51
>
> 52 void EventLaunchTask(void *pvParameters)
>
> 53   {
>
> 54   OvmsEvents* me = (OvmsEvents*)pvParameters;
>
> 55
>
> 56   me->EventTask();
>
> 57   }
>
> 58
>
> 59 void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand* cmd,
> int argc, const char* const* argv)
>
> 60   {
>
> --
> ?dv?zlettel:
> Kov?cs Tam?s
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>


-- 
?dv?zlettel:
Kov?cs Tam?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200605/6567c531/attachment-0001.html>

From dexter at expeedo.de  Sat Jun  6 03:42:15 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Fri, 5 Jun 2020 21:42:15 +0200
Subject: [Ovmsdev] Random crash if enable notifications
In-Reply-To: <CAGpaXUt0C_rv992y+bg7-wmD8wBZ_8g+hFoVndo7YL-xG8L3+A@mail.gmail.com>
References: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>
 <3ce6a6e3-8119-f123-296c-653ba3e258b4@expeedo.de>
 <CAGpaXUt0C_rv992y+bg7-wmD8wBZ_8g+hFoVndo7YL-xG8L3+A@mail.gmail.com>
Message-ID: <9e727cb7-1042-202d-c80a-b44b1e1d2f67@expeedo.de>

See previous posts on this, you also need the fixed toolchain: https://github.com/espressif/esp-idf/issues/2892#issuecomment-501106283

Regards,
Michael


Am 05.06.20 um 20:04 schrieb Tam?s Kov?cs:
> i think i don't run spiram fix. How can i use it.?I must?check out branch "spiram-fix-test" ?to run spiram fix?
>
> Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> ezt ?rta (id?pont: 2020. j?n. 5., P, 6:58):
>
>     Tam?s,
>
>     that doesn't need to be related to the pushover code. Do you run the spiram fix? I had this kind of heap corruption crashes frequently on builds without
>     the spiram fix but not once with the fix.
>
>     Regards,
>     Michael
>
>
>     Am 05.06.20 um 05:29 schrieb Tam?s Kov?cs:
>>     Some day's ago i enabled Pushover notifications and i get some crash after that.
>>
>>     The crash backtrase?is:?
>>     Backtrace: 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4 0x400f0db4 0x400f0db4
>>     0x400f0db4 0x40156109 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>>     a2l output is:
>>
>>     kommykt at MacBook-Air OVMS.V3 % a2l 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb
>>     0x400f0db4 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>>
>>     Using elf file: /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>>
>>
>>     0x4008b75f is in invoke_abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>>
>>     151#endif
>>
>>     152? ? while (1) {
>>
>>     153? ? ? ? if (esp_cpu_in_ocd_debug_mode()) {
>>
>>     154? ? ? ? ? ? __asm__ ("break 0,0");
>>
>>     155? ? ? ? }
>>
>>     156? ? ? ? *((int *) 0) = 0;
>>
>>     157? ? }
>>
>>     158}
>>
>>     159
>>
>>     160void abort()
>>
>>
>>     0x4008b9f9 is in abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>>
>>     166? ? * don't overwrite that.
>>
>>     167? ? */
>>
>>     168? ? if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>>
>>     169? ? ? ? esp_reset_reason_set_hint(ESP_RST_PANIC);
>>
>>     170? ? }
>>
>>     171? ? invoke_abort();
>>
>>     172}
>>
>>     173
>>
>>     174
>>
>>     175static const char *edesc[] = {
>>
>>
>>     0x4010b253 is in __assert_func (../../../.././newlib/libc/stdlib/assert.c:63).
>>
>>
>>     0x40098c5f is in multi_heap_free (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>>
>>     209? ? ? ? return;
>>
>>     210? ? }
>>
>>     211? ? multi_heap_internal_lock(heap);
>>
>>     212
>>
>>     213? ? poison_head_t *head = verify_allocated_region(p, true);
>>
>>     214? ? assert(head != NULL);
>>
>>     215
>>
>>     216? ? #ifdef SLOW
>>
>>     217? ? /* replace everything with FREE_FILL_PATTERN, including the poison head/tail */
>>
>>     218? ? memset(head, FREE_FILL_PATTERN,
>>
>>
>>     0x40084361 is in heap_caps_free (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>>
>>     263? ? ? ? ptr = (void *)dramAddrPtr[-1];
>>
>>     264? ? }
>>
>>     265
>>
>>     266? ? heap_t *heap = find_containing_heap(ptr);
>>
>>     267? ? assert(heap != NULL && "free() target pointer is outside heap areas");
>>
>>     268? ? multi_heap_free(heap->heap, ptr);
>>
>>     269}
>>
>>     270
>>
>>     271IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>>
>>     272{
>>
>>
>>     0x40084945 is in _free_r (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>>
>>     37? ? return heap_caps_malloc_default( size );
>>
>>     38}
>>
>>     39
>>
>>     40void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>>
>>     41{
>>
>>     42? ? heap_caps_free( ptr );
>>
>>     43}
>>
>>     44
>>
>>     45void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>>
>>     46{
>>
>>
>>     0x401c1181 is in operator delete(void*) (/Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/del_op.cc:46).
>>
>>
>>     0x400f01e1 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>     std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >
>>     >::_M_drop_node(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110).
>>
>>     105? ? ? }
>>
>>     106
>>
>>     107? ? ? // __p is not permitted to be a null pointer.
>>
>>     108? ? ? void
>>
>>     109? ? ? deallocate(pointer __p, size_type)
>>
>>     110? ? ? { ::operator delete(__p); }
>>
>>     111
>>
>>     112? ? ? size_type
>>
>>     113? ? ? max_size() const _GLIBCXX_USE_NOEXCEPT
>>
>>     114? ? ? { return size_t(-1) / sizeof(_Tp); }
>>
>>
>>     0x400f0dbb is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>     std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >
>>     >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1614).
>>
>>     1609? ? ? // Erase without rebalancing.
>>
>>     1610? ? ? while (__x != 0)
>>
>>     1611{
>>
>>     1612? _M_erase(_S_right(__x));
>>
>>     1613? _Link_type __y = _S_left(__x);
>>
>>     1614? _M_drop_node(__x);
>>
>>     1615? __x = __y;
>>
>>     1616}
>>
>>     1617? ? }
>>
>>     1618
>>
>>     0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>     std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >
>>     >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>>     1607? ? _M_erase(_Link_type __x)
>>
>>     1608? ? {
>>
>>     1609? ? ? // Erase without rebalancing.
>>
>>     1610? ? ? while (__x != 0)
>>
>>     1611{
>>
>>     1612? _M_erase(_S_right(__x));
>>
>>     1613? _Link_type __y = _S_left(__x);
>>
>>     1614? _M_drop_node(__x);
>>
>>     1615? __x = __y;
>>
>>     1616}
>>
>>
>>     0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>     std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >
>>     >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>>     1607? ? _M_erase(_Link_type __x)
>>
>>     1608? ? {
>>
>>     1609? ? ? // Erase without rebalancing.
>>
>>     1610? ? ? while (__x != 0)
>>
>>     1611{
>>
>>     1612? _M_erase(_S_right(__x));
>>
>>     1613? _Link_type __y = _S_left(__x);
>>
>>     1614? _M_drop_node(__x);
>>
>>     1615? __x = __y;
>>
>>     1616}
>>
>>
>>     0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>     std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >
>>     >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>>     1607? ? _M_erase(_Link_type __x)
>>
>>     1608? ? {
>>
>>     1609? ? ? // Erase without rebalancing.
>>
>>     1610? ? ? while (__x != 0)
>>
>>     1611{
>>
>>     1612? _M_erase(_S_right(__x));
>>
>>     1613? _Link_type __y = _S_left(__x);
>>
>>     1614? _M_drop_node(__x);
>>
>>     1615? __x = __y;
>>
>>     1616}
>>
>>
>>     0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>     std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >
>>     >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>>     1607? ? _M_erase(_Link_type __x)
>>
>>     1608? ? {
>>
>>     1609? ? ? // Erase without rebalancing.
>>
>>     1610? ? ? while (__x != 0)
>>
>>     1611{
>>
>>     1612? _M_erase(_S_right(__x));
>>
>>     1613? _Link_type __y = _S_left(__x);
>>
>>     1614? _M_drop_node(__x);
>>
>>     1615? __x = __y;
>>
>>     1616}
>>
>>
>>     0x40156109 is in Pushover::EventListener(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:858).
>>
>>     853
>>
>>     854? ? ? _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a);
>>
>>     855#endif
>>
>>     856
>>
>>     857? ? ? ~_Rb_tree() _GLIBCXX_NOEXCEPT
>>
>>     858? ? ? { _M_erase(_M_begin()); }
>>
>>     859
>>
>>     860? ? ? _Rb_tree&
>>
>>     861? ? ? operator=(const _Rb_tree& __x);
>>
>>     862
>>
>>     0x401550da is in std::_Function_handler<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*),
>>     std::_Bind<std::_Mem_fn<void (Pushover::*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)> (Pushover*,
>>     std::_Placeholder<1>, std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&, std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> >&&, void*&&) (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600).
>>
>>     595? ? ? template<typename... _Args, typename _Req
>>
>>     596? ? ? ? ? ? ? = _Require<typename _Traits::__lvalue,
>>
>>     597? ? ? ? ? ? ? ? ? ? ? ? ? _CheckArgs<_Pack<_Args...>>>>
>>
>>     598result_type
>>
>>     599operator()(_Class* __object, _Args&&... __args) const
>>
>>     600{ return (__object->*_M_pmf)(std::forward<_Args>(__args)...); }
>>
>>     601
>>
>>     602? ? ? // Handle smart pointers, references and pointers to derived
>>
>>     603? ? ? template<typename _Tp, typename... _Args, typename _Req
>>
>>     604? ? ? ? ? ? ? = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*, _Tp>,
>>
>>
>>     0x400f3545 is in std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>     void*)>::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) const
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271).
>>
>>     2266? ? function<_Res(_ArgTypes...)>::
>>
>>     2267? ? operator()(_ArgTypes... __args) const
>>
>>     2268? ? {
>>
>>     2269? ? ? if (_M_empty())
>>
>>     2270__throw_bad_function_call();
>>
>>     2271? ? ? return _M_invoker(_M_functor, std::forward<_ArgTypes>(__args)...);
>>
>>     2272? ? }
>>
>>     2273
>>
>>     2274#if __cpp_rtti
>>
>>     2275? template<typename _Res, typename... _ArgTypes>
>>
>>
>>     0x400f375e is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*)
>>     (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:234).
>>
>>     229? ? ? {
>>
>>     230? ? ? for (EventCallbackList::iterator itc=el->begin(); itc!=el->end(); ++itc)
>>
>>     231? ? ? ? {
>>
>>     232? ? ? ? m_current_started = monotonictime;
>>
>>     233? ? ? ? m_current_callback = *itc;
>>
>>     234? ? ? ? m_current_callback->m_callback(m_current_event, msg->body.signal.data);
>>
>>     235? ? ? ? m_current_callback = NULL;
>>
>>     236? ? ? ? }
>>
>>     237? ? ? }
>>
>>     238? ? }
>>
>>
>>     0x400f37d5 is in OvmsEvents::EventTask() (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:185).
>>
>>     180? ? ? switch(msg.type)
>>
>>     181? ? ? ? {
>>
>>     182? ? ? ? case EVENT_none:
>>
>>     183? ? ? ? ? break;
>>
>>     184? ? ? ? case EVENT_signal:
>>
>>     185? ? ? ? ? HandleQueueSignalEvent(&msg);
>>
>>     186? ? ? ? ? break;
>>
>>     187? ? ? ? default:
>>
>>     188? ? ? ? ? break;
>>
>>     189? ? ? ? }
>>
>>
>>     0x400f37e5 is in EventLaunchTask(void*) (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:56).
>>
>>     51
>>
>>     52void EventLaunchTask(void *pvParameters)
>>
>>     53? {
>>
>>     54? OvmsEvents* me = (OvmsEvents*)pvParameters;
>>
>>     55
>>
>>     56? me->EventTask();
>>
>>     57? }
>>
>>     58
>>
>>     59void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv)
>>
>>     60? {
>>
>>
>>     -- 
>>     ?dv?zlettel:
>>     Kov?cs Tam?s
>>
>>
>>     _______________________________________________
>>     OvmsDev mailing list
>>     OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>     -- 
>     Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>     Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
>     _______________________________________________
>     OvmsDev mailing list
>     OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> -- 
> ?dv?zlettel:
> Kov?cs Tam?s
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200605/775b2b78/attachment-0001.html>

From leres at xse.com  Sun Jun  7 04:02:55 2020
From: leres at xse.com (Craig Leres)
Date: Sat, 6 Jun 2020 13:02:55 -0700
Subject: [Ovmsdev] Persistent metrics
In-Reply-To: <93BA45A0-4637-4B13-B1A9-24F5EDEDC3CB@webb-johnson.net>
References: <21eeed64-9ba4-4e5b-d550-b75cac5e0cef@gmail.com>
 <05748430-9C2F-4120-9140-6B79632B7B45@webb-johnson.net>
 <b01fb424-525d-f7ea-eb8a-3bd20828f768@gmail.com>
 <93BA45A0-4637-4B13-B1A9-24F5EDEDC3CB@webb-johnson.net>
Message-ID: <f5fe5127-8cb2-7555-b3be-24c6bcd1c627@xse.com>

On 2020-04-21 20:21, Mark Webb-Johnson wrote:
> There is a small amount of RTC ram that is retained through a reboot.
> Perhaps we could have a mechanism to save+restore certain metrics there?
> But not at all simple.

I figured out how to do this and implemented it with this pull request:


https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/377

The trick is the RTC_NOINIT_ATTR macro which places data into RTC slow
memory, in a memory section that is not initialized on boot:


https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/general-notes.html

There is a new persist argument that can be used when creating a metric:

    -  ms_v_bat_soc = new OvmsMetricFloat(MS_V_BAT_SOC, SM_STALE_HIGH,
Percentage);
    +  ms_v_bat_soc = new OvmsMetricFloat(MS_V_BAT_SOC, SM_STALE_HIGH,
Percentage, true);

This is only implemented for OvmsMetricFloat and I only enabled it for a
small set of metrics. "metrics persist" shows what's being saved, how
many bytes are in use, etc. (It just occurred to me it would be better
to add a flag to "metrics list" to only show persist metrics ...)

The changes solve my desire for v.b.soc to be visible in the app after a
reboot. I wanted to use it for v.p.direction but minor drifts in the
calculated gps position foil that. I enabled it for the tpms metrics but
since my cars don't have working tpms code even when I manually populate
values (e.g. "metrics set v.tp.fl.p 202.29") the app doesn't show them
because (I believe) they are stale.

I expect there are metrics you "big battery" guys will want to add. (And
it won't hurt my feelings if somebody completely rewrites this.)

		Craig

OVMS# metrics persist ?
Usage: metrics persist [-r]
OVMS# metrics persist
version                                  1
serial                                   2
size                                     340
slots used                               13 of 16
v.b.soc                                  82.0
v.b.temp                                 19.0
v.m.temp                                 0.0
v.e.temp                                 20.0
v.p.odometer                             0.0
v.tp.fl.t                                0.0
v.tp.fr.t                                0.0
v.tp.rr.t                                0.0
v.tp.rl.t                                0.0
v.tp.fl.p                                0.0
v.tp.fr.p                                0.0
v.tp.rr.p                                0.0
v.tp.rl.p                                0.0

From kommykt at gmail.com  Sun Jun  7 13:50:44 2020
From: kommykt at gmail.com (=?UTF-8?B?VGFtw6FzIEtvdsOhY3M=?=)
Date: Sun, 7 Jun 2020 07:50:44 +0200
Subject: [Ovmsdev] Random crash if enable notifications
In-Reply-To: <9e727cb7-1042-202d-c80a-b44b1e1d2f67@expeedo.de>
References: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>
 <3ce6a6e3-8119-f123-296c-653ba3e258b4@expeedo.de>
 <CAGpaXUt0C_rv992y+bg7-wmD8wBZ_8g+hFoVndo7YL-xG8L3+A@mail.gmail.com>
 <9e727cb7-1042-202d-c80a-b44b1e1d2f67@expeedo.de>
Message-ID: <CAGpaXUthOkR9BURwJaK1PmHMgDkL4pmXH9OThJSm8e2LTpy_QA@mail.gmail.com>

I downloaded this toolchain and use it: build idf v3.3-beta3-776-g3d198cd50
I checkout esp-idf to spiram-fix-test branch.

I use a forked repo.
I run the following to update to spiram-fix-test, on my local repo.
git fetch upstream
git pull upstream/spiram-fix-test master

But i now get crash the last is:
Last crash: abort() was called on core 1 Backtrace: 0x4008ace7 0x4008af7d
0x4010badf 0x40097d93 0x40083ffd 0x400845f1 0x4000bec7 0x4012c729
0x402a1815 0x401eb40d 0x401f7a26 0x401f8af0 0x40207065 0x40206f45
0x40207133 0x40206faf 0x402073b6 0x4020747d 0x401f4445 0x401f3344
0x401f3677 0x401f441e 0x402079d1 0x401f76e5 0x401f7892 0x40202ea6
0x4012db9a 0x4012dd9d

kommykt at MacBook-Air OVMS.V3 % a2l 0x4008ace7 0x4008af7d 0x4010badf
0x40097d93 0x40083ffd 0x400845f1 0x4000bec7 0x4012c729 0x402a1815
0x401eb40d 0x401f7a26 0x401f8af0 0x40207065 0x40206f45 0x40207133
0x40206faf 0x402073b6 0x4020747d 0x401f4445 0x401f3344 0x401f3677
0x401f441e 0x402079d1 0x401f76e5 0x401f7892 0x40202ea6 0x4012db9a 0x4012dd9d

Using elf file:
/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf

0x4008ace7 is in invoke_abort
(/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).

151 #endif

152     while (1) {

153         if (esp_cpu_in_ocd_debug_mode()) {

154             __asm__ ("break 0,0");

155         }

156         *((int *) 0) = 0;

157     }

158 }

159

160 void abort()

0x4008af7d is in abort
(/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).

166     * don't overwrite that.

167     */

168     if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {

169         esp_reset_reason_set_hint(ESP_RST_PANIC);

170     }

171     invoke_abort();

172 }

173

174

175 static const char *edesc[] = {

0x4010badf is in __assert_func
(../../../.././newlib/libc/stdlib/assert.c:63).

0x40097d93 is in multi_heap_free
(/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).

209         return;

210     }

211     multi_heap_internal_lock(heap);

212

213     poison_head_t *head = verify_allocated_region(p, true);

214     assert(head != NULL);

215

216     #ifdef SLOW

217     /* replace everything with FREE_FILL_PATTERN, including the poison
head/tail */

218     memset(head, FREE_FILL_PATTERN,

0x40083ffd is in heap_caps_free
(/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).

263         ptr = (void *)dramAddrPtr[-1];

264     }

265

266     heap_t *heap = find_containing_heap(ptr);

267     assert(heap != NULL && "free() target pointer is outside heap
areas");

268     multi_heap_free(heap->heap, ptr);

269 }

270

271 IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)

272 {

0x400845f1 is in _free_r
(/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).

37     return heap_caps_malloc_default( size );

38 }

39

40 void IRAM_ATTR _free_r(struct _reent *r, void* ptr)

41 {

42     heap_caps_free( ptr );

43 }

44

45 void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)

46 {

0x4012c729 is in DukOvmsFree(void*, void*)
(/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:442).

437   return ExternalRamRealloc(ptr, size);

438   }

439

440 void DukOvmsFree(void *udata, void *ptr)

441   {

442   free(ptr);

443   }

444

445 void DukOvmsFatalHandler(void *udata, const char *msg)

446   {

0x402a1815 is in duk_heap_mem_free (duk_heap_memory.c:406).

0x401eb40d is in duk__refcount_refzero_hstring (duk_heap_alloc.c:103).

0x401f7a26 is in duk_heaphdr_refzero (duk_heap_refcount.c:630).

0x401f8af0 is in duk_pop_2 (duk_api_stack.c:6089).

0x40207065 is in duk__enc_value (duk_bi_json.c:2240).

0x40206f45 is in duk__enc_value (duk_bi_json.c:1951).

1946 in duk_bi_json.c

0x40207133 is in duk__enc_object (duk_bi_json.c:1885).

1880 in duk_bi_json.c

0x40206faf is in duk__enc_value (duk_bi_json.c:2203).

2198 in duk_bi_json.c

0x402073b6 is in duk_bi_json_stringify_helper (duk_bi_json.c:3191).

3186 in duk_bi_json.c

0x4020747d is in duk_bi_duktape_object_enc (duk_bi_duktape.c:96).

0x401f4445 is in duk__handle_call_raw (duk_js_call.c:2276).

0x401f3344 is in duk__js_execute_bytecode_inner (duk_js_call.c:2422).

2417 in duk_js_call.c

0x401f3677 is in duk_js_execute_bytecode (duk_js_executor.c:2956).

0x401f441e is in duk__handle_call_raw (duk_js_call.c:2246).

0x402079d1 is in duk__pcall_method_raw (duk_js_call.c:2422).

2417 in duk_js_call.c

0x401f76e5 is in duk_handle_safe_call (duk_js_call.c:2475).

2470 in duk_js_call.c

0x401f7892 is in duk_safe_call (duk_api_call.c:318).

0x40202ea6 is in duk_pcall_method (duk_api_call.c:242).

237 in duk_api_call.c

0x4012db9a is in OvmsScripts::DukTapeTask()
(/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:2273).

2268             duk_get_global_string(m_dukctx, "PubSub");

2269             duk_get_prop_string(m_dukctx, -1, "publish");

2270             duk_dup(m_dukctx, -2);  /* this binding = process */

2271             duk_push_string(m_dukctx, msg.body.dt_event.name);

2272             duk_push_string(m_dukctx, "");

2273             if (duk_pcall_method(m_dukctx, 2) != 0)

2274               {

2275               DukOvmsErrorHandler(m_dukctx, -1);

2276               }

2277             duk_pop_2(m_dukctx);

0x4012dd9d is in DukTapeLaunchTask(void*)
(/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:427).

422

423 void DukTapeLaunchTask(void *pvParameters)

424   {

425   OvmsScripts* me = (OvmsScripts*)pvParameters;

426

427   me->DukTapeTask();

428   }

429

430 void* DukOvmsAlloc(void *udata, duk_size_t size)

431   {


Michael Balzer <dexter at expeedo.de> ezt ?rta (id?pont: 2020. j?n. 5., P,
21:43):

> See previous posts on this, you also need the fixed toolchain:
> https://github.com/espressif/esp-idf/issues/2892#issuecomment-501106283
>
> Regards,
> Michael
>
>
> Am 05.06.20 um 20:04 schrieb Tam?s Kov?cs:
>
> i think i don't run spiram fix. How can i use it. I must check out branch
> "spiram-fix-test"  to run spiram fix?
>
> Michael Balzer <dexter at expeedo.de> ezt ?rta (id?pont: 2020. j?n. 5., P,
> 6:58):
>
>> Tam?s,
>>
>> that doesn't need to be related to the pushover code. Do you run the
>> spiram fix? I had this kind of heap corruption crashes frequently on builds
>> without the spiram fix but not once with the fix.
>>
>> Regards,
>> Michael
>>
>>
>> Am 05.06.20 um 05:29 schrieb Tam?s Kov?cs:
>>
>> Some day's ago i enabled Pushover notifications and i get some crash
>> after that.
>>
>> The crash backtrase is:
>> Backtrace: 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361
>> 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4
>> 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545
>> 0x400f375e 0x400f37d5 0x400f37e5
>> a2l output is:
>>
>> kommykt at MacBook-Air OVMS.V3 % a2l 0x4008b75f 0x4008b9f9 0x4010b253
>> 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1
>> 0x400f0dbb 0x400f0db4 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109
>> 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>>
>> Using elf file:
>> /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>>
>>
>> 0x4008b75f is in invoke_abort
>> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>>
>> 151 #endif
>>
>> 152     while (1) {
>>
>> 153         if (esp_cpu_in_ocd_debug_mode()) {
>>
>> 154             __asm__ ("break 0,0");
>>
>> 155         }
>>
>> 156         *((int *) 0) = 0;
>>
>> 157     }
>>
>> 158 }
>>
>> 159
>>
>> 160 void abort()
>>
>>
>> 0x4008b9f9 is in abort
>> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>>
>> 166     * don't overwrite that.
>>
>> 167     */
>>
>> 168     if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>>
>> 169         esp_reset_reason_set_hint(ESP_RST_PANIC);
>>
>> 170     }
>>
>> 171     invoke_abort();
>>
>> 172 }
>>
>> 173
>>
>> 174
>>
>> 175 static const char *edesc[] = {
>>
>>
>> 0x4010b253 is in __assert_func
>> (../../../.././newlib/libc/stdlib/assert.c:63).
>>
>>
>> 0x40098c5f is in multi_heap_free
>> (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>>
>> 209         return;
>>
>> 210     }
>>
>> 211     multi_heap_internal_lock(heap);
>>
>> 212
>>
>> 213     poison_head_t *head = verify_allocated_region(p, true);
>>
>> 214     assert(head != NULL);
>>
>> 215
>>
>> 216     #ifdef SLOW
>>
>> 217     /* replace everything with FREE_FILL_PATTERN, including the
>> poison head/tail */
>>
>> 218     memset(head, FREE_FILL_PATTERN,
>>
>>
>> 0x40084361 is in heap_caps_free
>> (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>>
>> 263         ptr = (void *)dramAddrPtr[-1];
>>
>> 264     }
>>
>> 265
>>
>> 266     heap_t *heap = find_containing_heap(ptr);
>>
>> 267     assert(heap != NULL && "free() target pointer is outside heap
>> areas");
>>
>> 268     multi_heap_free(heap->heap, ptr);
>>
>> 269 }
>>
>> 270
>>
>> 271 IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>>
>> 272 {
>>
>>
>> 0x40084945 is in _free_r
>> (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>>
>> 37     return heap_caps_malloc_default( size );
>>
>> 38 }
>>
>> 39
>>
>> 40 void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>>
>> 41 {
>>
>> 42     heap_caps_free( ptr );
>>
>> 43 }
>>
>> 44
>>
>> 45 void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>>
>> 46 {
>>
>>
>> 0x401c1181 is in operator delete(void*)
>> (/Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/del_op.cc:46).
>>
>>
>> 0x400f01e1 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >
>> >::_M_drop_node(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >*)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110).
>>
>> 105       }
>>
>> 106
>>
>> 107       // __p is not permitted to be a null pointer.
>>
>> 108       void
>>
>> 109       deallocate(pointer __p, size_type)
>>
>> 110       { ::operator delete(__p); }
>>
>> 111
>>
>> 112       size_type
>>
>> 113       max_size() const _GLIBCXX_USE_NOEXCEPT
>>
>> 114       { return size_t(-1) / sizeof(_Tp); }
>>
>>
>> 0x400f0dbb is in std::_Rb_tree<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >
>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >*)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1614).
>>
>> 1609       // Erase without rebalancing.
>>
>> 1610       while (__x != 0)
>>
>> 1611 {
>>
>> 1612   _M_erase(_S_right(__x));
>>
>> 1613   _Link_type __y = _S_left(__x);
>>
>> 1614   _M_drop_node(__x);
>>
>> 1615   __x = __y;
>>
>> 1616 }
>>
>> 1617     }
>>
>> 1618
>>
>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >
>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >*)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>> 1607     _M_erase(_Link_type __x)
>>
>> 1608     {
>>
>> 1609       // Erase without rebalancing.
>>
>> 1610       while (__x != 0)
>>
>> 1611 {
>>
>> 1612   _M_erase(_S_right(__x));
>>
>> 1613   _Link_type __y = _S_left(__x);
>>
>> 1614   _M_drop_node(__x);
>>
>> 1615   __x = __y;
>>
>> 1616 }
>>
>>
>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >
>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >*)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>> 1607     _M_erase(_Link_type __x)
>>
>> 1608     {
>>
>> 1609       // Erase without rebalancing.
>>
>> 1610       while (__x != 0)
>>
>> 1611 {
>>
>> 1612   _M_erase(_S_right(__x));
>>
>> 1613   _Link_type __y = _S_left(__x);
>>
>> 1614   _M_drop_node(__x);
>>
>> 1615   __x = __y;
>>
>> 1616 }
>>
>>
>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >
>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >*)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>> 1607     _M_erase(_Link_type __x)
>>
>> 1608     {
>>
>> 1609       // Erase without rebalancing.
>>
>> 1610       while (__x != 0)
>>
>> 1611 {
>>
>> 1612   _M_erase(_S_right(__x));
>>
>> 1613   _Link_type __y = _S_left(__x);
>>
>> 1614   _M_drop_node(__x);
>>
>> 1615   __x = __y;
>>
>> 1616 }
>>
>>
>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >
>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >*)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>> 1607     _M_erase(_Link_type __x)
>>
>> 1608     {
>>
>> 1609       // Erase without rebalancing.
>>
>> 1610       while (__x != 0)
>>
>> 1611 {
>>
>> 1612   _M_erase(_S_right(__x));
>>
>> 1613   _Link_type __y = _S_left(__x);
>>
>> 1614   _M_drop_node(__x);
>>
>> 1615   __x = __y;
>>
>> 1616 }
>>
>>
>> 0x40156109 is in Pushover::EventListener(std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >, void*)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:858).
>>
>> 853
>>
>> 854       _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a);
>>
>> 855 #endif
>>
>> 856
>>
>> 857       ~_Rb_tree() _GLIBCXX_NOEXCEPT
>>
>> 858       { _M_erase(_M_begin()); }
>>
>> 859
>>
>> 860       _Rb_tree&
>>
>> 861       operator=(const _Rb_tree& __x);
>>
>> 862
>>
>> 0x401550da is in std::_Function_handler<void
>> (std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >, void*), std::_Bind<std::_Mem_fn<void
>> (Pushover::*)(std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >, void*)> (Pushover*, std::_Placeholder<1>,
>> std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >&&, void*&&)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600).
>>
>> 595       template<typename... _Args, typename _Req
>>
>> 596               = _Require<typename _Traits::__lvalue,
>>
>> 597                           _CheckArgs<_Pack<_Args...>>>>
>>
>> 598 result_type
>>
>> 599 operator()(_Class* __object, _Args&&... __args) const
>>
>> 600 { return (__object->*_M_pmf)(std::forward<_Args>(__args)...); }
>>
>> 601
>>
>> 602       // Handle smart pointers, references and pointers to derived
>>
>> 603       template<typename _Tp, typename... _Args, typename _Req
>>
>> 604               = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*,
>> _Tp>,
>>
>>
>> 0x400f3545 is in std::function<void (std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> void*)>::operator()(std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >, void*) const
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271).
>>
>> 2266     function<_Res(_ArgTypes...)>::
>>
>> 2267     operator()(_ArgTypes... __args) const
>>
>> 2268     {
>>
>> 2269       if (_M_empty())
>>
>> 2270 __throw_bad_function_call();
>>
>> 2271       return _M_invoker(_M_functor,
>> std::forward<_ArgTypes>(__args)...);
>>
>> 2272     }
>>
>> 2273
>>
>> 2274 #if __cpp_rtti
>>
>> 2275   template<typename _Res, typename... _ArgTypes>
>>
>>
>> 0x400f375e is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*)
>> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:234).
>>
>> 229       {
>>
>> 230       for (EventCallbackList::iterator itc=el->begin();
>> itc!=el->end(); ++itc)
>>
>> 231         {
>>
>> 232         m_current_started = monotonictime;
>>
>> 233         m_current_callback = *itc;
>>
>> 234         m_current_callback->m_callback(m_current_event,
>> msg->body.signal.data);
>>
>> 235         m_current_callback = NULL;
>>
>> 236         }
>>
>> 237       }
>>
>> 238     }
>>
>>
>> 0x400f37d5 is in OvmsEvents::EventTask()
>> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:185).
>>
>> 180       switch(msg.type)
>>
>> 181         {
>>
>> 182         case EVENT_none:
>>
>> 183           break;
>>
>> 184         case EVENT_signal:
>>
>> 185           HandleQueueSignalEvent(&msg);
>>
>> 186           break;
>>
>> 187         default:
>>
>> 188           break;
>>
>> 189         }
>>
>>
>> 0x400f37e5 is in EventLaunchTask(void*)
>> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:56).
>>
>> 51
>>
>> 52 void EventLaunchTask(void *pvParameters)
>>
>> 53   {
>>
>> 54   OvmsEvents* me = (OvmsEvents*)pvParameters;
>>
>> 55
>>
>> 56   me->EventTask();
>>
>> 57   }
>>
>> 58
>>
>> 59 void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand* cmd,
>> int argc, const char* const* argv)
>>
>> 60   {
>>
>> --
>> ?dv?zlettel:
>> Kov?cs Tam?s
>>
>>
>> _______________________________________________
>> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>> --
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>
>
> --
> ?dv?zlettel:
> Kov?cs Tam?s
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>


-- 
?dv?zlettel:
Kov?cs Tam?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200607/7bba7e3a/attachment-0001.html>

From casner at acm.org  Tue Jun  9 01:02:53 2020
From: casner at acm.org (Stephen Casner)
Date: Mon, 8 Jun 2020 10:02:53 -0700 (PDT)
Subject: [Ovmsdev] Strange app behavior
Message-ID: <alpine.OSX.2.21.9999.2006080951320.15345@auge.attlocal.net>

I'm running 3.2.012.  This morning when I went to check the status
after charging overnight, which had completed, the iPhone app was
behaving in a very strange manner.  I cycled a few times (for as long
as I watched) through three states at an interval on the order of
10-20 seconds:

1. 86%, ideal range 191, no charge connector icon.  Those range and
SOC numbers were correct, but the charge cable was connected.

2. 95%, ideal range 177, charge connector icon shown.

3. 48%, don't recall the range, no charge connector icon.

When I checked the Car screen, it too was cycling among showing no
numbers, showing old gray numbers, and showing some numbers in white.
I don't recall their accuracy.

Now after I finished my morning walk the display appears stable and
correct with 86%, ideal range 190, and charge connector icon shown.
The Car screen shows just old numbers in gray except for the aux
battery voltage.  Sorry I didn't have the presence of mind to grab
screenshots.

                                                        -- Steve

From dexter at expeedo.de  Tue Jun  9 02:33:13 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Mon, 8 Jun 2020 20:33:13 +0200
Subject: [Ovmsdev] Strange app behavior
In-Reply-To: <alpine.OSX.2.21.9999.2006080951320.15345@auge.attlocal.net>
References: <alpine.OSX.2.21.9999.2006080951320.15345@auge.attlocal.net>
Message-ID: <7dec280e-35b7-7a02-32e9-2d1d32502fd8@expeedo.de>

That may have been https://github.com/openvehicles/Open-Vehicle-Server/issues/2

Regards,
Michael


Am 08.06.20 um 19:02 schrieb Stephen Casner:
> I'm running 3.2.012.  This morning when I went to check the status
> after charging overnight, which had completed, the iPhone app was
> behaving in a very strange manner.  I cycled a few times (for as long
> as I watched) through three states at an interval on the order of
> 10-20 seconds:
>
> 1. 86%, ideal range 191, no charge connector icon.  Those range and
> SOC numbers were correct, but the charge cable was connected.
>
> 2. 95%, ideal range 177, charge connector icon shown.
>
> 3. 48%, don't recall the range, no charge connector icon.
>
> When I checked the Car screen, it too was cycling among showing no
> numbers, showing old gray numbers, and showing some numbers in white.
> I don't recall their accuracy.
>
> Now after I finished my morning walk the display appears stable and
> correct with 86%, ideal range 190, and charge connector icon shown.
> The Car screen shows just old numbers in gray except for the aux
> battery voltage.  Sorry I didn't have the presence of mind to grab
> screenshots.
>
>                                                         -- Steve
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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


From dexter at expeedo.de  Tue Jun  9 02:39:00 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Mon, 8 Jun 2020 20:39:00 +0200
Subject: [Ovmsdev] Random crash if enable notifications
In-Reply-To: <CAGpaXUthOkR9BURwJaK1PmHMgDkL4pmXH9OThJSm8e2LTpy_QA@mail.gmail.com>
References: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>
 <3ce6a6e3-8119-f123-296c-653ba3e258b4@expeedo.de>
 <CAGpaXUt0C_rv992y+bg7-wmD8wBZ_8g+hFoVndo7YL-xG8L3+A@mail.gmail.com>
 <9e727cb7-1042-202d-c80a-b44b1e1d2f67@expeedo.de>
 <CAGpaXUthOkR9BURwJaK1PmHMgDkL4pmXH9OThJSm8e2LTpy_QA@mail.gmail.com>
Message-ID: <b3d55512-bf11-8197-25ce-8fb788e8f5bd@expeedo.de>

I cannot tell if you did the correct setup for the spiram fix.

You need
- the new toolchain
- the new libs
- the spiram esp-idf branch
- the spiram ovms branch

If you've got all of this, then the crash isn't related to the SPIRAM bug.

Regards,
Michael


Am 07.06.20 um 07:50 schrieb Tam?s Kov?cs:
> I downloaded this toolchain and use it:?build idf v3.3-beta3-776-g3d198cd50
> I checkout?esp-idf to spiram-fix-test branch.
>
> I use a forked repo.
> I run the following to update to spiram-fix-test, on my local repo.
> git fetch upstream
> git pull upstream/spiram-fix-test master
>
> But i now get crash the last is:?
> Last crash: abort() was called on core 1 Backtrace: 0x4008ace7 0x4008af7d 0x4010badf 0x40097d93 0x40083ffd 0x400845f1 0x4000bec7 0x4012c729 0x402a1815
> 0x401eb40d 0x401f7a26 0x401f8af0 0x40207065 0x40206f45 0x40207133 0x40206faf 0x402073b6 0x4020747d 0x401f4445 0x401f3344 0x401f3677 0x401f441e 0x402079d1
> 0x401f76e5 0x401f7892 0x40202ea6 0x4012db9a 0x4012dd9d
>
> kommykt at MacBook-Air OVMS.V3 % a2l 0x4008ace7 0x4008af7d 0x4010badf 0x40097d93 0x40083ffd 0x400845f1 0x4000bec7 0x4012c729 0x402a1815 0x401eb40d 0x401f7a26
> 0x401f8af0 0x40207065 0x40206f45 0x40207133 0x40206faf 0x402073b6 0x4020747d 0x401f4445 0x401f3344 0x401f3677 0x401f441e 0x402079d1 0x401f76e5 0x401f7892
> 0x40202ea6 0x4012db9a 0x4012dd9d
>
> Using elf file: /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>
> 0x4008ace7 is in invoke_abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>
> 151#endif
>
> 152? ? while (1) {
>
> 153? ? ? ? if (esp_cpu_in_ocd_debug_mode()) {
>
> 154? ? ? ? ? ? __asm__ ("break 0,0");
>
> 155? ? ? ? }
>
> 156? ? ? ? *((int *) 0) = 0;
>
> 157? ? }
>
> 158}
>
> 159
>
> 160void abort()
>
> 0x4008af7d is in abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>
> 166? ? * don't overwrite that.
>
> 167? ? */
>
> 168? ? if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>
> 169? ? ? ? esp_reset_reason_set_hint(ESP_RST_PANIC);
>
> 170? ? }
>
> 171? ? invoke_abort();
>
> 172}
>
> 173
>
> 174
>
> 175static const char *edesc[] = {
>
> 0x4010badf is in __assert_func (../../../.././newlib/libc/stdlib/assert.c:63).
>
> 0x40097d93 is in multi_heap_free (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>
> 209? ? ? ? return;
>
> 210? ? }
>
> 211? ? multi_heap_internal_lock(heap);
>
> 212
>
> 213? ? poison_head_t *head = verify_allocated_region(p, true);
>
> 214? ? assert(head != NULL);
>
> 215
>
> 216? ? #ifdef SLOW
>
> 217? ? /* replace everything with FREE_FILL_PATTERN, including the poison head/tail */
>
> 218? ? memset(head, FREE_FILL_PATTERN,
>
> 0x40083ffd is in heap_caps_free (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>
> 263? ? ? ? ptr = (void *)dramAddrPtr[-1];
>
> 264? ? }
>
> 265
>
> 266? ? heap_t *heap = find_containing_heap(ptr);
>
> 267? ? assert(heap != NULL && "free() target pointer is outside heap areas");
>
> 268? ? multi_heap_free(heap->heap, ptr);
>
> 269}
>
> 270
>
> 271IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>
> 272{
>
> 0x400845f1 is in _free_r (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>
> 37? ? return heap_caps_malloc_default( size );
>
> 38}
>
> 39
>
> 40void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>
> 41{
>
> 42? ? heap_caps_free( ptr );
>
> 43}
>
> 44
>
> 45void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>
> 46{
>
> 0x4012c729 is in DukOvmsFree(void*, void*) (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:442).
>
> 437? return ExternalRamRealloc(ptr, size);
>
> 438? }
>
> 439
>
> 440void DukOvmsFree(void *udata, void *ptr)
>
> 441? {
>
> 442? free(ptr);
>
> 443? }
>
> 444
>
> 445void DukOvmsFatalHandler(void *udata, const char *msg)
>
> 446? {
>
> 0x402a1815 is in duk_heap_mem_free (duk_heap_memory.c:406).
>
> 0x401eb40d is in duk__refcount_refzero_hstring (duk_heap_alloc.c:103).
>
> 0x401f7a26 is in duk_heaphdr_refzero (duk_heap_refcount.c:630).
>
> 0x401f8af0 is in duk_pop_2 (duk_api_stack.c:6089).
>
> 0x40207065 is in duk__enc_value (duk_bi_json.c:2240).
>
> 0x40206f45 is in duk__enc_value (duk_bi_json.c:1951).
>
> 1946in duk_bi_json.c
>
> 0x40207133 is in duk__enc_object (duk_bi_json.c:1885).
>
> 1880in duk_bi_json.c
>
> 0x40206faf is in duk__enc_value (duk_bi_json.c:2203).
>
> 2198in duk_bi_json.c
>
> 0x402073b6 is in duk_bi_json_stringify_helper (duk_bi_json.c:3191).
>
> 3186in duk_bi_json.c
>
> 0x4020747d is in duk_bi_duktape_object_enc (duk_bi_duktape.c:96).
>
> 0x401f4445 is in duk__handle_call_raw (duk_js_call.c:2276).
>
> 0x401f3344 is in duk__js_execute_bytecode_inner (duk_js_call.c:2422).
>
> 2417in duk_js_call.c
>
> 0x401f3677 is in duk_js_execute_bytecode (duk_js_executor.c:2956).
>
> 0x401f441e is in duk__handle_call_raw (duk_js_call.c:2246).
>
> 0x402079d1 is in duk__pcall_method_raw (duk_js_call.c:2422).
>
> 2417in duk_js_call.c
>
> 0x401f76e5 is in duk_handle_safe_call (duk_js_call.c:2475).
>
> 2470in duk_js_call.c
>
> 0x401f7892 is in duk_safe_call (duk_api_call.c:318).
>
> 0x40202ea6 is in duk_pcall_method (duk_api_call.c:242).
>
> 237in duk_api_call.c
>
> 0x4012db9a is in OvmsScripts::DukTapeTask() (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:2273).
>
> 2268? ? ? ? ? ? duk_get_global_string(m_dukctx, "PubSub");
>
> 2269? ? ? ? ? ? duk_get_prop_string(m_dukctx, -1, "publish");
>
> 2270? ? ? ? ? ? duk_dup(m_dukctx, -2);? /* this binding = process */
>
> 2271? ? ? ? ? ? duk_push_string(m_dukctx, msg.body.dt_event.name <http://msg.body.dt_event.name>);
>
> 2272? ? ? ? ? ? duk_push_string(m_dukctx, "");
>
> 2273? ? ? ? ? ? if (duk_pcall_method(m_dukctx, 2) != 0)
>
> 2274? ? ? ? ? ? ? {
>
> 2275? ? ? ? ? ? ? DukOvmsErrorHandler(m_dukctx, -1);
>
> 2276? ? ? ? ? ? ? }
>
> 2277? ? ? ? ? ? duk_pop_2(m_dukctx);
>
> 0x4012dd9d is in DukTapeLaunchTask(void*) (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:427).
>
> 422
>
> 423void DukTapeLaunchTask(void *pvParameters)
>
> 424? {
>
> 425? OvmsScripts* me = (OvmsScripts*)pvParameters;
>
> 426
>
> 427? me->DukTapeTask();
>
> 428? }
>
> 429
>
> 430void* DukOvmsAlloc(void *udata, duk_size_t size)
>
> 431? {
>
>
>
> Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> ezt ?rta (id?pont: 2020. j?n. 5., P, 21:43):
>
>     See previous posts on this, you also need the fixed toolchain: https://github.com/espressif/esp-idf/issues/2892#issuecomment-501106283
>
>     Regards,
>     Michael
>
>
>     Am 05.06.20 um 20:04 schrieb Tam?s Kov?cs:
>>     i think i don't run spiram fix. How can i use it.?I must?check out branch "spiram-fix-test" ?to run spiram fix?
>>
>>     Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> ezt ?rta (id?pont: 2020. j?n. 5., P, 6:58):
>>
>>         Tam?s,
>>
>>         that doesn't need to be related to the pushover code. Do you run the spiram fix? I had this kind of heap corruption crashes frequently on builds
>>         without the spiram fix but not once with the fix.
>>
>>         Regards,
>>         Michael
>>
>>
>>         Am 05.06.20 um 05:29 schrieb Tam?s Kov?cs:
>>>         Some day's ago i enabled Pushover notifications and i get some crash after that.
>>>
>>>         The crash backtrase?is:?
>>>         Backtrace: 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4 0x400f0db4
>>>         0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>>>         a2l output is:
>>>
>>>         kommykt at MacBook-Air OVMS.V3 % a2l 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb
>>>         0x400f0db4 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>>>
>>>         Using elf file: /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>>>
>>>
>>>         0x4008b75f is in invoke_abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>>>
>>>         151#endif
>>>
>>>         152? ? while (1) {
>>>
>>>         153? ? ? ? if (esp_cpu_in_ocd_debug_mode()) {
>>>
>>>         154? ? ? ? ? ? __asm__ ("break 0,0");
>>>
>>>         155? ? ? ? }
>>>
>>>         156? ? ? ? *((int *) 0) = 0;
>>>
>>>         157? ? }
>>>
>>>         158}
>>>
>>>         159
>>>
>>>         160void abort()
>>>
>>>
>>>         0x4008b9f9 is in abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>>>
>>>         166? ? * don't overwrite that.
>>>
>>>         167? ? */
>>>
>>>         168? ? if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>>>
>>>         169? ? ? ? esp_reset_reason_set_hint(ESP_RST_PANIC);
>>>
>>>         170? ? }
>>>
>>>         171? ? invoke_abort();
>>>
>>>         172}
>>>
>>>         173
>>>
>>>         174
>>>
>>>         175static const char *edesc[] = {
>>>
>>>
>>>         0x4010b253 is in __assert_func (../../../.././newlib/libc/stdlib/assert.c:63).
>>>
>>>
>>>         0x40098c5f is in multi_heap_free (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>>>
>>>         209? ? ? ? return;
>>>
>>>         210? ? }
>>>
>>>         211? ? multi_heap_internal_lock(heap);
>>>
>>>         212
>>>
>>>         213? ? poison_head_t *head = verify_allocated_region(p, true);
>>>
>>>         214? ? assert(head != NULL);
>>>
>>>         215
>>>
>>>         216? ? #ifdef SLOW
>>>
>>>         217? ? /* replace everything with FREE_FILL_PATTERN, including the poison head/tail */
>>>
>>>         218? ? memset(head, FREE_FILL_PATTERN,
>>>
>>>
>>>         0x40084361 is in heap_caps_free (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>>>
>>>         263? ? ? ? ptr = (void *)dramAddrPtr[-1];
>>>
>>>         264? ? }
>>>
>>>         265
>>>
>>>         266? ? heap_t *heap = find_containing_heap(ptr);
>>>
>>>         267? ? assert(heap != NULL && "free() target pointer is outside heap areas");
>>>
>>>         268? ? multi_heap_free(heap->heap, ptr);
>>>
>>>         269}
>>>
>>>         270
>>>
>>>         271IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>>>
>>>         272{
>>>
>>>
>>>         0x40084945 is in _free_r (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>>>
>>>         37? ? return heap_caps_malloc_default( size );
>>>
>>>         38}
>>>
>>>         39
>>>
>>>         40void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>>>
>>>         41{
>>>
>>>         42? ? heap_caps_free( ptr );
>>>
>>>         43}
>>>
>>>         44
>>>
>>>         45void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>>>
>>>         46{
>>>
>>>
>>>         0x401c1181 is in operator delete(void*) (/Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/del_op.cc:46).
>>>
>>>
>>>         0x400f01e1 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>>         std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >,
>>>         std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
>>>         std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > > > >::_M_drop_node(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110).
>>>
>>>         105? ? ? }
>>>
>>>         106
>>>
>>>         107? ? ? // __p is not permitted to be a null pointer.
>>>
>>>         108? ? ? void
>>>
>>>         109? ? ? deallocate(pointer __p, size_type)
>>>
>>>         110? ? ? { ::operator delete(__p); }
>>>
>>>         111
>>>
>>>         112? ? ? size_type
>>>
>>>         113? ? ? max_size() const _GLIBCXX_USE_NOEXCEPT
>>>
>>>         114? ? ? { return size_t(-1) / sizeof(_Tp); }
>>>
>>>
>>>         0x400f0dbb is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>>         std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >,
>>>         std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
>>>         std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1614).
>>>
>>>         1609? ? ? // Erase without rebalancing.
>>>
>>>         1610? ? ? while (__x != 0)
>>>
>>>         1611{
>>>
>>>         1612? _M_erase(_S_right(__x));
>>>
>>>         1613? _Link_type __y = _S_left(__x);
>>>
>>>         1614? _M_drop_node(__x);
>>>
>>>         1615? __x = __y;
>>>
>>>         1616}
>>>
>>>         1617? ? }
>>>
>>>         1618
>>>
>>>         0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>>         std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >,
>>>         std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
>>>         std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>>         1607? ? _M_erase(_Link_type __x)
>>>
>>>         1608? ? {
>>>
>>>         1609? ? ? // Erase without rebalancing.
>>>
>>>         1610? ? ? while (__x != 0)
>>>
>>>         1611{
>>>
>>>         1612? _M_erase(_S_right(__x));
>>>
>>>         1613? _Link_type __y = _S_left(__x);
>>>
>>>         1614? _M_drop_node(__x);
>>>
>>>         1615? __x = __y;
>>>
>>>         1616}
>>>
>>>
>>>         0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>>         std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >,
>>>         std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
>>>         std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>>         1607? ? _M_erase(_Link_type __x)
>>>
>>>         1608? ? {
>>>
>>>         1609? ? ? // Erase without rebalancing.
>>>
>>>         1610? ? ? while (__x != 0)
>>>
>>>         1611{
>>>
>>>         1612? _M_erase(_S_right(__x));
>>>
>>>         1613? _Link_type __y = _S_left(__x);
>>>
>>>         1614? _M_drop_node(__x);
>>>
>>>         1615? __x = __y;
>>>
>>>         1616}
>>>
>>>
>>>         0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>>         std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >,
>>>         std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
>>>         std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>>         1607? ? _M_erase(_Link_type __x)
>>>
>>>         1608? ? {
>>>
>>>         1609? ? ? // Erase without rebalancing.
>>>
>>>         1610? ? ? while (__x != 0)
>>>
>>>         1611{
>>>
>>>         1612? _M_erase(_S_right(__x));
>>>
>>>         1613? _Link_type __y = _S_left(__x);
>>>
>>>         1614? _M_drop_node(__x);
>>>
>>>         1615? __x = __y;
>>>
>>>         1616}
>>>
>>>
>>>         0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>>         std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >,
>>>         std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
>>>         std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>>         1607? ? _M_erase(_Link_type __x)
>>>
>>>         1608? ? {
>>>
>>>         1609? ? ? // Erase without rebalancing.
>>>
>>>         1610? ? ? while (__x != 0)
>>>
>>>         1611{
>>>
>>>         1612? _M_erase(_S_right(__x));
>>>
>>>         1613? _Link_type __y = _S_left(__x);
>>>
>>>         1614? _M_drop_node(__x);
>>>
>>>         1615? __x = __y;
>>>
>>>         1616}
>>>
>>>
>>>         0x40156109 is in Pushover::EventListener(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:858).
>>>
>>>         853
>>>
>>>         854? ? ? _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a);
>>>
>>>         855#endif
>>>
>>>         856
>>>
>>>         857? ? ? ~_Rb_tree() _GLIBCXX_NOEXCEPT
>>>
>>>         858? ? ? { _M_erase(_M_begin()); }
>>>
>>>         859
>>>
>>>         860? ? ? _Rb_tree&
>>>
>>>         861? ? ? operator=(const _Rb_tree& __x);
>>>
>>>         862
>>>
>>>         0x401550da is in std::_Function_handler<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*),
>>>         std::_Bind<std::_Mem_fn<void (Pushover::*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)> (Pushover*,
>>>         std::_Placeholder<1>, std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&, std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> >&&, void*&&) (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600).
>>>
>>>         595? ? ? template<typename... _Args, typename _Req
>>>
>>>         596? ? ? ? ? ? ? = _Require<typename _Traits::__lvalue,
>>>
>>>         597? ? ? ? ? ? ? ? ? ? ? ? ? _CheckArgs<_Pack<_Args...>>>>
>>>
>>>         598result_type
>>>
>>>         599operator()(_Class* __object, _Args&&... __args) const
>>>
>>>         600{ return (__object->*_M_pmf)(std::forward<_Args>(__args)...); }
>>>
>>>         601
>>>
>>>         602? ? ? // Handle smart pointers, references and pointers to derived
>>>
>>>         603? ? ? template<typename _Tp, typename... _Args, typename _Req
>>>
>>>         604? ? ? ? ? ? ? = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*, _Tp>,
>>>
>>>
>>>         0x400f3545 is in std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>>         void*)>::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) const
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271).
>>>
>>>         2266? ? function<_Res(_ArgTypes...)>::
>>>
>>>         2267? ? operator()(_ArgTypes... __args) const
>>>
>>>         2268? ? {
>>>
>>>         2269? ? ? if (_M_empty())
>>>
>>>         2270__throw_bad_function_call();
>>>
>>>         2271? ? ? return _M_invoker(_M_functor, std::forward<_ArgTypes>(__args)...);
>>>
>>>         2272? ? }
>>>
>>>         2273
>>>
>>>         2274#if __cpp_rtti
>>>
>>>         2275? template<typename _Res, typename... _ArgTypes>
>>>
>>>
>>>         0x400f375e is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*)
>>>         (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:234).
>>>
>>>         229? ? ? {
>>>
>>>         230? ? ? for (EventCallbackList::iterator itc=el->begin(); itc!=el->end(); ++itc)
>>>
>>>         231? ? ? ? {
>>>
>>>         232? ? ? ? m_current_started = monotonictime;
>>>
>>>         233? ? ? ? m_current_callback = *itc;
>>>
>>>         234? ? ? ? m_current_callback->m_callback(m_current_event, msg->body.signal.data);
>>>
>>>         235? ? ? ? m_current_callback = NULL;
>>>
>>>         236? ? ? ? }
>>>
>>>         237? ? ? }
>>>
>>>         238? ? }
>>>
>>>
>>>         0x400f37d5 is in OvmsEvents::EventTask() (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:185).
>>>
>>>         180? ? ? switch(msg.type)
>>>
>>>         181? ? ? ? {
>>>
>>>         182? ? ? ? case EVENT_none:
>>>
>>>         183? ? ? ? ? break;
>>>
>>>         184? ? ? ? case EVENT_signal:
>>>
>>>         185? ? ? ? ? HandleQueueSignalEvent(&msg);
>>>
>>>         186? ? ? ? ? break;
>>>
>>>         187? ? ? ? default:
>>>
>>>         188? ? ? ? ? break;
>>>
>>>         189? ? ? ? }
>>>
>>>
>>>         0x400f37e5 is in EventLaunchTask(void*) (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:56).
>>>
>>>         51
>>>
>>>         52void EventLaunchTask(void *pvParameters)
>>>
>>>         53? {
>>>
>>>         54? OvmsEvents* me = (OvmsEvents*)pvParameters;
>>>
>>>         55
>>>
>>>         56? me->EventTask();
>>>
>>>         57? }
>>>
>>>         58
>>>
>>>         59void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv)
>>>
>>>         60? {
>>>
>>>
>>>         -- 
>>>         ?dv?zlettel:
>>>         Kov?cs Tam?s
>>>
>>>
>>>         _______________________________________________
>>>         OvmsDev mailing list
>>>         OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>         http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>         -- 
>>         Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>         Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>>         _______________________________________________
>>         OvmsDev mailing list
>>         OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>         http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>>
>>     -- 
>>     ?dv?zlettel:
>>     Kov?cs Tam?s
>>
>>
>>     _______________________________________________
>>     OvmsDev mailing list
>>     OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>     -- 
>     Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>     Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
>     _______________________________________________
>     OvmsDev mailing list
>     OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> -- 
> ?dv?zlettel:
> Kov?cs Tam?s
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200608/0e49258e/attachment-0001.html>

From casner at acm.org  Tue Jun  9 13:39:37 2020
From: casner at acm.org (Stephen Casner)
Date: Mon, 8 Jun 2020 22:39:37 -0700 (PDT)
Subject: [Ovmsdev] Strange app behavior
In-Reply-To: <7dec280e-35b7-7a02-32e9-2d1d32502fd8@expeedo.de>
References: <alpine.OSX.2.21.9999.2006080951320.15345@auge.attlocal.net>
 <7dec280e-35b7-7a02-32e9-2d1d32502fd8@expeedo.de>
Message-ID: <alpine.OSX.2.21.9999.2006082236160.15345@auge.attlocal.net>

That sounds plausible.  Since the problem ceased, I wonder if that
implies that the server was restarted.  I'm using Mark's server.

                                                        -- Steve

On Mon, 8 Jun 2020, Michael Balzer wrote:

> That may have been https://github.com/openvehicles/Open-Vehicle-Server/issues/2
>
> Regards,
> Michael
>
>
> Am 08.06.20 um 19:02 schrieb Stephen Casner:
> > I'm running 3.2.012.  This morning when I went to check the status
> > after charging overnight, which had completed, the iPhone app was
> > behaving in a very strange manner.  I cycled a few times (for as long
> > as I watched) through three states at an interval on the order of
> > 10-20 seconds:
> >
> > 1. 86%, ideal range 191, no charge connector icon.  Those range and
> > SOC numbers were correct, but the charge cable was connected.
> >
> > 2. 95%, ideal range 177, charge connector icon shown.
> >
> > 3. 48%, don't recall the range, no charge connector icon.
> >
> > When I checked the Car screen, it too was cycling among showing no
> > numbers, showing old gray numbers, and showing some numbers in white.
> > I don't recall their accuracy.
> >
> > Now after I finished my morning walk the display appears stable and
> > correct with 86%, ideal range 190, and charge connector icon shown.
> > The Car screen shows just old numbers in gray except for the aux
> > battery voltage.  Sorry I didn't have the presence of mind to grab
> > screenshots.
> >
> >                                                         -- Steve
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>

From mark at webb-johnson.net  Tue Jun  9 13:48:57 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Tue, 9 Jun 2020 13:48:57 +0800
Subject: [Ovmsdev] Strange app behavior
In-Reply-To: <alpine.OSX.2.21.9999.2006082236160.15345@auge.attlocal.net>
References: <alpine.OSX.2.21.9999.2006080951320.15345@auge.attlocal.net>
 <7dec280e-35b7-7a02-32e9-2d1d32502fd8@expeedo.de>
 <alpine.OSX.2.21.9999.2006082236160.15345@auge.attlocal.net>
Message-ID: <AB995B00-EA4C-4C58-8685-93181C7EF36B@webb-johnson.net>

Steve,

I wasn?t aware of this issue, but will look into it. I can?t immediately see the cause, but it should be relatively easy to add a clean-up of the channel structures when the connection starts.

I haven?t restarted the api.openvehicles.com <http://api.openvehicles.com/> server recently.

Regards, Mark.

> On 9 Jun 2020, at 1:39 PM, Stephen Casner <casner at acm.org> wrote:
> 
> That sounds plausible.  Since the problem ceased, I wonder if that
> implies that the server was restarted.  I'm using Mark's server.
> 
>                                                        -- Steve
> 
> On Mon, 8 Jun 2020, Michael Balzer wrote:
> 
>> That may have been https://github.com/openvehicles/Open-Vehicle-Server/issues/2
>> 
>> Regards,
>> Michael
>> 
>> 
>> Am 08.06.20 um 19:02 schrieb Stephen Casner:
>>> I'm running 3.2.012.  This morning when I went to check the status
>>> after charging overnight, which had completed, the iPhone app was
>>> behaving in a very strange manner.  I cycled a few times (for as long
>>> as I watched) through three states at an interval on the order of
>>> 10-20 seconds:
>>> 
>>> 1. 86%, ideal range 191, no charge connector icon.  Those range and
>>> SOC numbers were correct, but the charge cable was connected.
>>> 
>>> 2. 95%, ideal range 177, charge connector icon shown.
>>> 
>>> 3. 48%, don't recall the range, no charge connector icon.
>>> 
>>> When I checked the Car screen, it too was cycling among showing no
>>> numbers, showing old gray numbers, and showing some numbers in white.
>>> I don't recall their accuracy.
>>> 
>>> Now after I finished my morning walk the display appears stable and
>>> correct with 86%, ideal range 190, and charge connector icon shown.
>>> The Car screen shows just old numbers in gray except for the aux
>>> battery voltage.  Sorry I didn't have the presence of mind to grab
>>> screenshots.
>>> 
>>>                                                        -- Steve
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> 
>> --
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> 
>> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200609/1ec0ea5b/attachment.html>

From sebastien.darveau at synnoetic.com  Tue Jun  9 20:24:25 2020
From: sebastien.darveau at synnoetic.com (=?UTF-8?Q?S=C3=A9bastien_Darveau?=)
Date: Tue, 9 Jun 2020 12:24:25 +0000
Subject: [Ovmsdev] Strange app behavior
In-Reply-To: <AB995B00-EA4C-4C58-8685-93181C7EF36B@webb-johnson.net>
References: <alpine.OSX.2.21.9999.2006080951320.15345@auge.attlocal.net> 
 <7dec280e-35b7-7a02-32e9-2d1d32502fd8@expeedo.de> 
 <alpine.OSX.2.21.9999.2006082236160.15345@auge.attlocal.net> 
 <AB995B00-EA4C-4C58-8685-93181C7EF36B@webb-johnson.net> 
 <127C38DA-1DCF-45A3-A4EF-DE8578B9175A@synnoetic.com>
Message-ID: <010001729909f196-e602d92b-92d8-4615-8745-f33bd06408ff-000000@email.amazonses.com>

Hi,

I?ve also seen this strange behavior yesterday afternoon. I?m connected on the same server (api.openvehicles.com <http://api.openvehicles.com> ). The car was going out of range of the Wifi and using the modem at that time. It seems stable now.

Regards,
Sebastien Darveau

On Jun 9, 2020, at 1:48 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net> > wrote:

Steve,

I wasn?t aware of this issue, but will look into it. I can?t immediately see the cause, but it should be relatively easy to add a clean-up of the channel structures when the connection starts.

I haven?t restarted the api.openvehicles.com <http://api.openvehicles.com/> server recently.

Regards, Mark.

On 9 Jun 2020, at 1:39 PM, Stephen Casner <casner at acm.org <mailto:casner at acm.org> > wrote:

That sounds plausible. ?Since the problem ceased, I wonder if that
implies that the server was restarted. ?I'm using Mark's server.

 ???????????????????????????????????????????????????????-- Steve

On Mon, 8 Jun 2020, Michael Balzer wrote:

That may have been https://github.com/openvehicles/Open-Vehicle-Server/issues/2

Regards,
Michael


Am 08.06.20 um 19:02 schrieb Stephen Casner:
I'm running 3.2.012. ?This morning when I went to check the status
after charging overnight, which had completed, the iPhone app was
behaving in a very strange manner. ?I cycled a few times (for as long
as I watched) through three states at an interval on the order of
10-20 seconds:

1. 86%, ideal range 191, no charge connector icon. ?Those range and

SOC numbers were correct, but the charge cable was connected.

2. 95%, ideal range 177, charge connector icon shown.

3. 48%, don't recall the range, no charge connector icon.

When I checked the Car screen, it too was cycling among showing no
numbers, showing old gray numbers, and showing some numbers in white.
I don't recall their accuracy.

Now after I finished my morning walk the display appears stable and
correct with 86%, ideal range 190, and charge connector icon shown.
The Car screen shows just old numbers in gray except for the aux
battery voltage. ?Sorry I didn't have the presence of mind to grab
screenshots.

 ???????????????????????????????????????????????????????-- Steve
_______________________________________________
OvmsDev mailing list
OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com> 
http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> 

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

_______________________________________________
OvmsDev mailing list
OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com> 
http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> 


_______________________________________________
OvmsDev mailing list
OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com> 
http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> 

_______________________________________________
OvmsDev mailing list
OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com> 
http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200609/3c1fa813/attachment.html>

From mark at webb-johnson.net  Wed Jun 10 09:28:46 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Wed, 10 Jun 2020 09:28:46 +0800
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <ae250edd-441b-a6a2-feb7-2871984ad940@expeedo.de>
References: <97B46650-871C-40FF-B10E-A016963E0096@webb-johnson.net>
 <2BC4ED11-7D86-4AB2-87AB-71D648318A3A@webb-johnson.net>
 <ae250edd-441b-a6a2-feb7-2871984ad940@expeedo.de>
Message-ID: <87573F10-AC8A-483A-8085-97E128B6D79F@webb-johnson.net>

No issues reported, so just released this to MAIN.

Regards, Mark.

> On 5 Jun 2020, at 1:15 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> Followed.
> 
> Regards,
> Michael
> 
> 
> Am 05.06.20 um 07:06 schrieb Mark Webb-Johnson:
>> I have release this 3.2.013 to EAP.
>> 
>> Regards, Mark.
>> 
>>> On 31 May 2020, at 5:34 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>> 
>>> 
>>> Getting ready to release 3.2.013. I?ve tagged it, and built for api.openvehicles.com <http://api.openvehicles.com/> edge.
>>> 
>>> The main changes here are:
>>> 
>>> TPMS subsystem (including Tesla Roadster support with new optional K-line expansion board)
>>> Change to config for server.v2
>>> 
>>> For #2, I moved the server password from server.v2/password to password/server.v2, and made the server.v2 config parameter read-write. That better matches how server.v3 does it. The change is done via a config migration, so should be transparent.
>>> 
>>> Absent any issues, I plan to move to EAP early in the coming week.
>>> 
>>> Regards, Mark
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> 
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/417cad0a/attachment-0001.html>

From dexter at expeedo.de  Wed Jun 10 13:40:27 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Wed, 10 Jun 2020 07:40:27 +0200
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <87573F10-AC8A-483A-8085-97E128B6D79F@webb-johnson.net>
References: <97B46650-871C-40FF-B10E-A016963E0096@webb-johnson.net>
 <2BC4ED11-7D86-4AB2-87AB-71D648318A3A@webb-johnson.net>
 <ae250edd-441b-a6a2-feb7-2871984ad940@expeedo.de>
 <87573F10-AC8A-483A-8085-97E128B6D79F@webb-johnson.net>
Message-ID: <0404afc3-0ca1-8f9b-4d8a-84ffbe78e93f@expeedo.de>

Followed.

Regards,
Michael


Am 10.06.20 um 03:28 schrieb Mark Webb-Johnson:
> No issues reported, so just released this to MAIN.
>
> Regards, Mark.
>
>> On 5 Jun 2020, at 1:15 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
>> Followed.
>>
>> Regards,
>> Michael
>>
>>
>> Am 05.06.20 um 07:06 schrieb Mark Webb-Johnson:
>>> I have release this?3.2.013 to EAP.
>>>
>>> Regards, Mark.
>>>
>>>> On 31 May 2020, at 5:34 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>>
>>>>
>>>> Getting ready to release 3.2.013. I?ve tagged it, and built for api.openvehicles.com <http://api.openvehicles.com/>?edge.
>>>>
>>>> The main changes here are:
>>>>
>>>>  1. TPMS subsystem (including Tesla Roadster support with new optional K-line expansion board)
>>>>  2. Change to config for server.v2
>>>>
>>>>
>>>> For #2, I moved the server password from server.v2/password to password/server.v2, and made the server.v2 config parameter read-write. That better matches
>>>> how server.v3 does it. The change is done via a config migration, so should be transparent.
>>>>
>>>> Absent any issues, I plan to move to EAP early in the coming week.
>>>>
>>>> Regards, Mark
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/8136c244/attachment.html>

From chris at arachnon.de  Wed Jun 10 20:57:59 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Wed, 10 Jun 2020 14:57:59 +0200
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <0404afc3-0ca1-8f9b-4d8a-84ffbe78e93f@expeedo.de>
References: <97B46650-871C-40FF-B10E-A016963E0096@webb-johnson.net>
 <2BC4ED11-7D86-4AB2-87AB-71D648318A3A@webb-johnson.net>
 <ae250edd-441b-a6a2-feb7-2871984ad940@expeedo.de>
 <87573F10-AC8A-483A-8085-97E128B6D79F@webb-johnson.net>
 <0404afc3-0ca1-8f9b-4d8a-84ffbe78e93f@expeedo.de>
Message-ID: <1591793879.2548.5.camel@arachnon.de>

Hi all,
sorry for a perhaps silly question, but I don't understand the version
numbering between master and fork.
I regulary merge the changes from the ovms repository to my fork. So
far so good and I am up to date at the moment. OVMS is now on release
3.2.013. When I perform a pull request on my fork and do a "make" on my
local machine, I'm still on release 3.2.010. Even though the code is
absolutely up to date.
Could someone give me a hint on how to get the release numbers synced
between the ovms master and my fork?
Thanx in advance.
Greetinx
Chris

Am Mittwoch, den 10.06.2020, 07:40 +0200 schrieb Michael Balzer:
> ????Followed.
> 
> ????
> 
> ????Regards,
> 
> ????Michael
> 
> ????
> 
> ????
> 
> ????Am 10.06.20 um 03:28 schrieb Mark
> ??????Webb-Johnson:
> 
> ????
> 
> ????
> > ??????
> > ??????No issues reported, so just released this to MAIN.
> > ??????
> > 
> > ??????
> > ??????Regards, Mark.
> > 
> > ????????
> > 
> > ??????????
> > > ????????????On 5 Jun 2020, at 1:15 PM, Michael Balzer <dexter at exp
> > > eedo.de> wrote:
> > > ????????????
> > > 
> > > ????????????
> > > ??????????????
> > > ???????????????Followed.
> > > 
> > > ????????????????
> > > 
> > > ????????????????Regards,
> > > 
> > > ????????????????Michael
> > > 
> > > ????????????????
> > > 
> > > ????????????????
> > > 
> > > ????????????????Am 05.06.20 um 07:06
> > > ??????????????????schrieb Mark Webb-Johnson:
> > > 
> > > ????????????????
> > > ????????????????
> > > > ??????????????????
> > > > ??????????????????I have release this?3.2.013 to EAP.
> > > > ??????????????????
> > > > 
> > > > ??????????????????
> > > > ??????????????????Regards, Mark.
> > > > 
> > > > ????????????????????
> > > > 
> > > > ??????????????????????
> > > > > ????????????????????????On 31 May 2020, at 5:34 PM, Mark
> > > > > ??????????????????????????Webb-Johnson <mark at webb-johnson.net
> > > > > >
> > > > > ??????????????????????????wrote:
> > > > > ????????????????????????
> > > > > 
> > > > > ????????????????????????
> > > > > ??????????????????????????
> > > > > ??????????????????????????
> > > > > ????????????????????????????
> > > > > 
> > > > > ????????????????????????????
> > > > > ????????????????????????????Getting ready to release
> > > > > ??????????????????????????????3.2.013. I?ve tagged it, and
> > > > > built for api.openvehicles.com?edge.
> > > > > ????????????????????????????
> > > > > 
> > > > > ????????????????????????????
> > > > > ????????????????????????????The main changes here are:
> > > > > ????????????????????????????
> > > > > 
> > > > > ????????????????????????????
> > > > > ????????????????????????????
> > > > > ??????????????????????????????
> > > > > ????????????????????????????????TPMS subsystem (including
> > > > > ??????????????????????????????????Tesla Roadster support with
> > > > > new
> > > > > ??????????????????????????????????optional K-line expansion
> > > > > board)
> > > > > ????????????????????????????????Change to config for
> > > > > ??????????????????????????????????server.v2
> > > > > ??????????????????????????????
> > > > > ????????????????????????????
> > > > > ????????????????????????????
> > > > > 
> > > > > ????????????????????????????
> > > > > ????????????????????????????For #2, I moved the server
> > > > > ??????????????????????????????password from
> > > > > server.v2/password to
> > > > > ??????????????????????????????password/server.v2, and made
> > > > > the server.v2
> > > > > ??????????????????????????????config parameter read-write.
> > > > > That better
> > > > > ??????????????????????????????matches how server.v3 does it.
> > > > > The change
> > > > > ??????????????????????????????is done via a config migration,
> > > > > so should
> > > > > ??????????????????????????????be transparent.
> > > > > ????????????????????????????
> > > > > 
> > > > > ????????????????????????????
> > > > > ????????????????????????????Absent any issues, I plan to
> > > > > ??????????????????????????????move to EAP early in the coming
> > > > > week.
> > > > > ????????????????????????????
> > > > > 
> > > > > ????????????????????????????
> > > > > ????????????????????????????Regards, Mark
> > > > > ????????????????????????????
> > > > > 
> > > > > ????????????????????????????
> > > > > ??????????????????????????
> > > > > _______________________________________________
> > > > > 
> > > > > ??????????????????????????OvmsDev mailing list
> > > > > 
> > > > > ??????????????????????????OvmsDev at lists.openvehicles.com
> > > > > 
> > > > > ??????????????????????????http://lists.openvehicles.com/mailm
> > > > > an/listinfo/ovmsdev
> > > > > 
> > > > > ????????????????????????
> > > > > ??????????????????????
> > > > 
> > > > ????????????????????
> > > > ????????????????????
> > > > 
> > > > ??????????????????
> > > > ??????????????????
> > > > 
> > > > ??????????????????
> > > > ??????????????????_____________________________________________
> > > > __
> > > > OvmsDev mailing list
> > > > OvmsDev at lists.openvehicles.com
> > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > 
> > > > ????????????????
> > > 
> > > ????????????????
> > > 
> > > ????????????????
> > > ??????????????
> > > ??????????????_______________________________________________
> > > 
> > > ??????????????OvmsDev mailing list
> > > 
> > > ??????????????OvmsDev at lists.openvehicles.com
> > > 
> > > ??????????????http://lists.openvehicles.com/mailman/listinfo/ovms
> > > dev
> > > 
> > > ????????????
> > > ??????????
> > 
> > ????????
> > ????????
> > 
> > ??????
> > ??????
> > 
> > ??????
> > ??????_______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > 
> > ????
> 
> ????
> 
> ????--?
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> 
> ??
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/a3a7f156/attachment-0001.html>

From mark at webb-johnson.net  Wed Jun 10 21:17:34 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Wed, 10 Jun 2020 21:17:34 +0800
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <1591793879.2548.5.camel@arachnon.de>
References: <1591793879.2548.5.camel@arachnon.de>
Message-ID: <61D88B39-3397-4E50-8F51-0FDAEAE4D4BD@webb-johnson.net>

You probably need to include ?tags as an option on your git fetch.

The version is in the tag.

Regards, Mark

> On 10 Jun 2020, at 8:59 PM, Chris van der Meijden <chris at arachnon.de> wrote:
> 
> ?
> Hi all,
> 
> sorry for a perhaps silly question, but I don't understand the version numbering between master and fork.
> 
> I regulary merge the changes from the ovms repository to my fork. So far so good and I am up to date at the moment. OVMS is now on release 3.2.013. When I perform a pull request on my fork and do a "make" on my local machine, I'm still on release 3.2.010. Even though the code is absolutely up to date.
> 
> Could someone give me a hint on how to get the release numbers synced between the ovms master and my fork?
> 
> Thanx in advance.
> 
> Greetinx
> 
> Chris
> 
> 
> Am Mittwoch, den 10.06.2020, 07:40 +0200 schrieb Michael Balzer:
>> Followed.
>> 
>> Regards,
>> Michael
>> 
>> 
>> Am 10.06.20 um 03:28 schrieb Mark Webb-Johnson:
>>> No issues reported, so just released this to MAIN.
>>> 
>>> Regards, Mark.
>>> 
>>>> On 5 Jun 2020, at 1:15 PM, Michael Balzer <dexter at expeedo.de> wrote:
>>>> 
>>>> Followed.
>>>> 
>>>> Regards,
>>>> Michael
>>>> 
>>>> 
>>>> Am 05.06.20 um 07:06 schrieb Mark Webb-Johnson:
>>>>> I have release this 3.2.013 to EAP.
>>>>> 
>>>>> Regards, Mark.
>>>>> 
>>>>>> On 31 May 2020, at 5:34 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>>>>> 
>>>>>> 
>>>>>> Getting ready to release 3.2.013. I?ve tagged it, and built for api.openvehicles.com edge.
>>>>>> 
>>>>>> The main changes here are:
>>>>>> 
>>>>>> TPMS subsystem (including Tesla Roadster support with new optional K-line expansion board)
>>>>>> Change to config for server.v2
>>>>>> 
>>>>>> For #2, I moved the server password from server.v2/password to password/server.v2, and made the server.v2 config parameter read-write. That better matches how server.v3 does it. The change is done via a config migration, so should be transparent.
>>>>>> 
>>>>>> Absent any issues, I plan to move to EAP early in the coming week.
>>>>>> 
>>>>>> Regards, Mark
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.openvehicles.com
>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>> 
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> 
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/10de6b0a/attachment.html>

From chris at arachnon.de  Wed Jun 10 21:39:23 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Wed, 10 Jun 2020 15:39:23 +0200
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <61D88B39-3397-4E50-8F51-0FDAEAE4D4BD@webb-johnson.net>
References: <1591793879.2548.5.camel@arachnon.de>
 <61D88B39-3397-4E50-8F51-0FDAEAE4D4BD@webb-johnson.net>
Message-ID: <1591796363.2548.7.camel@arachnon.de>

Thanx for your quick response.
--tags did the trick for the local version when compiling. Nevertheless
the tags are not pushed back with "git push origin master" into my fork
on github. There the "releases" and "tags" are still on 3.2.010 ...
I will google that ...

Am Mittwoch, den 10.06.2020, 21:17 +0800 schrieb Mark Webb-Johnson:
> You probably need to include ?tags as an option on your git fetch.
> 
> The version is in the tag.
> 
> Regards, Mark
> 
> > On 10 Jun 2020, at 8:59 PM, Chris van der Meijden <chris at arachnon.d
> > e> wrote:
> > 
> > ?
> > ????
> > ??
> > ? Hi all,
> > sorry for a perhaps silly question, but I don't understand the
> > version numbering between master and fork.
> > I regulary merge the changes from the ovms repository to my fork.
> > So far so good and I am up to date at the moment. OVMS is now on
> > release 3.2.013. When I perform a pull request on my fork and do a
> > "make" on my local machine, I'm still on release 3.2.010. Even
> > though the code is absolutely up to date.
> > Could someone give me a hint on how to get the release numbers
> > synced between the ovms master and my fork?
> > Thanx in advance.
> > Greetinx
> > Chris
> > 
> > Am Mittwoch, den 10.06.2020, 07:40 +0200 schrieb Michael Balzer:
> > > ????Followed.
> > > 
> > > ????
> > > 
> > > ????Regards,
> > > 
> > > ????Michael
> > > 
> > > ????
> > > 
> > > ????
> > > 
> > > ????Am 10.06.20 um 03:28 schrieb Mark
> > > ??????Webb-Johnson:
> > > 
> > > ????
> > > 
> > > ????
> > > > ??????
> > > > ??????No issues reported, so just released this to MAIN.
> > > > ??????
> > > > 
> > > > ??????
> > > > ??????Regards, Mark.
> > > > 
> > > > ????????
> > > > 
> > > > ??????????
> > > > > ????????????On 5 Jun 2020, at 1:15 PM, Michael Balzer <dexter
> > > > > @expeedo.de> wrote:
> > > > > ????????????
> > > > > 
> > > > > ????????????
> > > > > ??????????????
> > > > > ???????????????Followed.
> > > > > 
> > > > > ????????????????
> > > > > 
> > > > > ????????????????Regards,
> > > > > 
> > > > > ????????????????Michael
> > > > > 
> > > > > ????????????????
> > > > > 
> > > > > ????????????????
> > > > > 
> > > > > ????????????????Am 05.06.20 um 07:06
> > > > > ??????????????????schrieb Mark Webb-Johnson:
> > > > > 
> > > > > ????????????????
> > > > > ????????????????
> > > > > > ??????????????????
> > > > > > ??????????????????I have release this?3.2.013 to EAP.
> > > > > > ??????????????????
> > > > > > 
> > > > > > ??????????????????
> > > > > > ??????????????????Regards, Mark.
> > > > > > 
> > > > > > ????????????????????
> > > > > > 
> > > > > > ??????????????????????
> > > > > > > ????????????????????????On 31 May 2020, at 5:34 PM, Mark
> > > > > > > ??????????????????????????Webb-Johnson <mark at webb-johnson
> > > > > > > .net>
> > > > > > > ??????????????????????????wrote:
> > > > > > > ????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????
> > > > > > > ??????????????????????????
> > > > > > > ??????????????????????????
> > > > > > > ????????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????????
> > > > > > > ????????????????????????????Getting ready to release
> > > > > > > ??????????????????????????????3.2.013. I?ve tagged it,
> > > > > > > and built for api.openvehicles.com?edge.
> > > > > > > ????????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????????
> > > > > > > ????????????????????????????The main changes here are:
> > > > > > > ????????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????????
> > > > > > > ????????????????????????????
> > > > > > > ??????????????????????????????
> > > > > > > ????????????????????????????????TPMS subsystem (including
> > > > > > > ??????????????????????????????????Tesla Roadster support
> > > > > > > with new
> > > > > > > ??????????????????????????????????optional K-line
> > > > > > > expansion board)
> > > > > > > ????????????????????????????????Change to config for
> > > > > > > ??????????????????????????????????server.v2
> > > > > > > ??????????????????????????????
> > > > > > > ????????????????????????????
> > > > > > > ????????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????????
> > > > > > > ????????????????????????????For #2, I moved the server
> > > > > > > ??????????????????????????????password from
> > > > > > > server.v2/password to
> > > > > > > ??????????????????????????????password/server.v2, and
> > > > > > > made the server.v2
> > > > > > > ??????????????????????????????config parameter read-
> > > > > > > write. That better
> > > > > > > ??????????????????????????????matches how server.v3 does
> > > > > > > it. The change
> > > > > > > ??????????????????????????????is done via a config
> > > > > > > migration, so should
> > > > > > > ??????????????????????????????be transparent.
> > > > > > > ????????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????????
> > > > > > > ????????????????????????????Absent any issues, I plan to
> > > > > > > ??????????????????????????????move to EAP early in the
> > > > > > > coming week.
> > > > > > > ????????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????????
> > > > > > > ????????????????????????????Regards, Mark
> > > > > > > ????????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????????
> > > > > > > ??????????????????????????
> > > > > > > _______________________________________________
> > > > > > > 
> > > > > > > ??????????????????????????OvmsDev mailing list
> > > > > > > 
> > > > > > > ??????????????????????????OvmsDev at lists.openvehicles.com
> > > > > > > 
> > > > > > > ??????????????????????????http://lists.openvehicles.com/m
> > > > > > > ailman/listinfo/ovmsdev
> > > > > > > 
> > > > > > > ????????????????????????
> > > > > > > ??????????????????????
> > > > > > 
> > > > > > ????????????????????
> > > > > > ????????????????????
> > > > > > 
> > > > > > ??????????????????
> > > > > > ??????????????????
> > > > > > 
> > > > > > ??????????????????
> > > > > > ??????????????????_________________________________________
> > > > > > ______
> > > > > > OvmsDev mailing list
> > > > > > OvmsDev at lists.openvehicles.com
> > > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > > > 
> > > > > > ????????????????
> > > > > 
> > > > > ????????????????
> > > > > 
> > > > > ????????????????
> > > > > ??????????????
> > > > > ??????????????_______________________________________________
> > > > > 
> > > > > ??????????????OvmsDev mailing list
> > > > > 
> > > > > ??????????????OvmsDev at lists.openvehicles.com
> > > > > 
> > > > > ??????????????http://lists.openvehicles.com/mailman/listinfo/
> > > > > ovmsdev
> > > > > 
> > > > > ????????????
> > > > > ??????????
> > > > 
> > > > ????????
> > > > ????????
> > > > 
> > > > ??????
> > > > ??????
> > > > 
> > > > ??????
> > > > ??????_______________________________________________
> > > > OvmsDev mailing list
> > > > OvmsDev at lists.openvehicles.com
> > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > 
> > > > ????
> > > 
> > > ????
> > > 
> > > ????
> > > ??
> > > 
> > > _______________________________________________
> > > OvmsDev mailing list
> > > OvmsDev at lists.openvehicles.com
> > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/6ce9e242/attachment-0001.html>

From mark at webb-johnson.net  Wed Jun 10 21:43:10 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Wed, 10 Jun 2020 21:43:10 +0800
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <1591796363.2548.7.camel@arachnon.de>
References: <1591796363.2548.7.camel@arachnon.de>
Message-ID: <B1DE133D-50DC-4E92-B3F3-FA8EF40AF61E@webb-johnson.net>

Also ?tags on the push.

Regards, Mark

> On 10 Jun 2020, at 9:40 PM, Chris van der Meijden <chris at arachnon.de> wrote:
> 
> ?
> Thanx for your quick response.
> 
> --tags did the trick for the local version when compiling. Nevertheless the tags are not pushed back with "git push origin master" into my fork on github. There the "releases" and "tags" are still on 3.2.010 ...
> 
> I will google that ...
> 
> 
> Am Mittwoch, den 10.06.2020, 21:17 +0800 schrieb Mark Webb-Johnson:
>> You probably need to include ?tags as an option on your git fetch.
>> 
>> The version is in the tag.
>> 
>> Regards, Mark
>> 
>>>> On 10 Jun 2020, at 8:59 PM, Chris van der Meijden <chris at arachnon.de> wrote:
>>>> 
>>> ?
>>> Hi all,
>>> 
>>> sorry for a perhaps silly question, but I don't understand the version numbering between master and fork.
>>> 
>>> I regulary merge the changes from the ovms repository to my fork. So far so good and I am up to date at the moment. OVMS is now on release 3.2.013. When I perform a pull request on my fork and do a "make" on my local machine, I'm still on release 3.2.010. Even though the code is absolutely up to date.
>>> 
>>> Could someone give me a hint on how to get the release numbers synced between the ovms master and my fork?
>>> 
>>> Thanx in advance.
>>> 
>>> Greetinx
>>> 
>>> Chris
>>> 
>>> 
>>> Am Mittwoch, den 10.06.2020, 07:40 +0200 schrieb Michael Balzer:
>>>> Followed.
>>>> 
>>>> Regards,
>>>> Michael
>>>> 
>>>> 
>>>> Am 10.06.20 um 03:28 schrieb Mark Webb-Johnson:
>>>>> No issues reported, so just released this to MAIN.
>>>>> 
>>>>> Regards, Mark.
>>>>> 
>>>>>> On 5 Jun 2020, at 1:15 PM, Michael Balzer <dexter at expeedo.de> wrote:
>>>>>> 
>>>>>> Followed.
>>>>>> 
>>>>>> Regards,
>>>>>> Michael
>>>>>> 
>>>>>> 
>>>>>> Am 05.06.20 um 07:06 schrieb Mark Webb-Johnson:
>>>>>>> I have release this 3.2.013 to EAP.
>>>>>>> 
>>>>>>> Regards, Mark.
>>>>>>> 
>>>>>>>> On 31 May 2020, at 5:34 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Getting ready to release 3.2.013. I?ve tagged it, and built for api.openvehicles.com edge.
>>>>>>>> 
>>>>>>>> The main changes here are:
>>>>>>>> 
>>>>>>>> TPMS subsystem (including Tesla Roadster support with new optional K-line expansion board)
>>>>>>>> Change to config for server.v2
>>>>>>>> 
>>>>>>>> For #2, I moved the server password from server.v2/password to password/server.v2, and made the server.v2 config parameter read-write. That better matches how server.v3 does it. The change is done via a config migration, so should be transparent.
>>>>>>>> 
>>>>>>>> Absent any issues, I plan to move to EAP early in the coming week.
>>>>>>>> 
>>>>>>>> Regards, Mark
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> OvmsDev mailing list
>>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.openvehicles.com
>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>> 
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/45309c98/attachment.html>

From chris at arachnon.de  Wed Jun 10 21:42:31 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Wed, 10 Jun 2020 15:42:31 +0200
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <1591796363.2548.7.camel@arachnon.de>
References: <1591793879.2548.5.camel@arachnon.de>
 <61D88B39-3397-4E50-8F51-0FDAEAE4D4BD@webb-johnson.net>
 <1591796363.2548.7.camel@arachnon.de>
Message-ID: <1591796551.2548.8.camel@arachnon.de>

OK, now this was silly :-)

I just needed to 

git push origin master --tags

...

Chris

Am Mittwoch, den 10.06.2020, 15:39 +0200 schrieb Chris van der Meijden:
> Thanx for your quick response.
> 
> --tags did the trick for the local version when compiling.
> Nevertheless the tags are not pushed back with "git push origin
> master" into my fork on github. There the "releases" and "tags" are
> still on 3.2.010 ...
> 
> I will google that ...
> 
> 
> Am Mittwoch, den 10.06.2020, 21:17 +0800 schrieb Mark Webb-Johnson:
> > You probably need to include ?tags as an option on your git fetch.
> > 
> > The version is in the tag.
> > 
> > Regards, Mark
> > 
> > > On 10 Jun 2020, at 8:59 PM, Chris van der Meijden <chris at arachnon
> > > .de> wrote:
> > > 
> > > ?
> > > ????
> > > ??
> > > ? Hi all,
> > > sorry for a perhaps silly question, but I don't understand the
> > > version numbering between master and fork.
> > > I regulary merge the changes from the ovms repository to my fork.
> > > So far so good and I am up to date at the moment. OVMS is now on
> > > release 3.2.013. When I perform a pull request on my fork and do
> > > a "make" on my local machine, I'm still on release 3.2.010. Even
> > > though the code is absolutely up to date.
> > > Could someone give me a hint on how to get the release numbers
> > > synced between the ovms master and my fork?
> > > Thanx in advance.
> > > Greetinx
> > > Chris
> > > 
> > > Am Mittwoch, den 10.06.2020, 07:40 +0200 schrieb Michael Balzer:
> > > > ????Followed.
> > > > 
> > > > ????
> > > > 
> > > > ????Regards,
> > > > 
> > > > ????Michael
> > > > 
> > > > ????
> > > > 
> > > > ????
> > > > 
> > > > ????Am 10.06.20 um 03:28 schrieb Mark
> > > > ??????Webb-Johnson:
> > > > 
> > > > ????
> > > > 
> > > > ????
> > > > > ??????
> > > > > ??????No issues reported, so just released this to MAIN.
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????Regards, Mark.
> > > > > 
> > > > > ????????
> > > > > 
> > > > > ??????????
> > > > > > ????????????On 5 Jun 2020, at 1:15 PM, Michael Balzer <dext
> > > > > > er at expeedo.de> wrote:
> > > > > > ????????????
> > > > > > ????????????
> > > > > > ??????????????
> > > > > > ???????????????Followed.
> > > > > > 
> > > > > > ????????????????
> > > > > > 
> > > > > > ????????????????Regards,
> > > > > > 
> > > > > > ????????????????Michael
> > > > > > 
> > > > > > ????????????????
> > > > > > 
> > > > > > ????????????????
> > > > > > 
> > > > > > ????????????????Am 05.06.20 um 07:06
> > > > > > ??????????????????schrieb Mark Webb-Johnson:
> > > > > > 
> > > > > > ????????????????
> > > > > > ????????????????
> > > > > > > ??????????????????
> > > > > > > ??????????????????I have release this?3.2.013 to EAP.
> > > > > > > ??????????????????
> > > > > > > 
> > > > > > > ??????????????????
> > > > > > > ??????????????????Regards, Mark.
> > > > > > > 
> > > > > > > ????????????????????
> > > > > > > 
> > > > > > > ??????????????????????
> > > > > > > > ????????????????????????On 31 May 2020, at 5:34 PM,
> > > > > > > > Mark
> > > > > > > > ??????????????????????????Webb-Johnson <mark at webb-johns
> > > > > > > > on.net>
> > > > > > > > ??????????????????????????wrote:
> > > > > > > > ????????????????????????
> > > > > > > > ????????????????????????
> > > > > > > > ??????????????????????????
> > > > > > > > ??????????????????????????
> > > > > > > > ????????????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????????????
> > > > > > > > ????????????????????????????Getting ready to release
> > > > > > > > ??????????????????????????????3.2.013. I?ve tagged it,
> > > > > > > > and built for api.openvehicles.com?edge.
> > > > > > > > ????????????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????????????
> > > > > > > > ????????????????????????????The main changes here are:
> > > > > > > > ????????????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????????????
> > > > > > > > ????????????????????????????
> > > > > > > > ??????????????????????????????
> > > > > > > > ????????????????????????????????TPMS subsystem
> > > > > > > > (including
> > > > > > > > ??????????????????????????????????Tesla Roadster
> > > > > > > > support with new
> > > > > > > > ??????????????????????????????????optional K-line
> > > > > > > > expansion board)
> > > > > > > > ????????????????????????????????Change to config for
> > > > > > > > ??????????????????????????????????server.v2
> > > > > > > > ??????????????????????????????
> > > > > > > > ????????????????????????????
> > > > > > > > ????????????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????????????
> > > > > > > > ????????????????????????????For #2, I moved the server
> > > > > > > > ??????????????????????????????password from
> > > > > > > > server.v2/password to
> > > > > > > > ??????????????????????????????password/server.v2, and
> > > > > > > > made the server.v2
> > > > > > > > ??????????????????????????????config parameter read-
> > > > > > > > write. That better
> > > > > > > > ??????????????????????????????matches how server.v3
> > > > > > > > does it. The change
> > > > > > > > ??????????????????????????????is done via a config
> > > > > > > > migration, so should
> > > > > > > > ??????????????????????????????be transparent.
> > > > > > > > ????????????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????????????
> > > > > > > > ????????????????????????????Absent any issues, I plan
> > > > > > > > to
> > > > > > > > ??????????????????????????????move to EAP early in the
> > > > > > > > coming week.
> > > > > > > > ????????????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????????????
> > > > > > > > ????????????????????????????Regards, Mark
> > > > > > > > ????????????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????????????
> > > > > > > > ??????????????????????????
> > > > > > > > _______________________________________________
> > > > > > > > 
> > > > > > > > ??????????????????????????OvmsDev mailing list
> > > > > > > > 
> > > > > > > > ??????????????????????????OvmsDev at lists.openvehicles.co
> > > > > > > > m
> > > > > > > > 
> > > > > > > > ??????????????????????????http://lists.openvehicles.com
> > > > > > > > /mailman/listinfo/ovmsdev
> > > > > > > > 
> > > > > > > > ????????????????????????
> > > > > > > > ??????????????????????
> > > > > > > 
> > > > > > > ????????????????????
> > > > > > > ????????????????????
> > > > > > > 
> > > > > > > ??????????????????
> > > > > > > ??????????????????
> > > > > > > 
> > > > > > > ??????????????????
> > > > > > > ??????????????????_______________________________________
> > > > > > > ________
> > > > > > > OvmsDev mailing list
> > > > > > > OvmsDev at lists.openvehicles.com
> > > > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > > > > 
> > > > > > > ????????????????
> > > > > > 
> > > > > > ????????????????
> > > > > > 
> > > > > > ????????????????
> > > > > > ??????????????
> > > > > > ??????????????_____________________________________________
> > > > > > __
> > > > > > 
> > > > > > ??????????????OvmsDev mailing list
> > > > > > 
> > > > > > ??????????????OvmsDev at lists.openvehicles.com
> > > > > > 
> > > > > > ??????????????http://lists.openvehicles.com/mailman/listinf
> > > > > > o/ovmsdev
> > > > > > 
> > > > > > ????????????
> > > > > > ??????????
> > > > > 
> > > > > ????????
> > > > > ????????
> > > > > 
> > > > > ??????
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????_______________________________________________
> > > > > OvmsDev mailing list
> > > > > OvmsDev at lists.openvehicles.com
> > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > > 
> > > > > ????
> > > > 
> > > > ????
> > > > 
> > > > ????
> > > > ??
> > > > 
> > > > _______________________________________________
> > > > OvmsDev mailing list
> > > > OvmsDev at lists.openvehicles.com
> > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > _______________________________________________
> > > OvmsDev mailing list
> > > OvmsDev at lists.openvehicles.com
> > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/2d79702d/attachment-0001.html>

From chris at arachnon.de  Wed Jun 10 21:44:06 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Wed, 10 Jun 2020 15:44:06 +0200
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <B1DE133D-50DC-4E92-B3F3-FA8EF40AF61E@webb-johnson.net>
References: <1591796363.2548.7.camel@arachnon.de>
 <B1DE133D-50DC-4E92-B3F3-FA8EF40AF61E@webb-johnson.net>
Message-ID: <1591796646.2548.9.camel@arachnon.de>

Crosspost :-)

Thanx!

Am Mittwoch, den 10.06.2020, 21:43 +0800 schrieb Mark Webb-Johnson:
> Also ?tags on the push.
> 
> Regards, Mark
> 
> > On 10 Jun 2020, at 9:40 PM, Chris van der Meijden <chris at arachnon.d
> > e> wrote:
> > 
> > ?Thanx for your quick response.
> > --tags did the trick for the local version when compiling.
> > Nevertheless the tags are not pushed back with "git push origin
> > master" into my fork on github. There the "releases" and "tags" are
> > still on 3.2.010 ...
> > I will google that ...
> > 
> > Am Mittwoch, den 10.06.2020, 21:17 +0800 schrieb Mark Webb-Johnson:
> > > You probably need to include ?tags as an option on your git
> > > fetch.
> > > 
> > > The version is in the tag.
> > > 
> > > Regards, Mark
> > > 
> > > > On 10 Jun 2020, at 8:59 PM, Chris van der Meijden <chris at arachn
> > > > on.de> wrote:
> > > > 
> > > > ?
> > > > ????
> > > > ??
> > > > ? Hi all,
> > > > sorry for a perhaps silly question, but I don't understand the
> > > > version numbering between master and fork.
> > > > I regulary merge the changes from the ovms repository to my
> > > > fork. So far so good and I am up to date at the moment. OVMS is
> > > > now on release 3.2.013. When I perform a pull request on my
> > > > fork and do a "make" on my local machine, I'm still on release
> > > > 3.2.010. Even though the code is absolutely up to date.
> > > > Could someone give me a hint on how to get the release numbers
> > > > synced between the ovms master and my fork?
> > > > Thanx in advance.
> > > > Greetinx
> > > > Chris
> > > > 
> > > > Am Mittwoch, den 10.06.2020, 07:40 +0200 schrieb Michael
> > > > Balzer:
> > > > > ????Followed.
> > > > > 
> > > > > ????
> > > > > 
> > > > > ????Regards,
> > > > > 
> > > > > ????Michael
> > > > > 
> > > > > ????
> > > > > 
> > > > > ????
> > > > > 
> > > > > ????Am 10.06.20 um 03:28 schrieb Mark
> > > > > ??????Webb-Johnson:
> > > > > 
> > > > > ????
> > > > > 
> > > > > ????
> > > > > > ??????
> > > > > > ??????No issues reported, so just released this to MAIN.
> > > > > > ??????
> > > > > > 
> > > > > > ??????
> > > > > > ??????Regards, Mark.
> > > > > > 
> > > > > > ????????
> > > > > > 
> > > > > > ??????????
> > > > > > > ????????????On 5 Jun 2020, at 1:15 PM, Michael Balzer <de
> > > > > > > xter at expeedo.de> wrote:
> > > > > > > ????????????
> > > > > > > ????????????
> > > > > > > ??????????????
> > > > > > > ???????????????Followed.
> > > > > > > 
> > > > > > > ????????????????
> > > > > > > 
> > > > > > > ????????????????Regards,
> > > > > > > 
> > > > > > > ????????????????Michael
> > > > > > > 
> > > > > > > ????????????????
> > > > > > > 
> > > > > > > ????????????????
> > > > > > > 
> > > > > > > ????????????????Am 05.06.20 um 07:06
> > > > > > > ??????????????????schrieb Mark Webb-Johnson:
> > > > > > > 
> > > > > > > ????????????????
> > > > > > > ????????????????
> > > > > > > > ??????????????????
> > > > > > > > ??????????????????I have release this?3.2.013 to EAP.
> > > > > > > > ??????????????????
> > > > > > > > 
> > > > > > > > ??????????????????
> > > > > > > > ??????????????????Regards, Mark.
> > > > > > > > 
> > > > > > > > ????????????????????
> > > > > > > > 
> > > > > > > > ??????????????????????
> > > > > > > > > ????????????????????????On 31 May 2020, at 5:34 PM,
> > > > > > > > > Mark
> > > > > > > > > ??????????????????????????Webb-Johnson <mark at webb-joh
> > > > > > > > > nson.net>
> > > > > > > > > ??????????????????????????wrote:
> > > > > > > > > ????????????????????????
> > > > > > > > > ????????????????????????
> > > > > > > > > ??????????????????????????
> > > > > > > > > ??????????????????????????
> > > > > > > > > ????????????????????????????
> > > > > > > > > 
> > > > > > > > > ????????????????????????????
> > > > > > > > > ????????????????????????????Getting ready to release
> > > > > > > > > ??????????????????????????????3.2.013. I?ve tagged
> > > > > > > > > it, and built for api.openvehicles.com?edge.
> > > > > > > > > ????????????????????????????
> > > > > > > > > 
> > > > > > > > > ????????????????????????????
> > > > > > > > > ????????????????????????????The main changes here
> > > > > > > > > are:
> > > > > > > > > ????????????????????????????
> > > > > > > > > 
> > > > > > > > > ????????????????????????????
> > > > > > > > > ????????????????????????????
> > > > > > > > > ??????????????????????????????
> > > > > > > > > ????????????????????????????????TPMS subsystem
> > > > > > > > > (including
> > > > > > > > > ??????????????????????????????????Tesla Roadster
> > > > > > > > > support with new
> > > > > > > > > ??????????????????????????????????optional K-line
> > > > > > > > > expansion board)
> > > > > > > > > ????????????????????????????????Change to config for
> > > > > > > > > ??????????????????????????????????server.v2
> > > > > > > > > ??????????????????????????????
> > > > > > > > > ????????????????????????????
> > > > > > > > > ????????????????????????????
> > > > > > > > > 
> > > > > > > > > ????????????????????????????
> > > > > > > > > ????????????????????????????For #2, I moved the
> > > > > > > > > server
> > > > > > > > > ??????????????????????????????password from
> > > > > > > > > server.v2/password to
> > > > > > > > > ??????????????????????????????password/server.v2, and
> > > > > > > > > made the server.v2
> > > > > > > > > ??????????????????????????????config parameter read-
> > > > > > > > > write. That better
> > > > > > > > > ??????????????????????????????matches how server.v3
> > > > > > > > > does it. The change
> > > > > > > > > ??????????????????????????????is done via a config
> > > > > > > > > migration, so should
> > > > > > > > > ??????????????????????????????be transparent.
> > > > > > > > > ????????????????????????????
> > > > > > > > > 
> > > > > > > > > ????????????????????????????
> > > > > > > > > ????????????????????????????Absent any issues, I plan
> > > > > > > > > to
> > > > > > > > > ??????????????????????????????move to EAP early in
> > > > > > > > > the coming week.
> > > > > > > > > ????????????????????????????
> > > > > > > > > 
> > > > > > > > > ????????????????????????????
> > > > > > > > > ????????????????????????????Regards, Mark
> > > > > > > > > ????????????????????????????
> > > > > > > > > 
> > > > > > > > > ????????????????????????????
> > > > > > > > > ??????????????????????????
> > > > > > > > > _______________________________________________
> > > > > > > > > 
> > > > > > > > > ??????????????????????????OvmsDev mailing list
> > > > > > > > > 
> > > > > > > > > ??????????????????????????OvmsDev at lists.openvehicles.
> > > > > > > > > com
> > > > > > > > > 
> > > > > > > > > ??????????????????????????http://lists.openvehicles.c
> > > > > > > > > om/mailman/listinfo/ovmsdev
> > > > > > > > > 
> > > > > > > > > ????????????????????????
> > > > > > > > > ??????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????
> > > > > > > > ????????????????????
> > > > > > > > 
> > > > > > > > ??????????????????
> > > > > > > > ??????????????????
> > > > > > > > 
> > > > > > > > ??????????????????
> > > > > > > > ??????????????????_____________________________________
> > > > > > > > __________
> > > > > > > > OvmsDev mailing list
> > > > > > > > OvmsDev at lists.openvehicles.com
> > > > > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > > > > > 
> > > > > > > > ????????????????
> > > > > > > 
> > > > > > > ????????????????
> > > > > > > 
> > > > > > > ????????????????
> > > > > > > ??????????????
> > > > > > > ??????????????___________________________________________
> > > > > > > ____
> > > > > > > 
> > > > > > > ??????????????OvmsDev mailing list
> > > > > > > 
> > > > > > > ??????????????OvmsDev at lists.openvehicles.com
> > > > > > > 
> > > > > > > ??????????????http://lists.openvehicles.com/mailman/listi
> > > > > > > nfo/ovmsdev
> > > > > > > 
> > > > > > > ????????????
> > > > > > > ??????????
> > > > > > 
> > > > > > ????????
> > > > > > ????????
> > > > > > 
> > > > > > ??????
> > > > > > ??????
> > > > > > 
> > > > > > ??????
> > > > > > ??????_______________________________________________
> > > > > > OvmsDev mailing list
> > > > > > OvmsDev at lists.openvehicles.com
> > > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > > > 
> > > > > > ????
> > > > > 
> > > > > ????
> > > > > 
> > > > > ????
> > > > > ??
> > > > > 
> > > > > _______________________________________________
> > > > > OvmsDev mailing list
> > > > > OvmsDev at lists.openvehicles.com
> > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > _______________________________________________
> > > > OvmsDev mailing list
> > > > OvmsDev at lists.openvehicles.com
> > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > _______________________________________________
> > > OvmsDev mailing list
> > > OvmsDev at lists.openvehicles.com
> > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/69623960/attachment.html>

From mark at webb-johnson.net  Thu Jun 11 09:37:03 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Thu, 11 Jun 2020 09:37:03 +0800
Subject: [Ovmsdev] Strange app behavior
In-Reply-To: <AB995B00-EA4C-4C58-8685-93181C7EF36B@webb-johnson.net>
References: <alpine.OSX.2.21.9999.2006080951320.15345@auge.attlocal.net>
 <7dec280e-35b7-7a02-32e9-2d1d32502fd8@expeedo.de>
 <alpine.OSX.2.21.9999.2006082236160.15345@auge.attlocal.net>
 <AB995B00-EA4C-4C58-8685-93181C7EF36B@webb-johnson.net>
Message-ID: <0852A30F-ABC9-4E3B-9345-5EC880A06C69@webb-johnson.net>


Very bizarre. The issue was hard to track down. Seems to be strange behaviour in SSL connections with faults, where the SSL error comes in, the connection is torn down, but then a welcome message arrives for the login (after the disconnection). If the welcome login succeeds, then the vehicle App connection is associated with the FD# and causes the issue later on.

So, the server code sees a login message after the connection was disconnected ?

2020-06-10 20:36:20.271547 +0800 info  OVMS::Server::ApiV2: #253 - - new TLS connection from <redacted>
2020-06-10 20:36:20.273606 +0800 info  OVMS::Server::Core: #253 - - ConnStart
2020-06-10 20:36:28.781028 +0800 error OVMS::Server::ApiV2: #253 C <redacted-car> got error: ssl3_read_bytes: ssl handshake failure
2020-06-10 20:36:28.782356 +0800 info  OVMS::Server::Core: #253 C <redacted-car> CarDisconnect
2020-06-10 20:36:28.782821 +0800 info  OVMS::Server::Core: #253 - - ConnFinish
Use of uninitialized value in concatenation (.) or string at plugins/system/OVMS/Server/ApiV2.pm line 631.
2020-06-10 20:36:28.783094 +0800 info  OVMS::Server::ApiV2: #253 C <redacted-car> got proto #/C login
Use of uninitialized value $clienttype in concatenation (.) or string at plugins/system/OVMS/Server/Core.pm line 237.
2020-06-10 20:36:28.784261 +0800 info  OVMS::Server::Core: #253  <redacted-car> CarConnect

At that stage, the fd #253 is tagged with an App connection, and never cleared (because the CarDisconnect was before the CarConnect).

Later on, that fd# can get data from the original app/car with connection issues. The source of bad data seems to be almost always the DEMO car.

Workaround is to add connection checks to the io_line and io_welcome routines, to simply return (discard) if the connection is not marked as up.

Will load this live on api.openvehicles.com now, and monitor for a few days. We now have logging for these mismatched connections (and code to avoid sending out the data in that case), so it should be easy to see if this solves the problem.

Regards, Mark.

> On 9 Jun 2020, at 1:48 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> Steve,
> 
> I wasn?t aware of this issue, but will look into it. I can?t immediately see the cause, but it should be relatively easy to add a clean-up of the channel structures when the connection starts.
> 
> I haven?t restarted the api.openvehicles.com <http://api.openvehicles.com/> server recently.
> 
> Regards, Mark.
> 
>> On 9 Jun 2020, at 1:39 PM, Stephen Casner <casner at acm.org <mailto:casner at acm.org>> wrote:
>> 
>> That sounds plausible.  Since the problem ceased, I wonder if that
>> implies that the server was restarted.  I'm using Mark's server.
>> 
>>                                                        -- Steve
>> 
>> On Mon, 8 Jun 2020, Michael Balzer wrote:
>> 
>>> That may have been https://github.com/openvehicles/Open-Vehicle-Server/issues/2 <https://github.com/openvehicles/Open-Vehicle-Server/issues/2>
>>> 
>>> Regards,
>>> Michael
>>> 
>>> 
>>> Am 08.06.20 um 19:02 schrieb Stephen Casner:
>>>> I'm running 3.2.012.  This morning when I went to check the status
>>>> after charging overnight, which had completed, the iPhone app was
>>>> behaving in a very strange manner.  I cycled a few times (for as long
>>>> as I watched) through three states at an interval on the order of
>>>> 10-20 seconds:
>>>> 
>>>> 1. 86%, ideal range 191, no charge connector icon.  Those range and
>>>> SOC numbers were correct, but the charge cable was connected.
>>>> 
>>>> 2. 95%, ideal range 177, charge connector icon shown.
>>>> 
>>>> 3. 48%, don't recall the range, no charge connector icon.
>>>> 
>>>> When I checked the Car screen, it too was cycling among showing no
>>>> numbers, showing old gray numbers, and showing some numbers in white.
>>>> I don't recall their accuracy.
>>>> 
>>>> Now after I finished my morning walk the display appears stable and
>>>> correct with 86%, ideal range 190, and charge connector icon shown.
>>>> The Car screen shows just old numbers in gray except for the aux
>>>> battery voltage.  Sorry I didn't have the presence of mind to grab
>>>> screenshots.
>>>> 
>>>>                                                        -- Steve
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>> 
>>> --
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>> 
>>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200611/c85ca5d4/attachment-0001.html>

From leres at xse.com  Sat Jun 13 07:09:24 2020
From: leres at xse.com (Craig Leres)
Date: Fri, 12 Jun 2020 16:09:24 -0700
Subject: [Ovmsdev] Gas vs. battery metric?
Message-ID: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>

I'd like to add a boolean metric for gas vehicles as a prelude to the
phone apps having this info. Would this be ok?

    #define MS_V_MOT_GAS "v.m.gas"

    ms_v_mot_gas = new OvmsMetricBool(MS_V_MOT_GAS);

The default to false. The other way would be via OvmsMetricInt and an
enum (or defines):

    typedef enum : uint8_t
      {
      Battery = 0,
      Gasoline = 1,
    } metric_vehicle_t;

    #define MS_V_MOT_TYPE "v.m.type"

    ms_v_mot_type = new OvmsMetricInt(MS_V_MOT_TYPE);

which would allow for more than two types.

		Craig

From chris at arachnon.de  Sat Jun 13 13:57:09 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Sat, 13 Jun 2020 07:57:09 +0200
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
Message-ID: <1592027829.2567.4.camel@arachnon.de>

Hi Craig,

I think this question could be thin ice :-)

We could start a highly political and emotional discussion on this.
Question is, do we want to support fossil fuel burning technology, or
do we want to make the statement, that the burning stuff aera is over
and if you want to use cool technology like OVMS, then come into the
future and buy an electric vehicle?

Now I'm definitly aware that there will be various different points of
view on this topic and that it is a hot topic. It is easy to drift into
arguing about how political or not OVMS should or could be and
political discussions in a large community mostly leed to emotional
discussions.

I would like to go the way Robert Llewellyn (Youtube channel
Fullycharged) went, when he started to disagree with Johnny Smith on
wether to test hybrids on the channel or not. Robert decided not to do
so, because that would be the wrong signal to the viewers. But that
decission went to the point that Johnny left the show. So, as I said,
these discussions can be thin ice :-)

I'm interested to see where we will be going on this.

Greetinx

Chris

Am Freitag, den 12.06.2020, 16:09 -0700 schrieb Craig Leres:
> I'd like to add a boolean metric for gas vehicles as a prelude to the
> phone apps having this info. Would this be ok?
> 
>     #define MS_V_MOT_GAS "v.m.gas"
> 
>     ms_v_mot_gas = new OvmsMetricBool(MS_V_MOT_GAS);
> 
> The default to false. The other way would be via OvmsMetricInt and an
> enum (or defines):
> 
>     typedef enum : uint8_t
>       {
>       Battery = 0,
>       Gasoline = 1,
>     } metric_vehicle_t;
> 
>     #define MS_V_MOT_TYPE "v.m.type"
> 
>     ms_v_mot_type = new OvmsMetricInt(MS_V_MOT_TYPE);
> 
> which would allow for more than two types.
> 
> 		Craig
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200613/b5c88b8a/attachment.html>

From dexter at expeedo.de  Sat Jun 13 21:30:55 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Sat, 13 Jun 2020 15:30:55 +0200
Subject: [Ovmsdev] File logging task
In-Reply-To: <6eac2ac1-4835-7a73-51f3-af003a43eae6@expeedo.de>
References: <6eac2ac1-4835-7a73-51f3-af003a43eae6@expeedo.de>
Message-ID: <1bc35602-d032-2d09-07b8-650a7eb3e234@expeedo.de>

I've added a simple workaround for this issue to our esp-idf fork: https://github.com/openvehicles/esp-idf/commit/9024cd38ecbc78a46ed16b79d63f57812e72b123

The workaround checks if logging is done from the timer context, if so reduces the semaphore wait time to zero, thus avoiding blocking.

That should eliminate any timer consistency issues arising from logging in timer callbacks. The disadvantage is a higher chance of such log messages getting
dropped.

Regards,
Michael


Am 05.11.19 um 21:45 schrieb Michael Balzer:
> Everyone,
>
> I've pushed the long due refactoring of the file logging into a dedicated task. This removes most of the delays involved in file logging, as the fsync() and
> log cycling now is done in the logging task and no longer blocks overall log message processing.
>
> I stumbled upon a bad thing (tm) though we need to resolve with logging: the esp-idf logging generally involves a semaphore wait of max 10 ms (!). I wasn't
> aware of this because I didn't look into the source before, there also is no warning about this in the esp-idf documentation
> (https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/log.html), so I guess I'm not the only one being taken by surprise here.
>
>     // Maximum time to wait for the mutex in a logging statement.
>     #define *MAX_MUTEX_WAIT_MS 10*
>     #define MAX_MUTEX_WAIT_TICKS ((MAX_MUTEX_WAIT_MS + portTICK_PERIOD_MS - 1) / portTICK_PERIOD_MS)
>     ?
>     void IRAM_ATTR *esp_log_write*(esp_log_level_t level,
>     ??????? const char* tag,
>     ??????? const char* format, ...)
>     {
>     ??? if (!s_log_mutex) {
>     ??????? s_log_mutex = xSemaphoreCreateMutex();
>     ??? }
>     ??? if (*xSemaphoreTake(s_log_mutex, MAX_MUTEX_WAIT_TICKS*) == pdFALSE) {
>     ??????? return;
>     ??? }
>     ?
>
>
> That semaphore is needed to secure the log level tag cache against parallel access, so it also affects log messages of currently disabled tags and/or levels.
>
> This means we *must not* use the standard logging from timer callbacks, at no verbosity level. But we do, partially caused by my own code serving as a bad
> example I assume -- sorry.
>
> But I've not only found direct log calls in most vehicle timer callbacks, there also are some hidden ones from calling the framework, for example marking a
> notification as read can produce a log output from Cleanup() if tracing is enabled.
>
> We need to change this short to mid term. This may be the cause of those strange timer overflow issues we've seen occasionally. It also means every debug or
> verbose log output currently in the code involves potentially multiple semaphore waits, that's for example the case for all hex dumps logged by the SIMCOM module.
>
> Our primary option is to remove all log calls from all low level framework functions and timer callbacks.
>
> A simple & quick workaround could be to extend the ESP_LOGx macros to check if they are executed in the timer task context, if so suppress the message or call
> the ESP_EARLY log function instead. That will hide these log messages from the logging framework though, if using the _EARLY_ variant they only will be sent
> to the USB port.
>
> For a better solution I thought about adding a dedicated queue & task for the initial log submission as well. That will need quite some rework to the esp-idf
> (no changes for this in the current master) but would allow to continue logging as we do now. Cons: queue submission involves some overhead & RAM, printf
> format expansion needs to be done before the tag/level check, messages may need to be dropped if the task starves or RAM gets tight, log output to consoles
> will depend on a task as well.
>
> Opinions / better ideas?
>
> Regards,
> Michael
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200613/9031297c/attachment.html>

From dexter at expeedo.de  Sat Jun 13 23:31:40 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Sat, 13 Jun 2020 17:31:40 +0200
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <1592027829.2567.4.camel@arachnon.de>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
Message-ID: <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>

My 2 cents:

We shouldn't generally exclude alternative propulsion technologies.
Battery based electric propulsion will cover the majority of future
transportation and mobility, but it won't fit every use case and every
kind of vehicle.

We should keep the core support to be for (battery) electric propulsion,
and add support for alternative technologies on a strict add-on base.

If for example a vehicle has a hydrogen based range extender, that
should be signaled by the vehicle adapter, and the system should only
then add the set of standard metrics for this particular technology.

A metric "v.m.gas" would be confusing (what kind of gas? what kind of
energy conversion?), would favorize a specific technology by it's name,
and would not be sufficient to describe arbitrary combinations of
technologies (e.g. a BEV with rocket thrusters?).

How about adding an array or set metric like "v.ext" or "v.tech", for
defined technology codes. A tag present in the metric means the
additional metrics, commands & configs for that technology are available.

Regards,
Michael


13.06.20 um 07:57 schrieb Chris van der Meijden:
> Hi Craig,
>
> I think this question could be thin ice :-)
>
> We could start a highly political and emotional discussion on this.
> Question is, do we want to support fossil fuel burning technology, or
> do we want to make the statement, that the burning stuff aera is over
> and if you want to use cool technology like OVMS, then come into the
> future and buy an electric vehicle?
>
> Now I'm definitly aware that there will be various different points of
> view on this topic and that it is a hot topic. It is easy to drift
> into arguing about how political or not OVMS should or could be and
> political discussions in a large community mostly leed to emotional
> discussions.
>
> I would like to go the way Robert Llewellyn (Youtube channel
> Fullycharged) went, when he started to disagree with Johnny Smith on
> wether to test hybrids on the channel or not. Robert decided not to do
> so, because that would be the wrong signal to the viewers. But that
> decission went to the point that Johnny left the show. So, as I said,
> these discussions can be thin ice :-)
>
> I'm interested to see where we will be going on this.
>
> Greetinx
>
> Chris
>
> Am Freitag, den 12.06.2020, 16:09 -0700 schrieb Craig Leres:
>> I'd like to add a boolean metric for gas vehicles as a prelude to the
>> phone apps having this info. Would this be ok?
>>
>>     #define MS_V_MOT_GAS "v.m.gas"
>>
>>     ms_v_mot_gas = new OvmsMetricBool(MS_V_MOT_GAS);
>>
>> The default to false. The other way would be via OvmsMetricInt and an
>> enum (or defines):
>>
>>     typedef enum : uint8_t
>>       {
>>       Battery = 0,
>>       Gasoline = 1,
>>     } metric_vehicle_t;
>>
>>     #define MS_V_MOT_TYPE "v.m.type"
>>
>>     ms_v_mot_type = new OvmsMetricInt(MS_V_MOT_TYPE);
>>
>> which would allow for more than two types.
>>
>> 		Craig
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200613/801c0748/attachment-0001.html>

From kommykt at gmail.com  Sun Jun 14 14:39:16 2020
From: kommykt at gmail.com (=?UTF-8?B?VGFtw6FzIEtvdsOhY3M=?=)
Date: Sun, 14 Jun 2020 08:39:16 +0200
Subject: [Ovmsdev] Random crash if enable notifications
In-Reply-To: <b3d55512-bf11-8197-25ce-8fb788e8f5bd@expeedo.de>
References: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>
 <3ce6a6e3-8119-f123-296c-653ba3e258b4@expeedo.de>
 <CAGpaXUt0C_rv992y+bg7-wmD8wBZ_8g+hFoVndo7YL-xG8L3+A@mail.gmail.com>
 <9e727cb7-1042-202d-c80a-b44b1e1d2f67@expeedo.de>
 <CAGpaXUthOkR9BURwJaK1PmHMgDkL4pmXH9OThJSm8e2LTpy_QA@mail.gmail.com>
 <b3d55512-bf11-8197-25ce-8fb788e8f5bd@expeedo.de>
Message-ID: <CAGpaXUuRy4KMuZKpRLLFnp76rs+gojVHzqotKip+=SQOvVxu=Q@mail.gmail.com>

Now i use 3.2.0.13 from api.openvehicles.com/firmware/ota EAP, updated via
OTA, but if enable pushover notifications, get some crash.

*Pushover Enabled* get the following crash
2020-06-11 07:15:48 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055928 Crash 12 12 1 0 abort() 1
0x4008b72f 0x4008b9c9 0x4010b023 0x4009847e 0x40098743 0x400988f5
0x400982da 0x40084351 0x400847dd 0x4000bec7 0x401c0e6d 0x401c6d9a
0x400f2d99 0x400f39d3 0x400f39cc 0x4015613d 0x4015513a 0x400f2605
0x400f2812 0x400f2889 0x400f2899  4 Exception/panic
2020-06-11 07:15:50 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055928 Crash 12 12 1 0 abort() 1
0x4008b72f 0x4008b9c9 0x4010b023 0x4009847e 0x40098743 0x400988f5
0x400982da 0x40084351 0x400847dd 0x4000bec7 0x401c0e6d 0x401c6d9a
0x400f2d99 0x400f39d3 0x400f39cc 0x4015613d 0x4015513a 0x400f2605
0x400f2812 0x400f2889 0x400f2899  4 Exception/panic
2020-06-11 07:15:52 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055928 Crash 12 12 1 0 abort() 1
0x4008b72f 0x4008b9c9 0x4010b023 0x4009847e 0x40098743 0x400988f5
0x400982da 0x40084351 0x400847dd 0x4000bec7 0x401c0e6d 0x401c6d9a
0x400f2d99 0x400f39d3 0x400f39cc 0x4015613d 0x4015513a 0x400f2605
0x400f2812 0x400f2889 0x400f2899  4 Exception/panic
2020-06-11 08:17:25 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055929 Crash 12 12 2 0 abort() 1
0x4008b72f 0x4008b9c9 0x4010b023 0x400982d3 0x40084351 0x400847dd
0x4000bec7 0x401c0e6d 0x400f2da1 0x400f39d3 0x400f39cc 0x400f39cc
0x400f39cc 0x400f39cc 0x400f39cc 0x4015613d 0x4015513a 0x400f2605
0x400f2812 0x400f2889 0x400f2899  4 Exception/panic
2020-06-11 08:17:29 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055929 Crash 12 12 2 0 abort() 1
0x4008b72f 0x4008b9c9 0x4010b023 0x400982d3 0x40084351 0x400847dd
0x4000bec7 0x401c0e6d 0x400f2da1 0x400f39d3 0x400f39cc 0x400f39cc
0x400f39cc 0x400f39cc 0x400f39cc 0x4015613d 0x4015513a 0x400f2605
0x400f2812 0x400f2889 0x400f2899  4 Exception/panic
2020-06-11 11:11:37 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055930 Crash 12 12 3 0 abort() 1
0x4008b72f 0x4008b9c9 0x4010b023 0x400982d3 0x40084351 0x400847dd
0x4000bec7 0x401c0e6d 0x401c6d9a 0x400f2d99 0x400f39d3 0x400f39cc
0x4015613d 0x4015513a 0x400f2605 0x400f2812 0x400f2889 0x400f2899  4
Exception/panic
2020-06-11 17:16:13 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055931 Crash 12 12 4 0 abort() 1
0x4008b72f 0x4008b9c9 0x4010b023 0x400982d3 0x40084351 0x400847dd
0x4000bec7 0x401c0e6d 0x400f2da1 0x400f39d3 0x400f39cc 0x400f39cc
0x400f39cc 0x400f39cc 0x400f39cc 0x4015613d 0x4015513a 0x400f2605
0x400f2812 0x400f2889 0x400f2899  4 Exception/panic

*Pushover disabled:*




2020-06-13 13:19:33 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055932 Crash 12 12 5 0 abort() 0
0x4008b72f 0x4008b9c9 0x400e6abc 0x4008404a  6 Task watchdog
2020-06-13 15:08:28 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055933 Crash 12 12 6 0 abort() 0
0x4008b72f 0x4008b9c9 0x400e6abc 0x4008404a  6 Task watchdog
2020-06-13 18:22:30 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055934 Crash 12 12 7 0 abort() 0
0x4008b72f 0x4008b9c9 0x400e6abc 0x4008404a  6 Task watchdog
2020-06-13 19:26:15 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055935 Crash 12 12 8 0 abort() 0
0x4008b72f 0x4008b9c9 0x400e6abc 0x4008404a  6 Task watchdog


Michael Balzer <dexter at expeedo.de> ezt ?rta (id?pont: 2020. j?n. 8., H,
20:39):

> I cannot tell if you did the correct setup for the spiram fix.
>
> You need
> - the new toolchain
> - the new libs
> - the spiram esp-idf branch
> - the spiram ovms branch
>
> If you've got all of this, then the crash isn't related to the SPIRAM bug.
>
> Regards,
> Michael
>
>
> Am 07.06.20 um 07:50 schrieb Tam?s Kov?cs:
>
> I downloaded this toolchain and use it: build idf
> v3.3-beta3-776-g3d198cd50
> I checkout esp-idf to spiram-fix-test branch.
>
> I use a forked repo.
> I run the following to update to spiram-fix-test, on my local repo.
> git fetch upstream
> git pull upstream/spiram-fix-test master
>
> But i now get crash the last is:
> Last crash: abort() was called on core 1 Backtrace: 0x4008ace7 0x4008af7d
> 0x4010badf 0x40097d93 0x40083ffd 0x400845f1 0x4000bec7 0x4012c729
> 0x402a1815 0x401eb40d 0x401f7a26 0x401f8af0 0x40207065 0x40206f45
> 0x40207133 0x40206faf 0x402073b6 0x4020747d 0x401f4445 0x401f3344
> 0x401f3677 0x401f441e 0x402079d1 0x401f76e5 0x401f7892 0x40202ea6
> 0x4012db9a 0x4012dd9d
>
> kommykt at MacBook-Air OVMS.V3 % a2l 0x4008ace7 0x4008af7d 0x4010badf
> 0x40097d93 0x40083ffd 0x400845f1 0x4000bec7 0x4012c729 0x402a1815
> 0x401eb40d 0x401f7a26 0x401f8af0 0x40207065 0x40206f45 0x40207133
> 0x40206faf 0x402073b6 0x4020747d 0x401f4445 0x401f3344 0x401f3677
> 0x401f441e 0x402079d1 0x401f76e5 0x401f7892 0x40202ea6 0x4012db9a 0x4012dd9d
>
> Using elf file:
> /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>
> 0x4008ace7 is in invoke_abort
> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>
> 151 #endif
>
> 152     while (1) {
>
> 153         if (esp_cpu_in_ocd_debug_mode()) {
>
> 154             __asm__ ("break 0,0");
>
> 155         }
>
> 156         *((int *) 0) = 0;
>
> 157     }
>
> 158 }
>
> 159
>
> 160 void abort()
>
> 0x4008af7d is in abort
> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>
> 166     * don't overwrite that.
>
> 167     */
>
> 168     if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>
> 169         esp_reset_reason_set_hint(ESP_RST_PANIC);
>
> 170     }
>
> 171     invoke_abort();
>
> 172 }
>
> 173
>
> 174
>
> 175 static const char *edesc[] = {
>
> 0x4010badf is in __assert_func
> (../../../.././newlib/libc/stdlib/assert.c:63).
>
> 0x40097d93 is in multi_heap_free
> (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>
> 209         return;
>
> 210     }
>
> 211     multi_heap_internal_lock(heap);
>
> 212
>
> 213     poison_head_t *head = verify_allocated_region(p, true);
>
> 214     assert(head != NULL);
>
> 215
>
> 216     #ifdef SLOW
>
> 217     /* replace everything with FREE_FILL_PATTERN, including the
> poison head/tail */
>
> 218     memset(head, FREE_FILL_PATTERN,
>
> 0x40083ffd is in heap_caps_free
> (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>
> 263         ptr = (void *)dramAddrPtr[-1];
>
> 264     }
>
> 265
>
> 266     heap_t *heap = find_containing_heap(ptr);
>
> 267     assert(heap != NULL && "free() target pointer is outside heap
> areas");
>
> 268     multi_heap_free(heap->heap, ptr);
>
> 269 }
>
> 270
>
> 271 IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>
> 272 {
>
> 0x400845f1 is in _free_r
> (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>
> 37     return heap_caps_malloc_default( size );
>
> 38 }
>
> 39
>
> 40 void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>
> 41 {
>
> 42     heap_caps_free( ptr );
>
> 43 }
>
> 44
>
> 45 void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>
> 46 {
>
> 0x4012c729 is in DukOvmsFree(void*, void*)
> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:442).
>
> 437   return ExternalRamRealloc(ptr, size);
>
> 438   }
>
> 439
>
> 440 void DukOvmsFree(void *udata, void *ptr)
>
> 441   {
>
> 442   free(ptr);
>
> 443   }
>
> 444
>
> 445 void DukOvmsFatalHandler(void *udata, const char *msg)
>
> 446   {
>
> 0x402a1815 is in duk_heap_mem_free (duk_heap_memory.c:406).
>
> 0x401eb40d is in duk__refcount_refzero_hstring (duk_heap_alloc.c:103).
>
> 0x401f7a26 is in duk_heaphdr_refzero (duk_heap_refcount.c:630).
>
> 0x401f8af0 is in duk_pop_2 (duk_api_stack.c:6089).
>
> 0x40207065 is in duk__enc_value (duk_bi_json.c:2240).
>
> 0x40206f45 is in duk__enc_value (duk_bi_json.c:1951).
>
> 1946 in duk_bi_json.c
>
> 0x40207133 is in duk__enc_object (duk_bi_json.c:1885).
>
> 1880 in duk_bi_json.c
>
> 0x40206faf is in duk__enc_value (duk_bi_json.c:2203).
>
> 2198 in duk_bi_json.c
>
> 0x402073b6 is in duk_bi_json_stringify_helper (duk_bi_json.c:3191).
>
> 3186 in duk_bi_json.c
>
> 0x4020747d is in duk_bi_duktape_object_enc (duk_bi_duktape.c:96).
>
> 0x401f4445 is in duk__handle_call_raw (duk_js_call.c:2276).
>
> 0x401f3344 is in duk__js_execute_bytecode_inner (duk_js_call.c:2422).
>
> 2417 in duk_js_call.c
>
> 0x401f3677 is in duk_js_execute_bytecode (duk_js_executor.c:2956).
>
> 0x401f441e is in duk__handle_call_raw (duk_js_call.c:2246).
>
> 0x402079d1 is in duk__pcall_method_raw (duk_js_call.c:2422).
>
> 2417 in duk_js_call.c
>
> 0x401f76e5 is in duk_handle_safe_call (duk_js_call.c:2475).
>
> 2470 in duk_js_call.c
>
> 0x401f7892 is in duk_safe_call (duk_api_call.c:318).
>
> 0x40202ea6 is in duk_pcall_method (duk_api_call.c:242).
>
> 237 in duk_api_call.c
>
> 0x4012db9a is in OvmsScripts::DukTapeTask()
> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:2273).
>
> 2268             duk_get_global_string(m_dukctx, "PubSub");
>
> 2269             duk_get_prop_string(m_dukctx, -1, "publish");
>
> 2270             duk_dup(m_dukctx, -2);  /* this binding = process */
>
> 2271             duk_push_string(m_dukctx, msg.body.dt_event.name);
>
> 2272             duk_push_string(m_dukctx, "");
>
> 2273             if (duk_pcall_method(m_dukctx, 2) != 0)
>
> 2274               {
>
> 2275               DukOvmsErrorHandler(m_dukctx, -1);
>
> 2276               }
>
> 2277             duk_pop_2(m_dukctx);
>
> 0x4012dd9d is in DukTapeLaunchTask(void*)
> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:427).
>
> 422
>
> 423 void DukTapeLaunchTask(void *pvParameters)
>
> 424   {
>
> 425   OvmsScripts* me = (OvmsScripts*)pvParameters;
>
> 426
>
> 427   me->DukTapeTask();
>
> 428   }
>
> 429
>
> 430 void* DukOvmsAlloc(void *udata, duk_size_t size)
>
> 431   {
>
>
> Michael Balzer <dexter at expeedo.de> ezt ?rta (id?pont: 2020. j?n. 5., P,
> 21:43):
>
>> See previous posts on this, you also need the fixed toolchain:
>> https://github.com/espressif/esp-idf/issues/2892#issuecomment-501106283
>>
>> Regards,
>> Michael
>>
>>
>> Am 05.06.20 um 20:04 schrieb Tam?s Kov?cs:
>>
>> i think i don't run spiram fix. How can i use it. I must check out
>> branch "spiram-fix-test"  to run spiram fix?
>>
>> Michael Balzer <dexter at expeedo.de> ezt ?rta (id?pont: 2020. j?n. 5., P,
>> 6:58):
>>
>>> Tam?s,
>>>
>>> that doesn't need to be related to the pushover code. Do you run the
>>> spiram fix? I had this kind of heap corruption crashes frequently on builds
>>> without the spiram fix but not once with the fix.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> Am 05.06.20 um 05:29 schrieb Tam?s Kov?cs:
>>>
>>> Some day's ago i enabled Pushover notifications and i get some crash
>>> after that.
>>>
>>> The crash backtrase is:
>>> Backtrace: 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361
>>> 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4
>>> 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545
>>> 0x400f375e 0x400f37d5 0x400f37e5
>>> a2l output is:
>>>
>>> kommykt at MacBook-Air OVMS.V3 % a2l 0x4008b75f 0x4008b9f9 0x4010b253
>>> 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1
>>> 0x400f0dbb 0x400f0db4 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109
>>> 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>>>
>>> Using elf file:
>>> /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>>>
>>>
>>> 0x4008b75f is in invoke_abort
>>> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>>>
>>> 151 #endif
>>>
>>> 152     while (1) {
>>>
>>> 153         if (esp_cpu_in_ocd_debug_mode()) {
>>>
>>> 154             __asm__ ("break 0,0");
>>>
>>> 155         }
>>>
>>> 156         *((int *) 0) = 0;
>>>
>>> 157     }
>>>
>>> 158 }
>>>
>>> 159
>>>
>>> 160 void abort()
>>>
>>>
>>> 0x4008b9f9 is in abort
>>> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>>>
>>> 166     * don't overwrite that.
>>>
>>> 167     */
>>>
>>> 168     if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>>>
>>> 169         esp_reset_reason_set_hint(ESP_RST_PANIC);
>>>
>>> 170     }
>>>
>>> 171     invoke_abort();
>>>
>>> 172 }
>>>
>>> 173
>>>
>>> 174
>>>
>>> 175 static const char *edesc[] = {
>>>
>>>
>>> 0x4010b253 is in __assert_func
>>> (../../../.././newlib/libc/stdlib/assert.c:63).
>>>
>>>
>>> 0x40098c5f is in multi_heap_free
>>> (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>>>
>>> 209         return;
>>>
>>> 210     }
>>>
>>> 211     multi_heap_internal_lock(heap);
>>>
>>> 212
>>>
>>> 213     poison_head_t *head = verify_allocated_region(p, true);
>>>
>>> 214     assert(head != NULL);
>>>
>>> 215
>>>
>>> 216     #ifdef SLOW
>>>
>>> 217     /* replace everything with FREE_FILL_PATTERN, including the
>>> poison head/tail */
>>>
>>> 218     memset(head, FREE_FILL_PATTERN,
>>>
>>>
>>> 0x40084361 is in heap_caps_free
>>> (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>>>
>>> 263         ptr = (void *)dramAddrPtr[-1];
>>>
>>> 264     }
>>>
>>> 265
>>>
>>> 266     heap_t *heap = find_containing_heap(ptr);
>>>
>>> 267     assert(heap != NULL && "free() target pointer is outside heap
>>> areas");
>>>
>>> 268     multi_heap_free(heap->heap, ptr);
>>>
>>> 269 }
>>>
>>> 270
>>>
>>> 271 IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>>>
>>> 272 {
>>>
>>>
>>> 0x40084945 is in _free_r
>>> (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>>>
>>> 37     return heap_caps_malloc_default( size );
>>>
>>> 38 }
>>>
>>> 39
>>>
>>> 40 void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>>>
>>> 41 {
>>>
>>> 42     heap_caps_free( ptr );
>>>
>>> 43 }
>>>
>>> 44
>>>
>>> 45 void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>>>
>>> 46 {
>>>
>>>
>>> 0x401c1181 is in operator delete(void*)
>>> (/Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/del_op.cc:46).
>>>
>>>
>>> 0x400f01e1 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >,
>>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >
>>> >::_M_drop_node(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >*)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110).
>>>
>>> 105       }
>>>
>>> 106
>>>
>>> 107       // __p is not permitted to be a null pointer.
>>>
>>> 108       void
>>>
>>> 109       deallocate(pointer __p, size_type)
>>>
>>> 110       { ::operator delete(__p); }
>>>
>>> 111
>>>
>>> 112       size_type
>>>
>>> 113       max_size() const _GLIBCXX_USE_NOEXCEPT
>>>
>>> 114       { return size_t(-1) / sizeof(_Tp); }
>>>
>>>
>>> 0x400f0dbb is in std::_Rb_tree<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >,
>>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >
>>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >*)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1614).
>>>
>>> 1609       // Erase without rebalancing.
>>>
>>> 1610       while (__x != 0)
>>>
>>> 1611 {
>>>
>>> 1612   _M_erase(_S_right(__x));
>>>
>>> 1613   _Link_type __y = _S_left(__x);
>>>
>>> 1614   _M_drop_node(__x);
>>>
>>> 1615   __x = __y;
>>>
>>> 1616 }
>>>
>>> 1617     }
>>>
>>> 1618
>>>
>>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >,
>>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >
>>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >*)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>> 1607     _M_erase(_Link_type __x)
>>>
>>> 1608     {
>>>
>>> 1609       // Erase without rebalancing.
>>>
>>> 1610       while (__x != 0)
>>>
>>> 1611 {
>>>
>>> 1612   _M_erase(_S_right(__x));
>>>
>>> 1613   _Link_type __y = _S_left(__x);
>>>
>>> 1614   _M_drop_node(__x);
>>>
>>> 1615   __x = __y;
>>>
>>> 1616 }
>>>
>>>
>>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >,
>>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >
>>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >*)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>> 1607     _M_erase(_Link_type __x)
>>>
>>> 1608     {
>>>
>>> 1609       // Erase without rebalancing.
>>>
>>> 1610       while (__x != 0)
>>>
>>> 1611 {
>>>
>>> 1612   _M_erase(_S_right(__x));
>>>
>>> 1613   _Link_type __y = _S_left(__x);
>>>
>>> 1614   _M_drop_node(__x);
>>>
>>> 1615   __x = __y;
>>>
>>> 1616 }
>>>
>>>
>>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >,
>>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >
>>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >*)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>> 1607     _M_erase(_Link_type __x)
>>>
>>> 1608     {
>>>
>>> 1609       // Erase without rebalancing.
>>>
>>> 1610       while (__x != 0)
>>>
>>> 1611 {
>>>
>>> 1612   _M_erase(_S_right(__x));
>>>
>>> 1613   _Link_type __y = _S_left(__x);
>>>
>>> 1614   _M_drop_node(__x);
>>>
>>> 1615   __x = __y;
>>>
>>> 1616 }
>>>
>>>
>>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >,
>>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >
>>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >*)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>> 1607     _M_erase(_Link_type __x)
>>>
>>> 1608     {
>>>
>>> 1609       // Erase without rebalancing.
>>>
>>> 1610       while (__x != 0)
>>>
>>> 1611 {
>>>
>>> 1612   _M_erase(_S_right(__x));
>>>
>>> 1613   _Link_type __y = _S_left(__x);
>>>
>>> 1614   _M_drop_node(__x);
>>>
>>> 1615   __x = __y;
>>>
>>> 1616 }
>>>
>>>
>>> 0x40156109 is in
>>> Pushover::EventListener(std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >, void*)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:858).
>>>
>>> 853
>>>
>>> 854       _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a);
>>>
>>> 855 #endif
>>>
>>> 856
>>>
>>> 857       ~_Rb_tree() _GLIBCXX_NOEXCEPT
>>>
>>> 858       { _M_erase(_M_begin()); }
>>>
>>> 859
>>>
>>> 860       _Rb_tree&
>>>
>>> 861       operator=(const _Rb_tree& __x);
>>>
>>> 862
>>>
>>> 0x401550da is in std::_Function_handler<void
>>> (std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> >, void*), std::_Bind<std::_Mem_fn<void
>>> (Pushover::*)(std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> >, void*)> (Pushover*, std::_Placeholder<1>,
>>> std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> >&&, void*&&)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600).
>>>
>>> 595       template<typename... _Args, typename _Req
>>>
>>> 596               = _Require<typename _Traits::__lvalue,
>>>
>>> 597                           _CheckArgs<_Pack<_Args...>>>>
>>>
>>> 598 result_type
>>>
>>> 599 operator()(_Class* __object, _Args&&... __args) const
>>>
>>> 600 { return (__object->*_M_pmf)(std::forward<_Args>(__args)...); }
>>>
>>> 601
>>>
>>> 602       // Handle smart pointers, references and pointers to derived
>>>
>>> 603       template<typename _Tp, typename... _Args, typename _Req
>>>
>>> 604               = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*,
>>> _Tp>,
>>>
>>>
>>> 0x400f3545 is in std::function<void (std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >,
>>> void*)>::operator()(std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >, void*) const
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271).
>>>
>>> 2266     function<_Res(_ArgTypes...)>::
>>>
>>> 2267     operator()(_ArgTypes... __args) const
>>>
>>> 2268     {
>>>
>>> 2269       if (_M_empty())
>>>
>>> 2270 __throw_bad_function_call();
>>>
>>> 2271       return _M_invoker(_M_functor,
>>> std::forward<_ArgTypes>(__args)...);
>>>
>>> 2272     }
>>>
>>> 2273
>>>
>>> 2274 #if __cpp_rtti
>>>
>>> 2275   template<typename _Res, typename... _ArgTypes>
>>>
>>>
>>> 0x400f375e is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*)
>>> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:234).
>>>
>>> 229       {
>>>
>>> 230       for (EventCallbackList::iterator itc=el->begin();
>>> itc!=el->end(); ++itc)
>>>
>>> 231         {
>>>
>>> 232         m_current_started = monotonictime;
>>>
>>> 233         m_current_callback = *itc;
>>>
>>> 234         m_current_callback->m_callback(m_current_event,
>>> msg->body.signal.data);
>>>
>>> 235         m_current_callback = NULL;
>>>
>>> 236         }
>>>
>>> 237       }
>>>
>>> 238     }
>>>
>>>
>>> 0x400f37d5 is in OvmsEvents::EventTask()
>>> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:185).
>>>
>>> 180       switch(msg.type)
>>>
>>> 181         {
>>>
>>> 182         case EVENT_none:
>>>
>>> 183           break;
>>>
>>> 184         case EVENT_signal:
>>>
>>> 185           HandleQueueSignalEvent(&msg);
>>>
>>> 186           break;
>>>
>>> 187         default:
>>>
>>> 188           break;
>>>
>>> 189         }
>>>
>>>
>>> 0x400f37e5 is in EventLaunchTask(void*)
>>> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:56).
>>>
>>> 51
>>>
>>> 52 void EventLaunchTask(void *pvParameters)
>>>
>>> 53   {
>>>
>>> 54   OvmsEvents* me = (OvmsEvents*)pvParameters;
>>>
>>> 55
>>>
>>> 56   me->EventTask();
>>>
>>> 57   }
>>>
>>> 58
>>>
>>> 59 void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand*
>>> cmd, int argc, const char* const* argv)
>>>
>>> 60   {
>>>
>>> --
>>> ?dv?zlettel:
>>> Kov?cs Tam?s
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>> --
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>
>>
>> --
>> ?dv?zlettel:
>> Kov?cs Tam?s
>>
>>
>> _______________________________________________
>> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>> --
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>
>
> --
> ?dv?zlettel:
> Kov?cs Tam?s
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>


-- 
?dv?zlettel:
Kov?cs Tam?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200614/db16dd53/attachment-0001.html>

From leres at xse.com  Sun Jun 14 23:21:27 2020
From: leres at xse.com (Craig Leres)
Date: Sun, 14 Jun 2020 08:21:27 -0700
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
 <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
Message-ID: <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>

On 2020-06-13 08:31, Michael Balzer wrote:
> How about adding an array or set metric like "v.ext" or "v.tech", for
> defined technology codes. A tag present in the metric means the
> additional metrics, commands & configs for that technology are available.

My goal is to make it possible for the app to depict soc with something
other than a battery graphic when the energy source is not a battery.
How about v.tech with "battery" and "other" as the initial two possible
values?

		Craig

From chris at arachnon.de  Mon Jun 15 00:59:33 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Sun, 14 Jun 2020 18:59:33 +0200
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
 <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
 <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>
Message-ID: <1592153973.13853.18.camel@arachnon.de>

Thank you for considering my thoughts.
I believe it is a good idea to use a v.tech variable and not using gas
or gazoline. That gives OVMS enough flexibility and is also a?(little)
statement.
I'm also looking forward to rocket propulsion add ons :-))
Greetinx
Chris

Am Sonntag, den 14.06.2020, 08:21 -0700 schrieb Craig Leres:
> On 2020-06-13 08:31, Michael Balzer wrote:
> > How about adding an array or set metric like "v.ext" or "v.tech",
> > for
> > defined technology codes. A tag present in the metric means the
> > additional metrics, commands & configs for that technology are
> > available.
> 
> My goal is to make it possible for the app to depict soc with
> something
> other than a battery graphic when the energy source is not a battery.
> How about v.tech with "battery" and "other" as the initial two
> possible
> values?
> 
> 		Craig
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200614/29d52cdb/attachment.html>

From dexter at expeedo.de  Mon Jun 15 02:46:01 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Sun, 14 Jun 2020 20:46:01 +0200
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <1592153973.13853.18.camel@arachnon.de>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
 <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
 <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>
 <1592153973.13853.18.camel@arachnon.de>
Message-ID: <3ea9f7cc-82d3-3a14-30f3-1dd9d8505894@expeedo.de>

Craig,

I strictly vote against re-interpretation of the SOC metric. Where
metrics have clear semantics we should not make them dependent on some
context.

A battery is not a fuel tank, and vehicles may have both. "v.b." is the
namespace "vehicle battery" and shall not be populated with non-battery
metrics.

That's what I meant by adding technology specific metrics: if the
vehicle has a fuel tank, additional standard metrics describing that
fuel tank shall be present.

Fuel tank specific metrics might e.g. get the namespace "v.ft.", ICE
engine specific metrics might get "v.ice.", fuel cell metrics "v.fc.",
rocket thruster metrics "v.rt." ? you get the idea.

Make a proposition for the metrics sets you need. Try to define them as
generalized as possible.

That will probably include duplicates of some metrics, like the ranges &
consumption. That's necessary to be able to describe a hybrid, and some
units among those will also need to be different (e.g. consumption in
litres / m? per km).

Regards,
Michael


Am 14.06.20 um 18:59 schrieb Chris van der Meijden:
> Thank you for considering my thoughts.
>
> I believe it is a good idea to use a v.tech variable and not using gas
> or gazoline. That gives OVMS enough flexibility and is also a?(little)
> statement.
>
> I'm also looking forward to rocket propulsion add ons :-))
>
> Greetinx
>
> Chris
>
>
> Am Sonntag, den 14.06.2020, 08:21 -0700 schrieb Craig Leres:
>> On 2020-06-13 08:31, Michael Balzer wrote:
>>> How about adding an array or set metric like "v.ext" or "v.tech",
>>> for defined technology codes. A tag present in the metric means the
>>> additional metrics, commands & configs for that technology are
>>> available. 
>>
>>
>> My goal is to make it possible for the app to depict soc with something
>> other than a battery graphic when the energy source is not a battery.
>> How about v.tech with "battery" and "other" as the initial two possible
>> values?
>>
>> 		Craig
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200614/80aef29a/attachment.html>

From mark at webb-johnson.net  Mon Jun 15 10:27:52 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Mon, 15 Jun 2020 10:27:52 +0800
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <3ea9f7cc-82d3-3a14-30f3-1dd9d8505894@expeedo.de>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
 <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
 <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>
 <1592153973.13853.18.camel@arachnon.de>
 <3ea9f7cc-82d3-3a14-30f3-1dd9d8505894@expeedo.de>
Message-ID: <F24DA1A4-AB81-4AB7-A689-A638C32484DC@webb-johnson.net>


I think the core principle of the ?Open? in ?Open Vehicle Monitoring System? is that we should not restrict any uses, no matter our personal opinions.

Regarding the metrics themselves, I agree with Michael. The v.b namespace is intended for vehicle battery metrics. Perhaps we can simply add another namespace ?v.ice? for internal combustion engine fuels?

Note that OBDII defines standard fuel type codings (service 01 PID 51):

Value	Description
0	Not available
1	Gasoline
2	Methanol
3	Ethanol
4	Diesel
5	LPG <https://en.wikipedia.org/wiki/Liquefied_petroleum_gas>
6	CNG <https://en.wikipedia.org/wiki/Compressed_natural_gas>
7	Propane
8	Electric
9	Bifuel <https://en.wikipedia.org/wiki/Bi-fuel_vehicle> running Gasoline
10	Bifuel running Methanol
11	Bifuel running Ethanol
12	Bifuel running LPG
13	Bifuel running CNG
14	Bifuel running Propane
15	Bifuel running Electricity
16	Bifuel running electric and combustion engine
17	Hybrid gasoline
18	Hybrid Ethanol
19	Hybrid Diesel
20	Hybrid Electric
21	Hybrid running electric and combustion engine
22	Hybrid Regenerative
23	Bifuel running diesel

A ?v.fueltype? metric makes sense for this. Perhaps just use the full OBDII list (which supports hybrids). For ICE vehicles, keeping to standard OBDII PIDs is probably the simplest and most standardised approach. So, ?v.ice.tank.level?, or something like that (OBDII PID 0x2f).

Regarding the Apps support for this (and other things), that is something I am working on and trying to prototype. I will eMail separately regarding this.

Regards, Mark.

> On 15 Jun 2020, at 2:46 AM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> Craig,
> 
> I strictly vote against re-interpretation of the SOC metric. Where metrics have clear semantics we should not make them dependent on some context.
> 
> A battery is not a fuel tank, and vehicles may have both. "v.b." is the namespace "vehicle battery" and shall not be populated with non-battery metrics.
> 
> That's what I meant by adding technology specific metrics: if the vehicle has a fuel tank, additional standard metrics describing that fuel tank shall be present.
> 
> Fuel tank specific metrics might e.g. get the namespace "v.ft.", ICE engine specific metrics might get "v.ice.", fuel cell metrics "v.fc.", rocket thruster metrics "v.rt." ? you get the idea.
> 
> Make a proposition for the metrics sets you need. Try to define them as generalized as possible.
> 
> That will probably include duplicates of some metrics, like the ranges & consumption. That's necessary to be able to describe a hybrid, and some units among those will also need to be different (e.g. consumption in litres / m? per km).
> 
> Regards,
> Michael
> 
> 
> Am 14.06.20 um 18:59 schrieb Chris van der Meijden:
>> Thank you for considering my thoughts.
>> 
>> I believe it is a good idea to use a v.tech variable and not using gas or gazoline. That gives OVMS enough flexibility and is also a (little) statement.
>> 
>> I'm also looking forward to rocket propulsion add ons :-))
>> 
>> Greetinx
>> 
>> Chris
>> 
>> 
>> Am Sonntag, den 14.06.2020, 08:21 -0700 schrieb Craig Leres:
>>> On 2020-06-13 08:31, Michael Balzer wrote:
>>>> 
>>>> How about adding an array or set metric like "v.ext" or "v.tech", for
>>>> defined technology codes. A tag present in the metric means the
>>>> additional metrics, commands & configs for that technology are available.
>>> 
>>> 
>>> My goal is to make it possible for the app to depict soc with something
>>> other than a battery graphic when the energy source is not a battery.
>>> How about v.tech with "battery" and "other" as the initial two possible
>>> values?
>>> 
>>> 		Craig
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> 
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/19f74814/attachment-0001.html>

From mark at webb-johnson.net  Mon Jun 15 13:55:10 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Mon, 15 Jun 2020 13:55:10 +0800
Subject: [Ovmsdev] File logging task
In-Reply-To: <1bc35602-d032-2d09-07b8-650a7eb3e234@expeedo.de>
References: <6eac2ac1-4835-7a73-51f3-af003a43eae6@expeedo.de>
 <1bc35602-d032-2d09-07b8-650a7eb3e234@expeedo.de>
Message-ID: <AC2DA22E-F65F-4D75-AA65-5C12C829B0A4@webb-johnson.net>


Do you think that the overhead of the logging framework is impacting performance of things like SSH/SCP and SIMCOM async? Kind of related to the issue I raised about the infinite loop caused by debug logging on the web console and ssh (when those are already receiving log monitor output) - logging the logging.

It seems using ESP_EARLY would avoid this? Or a cleanup to move such logging to verbose level, other stuff at debug level, and a restriction on web client and ssh to never log monitor above debug level?

Regards, Mark.

> On 13 Jun 2020, at 9:30 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> I've added a simple workaround for this issue to our esp-idf fork: https://github.com/openvehicles/esp-idf/commit/9024cd38ecbc78a46ed16b79d63f57812e72b123 <https://github.com/openvehicles/esp-idf/commit/9024cd38ecbc78a46ed16b79d63f57812e72b123>
> 
> The workaround checks if logging is done from the timer context, if so reduces the semaphore wait time to zero, thus avoiding blocking.
> 
> That should eliminate any timer consistency issues arising from logging in timer callbacks. The disadvantage is a higher chance of such log messages getting dropped.
> 
> Regards,
> Michael
> 
> 
> Am 05.11.19 um 21:45 schrieb Michael Balzer:
>> Everyone,
>> 
>> I've pushed the long due refactoring of the file logging into a dedicated task. This removes most of the delays involved in file logging, as the fsync() and log cycling now is done in the logging task and no longer blocks overall log message processing.
>> 
>> I stumbled upon a bad thing (tm) though we need to resolve with logging: the esp-idf logging generally involves a semaphore wait of max 10 ms (!). I wasn't aware of this because I didn't look into the source before, there also is no warning about this in the esp-idf documentation (https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/log.html <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/log.html>), so I guess I'm not the only one being taken by surprise here.
>> 
>> // Maximum time to wait for the mutex in a logging statement.
>> #define MAX_MUTEX_WAIT_MS 10
>> #define MAX_MUTEX_WAIT_TICKS ((MAX_MUTEX_WAIT_MS + portTICK_PERIOD_MS - 1) / portTICK_PERIOD_MS)
>> ?
>> void IRAM_ATTR esp_log_write(esp_log_level_t level,
>>         const char* tag,
>>         const char* format, ...)
>> {
>>     if (!s_log_mutex) {
>>         s_log_mutex = xSemaphoreCreateMutex();
>>     }
>>     if (xSemaphoreTake(s_log_mutex, MAX_MUTEX_WAIT_TICKS) == pdFALSE) {
>>         return;
>>     }
>> ?
>> 
>> That semaphore is needed to secure the log level tag cache against parallel access, so it also affects log messages of currently disabled tags and/or levels.
>> 
>> This means we must not use the standard logging from timer callbacks, at no verbosity level. But we do, partially caused by my own code serving as a bad example I assume -- sorry.
>> 
>> But I've not only found direct log calls in most vehicle timer callbacks, there also are some hidden ones from calling the framework, for example marking a notification as read can produce a log output from Cleanup() if tracing is enabled.
>> 
>> We need to change this short to mid term. This may be the cause of those strange timer overflow issues we've seen occasionally. It also means every debug or verbose log output currently in the code involves potentially multiple semaphore waits, that's for example the case for all hex dumps logged by the SIMCOM module.
>> 
>> Our primary option is to remove all log calls from all low level framework functions and timer callbacks.
>> 
>> A simple & quick workaround could be to extend the ESP_LOGx macros to check if they are executed in the timer task context, if so suppress the message or call the ESP_EARLY log function instead. That will hide these log messages from the logging framework though, if using the _EARLY_ variant they only will be sent to the USB port.
>> 
>> For a better solution I thought about adding a dedicated queue & task for the initial log submission as well. That will need quite some rework to the esp-idf (no changes for this in the current master) but would allow to continue logging as we do now. Cons: queue submission involves some overhead & RAM, printf format expansion needs to be done before the tag/level check, messages may need to be dropped if the task starves or RAM gets tight, log output to consoles will depend on a task as well.
>> 
>> Opinions / better ideas?
>> 
>> Regards,
>> Michael
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> 
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/d6cd8211/attachment.html>

From mark at webb-johnson.net  Mon Jun 15 15:00:56 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Mon, 15 Jun 2020 15:00:56 +0800
Subject: [Ovmsdev] Cross Platform Unified App
Message-ID: <0DB4B4E5-CA50-4B98-8469-BDD171252B42@webb-johnson.net>


As you may know, I?ve been working for some time on the design of a cross platform unified App for OVMS. Here are my thoughts.

I think our approach of the ?virtual vehicle?, represented by a hash/set of metric->value, works well. We have been successful in providing common vehicle metrics for more than a dozen different types of electric vehicle, plus a bunch of other generic types. Overall, I think this is the correct approach, and lends itself very well to the IoT MQTT way of doing things.

Maintaining two separate Apps on two different platforms has been difficult, and the features and functionality are diverging too much.

The v2 protocol is too limiting (especially for new vehicle types, and custom metrics).

I like the idea of providing a ?templated? approach to the displays in the Apps. We design templates to pick metrics, along with other assets, and display their current values updated in real time.

By leveraging the ?virtual vehicle? model, we can also introduce the concept of vehicle sources. At the moment, we are limited to just one vehicle data source - OVMS protocol v2, and to some extent the apps already convert the incoming v2 data into a hard-coded set of metrics, with hard-coded display layouts. The purpose of these vehicle sources is to login to a remote server, retrieve the vehicle data, and store it as the standardised metrics, in the standardised ?virtual vehicle?. Example sources could be OVMS protocol v2, OVMS protocol v3 (MQTT), Tesla API, Carwings API, direct bluetooth to an OVMS module, etc. We could virtualise these protocols, with a common interface.

So, my proposal is:

We develop a single universal App, coded in a ?free? open environment. I have looked at Xamarin and Phonegap (vue-js, and a bunch of alternatives in common use nowadays). My current preference is vue-js, as it seems that javascript and html lend themselves best to the templated display approach - it is trivial to dynamically load this content. That, plus the environment is truly free and well understood by a huge developer community. However, no decision has been made and I am open to suggestions.

The App implements a virtual protocol system. Each virtual protocol talks a particular backend API for a particular account. The virtual protocol then publishes vehicles for the user to choose from. Initially we would write an OVMS v2 protocol implementation, but others (as previously listed) should be relatively easy to implement.

The App implements a virtual vehicle system. Each virtual protocol converts the incoming vehicle data to the virtual vehicle metrics. We can base this simply on the OVMS v3 standardised metrics, but custom metrics also need to be supported. Commands to be sent to the vehicle can also be implemented in a similar way. The OVMS v3 MQTT protocol would be a 1-to-1 mapping here, for example.

The App displays are implemented via a templating system, with templates provided per vehicle type and per screen type (phone, tablet, desktop, etc). The user can customise these templates, using either named virtual vehicle metrics or other assets (pictures, buttons for commands, etc).

I feel that this approach provides an excellent balance. It allows for comprehensive support and flexibility of display for each vehicle type, without complicating the implementation. It also allows owners of more than one type of vehicle (perhaps not all supported by OVMS) to use a single App to monitor and control.

I am happy to build the framework for this, but would much prefer others to come on board to assist.

Any thoughts or suggestion are most welcome.

Regards, Mark.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/18878057/attachment.html>

From chris at arachnon.de  Mon Jun 15 15:13:00 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Mon, 15 Jun 2020 09:13:00 +0200
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <F24DA1A4-AB81-4AB7-A689-A638C32484DC@webb-johnson.net>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
 <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
 <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>
 <1592153973.13853.18.camel@arachnon.de>
 <3ea9f7cc-82d3-3a14-30f3-1dd9d8505894@expeedo.de>
 <F24DA1A4-AB81-4AB7-A689-A638C32484DC@webb-johnson.net>
Message-ID: <1592205180.2530.1.camel@arachnon.de>

Sorry, I disagree.
I think "Open" stands for open source and open source should also mean
being open to discussions. And discussions involve personal opinions.
IMHO supporting internal combustion engines in OVMS is a bad idea in
times of climate change. It is the wrong signal if we do so.?
I do not??want to "over discuss" this, but it is important enough for
me suggest not to implement support for ICE engines.
Greetinx
Chris

Am Montag, den 15.06.2020, 10:27 +0800 schrieb Mark Webb-Johnson:
> I think the core principle of the ?Open? in ?Open Vehicle Monitoring
> System? is that we should not restrict any uses, no matter our
> personal opinions.
> Regarding the metrics themselves, I agree with Michael. The v.b
> namespace is intended for vehicle battery metrics. Perhaps we can
> simply add another namespace ?v.ice? for internal combustion engine
> fuels?
> 
> Note that OBDII defines standard fuel type codings (service 01 PID
> 51):
> 
> ValueDescription0Not
> available1Gasoline2Methanol3Ethanol4Diesel5LPG6CNG7Propane8Electric9B
> ifuel?running Gasoline10Bifuel running Methanol11Bifuel running
> Ethanol12Bifuel running LPG13Bifuel running CNG14Bifuel running
> Propane15Bifuel running Electricity16Bifuel running electric and
> combustion engine17Hybrid gasoline18Hybrid Ethanol19Hybrid
> Diesel20Hybrid Electric21Hybrid running electric and combustion
> engine22Hybrid Regenerative23Bifuel running diesel
> A ?v.fueltype? metric makes sense for this. Perhaps just use the full
> OBDII list (which supports hybrids). For ICE vehicles, keeping to
> standard OBDII PIDs is probably the simplest and most standardised
> approach. So, ?v.ice.tank.level?, or something like that (OBDII PID
> 0x2f).
> 
> Regarding the Apps support for this (and other things), that is
> something I am working on and trying to prototype. I will eMail
> separately regarding this.
> 
> Regards, Mark.
> 
> > On 15 Jun 2020, at 2:46 AM, Michael Balzer <dexter at expeedo.de>
> > wrote:
> > 
> > 
> > ??
> > ????
> > ??
> > ??
> > ????Craig,
> > 
> > ????
> > 
> > ????I strictly vote against re-interpretation of the SOC metric.
> > Where
> > ????metrics have clear semantics we should not make them dependent
> > on
> > ????some context.
> > 
> > ????
> > 
> > ????A battery is not a fuel tank, and vehicles may have both.
> > "v.b." is
> > ????the namespace "vehicle battery" and shall not be populated with
> > ????non-battery metrics.
> > 
> > ????
> > 
> > ????That's what I meant by adding technology specific metrics: if
> > the
> > ????vehicle has a fuel tank, additional standard metrics describing
> > that
> > ????fuel tank shall be present.
> > 
> > ????
> > 
> > ????Fuel tank specific metrics might e.g. get the namespace
> > "v.ft.", ICE
> > ????engine specific metrics might get "v.ice.", fuel cell metrics
> > ????"v.fc.", rocket thruster metrics "v.rt." ? you get the idea.
> > 
> > ????
> > 
> > ????Make a proposition for the metrics sets you need. Try to define
> > them
> > ????as generalized as possible.
> > 
> > ????
> > 
> > ????That will probably include duplicates of some metrics, like the
> > ????ranges & consumption. That's necessary to be able to describe a
> > ????hybrid, and some units among those will also need to be
> > different
> > ????(e.g. consumption in litres / m? per km).
> > 
> > ????
> > 
> > ????Regards,
> > 
> > ????Michael
> > 
> > ????
> > 
> > ????
> > 
> > ????Am 14.06.20 um 18:59 schrieb Chris van
> > ??????der Meijden:
> > 
> > ????
> > ????
> > > ??????
> > > ??????Thank you for considering my thoughts.
> > > ??????
> > > 
> > > ??????
> > > ??????I believe it is a good idea to use a v.tech variable and
> > > not
> > > ????????using gas or gazoline. That gives OVMS enough flexibility
> > > and is
> > > ????????also a?(little) statement.
> > > ??????
> > > 
> > > ??????
> > > ??????I'm also looking forward to rocket propulsion add ons :-))
> > > ??????
> > > 
> > > ??????
> > > ??????Greetinx
> > > ??????
> > > 
> > > ??????
> > > ??????Chris
> > > ??????
> > > 
> > > ??????
> > > ??????
> > > 
> > > ??????
> > > ??????Am Sonntag, den 14.06.2020, 08:21 -0700 schrieb Craig
> > > Leres:
> > > ??????
> > > > ????????On 2020-06-13 08:31, Michael Balzer wrote:
> > > > > How about adding an array or set metric like "v.ext" or
> > > > > "v.tech", for
> > > > > defined technology codes. A tag present in the metric means
> > > > > the
> > > > > additional metrics, commands & configs for that technology
> > > > > are available.
> > > > 
> > > > My goal is to make it possible for the app to depict soc with
> > > > something
> > > > other than a battery graphic when the energy source is not a
> > > > battery.
> > > > How about v.tech with "battery" and "other" as the initial two
> > > > possible
> > > > values?
> > > > 
> > > > 		Craig
> > > > _______________________________________________
> > > > OvmsDev mailing list
> > > > OvmsDev at lists.openvehicles.com
> > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > 
> > > > ??????
> > > 
> > > ????
> > 
> > ????
> > 
> > ????
> > ??
> > 
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/7026aa77/attachment-0001.html>

From mark at webb-johnson.net  Mon Jun 15 15:56:46 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Mon, 15 Jun 2020 15:56:46 +0800
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <1592205180.2530.1.camel@arachnon.de>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
 <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
 <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>
 <1592153973.13853.18.camel@arachnon.de>
 <3ea9f7cc-82d3-3a14-30f3-1dd9d8505894@expeedo.de>
 <F24DA1A4-AB81-4AB7-A689-A638C32484DC@webb-johnson.net>
 <1592205180.2530.1.camel@arachnon.de>
Message-ID: <D6C82A11-A444-41FF-8E52-4041667EC3CB@webb-johnson.net>

Hmmm...

It is hard to decouple ?open? from ?free?, particularly given the roots of the open source movement. But at it?s core is the concept of openness and freedom in that I (or we) should not be telling anyone what they can or cannot do with this project. The user is free to do with it what they will, and our license explicitly states that.

So, given that we cannot control what is done with the project, or what type of vehicle it is used in, the decision is whether we allow the ?v.b? battery namespace to be ?trampled on? with ICE metrics? I think that the suggested v.ice namespace is a reasonable compromise.

Regards, Mark.

P.S. My personal opinion is that I drive electric cars, prefer them, and advocate for them every day. I even co-founded a charity here in HK to support and promote them.

> On 15 Jun 2020, at 3:13 PM, Chris van der Meijden <chris at arachnon.de> wrote:
> 
> Sorry, I disagree.
> 
> I think "Open" stands for open source and open source should also mean being open to discussions. And discussions involve personal opinions.
> 
> IMHO supporting internal combustion engines in OVMS is a bad idea in times of climate change. It is the wrong signal if we do so.
> 
> I do not want to "over discuss" this, but it is important enough for me suggest not to implement support for ICE engines.
> 
> Greetinx
> 
> Chris
> 
> 
> Am Montag, den 15.06.2020, 10:27 +0800 schrieb Mark Webb-Johnson:
>> 
>> I think the core principle of the ?Open? in ?Open Vehicle Monitoring System? is that we should not restrict any uses, no matter our personal opinions.
>> 
>> Regarding the metrics themselves, I agree with Michael. The v.b namespace is intended for vehicle battery metrics. Perhaps we can simply add another namespace ?v.ice? for internal combustion engine fuels?
>> 
>> Note that OBDII defines standard fuel type codings (service 01 PID 51):
>> 
>> Value	Description
>> 0	Not available
>> 1	Gasoline
>> 2	Methanol
>> 3	Ethanol
>> 4	Diesel
>> 5	LPG <https://en.wikipedia.org/wiki/Liquefied_petroleum_gas>
>> 6	CNG <https://en.wikipedia.org/wiki/Compressed_natural_gas>
>> 7	Propane
>> 8	Electric
>> 9	Bifuel <https://en.wikipedia.org/wiki/Bi-fuel_vehicle> running Gasoline
>> 10	Bifuel running Methanol
>> 11	Bifuel running Ethanol
>> 12	Bifuel running LPG
>> 13	Bifuel running CNG
>> 14	Bifuel running Propane
>> 15	Bifuel running Electricity
>> 16	Bifuel running electric and combustion engine
>> 17	Hybrid gasoline
>> 18	Hybrid Ethanol
>> 19	Hybrid Diesel
>> 20	Hybrid Electric
>> 21	Hybrid running electric and combustion engine
>> 22	Hybrid Regenerative
>> 23	Bifuel running diesel
>> 
>> A ?v.fueltype? metric makes sense for this. Perhaps just use the full OBDII list (which supports hybrids). For ICE vehicles, keeping to standard OBDII PIDs is probably the simplest and most standardised approach. So, ?v.ice.tank.level?, or something like that (OBDII PID 0x2f).
>> 
>> Regarding the Apps support for this (and other things), that is something I am working on and trying to prototype. I will eMail separately regarding this.
>> 
>> Regards, Mark.
>> 
>>> On 15 Jun 2020, at 2:46 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>> 
>>> Craig,
>>> 
>>> I strictly vote against re-interpretation of the SOC metric. Where metrics have clear semantics we should not make them dependent on some context.
>>> 
>>> A battery is not a fuel tank, and vehicles may have both. "v.b." is the namespace "vehicle battery" and shall not be populated with non-battery metrics.
>>> 
>>> That's what I meant by adding technology specific metrics: if the vehicle has a fuel tank, additional standard metrics describing that fuel tank shall be present.
>>> 
>>> Fuel tank specific metrics might e.g. get the namespace "v.ft.", ICE engine specific metrics might get "v.ice.", fuel cell metrics "v.fc.", rocket thruster metrics "v.rt." ? you get the idea.
>>> 
>>> Make a proposition for the metrics sets you need. Try to define them as generalized as possible.
>>> 
>>> That will probably include duplicates of some metrics, like the ranges & consumption. That's necessary to be able to describe a hybrid, and some units among those will also need to be different (e.g. consumption in litres / m? per km).
>>> 
>>> Regards,
>>> Michael
>>> 
>>> 
>>> Am 14.06.20 um 18:59 schrieb Chris van der Meijden:
>>>> Thank you for considering my thoughts.
>>>> 
>>>> I believe it is a good idea to use a v.tech <http://v.tech/> variable and not using gas or gazoline. That gives OVMS enough flexibility and is also a (little) statement.
>>>> 
>>>> I'm also looking forward to rocket propulsion add ons :-))
>>>> 
>>>> Greetinx
>>>> 
>>>> Chris
>>>> 
>>>> 
>>>> Am Sonntag, den 14.06.2020, 08:21 -0700 schrieb Craig Leres:
>>>>> On 2020-06-13 08:31, Michael Balzer wrote:
>>>>>> 
>>>>>> How about adding an array or set metric like "v.ext" or "v.tech <http://v.tech/>", for
>>>>>> defined technology codes. A tag present in the metric means the
>>>>>> additional metrics, commands & configs for that technology are available.
>>>>> 
>>>>> 
>>>>> My goal is to make it possible for the app to depict soc with something
>>>>> other than a battery graphic when the energy source is not a battery.
>>>>> How about v.tech <http://v.tech/> with "battery" and "other" as the initial two possible
>>>>> values?
>>>>> 
>>>>> 		Craig
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/6d7604e8/attachment.html>

From chris at arachnon.de  Mon Jun 15 16:38:18 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Mon, 15 Jun 2020 10:38:18 +0200
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <D6C82A11-A444-41FF-8E52-4041667EC3CB@webb-johnson.net>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
 <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
 <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>
 <1592153973.13853.18.camel@arachnon.de>
 <3ea9f7cc-82d3-3a14-30f3-1dd9d8505894@expeedo.de>
 <F24DA1A4-AB81-4AB7-A689-A638C32484DC@webb-johnson.net>
 <1592205180.2530.1.camel@arachnon.de>
 <D6C82A11-A444-41FF-8E52-4041667EC3CB@webb-johnson.net>
Message-ID: <1592210298.2530.8.camel@arachnon.de>

Hey Mark
I think it is a difference telling someone what to do or actively
enabling what someone can do. If you enable something for someone you
are ethicaly responsible for that something.
All in all, we are all on the same side of the river. Driving EV's
brought a deeper understanding for the climate issues to me and I'm
sure to most of us. Good to read that you are active in a charity in
HK. Working together for a cleaner future. Just like the development of
OVMS :-)
Regards
Chris
Am Montag, den 15.06.2020, 15:56 +0800 schrieb Mark Webb-Johnson:
> Hmmm...
> It is hard to decouple ?open? from ?free?, particularly given the
> roots of the open source movement. But at it?s core is the concept of
> openness and freedom in that I (or we) should not be telling anyone
> what they can or cannot do with this project. The user is free to do
> with it what they will, and our license explicitly states that.
> 
> So, given that we cannot control what is done with the project, or
> what type of vehicle it is used in, the decision is whether we allow
> the ?v.b? battery namespace to be ?trampled on? with ICE metrics? I
> think that the suggested v.ice namespace is a reasonable compromise.
> 
> Regards, Mark.
> 
> P.S. My personal opinion is that I drive electric cars, prefer them,
> and advocate for them every day. I even co-founded a charity here in
> HK to support and promote them.
> 
> > On 15 Jun 2020, at 3:13 PM, Chris van der Meijden <chris at arachnon.d
> > e> wrote:
> > 
> > Sorry, I disagree.
> > I think "Open" stands for open source and open source should also
> > mean being open to discussions. And discussions involve personal
> > opinions.
> > IMHO supporting internal combustion engines in OVMS is a bad idea
> > in times of climate change. It is the wrong signal if we do so.?
> > I do not??want to "over discuss" this, but it is important enough
> > for me suggest not to implement support for ICE engines.
> > Greetinx
> > Chris
> > 
> > Am Montag, den 15.06.2020, 10:27 +0800 schrieb Mark Webb-Johnson:
> > > I think the core principle of the ?Open? in ?Open Vehicle
> > > Monitoring System? is that we should not restrict any uses, no
> > > matter our personal opinions.
> > > Regarding the metrics themselves, I agree with Michael. The v.b
> > > namespace is intended for vehicle battery metrics. Perhaps we can
> > > simply add another namespace ?v.ice? for internal combustion
> > > engine fuels?
> > > 
> > > Note that OBDII defines standard fuel type codings (service 01
> > > PID 51):
> > > 
> > > ValueDescription0Not
> > > available1Gasoline2Methanol3Ethanol4Diesel5LPG6CNG7Propane8Electr
> > > ic9Bifuel?running Gasoline10Bifuel running Methanol11Bifuel
> > > running Ethanol12Bifuel running LPG13Bifuel running CNG14Bifuel
> > > running Propane15Bifuel running Electricity16Bifuel running
> > > electric and combustion engine17Hybrid gasoline18Hybrid
> > > Ethanol19Hybrid Diesel20Hybrid Electric21Hybrid running electric
> > > and combustion engine22Hybrid Regenerative23Bifuel running diesel
> > > A ?v.fueltype? metric makes sense for this. Perhaps just use the
> > > full OBDII list (which supports hybrids). For ICE vehicles,
> > > keeping to standard OBDII PIDs is probably the simplest and most
> > > standardised approach. So, ?v.ice.tank.level?, or something like
> > > that (OBDII PID 0x2f).
> > > 
> > > Regarding the Apps support for this (and other things), that is
> > > something I am working on and trying to prototype. I will eMail
> > > separately regarding this.
> > > 
> > > Regards, Mark.
> > > 
> > > > On 15 Jun 2020, at 2:46 AM, Michael Balzer <dexter at expeedo.de>
> > > > wrote:
> > > > 
> > > > 
> > > > ??
> > > > ????
> > > > ??
> > > > ??
> > > > ????Craig,
> > > > 
> > > > ????
> > > > 
> > > > ????I strictly vote against re-interpretation of the SOC
> > > > metric. Where
> > > > ????metrics have clear semantics we should not make them
> > > > dependent on
> > > > ????some context.
> > > > 
> > > > ????
> > > > 
> > > > ????A battery is not a fuel tank, and vehicles may have both.
> > > > "v.b." is
> > > > ????the namespace "vehicle battery" and shall not be populated
> > > > with
> > > > ????non-battery metrics.
> > > > 
> > > > ????
> > > > 
> > > > ????That's what I meant by adding technology specific metrics:
> > > > if the
> > > > ????vehicle has a fuel tank, additional standard metrics
> > > > describing that
> > > > ????fuel tank shall be present.
> > > > 
> > > > ????
> > > > 
> > > > ????Fuel tank specific metrics might e.g. get the namespace
> > > > "v.ft.", ICE
> > > > ????engine specific metrics might get "v.ice.", fuel cell
> > > > metrics
> > > > ????"v.fc.", rocket thruster metrics "v.rt." ? you get the
> > > > idea.
> > > > 
> > > > ????
> > > > 
> > > > ????Make a proposition for the metrics sets you need. Try to
> > > > define them
> > > > ????as generalized as possible.
> > > > 
> > > > ????
> > > > 
> > > > ????That will probably include duplicates of some metrics, like
> > > > the
> > > > ????ranges & consumption. That's necessary to be able to
> > > > describe a
> > > > ????hybrid, and some units among those will also need to be
> > > > different
> > > > ????(e.g. consumption in litres / m? per km).
> > > > 
> > > > ????
> > > > 
> > > > ????Regards,
> > > > 
> > > > ????Michael
> > > > 
> > > > ????
> > > > 
> > > > ????
> > > > 
> > > > ????Am 14.06.20 um 18:59 schrieb Chris van
> > > > ??????der Meijden:
> > > > 
> > > > ????
> > > > ????
> > > > > ??????
> > > > > ??????Thank you for considering my thoughts.
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????I believe it is a good idea to use a v.tech variable
> > > > > and not
> > > > > ????????using gas or gazoline. That gives OVMS enough
> > > > > flexibility and is
> > > > > ????????also a?(little) statement.
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????I'm also looking forward to rocket propulsion add ons
> > > > > :-))
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????Greetinx
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????Chris
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????Am Sonntag, den 14.06.2020, 08:21 -0700 schrieb Craig
> > > > > Leres:
> > > > > ??????
> > > > > > ????????On 2020-06-13 08:31, Michael Balzer wrote:
> > > > > > > How about adding an array or set metric like "v.ext" or
> > > > > > > "v.tech", for
> > > > > > > defined technology codes. A tag present in the metric
> > > > > > > means the
> > > > > > > additional metrics, commands & configs for that
> > > > > > > technology are available.
> > > > > > 
> > > > > > My goal is to make it possible for the app to depict soc
> > > > > > with something
> > > > > > other than a battery graphic when the energy source is not
> > > > > > a battery.
> > > > > > How about v.tech with "battery" and "other" as the initial
> > > > > > two possible
> > > > > > values?
> > > > > > 
> > > > > > 		Craig
> > > > > > _______________________________________________
> > > > > > OvmsDev mailing list
> > > > > > OvmsDev at lists.openvehicles.com
> > > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > > > 
> > > > > > ??????
> > > > > 
> > > > > ????
> > > > 
> > > > ????
> > > > 
> > > > ????
> > > > ??
> > > > 
> > > > _______________________________________________
> > > > OvmsDev mailing list
> > > > OvmsDev at lists.openvehicles.com
> > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > 
> > > _______________________________________________
> > > OvmsDev mailing list
> > > OvmsDev at lists.openvehicles.com
> > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/2ae9f262/attachment-0001.html>

From dexter at expeedo.de  Tue Jun 16 02:04:43 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Mon, 15 Jun 2020 20:04:43 +0200
Subject: [Ovmsdev] File logging task
In-Reply-To: <AC2DA22E-F65F-4D75-AA65-5C12C829B0A4@webb-johnson.net>
References: <6eac2ac1-4835-7a73-51f3-af003a43eae6@expeedo.de>
 <1bc35602-d032-2d09-07b8-650a7eb3e234@expeedo.de>
 <AC2DA22E-F65F-4D75-AA65-5C12C829B0A4@webb-johnson.net>
Message-ID: <9eb50fd8-0408-8f71-4f4c-c50534dcf2af@expeedo.de>

The overhead of a direct log call is the call, the semaphore
acquisition, the tag level check & the min-heap handling. That should
normally be small. The semaphore has a nominal max wait of 1 tick = 10
ms, but the actual delay will normally be in the ?s range.

So I don't think that's causing performance issues if not used
excessively or within critical sections.

There is much more overhead though if our OvmsCommand::HexDump() utility
is used, as is the case in the SIMCOM driver. HexDump() needs to
allocate memory and format the buffer (possibly multiple blocks),
regardless of the tag level. The actual tag level check isn't exported
from the idf log module, so can currently not be done in advance. We
could change that, but there are few HexDump() calls now, most of them
just for error reports.

On excluding verbose level logging from web & ssh channels: I think
that's a severe & (now) unnecessary restriction. I've been using both
for verbose debugging and consider this to be useful & convenient.

Regards,
Michael


Am 15.06.20 um 07:55 schrieb Mark Webb-Johnson:
>
> Do you think that the overhead of the logging framework is impacting
> performance of things like SSH/SCP and SIMCOM async? Kind of related
> to the issue I raised about the infinite loop caused by debug logging
> on the web console and ssh (when those are already receiving log
> monitor output) - logging the logging.
>
> It seems using ESP_EARLY would avoid this? Or a cleanup to move such
> logging to verbose level, other stuff at debug level, and a
> restriction on web client and ssh to never log monitor above debug level?
>
> Regards, Mark.
>
>> On 13 Jun 2020, at 9:30 PM, Michael Balzer <dexter at expeedo.de
>> <mailto:dexter at expeedo.de>> wrote:
>>
>> I've added a simple workaround for this issue to our esp-idf fork:
>> https://github.com/openvehicles/esp-idf/commit/9024cd38ecbc78a46ed16b79d63f57812e72b123
>>
>> The workaround checks if logging is done from the timer context, if
>> so reduces the semaphore wait time to zero, thus avoiding blocking.
>>
>> That should eliminate any timer consistency issues arising from
>> logging in timer callbacks. The disadvantage is a higher chance of
>> such log messages getting dropped.
>>
>> Regards,
>> Michael
>>
>>
>> Am 05.11.19 um 21:45 schrieb Michael Balzer:
>>> Everyone,
>>>
>>> I've pushed the long due refactoring of the file logging into a
>>> dedicated task. This removes most of the delays involved in file
>>> logging, as the fsync() and log cycling now is done in the logging
>>> task and no longer blocks overall log message processing.
>>>
>>> I stumbled upon a bad thing (tm) though we need to resolve with
>>> logging: the esp-idf logging generally involves a semaphore wait of
>>> max 10 ms (!). I wasn't aware of this because I didn't look into the
>>> source before, there also is no warning about this in the esp-idf
>>> documentation
>>> (https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/log.html),
>>> so I guess I'm not the only one being taken by surprise here.
>>>
>>>     // Maximum time to wait for the mutex in a logging statement.
>>>     #define *MAX_MUTEX_WAIT_MS 10*
>>>     #define MAX_MUTEX_WAIT_TICKS ((MAX_MUTEX_WAIT_MS +
>>>     portTICK_PERIOD_MS - 1) / portTICK_PERIOD_MS)
>>>     ?
>>>     void IRAM_ATTR *esp_log_write*(esp_log_level_t level,
>>>     ??????? const char* tag,
>>>     ??????? const char* format, ...)
>>>     {
>>>     ??? if (!s_log_mutex) {
>>>     ??????? s_log_mutex = xSemaphoreCreateMutex();
>>>     ??? }
>>>     ??? if (*xSemaphoreTake(s_log_mutex, MAX_MUTEX_WAIT_TICKS*) ==
>>>     pdFALSE) {
>>>     ??????? return;
>>>     ??? }
>>>     ?
>>>
>>>
>>> That semaphore is needed to secure the log level tag cache against
>>> parallel access, so it also affects log messages of currently
>>> disabled tags and/or levels.
>>>
>>> This means we *must not* use the standard logging from timer
>>> callbacks, at no verbosity level. But we do, partially caused by my
>>> own code serving as a bad example I assume -- sorry.
>>>
>>> But I've not only found direct log calls in most vehicle timer
>>> callbacks, there also are some hidden ones from calling the
>>> framework, for example marking a notification as read can produce a
>>> log output from Cleanup() if tracing is enabled.
>>>
>>> We need to change this short to mid term. This may be the cause of
>>> those strange timer overflow issues we've seen occasionally. It also
>>> means every debug or verbose log output currently in the code
>>> involves potentially multiple semaphore waits, that's for example
>>> the case for all hex dumps logged by the SIMCOM module.
>>>
>>> Our primary option is to remove all log calls from all low level
>>> framework functions and timer callbacks.
>>>
>>> A simple & quick workaround could be to extend the ESP_LOGx macros
>>> to check if they are executed in the timer task context, if so
>>> suppress the message or call the ESP_EARLY log function instead.
>>> That will hide these log messages from the logging framework though,
>>> if using the _EARLY_ variant they only will be sent to the USB port.
>>>
>>> For a better solution I thought about adding a dedicated queue &
>>> task for the initial log submission as well. That will need quite
>>> some rework to the esp-idf (no changes for this in the current
>>> master) but would allow to continue logging as we do now. Cons:
>>> queue submission involves some overhead & RAM, printf format
>>> expansion needs to be done before the tag/level check, messages may
>>> need to be dropped if the task starves or RAM gets tight, log output
>>> to consoles will depend on a task as well.
>>>
>>> Opinions / better ideas?
>>>
>>> Regards,
>>> Michael
>>> -- 
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/517614ab/attachment.html>

From shamziman at gmail.com  Tue Jun 16 03:20:47 2020
From: shamziman at gmail.com (Shaun Jurrens)
Date: Mon, 15 Jun 2020 21:20:47 +0200
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <1592210298.2530.8.camel@arachnon.de>
References: <1592210298.2530.8.camel@arachnon.de>
Message-ID: <D3F3E9B5-EE3C-4797-AF3A-8C6C745CCABB@gmail.com>

Hey,

I appreciate the wisdom in Mark?s approach and his and others? work on this project and, in this matter, his opinion.  No solution is ever used just for what it was intended. Even if he wanted to, the project could easily be forked and massed produced in countries with few IP laws.  It?s already ?out there?.

Secondly, purists and absolutists rarely serve projects?s benefit very long as their growing impatience with the world?s imperfections tend to kill their motivation sooner rather than later.  Indeed, if perfect environmental requirements were necessary, then no one in NL, for example, would be allowed to drive at all, EV or ICE, as well over 90% of NL?s energy production isn?t from renewables.  Life is more complex than what we can easily see.

I own an Ampera and am glad for the functionality that has been developed in OVMS and hope to be able to contribute some day soon. The car is a utilitarian compromise from its day in 2013, and it gets me through the year with 90% of my travel on battery.  It?s not perfect, but it?s much better than nothing, and that is where most of us (and the world) need to start. 

The old saying is ?Perfection is the enemy of progress? (or as Voltaire phrased it, ?the best is the enemy of the good?), fits rather aptly here.

Cheers,
Shaun
(via the iPad thingamajigg)

> On 15 Jun 2020, at 10:39, Chris van der Meijden <chris at arachnon.de> wrote:
> 
> ?
> Hey Mark
> 
> I think it is a difference telling someone what to do or actively enabling what someone can do. If you enable something for someone you are ethicaly responsible for that something.
> 
> All in all, we are all on the same side of the river. Driving EV's brought a deeper understanding for the climate issues to me and I'm sure to most of us. Good to read that you are active in a charity in HK. Working together for a cleaner future. Just like the development of OVMS :-)
> 
> Regards
> 
> Chris
> 
> Am Montag, den 15.06.2020, 15:56 +0800 schrieb Mark Webb-Johnson:
>> Hmmm...
>> 
>> It is hard to decouple ?open? from ?free?, particularly given the roots of the open source movement. But at it?s core is the concept of openness and freedom in that I (or we) should not be telling anyone what they can or cannot do with this project. The user is free to do with it what they will, and our license explicitly states that.
>> 
>> So, given that we cannot control what is done with the project, or what type of vehicle it is used in, the decision is whether we allow the ?v.b? battery namespace to be ?trampled on? with ICE metrics? I think that the suggested v.ice namespace is a reasonable compromise.
>> 
>> Regards, Mark.
>> 
>> P.S. My personal opinion is that I drive electric cars, prefer them, and advocate for them every day. I even co-founded a charity here in HK to support and promote them.
>> 
>>> On 15 Jun 2020, at 3:13 PM, Chris van der Meijden <chris at arachnon.de> wrote:
>>> 
>>> Sorry, I disagree.
>>> 
>>> I think "Open" stands for open source and open source should also mean being open to discussions. And discussions involve personal opinions.
>>> 
>>> IMHO supporting internal combustion engines in OVMS is a bad idea in times of climate change. It is the wrong signal if we do so.
>>> 
>>> I do not want to "over discuss" this, but it is important enough for me suggest not to implement support for ICE engines.
>>> 
>>> Greetinx
>>> 
>>> Chris
>>> 
>>> 
>>> Am Montag, den 15.06.2020, 10:27 +0800 schrieb Mark Webb-Johnson:
>>>> 
>>>> I think the core principle of the ?Open? in ?Open Vehicle Monitoring System? is that we should not restrict any uses, no matter our personal opinions.
>>>> 
>>>> Regarding the metrics themselves, I agree with Michael. The v.b namespace is intended for vehicle battery metrics. Perhaps we can simply add another namespace ?v.ice? for internal combustion engine fuels?
>>>> 
>>>> Note that OBDII defines standard fuel type codings (service 01 PID 51):
>>>> 
>>>> Value	Description
>>>> 0	Not available
>>>> 1	Gasoline
>>>> 2	Methanol
>>>> 3	Ethanol
>>>> 4	Diesel
>>>> 5	LPG
>>>> 6	CNG
>>>> 7	Propane
>>>> 8	Electric
>>>> 9	Bifuel running Gasoline
>>>> 10	Bifuel running Methanol
>>>> 11	Bifuel running Ethanol
>>>> 12	Bifuel running LPG
>>>> 13	Bifuel running CNG
>>>> 14	Bifuel running Propane
>>>> 15	Bifuel running Electricity
>>>> 16	Bifuel running electric and combustion engine
>>>> 17	Hybrid gasoline
>>>> 18	Hybrid Ethanol
>>>> 19	Hybrid Diesel
>>>> 20	Hybrid Electric
>>>> 21	Hybrid running electric and combustion engine
>>>> 22	Hybrid Regenerative
>>>> 23	Bifuel running diesel
>>>> 
>>>> A ?v.fueltype? metric makes sense for this. Perhaps just use the full OBDII list (which supports hybrids). For ICE vehicles, keeping to standard OBDII PIDs is probably the simplest and most standardised approach. So, ?v.ice.tank.level?, or something like that (OBDII PID 0x2f).
>>>> 
>>>> Regarding the Apps support for this (and other things), that is something I am working on and trying to prototype. I will eMail separately regarding this.
>>>> 
>>>> Regards, Mark.
>>>> 
>>>>> On 15 Jun 2020, at 2:46 AM, Michael Balzer <dexter at expeedo.de> wrote:
>>>>> 
>>>>> Craig,
>>>>> 
>>>>> I strictly vote against re-interpretation of the SOC metric. Where metrics have clear semantics we should not make them dependent on some context.
>>>>> 
>>>>> A battery is not a fuel tank, and vehicles may have both. "v.b." is the namespace "vehicle battery" and shall not be populated with non-battery metrics.
>>>>> 
>>>>> That's what I meant by adding technology specific metrics: if the vehicle has a fuel tank, additional standard metrics describing that fuel tank shall be present.
>>>>> 
>>>>> Fuel tank specific metrics might e.g. get the namespace "v.ft.", ICE engine specific metrics might get "v.ice.", fuel cell metrics "v.fc.", rocket thruster metrics "v.rt." ? you get the idea.
>>>>> 
>>>>> Make a proposition for the metrics sets you need. Try to define them as generalized as possible.
>>>>> 
>>>>> That will probably include duplicates of some metrics, like the ranges & consumption. That's necessary to be able to describe a hybrid, and some units among those will also need to be different (e.g. consumption in litres / m? per km).
>>>>> 
>>>>> Regards,
>>>>> Michael
>>>>> 
>>>>> 
>>>>> Am 14.06.20 um 18:59 schrieb Chris van der Meijden:
>>>>>> Thank you for considering my thoughts.
>>>>>> 
>>>>>> I believe it is a good idea to use a v.tech variable and not using gas or gazoline. That gives OVMS enough flexibility and is also a (little) statement.
>>>>>> 
>>>>>> I'm also looking forward to rocket propulsion add ons :-))
>>>>>> 
>>>>>> Greetinx
>>>>>> 
>>>>>> Chris
>>>>>> 
>>>>>> 
>>>>>> Am Sonntag, den 14.06.2020, 08:21 -0700 schrieb Craig Leres:
>>>>>>>> On 2020-06-13 08:31, Michael Balzer wrote:
>>>>>>>> 
>>>>>>>> How about adding an array or set metric like "v.ext" or "v.tech", for
>>>>>>>> defined technology codes. A tag present in the metric means the
>>>>>>>> additional metrics, commands & configs for that technology are available.
>>>>>>> 
>>>>>>> 
>>>>>>> My goal is to make it possible for the app to depict soc with something
>>>>>>> other than a battery graphic when the energy source is not a battery.
>>>>>>> How about v.tech with "battery" and "other" as the initial two possible
>>>>>>> values?
>>>>>>> 
>>>>>>> 		Craig
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>> 
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>> 
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/ea60c5df/attachment-0001.html>

From jaunius at gmx.com  Tue Jun 23 18:45:28 2020
From: jaunius at gmx.com (Jaunius Kapkan)
Date: Tue, 23 Jun 2020 13:45:28 +0300
Subject: [Ovmsdev] NL: iOS app - Add Cabin Temp and HVAC state
Message-ID: <E85AB984-AA6C-49E5-B4E5-C5CA7EF29EE5@gmx.com>

Hi,

Can someone guide on the best approach here. I have no access to MAC so it would be more of a trial and error approach.  Current view:

Metrics:


Or are we close to the unified app for both iOS and Android and I should wait?

Regards,

Regards,
Jaunius Kapkan [Sent from cellphone]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200623/436d56f1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0dddcf99-4faa-4b3a-a523-da98780ce30d.jpg
Type: image/jpeg
Size: 240992 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200623/436d56f1/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f370a907-df44-4b55-bf0a-b7eb11ef1382.jpg
Type: image/jpeg
Size: 60887 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200623/436d56f1/attachment-0003.jpg>

From mark at webb-johnson.net  Wed Jun 24 10:22:25 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Wed, 24 Jun 2020 10:22:25 +0800
Subject: [Ovmsdev] NL: iOS app - Add Cabin Temp and HVAC state
In-Reply-To: <E85AB984-AA6C-49E5-B4E5-C5CA7EF29EE5@gmx.com>
References: <E85AB984-AA6C-49E5-B4E5-C5CA7EF29EE5@gmx.com>
Message-ID: <43EE4DE2-5F95-468D-AA1D-CE348BB88A44@webb-johnson.net>

Those two metrics are available in v2 protocol:

Both in doors5, as part of the ?D? message

So, the iOS App should have them delivered. But the iOS App doesn?t handle anything beyond doors3 in the ?D? message at the moment. That would not be too hard to add, but you?d be unlikely to get the change 100% without an ability to test. Displaying on the screen itself is probably not too hard. Apple has some new requirements for App Store submission, including requiring support for apple sign on, that I am not sure if we now meet (so getting this approved maybe a hassle). If someone makes the change, I will try to get it through.

Unified App

I have been concentrating on the unified app recently, rather than trying to extend the iOS specific App. But it is hard going, and a real struggle. I?ve got forty years of programming experience, but am very new to these unified frameworks.

Compared to the native app frameworks, these unified app frameworks are a mess. Poor documentation. Breaking changes on every version upgrade. Outdated example code. Unmaintained libraries. The open source ones are like perl - 10 libraries to do variants of the same thing and no idea which one is the best. The majority simply don?t work on the latest version of the framework. I like Xamarin (which doesn?t suffer front too many of these problems), but it is just too proprietary for my taste (and I am scared MS will shut it down, or restrict it in some way). We use Monaca (phone gap based) at work, but it is just too restrictive and too ?webby'.


I have decided to try to implement the App in react-native, which seems to be the most up-to-date and modern of the open source frameworks. It is certainly fast, but the breaking changes in each new versions are a nightmare for those new to the framework (like me). Any example code / library more than a few months old just doesn?t work properly. The nice thing about this framework is that so long as we stick to pure javascript, we can self-publish a development version of the App, and load it remotely from the ?expo? client that runs on Android and iOS phones and tables. It is incredibly quick to iterate through changes, without all the code signing crap, App Store approvals and delays. We would still use the app stores to publish final versions. For example, my current first couple of evenings very basic attempt at building using this framework is here:

https://exp.host/@markwj/Open-Vehicle-React-App <https://exp.host/@markwj/Open-Vehicle-React-App>

Install the expo client, point the camera at that QR code, and the App will be downloaded and run locally. Some comments:

Status tab is for vehicle overall status. This is a web view, and will be loaded dynamically (with callbacks to be able to retrieve metrics, issue commands) for per-vehicle-type and per-customer customisation.

Vehicle tab is for vehicle environment status. Same as the status tab, this is a web view.

Location tab is a map.

Messages tab are chat style messages for talking to the car.

Settings tab will change in this app, and will be for settings of that particular select car.

The above tabs may change (in particular, I am not sure about status and vehicle tabs - perhaps we need just one, and then have some customisable way of having multiple screens per car type. I don?t like that it is fix to two screens. So I am thinking maybe just one screen, with tabs along the top, or swipe, to switch between pages.

Swipe left for the menu drawer. This is where the list of your vehicles will be, as well as menu options (create new vehicle, etc).

The basic ideas behind this are unchanged, as I outlined before. Vehicle API agnostic, central metrics store, user customisable display, etc.

I'm working in the open on this, committing as I go along. So dozens/hundreds of little commits, often correcting each other. It is a prototype, that I am using to just test each of the technologies we need (e.g. can the web view retrieve metrics from the app), can we support websocket connections to OVMS v2 servers, etc. I have no idea if it can become a production App, but so far it seems that it can.

If anybody wants to jump onboard and help, that would be most appreciated. Especially if you have javascript or react experience. Likewise, if anybody wants to try this in another framework, that is also possible. At this point, I am simply not sure what is the best approach.

Regards, Mark.

> On 23 Jun 2020, at 6:45 PM, Jaunius Kapkan <jaunius at gmx.com> wrote:
> 
> Hi,
> 
> Can someone guide on the best approach here. I have no access to MAC so it would be more of a trial and error approach.  Current view:
> <0dddcf99-4faa-4b3a-a523-da98780ce30d.jpg>
> Metrics:
> <f370a907-df44-4b55-bf0a-b7eb11ef1382.jpg>
> 
> Or are we close to the unified app for both iOS and Android and I should wait?
> 
> Regards,
> 
> Regards,
> Jaunius Kapkan [Sent from cellphone]
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200624/f9eefcad/attachment.html>

From leres at xse.com  Wed Jun 24 11:43:14 2020
From: leres at xse.com (Craig Leres)
Date: Tue, 23 Jun 2020 20:43:14 -0700
Subject: [Ovmsdev] NL: iOS app - Add Cabin Temp and HVAC state
Message-ID: <F4EB8152-0188-4471-9CAA-A9102B1FFFF7@xse.com>

?On 2020-06-23 19:22, Mark Webb-Johnson wrote:
> Those two metrics are available in v2 protocol:
> 
>  * Both in doors5, as part of the ?D? message
> 
> 
> So, the iOS App should have them delivered. But the iOS App doesn?t
> handle anything beyond doors3 in the ?D? message at the moment. That
> would not be too hard to add, but you?d be unlikely to get the change
> 100% without an ability to test. Displaying on the screen itself is
> probably not too hard. Apple has some new requirements for App Store
> submission, including requiring support for apple sign on, that I am not
> sure if we now meet (so getting this approved maybe a hassle). If
> someone makes the change, I will try to get it through.

I recently got a mini (mostly to run zoom for meetings) and can build,
run, and test in the osx simulator; I have more time during the weekend
than the week but would happy to help test changes.

> _*Unified App*_

> If anybody wants to jump onboard and help, that would be most
> appreciated. Especially if you have javascript or react experience.
> Likewise, if anybody wants to try this in another framework, that is
> also possible. At this point, I am simply not sure what is the best
> approach.

I couldn't easily get this to run anywhere. Firefox gave me an empty
popup window. Chrome launch a popup window with a phone that eventually
launches the app. But when I click on it I get a blue window that says
something went wrong (the error log says Uncaught Error: No project
found at exp://exp.host/@undefined/undefined).

       Craig


From mark at webb-johnson.net  Wed Jun 24 12:33:42 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Wed, 24 Jun 2020 12:33:42 +0800
Subject: [Ovmsdev] NL: iOS app - Add Cabin Temp and HVAC state
In-Reply-To: <F4EB8152-0188-4471-9CAA-A9102B1FFFF7@xse.com>
References: <F4EB8152-0188-4471-9CAA-A9102B1FFFF7@xse.com>
Message-ID: <45EE71A6-A657-400C-BA03-161A15091D81@webb-johnson.net>


> I couldn't easily get this to run anywhere. Firefox gave me an empty
> popup window. Chrome launch a popup window with a phone that eventually
> launches the app. But when I click on it I get a blue window that says
> something went wrong (the error log says Uncaught Error: No project
> found at exp://exp.host/@undefined/undefined).

You need to first install the expo app on your phone:

iOS: iOS App <https://itunes.apple.com/app/apple-store/id982107779>
Android: Android App <https://play.google.com/store/apps/details?id=host.exp.exponent&referrer=www>

Then, scan the picture, or click on that exp: url.

Regards, Mark.

> On 24 Jun 2020, at 11:43 AM, Craig Leres <leres at xse.com> wrote:
> 
> On 2020-06-23 19:22, Mark Webb-Johnson wrote:
>> Those two metrics are available in v2 protocol:
>> 
>> * Both in doors5, as part of the ?D? message
>> 
>> 
>> So, the iOS App should have them delivered. But the iOS App doesn?t
>> handle anything beyond doors3 in the ?D? message at the moment. That
>> would not be too hard to add, but you?d be unlikely to get the change
>> 100% without an ability to test. Displaying on the screen itself is
>> probably not too hard. Apple has some new requirements for App Store
>> submission, including requiring support for apple sign on, that I am not
>> sure if we now meet (so getting this approved maybe a hassle). If
>> someone makes the change, I will try to get it through.
> 
> I recently got a mini (mostly to run zoom for meetings) and can build,
> run, and test in the osx simulator; I have more time during the weekend
> than the week but would happy to help test changes.
> 
>> _*Unified App*_
> 
>> If anybody wants to jump onboard and help, that would be most
>> appreciated. Especially if you have javascript or react experience.
>> Likewise, if anybody wants to try this in another framework, that is
>> also possible. At this point, I am simply not sure what is the best
>> approach.
> 
> I couldn't easily get this to run anywhere. Firefox gave me an empty
> popup window. Chrome launch a popup window with a phone that eventually
> launches the app. But when I click on it I get a blue window that says
> something went wrong (the error log says Uncaught Error: No project
> found at exp://exp.host/@undefined/undefined).
> 
>       Craig
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200624/217b56c8/attachment.html>

From kommykt at gmail.com  Wed Jun 24 16:07:42 2020
From: kommykt at gmail.com (=?UTF-8?B?VGFtw6FzIEtvdsOhY3M=?=)
Date: Wed, 24 Jun 2020 10:07:42 +0200
Subject: [Ovmsdev] NL: iOS app - Add Cabin Temp and HVAC state
In-Reply-To: <45EE71A6-A657-400C-BA03-161A15091D81@webb-johnson.net>
References: <F4EB8152-0188-4471-9CAA-A9102B1FFFF7@xse.com>
 <45EE71A6-A657-400C-BA03-161A15091D81@webb-johnson.net>
Message-ID: <CAGpaXUtu3bNXhcKrA9wytMOc-dO0LbtgAWGD6ySQN1WuwxrgVA@mail.gmail.com>

On ios i get the following error:

2020. j?nius 24., szerda d?tummal Mark Webb-Johnson <mark at webb-johnson.net>
ezt ?rta:

>
> I couldn't easily get this to run anywhere. Firefox gave me an empty
> popup window. Chrome launch a popup window with a phone that eventually
> launches the app. But when I click on it I get a blue window that says
> something went wrong (the error log says Uncaught Error: No project
> found at exp://exp.host/@undefined/undefined).
>
>
> You need to first install the expo app on your phone:
>
> iOS: iOS App <https://itunes.apple.com/app/apple-store/id982107779>
> Android: Android App
> <https://play.google.com/store/apps/details?id=host.exp.exponent&referrer=www>
>
> Then, scan the picture, or click on that exp: url.
>
> Regards, Mark.
>
> On 24 Jun 2020, at 11:43 AM, Craig Leres <leres at xse.com> wrote:
>
> On 2020-06-23 19:22, Mark Webb-Johnson wrote:
>
> Those two metrics are available in v2 protocol:
>
> * Both in doors5, as part of the ?D? message
>
>
> So, the iOS App should have them delivered. But the iOS App doesn?t
> handle anything beyond doors3 in the ?D? message at the moment. That
> would not be too hard to add, but you?d be unlikely to get the change
> 100% without an ability to test. Displaying on the screen itself is
> probably not too hard. Apple has some new requirements for App Store
> submission, including requiring support for apple sign on, that I am not
> sure if we now meet (so getting this approved maybe a hassle). If
> someone makes the change, I will try to get it through.
>
>
> I recently got a mini (mostly to run zoom for meetings) and can build,
> run, and test in the osx simulator; I have more time during the weekend
> than the week but would happy to help test changes.
>
> _*Unified App*_
>
>
> If anybody wants to jump onboard and help, that would be most
> appreciated. Especially if you have javascript or react experience.
> Likewise, if anybody wants to try this in another framework, that is
> also possible. At this point, I am simply not sure what is the best
> approach.
>
>
> I couldn't easily get this to run anywhere. Firefox gave me an empty
> popup window. Chrome launch a popup window with a phone that eventually
> launches the app. But when I click on it I get a blue window that says
> something went wrong (the error log says Uncaught Error: No project
> found at exp://exp.host/@undefined/undefined).
>
>       Craig
>
>
>

-- 
?dv?zlettel:
Kov?cs Tam?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200624/92fc6438/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DB8E0EE1-1923-4DA5-BA4C-E623D78BB5B4.png
Type: image/png
Size: 143142 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200624/92fc6438/attachment-0001.png>

From mark at webb-johnson.net  Wed Jun 24 16:22:16 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Wed, 24 Jun 2020 16:22:16 +0800
Subject: [Ovmsdev] NL: iOS app - Add Cabin Temp and HVAC state
In-Reply-To: <CAGpaXUtu3bNXhcKrA9wytMOc-dO0LbtgAWGD6ySQN1WuwxrgVA@mail.gmail.com>
References: <F4EB8152-0188-4471-9CAA-A9102B1FFFF7@xse.com>
 <45EE71A6-A657-400C-BA03-161A15091D81@webb-johnson.net>
 <CAGpaXUtu3bNXhcKrA9wytMOc-dO0LbtgAWGD6ySQN1WuwxrgVA@mail.gmail.com>
Message-ID: <F1E09D40-F1C5-473A-8ADB-ABF4E10D8FBB@webb-johnson.net>

Great. Looks like Apple clamped down so that no longer works. Should be ok on Android. When I get the web app bit worked out it will also work there.

Regards, Mark.

> On 24 Jun 2020, at 4:07 PM, Tam?s Kov?cs <kommykt at gmail.com> wrote:
> 
> On ios i get the following error:
> 
> 2020. j?nius 24., szerda d?tummal Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> ezt ?rta:
> 
>> I couldn't easily get this to run anywhere. Firefox gave me an empty
>> popup window. Chrome launch a popup window with a phone that eventually
>> launches the app. But when I click on it I get a blue window that says
>> something went wrong (the error log says Uncaught Error: No project
>> found at exp://exp.host/@undefined/undefined <>).
> 
> You need to first install the expo app on your phone:
> 
> iOS: iOS App <https://itunes.apple.com/app/apple-store/id982107779>
> Android: Android App <https://play.google.com/store/apps/details?id=host.exp.exponent&referrer=www>
> 
> Then, scan the picture, or click on that exp: url.
> 
> Regards, Mark.
> 
>> On 24 Jun 2020, at 11:43 AM, Craig Leres <leres at xse.com <mailto:leres at xse.com>> wrote:
>> 
>> On 2020-06-23 19:22, Mark Webb-Johnson wrote:
>>> Those two metrics are available in v2 protocol:
>>> 
>>> * Both in doors5, as part of the ?D? message
>>> 
>>> 
>>> So, the iOS App should have them delivered. But the iOS App doesn?t
>>> handle anything beyond doors3 in the ?D? message at the moment. That
>>> would not be too hard to add, but you?d be unlikely to get the change
>>> 100% without an ability to test. Displaying on the screen itself is
>>> probably not too hard. Apple has some new requirements for App Store
>>> submission, including requiring support for apple sign on, that I am not
>>> sure if we now meet (so getting this approved maybe a hassle). If
>>> someone makes the change, I will try to get it through.
>> 
>> I recently got a mini (mostly to run zoom for meetings) and can build,
>> run, and test in the osx simulator; I have more time during the weekend
>> than the week but would happy to help test changes.
>> 
>>> _*Unified App*_
>> 
>>> If anybody wants to jump onboard and help, that would be most
>>> appreciated. Especially if you have javascript or react experience.
>>> Likewise, if anybody wants to try this in another framework, that is
>>> also possible. At this point, I am simply not sure what is the best
>>> approach.
>> 
>> I couldn't easily get this to run anywhere. Firefox gave me an empty
>> popup window. Chrome launch a popup window with a phone that eventually
>> launches the app. But when I click on it I get a blue window that says
>> something went wrong (the error log says Uncaught Error: No project
>> found at exp://exp.host/@undefined/undefined <>).
>> 
>>       Craig
>> 
> 
> 
> 
> -- 
> ?dv?zlettel:
> Kov?cs Tam?s
> 
> 
> <DB8E0EE1-1923-4DA5-BA4C-E623D78BB5B4.png>_______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200624/48f17824/attachment.html>

From sebastien.darveau at synnoetic.com  Wed Jun 24 21:10:10 2020
From: sebastien.darveau at synnoetic.com (=?UTF-8?Q?S=C3=A9bastien_Darveau?=)
Date: Wed, 24 Jun 2020 13:10:10 +0000
Subject: [Ovmsdev] Cross Platform Unified App
In-Reply-To: <0DB4B4E5-CA50-4B98-8469-BDD171252B42@webb-johnson.net>
References: <0DB4B4E5-CA50-4B98-8469-BDD171252B42@webb-johnson.net> 
 <EDF622C6-D71E-42D9-8F6C-9165EAF7CF7D@synnoetic.com>
Message-ID: <01000172e6733afc-3e777dea-2ef6-443c-908a-4904c071418f-000000@email.amazonses.com>

Hello,?

Here is my 2 cents on this.

- Have you also looked into Xamarin.Forms? It is the equivalent display templated approach used by Xamarin for Multiplatform UI. It uses data binding to instantly reflect model changes and it is quite flexible. It usually goes with the MVVM (Model-View ViewModel) design pattern. I have a year of experience with it and I can help to start the project.

- I can?t really talk about vehicle-server protocols but for app-server communication, I would favour a well designed REST api. As for the low level protocol, I used to have a separate project containing only DTO objects that is shared by server and client as a submodule. This is the interface. Server uses Automapper (?https://automapper.org/?) to map entities to DTO objects before sending back the response.?

Regards,
Sebastien Darveau


On Jun 15, 2020, at 3:00 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net> > wrote:


As you may know, I?ve been working for some time on the design of a cross platform unified App for OVMS. Here are my thoughts.

*	I think our approach of the ?virtual vehicle?, represented by a hash/set of metric->value, works well. We have been successful in providing common vehicle metrics for more than a dozen different types of electric vehicle, plus a bunch of other generic types. Overall, I think this is the correct approach, and lends itself very well to the IoT MQTT way of doing things.

*	Maintaining two separate Apps on two different platforms has been difficult, and the features and functionality are diverging too much.

*	The v2 protocol is too limiting (especially for new vehicle types, and custom metrics).

*	I like the idea of providing a ?templated? approach to the displays in the Apps. We design templates to pick metrics, along with other assets, and display their current values updated in real time.

*	By leveraging the ?virtual vehicle? model, we can also introduce the concept of vehicle sources. At the moment, we are limited to just one vehicle data source - OVMS protocol v2, and to some extent the apps already convert the incoming v2 data into a hard-coded set of metrics, with hard-coded display layouts. The purpose of these vehicle sources is to login to a remote server, retrieve the vehicle data, and store it as the standardised metrics, in the standardised ?virtual vehicle?. Example sources could be OVMS protocol v2, OVMS protocol v3 (MQTT), Tesla API, Carwings API, direct bluetooth to an OVMS module, etc. We could virtualise these protocols, with a common interface.

So, my proposal is:

1.	We develop a single universal App, coded in a ?free? open environment. I have looked at Xamarin and Phonegap (vue-js, and a bunch of alternatives in common use nowadays). My current preference is vue-js, as it seems that javascript and html lend themselves best to the templated display approach - it is trivial to dynamically load this content. That, plus the environment is truly free and well understood by a huge developer community. However, no decision has been made and I am open to suggestions.

2.	The App implements a virtual protocol system. Each virtual protocol talks a particular backend API for a particular account. The virtual protocol then publishes vehicles for the user to choose from. Initially we would write an OVMS v2 protocol implementation, but others (as previously listed) should be relatively easy to implement.

3.	The App implements a virtual vehicle system. Each virtual protocol converts the incoming vehicle data to the virtual vehicle metrics. We can base this simply on the OVMS v3 standardised metrics, but custom metrics also need to be supported. Commands to be sent to the vehicle can also be implemented in a similar way. The OVMS v3 MQTT protocol would be a 1-to-1 mapping here, for example.

4.	The App displays are implemented via a templating system, with templates provided per vehicle type and per screen type (phone, tablet, desktop, etc). The user can customise these templates, using either named virtual vehicle metrics or other assets (pictures, buttons for commands, etc).

5.	I feel that this approach provides an excellent balance. It allows for comprehensive support and flexibility of display for each vehicle type, without complicating the implementation. It also allows owners of more than one type of vehicle (perhaps not all supported by OVMS) to use a single App to monitor and control.

I am happy to build the framework for this, but would much prefer others to come on board to assist.

Any thoughts or suggestion are most welcome.

Regards, Mark.

_______________________________________________
OvmsDev mailing list
OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com> 
http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200624/2931b7d4/attachment.html>

From mark at webb-johnson.net  Fri Jun 26 16:10:15 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Fri, 26 Jun 2020 16:10:15 +0800
Subject: [Ovmsdev] Cross Platform Unified App
In-Reply-To: <01000172e6733afc-3e777dea-2ef6-443c-908a-4904c071418f-000000@email.amazonses.com>
References: <0DB4B4E5-CA50-4B98-8469-BDD171252B42@webb-johnson.net>
 <EDF622C6-D71E-42D9-8F6C-9165EAF7CF7D@synnoetic.com>
 <01000172e6733afc-3e777dea-2ef6-443c-908a-4904c071418f-000000@email.amazonses.com>
Message-ID: <8F15B149-C7F8-473E-BD65-A232029F6FF3@webb-johnson.net>


I did look into Xamarin forms, and tried to create some simple apps. I like it, but it is just too proprietary for my taste (and I am scared MS will shut it down, or restrict it in some way). I would prefer some open source approach. The documentation is however very good, and platform is stable, but examples not very helpful. I do like the way it allows a common UI (with forms), but still permits customisation on a per-platform basis.

The framework app I tried to create in react-native is simply this:

Tabs
Vehicle (web view)
Status (web view)
Location (native map)
Messages (chat ui)
Settings (just a simple form based screen)

Drawer style menu pulled in from the left, with arbritrary content

Support for light/dark theme (autoswitched to the Operating System selection would be best)

Support for Android and iOS

If that is simple in Xamarin, and you have time, it would be useful to generate that template app in Xamarin (forms) so we can compare the two.

Regarding the API, I want this App to be protocol-agnostic. Internally, it has a virtual vehicle with a set of metrics, messaging system, and set of commands that can be issued. Then we can implement the actual protocols and directly support things like Tesla?s API, Carwings, etc, as well as OVMS. This also makes it very simple to migrate from protocol v2 to v3 (or our http api).

Regards, Mark

> On 24 Jun 2020, at 9:10 PM, S?bastien Darveau <sebastien.darveau at synnoetic.com> wrote:
> 
> Hello, 
> 
> Here is my 2 cents on this.
> 
> - Have you also looked into Xamarin.Forms? It is the equivalent display templated approach used by Xamarin for Multiplatform UI. It uses data binding to instantly reflect model changes and it is quite flexible. It usually goes with the MVVM (Model-View ViewModel) design pattern. I have a year of experience with it and I can help to start the project.
> 
> - I can?t really talk about vehicle-server protocols but for app-server communication, I would favour a well designed REST api. As for the low level protocol, I used to have a separate project containing only DTO objects that is shared by server and client as a submodule. This is the interface. Server uses Automapper ( https://automapper.org/ <https://automapper.org/> ) to map entities to DTO objects before sending back the response. 
> 
> Regards,
> Sebastien Darveau
> 
> 
>> On Jun 15, 2020, at 3:00 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>> 
>> 
>> As you may know, I?ve been working for some time on the design of a cross platform unified App for OVMS. Here are my thoughts.
>> 
>> I think our approach of the ?virtual vehicle?, represented by a hash/set of metric->value, works well. We have been successful in providing common vehicle metrics for more than a dozen different types of electric vehicle, plus a bunch of other generic types. Overall, I think this is the correct approach, and lends itself very well to the IoT MQTT way of doing things.
>> 
>> Maintaining two separate Apps on two different platforms has been difficult, and the features and functionality are diverging too much.
>> 
>> The v2 protocol is too limiting (especially for new vehicle types, and custom metrics).
>> 
>> I like the idea of providing a ?templated? approach to the displays in the Apps. We design templates to pick metrics, along with other assets, and display their current values updated in real time.
>> 
>> By leveraging the ?virtual vehicle? model, we can also introduce the concept of vehicle sources. At the moment, we are limited to just one vehicle data source - OVMS protocol v2, and to some extent the apps already convert the incoming v2 data into a hard-coded set of metrics, with hard-coded display layouts. The purpose of these vehicle sources is to login to a remote server, retrieve the vehicle data, and store it as the standardised metrics, in the standardised ?virtual vehicle?. Example sources could be OVMS protocol v2, OVMS protocol v3 (MQTT), Tesla API, Carwings API, direct bluetooth to an OVMS module, etc. We could virtualise these protocols, with a common interface.
>> 
>> So, my proposal is:
>> 
>> We develop a single universal App, coded in a ?free? open environment. I have looked at Xamarin and Phonegap (vue-js, and a bunch of alternatives in common use nowadays). My current preference is vue-js, as it seems that javascript and html lend themselves best to the templated display approach - it is trivial to dynamically load this content. That, plus the environment is truly free and well understood by a huge developer community. However, no decision has been made and I am open to suggestions.
>> 
>> The App implements a virtual protocol system. Each virtual protocol talks a particular backend API for a particular account. The virtual protocol then publishes vehicles for the user to choose from. Initially we would write an OVMS v2 protocol implementation, but others (as previously listed) should be relatively easy to implement.
>> 
>> The App implements a virtual vehicle system. Each virtual protocol converts the incoming vehicle data to the virtual vehicle metrics. We can base this simply on the OVMS v3 standardised metrics, but custom metrics also need to be supported. Commands to be sent to the vehicle can also be implemented in a similar way. The OVMS v3 MQTT protocol would be a 1-to-1 mapping here, for example.
>> 
>> The App displays are implemented via a templating system, with templates provided per vehicle type and per screen type (phone, tablet, desktop, etc). The user can customise these templates, using either named virtual vehicle metrics or other assets (pictures, buttons for commands, etc).
>> 
>> I feel that this approach provides an excellent balance. It allows for comprehensive support and flexibility of display for each vehicle type, without complicating the implementation. It also allows owners of more than one type of vehicle (perhaps not all supported by OVMS) to use a single App to monitor and control.
>> 
>> I am happy to build the framework for this, but would much prefer others to come on board to assist.
>> 
>> Any thoughts or suggestion are most welcome.
>> 
>> Regards, Mark.
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200626/35a9773b/attachment.html>

From kommykt at gmail.com  Mon Jun  1 23:30:22 2020
From: kommykt at gmail.com (=?UTF-8?B?VGFtw6FzIEtvdsOhY3M=?=)
Date: Mon, 1 Jun 2020 17:30:22 +0200
Subject: [Ovmsdev] Save Status
Message-ID: <CAGpaXUt_zdGjTLecuq+w5EVeG-JPMecFr3g8c8Hvo2vMvPOaTg@mail.gmail.com>

I would like to implement Save status to save / load value when module
crash. I copy kia_common.h/cpp and remove all code not relevant, added code
to vehicle_mitsubishi.h/cpp same as kia, but not restore the soc value.
If i check the saved file at web interface / editor has size 4, and if i
open it is empty.

Last time i saw the Trip power plugin do the same at my module, if
module restart no data in web interface. I think Trip power chart plugin
overwrite the datafile after reboot. Save data to SD card.

Any idea?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200601/47768bc9/attachment.htm>

From egon at heuer-humfeld.de  Tue Jun  2 00:54:42 2020
From: egon at heuer-humfeld.de (Thomas Heuer)
Date: Mon, 01 Jun 2020 18:54:42 +0200
Subject: [Ovmsdev] Save Status
References: <CAGpaXUt_zdGjTLecuq+w5EVeG-JPMecFr3g8c8Hvo2vMvPOaTg@mail.gmail.com>
Message-ID: <31zq6x-xuiabq-r5kug56qo9dsnwsk0l309poo-h0n37t-syaiklhhx2mt81xbold276ln-68b9oi-l02l3g-4kod03-dh1jo7-quowgsjah2vu-tk4yeywpsf6idxjs43tqjnhe-u513syrerssq26289.1591030482404@email.android.com>

An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200601/56d8db97/attachment.htm>

From shamziman at gmail.com  Tue Jun  2 01:58:40 2020
From: shamziman at gmail.com (Shaun Jurrens)
Date: Mon, 1 Jun 2020 19:58:40 +0200
Subject: [Ovmsdev] UserTrust/AddTrust/Comodo root CA expiration
In-Reply-To: <CC50B134-C817-469D-AFCA-4CB8E3929B3B@webb-johnson.net>
References: <CC50B134-C817-469D-AFCA-4CB8E3929B3B@webb-johnson.net>
Message-ID: <E905A327-6044-46D1-A3C7-1FCAB26D122D@gmail.com>

Hi,

I finally got my module in these Covid times (took 2 shipments and almost 3 months) and got it set up for the first time and after I got logged in via ssh, I also got the new certificate installed after a few minutes of orienting myself with the file system commands.  It might be worth mentioning that the ?trustedca? directory doesn?t actually exist by default.  So basically, you need to do:

OVMS# vfs mkdir /store/trustedca 

and then from a laptop terminal prompt:
scp -c aes128-cbc usertrust.crt omvs at 192.168.4.1:/store/trustedca/usertrust.crt 

I?m not sure if the cipher needs to be specified and the module seemed to need a reboot to read the certificate, but I then finally did get a connection.

There was still some noise from mongoose about SSL, but it didn?t seem to affect the v2 server connection.

Overall, it was pretty easy to setup and much more transparent than my old V2 module. I guess I should start looking at the Volt/Ampere code to see if this pre-heat option is real and app accessible.

Yada, yada,
Shaun
(via the iPad thingamajigg)

> On 31 May 2020, at 02:45, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> ?
> 
> The AddTrust root CA certificate that our api.openvehicles.com is signed by has expired (last night). This will impact TLS connections to api.openvehicles.com. Our certificate itself is fine (and doesn?t expire until Feb 2022), but the root cert is was signed by (via intermediaries) has expired.
> 
> Pretty irresponsible for AddTrust/UserTrust/Comodo to sign a certificate with a later expiration date than their own CA, imho. Also irresponsible for them not to inform the customers. Everybody can be expected to monitor their own certificate expiration date, but not that of their certificate authority.
> 
> I?ve been up most of the night dealing with fallout from this (in other work and customer related systems), so not happy.
> 
> Anyway, I?ve updated the trusted root certificate in edge now, and released that. AddTrust has become UserTrust.
> 
> To connect via tls to api.openvehicles.com now, you will either need to firmware update, or manually add the trusted ca to /store/trustedca/usertrust.crt (I have attached it here, for convenience).
> 
> I have also taken this opportunity to change the server v2 and v3 backoff retry times to 60 seconds (was 20 or 30).
> 
> Regards, Mark.
> 
> <usertrust.crt>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200601/1a5e87f3/attachment.htm>

From kommykt at gmail.com  Fri Jun  5 11:25:15 2020
From: kommykt at gmail.com (=?UTF-8?B?VGFtw6FzIEtvdsOhY3M=?=)
Date: Fri, 5 Jun 2020 05:25:15 +0200
Subject: [Ovmsdev] Save Status
In-Reply-To: <31zq6x-xuiabq-r5kug56qo9dsnwsk0l309poo-h0n37t-syaiklhhx2mt81xbold276ln-68b9oi-l02l3g-4kod03-dh1jo7-quowgsjah2vu-tk4yeywpsf6idxjs43tqjnhe-u513syrerssq26289.1591030482404@email.android.com>
References: <CAGpaXUt_zdGjTLecuq+w5EVeG-JPMecFr3g8c8Hvo2vMvPOaTg@mail.gmail.com>
 <31zq6x-xuiabq-r5kug56qo9dsnwsk0l309poo-h0n37t-syaiklhhx2mt81xbold276ln-68b9oi-l02l3g-4kod03-dh1jo7-quowgsjah2vu-tk4yeywpsf6idxjs43tqjnhe-u513syrerssq26289.1591030482404@email.android.com>
Message-ID: <CAGpaXUsa=JpvPVrBToDUEb4X2SKF18r4Om8URtj19MvUaXkaHA@mail.gmail.com>

Thanks ! SmartED code works very well.

Thomas Heuer <egon at heuer-humfeld.de> ezt ?rta (id?pont: 2020. j?n. 1., H,
18:55):

> Look at the Smarted code vor save and restore status.
> The problem is, that the SD is mounted to late.
>
> Von meinem Huawei-Telefon gesendet
>
>
> -------- Urspr?ngliche Nachricht --------
> Von: Tam?s Kov?cs <kommykt at gmail.com>
> Datum: Mo., 1. Juni 2020, 17:30
> An: OVMS Developers <ovmsdev at lists.openvehicles.com>
> Betreff: [Ovmsdev] Save Status
>
> I would like to implement Save status to save / load value when module
> crash. I copy kia_common.h/cpp and remove all code not relevant, added code
> to vehicle_mitsubishi.h/cpp same as kia, but not restore the soc value.
> If i check the saved file at web interface / editor has size 4, and if i
> open it is empty.
>
> Last time i saw the Trip power plugin do the same at my module, if
> module restart no data in web interface. I think Trip power chart plugin
> overwrite the datafile after reboot. Save data to SD card.
>
> Any idea?
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>


-- 
?dv?zlettel:
Kov?cs Tam?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200605/6d857948/attachment.htm>

From kommykt at gmail.com  Fri Jun  5 11:29:35 2020
From: kommykt at gmail.com (=?UTF-8?B?VGFtw6FzIEtvdsOhY3M=?=)
Date: Fri, 5 Jun 2020 05:29:35 +0200
Subject: [Ovmsdev] Random crash if enable notifications
Message-ID: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>

Some day's ago i enabled Pushover notifications and i get some crash after
that.

The crash backtrase is:
Backtrace: 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361
0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4
0x400f0db4 0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545
0x400f375e 0x400f37d5 0x400f37e5

a2l output is:

kommykt at MacBook-Air OVMS.V3 % a2l 0x4008b75f 0x4008b9f9 0x4010b253
0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1
0x400f0dbb 0x400f0db4 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109
0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5

Using elf file:
/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf


0x4008b75f is in invoke_abort
(/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).

151 #endif

152     while (1) {

153         if (esp_cpu_in_ocd_debug_mode()) {

154             __asm__ ("break 0,0");

155         }

156         *((int *) 0) = 0;

157     }

158 }

159

160 void abort()


0x4008b9f9 is in abort
(/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).

166     * don't overwrite that.

167     */

168     if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {

169         esp_reset_reason_set_hint(ESP_RST_PANIC);

170     }

171     invoke_abort();

172 }

173

174

175 static const char *edesc[] = {


0x4010b253 is in __assert_func
(../../../.././newlib/libc/stdlib/assert.c:63).


0x40098c5f is in multi_heap_free
(/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).

209         return;

210     }

211     multi_heap_internal_lock(heap);

212

213     poison_head_t *head = verify_allocated_region(p, true);

214     assert(head != NULL);

215

216     #ifdef SLOW

217     /* replace everything with FREE_FILL_PATTERN, including the poison
head/tail */

218     memset(head, FREE_FILL_PATTERN,


0x40084361 is in heap_caps_free
(/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).

263         ptr = (void *)dramAddrPtr[-1];

264     }

265

266     heap_t *heap = find_containing_heap(ptr);

267     assert(heap != NULL && "free() target pointer is outside heap
areas");

268     multi_heap_free(heap->heap, ptr);

269 }

270

271 IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)

272 {


0x40084945 is in _free_r
(/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).

37     return heap_caps_malloc_default( size );

38 }

39

40 void IRAM_ATTR _free_r(struct _reent *r, void* ptr)

41 {

42     heap_caps_free( ptr );

43 }

44

45 void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)

46 {


0x401c1181 is in operator delete(void*)
(/Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/del_op.cc:46).


0x400f01e1 is in std::_Rb_tree<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::_Select1st<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >
>::_M_drop_node(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >*)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110).

105       }

106

107       // __p is not permitted to be a null pointer.

108       void

109       deallocate(pointer __p, size_type)

110       { ::operator delete(__p); }

111

112       size_type

113       max_size() const _GLIBCXX_USE_NOEXCEPT

114       { return size_t(-1) / sizeof(_Tp); }


0x400f0dbb is in std::_Rb_tree<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::_Select1st<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >
>::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >*)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1614).

1609       // Erase without rebalancing.

1610       while (__x != 0)

1611 {

1612   _M_erase(_S_right(__x));

1613   _Link_type __y = _S_left(__x);

1614   _M_drop_node(__x);

1615   __x = __y;

1616 }

1617     }

1618


0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::_Select1st<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >
>::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >*)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).

1607     _M_erase(_Link_type __x)

1608     {

1609       // Erase without rebalancing.

1610       while (__x != 0)

1611 {

1612   _M_erase(_S_right(__x));

1613   _Link_type __y = _S_left(__x);

1614   _M_drop_node(__x);

1615   __x = __y;

1616 }


0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::_Select1st<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >
>::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >*)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).

1607     _M_erase(_Link_type __x)

1608     {

1609       // Erase without rebalancing.

1610       while (__x != 0)

1611 {

1612   _M_erase(_S_right(__x));

1613   _Link_type __y = _S_left(__x);

1614   _M_drop_node(__x);

1615   __x = __y;

1616 }


0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::_Select1st<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >
>::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >*)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).

1607     _M_erase(_Link_type __x)

1608     {

1609       // Erase without rebalancing.

1610       while (__x != 0)

1611 {

1612   _M_erase(_S_right(__x));

1613   _Link_type __y = _S_left(__x);

1614   _M_drop_node(__x);

1615   __x = __y;

1616 }


0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::_Select1st<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >
>::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > > >*)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).

1607     _M_erase(_Link_type __x)

1608     {

1609       // Erase without rebalancing.

1610       while (__x != 0)

1611 {

1612   _M_erase(_S_right(__x));

1613   _Link_type __y = _S_left(__x);

1614   _M_drop_node(__x);

1615   __x = __y;

1616 }


0x40156109 is in Pushover::EventListener(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, void*)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:858).

853

854       _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a);

855 #endif

856

857       ~_Rb_tree() _GLIBCXX_NOEXCEPT

858       { _M_erase(_M_begin()); }

859

860       _Rb_tree&

861       operator=(const _Rb_tree& __x);

862


0x401550da is in std::_Function_handler<void
(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, void*), std::_Bind<std::_Mem_fn<void
(Pushover::*)(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, void*)> (Pushover*, std::_Placeholder<1>,
std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >&&, void*&&)
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600).

595       template<typename... _Args, typename _Req

596               = _Require<typename _Traits::__lvalue,

597                           _CheckArgs<_Pack<_Args...>>>>

598 result_type

599 operator()(_Class* __object, _Args&&... __args) const

600 { return (__object->*_M_pmf)(std::forward<_Args>(__args)...); }

601

602       // Handle smart pointers, references and pointers to derived

603       template<typename _Tp, typename... _Args, typename _Req

604               = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*, _Tp>,


0x400f3545 is in std::function<void (std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
void*)>::operator()(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, void*) const
(/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271).

2266     function<_Res(_ArgTypes...)>::

2267     operator()(_ArgTypes... __args) const

2268     {

2269       if (_M_empty())

2270 __throw_bad_function_call();

2271       return _M_invoker(_M_functor,
std::forward<_ArgTypes>(__args)...);

2272     }

2273

2274 #if __cpp_rtti

2275   template<typename _Res, typename... _ArgTypes>


0x400f375e is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*)
(/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:234).

229       {

230       for (EventCallbackList::iterator itc=el->begin(); itc!=el->end();
++itc)

231         {

232         m_current_started = monotonictime;

233         m_current_callback = *itc;

234         m_current_callback->m_callback(m_current_event,
msg->body.signal.data);

235         m_current_callback = NULL;

236         }

237       }

238     }


0x400f37d5 is in OvmsEvents::EventTask()
(/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:185).

180       switch(msg.type)

181         {

182         case EVENT_none:

183           break;

184         case EVENT_signal:

185           HandleQueueSignalEvent(&msg);

186           break;

187         default:

188           break;

189         }


0x400f37e5 is in EventLaunchTask(void*)
(/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:56).

51

52 void EventLaunchTask(void *pvParameters)

53   {

54   OvmsEvents* me = (OvmsEvents*)pvParameters;

55

56   me->EventTask();

57   }

58

59 void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand* cmd,
int argc, const char* const* argv)

60   {

-- 
?dv?zlettel:
Kov?cs Tam?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200605/3d5ead2b/attachment.htm>

From dexter at expeedo.de  Fri Jun  5 12:57:10 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Fri, 5 Jun 2020 06:57:10 +0200
Subject: [Ovmsdev] Random crash if enable notifications
In-Reply-To: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>
References: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>
Message-ID: <3ce6a6e3-8119-f123-296c-653ba3e258b4@expeedo.de>

Tam?s,

that doesn't need to be related to the pushover code. Do you run the spiram fix? I had this kind of heap corruption crashes frequently on builds without the
spiram fix but not once with the fix.

Regards,
Michael


Am 05.06.20 um 05:29 schrieb Tam?s Kov?cs:
> Some day's ago i enabled Pushover notifications and i get some crash after that.
>
> The crash backtrase?is:?
> Backtrace: 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4 0x400f0db4 0x400f0db4
> 0x400f0db4 0x40156109 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
> a2l output is:
>
> kommykt at MacBook-Air OVMS.V3 % a2l 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4
> 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>
> Using elf file: /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>
>
> 0x4008b75f is in invoke_abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>
> 151#endif
>
> 152? ? while (1) {
>
> 153? ? ? ? if (esp_cpu_in_ocd_debug_mode()) {
>
> 154? ? ? ? ? ? __asm__ ("break 0,0");
>
> 155? ? ? ? }
>
> 156? ? ? ? *((int *) 0) = 0;
>
> 157? ? }
>
> 158}
>
> 159
>
> 160void abort()
>
>
> 0x4008b9f9 is in abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>
> 166? ? * don't overwrite that.
>
> 167? ? */
>
> 168? ? if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>
> 169? ? ? ? esp_reset_reason_set_hint(ESP_RST_PANIC);
>
> 170? ? }
>
> 171? ? invoke_abort();
>
> 172}
>
> 173
>
> 174
>
> 175static const char *edesc[] = {
>
>
> 0x4010b253 is in __assert_func (../../../.././newlib/libc/stdlib/assert.c:63).
>
>
> 0x40098c5f is in multi_heap_free (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>
> 209? ? ? ? return;
>
> 210? ? }
>
> 211? ? multi_heap_internal_lock(heap);
>
> 212
>
> 213? ? poison_head_t *head = verify_allocated_region(p, true);
>
> 214? ? assert(head != NULL);
>
> 215
>
> 216? ? #ifdef SLOW
>
> 217? ? /* replace everything with FREE_FILL_PATTERN, including the poison head/tail */
>
> 218? ? memset(head, FREE_FILL_PATTERN,
>
>
> 0x40084361 is in heap_caps_free (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>
> 263? ? ? ? ptr = (void *)dramAddrPtr[-1];
>
> 264? ? }
>
> 265
>
> 266? ? heap_t *heap = find_containing_heap(ptr);
>
> 267? ? assert(heap != NULL && "free() target pointer is outside heap areas");
>
> 268? ? multi_heap_free(heap->heap, ptr);
>
> 269}
>
> 270
>
> 271IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>
> 272{
>
>
> 0x40084945 is in _free_r (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>
> 37? ? return heap_caps_malloc_default( size );
>
> 38}
>
> 39
>
> 40void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>
> 41{
>
> 42? ? heap_caps_free( ptr );
>
> 43}
>
> 44
>
> 45void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>
> 46{
>
>
> 0x401c1181 is in operator delete(void*) (/Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/del_op.cc:46).
>
>
> 0x400f01e1 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > >::_M_drop_node(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110).
>
> 105? ? ? }
>
> 106
>
> 107? ? ? // __p is not permitted to be a null pointer.
>
> 108? ? ? void
>
> 109? ? ? deallocate(pointer __p, size_type)
>
> 110? ? ? { ::operator delete(__p); }
>
> 111
>
> 112? ? ? size_type
>
> 113? ? ? max_size() const _GLIBCXX_USE_NOEXCEPT
>
> 114? ? ? { return size_t(-1) / sizeof(_Tp); }
>
>
> 0x400f0dbb is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1614).
>
> 1609? ? ? // Erase without rebalancing.
>
> 1610? ? ? while (__x != 0)
>
> 1611{
>
> 1612? _M_erase(_S_right(__x));
>
> 1613? _Link_type __y = _S_left(__x);
>
> 1614? _M_drop_node(__x);
>
> 1615? __x = __y;
>
> 1616}
>
> 1617? ? }
>
> 1618
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607? ? _M_erase(_Link_type __x)
>
> 1608? ? {
>
> 1609? ? ? // Erase without rebalancing.
>
> 1610? ? ? while (__x != 0)
>
> 1611{
>
> 1612? _M_erase(_S_right(__x));
>
> 1613? _Link_type __y = _S_left(__x);
>
> 1614? _M_drop_node(__x);
>
> 1615? __x = __y;
>
> 1616}
>
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607? ? _M_erase(_Link_type __x)
>
> 1608? ? {
>
> 1609? ? ? // Erase without rebalancing.
>
> 1610? ? ? while (__x != 0)
>
> 1611{
>
> 1612? _M_erase(_S_right(__x));
>
> 1613? _Link_type __y = _S_left(__x);
>
> 1614? _M_drop_node(__x);
>
> 1615? __x = __y;
>
> 1616}
>
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607? ? _M_erase(_Link_type __x)
>
> 1608? ? {
>
> 1609? ? ? // Erase without rebalancing.
>
> 1610? ? ? while (__x != 0)
>
> 1611{
>
> 1612? _M_erase(_S_right(__x));
>
> 1613? _Link_type __y = _S_left(__x);
>
> 1614? _M_drop_node(__x);
>
> 1615? __x = __y;
>
> 1616}
>
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607? ? _M_erase(_Link_type __x)
>
> 1608? ? {
>
> 1609? ? ? // Erase without rebalancing.
>
> 1610? ? ? while (__x != 0)
>
> 1611{
>
> 1612? _M_erase(_S_right(__x));
>
> 1613? _Link_type __y = _S_left(__x);
>
> 1614? _M_drop_node(__x);
>
> 1615? __x = __y;
>
> 1616}
>
>
> 0x40156109 is in Pushover::EventListener(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:858).
>
> 853
>
> 854? ? ? _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a);
>
> 855#endif
>
> 856
>
> 857? ? ? ~_Rb_tree() _GLIBCXX_NOEXCEPT
>
> 858? ? ? { _M_erase(_M_begin()); }
>
> 859
>
> 860? ? ? _Rb_tree&
>
> 861? ? ? operator=(const _Rb_tree& __x);
>
> 862
>
> 0x401550da is in std::_Function_handler<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*),
> std::_Bind<std::_Mem_fn<void (Pushover::*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)> (Pushover*,
> std::_Placeholder<1>, std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>
> >&&, void*&&) (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600).
>
> 595? ? ? template<typename... _Args, typename _Req
>
> 596? ? ? ? ? ? ? = _Require<typename _Traits::__lvalue,
>
> 597? ? ? ? ? ? ? ? ? ? ? ? ? _CheckArgs<_Pack<_Args...>>>>
>
> 598result_type
>
> 599operator()(_Class* __object, _Args&&... __args) const
>
> 600{ return (__object->*_M_pmf)(std::forward<_Args>(__args)...); }
>
> 601
>
> 602? ? ? // Handle smart pointers, references and pointers to derived
>
> 603? ? ? template<typename _Tp, typename... _Args, typename _Req
>
> 604? ? ? ? ? ? ? = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*, _Tp>,
>
>
> 0x400f3545 is in std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
> void*)>::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) const
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271).
>
> 2266? ? function<_Res(_ArgTypes...)>::
>
> 2267? ? operator()(_ArgTypes... __args) const
>
> 2268? ? {
>
> 2269? ? ? if (_M_empty())
>
> 2270__throw_bad_function_call();
>
> 2271? ? ? return _M_invoker(_M_functor, std::forward<_ArgTypes>(__args)...);
>
> 2272? ? }
>
> 2273
>
> 2274#if __cpp_rtti
>
> 2275? template<typename _Res, typename... _ArgTypes>
>
>
> 0x400f375e is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*)
> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:234).
>
> 229? ? ? {
>
> 230? ? ? for (EventCallbackList::iterator itc=el->begin(); itc!=el->end(); ++itc)
>
> 231? ? ? ? {
>
> 232? ? ? ? m_current_started = monotonictime;
>
> 233? ? ? ? m_current_callback = *itc;
>
> 234? ? ? ? m_current_callback->m_callback(m_current_event, msg->body.signal.data);
>
> 235? ? ? ? m_current_callback = NULL;
>
> 236? ? ? ? }
>
> 237? ? ? }
>
> 238? ? }
>
>
> 0x400f37d5 is in OvmsEvents::EventTask() (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:185).
>
> 180? ? ? switch(msg.type)
>
> 181? ? ? ? {
>
> 182? ? ? ? case EVENT_none:
>
> 183? ? ? ? ? break;
>
> 184? ? ? ? case EVENT_signal:
>
> 185? ? ? ? ? HandleQueueSignalEvent(&msg);
>
> 186? ? ? ? ? break;
>
> 187? ? ? ? default:
>
> 188? ? ? ? ? break;
>
> 189? ? ? ? }
>
>
> 0x400f37e5 is in EventLaunchTask(void*) (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:56).
>
> 51
>
> 52void EventLaunchTask(void *pvParameters)
>
> 53? {
>
> 54? OvmsEvents* me = (OvmsEvents*)pvParameters;
>
> 55
>
> 56? me->EventTask();
>
> 57? }
>
> 58
>
> 59void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv)
>
> 60? {
>
>
> -- 
> ?dv?zlettel:
> Kov?cs Tam?s
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200605/345c162e/attachment.htm>

From mark at webb-johnson.net  Fri Jun  5 13:06:39 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Fri, 5 Jun 2020 13:06:39 +0800
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <97B46650-871C-40FF-B10E-A016963E0096@webb-johnson.net>
References: <97B46650-871C-40FF-B10E-A016963E0096@webb-johnson.net>
Message-ID: <2BC4ED11-7D86-4AB2-87AB-71D648318A3A@webb-johnson.net>

I have release this 3.2.013 to EAP.

Regards, Mark.

> On 31 May 2020, at 5:34 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> 
> Getting ready to release 3.2.013. I?ve tagged it, and built for api.openvehicles.com <http://api.openvehicles.com/> edge.
> 
> The main changes here are:
> 
> TPMS subsystem (including Tesla Roadster support with new optional K-line expansion board)
> Change to config for server.v2
> 
> For #2, I moved the server password from server.v2/password to password/server.v2, and made the server.v2 config parameter read-write. That better matches how server.v3 does it. The change is done via a config migration, so should be transparent.
> 
> Absent any issues, I plan to move to EAP early in the coming week.
> 
> Regards, Mark
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200605/f6576749/attachment.htm>

From dexter at expeedo.de  Fri Jun  5 13:15:05 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Fri, 5 Jun 2020 07:15:05 +0200
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <2BC4ED11-7D86-4AB2-87AB-71D648318A3A@webb-johnson.net>
References: <97B46650-871C-40FF-B10E-A016963E0096@webb-johnson.net>
 <2BC4ED11-7D86-4AB2-87AB-71D648318A3A@webb-johnson.net>
Message-ID: <ae250edd-441b-a6a2-feb7-2871984ad940@expeedo.de>

Followed.

Regards,
Michael


Am 05.06.20 um 07:06 schrieb Mark Webb-Johnson:
> I have release this?3.2.013 to EAP.
>
> Regards, Mark.
>
>> On 31 May 2020, at 5:34 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>
>>
>> Getting ready to release 3.2.013. I?ve tagged it, and built for api.openvehicles.com <http://api.openvehicles.com/>?edge.
>>
>> The main changes here are:
>>
>>  1. TPMS subsystem (including Tesla Roadster support with new optional K-line expansion board)
>>  2. Change to config for server.v2
>>
>>
>> For #2, I moved the server password from server.v2/password to password/server.v2, and made the server.v2 config parameter read-write. That better matches
>> how server.v3 does it. The change is done via a config migration, so should be transparent.
>>
>> Absent any issues, I plan to move to EAP early in the coming week.
>>
>> Regards, Mark
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200605/56688b6a/attachment.htm>

From casner at acm.org  Fri Jun  5 14:18:27 2020
From: casner at acm.org (Stephen Casner)
Date: Thu, 4 Jun 2020 23:18:27 -0700 (PDT)
Subject: [Ovmsdev] UserTrust/AddTrust/Comodo root CA expiration
In-Reply-To: <CC50B134-C817-469D-AFCA-4CB8E3929B3B@webb-johnson.net>
References: <CC50B134-C817-469D-AFCA-4CB8E3929B3B@webb-johnson.net>
Message-ID: <alpine.OSX.2.21.9999.2006042316290.59343@auge.attlocal.net>

Mark,

It appears that my email host, imap.sonic.net, was bit by the same
AddTrust root CA certificate expiration.  My email application just
complained.

                                                        -- Steve

On Sun, 31 May 2020, Mark Webb-Johnson wrote:

>
> The AddTrust root CA certificate that our api.openvehicles.com <http://api.openvehicles.com/> is signed by has expired (last night). This will impact TLS connections to api.openvehicles.com <http://api.openvehicles.com/>. Our certificate itself is fine (and doesn?t expire until Feb 2022), but the root cert is was signed by (via intermediaries) has expired.
>
> Pretty irresponsible for AddTrust/UserTrust/Comodo to sign a certificate with a later expiration date than their own CA, imho. Also irresponsible for them not to inform the customers. Everybody can be expected to monitor their own certificate expiration date, but not that of their certificate authority.
>
> I?ve been up most of the night dealing with fallout from this (in other work and customer related systems), so not happy.
>
> Anyway, I?ve updated the trusted root certificate in edge now, and released that. AddTrust has become UserTrust.
>
> To connect via tls to api.openvehicles.com <http://api.openvehicles.com/> now, you will either need to firmware update, or manually add the trusted ca to /store/trustedca/usertrust.crt (I have attached it here, for convenience).
>
> I have also taken this opportunity to change the server v2 and v3 backoff retry times to 60 seconds (was 20 or 30).
>
> Regards, Mark.

From kommykt at gmail.com  Sat Jun  6 02:04:09 2020
From: kommykt at gmail.com (=?UTF-8?B?VGFtw6FzIEtvdsOhY3M=?=)
Date: Fri, 5 Jun 2020 20:04:09 +0200
Subject: [Ovmsdev] Random crash if enable notifications
In-Reply-To: <3ce6a6e3-8119-f123-296c-653ba3e258b4@expeedo.de>
References: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>
 <3ce6a6e3-8119-f123-296c-653ba3e258b4@expeedo.de>
Message-ID: <CAGpaXUt0C_rv992y+bg7-wmD8wBZ_8g+hFoVndo7YL-xG8L3+A@mail.gmail.com>

i think i don't run spiram fix. How can i use it. I must check out branch
"spiram-fix-test"  to run spiram fix?

Michael Balzer <dexter at expeedo.de> ezt ?rta (id?pont: 2020. j?n. 5., P,
6:58):

> Tam?s,
>
> that doesn't need to be related to the pushover code. Do you run the
> spiram fix? I had this kind of heap corruption crashes frequently on builds
> without the spiram fix but not once with the fix.
>
> Regards,
> Michael
>
>
> Am 05.06.20 um 05:29 schrieb Tam?s Kov?cs:
>
> Some day's ago i enabled Pushover notifications and i get some crash after
> that.
>
> The crash backtrase is:
> Backtrace: 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361
> 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4
> 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545
> 0x400f375e 0x400f37d5 0x400f37e5
> a2l output is:
>
> kommykt at MacBook-Air OVMS.V3 % a2l 0x4008b75f 0x4008b9f9 0x4010b253
> 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1
> 0x400f0dbb 0x400f0db4 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109
> 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>
> Using elf file:
> /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>
>
> 0x4008b75f is in invoke_abort
> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>
> 151 #endif
>
> 152     while (1) {
>
> 153         if (esp_cpu_in_ocd_debug_mode()) {
>
> 154             __asm__ ("break 0,0");
>
> 155         }
>
> 156         *((int *) 0) = 0;
>
> 157     }
>
> 158 }
>
> 159
>
> 160 void abort()
>
>
> 0x4008b9f9 is in abort
> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>
> 166     * don't overwrite that.
>
> 167     */
>
> 168     if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>
> 169         esp_reset_reason_set_hint(ESP_RST_PANIC);
>
> 170     }
>
> 171     invoke_abort();
>
> 172 }
>
> 173
>
> 174
>
> 175 static const char *edesc[] = {
>
>
> 0x4010b253 is in __assert_func
> (../../../.././newlib/libc/stdlib/assert.c:63).
>
>
> 0x40098c5f is in multi_heap_free
> (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>
> 209         return;
>
> 210     }
>
> 211     multi_heap_internal_lock(heap);
>
> 212
>
> 213     poison_head_t *head = verify_allocated_region(p, true);
>
> 214     assert(head != NULL);
>
> 215
>
> 216     #ifdef SLOW
>
> 217     /* replace everything with FREE_FILL_PATTERN, including the
> poison head/tail */
>
> 218     memset(head, FREE_FILL_PATTERN,
>
>
> 0x40084361 is in heap_caps_free
> (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>
> 263         ptr = (void *)dramAddrPtr[-1];
>
> 264     }
>
> 265
>
> 266     heap_t *heap = find_containing_heap(ptr);
>
> 267     assert(heap != NULL && "free() target pointer is outside heap
> areas");
>
> 268     multi_heap_free(heap->heap, ptr);
>
> 269 }
>
> 270
>
> 271 IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>
> 272 {
>
>
> 0x40084945 is in _free_r
> (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>
> 37     return heap_caps_malloc_default( size );
>
> 38 }
>
> 39
>
> 40 void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>
> 41 {
>
> 42     heap_caps_free( ptr );
>
> 43 }
>
> 44
>
> 45 void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>
> 46 {
>
>
> 0x401c1181 is in operator delete(void*)
> (/Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/del_op.cc:46).
>
>
> 0x400f01e1 is in std::_Rb_tree<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >,
> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >
> >::_M_drop_node(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110).
>
> 105       }
>
> 106
>
> 107       // __p is not permitted to be a null pointer.
>
> 108       void
>
> 109       deallocate(pointer __p, size_type)
>
> 110       { ::operator delete(__p); }
>
> 111
>
> 112       size_type
>
> 113       max_size() const _GLIBCXX_USE_NOEXCEPT
>
> 114       { return size_t(-1) / sizeof(_Tp); }
>
>
> 0x400f0dbb is in std::_Rb_tree<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >,
> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >
> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1614).
>
> 1609       // Erase without rebalancing.
>
> 1610       while (__x != 0)
>
> 1611 {
>
> 1612   _M_erase(_S_right(__x));
>
> 1613   _Link_type __y = _S_left(__x);
>
> 1614   _M_drop_node(__x);
>
> 1615   __x = __y;
>
> 1616 }
>
> 1617     }
>
> 1618
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >,
> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >
> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607     _M_erase(_Link_type __x)
>
> 1608     {
>
> 1609       // Erase without rebalancing.
>
> 1610       while (__x != 0)
>
> 1611 {
>
> 1612   _M_erase(_S_right(__x));
>
> 1613   _Link_type __y = _S_left(__x);
>
> 1614   _M_drop_node(__x);
>
> 1615   __x = __y;
>
> 1616 }
>
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >,
> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >
> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607     _M_erase(_Link_type __x)
>
> 1608     {
>
> 1609       // Erase without rebalancing.
>
> 1610       while (__x != 0)
>
> 1611 {
>
> 1612   _M_erase(_S_right(__x));
>
> 1613   _Link_type __y = _S_left(__x);
>
> 1614   _M_drop_node(__x);
>
> 1615   __x = __y;
>
> 1616 }
>
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >,
> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >
> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607     _M_erase(_Link_type __x)
>
> 1608     {
>
> 1609       // Erase without rebalancing.
>
> 1610       while (__x != 0)
>
> 1611 {
>
> 1612   _M_erase(_S_right(__x));
>
> 1613   _Link_type __y = _S_left(__x);
>
> 1614   _M_drop_node(__x);
>
> 1615   __x = __y;
>
> 1616 }
>
>
> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >,
> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const, std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::allocator<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >
> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>
> 1607     _M_erase(_Link_type __x)
>
> 1608     {
>
> 1609       // Erase without rebalancing.
>
> 1610       while (__x != 0)
>
> 1611 {
>
> 1612   _M_erase(_S_right(__x));
>
> 1613   _Link_type __y = _S_left(__x);
>
> 1614   _M_drop_node(__x);
>
> 1615   __x = __y;
>
> 1616 }
>
>
> 0x40156109 is in Pushover::EventListener(std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >, void*)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:858).
>
> 853
>
> 854       _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a);
>
> 855 #endif
>
> 856
>
> 857       ~_Rb_tree() _GLIBCXX_NOEXCEPT
>
> 858       { _M_erase(_M_begin()); }
>
> 859
>
> 860       _Rb_tree&
>
> 861       operator=(const _Rb_tree& __x);
>
> 862
>
> 0x401550da is in std::_Function_handler<void
> (std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >, void*), std::_Bind<std::_Mem_fn<void
> (Pushover::*)(std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >, void*)> (Pushover*, std::_Placeholder<1>,
> std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >&&, void*&&)
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600).
>
> 595       template<typename... _Args, typename _Req
>
> 596               = _Require<typename _Traits::__lvalue,
>
> 597                           _CheckArgs<_Pack<_Args...>>>>
>
> 598 result_type
>
> 599 operator()(_Class* __object, _Args&&... __args) const
>
> 600 { return (__object->*_M_pmf)(std::forward<_Args>(__args)...); }
>
> 601
>
> 602       // Handle smart pointers, references and pointers to derived
>
> 603       template<typename _Tp, typename... _Args, typename _Req
>
> 604               = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*,
> _Tp>,
>
>
> 0x400f3545 is in std::function<void (std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >,
> void*)>::operator()(std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >, void*) const
> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271).
>
> 2266     function<_Res(_ArgTypes...)>::
>
> 2267     operator()(_ArgTypes... __args) const
>
> 2268     {
>
> 2269       if (_M_empty())
>
> 2270 __throw_bad_function_call();
>
> 2271       return _M_invoker(_M_functor,
> std::forward<_ArgTypes>(__args)...);
>
> 2272     }
>
> 2273
>
> 2274 #if __cpp_rtti
>
> 2275   template<typename _Res, typename... _ArgTypes>
>
>
> 0x400f375e is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*)
> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:234).
>
> 229       {
>
> 230       for (EventCallbackList::iterator itc=el->begin();
> itc!=el->end(); ++itc)
>
> 231         {
>
> 232         m_current_started = monotonictime;
>
> 233         m_current_callback = *itc;
>
> 234         m_current_callback->m_callback(m_current_event,
> msg->body.signal.data);
>
> 235         m_current_callback = NULL;
>
> 236         }
>
> 237       }
>
> 238     }
>
>
> 0x400f37d5 is in OvmsEvents::EventTask()
> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:185).
>
> 180       switch(msg.type)
>
> 181         {
>
> 182         case EVENT_none:
>
> 183           break;
>
> 184         case EVENT_signal:
>
> 185           HandleQueueSignalEvent(&msg);
>
> 186           break;
>
> 187         default:
>
> 188           break;
>
> 189         }
>
>
> 0x400f37e5 is in EventLaunchTask(void*)
> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:56).
>
> 51
>
> 52 void EventLaunchTask(void *pvParameters)
>
> 53   {
>
> 54   OvmsEvents* me = (OvmsEvents*)pvParameters;
>
> 55
>
> 56   me->EventTask();
>
> 57   }
>
> 58
>
> 59 void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand* cmd,
> int argc, const char* const* argv)
>
> 60   {
>
> --
> ?dv?zlettel:
> Kov?cs Tam?s
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>


-- 
?dv?zlettel:
Kov?cs Tam?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200605/6567c531/attachment.htm>

From dexter at expeedo.de  Sat Jun  6 03:42:15 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Fri, 5 Jun 2020 21:42:15 +0200
Subject: [Ovmsdev] Random crash if enable notifications
In-Reply-To: <CAGpaXUt0C_rv992y+bg7-wmD8wBZ_8g+hFoVndo7YL-xG8L3+A@mail.gmail.com>
References: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>
 <3ce6a6e3-8119-f123-296c-653ba3e258b4@expeedo.de>
 <CAGpaXUt0C_rv992y+bg7-wmD8wBZ_8g+hFoVndo7YL-xG8L3+A@mail.gmail.com>
Message-ID: <9e727cb7-1042-202d-c80a-b44b1e1d2f67@expeedo.de>

See previous posts on this, you also need the fixed toolchain: https://github.com/espressif/esp-idf/issues/2892#issuecomment-501106283

Regards,
Michael


Am 05.06.20 um 20:04 schrieb Tam?s Kov?cs:
> i think i don't run spiram fix. How can i use it.?I must?check out branch "spiram-fix-test" ?to run spiram fix?
>
> Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> ezt ?rta (id?pont: 2020. j?n. 5., P, 6:58):
>
>     Tam?s,
>
>     that doesn't need to be related to the pushover code. Do you run the spiram fix? I had this kind of heap corruption crashes frequently on builds without
>     the spiram fix but not once with the fix.
>
>     Regards,
>     Michael
>
>
>     Am 05.06.20 um 05:29 schrieb Tam?s Kov?cs:
>>     Some day's ago i enabled Pushover notifications and i get some crash after that.
>>
>>     The crash backtrase?is:?
>>     Backtrace: 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4 0x400f0db4 0x400f0db4
>>     0x400f0db4 0x40156109 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>>     a2l output is:
>>
>>     kommykt at MacBook-Air OVMS.V3 % a2l 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb
>>     0x400f0db4 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>>
>>     Using elf file: /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>>
>>
>>     0x4008b75f is in invoke_abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>>
>>     151#endif
>>
>>     152? ? while (1) {
>>
>>     153? ? ? ? if (esp_cpu_in_ocd_debug_mode()) {
>>
>>     154? ? ? ? ? ? __asm__ ("break 0,0");
>>
>>     155? ? ? ? }
>>
>>     156? ? ? ? *((int *) 0) = 0;
>>
>>     157? ? }
>>
>>     158}
>>
>>     159
>>
>>     160void abort()
>>
>>
>>     0x4008b9f9 is in abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>>
>>     166? ? * don't overwrite that.
>>
>>     167? ? */
>>
>>     168? ? if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>>
>>     169? ? ? ? esp_reset_reason_set_hint(ESP_RST_PANIC);
>>
>>     170? ? }
>>
>>     171? ? invoke_abort();
>>
>>     172}
>>
>>     173
>>
>>     174
>>
>>     175static const char *edesc[] = {
>>
>>
>>     0x4010b253 is in __assert_func (../../../.././newlib/libc/stdlib/assert.c:63).
>>
>>
>>     0x40098c5f is in multi_heap_free (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>>
>>     209? ? ? ? return;
>>
>>     210? ? }
>>
>>     211? ? multi_heap_internal_lock(heap);
>>
>>     212
>>
>>     213? ? poison_head_t *head = verify_allocated_region(p, true);
>>
>>     214? ? assert(head != NULL);
>>
>>     215
>>
>>     216? ? #ifdef SLOW
>>
>>     217? ? /* replace everything with FREE_FILL_PATTERN, including the poison head/tail */
>>
>>     218? ? memset(head, FREE_FILL_PATTERN,
>>
>>
>>     0x40084361 is in heap_caps_free (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>>
>>     263? ? ? ? ptr = (void *)dramAddrPtr[-1];
>>
>>     264? ? }
>>
>>     265
>>
>>     266? ? heap_t *heap = find_containing_heap(ptr);
>>
>>     267? ? assert(heap != NULL && "free() target pointer is outside heap areas");
>>
>>     268? ? multi_heap_free(heap->heap, ptr);
>>
>>     269}
>>
>>     270
>>
>>     271IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>>
>>     272{
>>
>>
>>     0x40084945 is in _free_r (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>>
>>     37? ? return heap_caps_malloc_default( size );
>>
>>     38}
>>
>>     39
>>
>>     40void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>>
>>     41{
>>
>>     42? ? heap_caps_free( ptr );
>>
>>     43}
>>
>>     44
>>
>>     45void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>>
>>     46{
>>
>>
>>     0x401c1181 is in operator delete(void*) (/Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/del_op.cc:46).
>>
>>
>>     0x400f01e1 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>     std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >
>>     >::_M_drop_node(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110).
>>
>>     105? ? ? }
>>
>>     106
>>
>>     107? ? ? // __p is not permitted to be a null pointer.
>>
>>     108? ? ? void
>>
>>     109? ? ? deallocate(pointer __p, size_type)
>>
>>     110? ? ? { ::operator delete(__p); }
>>
>>     111
>>
>>     112? ? ? size_type
>>
>>     113? ? ? max_size() const _GLIBCXX_USE_NOEXCEPT
>>
>>     114? ? ? { return size_t(-1) / sizeof(_Tp); }
>>
>>
>>     0x400f0dbb is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>     std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >
>>     >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1614).
>>
>>     1609? ? ? // Erase without rebalancing.
>>
>>     1610? ? ? while (__x != 0)
>>
>>     1611{
>>
>>     1612? _M_erase(_S_right(__x));
>>
>>     1613? _Link_type __y = _S_left(__x);
>>
>>     1614? _M_drop_node(__x);
>>
>>     1615? __x = __y;
>>
>>     1616}
>>
>>     1617? ? }
>>
>>     1618
>>
>>     0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>     std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >
>>     >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>>     1607? ? _M_erase(_Link_type __x)
>>
>>     1608? ? {
>>
>>     1609? ? ? // Erase without rebalancing.
>>
>>     1610? ? ? while (__x != 0)
>>
>>     1611{
>>
>>     1612? _M_erase(_S_right(__x));
>>
>>     1613? _Link_type __y = _S_left(__x);
>>
>>     1614? _M_drop_node(__x);
>>
>>     1615? __x = __y;
>>
>>     1616}
>>
>>
>>     0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>     std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >
>>     >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>>     1607? ? _M_erase(_Link_type __x)
>>
>>     1608? ? {
>>
>>     1609? ? ? // Erase without rebalancing.
>>
>>     1610? ? ? while (__x != 0)
>>
>>     1611{
>>
>>     1612? _M_erase(_S_right(__x));
>>
>>     1613? _Link_type __y = _S_left(__x);
>>
>>     1614? _M_drop_node(__x);
>>
>>     1615? __x = __y;
>>
>>     1616}
>>
>>
>>     0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>     std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >
>>     >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>>     1607? ? _M_erase(_Link_type __x)
>>
>>     1608? ? {
>>
>>     1609? ? ? // Erase without rebalancing.
>>
>>     1610? ? ? while (__x != 0)
>>
>>     1611{
>>
>>     1612? _M_erase(_S_right(__x));
>>
>>     1613? _Link_type __y = _S_left(__x);
>>
>>     1614? _M_drop_node(__x);
>>
>>     1615? __x = __y;
>>
>>     1616}
>>
>>
>>     0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>     std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >
>>     >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const,
>>     std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>>     1607? ? _M_erase(_Link_type __x)
>>
>>     1608? ? {
>>
>>     1609? ? ? // Erase without rebalancing.
>>
>>     1610? ? ? while (__x != 0)
>>
>>     1611{
>>
>>     1612? _M_erase(_S_right(__x));
>>
>>     1613? _Link_type __y = _S_left(__x);
>>
>>     1614? _M_drop_node(__x);
>>
>>     1615? __x = __y;
>>
>>     1616}
>>
>>
>>     0x40156109 is in Pushover::EventListener(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:858).
>>
>>     853
>>
>>     854? ? ? _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a);
>>
>>     855#endif
>>
>>     856
>>
>>     857? ? ? ~_Rb_tree() _GLIBCXX_NOEXCEPT
>>
>>     858? ? ? { _M_erase(_M_begin()); }
>>
>>     859
>>
>>     860? ? ? _Rb_tree&
>>
>>     861? ? ? operator=(const _Rb_tree& __x);
>>
>>     862
>>
>>     0x401550da is in std::_Function_handler<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*),
>>     std::_Bind<std::_Mem_fn<void (Pushover::*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)> (Pushover*,
>>     std::_Placeholder<1>, std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&, std::__cxx11::basic_string<char, std::char_traits<char>,
>>     std::allocator<char> >&&, void*&&) (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600).
>>
>>     595? ? ? template<typename... _Args, typename _Req
>>
>>     596? ? ? ? ? ? ? = _Require<typename _Traits::__lvalue,
>>
>>     597? ? ? ? ? ? ? ? ? ? ? ? ? _CheckArgs<_Pack<_Args...>>>>
>>
>>     598result_type
>>
>>     599operator()(_Class* __object, _Args&&... __args) const
>>
>>     600{ return (__object->*_M_pmf)(std::forward<_Args>(__args)...); }
>>
>>     601
>>
>>     602? ? ? // Handle smart pointers, references and pointers to derived
>>
>>     603? ? ? template<typename _Tp, typename... _Args, typename _Req
>>
>>     604? ? ? ? ? ? ? = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*, _Tp>,
>>
>>
>>     0x400f3545 is in std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>     void*)>::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) const
>>     (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271).
>>
>>     2266? ? function<_Res(_ArgTypes...)>::
>>
>>     2267? ? operator()(_ArgTypes... __args) const
>>
>>     2268? ? {
>>
>>     2269? ? ? if (_M_empty())
>>
>>     2270__throw_bad_function_call();
>>
>>     2271? ? ? return _M_invoker(_M_functor, std::forward<_ArgTypes>(__args)...);
>>
>>     2272? ? }
>>
>>     2273
>>
>>     2274#if __cpp_rtti
>>
>>     2275? template<typename _Res, typename... _ArgTypes>
>>
>>
>>     0x400f375e is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*)
>>     (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:234).
>>
>>     229? ? ? {
>>
>>     230? ? ? for (EventCallbackList::iterator itc=el->begin(); itc!=el->end(); ++itc)
>>
>>     231? ? ? ? {
>>
>>     232? ? ? ? m_current_started = monotonictime;
>>
>>     233? ? ? ? m_current_callback = *itc;
>>
>>     234? ? ? ? m_current_callback->m_callback(m_current_event, msg->body.signal.data);
>>
>>     235? ? ? ? m_current_callback = NULL;
>>
>>     236? ? ? ? }
>>
>>     237? ? ? }
>>
>>     238? ? }
>>
>>
>>     0x400f37d5 is in OvmsEvents::EventTask() (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:185).
>>
>>     180? ? ? switch(msg.type)
>>
>>     181? ? ? ? {
>>
>>     182? ? ? ? case EVENT_none:
>>
>>     183? ? ? ? ? break;
>>
>>     184? ? ? ? case EVENT_signal:
>>
>>     185? ? ? ? ? HandleQueueSignalEvent(&msg);
>>
>>     186? ? ? ? ? break;
>>
>>     187? ? ? ? default:
>>
>>     188? ? ? ? ? break;
>>
>>     189? ? ? ? }
>>
>>
>>     0x400f37e5 is in EventLaunchTask(void*) (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:56).
>>
>>     51
>>
>>     52void EventLaunchTask(void *pvParameters)
>>
>>     53? {
>>
>>     54? OvmsEvents* me = (OvmsEvents*)pvParameters;
>>
>>     55
>>
>>     56? me->EventTask();
>>
>>     57? }
>>
>>     58
>>
>>     59void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv)
>>
>>     60? {
>>
>>
>>     -- 
>>     ?dv?zlettel:
>>     Kov?cs Tam?s
>>
>>
>>     _______________________________________________
>>     OvmsDev mailing list
>>     OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>     -- 
>     Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>     Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
>     _______________________________________________
>     OvmsDev mailing list
>     OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> -- 
> ?dv?zlettel:
> Kov?cs Tam?s
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200605/775b2b78/attachment.htm>

From leres at xse.com  Sun Jun  7 04:02:55 2020
From: leres at xse.com (Craig Leres)
Date: Sat, 6 Jun 2020 13:02:55 -0700
Subject: [Ovmsdev] Persistent metrics
In-Reply-To: <93BA45A0-4637-4B13-B1A9-24F5EDEDC3CB@webb-johnson.net>
References: <21eeed64-9ba4-4e5b-d550-b75cac5e0cef@gmail.com>
 <05748430-9C2F-4120-9140-6B79632B7B45@webb-johnson.net>
 <b01fb424-525d-f7ea-eb8a-3bd20828f768@gmail.com>
 <93BA45A0-4637-4B13-B1A9-24F5EDEDC3CB@webb-johnson.net>
Message-ID: <f5fe5127-8cb2-7555-b3be-24c6bcd1c627@xse.com>

On 2020-04-21 20:21, Mark Webb-Johnson wrote:
> There is a small amount of RTC ram that is retained through a reboot.
> Perhaps we could have a mechanism to save+restore certain metrics there?
> But not at all simple.

I figured out how to do this and implemented it with this pull request:


https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/377

The trick is the RTC_NOINIT_ATTR macro which places data into RTC slow
memory, in a memory section that is not initialized on boot:


https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/general-notes.html

There is a new persist argument that can be used when creating a metric:

    -  ms_v_bat_soc = new OvmsMetricFloat(MS_V_BAT_SOC, SM_STALE_HIGH,
Percentage);
    +  ms_v_bat_soc = new OvmsMetricFloat(MS_V_BAT_SOC, SM_STALE_HIGH,
Percentage, true);

This is only implemented for OvmsMetricFloat and I only enabled it for a
small set of metrics. "metrics persist" shows what's being saved, how
many bytes are in use, etc. (It just occurred to me it would be better
to add a flag to "metrics list" to only show persist metrics ...)

The changes solve my desire for v.b.soc to be visible in the app after a
reboot. I wanted to use it for v.p.direction but minor drifts in the
calculated gps position foil that. I enabled it for the tpms metrics but
since my cars don't have working tpms code even when I manually populate
values (e.g. "metrics set v.tp.fl.p 202.29") the app doesn't show them
because (I believe) they are stale.

I expect there are metrics you "big battery" guys will want to add. (And
it won't hurt my feelings if somebody completely rewrites this.)

		Craig

OVMS# metrics persist ?
Usage: metrics persist [-r]
OVMS# metrics persist
version                                  1
serial                                   2
size                                     340
slots used                               13 of 16
v.b.soc                                  82.0
v.b.temp                                 19.0
v.m.temp                                 0.0
v.e.temp                                 20.0
v.p.odometer                             0.0
v.tp.fl.t                                0.0
v.tp.fr.t                                0.0
v.tp.rr.t                                0.0
v.tp.rl.t                                0.0
v.tp.fl.p                                0.0
v.tp.fr.p                                0.0
v.tp.rr.p                                0.0
v.tp.rl.p                                0.0


From kommykt at gmail.com  Sun Jun  7 13:50:44 2020
From: kommykt at gmail.com (=?UTF-8?B?VGFtw6FzIEtvdsOhY3M=?=)
Date: Sun, 7 Jun 2020 07:50:44 +0200
Subject: [Ovmsdev] Random crash if enable notifications
In-Reply-To: <9e727cb7-1042-202d-c80a-b44b1e1d2f67@expeedo.de>
References: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>
 <3ce6a6e3-8119-f123-296c-653ba3e258b4@expeedo.de>
 <CAGpaXUt0C_rv992y+bg7-wmD8wBZ_8g+hFoVndo7YL-xG8L3+A@mail.gmail.com>
 <9e727cb7-1042-202d-c80a-b44b1e1d2f67@expeedo.de>
Message-ID: <CAGpaXUthOkR9BURwJaK1PmHMgDkL4pmXH9OThJSm8e2LTpy_QA@mail.gmail.com>

I downloaded this toolchain and use it: build idf v3.3-beta3-776-g3d198cd50
I checkout esp-idf to spiram-fix-test branch.

I use a forked repo.
I run the following to update to spiram-fix-test, on my local repo.
git fetch upstream
git pull upstream/spiram-fix-test master

But i now get crash the last is:
Last crash: abort() was called on core 1 Backtrace: 0x4008ace7 0x4008af7d
0x4010badf 0x40097d93 0x40083ffd 0x400845f1 0x4000bec7 0x4012c729
0x402a1815 0x401eb40d 0x401f7a26 0x401f8af0 0x40207065 0x40206f45
0x40207133 0x40206faf 0x402073b6 0x4020747d 0x401f4445 0x401f3344
0x401f3677 0x401f441e 0x402079d1 0x401f76e5 0x401f7892 0x40202ea6
0x4012db9a 0x4012dd9d

kommykt at MacBook-Air OVMS.V3 % a2l 0x4008ace7 0x4008af7d 0x4010badf
0x40097d93 0x40083ffd 0x400845f1 0x4000bec7 0x4012c729 0x402a1815
0x401eb40d 0x401f7a26 0x401f8af0 0x40207065 0x40206f45 0x40207133
0x40206faf 0x402073b6 0x4020747d 0x401f4445 0x401f3344 0x401f3677
0x401f441e 0x402079d1 0x401f76e5 0x401f7892 0x40202ea6 0x4012db9a 0x4012dd9d

Using elf file:
/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf

0x4008ace7 is in invoke_abort
(/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).

151 #endif

152     while (1) {

153         if (esp_cpu_in_ocd_debug_mode()) {

154             __asm__ ("break 0,0");

155         }

156         *((int *) 0) = 0;

157     }

158 }

159

160 void abort()

0x4008af7d is in abort
(/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).

166     * don't overwrite that.

167     */

168     if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {

169         esp_reset_reason_set_hint(ESP_RST_PANIC);

170     }

171     invoke_abort();

172 }

173

174

175 static const char *edesc[] = {

0x4010badf is in __assert_func
(../../../.././newlib/libc/stdlib/assert.c:63).

0x40097d93 is in multi_heap_free
(/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).

209         return;

210     }

211     multi_heap_internal_lock(heap);

212

213     poison_head_t *head = verify_allocated_region(p, true);

214     assert(head != NULL);

215

216     #ifdef SLOW

217     /* replace everything with FREE_FILL_PATTERN, including the poison
head/tail */

218     memset(head, FREE_FILL_PATTERN,

0x40083ffd is in heap_caps_free
(/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).

263         ptr = (void *)dramAddrPtr[-1];

264     }

265

266     heap_t *heap = find_containing_heap(ptr);

267     assert(heap != NULL && "free() target pointer is outside heap
areas");

268     multi_heap_free(heap->heap, ptr);

269 }

270

271 IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)

272 {

0x400845f1 is in _free_r
(/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).

37     return heap_caps_malloc_default( size );

38 }

39

40 void IRAM_ATTR _free_r(struct _reent *r, void* ptr)

41 {

42     heap_caps_free( ptr );

43 }

44

45 void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)

46 {

0x4012c729 is in DukOvmsFree(void*, void*)
(/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:442).

437   return ExternalRamRealloc(ptr, size);

438   }

439

440 void DukOvmsFree(void *udata, void *ptr)

441   {

442   free(ptr);

443   }

444

445 void DukOvmsFatalHandler(void *udata, const char *msg)

446   {

0x402a1815 is in duk_heap_mem_free (duk_heap_memory.c:406).

0x401eb40d is in duk__refcount_refzero_hstring (duk_heap_alloc.c:103).

0x401f7a26 is in duk_heaphdr_refzero (duk_heap_refcount.c:630).

0x401f8af0 is in duk_pop_2 (duk_api_stack.c:6089).

0x40207065 is in duk__enc_value (duk_bi_json.c:2240).

0x40206f45 is in duk__enc_value (duk_bi_json.c:1951).

1946 in duk_bi_json.c

0x40207133 is in duk__enc_object (duk_bi_json.c:1885).

1880 in duk_bi_json.c

0x40206faf is in duk__enc_value (duk_bi_json.c:2203).

2198 in duk_bi_json.c

0x402073b6 is in duk_bi_json_stringify_helper (duk_bi_json.c:3191).

3186 in duk_bi_json.c

0x4020747d is in duk_bi_duktape_object_enc (duk_bi_duktape.c:96).

0x401f4445 is in duk__handle_call_raw (duk_js_call.c:2276).

0x401f3344 is in duk__js_execute_bytecode_inner (duk_js_call.c:2422).

2417 in duk_js_call.c

0x401f3677 is in duk_js_execute_bytecode (duk_js_executor.c:2956).

0x401f441e is in duk__handle_call_raw (duk_js_call.c:2246).

0x402079d1 is in duk__pcall_method_raw (duk_js_call.c:2422).

2417 in duk_js_call.c

0x401f76e5 is in duk_handle_safe_call (duk_js_call.c:2475).

2470 in duk_js_call.c

0x401f7892 is in duk_safe_call (duk_api_call.c:318).

0x40202ea6 is in duk_pcall_method (duk_api_call.c:242).

237 in duk_api_call.c

0x4012db9a is in OvmsScripts::DukTapeTask()
(/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:2273).

2268             duk_get_global_string(m_dukctx, "PubSub");

2269             duk_get_prop_string(m_dukctx, -1, "publish");

2270             duk_dup(m_dukctx, -2);  /* this binding = process */

2271             duk_push_string(m_dukctx, msg.body.dt_event.name);

2272             duk_push_string(m_dukctx, "");

2273             if (duk_pcall_method(m_dukctx, 2) != 0)

2274               {

2275               DukOvmsErrorHandler(m_dukctx, -1);

2276               }

2277             duk_pop_2(m_dukctx);

0x4012dd9d is in DukTapeLaunchTask(void*)
(/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:427).

422

423 void DukTapeLaunchTask(void *pvParameters)

424   {

425   OvmsScripts* me = (OvmsScripts*)pvParameters;

426

427   me->DukTapeTask();

428   }

429

430 void* DukOvmsAlloc(void *udata, duk_size_t size)

431   {


Michael Balzer <dexter at expeedo.de> ezt ?rta (id?pont: 2020. j?n. 5., P,
21:43):

> See previous posts on this, you also need the fixed toolchain:
> https://github.com/espressif/esp-idf/issues/2892#issuecomment-501106283
>
> Regards,
> Michael
>
>
> Am 05.06.20 um 20:04 schrieb Tam?s Kov?cs:
>
> i think i don't run spiram fix. How can i use it. I must check out branch
> "spiram-fix-test"  to run spiram fix?
>
> Michael Balzer <dexter at expeedo.de> ezt ?rta (id?pont: 2020. j?n. 5., P,
> 6:58):
>
>> Tam?s,
>>
>> that doesn't need to be related to the pushover code. Do you run the
>> spiram fix? I had this kind of heap corruption crashes frequently on builds
>> without the spiram fix but not once with the fix.
>>
>> Regards,
>> Michael
>>
>>
>> Am 05.06.20 um 05:29 schrieb Tam?s Kov?cs:
>>
>> Some day's ago i enabled Pushover notifications and i get some crash
>> after that.
>>
>> The crash backtrase is:
>> Backtrace: 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361
>> 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4
>> 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545
>> 0x400f375e 0x400f37d5 0x400f37e5
>> a2l output is:
>>
>> kommykt at MacBook-Air OVMS.V3 % a2l 0x4008b75f 0x4008b9f9 0x4010b253
>> 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1
>> 0x400f0dbb 0x400f0db4 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109
>> 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>>
>> Using elf file:
>> /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>>
>>
>> 0x4008b75f is in invoke_abort
>> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>>
>> 151 #endif
>>
>> 152     while (1) {
>>
>> 153         if (esp_cpu_in_ocd_debug_mode()) {
>>
>> 154             __asm__ ("break 0,0");
>>
>> 155         }
>>
>> 156         *((int *) 0) = 0;
>>
>> 157     }
>>
>> 158 }
>>
>> 159
>>
>> 160 void abort()
>>
>>
>> 0x4008b9f9 is in abort
>> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>>
>> 166     * don't overwrite that.
>>
>> 167     */
>>
>> 168     if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>>
>> 169         esp_reset_reason_set_hint(ESP_RST_PANIC);
>>
>> 170     }
>>
>> 171     invoke_abort();
>>
>> 172 }
>>
>> 173
>>
>> 174
>>
>> 175 static const char *edesc[] = {
>>
>>
>> 0x4010b253 is in __assert_func
>> (../../../.././newlib/libc/stdlib/assert.c:63).
>>
>>
>> 0x40098c5f is in multi_heap_free
>> (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>>
>> 209         return;
>>
>> 210     }
>>
>> 211     multi_heap_internal_lock(heap);
>>
>> 212
>>
>> 213     poison_head_t *head = verify_allocated_region(p, true);
>>
>> 214     assert(head != NULL);
>>
>> 215
>>
>> 216     #ifdef SLOW
>>
>> 217     /* replace everything with FREE_FILL_PATTERN, including the
>> poison head/tail */
>>
>> 218     memset(head, FREE_FILL_PATTERN,
>>
>>
>> 0x40084361 is in heap_caps_free
>> (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>>
>> 263         ptr = (void *)dramAddrPtr[-1];
>>
>> 264     }
>>
>> 265
>>
>> 266     heap_t *heap = find_containing_heap(ptr);
>>
>> 267     assert(heap != NULL && "free() target pointer is outside heap
>> areas");
>>
>> 268     multi_heap_free(heap->heap, ptr);
>>
>> 269 }
>>
>> 270
>>
>> 271 IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>>
>> 272 {
>>
>>
>> 0x40084945 is in _free_r
>> (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>>
>> 37     return heap_caps_malloc_default( size );
>>
>> 38 }
>>
>> 39
>>
>> 40 void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>>
>> 41 {
>>
>> 42     heap_caps_free( ptr );
>>
>> 43 }
>>
>> 44
>>
>> 45 void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>>
>> 46 {
>>
>>
>> 0x401c1181 is in operator delete(void*)
>> (/Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/del_op.cc:46).
>>
>>
>> 0x400f01e1 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >
>> >::_M_drop_node(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >*)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110).
>>
>> 105       }
>>
>> 106
>>
>> 107       // __p is not permitted to be a null pointer.
>>
>> 108       void
>>
>> 109       deallocate(pointer __p, size_type)
>>
>> 110       { ::operator delete(__p); }
>>
>> 111
>>
>> 112       size_type
>>
>> 113       max_size() const _GLIBCXX_USE_NOEXCEPT
>>
>> 114       { return size_t(-1) / sizeof(_Tp); }
>>
>>
>> 0x400f0dbb is in std::_Rb_tree<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >
>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >*)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1614).
>>
>> 1609       // Erase without rebalancing.
>>
>> 1610       while (__x != 0)
>>
>> 1611 {
>>
>> 1612   _M_erase(_S_right(__x));
>>
>> 1613   _Link_type __y = _S_left(__x);
>>
>> 1614   _M_drop_node(__x);
>>
>> 1615   __x = __y;
>>
>> 1616 }
>>
>> 1617     }
>>
>> 1618
>>
>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >
>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >*)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>> 1607     _M_erase(_Link_type __x)
>>
>> 1608     {
>>
>> 1609       // Erase without rebalancing.
>>
>> 1610       while (__x != 0)
>>
>> 1611 {
>>
>> 1612   _M_erase(_S_right(__x));
>>
>> 1613   _Link_type __y = _S_left(__x);
>>
>> 1614   _M_drop_node(__x);
>>
>> 1615   __x = __y;
>>
>> 1616 }
>>
>>
>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >
>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >*)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>> 1607     _M_erase(_Link_type __x)
>>
>> 1608     {
>>
>> 1609       // Erase without rebalancing.
>>
>> 1610       while (__x != 0)
>>
>> 1611 {
>>
>> 1612   _M_erase(_S_right(__x));
>>
>> 1613   _Link_type __y = _S_left(__x);
>>
>> 1614   _M_drop_node(__x);
>>
>> 1615   __x = __y;
>>
>> 1616 }
>>
>>
>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >
>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >*)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>> 1607     _M_erase(_Link_type __x)
>>
>> 1608     {
>>
>> 1609       // Erase without rebalancing.
>>
>> 1610       while (__x != 0)
>>
>> 1611 {
>>
>> 1612   _M_erase(_S_right(__x));
>>
>> 1613   _Link_type __y = _S_left(__x);
>>
>> 1614   _M_drop_node(__x);
>>
>> 1615   __x = __y;
>>
>> 1616 }
>>
>>
>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >
>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > >*)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>
>> 1607     _M_erase(_Link_type __x)
>>
>> 1608     {
>>
>> 1609       // Erase without rebalancing.
>>
>> 1610       while (__x != 0)
>>
>> 1611 {
>>
>> 1612   _M_erase(_S_right(__x));
>>
>> 1613   _Link_type __y = _S_left(__x);
>>
>> 1614   _M_drop_node(__x);
>>
>> 1615   __x = __y;
>>
>> 1616 }
>>
>>
>> 0x40156109 is in Pushover::EventListener(std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >, void*)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:858).
>>
>> 853
>>
>> 854       _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a);
>>
>> 855 #endif
>>
>> 856
>>
>> 857       ~_Rb_tree() _GLIBCXX_NOEXCEPT
>>
>> 858       { _M_erase(_M_begin()); }
>>
>> 859
>>
>> 860       _Rb_tree&
>>
>> 861       operator=(const _Rb_tree& __x);
>>
>> 862
>>
>> 0x401550da is in std::_Function_handler<void
>> (std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >, void*), std::_Bind<std::_Mem_fn<void
>> (Pushover::*)(std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >, void*)> (Pushover*, std::_Placeholder<1>,
>> std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >&&, void*&&)
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600).
>>
>> 595       template<typename... _Args, typename _Req
>>
>> 596               = _Require<typename _Traits::__lvalue,
>>
>> 597                           _CheckArgs<_Pack<_Args...>>>>
>>
>> 598 result_type
>>
>> 599 operator()(_Class* __object, _Args&&... __args) const
>>
>> 600 { return (__object->*_M_pmf)(std::forward<_Args>(__args)...); }
>>
>> 601
>>
>> 602       // Handle smart pointers, references and pointers to derived
>>
>> 603       template<typename _Tp, typename... _Args, typename _Req
>>
>> 604               = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*,
>> _Tp>,
>>
>>
>> 0x400f3545 is in std::function<void (std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> void*)>::operator()(std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >, void*) const
>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271).
>>
>> 2266     function<_Res(_ArgTypes...)>::
>>
>> 2267     operator()(_ArgTypes... __args) const
>>
>> 2268     {
>>
>> 2269       if (_M_empty())
>>
>> 2270 __throw_bad_function_call();
>>
>> 2271       return _M_invoker(_M_functor,
>> std::forward<_ArgTypes>(__args)...);
>>
>> 2272     }
>>
>> 2273
>>
>> 2274 #if __cpp_rtti
>>
>> 2275   template<typename _Res, typename... _ArgTypes>
>>
>>
>> 0x400f375e is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*)
>> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:234).
>>
>> 229       {
>>
>> 230       for (EventCallbackList::iterator itc=el->begin();
>> itc!=el->end(); ++itc)
>>
>> 231         {
>>
>> 232         m_current_started = monotonictime;
>>
>> 233         m_current_callback = *itc;
>>
>> 234         m_current_callback->m_callback(m_current_event,
>> msg->body.signal.data);
>>
>> 235         m_current_callback = NULL;
>>
>> 236         }
>>
>> 237       }
>>
>> 238     }
>>
>>
>> 0x400f37d5 is in OvmsEvents::EventTask()
>> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:185).
>>
>> 180       switch(msg.type)
>>
>> 181         {
>>
>> 182         case EVENT_none:
>>
>> 183           break;
>>
>> 184         case EVENT_signal:
>>
>> 185           HandleQueueSignalEvent(&msg);
>>
>> 186           break;
>>
>> 187         default:
>>
>> 188           break;
>>
>> 189         }
>>
>>
>> 0x400f37e5 is in EventLaunchTask(void*)
>> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:56).
>>
>> 51
>>
>> 52 void EventLaunchTask(void *pvParameters)
>>
>> 53   {
>>
>> 54   OvmsEvents* me = (OvmsEvents*)pvParameters;
>>
>> 55
>>
>> 56   me->EventTask();
>>
>> 57   }
>>
>> 58
>>
>> 59 void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand* cmd,
>> int argc, const char* const* argv)
>>
>> 60   {
>>
>> --
>> ?dv?zlettel:
>> Kov?cs Tam?s
>>
>>
>> _______________________________________________
>> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>> --
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>
>
> --
> ?dv?zlettel:
> Kov?cs Tam?s
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>


-- 
?dv?zlettel:
Kov?cs Tam?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200607/7bba7e3a/attachment.htm>

From casner at acm.org  Tue Jun  9 01:02:53 2020
From: casner at acm.org (Stephen Casner)
Date: Mon, 8 Jun 2020 10:02:53 -0700 (PDT)
Subject: [Ovmsdev] Strange app behavior
Message-ID: <alpine.OSX.2.21.9999.2006080951320.15345@auge.attlocal.net>

I'm running 3.2.012.  This morning when I went to check the status
after charging overnight, which had completed, the iPhone app was
behaving in a very strange manner.  I cycled a few times (for as long
as I watched) through three states at an interval on the order of
10-20 seconds:

1. 86%, ideal range 191, no charge connector icon.  Those range and
SOC numbers were correct, but the charge cable was connected.

2. 95%, ideal range 177, charge connector icon shown.

3. 48%, don't recall the range, no charge connector icon.

When I checked the Car screen, it too was cycling among showing no
numbers, showing old gray numbers, and showing some numbers in white.
I don't recall their accuracy.

Now after I finished my morning walk the display appears stable and
correct with 86%, ideal range 190, and charge connector icon shown.
The Car screen shows just old numbers in gray except for the aux
battery voltage.  Sorry I didn't have the presence of mind to grab
screenshots.

                                                        -- Steve


From dexter at expeedo.de  Tue Jun  9 02:33:13 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Mon, 8 Jun 2020 20:33:13 +0200
Subject: [Ovmsdev] Strange app behavior
In-Reply-To: <alpine.OSX.2.21.9999.2006080951320.15345@auge.attlocal.net>
References: <alpine.OSX.2.21.9999.2006080951320.15345@auge.attlocal.net>
Message-ID: <7dec280e-35b7-7a02-32e9-2d1d32502fd8@expeedo.de>

That may have been https://github.com/openvehicles/Open-Vehicle-Server/issues/2

Regards,
Michael


Am 08.06.20 um 19:02 schrieb Stephen Casner:
> I'm running 3.2.012.  This morning when I went to check the status
> after charging overnight, which had completed, the iPhone app was
> behaving in a very strange manner.  I cycled a few times (for as long
> as I watched) through three states at an interval on the order of
> 10-20 seconds:
>
> 1. 86%, ideal range 191, no charge connector icon.  Those range and
> SOC numbers were correct, but the charge cable was connected.
>
> 2. 95%, ideal range 177, charge connector icon shown.
>
> 3. 48%, don't recall the range, no charge connector icon.
>
> When I checked the Car screen, it too was cycling among showing no
> numbers, showing old gray numbers, and showing some numbers in white.
> I don't recall their accuracy.
>
> Now after I finished my morning walk the display appears stable and
> correct with 86%, ideal range 190, and charge connector icon shown.
> The Car screen shows just old numbers in gray except for the aux
> battery voltage.  Sorry I didn't have the presence of mind to grab
> screenshots.
>
>                                                         -- Steve
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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



From dexter at expeedo.de  Tue Jun  9 02:39:00 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Mon, 8 Jun 2020 20:39:00 +0200
Subject: [Ovmsdev] Random crash if enable notifications
In-Reply-To: <CAGpaXUthOkR9BURwJaK1PmHMgDkL4pmXH9OThJSm8e2LTpy_QA@mail.gmail.com>
References: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>
 <3ce6a6e3-8119-f123-296c-653ba3e258b4@expeedo.de>
 <CAGpaXUt0C_rv992y+bg7-wmD8wBZ_8g+hFoVndo7YL-xG8L3+A@mail.gmail.com>
 <9e727cb7-1042-202d-c80a-b44b1e1d2f67@expeedo.de>
 <CAGpaXUthOkR9BURwJaK1PmHMgDkL4pmXH9OThJSm8e2LTpy_QA@mail.gmail.com>
Message-ID: <b3d55512-bf11-8197-25ce-8fb788e8f5bd@expeedo.de>

I cannot tell if you did the correct setup for the spiram fix.

You need
- the new toolchain
- the new libs
- the spiram esp-idf branch
- the spiram ovms branch

If you've got all of this, then the crash isn't related to the SPIRAM bug.

Regards,
Michael


Am 07.06.20 um 07:50 schrieb Tam?s Kov?cs:
> I downloaded this toolchain and use it:?build idf v3.3-beta3-776-g3d198cd50
> I checkout?esp-idf to spiram-fix-test branch.
>
> I use a forked repo.
> I run the following to update to spiram-fix-test, on my local repo.
> git fetch upstream
> git pull upstream/spiram-fix-test master
>
> But i now get crash the last is:?
> Last crash: abort() was called on core 1 Backtrace: 0x4008ace7 0x4008af7d 0x4010badf 0x40097d93 0x40083ffd 0x400845f1 0x4000bec7 0x4012c729 0x402a1815
> 0x401eb40d 0x401f7a26 0x401f8af0 0x40207065 0x40206f45 0x40207133 0x40206faf 0x402073b6 0x4020747d 0x401f4445 0x401f3344 0x401f3677 0x401f441e 0x402079d1
> 0x401f76e5 0x401f7892 0x40202ea6 0x4012db9a 0x4012dd9d
>
> kommykt at MacBook-Air OVMS.V3 % a2l 0x4008ace7 0x4008af7d 0x4010badf 0x40097d93 0x40083ffd 0x400845f1 0x4000bec7 0x4012c729 0x402a1815 0x401eb40d 0x401f7a26
> 0x401f8af0 0x40207065 0x40206f45 0x40207133 0x40206faf 0x402073b6 0x4020747d 0x401f4445 0x401f3344 0x401f3677 0x401f441e 0x402079d1 0x401f76e5 0x401f7892
> 0x40202ea6 0x4012db9a 0x4012dd9d
>
> Using elf file: /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>
> 0x4008ace7 is in invoke_abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>
> 151#endif
>
> 152? ? while (1) {
>
> 153? ? ? ? if (esp_cpu_in_ocd_debug_mode()) {
>
> 154? ? ? ? ? ? __asm__ ("break 0,0");
>
> 155? ? ? ? }
>
> 156? ? ? ? *((int *) 0) = 0;
>
> 157? ? }
>
> 158}
>
> 159
>
> 160void abort()
>
> 0x4008af7d is in abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>
> 166? ? * don't overwrite that.
>
> 167? ? */
>
> 168? ? if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>
> 169? ? ? ? esp_reset_reason_set_hint(ESP_RST_PANIC);
>
> 170? ? }
>
> 171? ? invoke_abort();
>
> 172}
>
> 173
>
> 174
>
> 175static const char *edesc[] = {
>
> 0x4010badf is in __assert_func (../../../.././newlib/libc/stdlib/assert.c:63).
>
> 0x40097d93 is in multi_heap_free (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>
> 209? ? ? ? return;
>
> 210? ? }
>
> 211? ? multi_heap_internal_lock(heap);
>
> 212
>
> 213? ? poison_head_t *head = verify_allocated_region(p, true);
>
> 214? ? assert(head != NULL);
>
> 215
>
> 216? ? #ifdef SLOW
>
> 217? ? /* replace everything with FREE_FILL_PATTERN, including the poison head/tail */
>
> 218? ? memset(head, FREE_FILL_PATTERN,
>
> 0x40083ffd is in heap_caps_free (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>
> 263? ? ? ? ptr = (void *)dramAddrPtr[-1];
>
> 264? ? }
>
> 265
>
> 266? ? heap_t *heap = find_containing_heap(ptr);
>
> 267? ? assert(heap != NULL && "free() target pointer is outside heap areas");
>
> 268? ? multi_heap_free(heap->heap, ptr);
>
> 269}
>
> 270
>
> 271IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>
> 272{
>
> 0x400845f1 is in _free_r (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>
> 37? ? return heap_caps_malloc_default( size );
>
> 38}
>
> 39
>
> 40void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>
> 41{
>
> 42? ? heap_caps_free( ptr );
>
> 43}
>
> 44
>
> 45void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>
> 46{
>
> 0x4012c729 is in DukOvmsFree(void*, void*) (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:442).
>
> 437? return ExternalRamRealloc(ptr, size);
>
> 438? }
>
> 439
>
> 440void DukOvmsFree(void *udata, void *ptr)
>
> 441? {
>
> 442? free(ptr);
>
> 443? }
>
> 444
>
> 445void DukOvmsFatalHandler(void *udata, const char *msg)
>
> 446? {
>
> 0x402a1815 is in duk_heap_mem_free (duk_heap_memory.c:406).
>
> 0x401eb40d is in duk__refcount_refzero_hstring (duk_heap_alloc.c:103).
>
> 0x401f7a26 is in duk_heaphdr_refzero (duk_heap_refcount.c:630).
>
> 0x401f8af0 is in duk_pop_2 (duk_api_stack.c:6089).
>
> 0x40207065 is in duk__enc_value (duk_bi_json.c:2240).
>
> 0x40206f45 is in duk__enc_value (duk_bi_json.c:1951).
>
> 1946in duk_bi_json.c
>
> 0x40207133 is in duk__enc_object (duk_bi_json.c:1885).
>
> 1880in duk_bi_json.c
>
> 0x40206faf is in duk__enc_value (duk_bi_json.c:2203).
>
> 2198in duk_bi_json.c
>
> 0x402073b6 is in duk_bi_json_stringify_helper (duk_bi_json.c:3191).
>
> 3186in duk_bi_json.c
>
> 0x4020747d is in duk_bi_duktape_object_enc (duk_bi_duktape.c:96).
>
> 0x401f4445 is in duk__handle_call_raw (duk_js_call.c:2276).
>
> 0x401f3344 is in duk__js_execute_bytecode_inner (duk_js_call.c:2422).
>
> 2417in duk_js_call.c
>
> 0x401f3677 is in duk_js_execute_bytecode (duk_js_executor.c:2956).
>
> 0x401f441e is in duk__handle_call_raw (duk_js_call.c:2246).
>
> 0x402079d1 is in duk__pcall_method_raw (duk_js_call.c:2422).
>
> 2417in duk_js_call.c
>
> 0x401f76e5 is in duk_handle_safe_call (duk_js_call.c:2475).
>
> 2470in duk_js_call.c
>
> 0x401f7892 is in duk_safe_call (duk_api_call.c:318).
>
> 0x40202ea6 is in duk_pcall_method (duk_api_call.c:242).
>
> 237in duk_api_call.c
>
> 0x4012db9a is in OvmsScripts::DukTapeTask() (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:2273).
>
> 2268? ? ? ? ? ? duk_get_global_string(m_dukctx, "PubSub");
>
> 2269? ? ? ? ? ? duk_get_prop_string(m_dukctx, -1, "publish");
>
> 2270? ? ? ? ? ? duk_dup(m_dukctx, -2);? /* this binding = process */
>
> 2271? ? ? ? ? ? duk_push_string(m_dukctx, msg.body.dt_event.name <http://msg.body.dt_event.name>);
>
> 2272? ? ? ? ? ? duk_push_string(m_dukctx, "");
>
> 2273? ? ? ? ? ? if (duk_pcall_method(m_dukctx, 2) != 0)
>
> 2274? ? ? ? ? ? ? {
>
> 2275? ? ? ? ? ? ? DukOvmsErrorHandler(m_dukctx, -1);
>
> 2276? ? ? ? ? ? ? }
>
> 2277? ? ? ? ? ? duk_pop_2(m_dukctx);
>
> 0x4012dd9d is in DukTapeLaunchTask(void*) (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:427).
>
> 422
>
> 423void DukTapeLaunchTask(void *pvParameters)
>
> 424? {
>
> 425? OvmsScripts* me = (OvmsScripts*)pvParameters;
>
> 426
>
> 427? me->DukTapeTask();
>
> 428? }
>
> 429
>
> 430void* DukOvmsAlloc(void *udata, duk_size_t size)
>
> 431? {
>
>
>
> Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> ezt ?rta (id?pont: 2020. j?n. 5., P, 21:43):
>
>     See previous posts on this, you also need the fixed toolchain: https://github.com/espressif/esp-idf/issues/2892#issuecomment-501106283
>
>     Regards,
>     Michael
>
>
>     Am 05.06.20 um 20:04 schrieb Tam?s Kov?cs:
>>     i think i don't run spiram fix. How can i use it.?I must?check out branch "spiram-fix-test" ?to run spiram fix?
>>
>>     Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> ezt ?rta (id?pont: 2020. j?n. 5., P, 6:58):
>>
>>         Tam?s,
>>
>>         that doesn't need to be related to the pushover code. Do you run the spiram fix? I had this kind of heap corruption crashes frequently on builds
>>         without the spiram fix but not once with the fix.
>>
>>         Regards,
>>         Michael
>>
>>
>>         Am 05.06.20 um 05:29 schrieb Tam?s Kov?cs:
>>>         Some day's ago i enabled Pushover notifications and i get some crash after that.
>>>
>>>         The crash backtrase?is:?
>>>         Backtrace: 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4 0x400f0db4
>>>         0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>>>         a2l output is:
>>>
>>>         kommykt at MacBook-Air OVMS.V3 % a2l 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb
>>>         0x400f0db4 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>>>
>>>         Using elf file: /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>>>
>>>
>>>         0x4008b75f is in invoke_abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>>>
>>>         151#endif
>>>
>>>         152? ? while (1) {
>>>
>>>         153? ? ? ? if (esp_cpu_in_ocd_debug_mode()) {
>>>
>>>         154? ? ? ? ? ? __asm__ ("break 0,0");
>>>
>>>         155? ? ? ? }
>>>
>>>         156? ? ? ? *((int *) 0) = 0;
>>>
>>>         157? ? }
>>>
>>>         158}
>>>
>>>         159
>>>
>>>         160void abort()
>>>
>>>
>>>         0x4008b9f9 is in abort (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>>>
>>>         166? ? * don't overwrite that.
>>>
>>>         167? ? */
>>>
>>>         168? ? if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>>>
>>>         169? ? ? ? esp_reset_reason_set_hint(ESP_RST_PANIC);
>>>
>>>         170? ? }
>>>
>>>         171? ? invoke_abort();
>>>
>>>         172}
>>>
>>>         173
>>>
>>>         174
>>>
>>>         175static const char *edesc[] = {
>>>
>>>
>>>         0x4010b253 is in __assert_func (../../../.././newlib/libc/stdlib/assert.c:63).
>>>
>>>
>>>         0x40098c5f is in multi_heap_free (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>>>
>>>         209? ? ? ? return;
>>>
>>>         210? ? }
>>>
>>>         211? ? multi_heap_internal_lock(heap);
>>>
>>>         212
>>>
>>>         213? ? poison_head_t *head = verify_allocated_region(p, true);
>>>
>>>         214? ? assert(head != NULL);
>>>
>>>         215
>>>
>>>         216? ? #ifdef SLOW
>>>
>>>         217? ? /* replace everything with FREE_FILL_PATTERN, including the poison head/tail */
>>>
>>>         218? ? memset(head, FREE_FILL_PATTERN,
>>>
>>>
>>>         0x40084361 is in heap_caps_free (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>>>
>>>         263? ? ? ? ptr = (void *)dramAddrPtr[-1];
>>>
>>>         264? ? }
>>>
>>>         265
>>>
>>>         266? ? heap_t *heap = find_containing_heap(ptr);
>>>
>>>         267? ? assert(heap != NULL && "free() target pointer is outside heap areas");
>>>
>>>         268? ? multi_heap_free(heap->heap, ptr);
>>>
>>>         269}
>>>
>>>         270
>>>
>>>         271IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>>>
>>>         272{
>>>
>>>
>>>         0x40084945 is in _free_r (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>>>
>>>         37? ? return heap_caps_malloc_default( size );
>>>
>>>         38}
>>>
>>>         39
>>>
>>>         40void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>>>
>>>         41{
>>>
>>>         42? ? heap_caps_free( ptr );
>>>
>>>         43}
>>>
>>>         44
>>>
>>>         45void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>>>
>>>         46{
>>>
>>>
>>>         0x401c1181 is in operator delete(void*) (/Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/del_op.cc:46).
>>>
>>>
>>>         0x400f01e1 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>>         std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >,
>>>         std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
>>>         std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > > > >::_M_drop_node(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110).
>>>
>>>         105? ? ? }
>>>
>>>         106
>>>
>>>         107? ? ? // __p is not permitted to be a null pointer.
>>>
>>>         108? ? ? void
>>>
>>>         109? ? ? deallocate(pointer __p, size_type)
>>>
>>>         110? ? ? { ::operator delete(__p); }
>>>
>>>         111
>>>
>>>         112? ? ? size_type
>>>
>>>         113? ? ? max_size() const _GLIBCXX_USE_NOEXCEPT
>>>
>>>         114? ? ? { return size_t(-1) / sizeof(_Tp); }
>>>
>>>
>>>         0x400f0dbb is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>>         std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >,
>>>         std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
>>>         std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1614).
>>>
>>>         1609? ? ? // Erase without rebalancing.
>>>
>>>         1610? ? ? while (__x != 0)
>>>
>>>         1611{
>>>
>>>         1612? _M_erase(_S_right(__x));
>>>
>>>         1613? _Link_type __y = _S_left(__x);
>>>
>>>         1614? _M_drop_node(__x);
>>>
>>>         1615? __x = __y;
>>>
>>>         1616}
>>>
>>>         1617? ? }
>>>
>>>         1618
>>>
>>>         0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>>         std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >,
>>>         std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
>>>         std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>>         1607? ? _M_erase(_Link_type __x)
>>>
>>>         1608? ? {
>>>
>>>         1609? ? ? // Erase without rebalancing.
>>>
>>>         1610? ? ? while (__x != 0)
>>>
>>>         1611{
>>>
>>>         1612? _M_erase(_S_right(__x));
>>>
>>>         1613? _Link_type __y = _S_left(__x);
>>>
>>>         1614? _M_drop_node(__x);
>>>
>>>         1615? __x = __y;
>>>
>>>         1616}
>>>
>>>
>>>         0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>>         std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >,
>>>         std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
>>>         std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>>         1607? ? _M_erase(_Link_type __x)
>>>
>>>         1608? ? {
>>>
>>>         1609? ? ? // Erase without rebalancing.
>>>
>>>         1610? ? ? while (__x != 0)
>>>
>>>         1611{
>>>
>>>         1612? _M_erase(_S_right(__x));
>>>
>>>         1613? _Link_type __y = _S_left(__x);
>>>
>>>         1614? _M_drop_node(__x);
>>>
>>>         1615? __x = __y;
>>>
>>>         1616}
>>>
>>>
>>>         0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>>         std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >,
>>>         std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
>>>         std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>>         1607? ? _M_erase(_Link_type __x)
>>>
>>>         1608? ? {
>>>
>>>         1609? ? ? // Erase without rebalancing.
>>>
>>>         1610? ? ? while (__x != 0)
>>>
>>>         1611{
>>>
>>>         1612? _M_erase(_S_right(__x));
>>>
>>>         1613? _Link_type __y = _S_left(__x);
>>>
>>>         1614? _M_drop_node(__x);
>>>
>>>         1615? __x = __y;
>>>
>>>         1616}
>>>
>>>
>>>         0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>>         std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >,
>>>         std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
>>>         std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char,
>>>         std::char_traits<char>, std::allocator<char> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>>         1607? ? _M_erase(_Link_type __x)
>>>
>>>         1608? ? {
>>>
>>>         1609? ? ? // Erase without rebalancing.
>>>
>>>         1610? ? ? while (__x != 0)
>>>
>>>         1611{
>>>
>>>         1612? _M_erase(_S_right(__x));
>>>
>>>         1613? _Link_type __y = _S_left(__x);
>>>
>>>         1614? _M_drop_node(__x);
>>>
>>>         1615? __x = __y;
>>>
>>>         1616}
>>>
>>>
>>>         0x40156109 is in Pushover::EventListener(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:858).
>>>
>>>         853
>>>
>>>         854? ? ? _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a);
>>>
>>>         855#endif
>>>
>>>         856
>>>
>>>         857? ? ? ~_Rb_tree() _GLIBCXX_NOEXCEPT
>>>
>>>         858? ? ? { _M_erase(_M_begin()); }
>>>
>>>         859
>>>
>>>         860? ? ? _Rb_tree&
>>>
>>>         861? ? ? operator=(const _Rb_tree& __x);
>>>
>>>         862
>>>
>>>         0x401550da is in std::_Function_handler<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*),
>>>         std::_Bind<std::_Mem_fn<void (Pushover::*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)> (Pushover*,
>>>         std::_Placeholder<1>, std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&, std::__cxx11::basic_string<char, std::char_traits<char>,
>>>         std::allocator<char> >&&, void*&&) (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600).
>>>
>>>         595? ? ? template<typename... _Args, typename _Req
>>>
>>>         596? ? ? ? ? ? ? = _Require<typename _Traits::__lvalue,
>>>
>>>         597? ? ? ? ? ? ? ? ? ? ? ? ? _CheckArgs<_Pack<_Args...>>>>
>>>
>>>         598result_type
>>>
>>>         599operator()(_Class* __object, _Args&&... __args) const
>>>
>>>         600{ return (__object->*_M_pmf)(std::forward<_Args>(__args)...); }
>>>
>>>         601
>>>
>>>         602? ? ? // Handle smart pointers, references and pointers to derived
>>>
>>>         603? ? ? template<typename _Tp, typename... _Args, typename _Req
>>>
>>>         604? ? ? ? ? ? ? = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*, _Tp>,
>>>
>>>
>>>         0x400f3545 is in std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
>>>         void*)>::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) const
>>>         (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271).
>>>
>>>         2266? ? function<_Res(_ArgTypes...)>::
>>>
>>>         2267? ? operator()(_ArgTypes... __args) const
>>>
>>>         2268? ? {
>>>
>>>         2269? ? ? if (_M_empty())
>>>
>>>         2270__throw_bad_function_call();
>>>
>>>         2271? ? ? return _M_invoker(_M_functor, std::forward<_ArgTypes>(__args)...);
>>>
>>>         2272? ? }
>>>
>>>         2273
>>>
>>>         2274#if __cpp_rtti
>>>
>>>         2275? template<typename _Res, typename... _ArgTypes>
>>>
>>>
>>>         0x400f375e is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*)
>>>         (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:234).
>>>
>>>         229? ? ? {
>>>
>>>         230? ? ? for (EventCallbackList::iterator itc=el->begin(); itc!=el->end(); ++itc)
>>>
>>>         231? ? ? ? {
>>>
>>>         232? ? ? ? m_current_started = monotonictime;
>>>
>>>         233? ? ? ? m_current_callback = *itc;
>>>
>>>         234? ? ? ? m_current_callback->m_callback(m_current_event, msg->body.signal.data);
>>>
>>>         235? ? ? ? m_current_callback = NULL;
>>>
>>>         236? ? ? ? }
>>>
>>>         237? ? ? }
>>>
>>>         238? ? }
>>>
>>>
>>>         0x400f37d5 is in OvmsEvents::EventTask() (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:185).
>>>
>>>         180? ? ? switch(msg.type)
>>>
>>>         181? ? ? ? {
>>>
>>>         182? ? ? ? case EVENT_none:
>>>
>>>         183? ? ? ? ? break;
>>>
>>>         184? ? ? ? case EVENT_signal:
>>>
>>>         185? ? ? ? ? HandleQueueSignalEvent(&msg);
>>>
>>>         186? ? ? ? ? break;
>>>
>>>         187? ? ? ? default:
>>>
>>>         188? ? ? ? ? break;
>>>
>>>         189? ? ? ? }
>>>
>>>
>>>         0x400f37e5 is in EventLaunchTask(void*) (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:56).
>>>
>>>         51
>>>
>>>         52void EventLaunchTask(void *pvParameters)
>>>
>>>         53? {
>>>
>>>         54? OvmsEvents* me = (OvmsEvents*)pvParameters;
>>>
>>>         55
>>>
>>>         56? me->EventTask();
>>>
>>>         57? }
>>>
>>>         58
>>>
>>>         59void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv)
>>>
>>>         60? {
>>>
>>>
>>>         -- 
>>>         ?dv?zlettel:
>>>         Kov?cs Tam?s
>>>
>>>
>>>         _______________________________________________
>>>         OvmsDev mailing list
>>>         OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>         http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>         -- 
>>         Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>         Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>>         _______________________________________________
>>         OvmsDev mailing list
>>         OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>         http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>>
>>     -- 
>>     ?dv?zlettel:
>>     Kov?cs Tam?s
>>
>>
>>     _______________________________________________
>>     OvmsDev mailing list
>>     OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>     -- 
>     Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>     Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
>     _______________________________________________
>     OvmsDev mailing list
>     OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> -- 
> ?dv?zlettel:
> Kov?cs Tam?s
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200608/0e49258e/attachment.htm>

From casner at acm.org  Tue Jun  9 13:39:37 2020
From: casner at acm.org (Stephen Casner)
Date: Mon, 8 Jun 2020 22:39:37 -0700 (PDT)
Subject: [Ovmsdev] Strange app behavior
In-Reply-To: <7dec280e-35b7-7a02-32e9-2d1d32502fd8@expeedo.de>
References: <alpine.OSX.2.21.9999.2006080951320.15345@auge.attlocal.net>
 <7dec280e-35b7-7a02-32e9-2d1d32502fd8@expeedo.de>
Message-ID: <alpine.OSX.2.21.9999.2006082236160.15345@auge.attlocal.net>

That sounds plausible.  Since the problem ceased, I wonder if that
implies that the server was restarted.  I'm using Mark's server.

                                                        -- Steve

On Mon, 8 Jun 2020, Michael Balzer wrote:

> That may have been https://github.com/openvehicles/Open-Vehicle-Server/issues/2
>
> Regards,
> Michael
>
>
> Am 08.06.20 um 19:02 schrieb Stephen Casner:
> > I'm running 3.2.012.  This morning when I went to check the status
> > after charging overnight, which had completed, the iPhone app was
> > behaving in a very strange manner.  I cycled a few times (for as long
> > as I watched) through three states at an interval on the order of
> > 10-20 seconds:
> >
> > 1. 86%, ideal range 191, no charge connector icon.  Those range and
> > SOC numbers were correct, but the charge cable was connected.
> >
> > 2. 95%, ideal range 177, charge connector icon shown.
> >
> > 3. 48%, don't recall the range, no charge connector icon.
> >
> > When I checked the Car screen, it too was cycling among showing no
> > numbers, showing old gray numbers, and showing some numbers in white.
> > I don't recall their accuracy.
> >
> > Now after I finished my morning walk the display appears stable and
> > correct with 86%, ideal range 190, and charge connector icon shown.
> > The Car screen shows just old numbers in gray except for the aux
> > battery voltage.  Sorry I didn't have the presence of mind to grab
> > screenshots.
> >
> >                                                         -- Steve
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>


From mark at webb-johnson.net  Tue Jun  9 13:48:57 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Tue, 9 Jun 2020 13:48:57 +0800
Subject: [Ovmsdev] Strange app behavior
In-Reply-To: <alpine.OSX.2.21.9999.2006082236160.15345@auge.attlocal.net>
References: <alpine.OSX.2.21.9999.2006080951320.15345@auge.attlocal.net>
 <7dec280e-35b7-7a02-32e9-2d1d32502fd8@expeedo.de>
 <alpine.OSX.2.21.9999.2006082236160.15345@auge.attlocal.net>
Message-ID: <AB995B00-EA4C-4C58-8685-93181C7EF36B@webb-johnson.net>

Steve,

I wasn?t aware of this issue, but will look into it. I can?t immediately see the cause, but it should be relatively easy to add a clean-up of the channel structures when the connection starts.

I haven?t restarted the api.openvehicles.com <http://api.openvehicles.com/> server recently.

Regards, Mark.

> On 9 Jun 2020, at 1:39 PM, Stephen Casner <casner at acm.org> wrote:
> 
> That sounds plausible.  Since the problem ceased, I wonder if that
> implies that the server was restarted.  I'm using Mark's server.
> 
>                                                        -- Steve
> 
> On Mon, 8 Jun 2020, Michael Balzer wrote:
> 
>> That may have been https://github.com/openvehicles/Open-Vehicle-Server/issues/2
>> 
>> Regards,
>> Michael
>> 
>> 
>> Am 08.06.20 um 19:02 schrieb Stephen Casner:
>>> I'm running 3.2.012.  This morning when I went to check the status
>>> after charging overnight, which had completed, the iPhone app was
>>> behaving in a very strange manner.  I cycled a few times (for as long
>>> as I watched) through three states at an interval on the order of
>>> 10-20 seconds:
>>> 
>>> 1. 86%, ideal range 191, no charge connector icon.  Those range and
>>> SOC numbers were correct, but the charge cable was connected.
>>> 
>>> 2. 95%, ideal range 177, charge connector icon shown.
>>> 
>>> 3. 48%, don't recall the range, no charge connector icon.
>>> 
>>> When I checked the Car screen, it too was cycling among showing no
>>> numbers, showing old gray numbers, and showing some numbers in white.
>>> I don't recall their accuracy.
>>> 
>>> Now after I finished my morning walk the display appears stable and
>>> correct with 86%, ideal range 190, and charge connector icon shown.
>>> The Car screen shows just old numbers in gray except for the aux
>>> battery voltage.  Sorry I didn't have the presence of mind to grab
>>> screenshots.
>>> 
>>>                                                        -- Steve
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> 
>> --
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> 
>> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200609/1ec0ea5b/attachment.htm>

From sebastien.darveau at synnoetic.com  Tue Jun  9 20:24:25 2020
From: sebastien.darveau at synnoetic.com (=?UTF-8?Q?S=C3=A9bastien_Darveau?=)
Date: Tue, 9 Jun 2020 12:24:25 +0000
Subject: [Ovmsdev] Strange app behavior
In-Reply-To: <AB995B00-EA4C-4C58-8685-93181C7EF36B@webb-johnson.net>
References: <alpine.OSX.2.21.9999.2006080951320.15345@auge.attlocal.net> 
 <7dec280e-35b7-7a02-32e9-2d1d32502fd8@expeedo.de> 
 <alpine.OSX.2.21.9999.2006082236160.15345@auge.attlocal.net> 
 <AB995B00-EA4C-4C58-8685-93181C7EF36B@webb-johnson.net> 
 <127C38DA-1DCF-45A3-A4EF-DE8578B9175A@synnoetic.com>
Message-ID: <010001729909f196-e602d92b-92d8-4615-8745-f33bd06408ff-000000@email.amazonses.com>

Hi,

I?ve also seen this strange behavior yesterday afternoon. I?m connected on the same server (api.openvehicles.com <http://api.openvehicles.com> ). The car was going out of range of the Wifi and using the modem at that time. It seems stable now.

Regards,
Sebastien Darveau

On Jun 9, 2020, at 1:48 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net> > wrote:

Steve,

I wasn?t aware of this issue, but will look into it. I can?t immediately see the cause, but it should be relatively easy to add a clean-up of the channel structures when the connection starts.

I haven?t restarted the api.openvehicles.com <http://api.openvehicles.com/> server recently.

Regards, Mark.

On 9 Jun 2020, at 1:39 PM, Stephen Casner <casner at acm.org <mailto:casner at acm.org> > wrote:

That sounds plausible. ?Since the problem ceased, I wonder if that
implies that the server was restarted. ?I'm using Mark's server.

 ???????????????????????????????????????????????????????-- Steve

On Mon, 8 Jun 2020, Michael Balzer wrote:

That may have been https://github.com/openvehicles/Open-Vehicle-Server/issues/2

Regards,
Michael


Am 08.06.20 um 19:02 schrieb Stephen Casner:
I'm running 3.2.012. ?This morning when I went to check the status
after charging overnight, which had completed, the iPhone app was
behaving in a very strange manner. ?I cycled a few times (for as long
as I watched) through three states at an interval on the order of
10-20 seconds:

1. 86%, ideal range 191, no charge connector icon. ?Those range and

SOC numbers were correct, but the charge cable was connected.

2. 95%, ideal range 177, charge connector icon shown.

3. 48%, don't recall the range, no charge connector icon.

When I checked the Car screen, it too was cycling among showing no
numbers, showing old gray numbers, and showing some numbers in white.
I don't recall their accuracy.

Now after I finished my morning walk the display appears stable and
correct with 86%, ideal range 190, and charge connector icon shown.
The Car screen shows just old numbers in gray except for the aux
battery voltage. ?Sorry I didn't have the presence of mind to grab
screenshots.

 ???????????????????????????????????????????????????????-- Steve
_______________________________________________
OvmsDev mailing list
OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com> 
http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> 

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

_______________________________________________
OvmsDev mailing list
OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com> 
http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> 


_______________________________________________
OvmsDev mailing list
OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com> 
http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> 

_______________________________________________
OvmsDev mailing list
OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com> 
http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200609/3c1fa813/attachment.htm>

From mark at webb-johnson.net  Wed Jun 10 09:28:46 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Wed, 10 Jun 2020 09:28:46 +0800
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <ae250edd-441b-a6a2-feb7-2871984ad940@expeedo.de>
References: <97B46650-871C-40FF-B10E-A016963E0096@webb-johnson.net>
 <2BC4ED11-7D86-4AB2-87AB-71D648318A3A@webb-johnson.net>
 <ae250edd-441b-a6a2-feb7-2871984ad940@expeedo.de>
Message-ID: <87573F10-AC8A-483A-8085-97E128B6D79F@webb-johnson.net>

No issues reported, so just released this to MAIN.

Regards, Mark.

> On 5 Jun 2020, at 1:15 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> Followed.
> 
> Regards,
> Michael
> 
> 
> Am 05.06.20 um 07:06 schrieb Mark Webb-Johnson:
>> I have release this 3.2.013 to EAP.
>> 
>> Regards, Mark.
>> 
>>> On 31 May 2020, at 5:34 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>> 
>>> 
>>> Getting ready to release 3.2.013. I?ve tagged it, and built for api.openvehicles.com <http://api.openvehicles.com/> edge.
>>> 
>>> The main changes here are:
>>> 
>>> TPMS subsystem (including Tesla Roadster support with new optional K-line expansion board)
>>> Change to config for server.v2
>>> 
>>> For #2, I moved the server password from server.v2/password to password/server.v2, and made the server.v2 config parameter read-write. That better matches how server.v3 does it. The change is done via a config migration, so should be transparent.
>>> 
>>> Absent any issues, I plan to move to EAP early in the coming week.
>>> 
>>> Regards, Mark
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> 
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/417cad0a/attachment.htm>

From dexter at expeedo.de  Wed Jun 10 13:40:27 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Wed, 10 Jun 2020 07:40:27 +0200
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <87573F10-AC8A-483A-8085-97E128B6D79F@webb-johnson.net>
References: <97B46650-871C-40FF-B10E-A016963E0096@webb-johnson.net>
 <2BC4ED11-7D86-4AB2-87AB-71D648318A3A@webb-johnson.net>
 <ae250edd-441b-a6a2-feb7-2871984ad940@expeedo.de>
 <87573F10-AC8A-483A-8085-97E128B6D79F@webb-johnson.net>
Message-ID: <0404afc3-0ca1-8f9b-4d8a-84ffbe78e93f@expeedo.de>

Followed.

Regards,
Michael


Am 10.06.20 um 03:28 schrieb Mark Webb-Johnson:
> No issues reported, so just released this to MAIN.
>
> Regards, Mark.
>
>> On 5 Jun 2020, at 1:15 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
>> Followed.
>>
>> Regards,
>> Michael
>>
>>
>> Am 05.06.20 um 07:06 schrieb Mark Webb-Johnson:
>>> I have release this?3.2.013 to EAP.
>>>
>>> Regards, Mark.
>>>
>>>> On 31 May 2020, at 5:34 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>>
>>>>
>>>> Getting ready to release 3.2.013. I?ve tagged it, and built for api.openvehicles.com <http://api.openvehicles.com/>?edge.
>>>>
>>>> The main changes here are:
>>>>
>>>>  1. TPMS subsystem (including Tesla Roadster support with new optional K-line expansion board)
>>>>  2. Change to config for server.v2
>>>>
>>>>
>>>> For #2, I moved the server password from server.v2/password to password/server.v2, and made the server.v2 config parameter read-write. That better matches
>>>> how server.v3 does it. The change is done via a config migration, so should be transparent.
>>>>
>>>> Absent any issues, I plan to move to EAP early in the coming week.
>>>>
>>>> Regards, Mark
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/8136c244/attachment.htm>

From chris at arachnon.de  Wed Jun 10 20:57:59 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Wed, 10 Jun 2020 14:57:59 +0200
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <0404afc3-0ca1-8f9b-4d8a-84ffbe78e93f@expeedo.de>
References: <97B46650-871C-40FF-B10E-A016963E0096@webb-johnson.net>
 <2BC4ED11-7D86-4AB2-87AB-71D648318A3A@webb-johnson.net>
 <ae250edd-441b-a6a2-feb7-2871984ad940@expeedo.de>
 <87573F10-AC8A-483A-8085-97E128B6D79F@webb-johnson.net>
 <0404afc3-0ca1-8f9b-4d8a-84ffbe78e93f@expeedo.de>
Message-ID: <1591793879.2548.5.camel@arachnon.de>

Hi all,
sorry for a perhaps silly question, but I don't understand the version
numbering between master and fork.
I regulary merge the changes from the ovms repository to my fork. So
far so good and I am up to date at the moment. OVMS is now on release
3.2.013. When I perform a pull request on my fork and do a "make" on my
local machine, I'm still on release 3.2.010. Even though the code is
absolutely up to date.
Could someone give me a hint on how to get the release numbers synced
between the ovms master and my fork?
Thanx in advance.
Greetinx
Chris

Am Mittwoch, den 10.06.2020, 07:40 +0200 schrieb Michael Balzer:
> ????Followed.
> 
> ????
> 
> ????Regards,
> 
> ????Michael
> 
> ????
> 
> ????
> 
> ????Am 10.06.20 um 03:28 schrieb Mark
> ??????Webb-Johnson:
> 
> ????
> 
> ????
> > ??????
> > ??????No issues reported, so just released this to MAIN.
> > ??????
> > 
> > ??????
> > ??????Regards, Mark.
> > 
> > ????????
> > 
> > ??????????
> > > ????????????On 5 Jun 2020, at 1:15 PM, Michael Balzer <dexter at exp
> > > eedo.de> wrote:
> > > ????????????
> > > 
> > > ????????????
> > > ??????????????
> > > ???????????????Followed.
> > > 
> > > ????????????????
> > > 
> > > ????????????????Regards,
> > > 
> > > ????????????????Michael
> > > 
> > > ????????????????
> > > 
> > > ????????????????
> > > 
> > > ????????????????Am 05.06.20 um 07:06
> > > ??????????????????schrieb Mark Webb-Johnson:
> > > 
> > > ????????????????
> > > ????????????????
> > > > ??????????????????
> > > > ??????????????????I have release this?3.2.013 to EAP.
> > > > ??????????????????
> > > > 
> > > > ??????????????????
> > > > ??????????????????Regards, Mark.
> > > > 
> > > > ????????????????????
> > > > 
> > > > ??????????????????????
> > > > > ????????????????????????On 31 May 2020, at 5:34 PM, Mark
> > > > > ??????????????????????????Webb-Johnson <mark at webb-johnson.net
> > > > > >
> > > > > ??????????????????????????wrote:
> > > > > ????????????????????????
> > > > > 
> > > > > ????????????????????????
> > > > > ??????????????????????????
> > > > > ??????????????????????????
> > > > > ????????????????????????????
> > > > > 
> > > > > ????????????????????????????
> > > > > ????????????????????????????Getting ready to release
> > > > > ??????????????????????????????3.2.013. I?ve tagged it, and
> > > > > built for api.openvehicles.com?edge.
> > > > > ????????????????????????????
> > > > > 
> > > > > ????????????????????????????
> > > > > ????????????????????????????The main changes here are:
> > > > > ????????????????????????????
> > > > > 
> > > > > ????????????????????????????
> > > > > ????????????????????????????
> > > > > ??????????????????????????????
> > > > > ????????????????????????????????TPMS subsystem (including
> > > > > ??????????????????????????????????Tesla Roadster support with
> > > > > new
> > > > > ??????????????????????????????????optional K-line expansion
> > > > > board)
> > > > > ????????????????????????????????Change to config for
> > > > > ??????????????????????????????????server.v2
> > > > > ??????????????????????????????
> > > > > ????????????????????????????
> > > > > ????????????????????????????
> > > > > 
> > > > > ????????????????????????????
> > > > > ????????????????????????????For #2, I moved the server
> > > > > ??????????????????????????????password from
> > > > > server.v2/password to
> > > > > ??????????????????????????????password/server.v2, and made
> > > > > the server.v2
> > > > > ??????????????????????????????config parameter read-write.
> > > > > That better
> > > > > ??????????????????????????????matches how server.v3 does it.
> > > > > The change
> > > > > ??????????????????????????????is done via a config migration,
> > > > > so should
> > > > > ??????????????????????????????be transparent.
> > > > > ????????????????????????????
> > > > > 
> > > > > ????????????????????????????
> > > > > ????????????????????????????Absent any issues, I plan to
> > > > > ??????????????????????????????move to EAP early in the coming
> > > > > week.
> > > > > ????????????????????????????
> > > > > 
> > > > > ????????????????????????????
> > > > > ????????????????????????????Regards, Mark
> > > > > ????????????????????????????
> > > > > 
> > > > > ????????????????????????????
> > > > > ??????????????????????????
> > > > > _______________________________________________
> > > > > 
> > > > > ??????????????????????????OvmsDev mailing list
> > > > > 
> > > > > ??????????????????????????OvmsDev at lists.openvehicles.com
> > > > > 
> > > > > ??????????????????????????http://lists.openvehicles.com/mailm
> > > > > an/listinfo/ovmsdev
> > > > > 
> > > > > ????????????????????????
> > > > > ??????????????????????
> > > > 
> > > > ????????????????????
> > > > ????????????????????
> > > > 
> > > > ??????????????????
> > > > ??????????????????
> > > > 
> > > > ??????????????????
> > > > ??????????????????_____________________________________________
> > > > __
> > > > OvmsDev mailing list
> > > > OvmsDev at lists.openvehicles.com
> > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > 
> > > > ????????????????
> > > 
> > > ????????????????
> > > 
> > > ????????????????
> > > ??????????????
> > > ??????????????_______________________________________________
> > > 
> > > ??????????????OvmsDev mailing list
> > > 
> > > ??????????????OvmsDev at lists.openvehicles.com
> > > 
> > > ??????????????http://lists.openvehicles.com/mailman/listinfo/ovms
> > > dev
> > > 
> > > ????????????
> > > ??????????
> > 
> > ????????
> > ????????
> > 
> > ??????
> > ??????
> > 
> > ??????
> > ??????_______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > 
> > ????
> 
> ????
> 
> ????--?
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> 
> ??
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/a3a7f156/attachment.htm>

From mark at webb-johnson.net  Wed Jun 10 21:17:34 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Wed, 10 Jun 2020 21:17:34 +0800
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <1591793879.2548.5.camel@arachnon.de>
References: <1591793879.2548.5.camel@arachnon.de>
Message-ID: <61D88B39-3397-4E50-8F51-0FDAEAE4D4BD@webb-johnson.net>

You probably need to include ?tags as an option on your git fetch.

The version is in the tag.

Regards, Mark

> On 10 Jun 2020, at 8:59 PM, Chris van der Meijden <chris at arachnon.de> wrote:
> 
> ?
> Hi all,
> 
> sorry for a perhaps silly question, but I don't understand the version numbering between master and fork.
> 
> I regulary merge the changes from the ovms repository to my fork. So far so good and I am up to date at the moment. OVMS is now on release 3.2.013. When I perform a pull request on my fork and do a "make" on my local machine, I'm still on release 3.2.010. Even though the code is absolutely up to date.
> 
> Could someone give me a hint on how to get the release numbers synced between the ovms master and my fork?
> 
> Thanx in advance.
> 
> Greetinx
> 
> Chris
> 
> 
> Am Mittwoch, den 10.06.2020, 07:40 +0200 schrieb Michael Balzer:
>> Followed.
>> 
>> Regards,
>> Michael
>> 
>> 
>> Am 10.06.20 um 03:28 schrieb Mark Webb-Johnson:
>>> No issues reported, so just released this to MAIN.
>>> 
>>> Regards, Mark.
>>> 
>>>> On 5 Jun 2020, at 1:15 PM, Michael Balzer <dexter at expeedo.de> wrote:
>>>> 
>>>> Followed.
>>>> 
>>>> Regards,
>>>> Michael
>>>> 
>>>> 
>>>> Am 05.06.20 um 07:06 schrieb Mark Webb-Johnson:
>>>>> I have release this 3.2.013 to EAP.
>>>>> 
>>>>> Regards, Mark.
>>>>> 
>>>>>> On 31 May 2020, at 5:34 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>>>>> 
>>>>>> 
>>>>>> Getting ready to release 3.2.013. I?ve tagged it, and built for api.openvehicles.com edge.
>>>>>> 
>>>>>> The main changes here are:
>>>>>> 
>>>>>> TPMS subsystem (including Tesla Roadster support with new optional K-line expansion board)
>>>>>> Change to config for server.v2
>>>>>> 
>>>>>> For #2, I moved the server password from server.v2/password to password/server.v2, and made the server.v2 config parameter read-write. That better matches how server.v3 does it. The change is done via a config migration, so should be transparent.
>>>>>> 
>>>>>> Absent any issues, I plan to move to EAP early in the coming week.
>>>>>> 
>>>>>> Regards, Mark
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.openvehicles.com
>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>> 
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> 
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/10de6b0a/attachment.htm>

From chris at arachnon.de  Wed Jun 10 21:39:23 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Wed, 10 Jun 2020 15:39:23 +0200
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <61D88B39-3397-4E50-8F51-0FDAEAE4D4BD@webb-johnson.net>
References: <1591793879.2548.5.camel@arachnon.de>
 <61D88B39-3397-4E50-8F51-0FDAEAE4D4BD@webb-johnson.net>
Message-ID: <1591796363.2548.7.camel@arachnon.de>

Thanx for your quick response.
--tags did the trick for the local version when compiling. Nevertheless
the tags are not pushed back with "git push origin master" into my fork
on github. There the "releases" and "tags" are still on 3.2.010 ...
I will google that ...

Am Mittwoch, den 10.06.2020, 21:17 +0800 schrieb Mark Webb-Johnson:
> You probably need to include ?tags as an option on your git fetch.
> 
> The version is in the tag.
> 
> Regards, Mark
> 
> > On 10 Jun 2020, at 8:59 PM, Chris van der Meijden <chris at arachnon.d
> > e> wrote:
> > 
> > ?
> > ????
> > ??
> > ? Hi all,
> > sorry for a perhaps silly question, but I don't understand the
> > version numbering between master and fork.
> > I regulary merge the changes from the ovms repository to my fork.
> > So far so good and I am up to date at the moment. OVMS is now on
> > release 3.2.013. When I perform a pull request on my fork and do a
> > "make" on my local machine, I'm still on release 3.2.010. Even
> > though the code is absolutely up to date.
> > Could someone give me a hint on how to get the release numbers
> > synced between the ovms master and my fork?
> > Thanx in advance.
> > Greetinx
> > Chris
> > 
> > Am Mittwoch, den 10.06.2020, 07:40 +0200 schrieb Michael Balzer:
> > > ????Followed.
> > > 
> > > ????
> > > 
> > > ????Regards,
> > > 
> > > ????Michael
> > > 
> > > ????
> > > 
> > > ????
> > > 
> > > ????Am 10.06.20 um 03:28 schrieb Mark
> > > ??????Webb-Johnson:
> > > 
> > > ????
> > > 
> > > ????
> > > > ??????
> > > > ??????No issues reported, so just released this to MAIN.
> > > > ??????
> > > > 
> > > > ??????
> > > > ??????Regards, Mark.
> > > > 
> > > > ????????
> > > > 
> > > > ??????????
> > > > > ????????????On 5 Jun 2020, at 1:15 PM, Michael Balzer <dexter
> > > > > @expeedo.de> wrote:
> > > > > ????????????
> > > > > 
> > > > > ????????????
> > > > > ??????????????
> > > > > ???????????????Followed.
> > > > > 
> > > > > ????????????????
> > > > > 
> > > > > ????????????????Regards,
> > > > > 
> > > > > ????????????????Michael
> > > > > 
> > > > > ????????????????
> > > > > 
> > > > > ????????????????
> > > > > 
> > > > > ????????????????Am 05.06.20 um 07:06
> > > > > ??????????????????schrieb Mark Webb-Johnson:
> > > > > 
> > > > > ????????????????
> > > > > ????????????????
> > > > > > ??????????????????
> > > > > > ??????????????????I have release this?3.2.013 to EAP.
> > > > > > ??????????????????
> > > > > > 
> > > > > > ??????????????????
> > > > > > ??????????????????Regards, Mark.
> > > > > > 
> > > > > > ????????????????????
> > > > > > 
> > > > > > ??????????????????????
> > > > > > > ????????????????????????On 31 May 2020, at 5:34 PM, Mark
> > > > > > > ??????????????????????????Webb-Johnson <mark at webb-johnson
> > > > > > > .net>
> > > > > > > ??????????????????????????wrote:
> > > > > > > ????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????
> > > > > > > ??????????????????????????
> > > > > > > ??????????????????????????
> > > > > > > ????????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????????
> > > > > > > ????????????????????????????Getting ready to release
> > > > > > > ??????????????????????????????3.2.013. I?ve tagged it,
> > > > > > > and built for api.openvehicles.com?edge.
> > > > > > > ????????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????????
> > > > > > > ????????????????????????????The main changes here are:
> > > > > > > ????????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????????
> > > > > > > ????????????????????????????
> > > > > > > ??????????????????????????????
> > > > > > > ????????????????????????????????TPMS subsystem (including
> > > > > > > ??????????????????????????????????Tesla Roadster support
> > > > > > > with new
> > > > > > > ??????????????????????????????????optional K-line
> > > > > > > expansion board)
> > > > > > > ????????????????????????????????Change to config for
> > > > > > > ??????????????????????????????????server.v2
> > > > > > > ??????????????????????????????
> > > > > > > ????????????????????????????
> > > > > > > ????????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????????
> > > > > > > ????????????????????????????For #2, I moved the server
> > > > > > > ??????????????????????????????password from
> > > > > > > server.v2/password to
> > > > > > > ??????????????????????????????password/server.v2, and
> > > > > > > made the server.v2
> > > > > > > ??????????????????????????????config parameter read-
> > > > > > > write. That better
> > > > > > > ??????????????????????????????matches how server.v3 does
> > > > > > > it. The change
> > > > > > > ??????????????????????????????is done via a config
> > > > > > > migration, so should
> > > > > > > ??????????????????????????????be transparent.
> > > > > > > ????????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????????
> > > > > > > ????????????????????????????Absent any issues, I plan to
> > > > > > > ??????????????????????????????move to EAP early in the
> > > > > > > coming week.
> > > > > > > ????????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????????
> > > > > > > ????????????????????????????Regards, Mark
> > > > > > > ????????????????????????????
> > > > > > > 
> > > > > > > ????????????????????????????
> > > > > > > ??????????????????????????
> > > > > > > _______________________________________________
> > > > > > > 
> > > > > > > ??????????????????????????OvmsDev mailing list
> > > > > > > 
> > > > > > > ??????????????????????????OvmsDev at lists.openvehicles.com
> > > > > > > 
> > > > > > > ??????????????????????????http://lists.openvehicles.com/m
> > > > > > > ailman/listinfo/ovmsdev
> > > > > > > 
> > > > > > > ????????????????????????
> > > > > > > ??????????????????????
> > > > > > 
> > > > > > ????????????????????
> > > > > > ????????????????????
> > > > > > 
> > > > > > ??????????????????
> > > > > > ??????????????????
> > > > > > 
> > > > > > ??????????????????
> > > > > > ??????????????????_________________________________________
> > > > > > ______
> > > > > > OvmsDev mailing list
> > > > > > OvmsDev at lists.openvehicles.com
> > > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > > > 
> > > > > > ????????????????
> > > > > 
> > > > > ????????????????
> > > > > 
> > > > > ????????????????
> > > > > ??????????????
> > > > > ??????????????_______________________________________________
> > > > > 
> > > > > ??????????????OvmsDev mailing list
> > > > > 
> > > > > ??????????????OvmsDev at lists.openvehicles.com
> > > > > 
> > > > > ??????????????http://lists.openvehicles.com/mailman/listinfo/
> > > > > ovmsdev
> > > > > 
> > > > > ????????????
> > > > > ??????????
> > > > 
> > > > ????????
> > > > ????????
> > > > 
> > > > ??????
> > > > ??????
> > > > 
> > > > ??????
> > > > ??????_______________________________________________
> > > > OvmsDev mailing list
> > > > OvmsDev at lists.openvehicles.com
> > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > 
> > > > ????
> > > 
> > > ????
> > > 
> > > ????
> > > ??
> > > 
> > > _______________________________________________
> > > OvmsDev mailing list
> > > OvmsDev at lists.openvehicles.com
> > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/6ce9e242/attachment.htm>

From mark at webb-johnson.net  Wed Jun 10 21:43:10 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Wed, 10 Jun 2020 21:43:10 +0800
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <1591796363.2548.7.camel@arachnon.de>
References: <1591796363.2548.7.camel@arachnon.de>
Message-ID: <B1DE133D-50DC-4E92-B3F3-FA8EF40AF61E@webb-johnson.net>

Also ?tags on the push.

Regards, Mark

> On 10 Jun 2020, at 9:40 PM, Chris van der Meijden <chris at arachnon.de> wrote:
> 
> ?
> Thanx for your quick response.
> 
> --tags did the trick for the local version when compiling. Nevertheless the tags are not pushed back with "git push origin master" into my fork on github. There the "releases" and "tags" are still on 3.2.010 ...
> 
> I will google that ...
> 
> 
> Am Mittwoch, den 10.06.2020, 21:17 +0800 schrieb Mark Webb-Johnson:
>> You probably need to include ?tags as an option on your git fetch.
>> 
>> The version is in the tag.
>> 
>> Regards, Mark
>> 
>>>> On 10 Jun 2020, at 8:59 PM, Chris van der Meijden <chris at arachnon.de> wrote:
>>>> 
>>> ?
>>> Hi all,
>>> 
>>> sorry for a perhaps silly question, but I don't understand the version numbering between master and fork.
>>> 
>>> I regulary merge the changes from the ovms repository to my fork. So far so good and I am up to date at the moment. OVMS is now on release 3.2.013. When I perform a pull request on my fork and do a "make" on my local machine, I'm still on release 3.2.010. Even though the code is absolutely up to date.
>>> 
>>> Could someone give me a hint on how to get the release numbers synced between the ovms master and my fork?
>>> 
>>> Thanx in advance.
>>> 
>>> Greetinx
>>> 
>>> Chris
>>> 
>>> 
>>> Am Mittwoch, den 10.06.2020, 07:40 +0200 schrieb Michael Balzer:
>>>> Followed.
>>>> 
>>>> Regards,
>>>> Michael
>>>> 
>>>> 
>>>> Am 10.06.20 um 03:28 schrieb Mark Webb-Johnson:
>>>>> No issues reported, so just released this to MAIN.
>>>>> 
>>>>> Regards, Mark.
>>>>> 
>>>>>> On 5 Jun 2020, at 1:15 PM, Michael Balzer <dexter at expeedo.de> wrote:
>>>>>> 
>>>>>> Followed.
>>>>>> 
>>>>>> Regards,
>>>>>> Michael
>>>>>> 
>>>>>> 
>>>>>> Am 05.06.20 um 07:06 schrieb Mark Webb-Johnson:
>>>>>>> I have release this 3.2.013 to EAP.
>>>>>>> 
>>>>>>> Regards, Mark.
>>>>>>> 
>>>>>>>> On 31 May 2020, at 5:34 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Getting ready to release 3.2.013. I?ve tagged it, and built for api.openvehicles.com edge.
>>>>>>>> 
>>>>>>>> The main changes here are:
>>>>>>>> 
>>>>>>>> TPMS subsystem (including Tesla Roadster support with new optional K-line expansion board)
>>>>>>>> Change to config for server.v2
>>>>>>>> 
>>>>>>>> For #2, I moved the server password from server.v2/password to password/server.v2, and made the server.v2 config parameter read-write. That better matches how server.v3 does it. The change is done via a config migration, so should be transparent.
>>>>>>>> 
>>>>>>>> Absent any issues, I plan to move to EAP early in the coming week.
>>>>>>>> 
>>>>>>>> Regards, Mark
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> OvmsDev mailing list
>>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.openvehicles.com
>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>> 
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/45309c98/attachment.htm>

From chris at arachnon.de  Wed Jun 10 21:42:31 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Wed, 10 Jun 2020 15:42:31 +0200
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <1591796363.2548.7.camel@arachnon.de>
References: <1591793879.2548.5.camel@arachnon.de>
 <61D88B39-3397-4E50-8F51-0FDAEAE4D4BD@webb-johnson.net>
 <1591796363.2548.7.camel@arachnon.de>
Message-ID: <1591796551.2548.8.camel@arachnon.de>

OK, now this was silly :-)

I just needed to 

git push origin master --tags

...

Chris

Am Mittwoch, den 10.06.2020, 15:39 +0200 schrieb Chris van der Meijden:
> Thanx for your quick response.
> 
> --tags did the trick for the local version when compiling.
> Nevertheless the tags are not pushed back with "git push origin
> master" into my fork on github. There the "releases" and "tags" are
> still on 3.2.010 ...
> 
> I will google that ...
> 
> 
> Am Mittwoch, den 10.06.2020, 21:17 +0800 schrieb Mark Webb-Johnson:
> > You probably need to include ?tags as an option on your git fetch.
> > 
> > The version is in the tag.
> > 
> > Regards, Mark
> > 
> > > On 10 Jun 2020, at 8:59 PM, Chris van der Meijden <chris at arachnon
> > > .de> wrote:
> > > 
> > > ?
> > > ????
> > > ??
> > > ? Hi all,
> > > sorry for a perhaps silly question, but I don't understand the
> > > version numbering between master and fork.
> > > I regulary merge the changes from the ovms repository to my fork.
> > > So far so good and I am up to date at the moment. OVMS is now on
> > > release 3.2.013. When I perform a pull request on my fork and do
> > > a "make" on my local machine, I'm still on release 3.2.010. Even
> > > though the code is absolutely up to date.
> > > Could someone give me a hint on how to get the release numbers
> > > synced between the ovms master and my fork?
> > > Thanx in advance.
> > > Greetinx
> > > Chris
> > > 
> > > Am Mittwoch, den 10.06.2020, 07:40 +0200 schrieb Michael Balzer:
> > > > ????Followed.
> > > > 
> > > > ????
> > > > 
> > > > ????Regards,
> > > > 
> > > > ????Michael
> > > > 
> > > > ????
> > > > 
> > > > ????
> > > > 
> > > > ????Am 10.06.20 um 03:28 schrieb Mark
> > > > ??????Webb-Johnson:
> > > > 
> > > > ????
> > > > 
> > > > ????
> > > > > ??????
> > > > > ??????No issues reported, so just released this to MAIN.
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????Regards, Mark.
> > > > > 
> > > > > ????????
> > > > > 
> > > > > ??????????
> > > > > > ????????????On 5 Jun 2020, at 1:15 PM, Michael Balzer <dext
> > > > > > er at expeedo.de> wrote:
> > > > > > ????????????
> > > > > > ????????????
> > > > > > ??????????????
> > > > > > ???????????????Followed.
> > > > > > 
> > > > > > ????????????????
> > > > > > 
> > > > > > ????????????????Regards,
> > > > > > 
> > > > > > ????????????????Michael
> > > > > > 
> > > > > > ????????????????
> > > > > > 
> > > > > > ????????????????
> > > > > > 
> > > > > > ????????????????Am 05.06.20 um 07:06
> > > > > > ??????????????????schrieb Mark Webb-Johnson:
> > > > > > 
> > > > > > ????????????????
> > > > > > ????????????????
> > > > > > > ??????????????????
> > > > > > > ??????????????????I have release this?3.2.013 to EAP.
> > > > > > > ??????????????????
> > > > > > > 
> > > > > > > ??????????????????
> > > > > > > ??????????????????Regards, Mark.
> > > > > > > 
> > > > > > > ????????????????????
> > > > > > > 
> > > > > > > ??????????????????????
> > > > > > > > ????????????????????????On 31 May 2020, at 5:34 PM,
> > > > > > > > Mark
> > > > > > > > ??????????????????????????Webb-Johnson <mark at webb-johns
> > > > > > > > on.net>
> > > > > > > > ??????????????????????????wrote:
> > > > > > > > ????????????????????????
> > > > > > > > ????????????????????????
> > > > > > > > ??????????????????????????
> > > > > > > > ??????????????????????????
> > > > > > > > ????????????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????????????
> > > > > > > > ????????????????????????????Getting ready to release
> > > > > > > > ??????????????????????????????3.2.013. I?ve tagged it,
> > > > > > > > and built for api.openvehicles.com?edge.
> > > > > > > > ????????????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????????????
> > > > > > > > ????????????????????????????The main changes here are:
> > > > > > > > ????????????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????????????
> > > > > > > > ????????????????????????????
> > > > > > > > ??????????????????????????????
> > > > > > > > ????????????????????????????????TPMS subsystem
> > > > > > > > (including
> > > > > > > > ??????????????????????????????????Tesla Roadster
> > > > > > > > support with new
> > > > > > > > ??????????????????????????????????optional K-line
> > > > > > > > expansion board)
> > > > > > > > ????????????????????????????????Change to config for
> > > > > > > > ??????????????????????????????????server.v2
> > > > > > > > ??????????????????????????????
> > > > > > > > ????????????????????????????
> > > > > > > > ????????????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????????????
> > > > > > > > ????????????????????????????For #2, I moved the server
> > > > > > > > ??????????????????????????????password from
> > > > > > > > server.v2/password to
> > > > > > > > ??????????????????????????????password/server.v2, and
> > > > > > > > made the server.v2
> > > > > > > > ??????????????????????????????config parameter read-
> > > > > > > > write. That better
> > > > > > > > ??????????????????????????????matches how server.v3
> > > > > > > > does it. The change
> > > > > > > > ??????????????????????????????is done via a config
> > > > > > > > migration, so should
> > > > > > > > ??????????????????????????????be transparent.
> > > > > > > > ????????????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????????????
> > > > > > > > ????????????????????????????Absent any issues, I plan
> > > > > > > > to
> > > > > > > > ??????????????????????????????move to EAP early in the
> > > > > > > > coming week.
> > > > > > > > ????????????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????????????
> > > > > > > > ????????????????????????????Regards, Mark
> > > > > > > > ????????????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????????????
> > > > > > > > ??????????????????????????
> > > > > > > > _______________________________________________
> > > > > > > > 
> > > > > > > > ??????????????????????????OvmsDev mailing list
> > > > > > > > 
> > > > > > > > ??????????????????????????OvmsDev at lists.openvehicles.co
> > > > > > > > m
> > > > > > > > 
> > > > > > > > ??????????????????????????http://lists.openvehicles.com
> > > > > > > > /mailman/listinfo/ovmsdev
> > > > > > > > 
> > > > > > > > ????????????????????????
> > > > > > > > ??????????????????????
> > > > > > > 
> > > > > > > ????????????????????
> > > > > > > ????????????????????
> > > > > > > 
> > > > > > > ??????????????????
> > > > > > > ??????????????????
> > > > > > > 
> > > > > > > ??????????????????
> > > > > > > ??????????????????_______________________________________
> > > > > > > ________
> > > > > > > OvmsDev mailing list
> > > > > > > OvmsDev at lists.openvehicles.com
> > > > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > > > > 
> > > > > > > ????????????????
> > > > > > 
> > > > > > ????????????????
> > > > > > 
> > > > > > ????????????????
> > > > > > ??????????????
> > > > > > ??????????????_____________________________________________
> > > > > > __
> > > > > > 
> > > > > > ??????????????OvmsDev mailing list
> > > > > > 
> > > > > > ??????????????OvmsDev at lists.openvehicles.com
> > > > > > 
> > > > > > ??????????????http://lists.openvehicles.com/mailman/listinf
> > > > > > o/ovmsdev
> > > > > > 
> > > > > > ????????????
> > > > > > ??????????
> > > > > 
> > > > > ????????
> > > > > ????????
> > > > > 
> > > > > ??????
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????_______________________________________________
> > > > > OvmsDev mailing list
> > > > > OvmsDev at lists.openvehicles.com
> > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > > 
> > > > > ????
> > > > 
> > > > ????
> > > > 
> > > > ????
> > > > ??
> > > > 
> > > > _______________________________________________
> > > > OvmsDev mailing list
> > > > OvmsDev at lists.openvehicles.com
> > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > _______________________________________________
> > > OvmsDev mailing list
> > > OvmsDev at lists.openvehicles.com
> > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/2d79702d/attachment.htm>

From chris at arachnon.de  Wed Jun 10 21:44:06 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Wed, 10 Jun 2020 15:44:06 +0200
Subject: [Ovmsdev] 3.2.013
In-Reply-To: <B1DE133D-50DC-4E92-B3F3-FA8EF40AF61E@webb-johnson.net>
References: <1591796363.2548.7.camel@arachnon.de>
 <B1DE133D-50DC-4E92-B3F3-FA8EF40AF61E@webb-johnson.net>
Message-ID: <1591796646.2548.9.camel@arachnon.de>

Crosspost :-)

Thanx!

Am Mittwoch, den 10.06.2020, 21:43 +0800 schrieb Mark Webb-Johnson:
> Also ?tags on the push.
> 
> Regards, Mark
> 
> > On 10 Jun 2020, at 9:40 PM, Chris van der Meijden <chris at arachnon.d
> > e> wrote:
> > 
> > ?Thanx for your quick response.
> > --tags did the trick for the local version when compiling.
> > Nevertheless the tags are not pushed back with "git push origin
> > master" into my fork on github. There the "releases" and "tags" are
> > still on 3.2.010 ...
> > I will google that ...
> > 
> > Am Mittwoch, den 10.06.2020, 21:17 +0800 schrieb Mark Webb-Johnson:
> > > You probably need to include ?tags as an option on your git
> > > fetch.
> > > 
> > > The version is in the tag.
> > > 
> > > Regards, Mark
> > > 
> > > > On 10 Jun 2020, at 8:59 PM, Chris van der Meijden <chris at arachn
> > > > on.de> wrote:
> > > > 
> > > > ?
> > > > ????
> > > > ??
> > > > ? Hi all,
> > > > sorry for a perhaps silly question, but I don't understand the
> > > > version numbering between master and fork.
> > > > I regulary merge the changes from the ovms repository to my
> > > > fork. So far so good and I am up to date at the moment. OVMS is
> > > > now on release 3.2.013. When I perform a pull request on my
> > > > fork and do a "make" on my local machine, I'm still on release
> > > > 3.2.010. Even though the code is absolutely up to date.
> > > > Could someone give me a hint on how to get the release numbers
> > > > synced between the ovms master and my fork?
> > > > Thanx in advance.
> > > > Greetinx
> > > > Chris
> > > > 
> > > > Am Mittwoch, den 10.06.2020, 07:40 +0200 schrieb Michael
> > > > Balzer:
> > > > > ????Followed.
> > > > > 
> > > > > ????
> > > > > 
> > > > > ????Regards,
> > > > > 
> > > > > ????Michael
> > > > > 
> > > > > ????
> > > > > 
> > > > > ????
> > > > > 
> > > > > ????Am 10.06.20 um 03:28 schrieb Mark
> > > > > ??????Webb-Johnson:
> > > > > 
> > > > > ????
> > > > > 
> > > > > ????
> > > > > > ??????
> > > > > > ??????No issues reported, so just released this to MAIN.
> > > > > > ??????
> > > > > > 
> > > > > > ??????
> > > > > > ??????Regards, Mark.
> > > > > > 
> > > > > > ????????
> > > > > > 
> > > > > > ??????????
> > > > > > > ????????????On 5 Jun 2020, at 1:15 PM, Michael Balzer <de
> > > > > > > xter at expeedo.de> wrote:
> > > > > > > ????????????
> > > > > > > ????????????
> > > > > > > ??????????????
> > > > > > > ???????????????Followed.
> > > > > > > 
> > > > > > > ????????????????
> > > > > > > 
> > > > > > > ????????????????Regards,
> > > > > > > 
> > > > > > > ????????????????Michael
> > > > > > > 
> > > > > > > ????????????????
> > > > > > > 
> > > > > > > ????????????????
> > > > > > > 
> > > > > > > ????????????????Am 05.06.20 um 07:06
> > > > > > > ??????????????????schrieb Mark Webb-Johnson:
> > > > > > > 
> > > > > > > ????????????????
> > > > > > > ????????????????
> > > > > > > > ??????????????????
> > > > > > > > ??????????????????I have release this?3.2.013 to EAP.
> > > > > > > > ??????????????????
> > > > > > > > 
> > > > > > > > ??????????????????
> > > > > > > > ??????????????????Regards, Mark.
> > > > > > > > 
> > > > > > > > ????????????????????
> > > > > > > > 
> > > > > > > > ??????????????????????
> > > > > > > > > ????????????????????????On 31 May 2020, at 5:34 PM,
> > > > > > > > > Mark
> > > > > > > > > ??????????????????????????Webb-Johnson <mark at webb-joh
> > > > > > > > > nson.net>
> > > > > > > > > ??????????????????????????wrote:
> > > > > > > > > ????????????????????????
> > > > > > > > > ????????????????????????
> > > > > > > > > ??????????????????????????
> > > > > > > > > ??????????????????????????
> > > > > > > > > ????????????????????????????
> > > > > > > > > 
> > > > > > > > > ????????????????????????????
> > > > > > > > > ????????????????????????????Getting ready to release
> > > > > > > > > ??????????????????????????????3.2.013. I?ve tagged
> > > > > > > > > it, and built for api.openvehicles.com?edge.
> > > > > > > > > ????????????????????????????
> > > > > > > > > 
> > > > > > > > > ????????????????????????????
> > > > > > > > > ????????????????????????????The main changes here
> > > > > > > > > are:
> > > > > > > > > ????????????????????????????
> > > > > > > > > 
> > > > > > > > > ????????????????????????????
> > > > > > > > > ????????????????????????????
> > > > > > > > > ??????????????????????????????
> > > > > > > > > ????????????????????????????????TPMS subsystem
> > > > > > > > > (including
> > > > > > > > > ??????????????????????????????????Tesla Roadster
> > > > > > > > > support with new
> > > > > > > > > ??????????????????????????????????optional K-line
> > > > > > > > > expansion board)
> > > > > > > > > ????????????????????????????????Change to config for
> > > > > > > > > ??????????????????????????????????server.v2
> > > > > > > > > ??????????????????????????????
> > > > > > > > > ????????????????????????????
> > > > > > > > > ????????????????????????????
> > > > > > > > > 
> > > > > > > > > ????????????????????????????
> > > > > > > > > ????????????????????????????For #2, I moved the
> > > > > > > > > server
> > > > > > > > > ??????????????????????????????password from
> > > > > > > > > server.v2/password to
> > > > > > > > > ??????????????????????????????password/server.v2, and
> > > > > > > > > made the server.v2
> > > > > > > > > ??????????????????????????????config parameter read-
> > > > > > > > > write. That better
> > > > > > > > > ??????????????????????????????matches how server.v3
> > > > > > > > > does it. The change
> > > > > > > > > ??????????????????????????????is done via a config
> > > > > > > > > migration, so should
> > > > > > > > > ??????????????????????????????be transparent.
> > > > > > > > > ????????????????????????????
> > > > > > > > > 
> > > > > > > > > ????????????????????????????
> > > > > > > > > ????????????????????????????Absent any issues, I plan
> > > > > > > > > to
> > > > > > > > > ??????????????????????????????move to EAP early in
> > > > > > > > > the coming week.
> > > > > > > > > ????????????????????????????
> > > > > > > > > 
> > > > > > > > > ????????????????????????????
> > > > > > > > > ????????????????????????????Regards, Mark
> > > > > > > > > ????????????????????????????
> > > > > > > > > 
> > > > > > > > > ????????????????????????????
> > > > > > > > > ??????????????????????????
> > > > > > > > > _______________________________________________
> > > > > > > > > 
> > > > > > > > > ??????????????????????????OvmsDev mailing list
> > > > > > > > > 
> > > > > > > > > ??????????????????????????OvmsDev at lists.openvehicles.
> > > > > > > > > com
> > > > > > > > > 
> > > > > > > > > ??????????????????????????http://lists.openvehicles.c
> > > > > > > > > om/mailman/listinfo/ovmsdev
> > > > > > > > > 
> > > > > > > > > ????????????????????????
> > > > > > > > > ??????????????????????
> > > > > > > > 
> > > > > > > > ????????????????????
> > > > > > > > ????????????????????
> > > > > > > > 
> > > > > > > > ??????????????????
> > > > > > > > ??????????????????
> > > > > > > > 
> > > > > > > > ??????????????????
> > > > > > > > ??????????????????_____________________________________
> > > > > > > > __________
> > > > > > > > OvmsDev mailing list
> > > > > > > > OvmsDev at lists.openvehicles.com
> > > > > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > > > > > 
> > > > > > > > ????????????????
> > > > > > > 
> > > > > > > ????????????????
> > > > > > > 
> > > > > > > ????????????????
> > > > > > > ??????????????
> > > > > > > ??????????????___________________________________________
> > > > > > > ____
> > > > > > > 
> > > > > > > ??????????????OvmsDev mailing list
> > > > > > > 
> > > > > > > ??????????????OvmsDev at lists.openvehicles.com
> > > > > > > 
> > > > > > > ??????????????http://lists.openvehicles.com/mailman/listi
> > > > > > > nfo/ovmsdev
> > > > > > > 
> > > > > > > ????????????
> > > > > > > ??????????
> > > > > > 
> > > > > > ????????
> > > > > > ????????
> > > > > > 
> > > > > > ??????
> > > > > > ??????
> > > > > > 
> > > > > > ??????
> > > > > > ??????_______________________________________________
> > > > > > OvmsDev mailing list
> > > > > > OvmsDev at lists.openvehicles.com
> > > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > > > 
> > > > > > ????
> > > > > 
> > > > > ????
> > > > > 
> > > > > ????
> > > > > ??
> > > > > 
> > > > > _______________________________________________
> > > > > OvmsDev mailing list
> > > > > OvmsDev at lists.openvehicles.com
> > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > _______________________________________________
> > > > OvmsDev mailing list
> > > > OvmsDev at lists.openvehicles.com
> > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > _______________________________________________
> > > OvmsDev mailing list
> > > OvmsDev at lists.openvehicles.com
> > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200610/69623960/attachment.htm>

From mark at webb-johnson.net  Thu Jun 11 09:37:03 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Thu, 11 Jun 2020 09:37:03 +0800
Subject: [Ovmsdev] Strange app behavior
In-Reply-To: <AB995B00-EA4C-4C58-8685-93181C7EF36B@webb-johnson.net>
References: <alpine.OSX.2.21.9999.2006080951320.15345@auge.attlocal.net>
 <7dec280e-35b7-7a02-32e9-2d1d32502fd8@expeedo.de>
 <alpine.OSX.2.21.9999.2006082236160.15345@auge.attlocal.net>
 <AB995B00-EA4C-4C58-8685-93181C7EF36B@webb-johnson.net>
Message-ID: <0852A30F-ABC9-4E3B-9345-5EC880A06C69@webb-johnson.net>


Very bizarre. The issue was hard to track down. Seems to be strange behaviour in SSL connections with faults, where the SSL error comes in, the connection is torn down, but then a welcome message arrives for the login (after the disconnection). If the welcome login succeeds, then the vehicle App connection is associated with the FD# and causes the issue later on.

So, the server code sees a login message after the connection was disconnected ?

2020-06-10 20:36:20.271547 +0800 info  OVMS::Server::ApiV2: #253 - - new TLS connection from <redacted>
2020-06-10 20:36:20.273606 +0800 info  OVMS::Server::Core: #253 - - ConnStart
2020-06-10 20:36:28.781028 +0800 error OVMS::Server::ApiV2: #253 C <redacted-car> got error: ssl3_read_bytes: ssl handshake failure
2020-06-10 20:36:28.782356 +0800 info  OVMS::Server::Core: #253 C <redacted-car> CarDisconnect
2020-06-10 20:36:28.782821 +0800 info  OVMS::Server::Core: #253 - - ConnFinish
Use of uninitialized value in concatenation (.) or string at plugins/system/OVMS/Server/ApiV2.pm line 631.
2020-06-10 20:36:28.783094 +0800 info  OVMS::Server::ApiV2: #253 C <redacted-car> got proto #/C login
Use of uninitialized value $clienttype in concatenation (.) or string at plugins/system/OVMS/Server/Core.pm line 237.
2020-06-10 20:36:28.784261 +0800 info  OVMS::Server::Core: #253  <redacted-car> CarConnect

At that stage, the fd #253 is tagged with an App connection, and never cleared (because the CarDisconnect was before the CarConnect).

Later on, that fd# can get data from the original app/car with connection issues. The source of bad data seems to be almost always the DEMO car.

Workaround is to add connection checks to the io_line and io_welcome routines, to simply return (discard) if the connection is not marked as up.

Will load this live on api.openvehicles.com now, and monitor for a few days. We now have logging for these mismatched connections (and code to avoid sending out the data in that case), so it should be easy to see if this solves the problem.

Regards, Mark.

> On 9 Jun 2020, at 1:48 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> Steve,
> 
> I wasn?t aware of this issue, but will look into it. I can?t immediately see the cause, but it should be relatively easy to add a clean-up of the channel structures when the connection starts.
> 
> I haven?t restarted the api.openvehicles.com <http://api.openvehicles.com/> server recently.
> 
> Regards, Mark.
> 
>> On 9 Jun 2020, at 1:39 PM, Stephen Casner <casner at acm.org <mailto:casner at acm.org>> wrote:
>> 
>> That sounds plausible.  Since the problem ceased, I wonder if that
>> implies that the server was restarted.  I'm using Mark's server.
>> 
>>                                                        -- Steve
>> 
>> On Mon, 8 Jun 2020, Michael Balzer wrote:
>> 
>>> That may have been https://github.com/openvehicles/Open-Vehicle-Server/issues/2 <https://github.com/openvehicles/Open-Vehicle-Server/issues/2>
>>> 
>>> Regards,
>>> Michael
>>> 
>>> 
>>> Am 08.06.20 um 19:02 schrieb Stephen Casner:
>>>> I'm running 3.2.012.  This morning when I went to check the status
>>>> after charging overnight, which had completed, the iPhone app was
>>>> behaving in a very strange manner.  I cycled a few times (for as long
>>>> as I watched) through three states at an interval on the order of
>>>> 10-20 seconds:
>>>> 
>>>> 1. 86%, ideal range 191, no charge connector icon.  Those range and
>>>> SOC numbers were correct, but the charge cable was connected.
>>>> 
>>>> 2. 95%, ideal range 177, charge connector icon shown.
>>>> 
>>>> 3. 48%, don't recall the range, no charge connector icon.
>>>> 
>>>> When I checked the Car screen, it too was cycling among showing no
>>>> numbers, showing old gray numbers, and showing some numbers in white.
>>>> I don't recall their accuracy.
>>>> 
>>>> Now after I finished my morning walk the display appears stable and
>>>> correct with 86%, ideal range 190, and charge connector icon shown.
>>>> The Car screen shows just old numbers in gray except for the aux
>>>> battery voltage.  Sorry I didn't have the presence of mind to grab
>>>> screenshots.
>>>> 
>>>>                                                        -- Steve
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>> 
>>> --
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>> 
>>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200611/c85ca5d4/attachment.htm>

From leres at xse.com  Sat Jun 13 07:09:24 2020
From: leres at xse.com (Craig Leres)
Date: Fri, 12 Jun 2020 16:09:24 -0700
Subject: [Ovmsdev] Gas vs. battery metric?
Message-ID: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>

I'd like to add a boolean metric for gas vehicles as a prelude to the
phone apps having this info. Would this be ok?

    #define MS_V_MOT_GAS "v.m.gas"

    ms_v_mot_gas = new OvmsMetricBool(MS_V_MOT_GAS);

The default to false. The other way would be via OvmsMetricInt and an
enum (or defines):

    typedef enum : uint8_t
      {
      Battery = 0,
      Gasoline = 1,
    } metric_vehicle_t;

    #define MS_V_MOT_TYPE "v.m.type"

    ms_v_mot_type = new OvmsMetricInt(MS_V_MOT_TYPE);

which would allow for more than two types.

		Craig


From chris at arachnon.de  Sat Jun 13 13:57:09 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Sat, 13 Jun 2020 07:57:09 +0200
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
Message-ID: <1592027829.2567.4.camel@arachnon.de>

Hi Craig,

I think this question could be thin ice :-)

We could start a highly political and emotional discussion on this.
Question is, do we want to support fossil fuel burning technology, or
do we want to make the statement, that the burning stuff aera is over
and if you want to use cool technology like OVMS, then come into the
future and buy an electric vehicle?

Now I'm definitly aware that there will be various different points of
view on this topic and that it is a hot topic. It is easy to drift into
arguing about how political or not OVMS should or could be and
political discussions in a large community mostly leed to emotional
discussions.

I would like to go the way Robert Llewellyn (Youtube channel
Fullycharged) went, when he started to disagree with Johnny Smith on
wether to test hybrids on the channel or not. Robert decided not to do
so, because that would be the wrong signal to the viewers. But that
decission went to the point that Johnny left the show. So, as I said,
these discussions can be thin ice :-)

I'm interested to see where we will be going on this.

Greetinx

Chris

Am Freitag, den 12.06.2020, 16:09 -0700 schrieb Craig Leres:
> I'd like to add a boolean metric for gas vehicles as a prelude to the
> phone apps having this info. Would this be ok?
> 
>     #define MS_V_MOT_GAS "v.m.gas"
> 
>     ms_v_mot_gas = new OvmsMetricBool(MS_V_MOT_GAS);
> 
> The default to false. The other way would be via OvmsMetricInt and an
> enum (or defines):
> 
>     typedef enum : uint8_t
>       {
>       Battery = 0,
>       Gasoline = 1,
>     } metric_vehicle_t;
> 
>     #define MS_V_MOT_TYPE "v.m.type"
> 
>     ms_v_mot_type = new OvmsMetricInt(MS_V_MOT_TYPE);
> 
> which would allow for more than two types.
> 
> 		Craig
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200613/b5c88b8a/attachment.htm>

From dexter at expeedo.de  Sat Jun 13 21:30:55 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Sat, 13 Jun 2020 15:30:55 +0200
Subject: [Ovmsdev] File logging task
In-Reply-To: <6eac2ac1-4835-7a73-51f3-af003a43eae6@expeedo.de>
References: <6eac2ac1-4835-7a73-51f3-af003a43eae6@expeedo.de>
Message-ID: <1bc35602-d032-2d09-07b8-650a7eb3e234@expeedo.de>

I've added a simple workaround for this issue to our esp-idf fork: https://github.com/openvehicles/esp-idf/commit/9024cd38ecbc78a46ed16b79d63f57812e72b123

The workaround checks if logging is done from the timer context, if so reduces the semaphore wait time to zero, thus avoiding blocking.

That should eliminate any timer consistency issues arising from logging in timer callbacks. The disadvantage is a higher chance of such log messages getting
dropped.

Regards,
Michael


Am 05.11.19 um 21:45 schrieb Michael Balzer:
> Everyone,
>
> I've pushed the long due refactoring of the file logging into a dedicated task. This removes most of the delays involved in file logging, as the fsync() and
> log cycling now is done in the logging task and no longer blocks overall log message processing.
>
> I stumbled upon a bad thing (tm) though we need to resolve with logging: the esp-idf logging generally involves a semaphore wait of max 10 ms (!). I wasn't
> aware of this because I didn't look into the source before, there also is no warning about this in the esp-idf documentation
> (https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/log.html), so I guess I'm not the only one being taken by surprise here.
>
>     // Maximum time to wait for the mutex in a logging statement.
>     #define *MAX_MUTEX_WAIT_MS 10*
>     #define MAX_MUTEX_WAIT_TICKS ((MAX_MUTEX_WAIT_MS + portTICK_PERIOD_MS - 1) / portTICK_PERIOD_MS)
>     ?
>     void IRAM_ATTR *esp_log_write*(esp_log_level_t level,
>     ??????? const char* tag,
>     ??????? const char* format, ...)
>     {
>     ??? if (!s_log_mutex) {
>     ??????? s_log_mutex = xSemaphoreCreateMutex();
>     ??? }
>     ??? if (*xSemaphoreTake(s_log_mutex, MAX_MUTEX_WAIT_TICKS*) == pdFALSE) {
>     ??????? return;
>     ??? }
>     ?
>
>
> That semaphore is needed to secure the log level tag cache against parallel access, so it also affects log messages of currently disabled tags and/or levels.
>
> This means we *must not* use the standard logging from timer callbacks, at no verbosity level. But we do, partially caused by my own code serving as a bad
> example I assume -- sorry.
>
> But I've not only found direct log calls in most vehicle timer callbacks, there also are some hidden ones from calling the framework, for example marking a
> notification as read can produce a log output from Cleanup() if tracing is enabled.
>
> We need to change this short to mid term. This may be the cause of those strange timer overflow issues we've seen occasionally. It also means every debug or
> verbose log output currently in the code involves potentially multiple semaphore waits, that's for example the case for all hex dumps logged by the SIMCOM module.
>
> Our primary option is to remove all log calls from all low level framework functions and timer callbacks.
>
> A simple & quick workaround could be to extend the ESP_LOGx macros to check if they are executed in the timer task context, if so suppress the message or call
> the ESP_EARLY log function instead. That will hide these log messages from the logging framework though, if using the _EARLY_ variant they only will be sent
> to the USB port.
>
> For a better solution I thought about adding a dedicated queue & task for the initial log submission as well. That will need quite some rework to the esp-idf
> (no changes for this in the current master) but would allow to continue logging as we do now. Cons: queue submission involves some overhead & RAM, printf
> format expansion needs to be done before the tag/level check, messages may need to be dropped if the task starves or RAM gets tight, log output to consoles
> will depend on a task as well.
>
> Opinions / better ideas?
>
> Regards,
> Michael
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200613/9031297c/attachment.htm>

From dexter at expeedo.de  Sat Jun 13 23:31:40 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Sat, 13 Jun 2020 17:31:40 +0200
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <1592027829.2567.4.camel@arachnon.de>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
Message-ID: <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>

My 2 cents:

We shouldn't generally exclude alternative propulsion technologies.
Battery based electric propulsion will cover the majority of future
transportation and mobility, but it won't fit every use case and every
kind of vehicle.

We should keep the core support to be for (battery) electric propulsion,
and add support for alternative technologies on a strict add-on base.

If for example a vehicle has a hydrogen based range extender, that
should be signaled by the vehicle adapter, and the system should only
then add the set of standard metrics for this particular technology.

A metric "v.m.gas" would be confusing (what kind of gas? what kind of
energy conversion?), would favorize a specific technology by it's name,
and would not be sufficient to describe arbitrary combinations of
technologies (e.g. a BEV with rocket thrusters?).

How about adding an array or set metric like "v.ext" or "v.tech", for
defined technology codes. A tag present in the metric means the
additional metrics, commands & configs for that technology are available.

Regards,
Michael


13.06.20 um 07:57 schrieb Chris van der Meijden:
> Hi Craig,
>
> I think this question could be thin ice :-)
>
> We could start a highly political and emotional discussion on this.
> Question is, do we want to support fossil fuel burning technology, or
> do we want to make the statement, that the burning stuff aera is over
> and if you want to use cool technology like OVMS, then come into the
> future and buy an electric vehicle?
>
> Now I'm definitly aware that there will be various different points of
> view on this topic and that it is a hot topic. It is easy to drift
> into arguing about how political or not OVMS should or could be and
> political discussions in a large community mostly leed to emotional
> discussions.
>
> I would like to go the way Robert Llewellyn (Youtube channel
> Fullycharged) went, when he started to disagree with Johnny Smith on
> wether to test hybrids on the channel or not. Robert decided not to do
> so, because that would be the wrong signal to the viewers. But that
> decission went to the point that Johnny left the show. So, as I said,
> these discussions can be thin ice :-)
>
> I'm interested to see where we will be going on this.
>
> Greetinx
>
> Chris
>
> Am Freitag, den 12.06.2020, 16:09 -0700 schrieb Craig Leres:
>> I'd like to add a boolean metric for gas vehicles as a prelude to the
>> phone apps having this info. Would this be ok?
>>
>>     #define MS_V_MOT_GAS "v.m.gas"
>>
>>     ms_v_mot_gas = new OvmsMetricBool(MS_V_MOT_GAS);
>>
>> The default to false. The other way would be via OvmsMetricInt and an
>> enum (or defines):
>>
>>     typedef enum : uint8_t
>>       {
>>       Battery = 0,
>>       Gasoline = 1,
>>     } metric_vehicle_t;
>>
>>     #define MS_V_MOT_TYPE "v.m.type"
>>
>>     ms_v_mot_type = new OvmsMetricInt(MS_V_MOT_TYPE);
>>
>> which would allow for more than two types.
>>
>> 		Craig
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200613/801c0748/attachment.htm>

From kommykt at gmail.com  Sun Jun 14 14:39:16 2020
From: kommykt at gmail.com (=?UTF-8?B?VGFtw6FzIEtvdsOhY3M=?=)
Date: Sun, 14 Jun 2020 08:39:16 +0200
Subject: [Ovmsdev] Random crash if enable notifications
In-Reply-To: <b3d55512-bf11-8197-25ce-8fb788e8f5bd@expeedo.de>
References: <CAGpaXUsXsLkixzGk06G3S=xkRSKd4UWV-EgoagPjTxV8bptNbg@mail.gmail.com>
 <3ce6a6e3-8119-f123-296c-653ba3e258b4@expeedo.de>
 <CAGpaXUt0C_rv992y+bg7-wmD8wBZ_8g+hFoVndo7YL-xG8L3+A@mail.gmail.com>
 <9e727cb7-1042-202d-c80a-b44b1e1d2f67@expeedo.de>
 <CAGpaXUthOkR9BURwJaK1PmHMgDkL4pmXH9OThJSm8e2LTpy_QA@mail.gmail.com>
 <b3d55512-bf11-8197-25ce-8fb788e8f5bd@expeedo.de>
Message-ID: <CAGpaXUuRy4KMuZKpRLLFnp76rs+gojVHzqotKip+=SQOvVxu=Q@mail.gmail.com>

Now i use 3.2.0.13 from api.openvehicles.com/firmware/ota EAP, updated via
OTA, but if enable pushover notifications, get some crash.

*Pushover Enabled* get the following crash
2020-06-11 07:15:48 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055928 Crash 12 12 1 0 abort() 1
0x4008b72f 0x4008b9c9 0x4010b023 0x4009847e 0x40098743 0x400988f5
0x400982da 0x40084351 0x400847dd 0x4000bec7 0x401c0e6d 0x401c6d9a
0x400f2d99 0x400f39d3 0x400f39cc 0x4015613d 0x4015513a 0x400f2605
0x400f2812 0x400f2889 0x400f2899  4 Exception/panic
2020-06-11 07:15:50 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055928 Crash 12 12 1 0 abort() 1
0x4008b72f 0x4008b9c9 0x4010b023 0x4009847e 0x40098743 0x400988f5
0x400982da 0x40084351 0x400847dd 0x4000bec7 0x401c0e6d 0x401c6d9a
0x400f2d99 0x400f39d3 0x400f39cc 0x4015613d 0x4015513a 0x400f2605
0x400f2812 0x400f2889 0x400f2899  4 Exception/panic
2020-06-11 07:15:52 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055928 Crash 12 12 1 0 abort() 1
0x4008b72f 0x4008b9c9 0x4010b023 0x4009847e 0x40098743 0x400988f5
0x400982da 0x40084351 0x400847dd 0x4000bec7 0x401c0e6d 0x401c6d9a
0x400f2d99 0x400f39d3 0x400f39cc 0x4015613d 0x4015513a 0x400f2605
0x400f2812 0x400f2889 0x400f2899  4 Exception/panic
2020-06-11 08:17:25 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055929 Crash 12 12 2 0 abort() 1
0x4008b72f 0x4008b9c9 0x4010b023 0x400982d3 0x40084351 0x400847dd
0x4000bec7 0x401c0e6d 0x400f2da1 0x400f39d3 0x400f39cc 0x400f39cc
0x400f39cc 0x400f39cc 0x400f39cc 0x4015613d 0x4015513a 0x400f2605
0x400f2812 0x400f2889 0x400f2899  4 Exception/panic
2020-06-11 08:17:29 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055929 Crash 12 12 2 0 abort() 1
0x4008b72f 0x4008b9c9 0x4010b023 0x400982d3 0x40084351 0x400847dd
0x4000bec7 0x401c0e6d 0x400f2da1 0x400f39d3 0x400f39cc 0x400f39cc
0x400f39cc 0x400f39cc 0x400f39cc 0x4015613d 0x4015513a 0x400f2605
0x400f2812 0x400f2889 0x400f2899  4 Exception/panic
2020-06-11 11:11:37 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055930 Crash 12 12 3 0 abort() 1
0x4008b72f 0x4008b9c9 0x4010b023 0x400982d3 0x40084351 0x400847dd
0x4000bec7 0x401c0e6d 0x401c6d9a 0x400f2d99 0x400f39d3 0x400f39cc
0x4015613d 0x4015513a 0x400f2605 0x400f2812 0x400f2889 0x400f2899  4
Exception/panic
2020-06-11 17:16:13 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055931 Crash 12 12 4 0 abort() 1
0x4008b72f 0x4008b9c9 0x4010b023 0x400982d3 0x40084351 0x400847dd
0x4000bec7 0x401c0e6d 0x400f2da1 0x400f39d3 0x400f39cc 0x400f39cc
0x400f39cc 0x400f39cc 0x400f39cc 0x4015613d 0x4015513a 0x400f2605
0x400f2812 0x400f2889 0x400f2899  4 Exception/panic

*Pushover disabled:*




2020-06-13 13:19:33 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055932 Crash 12 12 5 0 abort() 0
0x4008b72f 0x4008b9c9 0x400e6abc 0x4008404a  6 Task watchdog
2020-06-13 15:08:28 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055933 Crash 12 12 6 0 abort() 0
0x4008b72f 0x4008b9c9 0x400e6abc 0x4008404a  6 Task watchdog
2020-06-13 18:22:30 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055934 Crash 12 12 7 0 abort() 0
0x4008b72f 0x4008b9c9 0x400e6abc 0x4008404a  6 Task watchdog
2020-06-13 19:26:15 0 3.2.013/ota_1/eap (build idf v3.3-beta3-775-gdc1ca69
May 31 2020 17:27:06) 1331055935 Crash 12 12 8 0 abort() 0
0x4008b72f 0x4008b9c9 0x400e6abc 0x4008404a  6 Task watchdog


Michael Balzer <dexter at expeedo.de> ezt ?rta (id?pont: 2020. j?n. 8., H,
20:39):

> I cannot tell if you did the correct setup for the spiram fix.
>
> You need
> - the new toolchain
> - the new libs
> - the spiram esp-idf branch
> - the spiram ovms branch
>
> If you've got all of this, then the crash isn't related to the SPIRAM bug.
>
> Regards,
> Michael
>
>
> Am 07.06.20 um 07:50 schrieb Tam?s Kov?cs:
>
> I downloaded this toolchain and use it: build idf
> v3.3-beta3-776-g3d198cd50
> I checkout esp-idf to spiram-fix-test branch.
>
> I use a forked repo.
> I run the following to update to spiram-fix-test, on my local repo.
> git fetch upstream
> git pull upstream/spiram-fix-test master
>
> But i now get crash the last is:
> Last crash: abort() was called on core 1 Backtrace: 0x4008ace7 0x4008af7d
> 0x4010badf 0x40097d93 0x40083ffd 0x400845f1 0x4000bec7 0x4012c729
> 0x402a1815 0x401eb40d 0x401f7a26 0x401f8af0 0x40207065 0x40206f45
> 0x40207133 0x40206faf 0x402073b6 0x4020747d 0x401f4445 0x401f3344
> 0x401f3677 0x401f441e 0x402079d1 0x401f76e5 0x401f7892 0x40202ea6
> 0x4012db9a 0x4012dd9d
>
> kommykt at MacBook-Air OVMS.V3 % a2l 0x4008ace7 0x4008af7d 0x4010badf
> 0x40097d93 0x40083ffd 0x400845f1 0x4000bec7 0x4012c729 0x402a1815
> 0x401eb40d 0x401f7a26 0x401f8af0 0x40207065 0x40206f45 0x40207133
> 0x40206faf 0x402073b6 0x4020747d 0x401f4445 0x401f3344 0x401f3677
> 0x401f441e 0x402079d1 0x401f76e5 0x401f7892 0x40202ea6 0x4012db9a 0x4012dd9d
>
> Using elf file:
> /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>
> 0x4008ace7 is in invoke_abort
> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>
> 151 #endif
>
> 152     while (1) {
>
> 153         if (esp_cpu_in_ocd_debug_mode()) {
>
> 154             __asm__ ("break 0,0");
>
> 155         }
>
> 156         *((int *) 0) = 0;
>
> 157     }
>
> 158 }
>
> 159
>
> 160 void abort()
>
> 0x4008af7d is in abort
> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>
> 166     * don't overwrite that.
>
> 167     */
>
> 168     if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>
> 169         esp_reset_reason_set_hint(ESP_RST_PANIC);
>
> 170     }
>
> 171     invoke_abort();
>
> 172 }
>
> 173
>
> 174
>
> 175 static const char *edesc[] = {
>
> 0x4010badf is in __assert_func
> (../../../.././newlib/libc/stdlib/assert.c:63).
>
> 0x40097d93 is in multi_heap_free
> (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>
> 209         return;
>
> 210     }
>
> 211     multi_heap_internal_lock(heap);
>
> 212
>
> 213     poison_head_t *head = verify_allocated_region(p, true);
>
> 214     assert(head != NULL);
>
> 215
>
> 216     #ifdef SLOW
>
> 217     /* replace everything with FREE_FILL_PATTERN, including the
> poison head/tail */
>
> 218     memset(head, FREE_FILL_PATTERN,
>
> 0x40083ffd is in heap_caps_free
> (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>
> 263         ptr = (void *)dramAddrPtr[-1];
>
> 264     }
>
> 265
>
> 266     heap_t *heap = find_containing_heap(ptr);
>
> 267     assert(heap != NULL && "free() target pointer is outside heap
> areas");
>
> 268     multi_heap_free(heap->heap, ptr);
>
> 269 }
>
> 270
>
> 271 IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>
> 272 {
>
> 0x400845f1 is in _free_r
> (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>
> 37     return heap_caps_malloc_default( size );
>
> 38 }
>
> 39
>
> 40 void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>
> 41 {
>
> 42     heap_caps_free( ptr );
>
> 43 }
>
> 44
>
> 45 void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>
> 46 {
>
> 0x4012c729 is in DukOvmsFree(void*, void*)
> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:442).
>
> 437   return ExternalRamRealloc(ptr, size);
>
> 438   }
>
> 439
>
> 440 void DukOvmsFree(void *udata, void *ptr)
>
> 441   {
>
> 442   free(ptr);
>
> 443   }
>
> 444
>
> 445 void DukOvmsFatalHandler(void *udata, const char *msg)
>
> 446   {
>
> 0x402a1815 is in duk_heap_mem_free (duk_heap_memory.c:406).
>
> 0x401eb40d is in duk__refcount_refzero_hstring (duk_heap_alloc.c:103).
>
> 0x401f7a26 is in duk_heaphdr_refzero (duk_heap_refcount.c:630).
>
> 0x401f8af0 is in duk_pop_2 (duk_api_stack.c:6089).
>
> 0x40207065 is in duk__enc_value (duk_bi_json.c:2240).
>
> 0x40206f45 is in duk__enc_value (duk_bi_json.c:1951).
>
> 1946 in duk_bi_json.c
>
> 0x40207133 is in duk__enc_object (duk_bi_json.c:1885).
>
> 1880 in duk_bi_json.c
>
> 0x40206faf is in duk__enc_value (duk_bi_json.c:2203).
>
> 2198 in duk_bi_json.c
>
> 0x402073b6 is in duk_bi_json_stringify_helper (duk_bi_json.c:3191).
>
> 3186 in duk_bi_json.c
>
> 0x4020747d is in duk_bi_duktape_object_enc (duk_bi_duktape.c:96).
>
> 0x401f4445 is in duk__handle_call_raw (duk_js_call.c:2276).
>
> 0x401f3344 is in duk__js_execute_bytecode_inner (duk_js_call.c:2422).
>
> 2417 in duk_js_call.c
>
> 0x401f3677 is in duk_js_execute_bytecode (duk_js_executor.c:2956).
>
> 0x401f441e is in duk__handle_call_raw (duk_js_call.c:2246).
>
> 0x402079d1 is in duk__pcall_method_raw (duk_js_call.c:2422).
>
> 2417 in duk_js_call.c
>
> 0x401f76e5 is in duk_handle_safe_call (duk_js_call.c:2475).
>
> 2470 in duk_js_call.c
>
> 0x401f7892 is in duk_safe_call (duk_api_call.c:318).
>
> 0x40202ea6 is in duk_pcall_method (duk_api_call.c:242).
>
> 237 in duk_api_call.c
>
> 0x4012db9a is in OvmsScripts::DukTapeTask()
> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:2273).
>
> 2268             duk_get_global_string(m_dukctx, "PubSub");
>
> 2269             duk_get_prop_string(m_dukctx, -1, "publish");
>
> 2270             duk_dup(m_dukctx, -2);  /* this binding = process */
>
> 2271             duk_push_string(m_dukctx, msg.body.dt_event.name);
>
> 2272             duk_push_string(m_dukctx, "");
>
> 2273             if (duk_pcall_method(m_dukctx, 2) != 0)
>
> 2274               {
>
> 2275               DukOvmsErrorHandler(m_dukctx, -1);
>
> 2276               }
>
> 2277             duk_pop_2(m_dukctx);
>
> 0x4012dd9d is in DukTapeLaunchTask(void*)
> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_script/src/ovms_script.cpp:427).
>
> 422
>
> 423 void DukTapeLaunchTask(void *pvParameters)
>
> 424   {
>
> 425   OvmsScripts* me = (OvmsScripts*)pvParameters;
>
> 426
>
> 427   me->DukTapeTask();
>
> 428   }
>
> 429
>
> 430 void* DukOvmsAlloc(void *udata, duk_size_t size)
>
> 431   {
>
>
> Michael Balzer <dexter at expeedo.de> ezt ?rta (id?pont: 2020. j?n. 5., P,
> 21:43):
>
>> See previous posts on this, you also need the fixed toolchain:
>> https://github.com/espressif/esp-idf/issues/2892#issuecomment-501106283
>>
>> Regards,
>> Michael
>>
>>
>> Am 05.06.20 um 20:04 schrieb Tam?s Kov?cs:
>>
>> i think i don't run spiram fix. How can i use it. I must check out
>> branch "spiram-fix-test"  to run spiram fix?
>>
>> Michael Balzer <dexter at expeedo.de> ezt ?rta (id?pont: 2020. j?n. 5., P,
>> 6:58):
>>
>>> Tam?s,
>>>
>>> that doesn't need to be related to the pushover code. Do you run the
>>> spiram fix? I had this kind of heap corruption crashes frequently on builds
>>> without the spiram fix but not once with the fix.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> Am 05.06.20 um 05:29 schrieb Tam?s Kov?cs:
>>>
>>> Some day's ago i enabled Pushover notifications and i get some crash
>>> after that.
>>>
>>> The crash backtrase is:
>>> Backtrace: 0x4008b75f 0x4008b9f9 0x4010b253 0x40098c5f 0x40084361
>>> 0x40084945 0x4000bec7 0x401c1181 0x400f01e1 0x400f0dbb 0x400f0db4
>>> 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109 0x401550da 0x400f3545
>>> 0x400f375e 0x400f37d5 0x400f37e5
>>> a2l output is:
>>>
>>> kommykt at MacBook-Air OVMS.V3 % a2l 0x4008b75f 0x4008b9f9 0x4010b253
>>> 0x40098c5f 0x40084361 0x40084945 0x4000bec7 0x401c1181 0x400f01e1
>>> 0x400f0dbb 0x400f0db4 0x400f0db4 0x400f0db4 0x400f0db4 0x40156109
>>> 0x401550da 0x400f3545 0x400f375e 0x400f37d5 0x400f37e5
>>>
>>> Using elf file:
>>> /Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
>>>
>>>
>>> 0x4008b75f is in invoke_abort
>>> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:156).
>>>
>>> 151 #endif
>>>
>>> 152     while (1) {
>>>
>>> 153         if (esp_cpu_in_ocd_debug_mode()) {
>>>
>>> 154             __asm__ ("break 0,0");
>>>
>>> 155         }
>>>
>>> 156         *((int *) 0) = 0;
>>>
>>> 157     }
>>>
>>> 158 }
>>>
>>> 159
>>>
>>> 160 void abort()
>>>
>>>
>>> 0x4008b9f9 is in abort
>>> (/Users/kommykt/esp/esp-idf/components/esp32/panic.c:171).
>>>
>>> 166     * don't overwrite that.
>>>
>>> 167     */
>>>
>>> 168     if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) {
>>>
>>> 169         esp_reset_reason_set_hint(ESP_RST_PANIC);
>>>
>>> 170     }
>>>
>>> 171     invoke_abort();
>>>
>>> 172 }
>>>
>>> 173
>>>
>>> 174
>>>
>>> 175 static const char *edesc[] = {
>>>
>>>
>>> 0x4010b253 is in __assert_func
>>> (../../../.././newlib/libc/stdlib/assert.c:63).
>>>
>>>
>>> 0x40098c5f is in multi_heap_free
>>> (/Users/kommykt/esp/esp-idf/components/heap/multi_heap_poisoning.c:214).
>>>
>>> 209         return;
>>>
>>> 210     }
>>>
>>> 211     multi_heap_internal_lock(heap);
>>>
>>> 212
>>>
>>> 213     poison_head_t *head = verify_allocated_region(p, true);
>>>
>>> 214     assert(head != NULL);
>>>
>>> 215
>>>
>>> 216     #ifdef SLOW
>>>
>>> 217     /* replace everything with FREE_FILL_PATTERN, including the
>>> poison head/tail */
>>>
>>> 218     memset(head, FREE_FILL_PATTERN,
>>>
>>>
>>> 0x40084361 is in heap_caps_free
>>> (/Users/kommykt/esp/esp-idf/components/heap/heap_caps.c:268).
>>>
>>> 263         ptr = (void *)dramAddrPtr[-1];
>>>
>>> 264     }
>>>
>>> 265
>>>
>>> 266     heap_t *heap = find_containing_heap(ptr);
>>>
>>> 267     assert(heap != NULL && "free() target pointer is outside heap
>>> areas");
>>>
>>> 268     multi_heap_free(heap->heap, ptr);
>>>
>>> 269 }
>>>
>>> 270
>>>
>>> 271 IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps)
>>>
>>> 272 {
>>>
>>>
>>> 0x40084945 is in _free_r
>>> (/Users/kommykt/esp/esp-idf/components/newlib/syscalls.c:42).
>>>
>>> 37     return heap_caps_malloc_default( size );
>>>
>>> 38 }
>>>
>>> 39
>>>
>>> 40 void IRAM_ATTR _free_r(struct _reent *r, void* ptr)
>>>
>>> 41 {
>>>
>>> 42     heap_caps_free( ptr );
>>>
>>> 43 }
>>>
>>> 44
>>>
>>> 45 void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size)
>>>
>>> 46 {
>>>
>>>
>>> 0x401c1181 is in operator delete(void*)
>>> (/Volumes/build/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/del_op.cc:46).
>>>
>>>
>>> 0x400f01e1 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >,
>>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >
>>> >::_M_drop_node(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >*)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110).
>>>
>>> 105       }
>>>
>>> 106
>>>
>>> 107       // __p is not permitted to be a null pointer.
>>>
>>> 108       void
>>>
>>> 109       deallocate(pointer __p, size_type)
>>>
>>> 110       { ::operator delete(__p); }
>>>
>>> 111
>>>
>>> 112       size_type
>>>
>>> 113       max_size() const _GLIBCXX_USE_NOEXCEPT
>>>
>>> 114       { return size_t(-1) / sizeof(_Tp); }
>>>
>>>
>>> 0x400f0dbb is in std::_Rb_tree<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >,
>>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >
>>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >*)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1614).
>>>
>>> 1609       // Erase without rebalancing.
>>>
>>> 1610       while (__x != 0)
>>>
>>> 1611 {
>>>
>>> 1612   _M_erase(_S_right(__x));
>>>
>>> 1613   _Link_type __y = _S_left(__x);
>>>
>>> 1614   _M_drop_node(__x);
>>>
>>> 1615   __x = __y;
>>>
>>> 1616 }
>>>
>>> 1617     }
>>>
>>> 1618
>>>
>>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >,
>>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >
>>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >*)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>> 1607     _M_erase(_Link_type __x)
>>>
>>> 1608     {
>>>
>>> 1609       // Erase without rebalancing.
>>>
>>> 1610       while (__x != 0)
>>>
>>> 1611 {
>>>
>>> 1612   _M_erase(_S_right(__x));
>>>
>>> 1613   _Link_type __y = _S_left(__x);
>>>
>>> 1614   _M_drop_node(__x);
>>>
>>> 1615   __x = __y;
>>>
>>> 1616 }
>>>
>>>
>>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >,
>>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >
>>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >*)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>> 1607     _M_erase(_Link_type __x)
>>>
>>> 1608     {
>>>
>>> 1609       // Erase without rebalancing.
>>>
>>> 1610       while (__x != 0)
>>>
>>> 1611 {
>>>
>>> 1612   _M_erase(_S_right(__x));
>>>
>>> 1613   _Link_type __y = _S_left(__x);
>>>
>>> 1614   _M_drop_node(__x);
>>>
>>> 1615   __x = __y;
>>>
>>> 1616 }
>>>
>>>
>>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >,
>>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >
>>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >*)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>> 1607     _M_erase(_Link_type __x)
>>>
>>> 1608     {
>>>
>>> 1609       // Erase without rebalancing.
>>>
>>> 1610       while (__x != 0)
>>>
>>> 1611 {
>>>
>>> 1612   _M_erase(_S_right(__x));
>>>
>>> 1613   _Link_type __y = _S_left(__x);
>>>
>>> 1614   _M_drop_node(__x);
>>>
>>> 1615   __x = __y;
>>>
>>> 1616 }
>>>
>>>
>>> 0x400f0db4 is in std::_Rb_tree<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >,
>>> std::pair<std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > const, std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::_Select1st<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > >,
>>> std::allocator<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >
>>> >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > const,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > > >*)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1612).
>>>
>>> 1607     _M_erase(_Link_type __x)
>>>
>>> 1608     {
>>>
>>> 1609       // Erase without rebalancing.
>>>
>>> 1610       while (__x != 0)
>>>
>>> 1611 {
>>>
>>> 1612   _M_erase(_S_right(__x));
>>>
>>> 1613   _Link_type __y = _S_left(__x);
>>>
>>> 1614   _M_drop_node(__x);
>>>
>>> 1615   __x = __y;
>>>
>>> 1616 }
>>>
>>>
>>> 0x40156109 is in
>>> Pushover::EventListener(std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >, void*)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:858).
>>>
>>> 853
>>>
>>> 854       _Rb_tree(_Rb_tree&& __x, _Node_allocator&& __a);
>>>
>>> 855 #endif
>>>
>>> 856
>>>
>>> 857       ~_Rb_tree() _GLIBCXX_NOEXCEPT
>>>
>>> 858       { _M_erase(_M_begin()); }
>>>
>>> 859
>>>
>>> 860       _Rb_tree&
>>>
>>> 861       operator=(const _Rb_tree& __x);
>>>
>>> 862
>>>
>>> 0x401550da is in std::_Function_handler<void
>>> (std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> >, void*), std::_Bind<std::_Mem_fn<void
>>> (Pushover::*)(std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> >, void*)> (Pushover*, std::_Placeholder<1>,
>>> std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&,
>>> std::__cxx11::basic_string<char, std::char_traits<char>,
>>> std::allocator<char> >&&, void*&&)
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600).
>>>
>>> 595       template<typename... _Args, typename _Req
>>>
>>> 596               = _Require<typename _Traits::__lvalue,
>>>
>>> 597                           _CheckArgs<_Pack<_Args...>>>>
>>>
>>> 598 result_type
>>>
>>> 599 operator()(_Class* __object, _Args&&... __args) const
>>>
>>> 600 { return (__object->*_M_pmf)(std::forward<_Args>(__args)...); }
>>>
>>> 601
>>>
>>> 602       // Handle smart pointers, references and pointers to derived
>>>
>>> 603       template<typename _Tp, typename... _Args, typename _Req
>>>
>>> 604               = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*,
>>> _Tp>,
>>>
>>>
>>> 0x400f3545 is in std::function<void (std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >,
>>> void*)>::operator()(std::__cxx11::basic_string<char,
>>> std::char_traits<char>, std::allocator<char> >, void*) const
>>> (/Users/kommykt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271).
>>>
>>> 2266     function<_Res(_ArgTypes...)>::
>>>
>>> 2267     operator()(_ArgTypes... __args) const
>>>
>>> 2268     {
>>>
>>> 2269       if (_M_empty())
>>>
>>> 2270 __throw_bad_function_call();
>>>
>>> 2271       return _M_invoker(_M_functor,
>>> std::forward<_ArgTypes>(__args)...);
>>>
>>> 2272     }
>>>
>>> 2273
>>>
>>> 2274 #if __cpp_rtti
>>>
>>> 2275   template<typename _Res, typename... _ArgTypes>
>>>
>>>
>>> 0x400f375e is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*)
>>> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:234).
>>>
>>> 229       {
>>>
>>> 230       for (EventCallbackList::iterator itc=el->begin();
>>> itc!=el->end(); ++itc)
>>>
>>> 231         {
>>>
>>> 232         m_current_started = monotonictime;
>>>
>>> 233         m_current_callback = *itc;
>>>
>>> 234         m_current_callback->m_callback(m_current_event,
>>> msg->body.signal.data);
>>>
>>> 235         m_current_callback = NULL;
>>>
>>> 236         }
>>>
>>> 237       }
>>>
>>> 238     }
>>>
>>>
>>> 0x400f37d5 is in OvmsEvents::EventTask()
>>> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:185).
>>>
>>> 180       switch(msg.type)
>>>
>>> 181         {
>>>
>>> 182         case EVENT_none:
>>>
>>> 183           break;
>>>
>>> 184         case EVENT_signal:
>>>
>>> 185           HandleQueueSignalEvent(&msg);
>>>
>>> 186           break;
>>>
>>> 187         default:
>>>
>>> 188           break;
>>>
>>> 189         }
>>>
>>>
>>> 0x400f37e5 is in EventLaunchTask(void*)
>>> (/Users/kommykt/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_events.cpp:56).
>>>
>>> 51
>>>
>>> 52 void EventLaunchTask(void *pvParameters)
>>>
>>> 53   {
>>>
>>> 54   OvmsEvents* me = (OvmsEvents*)pvParameters;
>>>
>>> 55
>>>
>>> 56   me->EventTask();
>>>
>>> 57   }
>>>
>>> 58
>>>
>>> 59 void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand*
>>> cmd, int argc, const char* const* argv)
>>>
>>> 60   {
>>>
>>> --
>>> ?dv?zlettel:
>>> Kov?cs Tam?s
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>> --
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>
>>
>> --
>> ?dv?zlettel:
>> Kov?cs Tam?s
>>
>>
>> _______________________________________________
>> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>> --
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>
>
> --
> ?dv?zlettel:
> Kov?cs Tam?s
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>


-- 
?dv?zlettel:
Kov?cs Tam?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200614/db16dd53/attachment.htm>

From leres at xse.com  Sun Jun 14 23:21:27 2020
From: leres at xse.com (Craig Leres)
Date: Sun, 14 Jun 2020 08:21:27 -0700
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
 <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
Message-ID: <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>

On 2020-06-13 08:31, Michael Balzer wrote:
> How about adding an array or set metric like "v.ext" or "v.tech", for
> defined technology codes. A tag present in the metric means the
> additional metrics, commands & configs for that technology are available.

My goal is to make it possible for the app to depict soc with something
other than a battery graphic when the energy source is not a battery.
How about v.tech with "battery" and "other" as the initial two possible
values?

		Craig


From chris at arachnon.de  Mon Jun 15 00:59:33 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Sun, 14 Jun 2020 18:59:33 +0200
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
 <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
 <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>
Message-ID: <1592153973.13853.18.camel@arachnon.de>

Thank you for considering my thoughts.
I believe it is a good idea to use a v.tech variable and not using gas
or gazoline. That gives OVMS enough flexibility and is also a?(little)
statement.
I'm also looking forward to rocket propulsion add ons :-))
Greetinx
Chris

Am Sonntag, den 14.06.2020, 08:21 -0700 schrieb Craig Leres:
> On 2020-06-13 08:31, Michael Balzer wrote:
> > How about adding an array or set metric like "v.ext" or "v.tech",
> > for
> > defined technology codes. A tag present in the metric means the
> > additional metrics, commands & configs for that technology are
> > available.
> 
> My goal is to make it possible for the app to depict soc with
> something
> other than a battery graphic when the energy source is not a battery.
> How about v.tech with "battery" and "other" as the initial two
> possible
> values?
> 
> 		Craig
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200614/29d52cdb/attachment.htm>

From dexter at expeedo.de  Mon Jun 15 02:46:01 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Sun, 14 Jun 2020 20:46:01 +0200
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <1592153973.13853.18.camel@arachnon.de>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
 <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
 <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>
 <1592153973.13853.18.camel@arachnon.de>
Message-ID: <3ea9f7cc-82d3-3a14-30f3-1dd9d8505894@expeedo.de>

Craig,

I strictly vote against re-interpretation of the SOC metric. Where
metrics have clear semantics we should not make them dependent on some
context.

A battery is not a fuel tank, and vehicles may have both. "v.b." is the
namespace "vehicle battery" and shall not be populated with non-battery
metrics.

That's what I meant by adding technology specific metrics: if the
vehicle has a fuel tank, additional standard metrics describing that
fuel tank shall be present.

Fuel tank specific metrics might e.g. get the namespace "v.ft.", ICE
engine specific metrics might get "v.ice.", fuel cell metrics "v.fc.",
rocket thruster metrics "v.rt." ? you get the idea.

Make a proposition for the metrics sets you need. Try to define them as
generalized as possible.

That will probably include duplicates of some metrics, like the ranges &
consumption. That's necessary to be able to describe a hybrid, and some
units among those will also need to be different (e.g. consumption in
litres / m? per km).

Regards,
Michael


Am 14.06.20 um 18:59 schrieb Chris van der Meijden:
> Thank you for considering my thoughts.
>
> I believe it is a good idea to use a v.tech variable and not using gas
> or gazoline. That gives OVMS enough flexibility and is also a?(little)
> statement.
>
> I'm also looking forward to rocket propulsion add ons :-))
>
> Greetinx
>
> Chris
>
>
> Am Sonntag, den 14.06.2020, 08:21 -0700 schrieb Craig Leres:
>> On 2020-06-13 08:31, Michael Balzer wrote:
>>> How about adding an array or set metric like "v.ext" or "v.tech",
>>> for defined technology codes. A tag present in the metric means the
>>> additional metrics, commands & configs for that technology are
>>> available. 
>>
>>
>> My goal is to make it possible for the app to depict soc with something
>> other than a battery graphic when the energy source is not a battery.
>> How about v.tech with "battery" and "other" as the initial two possible
>> values?
>>
>> 		Craig
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200614/80aef29a/attachment.htm>

From mark at webb-johnson.net  Mon Jun 15 10:27:52 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Mon, 15 Jun 2020 10:27:52 +0800
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <3ea9f7cc-82d3-3a14-30f3-1dd9d8505894@expeedo.de>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
 <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
 <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>
 <1592153973.13853.18.camel@arachnon.de>
 <3ea9f7cc-82d3-3a14-30f3-1dd9d8505894@expeedo.de>
Message-ID: <F24DA1A4-AB81-4AB7-A689-A638C32484DC@webb-johnson.net>


I think the core principle of the ?Open? in ?Open Vehicle Monitoring System? is that we should not restrict any uses, no matter our personal opinions.

Regarding the metrics themselves, I agree with Michael. The v.b namespace is intended for vehicle battery metrics. Perhaps we can simply add another namespace ?v.ice? for internal combustion engine fuels?

Note that OBDII defines standard fuel type codings (service 01 PID 51):

Value	Description
0	Not available
1	Gasoline
2	Methanol
3	Ethanol
4	Diesel
5	LPG <https://en.wikipedia.org/wiki/Liquefied_petroleum_gas>
6	CNG <https://en.wikipedia.org/wiki/Compressed_natural_gas>
7	Propane
8	Electric
9	Bifuel <https://en.wikipedia.org/wiki/Bi-fuel_vehicle> running Gasoline
10	Bifuel running Methanol
11	Bifuel running Ethanol
12	Bifuel running LPG
13	Bifuel running CNG
14	Bifuel running Propane
15	Bifuel running Electricity
16	Bifuel running electric and combustion engine
17	Hybrid gasoline
18	Hybrid Ethanol
19	Hybrid Diesel
20	Hybrid Electric
21	Hybrid running electric and combustion engine
22	Hybrid Regenerative
23	Bifuel running diesel

A ?v.fueltype? metric makes sense for this. Perhaps just use the full OBDII list (which supports hybrids). For ICE vehicles, keeping to standard OBDII PIDs is probably the simplest and most standardised approach. So, ?v.ice.tank.level?, or something like that (OBDII PID 0x2f).

Regarding the Apps support for this (and other things), that is something I am working on and trying to prototype. I will eMail separately regarding this.

Regards, Mark.

> On 15 Jun 2020, at 2:46 AM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> Craig,
> 
> I strictly vote against re-interpretation of the SOC metric. Where metrics have clear semantics we should not make them dependent on some context.
> 
> A battery is not a fuel tank, and vehicles may have both. "v.b." is the namespace "vehicle battery" and shall not be populated with non-battery metrics.
> 
> That's what I meant by adding technology specific metrics: if the vehicle has a fuel tank, additional standard metrics describing that fuel tank shall be present.
> 
> Fuel tank specific metrics might e.g. get the namespace "v.ft.", ICE engine specific metrics might get "v.ice.", fuel cell metrics "v.fc.", rocket thruster metrics "v.rt." ? you get the idea.
> 
> Make a proposition for the metrics sets you need. Try to define them as generalized as possible.
> 
> That will probably include duplicates of some metrics, like the ranges & consumption. That's necessary to be able to describe a hybrid, and some units among those will also need to be different (e.g. consumption in litres / m? per km).
> 
> Regards,
> Michael
> 
> 
> Am 14.06.20 um 18:59 schrieb Chris van der Meijden:
>> Thank you for considering my thoughts.
>> 
>> I believe it is a good idea to use a v.tech variable and not using gas or gazoline. That gives OVMS enough flexibility and is also a (little) statement.
>> 
>> I'm also looking forward to rocket propulsion add ons :-))
>> 
>> Greetinx
>> 
>> Chris
>> 
>> 
>> Am Sonntag, den 14.06.2020, 08:21 -0700 schrieb Craig Leres:
>>> On 2020-06-13 08:31, Michael Balzer wrote:
>>>> 
>>>> How about adding an array or set metric like "v.ext" or "v.tech", for
>>>> defined technology codes. A tag present in the metric means the
>>>> additional metrics, commands & configs for that technology are available.
>>> 
>>> 
>>> My goal is to make it possible for the app to depict soc with something
>>> other than a battery graphic when the energy source is not a battery.
>>> How about v.tech with "battery" and "other" as the initial two possible
>>> values?
>>> 
>>> 		Craig
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> 
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/19f74814/attachment.htm>

From mark at webb-johnson.net  Mon Jun 15 13:55:10 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Mon, 15 Jun 2020 13:55:10 +0800
Subject: [Ovmsdev] File logging task
In-Reply-To: <1bc35602-d032-2d09-07b8-650a7eb3e234@expeedo.de>
References: <6eac2ac1-4835-7a73-51f3-af003a43eae6@expeedo.de>
 <1bc35602-d032-2d09-07b8-650a7eb3e234@expeedo.de>
Message-ID: <AC2DA22E-F65F-4D75-AA65-5C12C829B0A4@webb-johnson.net>


Do you think that the overhead of the logging framework is impacting performance of things like SSH/SCP and SIMCOM async? Kind of related to the issue I raised about the infinite loop caused by debug logging on the web console and ssh (when those are already receiving log monitor output) - logging the logging.

It seems using ESP_EARLY would avoid this? Or a cleanup to move such logging to verbose level, other stuff at debug level, and a restriction on web client and ssh to never log monitor above debug level?

Regards, Mark.

> On 13 Jun 2020, at 9:30 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> I've added a simple workaround for this issue to our esp-idf fork: https://github.com/openvehicles/esp-idf/commit/9024cd38ecbc78a46ed16b79d63f57812e72b123 <https://github.com/openvehicles/esp-idf/commit/9024cd38ecbc78a46ed16b79d63f57812e72b123>
> 
> The workaround checks if logging is done from the timer context, if so reduces the semaphore wait time to zero, thus avoiding blocking.
> 
> That should eliminate any timer consistency issues arising from logging in timer callbacks. The disadvantage is a higher chance of such log messages getting dropped.
> 
> Regards,
> Michael
> 
> 
> Am 05.11.19 um 21:45 schrieb Michael Balzer:
>> Everyone,
>> 
>> I've pushed the long due refactoring of the file logging into a dedicated task. This removes most of the delays involved in file logging, as the fsync() and log cycling now is done in the logging task and no longer blocks overall log message processing.
>> 
>> I stumbled upon a bad thing (tm) though we need to resolve with logging: the esp-idf logging generally involves a semaphore wait of max 10 ms (!). I wasn't aware of this because I didn't look into the source before, there also is no warning about this in the esp-idf documentation (https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/log.html <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/log.html>), so I guess I'm not the only one being taken by surprise here.
>> 
>> // Maximum time to wait for the mutex in a logging statement.
>> #define MAX_MUTEX_WAIT_MS 10
>> #define MAX_MUTEX_WAIT_TICKS ((MAX_MUTEX_WAIT_MS + portTICK_PERIOD_MS - 1) / portTICK_PERIOD_MS)
>> ?
>> void IRAM_ATTR esp_log_write(esp_log_level_t level,
>>         const char* tag,
>>         const char* format, ...)
>> {
>>     if (!s_log_mutex) {
>>         s_log_mutex = xSemaphoreCreateMutex();
>>     }
>>     if (xSemaphoreTake(s_log_mutex, MAX_MUTEX_WAIT_TICKS) == pdFALSE) {
>>         return;
>>     }
>> ?
>> 
>> That semaphore is needed to secure the log level tag cache against parallel access, so it also affects log messages of currently disabled tags and/or levels.
>> 
>> This means we must not use the standard logging from timer callbacks, at no verbosity level. But we do, partially caused by my own code serving as a bad example I assume -- sorry.
>> 
>> But I've not only found direct log calls in most vehicle timer callbacks, there also are some hidden ones from calling the framework, for example marking a notification as read can produce a log output from Cleanup() if tracing is enabled.
>> 
>> We need to change this short to mid term. This may be the cause of those strange timer overflow issues we've seen occasionally. It also means every debug or verbose log output currently in the code involves potentially multiple semaphore waits, that's for example the case for all hex dumps logged by the SIMCOM module.
>> 
>> Our primary option is to remove all log calls from all low level framework functions and timer callbacks.
>> 
>> A simple & quick workaround could be to extend the ESP_LOGx macros to check if they are executed in the timer task context, if so suppress the message or call the ESP_EARLY log function instead. That will hide these log messages from the logging framework though, if using the _EARLY_ variant they only will be sent to the USB port.
>> 
>> For a better solution I thought about adding a dedicated queue & task for the initial log submission as well. That will need quite some rework to the esp-idf (no changes for this in the current master) but would allow to continue logging as we do now. Cons: queue submission involves some overhead & RAM, printf format expansion needs to be done before the tag/level check, messages may need to be dropped if the task starves or RAM gets tight, log output to consoles will depend on a task as well.
>> 
>> Opinions / better ideas?
>> 
>> Regards,
>> Michael
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> 
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/d6cd8211/attachment.htm>

From mark at webb-johnson.net  Mon Jun 15 15:00:56 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Mon, 15 Jun 2020 15:00:56 +0800
Subject: [Ovmsdev] Cross Platform Unified App
Message-ID: <0DB4B4E5-CA50-4B98-8469-BDD171252B42@webb-johnson.net>


As you may know, I?ve been working for some time on the design of a cross platform unified App for OVMS. Here are my thoughts.

I think our approach of the ?virtual vehicle?, represented by a hash/set of metric->value, works well. We have been successful in providing common vehicle metrics for more than a dozen different types of electric vehicle, plus a bunch of other generic types. Overall, I think this is the correct approach, and lends itself very well to the IoT MQTT way of doing things.

Maintaining two separate Apps on two different platforms has been difficult, and the features and functionality are diverging too much.

The v2 protocol is too limiting (especially for new vehicle types, and custom metrics).

I like the idea of providing a ?templated? approach to the displays in the Apps. We design templates to pick metrics, along with other assets, and display their current values updated in real time.

By leveraging the ?virtual vehicle? model, we can also introduce the concept of vehicle sources. At the moment, we are limited to just one vehicle data source - OVMS protocol v2, and to some extent the apps already convert the incoming v2 data into a hard-coded set of metrics, with hard-coded display layouts. The purpose of these vehicle sources is to login to a remote server, retrieve the vehicle data, and store it as the standardised metrics, in the standardised ?virtual vehicle?. Example sources could be OVMS protocol v2, OVMS protocol v3 (MQTT), Tesla API, Carwings API, direct bluetooth to an OVMS module, etc. We could virtualise these protocols, with a common interface.

So, my proposal is:

We develop a single universal App, coded in a ?free? open environment. I have looked at Xamarin and Phonegap (vue-js, and a bunch of alternatives in common use nowadays). My current preference is vue-js, as it seems that javascript and html lend themselves best to the templated display approach - it is trivial to dynamically load this content. That, plus the environment is truly free and well understood by a huge developer community. However, no decision has been made and I am open to suggestions.

The App implements a virtual protocol system. Each virtual protocol talks a particular backend API for a particular account. The virtual protocol then publishes vehicles for the user to choose from. Initially we would write an OVMS v2 protocol implementation, but others (as previously listed) should be relatively easy to implement.

The App implements a virtual vehicle system. Each virtual protocol converts the incoming vehicle data to the virtual vehicle metrics. We can base this simply on the OVMS v3 standardised metrics, but custom metrics also need to be supported. Commands to be sent to the vehicle can also be implemented in a similar way. The OVMS v3 MQTT protocol would be a 1-to-1 mapping here, for example.

The App displays are implemented via a templating system, with templates provided per vehicle type and per screen type (phone, tablet, desktop, etc). The user can customise these templates, using either named virtual vehicle metrics or other assets (pictures, buttons for commands, etc).

I feel that this approach provides an excellent balance. It allows for comprehensive support and flexibility of display for each vehicle type, without complicating the implementation. It also allows owners of more than one type of vehicle (perhaps not all supported by OVMS) to use a single App to monitor and control.

I am happy to build the framework for this, but would much prefer others to come on board to assist.

Any thoughts or suggestion are most welcome.

Regards, Mark.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/18878057/attachment.htm>

From chris at arachnon.de  Mon Jun 15 15:13:00 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Mon, 15 Jun 2020 09:13:00 +0200
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <F24DA1A4-AB81-4AB7-A689-A638C32484DC@webb-johnson.net>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
 <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
 <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>
 <1592153973.13853.18.camel@arachnon.de>
 <3ea9f7cc-82d3-3a14-30f3-1dd9d8505894@expeedo.de>
 <F24DA1A4-AB81-4AB7-A689-A638C32484DC@webb-johnson.net>
Message-ID: <1592205180.2530.1.camel@arachnon.de>

Sorry, I disagree.
I think "Open" stands for open source and open source should also mean
being open to discussions. And discussions involve personal opinions.
IMHO supporting internal combustion engines in OVMS is a bad idea in
times of climate change. It is the wrong signal if we do so.?
I do not??want to "over discuss" this, but it is important enough for
me suggest not to implement support for ICE engines.
Greetinx
Chris

Am Montag, den 15.06.2020, 10:27 +0800 schrieb Mark Webb-Johnson:
> I think the core principle of the ?Open? in ?Open Vehicle Monitoring
> System? is that we should not restrict any uses, no matter our
> personal opinions.
> Regarding the metrics themselves, I agree with Michael. The v.b
> namespace is intended for vehicle battery metrics. Perhaps we can
> simply add another namespace ?v.ice? for internal combustion engine
> fuels?
> 
> Note that OBDII defines standard fuel type codings (service 01 PID
> 51):
> 
> ValueDescription0Not
> available1Gasoline2Methanol3Ethanol4Diesel5LPG6CNG7Propane8Electric9B
> ifuel?running Gasoline10Bifuel running Methanol11Bifuel running
> Ethanol12Bifuel running LPG13Bifuel running CNG14Bifuel running
> Propane15Bifuel running Electricity16Bifuel running electric and
> combustion engine17Hybrid gasoline18Hybrid Ethanol19Hybrid
> Diesel20Hybrid Electric21Hybrid running electric and combustion
> engine22Hybrid Regenerative23Bifuel running diesel
> A ?v.fueltype? metric makes sense for this. Perhaps just use the full
> OBDII list (which supports hybrids). For ICE vehicles, keeping to
> standard OBDII PIDs is probably the simplest and most standardised
> approach. So, ?v.ice.tank.level?, or something like that (OBDII PID
> 0x2f).
> 
> Regarding the Apps support for this (and other things), that is
> something I am working on and trying to prototype. I will eMail
> separately regarding this.
> 
> Regards, Mark.
> 
> > On 15 Jun 2020, at 2:46 AM, Michael Balzer <dexter at expeedo.de>
> > wrote:
> > 
> > 
> > ??
> > ????
> > ??
> > ??
> > ????Craig,
> > 
> > ????
> > 
> > ????I strictly vote against re-interpretation of the SOC metric.
> > Where
> > ????metrics have clear semantics we should not make them dependent
> > on
> > ????some context.
> > 
> > ????
> > 
> > ????A battery is not a fuel tank, and vehicles may have both.
> > "v.b." is
> > ????the namespace "vehicle battery" and shall not be populated with
> > ????non-battery metrics.
> > 
> > ????
> > 
> > ????That's what I meant by adding technology specific metrics: if
> > the
> > ????vehicle has a fuel tank, additional standard metrics describing
> > that
> > ????fuel tank shall be present.
> > 
> > ????
> > 
> > ????Fuel tank specific metrics might e.g. get the namespace
> > "v.ft.", ICE
> > ????engine specific metrics might get "v.ice.", fuel cell metrics
> > ????"v.fc.", rocket thruster metrics "v.rt." ? you get the idea.
> > 
> > ????
> > 
> > ????Make a proposition for the metrics sets you need. Try to define
> > them
> > ????as generalized as possible.
> > 
> > ????
> > 
> > ????That will probably include duplicates of some metrics, like the
> > ????ranges & consumption. That's necessary to be able to describe a
> > ????hybrid, and some units among those will also need to be
> > different
> > ????(e.g. consumption in litres / m? per km).
> > 
> > ????
> > 
> > ????Regards,
> > 
> > ????Michael
> > 
> > ????
> > 
> > ????
> > 
> > ????Am 14.06.20 um 18:59 schrieb Chris van
> > ??????der Meijden:
> > 
> > ????
> > ????
> > > ??????
> > > ??????Thank you for considering my thoughts.
> > > ??????
> > > 
> > > ??????
> > > ??????I believe it is a good idea to use a v.tech variable and
> > > not
> > > ????????using gas or gazoline. That gives OVMS enough flexibility
> > > and is
> > > ????????also a?(little) statement.
> > > ??????
> > > 
> > > ??????
> > > ??????I'm also looking forward to rocket propulsion add ons :-))
> > > ??????
> > > 
> > > ??????
> > > ??????Greetinx
> > > ??????
> > > 
> > > ??????
> > > ??????Chris
> > > ??????
> > > 
> > > ??????
> > > ??????
> > > 
> > > ??????
> > > ??????Am Sonntag, den 14.06.2020, 08:21 -0700 schrieb Craig
> > > Leres:
> > > ??????
> > > > ????????On 2020-06-13 08:31, Michael Balzer wrote:
> > > > > How about adding an array or set metric like "v.ext" or
> > > > > "v.tech", for
> > > > > defined technology codes. A tag present in the metric means
> > > > > the
> > > > > additional metrics, commands & configs for that technology
> > > > > are available.
> > > > 
> > > > My goal is to make it possible for the app to depict soc with
> > > > something
> > > > other than a battery graphic when the energy source is not a
> > > > battery.
> > > > How about v.tech with "battery" and "other" as the initial two
> > > > possible
> > > > values?
> > > > 
> > > > 		Craig
> > > > _______________________________________________
> > > > OvmsDev mailing list
> > > > OvmsDev at lists.openvehicles.com
> > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > 
> > > > ??????
> > > 
> > > ????
> > 
> > ????
> > 
> > ????
> > ??
> > 
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/7026aa77/attachment.htm>

From mark at webb-johnson.net  Mon Jun 15 15:56:46 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Mon, 15 Jun 2020 15:56:46 +0800
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <1592205180.2530.1.camel@arachnon.de>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
 <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
 <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>
 <1592153973.13853.18.camel@arachnon.de>
 <3ea9f7cc-82d3-3a14-30f3-1dd9d8505894@expeedo.de>
 <F24DA1A4-AB81-4AB7-A689-A638C32484DC@webb-johnson.net>
 <1592205180.2530.1.camel@arachnon.de>
Message-ID: <D6C82A11-A444-41FF-8E52-4041667EC3CB@webb-johnson.net>

Hmmm...

It is hard to decouple ?open? from ?free?, particularly given the roots of the open source movement. But at it?s core is the concept of openness and freedom in that I (or we) should not be telling anyone what they can or cannot do with this project. The user is free to do with it what they will, and our license explicitly states that.

So, given that we cannot control what is done with the project, or what type of vehicle it is used in, the decision is whether we allow the ?v.b? battery namespace to be ?trampled on? with ICE metrics? I think that the suggested v.ice namespace is a reasonable compromise.

Regards, Mark.

P.S. My personal opinion is that I drive electric cars, prefer them, and advocate for them every day. I even co-founded a charity here in HK to support and promote them.

> On 15 Jun 2020, at 3:13 PM, Chris van der Meijden <chris at arachnon.de> wrote:
> 
> Sorry, I disagree.
> 
> I think "Open" stands for open source and open source should also mean being open to discussions. And discussions involve personal opinions.
> 
> IMHO supporting internal combustion engines in OVMS is a bad idea in times of climate change. It is the wrong signal if we do so.
> 
> I do not want to "over discuss" this, but it is important enough for me suggest not to implement support for ICE engines.
> 
> Greetinx
> 
> Chris
> 
> 
> Am Montag, den 15.06.2020, 10:27 +0800 schrieb Mark Webb-Johnson:
>> 
>> I think the core principle of the ?Open? in ?Open Vehicle Monitoring System? is that we should not restrict any uses, no matter our personal opinions.
>> 
>> Regarding the metrics themselves, I agree with Michael. The v.b namespace is intended for vehicle battery metrics. Perhaps we can simply add another namespace ?v.ice? for internal combustion engine fuels?
>> 
>> Note that OBDII defines standard fuel type codings (service 01 PID 51):
>> 
>> Value	Description
>> 0	Not available
>> 1	Gasoline
>> 2	Methanol
>> 3	Ethanol
>> 4	Diesel
>> 5	LPG <https://en.wikipedia.org/wiki/Liquefied_petroleum_gas>
>> 6	CNG <https://en.wikipedia.org/wiki/Compressed_natural_gas>
>> 7	Propane
>> 8	Electric
>> 9	Bifuel <https://en.wikipedia.org/wiki/Bi-fuel_vehicle> running Gasoline
>> 10	Bifuel running Methanol
>> 11	Bifuel running Ethanol
>> 12	Bifuel running LPG
>> 13	Bifuel running CNG
>> 14	Bifuel running Propane
>> 15	Bifuel running Electricity
>> 16	Bifuel running electric and combustion engine
>> 17	Hybrid gasoline
>> 18	Hybrid Ethanol
>> 19	Hybrid Diesel
>> 20	Hybrid Electric
>> 21	Hybrid running electric and combustion engine
>> 22	Hybrid Regenerative
>> 23	Bifuel running diesel
>> 
>> A ?v.fueltype? metric makes sense for this. Perhaps just use the full OBDII list (which supports hybrids). For ICE vehicles, keeping to standard OBDII PIDs is probably the simplest and most standardised approach. So, ?v.ice.tank.level?, or something like that (OBDII PID 0x2f).
>> 
>> Regarding the Apps support for this (and other things), that is something I am working on and trying to prototype. I will eMail separately regarding this.
>> 
>> Regards, Mark.
>> 
>>> On 15 Jun 2020, at 2:46 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>> 
>>> Craig,
>>> 
>>> I strictly vote against re-interpretation of the SOC metric. Where metrics have clear semantics we should not make them dependent on some context.
>>> 
>>> A battery is not a fuel tank, and vehicles may have both. "v.b." is the namespace "vehicle battery" and shall not be populated with non-battery metrics.
>>> 
>>> That's what I meant by adding technology specific metrics: if the vehicle has a fuel tank, additional standard metrics describing that fuel tank shall be present.
>>> 
>>> Fuel tank specific metrics might e.g. get the namespace "v.ft.", ICE engine specific metrics might get "v.ice.", fuel cell metrics "v.fc.", rocket thruster metrics "v.rt." ? you get the idea.
>>> 
>>> Make a proposition for the metrics sets you need. Try to define them as generalized as possible.
>>> 
>>> That will probably include duplicates of some metrics, like the ranges & consumption. That's necessary to be able to describe a hybrid, and some units among those will also need to be different (e.g. consumption in litres / m? per km).
>>> 
>>> Regards,
>>> Michael
>>> 
>>> 
>>> Am 14.06.20 um 18:59 schrieb Chris van der Meijden:
>>>> Thank you for considering my thoughts.
>>>> 
>>>> I believe it is a good idea to use a v.tech <http://v.tech/> variable and not using gas or gazoline. That gives OVMS enough flexibility and is also a (little) statement.
>>>> 
>>>> I'm also looking forward to rocket propulsion add ons :-))
>>>> 
>>>> Greetinx
>>>> 
>>>> Chris
>>>> 
>>>> 
>>>> Am Sonntag, den 14.06.2020, 08:21 -0700 schrieb Craig Leres:
>>>>> On 2020-06-13 08:31, Michael Balzer wrote:
>>>>>> 
>>>>>> How about adding an array or set metric like "v.ext" or "v.tech <http://v.tech/>", for
>>>>>> defined technology codes. A tag present in the metric means the
>>>>>> additional metrics, commands & configs for that technology are available.
>>>>> 
>>>>> 
>>>>> My goal is to make it possible for the app to depict soc with something
>>>>> other than a battery graphic when the energy source is not a battery.
>>>>> How about v.tech <http://v.tech/> with "battery" and "other" as the initial two possible
>>>>> values?
>>>>> 
>>>>> 		Craig
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/6d7604e8/attachment.htm>

From chris at arachnon.de  Mon Jun 15 16:38:18 2020
From: chris at arachnon.de (Chris van der Meijden)
Date: Mon, 15 Jun 2020 10:38:18 +0200
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <D6C82A11-A444-41FF-8E52-4041667EC3CB@webb-johnson.net>
References: <392565d2-f464-e09e-08f1-184347fdb8ac@xse.com>
 <1592027829.2567.4.camel@arachnon.de>
 <4ed5b9d8-a124-2c62-d11f-4bec51298b18@expeedo.de>
 <b80e51a1-1809-e9a0-3d44-de38547d4556@xse.com>
 <1592153973.13853.18.camel@arachnon.de>
 <3ea9f7cc-82d3-3a14-30f3-1dd9d8505894@expeedo.de>
 <F24DA1A4-AB81-4AB7-A689-A638C32484DC@webb-johnson.net>
 <1592205180.2530.1.camel@arachnon.de>
 <D6C82A11-A444-41FF-8E52-4041667EC3CB@webb-johnson.net>
Message-ID: <1592210298.2530.8.camel@arachnon.de>

Hey Mark
I think it is a difference telling someone what to do or actively
enabling what someone can do. If you enable something for someone you
are ethicaly responsible for that something.
All in all, we are all on the same side of the river. Driving EV's
brought a deeper understanding for the climate issues to me and I'm
sure to most of us. Good to read that you are active in a charity in
HK. Working together for a cleaner future. Just like the development of
OVMS :-)
Regards
Chris
Am Montag, den 15.06.2020, 15:56 +0800 schrieb Mark Webb-Johnson:
> Hmmm...
> It is hard to decouple ?open? from ?free?, particularly given the
> roots of the open source movement. But at it?s core is the concept of
> openness and freedom in that I (or we) should not be telling anyone
> what they can or cannot do with this project. The user is free to do
> with it what they will, and our license explicitly states that.
> 
> So, given that we cannot control what is done with the project, or
> what type of vehicle it is used in, the decision is whether we allow
> the ?v.b? battery namespace to be ?trampled on? with ICE metrics? I
> think that the suggested v.ice namespace is a reasonable compromise.
> 
> Regards, Mark.
> 
> P.S. My personal opinion is that I drive electric cars, prefer them,
> and advocate for them every day. I even co-founded a charity here in
> HK to support and promote them.
> 
> > On 15 Jun 2020, at 3:13 PM, Chris van der Meijden <chris at arachnon.d
> > e> wrote:
> > 
> > Sorry, I disagree.
> > I think "Open" stands for open source and open source should also
> > mean being open to discussions. And discussions involve personal
> > opinions.
> > IMHO supporting internal combustion engines in OVMS is a bad idea
> > in times of climate change. It is the wrong signal if we do so.?
> > I do not??want to "over discuss" this, but it is important enough
> > for me suggest not to implement support for ICE engines.
> > Greetinx
> > Chris
> > 
> > Am Montag, den 15.06.2020, 10:27 +0800 schrieb Mark Webb-Johnson:
> > > I think the core principle of the ?Open? in ?Open Vehicle
> > > Monitoring System? is that we should not restrict any uses, no
> > > matter our personal opinions.
> > > Regarding the metrics themselves, I agree with Michael. The v.b
> > > namespace is intended for vehicle battery metrics. Perhaps we can
> > > simply add another namespace ?v.ice? for internal combustion
> > > engine fuels?
> > > 
> > > Note that OBDII defines standard fuel type codings (service 01
> > > PID 51):
> > > 
> > > ValueDescription0Not
> > > available1Gasoline2Methanol3Ethanol4Diesel5LPG6CNG7Propane8Electr
> > > ic9Bifuel?running Gasoline10Bifuel running Methanol11Bifuel
> > > running Ethanol12Bifuel running LPG13Bifuel running CNG14Bifuel
> > > running Propane15Bifuel running Electricity16Bifuel running
> > > electric and combustion engine17Hybrid gasoline18Hybrid
> > > Ethanol19Hybrid Diesel20Hybrid Electric21Hybrid running electric
> > > and combustion engine22Hybrid Regenerative23Bifuel running diesel
> > > A ?v.fueltype? metric makes sense for this. Perhaps just use the
> > > full OBDII list (which supports hybrids). For ICE vehicles,
> > > keeping to standard OBDII PIDs is probably the simplest and most
> > > standardised approach. So, ?v.ice.tank.level?, or something like
> > > that (OBDII PID 0x2f).
> > > 
> > > Regarding the Apps support for this (and other things), that is
> > > something I am working on and trying to prototype. I will eMail
> > > separately regarding this.
> > > 
> > > Regards, Mark.
> > > 
> > > > On 15 Jun 2020, at 2:46 AM, Michael Balzer <dexter at expeedo.de>
> > > > wrote:
> > > > 
> > > > 
> > > > ??
> > > > ????
> > > > ??
> > > > ??
> > > > ????Craig,
> > > > 
> > > > ????
> > > > 
> > > > ????I strictly vote against re-interpretation of the SOC
> > > > metric. Where
> > > > ????metrics have clear semantics we should not make them
> > > > dependent on
> > > > ????some context.
> > > > 
> > > > ????
> > > > 
> > > > ????A battery is not a fuel tank, and vehicles may have both.
> > > > "v.b." is
> > > > ????the namespace "vehicle battery" and shall not be populated
> > > > with
> > > > ????non-battery metrics.
> > > > 
> > > > ????
> > > > 
> > > > ????That's what I meant by adding technology specific metrics:
> > > > if the
> > > > ????vehicle has a fuel tank, additional standard metrics
> > > > describing that
> > > > ????fuel tank shall be present.
> > > > 
> > > > ????
> > > > 
> > > > ????Fuel tank specific metrics might e.g. get the namespace
> > > > "v.ft.", ICE
> > > > ????engine specific metrics might get "v.ice.", fuel cell
> > > > metrics
> > > > ????"v.fc.", rocket thruster metrics "v.rt." ? you get the
> > > > idea.
> > > > 
> > > > ????
> > > > 
> > > > ????Make a proposition for the metrics sets you need. Try to
> > > > define them
> > > > ????as generalized as possible.
> > > > 
> > > > ????
> > > > 
> > > > ????That will probably include duplicates of some metrics, like
> > > > the
> > > > ????ranges & consumption. That's necessary to be able to
> > > > describe a
> > > > ????hybrid, and some units among those will also need to be
> > > > different
> > > > ????(e.g. consumption in litres / m? per km).
> > > > 
> > > > ????
> > > > 
> > > > ????Regards,
> > > > 
> > > > ????Michael
> > > > 
> > > > ????
> > > > 
> > > > ????
> > > > 
> > > > ????Am 14.06.20 um 18:59 schrieb Chris van
> > > > ??????der Meijden:
> > > > 
> > > > ????
> > > > ????
> > > > > ??????
> > > > > ??????Thank you for considering my thoughts.
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????I believe it is a good idea to use a v.tech variable
> > > > > and not
> > > > > ????????using gas or gazoline. That gives OVMS enough
> > > > > flexibility and is
> > > > > ????????also a?(little) statement.
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????I'm also looking forward to rocket propulsion add ons
> > > > > :-))
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????Greetinx
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????Chris
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????
> > > > > 
> > > > > ??????
> > > > > ??????Am Sonntag, den 14.06.2020, 08:21 -0700 schrieb Craig
> > > > > Leres:
> > > > > ??????
> > > > > > ????????On 2020-06-13 08:31, Michael Balzer wrote:
> > > > > > > How about adding an array or set metric like "v.ext" or
> > > > > > > "v.tech", for
> > > > > > > defined technology codes. A tag present in the metric
> > > > > > > means the
> > > > > > > additional metrics, commands & configs for that
> > > > > > > technology are available.
> > > > > > 
> > > > > > My goal is to make it possible for the app to depict soc
> > > > > > with something
> > > > > > other than a battery graphic when the energy source is not
> > > > > > a battery.
> > > > > > How about v.tech with "battery" and "other" as the initial
> > > > > > two possible
> > > > > > values?
> > > > > > 
> > > > > > 		Craig
> > > > > > _______________________________________________
> > > > > > OvmsDev mailing list
> > > > > > OvmsDev at lists.openvehicles.com
> > > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > > > 
> > > > > > ??????
> > > > > 
> > > > > ????
> > > > 
> > > > ????
> > > > 
> > > > ????
> > > > ??
> > > > 
> > > > _______________________________________________
> > > > OvmsDev mailing list
> > > > OvmsDev at lists.openvehicles.com
> > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > 
> > > _______________________________________________
> > > OvmsDev mailing list
> > > OvmsDev at lists.openvehicles.com
> > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/2ae9f262/attachment.htm>

From dexter at expeedo.de  Tue Jun 16 02:04:43 2020
From: dexter at expeedo.de (Michael Balzer)
Date: Mon, 15 Jun 2020 20:04:43 +0200
Subject: [Ovmsdev] File logging task
In-Reply-To: <AC2DA22E-F65F-4D75-AA65-5C12C829B0A4@webb-johnson.net>
References: <6eac2ac1-4835-7a73-51f3-af003a43eae6@expeedo.de>
 <1bc35602-d032-2d09-07b8-650a7eb3e234@expeedo.de>
 <AC2DA22E-F65F-4D75-AA65-5C12C829B0A4@webb-johnson.net>
Message-ID: <9eb50fd8-0408-8f71-4f4c-c50534dcf2af@expeedo.de>

The overhead of a direct log call is the call, the semaphore
acquisition, the tag level check & the min-heap handling. That should
normally be small. The semaphore has a nominal max wait of 1 tick = 10
ms, but the actual delay will normally be in the ?s range.

So I don't think that's causing performance issues if not used
excessively or within critical sections.

There is much more overhead though if our OvmsCommand::HexDump() utility
is used, as is the case in the SIMCOM driver. HexDump() needs to
allocate memory and format the buffer (possibly multiple blocks),
regardless of the tag level. The actual tag level check isn't exported
from the idf log module, so can currently not be done in advance. We
could change that, but there are few HexDump() calls now, most of them
just for error reports.

On excluding verbose level logging from web & ssh channels: I think
that's a severe & (now) unnecessary restriction. I've been using both
for verbose debugging and consider this to be useful & convenient.

Regards,
Michael


Am 15.06.20 um 07:55 schrieb Mark Webb-Johnson:
>
> Do you think that the overhead of the logging framework is impacting
> performance of things like SSH/SCP and SIMCOM async? Kind of related
> to the issue I raised about the infinite loop caused by debug logging
> on the web console and ssh (when those are already receiving log
> monitor output) - logging the logging.
>
> It seems using ESP_EARLY would avoid this? Or a cleanup to move such
> logging to verbose level, other stuff at debug level, and a
> restriction on web client and ssh to never log monitor above debug level?
>
> Regards, Mark.
>
>> On 13 Jun 2020, at 9:30 PM, Michael Balzer <dexter at expeedo.de
>> <mailto:dexter at expeedo.de>> wrote:
>>
>> I've added a simple workaround for this issue to our esp-idf fork:
>> https://github.com/openvehicles/esp-idf/commit/9024cd38ecbc78a46ed16b79d63f57812e72b123
>>
>> The workaround checks if logging is done from the timer context, if
>> so reduces the semaphore wait time to zero, thus avoiding blocking.
>>
>> That should eliminate any timer consistency issues arising from
>> logging in timer callbacks. The disadvantage is a higher chance of
>> such log messages getting dropped.
>>
>> Regards,
>> Michael
>>
>>
>> Am 05.11.19 um 21:45 schrieb Michael Balzer:
>>> Everyone,
>>>
>>> I've pushed the long due refactoring of the file logging into a
>>> dedicated task. This removes most of the delays involved in file
>>> logging, as the fsync() and log cycling now is done in the logging
>>> task and no longer blocks overall log message processing.
>>>
>>> I stumbled upon a bad thing (tm) though we need to resolve with
>>> logging: the esp-idf logging generally involves a semaphore wait of
>>> max 10 ms (!). I wasn't aware of this because I didn't look into the
>>> source before, there also is no warning about this in the esp-idf
>>> documentation
>>> (https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/log.html),
>>> so I guess I'm not the only one being taken by surprise here.
>>>
>>>     // Maximum time to wait for the mutex in a logging statement.
>>>     #define *MAX_MUTEX_WAIT_MS 10*
>>>     #define MAX_MUTEX_WAIT_TICKS ((MAX_MUTEX_WAIT_MS +
>>>     portTICK_PERIOD_MS - 1) / portTICK_PERIOD_MS)
>>>     ?
>>>     void IRAM_ATTR *esp_log_write*(esp_log_level_t level,
>>>     ??????? const char* tag,
>>>     ??????? const char* format, ...)
>>>     {
>>>     ??? if (!s_log_mutex) {
>>>     ??????? s_log_mutex = xSemaphoreCreateMutex();
>>>     ??? }
>>>     ??? if (*xSemaphoreTake(s_log_mutex, MAX_MUTEX_WAIT_TICKS*) ==
>>>     pdFALSE) {
>>>     ??????? return;
>>>     ??? }
>>>     ?
>>>
>>>
>>> That semaphore is needed to secure the log level tag cache against
>>> parallel access, so it also affects log messages of currently
>>> disabled tags and/or levels.
>>>
>>> This means we *must not* use the standard logging from timer
>>> callbacks, at no verbosity level. But we do, partially caused by my
>>> own code serving as a bad example I assume -- sorry.
>>>
>>> But I've not only found direct log calls in most vehicle timer
>>> callbacks, there also are some hidden ones from calling the
>>> framework, for example marking a notification as read can produce a
>>> log output from Cleanup() if tracing is enabled.
>>>
>>> We need to change this short to mid term. This may be the cause of
>>> those strange timer overflow issues we've seen occasionally. It also
>>> means every debug or verbose log output currently in the code
>>> involves potentially multiple semaphore waits, that's for example
>>> the case for all hex dumps logged by the SIMCOM module.
>>>
>>> Our primary option is to remove all log calls from all low level
>>> framework functions and timer callbacks.
>>>
>>> A simple & quick workaround could be to extend the ESP_LOGx macros
>>> to check if they are executed in the timer task context, if so
>>> suppress the message or call the ESP_EARLY log function instead.
>>> That will hide these log messages from the logging framework though,
>>> if using the _EARLY_ variant they only will be sent to the USB port.
>>>
>>> For a better solution I thought about adding a dedicated queue &
>>> task for the initial log submission as well. That will need quite
>>> some rework to the esp-idf (no changes for this in the current
>>> master) but would allow to continue logging as we do now. Cons:
>>> queue submission involves some overhead & RAM, printf format
>>> expansion needs to be done before the tag/level check, messages may
>>> need to be dropped if the task starves or RAM gets tight, log output
>>> to consoles will depend on a task as well.
>>>
>>> Opinions / better ideas?
>>>
>>> Regards,
>>> Michael
>>> -- 
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/517614ab/attachment.htm>

From shamziman at gmail.com  Tue Jun 16 03:20:47 2020
From: shamziman at gmail.com (Shaun Jurrens)
Date: Mon, 15 Jun 2020 21:20:47 +0200
Subject: [Ovmsdev] Gas vs. battery metric?
In-Reply-To: <1592210298.2530.8.camel@arachnon.de>
References: <1592210298.2530.8.camel@arachnon.de>
Message-ID: <D3F3E9B5-EE3C-4797-AF3A-8C6C745CCABB@gmail.com>

Hey,

I appreciate the wisdom in Mark?s approach and his and others? work on this project and, in this matter, his opinion.  No solution is ever used just for what it was intended. Even if he wanted to, the project could easily be forked and massed produced in countries with few IP laws.  It?s already ?out there?.

Secondly, purists and absolutists rarely serve projects?s benefit very long as their growing impatience with the world?s imperfections tend to kill their motivation sooner rather than later.  Indeed, if perfect environmental requirements were necessary, then no one in NL, for example, would be allowed to drive at all, EV or ICE, as well over 90% of NL?s energy production isn?t from renewables.  Life is more complex than what we can easily see.

I own an Ampera and am glad for the functionality that has been developed in OVMS and hope to be able to contribute some day soon. The car is a utilitarian compromise from its day in 2013, and it gets me through the year with 90% of my travel on battery.  It?s not perfect, but it?s much better than nothing, and that is where most of us (and the world) need to start. 

The old saying is ?Perfection is the enemy of progress? (or as Voltaire phrased it, ?the best is the enemy of the good?), fits rather aptly here.

Cheers,
Shaun
(via the iPad thingamajigg)

> On 15 Jun 2020, at 10:39, Chris van der Meijden <chris at arachnon.de> wrote:
> 
> ?
> Hey Mark
> 
> I think it is a difference telling someone what to do or actively enabling what someone can do. If you enable something for someone you are ethicaly responsible for that something.
> 
> All in all, we are all on the same side of the river. Driving EV's brought a deeper understanding for the climate issues to me and I'm sure to most of us. Good to read that you are active in a charity in HK. Working together for a cleaner future. Just like the development of OVMS :-)
> 
> Regards
> 
> Chris
> 
> Am Montag, den 15.06.2020, 15:56 +0800 schrieb Mark Webb-Johnson:
>> Hmmm...
>> 
>> It is hard to decouple ?open? from ?free?, particularly given the roots of the open source movement. But at it?s core is the concept of openness and freedom in that I (or we) should not be telling anyone what they can or cannot do with this project. The user is free to do with it what they will, and our license explicitly states that.
>> 
>> So, given that we cannot control what is done with the project, or what type of vehicle it is used in, the decision is whether we allow the ?v.b? battery namespace to be ?trampled on? with ICE metrics? I think that the suggested v.ice namespace is a reasonable compromise.
>> 
>> Regards, Mark.
>> 
>> P.S. My personal opinion is that I drive electric cars, prefer them, and advocate for them every day. I even co-founded a charity here in HK to support and promote them.
>> 
>>> On 15 Jun 2020, at 3:13 PM, Chris van der Meijden <chris at arachnon.de> wrote:
>>> 
>>> Sorry, I disagree.
>>> 
>>> I think "Open" stands for open source and open source should also mean being open to discussions. And discussions involve personal opinions.
>>> 
>>> IMHO supporting internal combustion engines in OVMS is a bad idea in times of climate change. It is the wrong signal if we do so.
>>> 
>>> I do not want to "over discuss" this, but it is important enough for me suggest not to implement support for ICE engines.
>>> 
>>> Greetinx
>>> 
>>> Chris
>>> 
>>> 
>>> Am Montag, den 15.06.2020, 10:27 +0800 schrieb Mark Webb-Johnson:
>>>> 
>>>> I think the core principle of the ?Open? in ?Open Vehicle Monitoring System? is that we should not restrict any uses, no matter our personal opinions.
>>>> 
>>>> Regarding the metrics themselves, I agree with Michael. The v.b namespace is intended for vehicle battery metrics. Perhaps we can simply add another namespace ?v.ice? for internal combustion engine fuels?
>>>> 
>>>> Note that OBDII defines standard fuel type codings (service 01 PID 51):
>>>> 
>>>> Value	Description
>>>> 0	Not available
>>>> 1	Gasoline
>>>> 2	Methanol
>>>> 3	Ethanol
>>>> 4	Diesel
>>>> 5	LPG
>>>> 6	CNG
>>>> 7	Propane
>>>> 8	Electric
>>>> 9	Bifuel running Gasoline
>>>> 10	Bifuel running Methanol
>>>> 11	Bifuel running Ethanol
>>>> 12	Bifuel running LPG
>>>> 13	Bifuel running CNG
>>>> 14	Bifuel running Propane
>>>> 15	Bifuel running Electricity
>>>> 16	Bifuel running electric and combustion engine
>>>> 17	Hybrid gasoline
>>>> 18	Hybrid Ethanol
>>>> 19	Hybrid Diesel
>>>> 20	Hybrid Electric
>>>> 21	Hybrid running electric and combustion engine
>>>> 22	Hybrid Regenerative
>>>> 23	Bifuel running diesel
>>>> 
>>>> A ?v.fueltype? metric makes sense for this. Perhaps just use the full OBDII list (which supports hybrids). For ICE vehicles, keeping to standard OBDII PIDs is probably the simplest and most standardised approach. So, ?v.ice.tank.level?, or something like that (OBDII PID 0x2f).
>>>> 
>>>> Regarding the Apps support for this (and other things), that is something I am working on and trying to prototype. I will eMail separately regarding this.
>>>> 
>>>> Regards, Mark.
>>>> 
>>>>> On 15 Jun 2020, at 2:46 AM, Michael Balzer <dexter at expeedo.de> wrote:
>>>>> 
>>>>> Craig,
>>>>> 
>>>>> I strictly vote against re-interpretation of the SOC metric. Where metrics have clear semantics we should not make them dependent on some context.
>>>>> 
>>>>> A battery is not a fuel tank, and vehicles may have both. "v.b." is the namespace "vehicle battery" and shall not be populated with non-battery metrics.
>>>>> 
>>>>> That's what I meant by adding technology specific metrics: if the vehicle has a fuel tank, additional standard metrics describing that fuel tank shall be present.
>>>>> 
>>>>> Fuel tank specific metrics might e.g. get the namespace "v.ft.", ICE engine specific metrics might get "v.ice.", fuel cell metrics "v.fc.", rocket thruster metrics "v.rt." ? you get the idea.
>>>>> 
>>>>> Make a proposition for the metrics sets you need. Try to define them as generalized as possible.
>>>>> 
>>>>> That will probably include duplicates of some metrics, like the ranges & consumption. That's necessary to be able to describe a hybrid, and some units among those will also need to be different (e.g. consumption in litres / m? per km).
>>>>> 
>>>>> Regards,
>>>>> Michael
>>>>> 
>>>>> 
>>>>> Am 14.06.20 um 18:59 schrieb Chris van der Meijden:
>>>>>> Thank you for considering my thoughts.
>>>>>> 
>>>>>> I believe it is a good idea to use a v.tech variable and not using gas or gazoline. That gives OVMS enough flexibility and is also a (little) statement.
>>>>>> 
>>>>>> I'm also looking forward to rocket propulsion add ons :-))
>>>>>> 
>>>>>> Greetinx
>>>>>> 
>>>>>> Chris
>>>>>> 
>>>>>> 
>>>>>> Am Sonntag, den 14.06.2020, 08:21 -0700 schrieb Craig Leres:
>>>>>>>> On 2020-06-13 08:31, Michael Balzer wrote:
>>>>>>>> 
>>>>>>>> How about adding an array or set metric like "v.ext" or "v.tech", for
>>>>>>>> defined technology codes. A tag present in the metric means the
>>>>>>>> additional metrics, commands & configs for that technology are available.
>>>>>>> 
>>>>>>> 
>>>>>>> My goal is to make it possible for the app to depict soc with something
>>>>>>> other than a battery graphic when the energy source is not a battery.
>>>>>>> How about v.tech with "battery" and "other" as the initial two possible
>>>>>>> values?
>>>>>>> 
>>>>>>> 		Craig
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>> 
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>> 
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200615/ea60c5df/attachment.htm>

From jaunius at gmx.com  Tue Jun 23 18:45:28 2020
From: jaunius at gmx.com (Jaunius Kapkan)
Date: Tue, 23 Jun 2020 13:45:28 +0300
Subject: [Ovmsdev] NL: iOS app - Add Cabin Temp and HVAC state
Message-ID: <E85AB984-AA6C-49E5-B4E5-C5CA7EF29EE5@gmx.com>

Hi,

Can someone guide on the best approach here. I have no access to MAC so it would be more of a trial and error approach.  Current view:

Metrics:


Or are we close to the unified app for both iOS and Android and I should wait?

Regards,

Regards,
Jaunius Kapkan [Sent from cellphone]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200623/436d56f1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0dddcf99-4faa-4b3a-a523-da98780ce30d.jpg
Type: image/jpeg
Size: 240992 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200623/436d56f1/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f370a907-df44-4b55-bf0a-b7eb11ef1382.jpg
Type: image/jpeg
Size: 60887 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200623/436d56f1/attachment-0005.jpg>

From mark at webb-johnson.net  Wed Jun 24 10:22:25 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Wed, 24 Jun 2020 10:22:25 +0800
Subject: [Ovmsdev] NL: iOS app - Add Cabin Temp and HVAC state
In-Reply-To: <E85AB984-AA6C-49E5-B4E5-C5CA7EF29EE5@gmx.com>
References: <E85AB984-AA6C-49E5-B4E5-C5CA7EF29EE5@gmx.com>
Message-ID: <43EE4DE2-5F95-468D-AA1D-CE348BB88A44@webb-johnson.net>

Those two metrics are available in v2 protocol:

Both in doors5, as part of the ?D? message

So, the iOS App should have them delivered. But the iOS App doesn?t handle anything beyond doors3 in the ?D? message at the moment. That would not be too hard to add, but you?d be unlikely to get the change 100% without an ability to test. Displaying on the screen itself is probably not too hard. Apple has some new requirements for App Store submission, including requiring support for apple sign on, that I am not sure if we now meet (so getting this approved maybe a hassle). If someone makes the change, I will try to get it through.

Unified App

I have been concentrating on the unified app recently, rather than trying to extend the iOS specific App. But it is hard going, and a real struggle. I?ve got forty years of programming experience, but am very new to these unified frameworks.

Compared to the native app frameworks, these unified app frameworks are a mess. Poor documentation. Breaking changes on every version upgrade. Outdated example code. Unmaintained libraries. The open source ones are like perl - 10 libraries to do variants of the same thing and no idea which one is the best. The majority simply don?t work on the latest version of the framework. I like Xamarin (which doesn?t suffer front too many of these problems), but it is just too proprietary for my taste (and I am scared MS will shut it down, or restrict it in some way). We use Monaca (phone gap based) at work, but it is just too restrictive and too ?webby'.


I have decided to try to implement the App in react-native, which seems to be the most up-to-date and modern of the open source frameworks. It is certainly fast, but the breaking changes in each new versions are a nightmare for those new to the framework (like me). Any example code / library more than a few months old just doesn?t work properly. The nice thing about this framework is that so long as we stick to pure javascript, we can self-publish a development version of the App, and load it remotely from the ?expo? client that runs on Android and iOS phones and tables. It is incredibly quick to iterate through changes, without all the code signing crap, App Store approvals and delays. We would still use the app stores to publish final versions. For example, my current first couple of evenings very basic attempt at building using this framework is here:

https://exp.host/@markwj/Open-Vehicle-React-App <https://exp.host/@markwj/Open-Vehicle-React-App>

Install the expo client, point the camera at that QR code, and the App will be downloaded and run locally. Some comments:

Status tab is for vehicle overall status. This is a web view, and will be loaded dynamically (with callbacks to be able to retrieve metrics, issue commands) for per-vehicle-type and per-customer customisation.

Vehicle tab is for vehicle environment status. Same as the status tab, this is a web view.

Location tab is a map.

Messages tab are chat style messages for talking to the car.

Settings tab will change in this app, and will be for settings of that particular select car.

The above tabs may change (in particular, I am not sure about status and vehicle tabs - perhaps we need just one, and then have some customisable way of having multiple screens per car type. I don?t like that it is fix to two screens. So I am thinking maybe just one screen, with tabs along the top, or swipe, to switch between pages.

Swipe left for the menu drawer. This is where the list of your vehicles will be, as well as menu options (create new vehicle, etc).

The basic ideas behind this are unchanged, as I outlined before. Vehicle API agnostic, central metrics store, user customisable display, etc.

I'm working in the open on this, committing as I go along. So dozens/hundreds of little commits, often correcting each other. It is a prototype, that I am using to just test each of the technologies we need (e.g. can the web view retrieve metrics from the app), can we support websocket connections to OVMS v2 servers, etc. I have no idea if it can become a production App, but so far it seems that it can.

If anybody wants to jump onboard and help, that would be most appreciated. Especially if you have javascript or react experience. Likewise, if anybody wants to try this in another framework, that is also possible. At this point, I am simply not sure what is the best approach.

Regards, Mark.

> On 23 Jun 2020, at 6:45 PM, Jaunius Kapkan <jaunius at gmx.com> wrote:
> 
> Hi,
> 
> Can someone guide on the best approach here. I have no access to MAC so it would be more of a trial and error approach.  Current view:
> <0dddcf99-4faa-4b3a-a523-da98780ce30d.jpg>
> Metrics:
> <f370a907-df44-4b55-bf0a-b7eb11ef1382.jpg>
> 
> Or are we close to the unified app for both iOS and Android and I should wait?
> 
> Regards,
> 
> Regards,
> Jaunius Kapkan [Sent from cellphone]
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200624/f9eefcad/attachment.htm>

From leres at xse.com  Wed Jun 24 11:43:14 2020
From: leres at xse.com (Craig Leres)
Date: Tue, 23 Jun 2020 20:43:14 -0700
Subject: [Ovmsdev] NL: iOS app - Add Cabin Temp and HVAC state
Message-ID: <F4EB8152-0188-4471-9CAA-A9102B1FFFF7@xse.com>

?On 2020-06-23 19:22, Mark Webb-Johnson wrote:
> Those two metrics are available in v2 protocol:
> 
>  * Both in doors5, as part of the ?D? message
> 
> 
> So, the iOS App should have them delivered. But the iOS App doesn?t
> handle anything beyond doors3 in the ?D? message at the moment. That
> would not be too hard to add, but you?d be unlikely to get the change
> 100% without an ability to test. Displaying on the screen itself is
> probably not too hard. Apple has some new requirements for App Store
> submission, including requiring support for apple sign on, that I am not
> sure if we now meet (so getting this approved maybe a hassle). If
> someone makes the change, I will try to get it through.

I recently got a mini (mostly to run zoom for meetings) and can build,
run, and test in the osx simulator; I have more time during the weekend
than the week but would happy to help test changes.

> _*Unified App*_

> If anybody wants to jump onboard and help, that would be most
> appreciated. Especially if you have javascript or react experience.
> Likewise, if anybody wants to try this in another framework, that is
> also possible. At this point, I am simply not sure what is the best
> approach.

I couldn't easily get this to run anywhere. Firefox gave me an empty
popup window. Chrome launch a popup window with a phone that eventually
launches the app. But when I click on it I get a blue window that says
something went wrong (the error log says Uncaught Error: No project
found at exp://exp.host/@undefined/undefined).

       Craig



From mark at webb-johnson.net  Wed Jun 24 12:33:42 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Wed, 24 Jun 2020 12:33:42 +0800
Subject: [Ovmsdev] NL: iOS app - Add Cabin Temp and HVAC state
In-Reply-To: <F4EB8152-0188-4471-9CAA-A9102B1FFFF7@xse.com>
References: <F4EB8152-0188-4471-9CAA-A9102B1FFFF7@xse.com>
Message-ID: <45EE71A6-A657-400C-BA03-161A15091D81@webb-johnson.net>


> I couldn't easily get this to run anywhere. Firefox gave me an empty
> popup window. Chrome launch a popup window with a phone that eventually
> launches the app. But when I click on it I get a blue window that says
> something went wrong (the error log says Uncaught Error: No project
> found at exp://exp.host/@undefined/undefined).

You need to first install the expo app on your phone:

iOS: iOS App <https://itunes.apple.com/app/apple-store/id982107779>
Android: Android App <https://play.google.com/store/apps/details?id=host.exp.exponent&referrer=www>

Then, scan the picture, or click on that exp: url.

Regards, Mark.

> On 24 Jun 2020, at 11:43 AM, Craig Leres <leres at xse.com> wrote:
> 
> On 2020-06-23 19:22, Mark Webb-Johnson wrote:
>> Those two metrics are available in v2 protocol:
>> 
>> * Both in doors5, as part of the ?D? message
>> 
>> 
>> So, the iOS App should have them delivered. But the iOS App doesn?t
>> handle anything beyond doors3 in the ?D? message at the moment. That
>> would not be too hard to add, but you?d be unlikely to get the change
>> 100% without an ability to test. Displaying on the screen itself is
>> probably not too hard. Apple has some new requirements for App Store
>> submission, including requiring support for apple sign on, that I am not
>> sure if we now meet (so getting this approved maybe a hassle). If
>> someone makes the change, I will try to get it through.
> 
> I recently got a mini (mostly to run zoom for meetings) and can build,
> run, and test in the osx simulator; I have more time during the weekend
> than the week but would happy to help test changes.
> 
>> _*Unified App*_
> 
>> If anybody wants to jump onboard and help, that would be most
>> appreciated. Especially if you have javascript or react experience.
>> Likewise, if anybody wants to try this in another framework, that is
>> also possible. At this point, I am simply not sure what is the best
>> approach.
> 
> I couldn't easily get this to run anywhere. Firefox gave me an empty
> popup window. Chrome launch a popup window with a phone that eventually
> launches the app. But when I click on it I get a blue window that says
> something went wrong (the error log says Uncaught Error: No project
> found at exp://exp.host/@undefined/undefined).
> 
>       Craig
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200624/217b56c8/attachment.htm>

From kommykt at gmail.com  Wed Jun 24 16:07:42 2020
From: kommykt at gmail.com (=?UTF-8?B?VGFtw6FzIEtvdsOhY3M=?=)
Date: Wed, 24 Jun 2020 10:07:42 +0200
Subject: [Ovmsdev] NL: iOS app - Add Cabin Temp and HVAC state
In-Reply-To: <45EE71A6-A657-400C-BA03-161A15091D81@webb-johnson.net>
References: <F4EB8152-0188-4471-9CAA-A9102B1FFFF7@xse.com>
 <45EE71A6-A657-400C-BA03-161A15091D81@webb-johnson.net>
Message-ID: <CAGpaXUtu3bNXhcKrA9wytMOc-dO0LbtgAWGD6ySQN1WuwxrgVA@mail.gmail.com>

On ios i get the following error:

2020. j?nius 24., szerda d?tummal Mark Webb-Johnson <mark at webb-johnson.net>
ezt ?rta:

>
> I couldn't easily get this to run anywhere. Firefox gave me an empty
> popup window. Chrome launch a popup window with a phone that eventually
> launches the app. But when I click on it I get a blue window that says
> something went wrong (the error log says Uncaught Error: No project
> found at exp://exp.host/@undefined/undefined).
>
>
> You need to first install the expo app on your phone:
>
> iOS: iOS App <https://itunes.apple.com/app/apple-store/id982107779>
> Android: Android App
> <https://play.google.com/store/apps/details?id=host.exp.exponent&referrer=www>
>
> Then, scan the picture, or click on that exp: url.
>
> Regards, Mark.
>
> On 24 Jun 2020, at 11:43 AM, Craig Leres <leres at xse.com> wrote:
>
> On 2020-06-23 19:22, Mark Webb-Johnson wrote:
>
> Those two metrics are available in v2 protocol:
>
> * Both in doors5, as part of the ?D? message
>
>
> So, the iOS App should have them delivered. But the iOS App doesn?t
> handle anything beyond doors3 in the ?D? message at the moment. That
> would not be too hard to add, but you?d be unlikely to get the change
> 100% without an ability to test. Displaying on the screen itself is
> probably not too hard. Apple has some new requirements for App Store
> submission, including requiring support for apple sign on, that I am not
> sure if we now meet (so getting this approved maybe a hassle). If
> someone makes the change, I will try to get it through.
>
>
> I recently got a mini (mostly to run zoom for meetings) and can build,
> run, and test in the osx simulator; I have more time during the weekend
> than the week but would happy to help test changes.
>
> _*Unified App*_
>
>
> If anybody wants to jump onboard and help, that would be most
> appreciated. Especially if you have javascript or react experience.
> Likewise, if anybody wants to try this in another framework, that is
> also possible. At this point, I am simply not sure what is the best
> approach.
>
>
> I couldn't easily get this to run anywhere. Firefox gave me an empty
> popup window. Chrome launch a popup window with a phone that eventually
> launches the app. But when I click on it I get a blue window that says
> something went wrong (the error log says Uncaught Error: No project
> found at exp://exp.host/@undefined/undefined).
>
>       Craig
>
>
>

-- 
?dv?zlettel:
Kov?cs Tam?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200624/92fc6438/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DB8E0EE1-1923-4DA5-BA4C-E623D78BB5B4.png
Type: image/png
Size: 143142 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200624/92fc6438/attachment-0002.png>

From mark at webb-johnson.net  Wed Jun 24 16:22:16 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Wed, 24 Jun 2020 16:22:16 +0800
Subject: [Ovmsdev] NL: iOS app - Add Cabin Temp and HVAC state
In-Reply-To: <CAGpaXUtu3bNXhcKrA9wytMOc-dO0LbtgAWGD6ySQN1WuwxrgVA@mail.gmail.com>
References: <F4EB8152-0188-4471-9CAA-A9102B1FFFF7@xse.com>
 <45EE71A6-A657-400C-BA03-161A15091D81@webb-johnson.net>
 <CAGpaXUtu3bNXhcKrA9wytMOc-dO0LbtgAWGD6ySQN1WuwxrgVA@mail.gmail.com>
Message-ID: <F1E09D40-F1C5-473A-8ADB-ABF4E10D8FBB@webb-johnson.net>

Great. Looks like Apple clamped down so that no longer works. Should be ok on Android. When I get the web app bit worked out it will also work there.

Regards, Mark.

> On 24 Jun 2020, at 4:07 PM, Tam?s Kov?cs <kommykt at gmail.com> wrote:
> 
> On ios i get the following error:
> 
> 2020. j?nius 24., szerda d?tummal Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> ezt ?rta:
> 
>> I couldn't easily get this to run anywhere. Firefox gave me an empty
>> popup window. Chrome launch a popup window with a phone that eventually
>> launches the app. But when I click on it I get a blue window that says
>> something went wrong (the error log says Uncaught Error: No project
>> found at exp://exp.host/@undefined/undefined <>).
> 
> You need to first install the expo app on your phone:
> 
> iOS: iOS App <https://itunes.apple.com/app/apple-store/id982107779>
> Android: Android App <https://play.google.com/store/apps/details?id=host.exp.exponent&referrer=www>
> 
> Then, scan the picture, or click on that exp: url.
> 
> Regards, Mark.
> 
>> On 24 Jun 2020, at 11:43 AM, Craig Leres <leres at xse.com <mailto:leres at xse.com>> wrote:
>> 
>> On 2020-06-23 19:22, Mark Webb-Johnson wrote:
>>> Those two metrics are available in v2 protocol:
>>> 
>>> * Both in doors5, as part of the ?D? message
>>> 
>>> 
>>> So, the iOS App should have them delivered. But the iOS App doesn?t
>>> handle anything beyond doors3 in the ?D? message at the moment. That
>>> would not be too hard to add, but you?d be unlikely to get the change
>>> 100% without an ability to test. Displaying on the screen itself is
>>> probably not too hard. Apple has some new requirements for App Store
>>> submission, including requiring support for apple sign on, that I am not
>>> sure if we now meet (so getting this approved maybe a hassle). If
>>> someone makes the change, I will try to get it through.
>> 
>> I recently got a mini (mostly to run zoom for meetings) and can build,
>> run, and test in the osx simulator; I have more time during the weekend
>> than the week but would happy to help test changes.
>> 
>>> _*Unified App*_
>> 
>>> If anybody wants to jump onboard and help, that would be most
>>> appreciated. Especially if you have javascript or react experience.
>>> Likewise, if anybody wants to try this in another framework, that is
>>> also possible. At this point, I am simply not sure what is the best
>>> approach.
>> 
>> I couldn't easily get this to run anywhere. Firefox gave me an empty
>> popup window. Chrome launch a popup window with a phone that eventually
>> launches the app. But when I click on it I get a blue window that says
>> something went wrong (the error log says Uncaught Error: No project
>> found at exp://exp.host/@undefined/undefined <>).
>> 
>>       Craig
>> 
> 
> 
> 
> -- 
> ?dv?zlettel:
> Kov?cs Tam?s
> 
> 
> <DB8E0EE1-1923-4DA5-BA4C-E623D78BB5B4.png>_______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200624/48f17824/attachment.htm>

From sebastien.darveau at synnoetic.com  Wed Jun 24 21:10:10 2020
From: sebastien.darveau at synnoetic.com (=?UTF-8?Q?S=C3=A9bastien_Darveau?=)
Date: Wed, 24 Jun 2020 13:10:10 +0000
Subject: [Ovmsdev] Cross Platform Unified App
In-Reply-To: <0DB4B4E5-CA50-4B98-8469-BDD171252B42@webb-johnson.net>
References: <0DB4B4E5-CA50-4B98-8469-BDD171252B42@webb-johnson.net> 
 <EDF622C6-D71E-42D9-8F6C-9165EAF7CF7D@synnoetic.com>
Message-ID: <01000172e6733afc-3e777dea-2ef6-443c-908a-4904c071418f-000000@email.amazonses.com>

Hello,?

Here is my 2 cents on this.

- Have you also looked into Xamarin.Forms? It is the equivalent display templated approach used by Xamarin for Multiplatform UI. It uses data binding to instantly reflect model changes and it is quite flexible. It usually goes with the MVVM (Model-View ViewModel) design pattern. I have a year of experience with it and I can help to start the project.

- I can?t really talk about vehicle-server protocols but for app-server communication, I would favour a well designed REST api. As for the low level protocol, I used to have a separate project containing only DTO objects that is shared by server and client as a submodule. This is the interface. Server uses Automapper (?https://automapper.org/?) to map entities to DTO objects before sending back the response.?

Regards,
Sebastien Darveau


On Jun 15, 2020, at 3:00 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net> > wrote:


As you may know, I?ve been working for some time on the design of a cross platform unified App for OVMS. Here are my thoughts.

*	I think our approach of the ?virtual vehicle?, represented by a hash/set of metric->value, works well. We have been successful in providing common vehicle metrics for more than a dozen different types of electric vehicle, plus a bunch of other generic types. Overall, I think this is the correct approach, and lends itself very well to the IoT MQTT way of doing things.

*	Maintaining two separate Apps on two different platforms has been difficult, and the features and functionality are diverging too much.

*	The v2 protocol is too limiting (especially for new vehicle types, and custom metrics).

*	I like the idea of providing a ?templated? approach to the displays in the Apps. We design templates to pick metrics, along with other assets, and display their current values updated in real time.

*	By leveraging the ?virtual vehicle? model, we can also introduce the concept of vehicle sources. At the moment, we are limited to just one vehicle data source - OVMS protocol v2, and to some extent the apps already convert the incoming v2 data into a hard-coded set of metrics, with hard-coded display layouts. The purpose of these vehicle sources is to login to a remote server, retrieve the vehicle data, and store it as the standardised metrics, in the standardised ?virtual vehicle?. Example sources could be OVMS protocol v2, OVMS protocol v3 (MQTT), Tesla API, Carwings API, direct bluetooth to an OVMS module, etc. We could virtualise these protocols, with a common interface.

So, my proposal is:

1.	We develop a single universal App, coded in a ?free? open environment. I have looked at Xamarin and Phonegap (vue-js, and a bunch of alternatives in common use nowadays). My current preference is vue-js, as it seems that javascript and html lend themselves best to the templated display approach - it is trivial to dynamically load this content. That, plus the environment is truly free and well understood by a huge developer community. However, no decision has been made and I am open to suggestions.

2.	The App implements a virtual protocol system. Each virtual protocol talks a particular backend API for a particular account. The virtual protocol then publishes vehicles for the user to choose from. Initially we would write an OVMS v2 protocol implementation, but others (as previously listed) should be relatively easy to implement.

3.	The App implements a virtual vehicle system. Each virtual protocol converts the incoming vehicle data to the virtual vehicle metrics. We can base this simply on the OVMS v3 standardised metrics, but custom metrics also need to be supported. Commands to be sent to the vehicle can also be implemented in a similar way. The OVMS v3 MQTT protocol would be a 1-to-1 mapping here, for example.

4.	The App displays are implemented via a templating system, with templates provided per vehicle type and per screen type (phone, tablet, desktop, etc). The user can customise these templates, using either named virtual vehicle metrics or other assets (pictures, buttons for commands, etc).

5.	I feel that this approach provides an excellent balance. It allows for comprehensive support and flexibility of display for each vehicle type, without complicating the implementation. It also allows owners of more than one type of vehicle (perhaps not all supported by OVMS) to use a single App to monitor and control.

I am happy to build the framework for this, but would much prefer others to come on board to assist.

Any thoughts or suggestion are most welcome.

Regards, Mark.

_______________________________________________
OvmsDev mailing list
OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com> 
http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200624/2931b7d4/attachment.htm>

From mark at webb-johnson.net  Fri Jun 26 16:10:15 2020
From: mark at webb-johnson.net (Mark Webb-Johnson)
Date: Fri, 26 Jun 2020 16:10:15 +0800
Subject: [Ovmsdev] Cross Platform Unified App
In-Reply-To: <01000172e6733afc-3e777dea-2ef6-443c-908a-4904c071418f-000000@email.amazonses.com>
References: <0DB4B4E5-CA50-4B98-8469-BDD171252B42@webb-johnson.net>
 <EDF622C6-D71E-42D9-8F6C-9165EAF7CF7D@synnoetic.com>
 <01000172e6733afc-3e777dea-2ef6-443c-908a-4904c071418f-000000@email.amazonses.com>
Message-ID: <8F15B149-C7F8-473E-BD65-A232029F6FF3@webb-johnson.net>


I did look into Xamarin forms, and tried to create some simple apps. I like it, but it is just too proprietary for my taste (and I am scared MS will shut it down, or restrict it in some way). I would prefer some open source approach. The documentation is however very good, and platform is stable, but examples not very helpful. I do like the way it allows a common UI (with forms), but still permits customisation on a per-platform basis.

The framework app I tried to create in react-native is simply this:

Tabs
Vehicle (web view)
Status (web view)
Location (native map)
Messages (chat ui)
Settings (just a simple form based screen)

Drawer style menu pulled in from the left, with arbritrary content

Support for light/dark theme (autoswitched to the Operating System selection would be best)

Support for Android and iOS

If that is simple in Xamarin, and you have time, it would be useful to generate that template app in Xamarin (forms) so we can compare the two.

Regarding the API, I want this App to be protocol-agnostic. Internally, it has a virtual vehicle with a set of metrics, messaging system, and set of commands that can be issued. Then we can implement the actual protocols and directly support things like Tesla?s API, Carwings, etc, as well as OVMS. This also makes it very simple to migrate from protocol v2 to v3 (or our http api).

Regards, Mark

> On 24 Jun 2020, at 9:10 PM, S?bastien Darveau <sebastien.darveau at synnoetic.com> wrote:
> 
> Hello, 
> 
> Here is my 2 cents on this.
> 
> - Have you also looked into Xamarin.Forms? It is the equivalent display templated approach used by Xamarin for Multiplatform UI. It uses data binding to instantly reflect model changes and it is quite flexible. It usually goes with the MVVM (Model-View ViewModel) design pattern. I have a year of experience with it and I can help to start the project.
> 
> - I can?t really talk about vehicle-server protocols but for app-server communication, I would favour a well designed REST api. As for the low level protocol, I used to have a separate project containing only DTO objects that is shared by server and client as a submodule. This is the interface. Server uses Automapper ( https://automapper.org/ <https://automapper.org/> ) to map entities to DTO objects before sending back the response. 
> 
> Regards,
> Sebastien Darveau
> 
> 
>> On Jun 15, 2020, at 3:00 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>> 
>> 
>> As you may know, I?ve been working for some time on the design of a cross platform unified App for OVMS. Here are my thoughts.
>> 
>> I think our approach of the ?virtual vehicle?, represented by a hash/set of metric->value, works well. We have been successful in providing common vehicle metrics for more than a dozen different types of electric vehicle, plus a bunch of other generic types. Overall, I think this is the correct approach, and lends itself very well to the IoT MQTT way of doing things.
>> 
>> Maintaining two separate Apps on two different platforms has been difficult, and the features and functionality are diverging too much.
>> 
>> The v2 protocol is too limiting (especially for new vehicle types, and custom metrics).
>> 
>> I like the idea of providing a ?templated? approach to the displays in the Apps. We design templates to pick metrics, along with other assets, and display their current values updated in real time.
>> 
>> By leveraging the ?virtual vehicle? model, we can also introduce the concept of vehicle sources. At the moment, we are limited to just one vehicle data source - OVMS protocol v2, and to some extent the apps already convert the incoming v2 data into a hard-coded set of metrics, with hard-coded display layouts. The purpose of these vehicle sources is to login to a remote server, retrieve the vehicle data, and store it as the standardised metrics, in the standardised ?virtual vehicle?. Example sources could be OVMS protocol v2, OVMS protocol v3 (MQTT), Tesla API, Carwings API, direct bluetooth to an OVMS module, etc. We could virtualise these protocols, with a common interface.
>> 
>> So, my proposal is:
>> 
>> We develop a single universal App, coded in a ?free? open environment. I have looked at Xamarin and Phonegap (vue-js, and a bunch of alternatives in common use nowadays). My current preference is vue-js, as it seems that javascript and html lend themselves best to the templated display approach - it is trivial to dynamically load this content. That, plus the environment is truly free and well understood by a huge developer community. However, no decision has been made and I am open to suggestions.
>> 
>> The App implements a virtual protocol system. Each virtual protocol talks a particular backend API for a particular account. The virtual protocol then publishes vehicles for the user to choose from. Initially we would write an OVMS v2 protocol implementation, but others (as previously listed) should be relatively easy to implement.
>> 
>> The App implements a virtual vehicle system. Each virtual protocol converts the incoming vehicle data to the virtual vehicle metrics. We can base this simply on the OVMS v3 standardised metrics, but custom metrics also need to be supported. Commands to be sent to the vehicle can also be implemented in a similar way. The OVMS v3 MQTT protocol would be a 1-to-1 mapping here, for example.
>> 
>> The App displays are implemented via a templating system, with templates provided per vehicle type and per screen type (phone, tablet, desktop, etc). The user can customise these templates, using either named virtual vehicle metrics or other assets (pictures, buttons for commands, etc).
>> 
>> I feel that this approach provides an excellent balance. It allows for comprehensive support and flexibility of display for each vehicle type, without complicating the implementation. It also allows owners of more than one type of vehicle (perhaps not all supported by OVMS) to use a single App to monitor and control.
>> 
>> I am happy to build the framework for this, but would much prefer others to come on board to assist.
>> 
>> Any thoughts or suggestion are most welcome.
>> 
>> Regards, Mark.
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200626/35a9773b/attachment.htm>