Hi, I got remote climate control working on my 2016 Nissan Leaf with OVMS v3. In the 2016 model year Nissan moved the TCU from the EV CAN bus to the Car CAN bus and they change the remote climate control messages slightly. The Leaf - OBDII cables that were sold with OVMS v2 were future proofed and when used with the OVMS v3 have the EV bus wired to m_can1 and the CAR bus to m_can2. Mark mentioned this a while back and I'm happy to confirm that it works. A "standard" OBDII cable only exposes the CAR bus. Sending the right message to the m_can2 bus with a Leaf cable starts up the climate control. I must thank Mitchell on My Nissan Leaf for providing the updated can frame, see http://www.mynissanleaf.com/viewtopic.php?t=24053#p496393 I haven't worked out how to turn remote climate control off and I haven't tested remote charge start yet. This certainty encourages me to look at the cellular situation -- we've got a bit of a heat wave going on in NZ at the moment. When I last tried the cellular data, it worked moderately well for a day or so and then stopped because it had used all of the free 1MB allocation for the month on the Hologram SIM. I see less than 1MB per month using the OVMS v2 on a local carrier. I haven't looked at whether the v3 data usage was caused by excessive communications with the server, Hologram counting data differently to what I'm used to, or the v3 code reconnecting to the cellular network often. Nearly at feature parity with v2!
Tom, I fixed a minor bug in the v2 server code that caused much more data updates to be sent than necessary, can you please check if your data usage drops with that fix? https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ca6f... Regards, Michael Am 09.12.2017 um 11:10 schrieb Tom Parker:
This certainty encourages me to look at the cellular situation -- we've got a bit of a heat wave going on in NZ at the moment. When I last tried the cellular data, it worked moderately well for a day or so and then stopped because it had used all of the free 1MB allocation for the month on the Hologram SIM. I see less than 1MB per month using the OVMS v2 on a local carrier. I haven't looked at whether the v3 data usage was caused by excessive communications with the server, Hologram counting data differently to what I'm used to, or the v3 code reconnecting to the cellular network often.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 10/12/17 00:31, Michael Balzer wrote:
I fixed a minor bug in the v2 server code that caused much more data updates to be sent than necessary, can you please check if your data usage drops with that fix?
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ca6f...
I don't think changing from boolean to bitwise "or" would make a difference? I'm seeing a lot of messages, multiple per second, see below. I think the problems are in components/ovms_server_v2/src/ovms_server_v2.cpp. In OvmsServerV2::ServerTask, the m_now_stat and similar logic will always be true in a real car. At a minimum we have 4 significant figures on the 12v measurement, and the park timer will count up every second. I changed the logic to only check once per minute and it's a lot less chatty, but this is probably not the right solution: iff --git a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp index 32b463e..271b7ca 100644 --- a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp +++ b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp @@ -262,7 +262,6 @@ void OvmsServerV2::ServerTask() TransmitMsgFirmware(lasttx==0); TransmitMsgCapabilities(lasttx==0); lasttx = now; - } if (m_now_stat) TransmitMsgStat(); if (m_now_environment) TransmitMsgEnvironment(); @@ -276,6 +275,7 @@ void OvmsServerV2::ServerTask() if (m_pending_notify_error) TransmitNotifyError(); if (m_pending_notify_alert) TransmitNotifyAlert(); if (m_pending_notify_data) TransmitNotifyData(); + } // Poll for new data if ((m_buffer->PollSocket(m_conn.Socket(),1000) < 0)|| I haven't been following the notifications discussion but it looks like we need to discriminate between the metrics that change all the time and the metrics that should cause an update. The log below is from before making the change. 2017-12-16 20:14:59,6038,'#59 C rx msg S 85,K,391,4,charging,standard,71,0,10,29,0,0,3,1,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,391.50,0' 2017-12-16 20:15:00,6042,'#59 C rx msg D 92,0,5,0,0,27,0,290,0,1765,24,0,1,1,13.1593,0,0,0,0,0' 2017-12-16 20:15:00,6043,'#59 C rx msg S 85,K,392,4,charging,standard,71,0,10,30,0,0,3,1,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,391.50,0' 2017-12-16 20:15:00,6044,'#59 C rx msg D 92,0,5,0,0,27,0,300,0,1826,24,0,1,1,13.1593,0,0,0,0,0' 2017-12-16 20:15:00,6045,'#59 C rx msg S 85,K,392,3,charging,standard,71,0,10,31,0,0,3,1,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,392.00,0' 2017-12-16 20:15:00,6046,'#59 C rx msg D 92,0,5,0,0,27,0,310,0,1887,24,0,1,1,13.1923,0,0,0,0,0' 2017-12-16 20:17:26,6510,'#59 C rx msg S 85,K,392,4,charging,standard,71,0,10,32,0,0,3,1,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,392.00,0' 2017-12-16 20:17:28,6513,'#59 C rx msg D 92,0,5,0,0,27,0,320,0,1948,24,0,1,1,13.1484,0,0,0,0,0' 2017-12-16 20:17:28,6514,'#59 C rx msg S 85,K,392,4,charging,standard,72,0,10,33,0,0,3,1,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,392.00,0' 2017-12-16 20:17:28,6515,'#59 C rx msg D 92,0,5,0,0,27,0,330,0,2009,24,0,1,1,13.1538,0,0,0,0,0' 2017-12-16 20:17:28,6516,'#59 C rx msg F 3.0.0/factory/main build (idf v2.1-20-g88ab5d4) Dec 16 2017 10:05:30,,4,1,NL,VodafoneNZ Hologram' 2017-12-16 20:17:28,6517,'#59 C rx msg S 85,K,392,4,charging,standard,72,0,10,34,0,0,3,1,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,392.00,0' 2017-12-16 20:17:28,6518,'#59 C rx msg D 92,0,5,0,0,27,0,340,0,2070,24,0,1,1,13.0549,0,0,0,0,0' 2017-12-16 20:17:28,6519,'#59 C rx msg D 92,0,5,0,0,27,0,340,0,2071,24,0,1,1,13.0934,0,0,0,0,0' 2017-12-16 20:17:28,6520,'#59 C rx msg D 92,0,5,0,0,27,0,340,0,2072,23,0,1,1,13.0934,0,0,0,0,0' 2017-12-16 20:17:28,6521,'#59 C rx msg D 92,0,5,0,0,27,0,340,0,2073,24,0,1,1,13.0934,0,0,0,0,0' 2017-12-16 20:17:28,6523,'#59 C rx msg D 92,0,5,0,0,27,0,340,0,2077,23,0,1,1,13.0934,0,0,0,0,0' 2017-12-16 20:17:29,6524,'#59 C rx msg D 92,0,5,0,0,27,0,340,0,2078,24,0,1,1,13.0934,0,0,0,0,0' 2017-12-16 20:17:31,6528,'#59 C rx msg D 92,0,5,0,0,27,0,340,0,2080,23,0,1,1,13.0934,0,0,0,0,0' 2017-12-16 20:17:32,6531,'#59 C rx msg D 92,0,5,0,0,27,0,340,0,2081,23,0,1,1,13.0385,0,0,0,0,0' 2017-12-16 20:17:33,6532,'#59 C rx msg D 92,0,5,0,0,27,0,340,0,2082,24,0,1,1,13.0385,0,0,0,0,0'
Tom, Am 17.12.2017 um 11:00 schrieb Tom Parker:
On 10/12/17 00:31, Michael Balzer wrote:
I fixed a minor bug in the v2 server code that caused much more data updates to be sent than necessary, can you please check if your data usage drops with that fix? https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ca6f... I don't think changing from boolean to bitwise "or" would make a difference? I'm seeing a lot of messages, multiple per second, see below.
A logic or ("||") only gets evaluated up to the first "true", so it makes a difference if the function called does a modification -- IsModifiedAndClear() clears the modifier bit.
I think the problems are in components/ovms_server_v2/src/ovms_server_v2.cpp. In OvmsServerV2::ServerTask, the m_now_stat and similar logic will always be true in a real car. At a minimum we have 4 significant figures on the 12v measurement, and the park timer will count up every second.
I changed the logic to only check once per minute and it's a lot less chatty, but this is probably not the right solution:
I agree, that doesn't look right… OK, I found it: the frequent "D" updates are caused by the V2 server metrics listener setting m_now_environment to true on any (!) metrics change when peers are connected. I think these lines can just be removed from the listener: if (StandardMetrics.ms_s_v2_peers->AsInt() > 0) m_now_environment = true; // Transmit environment message if necessary …as it checks for immediate update triggers (charge state etc.) before, and the main loop logic takes care of per minute update frequency when peers are connected. Can you verify that? A higher update frequency will only be needed for the location streaming mode (todo). Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
The “design” of the v2 peers check for environment is to send an environment message immediately the environment changes (when one or more apps are connected). It is meant to display a door opening, on a connected App, immediately the door opens, rather than having to wait a minute. But, it should only do the actual transmission if something in the environment -actually- changes. Perhaps that is the issue? I’m travelling for the next 24 hours, so won’t be able to check. Does the above “clue” help any? Regards, Mark
On 17 Dec 2017, at 6:42 PM, Michael Balzer <dexter@expeedo.de> wrote:
Tom,
Am 17.12.2017 um 11:00 schrieb Tom Parker:
On 10/12/17 00:31, Michael Balzer wrote: I fixed a minor bug in the v2 server code that caused much more data updates to be sent than necessary, can you please check if your data usage drops with that fix? https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ca6f... I don't think changing from boolean to bitwise "or" would make a difference? I'm seeing a lot of messages, multiple per second, see below.
A logic or ("||") only gets evaluated up to the first "true", so it makes a difference if the function called does a modification -- IsModifiedAndClear() clears the modifier bit.
I think the problems are in components/ovms_server_v2/src/ovms_server_v2.cpp. In OvmsServerV2::ServerTask, the m_now_stat and similar logic will always be true in a real car. At a minimum we have 4 significant figures on the 12v measurement, and the park timer will count up every second.
I changed the logic to only check once per minute and it's a lot less chatty, but this is probably not the right solution:
I agree, that doesn't look right…
OK, I found it: the frequent "D" updates are caused by the V2 server metrics listener setting m_now_environment to true on any (!) metrics change when peers are connected.
I think these lines can just be removed from the listener:
if (StandardMetrics.ms_s_v2_peers->AsInt() > 0) m_now_environment = true; // Transmit environment message if necessary
…as it checks for immediate update triggers (charge state etc.) before, and the main loop logic takes care of per minute update frequency when peers are connected.
Can you verify that?
A higher update frequency will only be needed for the location streaming mode (todo).
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
That makes sense, I'll change the listener accordingly… Am 17.12.2017 um 11:56 schrieb Mark Webb-Johnson:
The “design” of the v2 peers check for environment is to send an environment message immediately the environment changes (when one or more apps are connected).
It is meant to display a door opening, on a connected App, immediately the door opens, rather than having to wait a minute.
But, it should only do the actual transmission if something in the environment -actually- changes. Perhaps that is the issue?
I’m travelling for the next 24 hours, so won’t be able to check. Does the above “clue” help any?
Regards, Mark
On 17 Dec 2017, at 6:42 PM, Michael Balzer <dexter@expeedo.de> wrote:
Tom,
Am 17.12.2017 um 11:00 schrieb Tom Parker:
On 10/12/17 00:31, Michael Balzer wrote: I fixed a minor bug in the v2 server code that caused much more data updates to be sent than necessary, can you please check if your data usage drops with that fix? https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ca6f... I don't think changing from boolean to bitwise "or" would make a difference? I'm seeing a lot of messages, multiple per second, see below. A logic or ("||") only gets evaluated up to the first "true", so it makes a difference if the function called does a modification -- IsModifiedAndClear() clears the modifier bit.
I think the problems are in components/ovms_server_v2/src/ovms_server_v2.cpp. In OvmsServerV2::ServerTask, the m_now_stat and similar logic will always be true in a real car. At a minimum we have 4 significant figures on the 12v measurement, and the park timer will count up every second.
I changed the logic to only check once per minute and it's a lot less chatty, but this is probably not the right solution: I agree, that doesn't look right…
OK, I found it: the frequent "D" updates are caused by the V2 server metrics listener setting m_now_environment to true on any (!) metrics change when peers are connected.
I think these lines can just be removed from the listener:
if (StandardMetrics.ms_s_v2_peers->AsInt() > 0) m_now_environment = true; // Transmit environment message if necessary
…as it checks for immediate update triggers (charge state etc.) before, and the main loop logic takes care of per minute update frequency when peers are connected.
Can you verify that?
A higher update frequency will only be needed for the location streaming mode (todo).
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Thanks! I have found v3 to be exceptionally easy to debug and test these things. Having the metrics so easy to change and simulate different events is really cool. Looking forward to being able to expose those metrics directly via MQTT and GATT. Regards, Mark
On 17 Dec 2017, at 7:16 PM, Michael Balzer <dexter@expeedo.de> wrote:
That makes sense, I'll change the listener accordingly…
Am 17.12.2017 um 11:56 schrieb Mark Webb-Johnson: The “design” of the v2 peers check for environment is to send an environment message immediately the environment changes (when one or more apps are connected).
It is meant to display a door opening, on a connected App, immediately the door opens, rather than having to wait a minute.
But, it should only do the actual transmission if something in the environment -actually- changes. Perhaps that is the issue?
I’m travelling for the next 24 hours, so won’t be able to check. Does the above “clue” help any?
Regards, Mark
On 17 Dec 2017, at 6:42 PM, Michael Balzer <dexter@expeedo.de> wrote:
Tom,
Am 17.12.2017 um 11:00 schrieb Tom Parker: On 10/12/17 00:31, Michael Balzer wrote: I fixed a minor bug in the v2 server code that caused much more data updates to be sent than necessary, can you please check if your data usage drops with that fix? https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ca6f... I don't think changing from boolean to bitwise "or" would make a difference? I'm seeing a lot of messages, multiple per second, see below. A logic or ("||") only gets evaluated up to the first "true", so it makes a difference if the function called does a modification -- IsModifiedAndClear() clears the modifier bit.
I think the problems are in components/ovms_server_v2/src/ovms_server_v2.cpp. In OvmsServerV2::ServerTask, the m_now_stat and similar logic will always be true in a real car. At a minimum we have 4 significant figures on the 12v measurement, and the park timer will count up every second.
I changed the logic to only check once per minute and it's a lot less chatty, but this is probably not the right solution: I agree, that doesn't look right…
OK, I found it: the frequent "D" updates are caused by the V2 server metrics listener setting m_now_environment to true on any (!) metrics change when peers are connected.
I think these lines can just be removed from the listener:
if (StandardMetrics.ms_s_v2_peers->AsInt() > 0) m_now_environment = true; // Transmit environment message if necessary
…as it checks for immediate update triggers (charge state etc.) before, and the main loop logic takes care of per minute update frequency when peers are connected.
Can you verify that?
A higher update frequency will only be needed for the location streaming mode (todo).
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
And the logging, and the terminals, and the performance… :) If just RAM wouldn't be so limited… …Tom, please test: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/85d8... Regards, Michael Am 17.12.2017 um 12:28 schrieb Mark Webb-Johnson:
Thanks!
I have found v3 to be exceptionally easy to debug and test these things. Having the metrics so easy to change and simulate different events is really cool. Looking forward to being able to expose those metrics directly via MQTT and GATT.
Regards, Mark
On 17 Dec 2017, at 7:16 PM, Michael Balzer <dexter@expeedo.de> wrote:
That makes sense, I'll change the listener accordingly…
Am 17.12.2017 um 11:56 schrieb Mark Webb-Johnson: The “design” of the v2 peers check for environment is to send an environment message immediately the environment changes (when one or more apps are connected).
It is meant to display a door opening, on a connected App, immediately the door opens, rather than having to wait a minute.
But, it should only do the actual transmission if something in the environment -actually- changes. Perhaps that is the issue?
I’m travelling for the next 24 hours, so won’t be able to check. Does the above “clue” help any?
Regards, Mark
On 17 Dec 2017, at 6:42 PM, Michael Balzer <dexter@expeedo.de> wrote:
Tom,
Am 17.12.2017 um 11:00 schrieb Tom Parker: On 10/12/17 00:31, Michael Balzer wrote: I fixed a minor bug in the v2 server code that caused much more data updates to be sent than necessary, can you please check if your data usage drops with that fix? https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ca6f... I don't think changing from boolean to bitwise "or" would make a difference? I'm seeing a lot of messages, multiple per second, see below. A logic or ("||") only gets evaluated up to the first "true", so it makes a difference if the function called does a modification -- IsModifiedAndClear() clears the modifier bit.
I think the problems are in components/ovms_server_v2/src/ovms_server_v2.cpp. In OvmsServerV2::ServerTask, the m_now_stat and similar logic will always be true in a real car. At a minimum we have 4 significant figures on the 12v measurement, and the park timer will count up every second.
I changed the logic to only check once per minute and it's a lot less chatty, but this is probably not the right solution: I agree, that doesn't look right…
OK, I found it: the frequent "D" updates are caused by the V2 server metrics listener setting m_now_environment to true on any (!) metrics change when peers are connected.
I think these lines can just be removed from the listener:
if (StandardMetrics.ms_s_v2_peers->AsInt() > 0) m_now_environment = true; // Transmit environment message if necessary
…as it checks for immediate update triggers (charge state etc.) before, and the main loop logic takes care of per minute update frequency when peers are connected.
Can you verify that?
A higher update frequency will only be needed for the location streaming mode (todo).
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
If just RAM wouldn't be so limited…
I think Espressif think the same. 4MB PSRAM should help. Mark
On 17 Dec 2017, at 7:40 PM, Michael Balzer <dexter@expeedo.de> wrote:
And the logging, and the terminals, and the performance… :) If just RAM wouldn't be so limited…
…Tom, please test:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/85d8...
Regards, Michael
Am 17.12.2017 um 12:28 schrieb Mark Webb-Johnson: Thanks!
I have found v3 to be exceptionally easy to debug and test these things. Having the metrics so easy to change and simulate different events is really cool. Looking forward to being able to expose those metrics directly via MQTT and GATT.
Regards, Mark
On 17 Dec 2017, at 7:16 PM, Michael Balzer <dexter@expeedo.de> wrote:
That makes sense, I'll change the listener accordingly…
Am 17.12.2017 um 11:56 schrieb Mark Webb-Johnson: The “design” of the v2 peers check for environment is to send an environment message immediately the environment changes (when one or more apps are connected).
It is meant to display a door opening, on a connected App, immediately the door opens, rather than having to wait a minute.
But, it should only do the actual transmission if something in the environment -actually- changes. Perhaps that is the issue?
I’m travelling for the next 24 hours, so won’t be able to check. Does the above “clue” help any?
Regards, Mark
On 17 Dec 2017, at 6:42 PM, Michael Balzer <dexter@expeedo.de> wrote:
Tom,
> Am 17.12.2017 um 11:00 schrieb Tom Parker: > On 10/12/17 00:31, Michael Balzer wrote: > I fixed a minor bug in the v2 server code that caused much more data updates to be sent than necessary, can you please check if your data usage drops with > that fix? > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ca6f... I don't think changing from boolean to bitwise "or" would make a difference? I'm seeing a lot of messages, multiple per second, see below. A logic or ("||") only gets evaluated up to the first "true", so it makes a difference if the function called does a modification -- IsModifiedAndClear() clears the modifier bit.
I think the problems are in components/ovms_server_v2/src/ovms_server_v2.cpp. In OvmsServerV2::ServerTask, the m_now_stat and similar logic will always be true in a real car. At a minimum we have 4 significant figures on the 12v measurement, and the park timer will count up every second.
I changed the logic to only check once per minute and it's a lot less chatty, but this is probably not the right solution: I agree, that doesn't look right…
OK, I found it: the frequent "D" updates are caused by the V2 server metrics listener setting m_now_environment to true on any (!) metrics change when peers are connected.
I think these lines can just be removed from the listener:
if (StandardMetrics.ms_s_v2_peers->AsInt() > 0) m_now_environment = true; // Transmit environment message if necessary
…as it checks for immediate update triggers (charge state etc.) before, and the main loop logic takes care of per minute update frequency when peers are connected.
Can you verify that?
A higher update frequency will only be needed for the location streaming mode (todo).
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
At least during charging this appears to be working better, 2 messages per minute for the most part. I always have a client connected as my python client is always connected waiting for messages. These logs are with 63b87c3f46d5af9eaf49739aa3179c4d026aa3de + a hack to ignore changes in the ms_v_bat_12v_voltage metric (and also nissan leaf remote control changes but they don't affect the telemetry). I'm ignoring the 12v because it appears to have only 3 decimal significant figures of signal and we're monitoring changes on 3 additional significant figures of noise. The following are the values every minute while the car is charging the traction battery and the 12v system is powered by the on board DC-DC. 13.1374 13.1923 13.1813 13.1264 13.1209 13.1978 13.1044 13.1154 13.1538 13.2418 13.1593 13.1813 13.1484 13.1813 13.1374 13.1813 13.1813 It's probably worth storing and even transmitting 4 significant figures, as you can see trends in the noise much more clearly than the v2's 100mV steps, but we shouldn't trigger notifications on the noise. We could also look at averaging or taking the median to increase the signal to noise ratio. The full log below shows the few minutes as I arrived home and it connected to the wifi (gsm is too unstable to use) and then I plugged in and started charging. 2017-12-19 05:09:33,21226,'#79 A got login' 2017-12-19 05:10:01,21292,'#37 C got login' 2017-12-19 05:10:01,21293,'#37 C rx msg S 50,K,0,0,stopped,standard,42,0,0,0,0,0,13,21,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.50,96' 2017-12-19 05:10:01,21294,'#37 C rx msg D 128,0,5,0,0,27,0,70,0,460,21,1,1,1,12.5934,0,0,0,0,0' 2017-12-19 05:10:02,21295,'#37 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:02,21296,'#37 C rx msg W 0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:03,21297,'#37 C rx msg F 3.0.0/factory/main build (idf v2.1-20-g88ab5d4) Dec 18 2017 09:50:21,,0,1,NL,redacted' 2017-12-19 05:10:03,21298,'#37 C rx msg S 50,K,0,0,stopped,standard,42,0,0,0,0,0,13,21,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.50,96' 2017-12-19 05:10:03,21299,'#37 C rx msg D 128,0,5,0,0,27,0,70,0,460,21,1,1,1,12.5934,0,0,0,0,0' 2017-12-19 05:10:04,21300,'#37 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:04,21301,'#37 C rx msg W 0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:05,21302,'#37 C rx msg F 3.0.0/factory/main build (idf v2.1-20-g88ab5d4) Dec 18 2017 09:50:21,,0,1,NL,redacted' 2017-12-19 05:10:22,21360,'#37 C rx msg S 50,K,511,0,charging,standard,42,0,17,0,0,0,3,1,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,511.50,96' 2017-12-19 05:10:22,21361,'#37 C rx msg D 156,0,5,0,0,27,0,70,0,477,22,1,1,1,12.6758,0,0,0,0,0' 2017-12-19 05:10:23,21362,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:23,21363,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:24,21364,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:27,21372,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:11:19,21481,'#37 C rx msg S 50,K,379,5,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,379.50,96' 2017-12-19 05:11:19,21482,'#37 C rx msg D 156,0,5,0,0,27,0,80,0,521,22,1,1,1,13.1044,0,0,0,0,0' 2017-12-19 05:11:39,21537,'#37 C rx msg D 92,0,5,0,0,27,0,90,0,558,22,0,1,1,13.1374,0,0,0,0,0' 2017-12-19 05:12:03,21599,'#37 C rx msg S 50,K,379,4,charging,standard,42,0,10,1,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,379.50,96' 2017-12-19 05:12:03,21602,'#37 C rx msg D 92,0,5,0,0,27,0,90,0,582,22,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:13:04,21745,'#37 C rx msg S 50,K,380,4,charging,standard,42,0,10,2,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.00,96' 2017-12-19 05:13:04,21746,'#37 C rx msg D 92,0,5,0,0,27,0,100,0,643,22,0,1,1,13.1648,0,0,0,0,0' 2017-12-19 05:14:05,21870,'#37 C rx msg S 50,K,380,4,charging,standard,42,0,10,3,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.00,96' 2017-12-19 05:14:07,21879,'#37 C rx msg D 92,0,5,0,0,27,0,110,0,704,22,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:15:13,22039,'#37 C rx msg S 50,K,380,3,charging,standard,42,0,10,4,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:15:13,22040,'#37 C rx msg D 92,0,5,0,0,27,0,120,0,765,23,0,1,1,13.1593,0,0,0,0,0' 2017-12-19 05:15:51,22142,'#15 A timeout due app due to inactivity' 2017-12-19 05:15:54,22146,'#15 A got login' 2017-12-19 05:16:07,22183,'#37 C rx msg S 51,K,380,5,charging,standard,42,0,10,5,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:16:07,22184,'#37 C rx msg D 92,0,5,0,0,27,0,130,0,826,23,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:17:08,22324,'#37 C rx msg S 51,K,380,4,charging,standard,42,0,10,6,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:17:08,22325,'#37 C rx msg D 92,0,5,0,0,27,0,140,0,887,23,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:18:09,22450,'#37 C rx msg S 51,K,380,4,charging,standard,43,0,10,7,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:18:12,22457,'#37 C rx msg D 92,0,5,0,0,27,0,150,0,948,23,0,1,1,13.1923,0,0,0,0,0' 2017-12-19 05:19:10,22589,'#37 C rx msg S 51,K,380,4,charging,standard,43,0,10,8,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:19:10,22590,'#37 C rx msg D 92,0,5,0,0,27,0,160,0,1009,23,0,1,1,13.1593,0,0,0,0,0' 2017-12-19 05:20:11,22725,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,9,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:20:11,22726,'#37 C rx msg D 92,0,5,0,0,27,0,170,0,1070,23,0,1,1,13.1703,0,0,0,0,0' 2017-12-19 05:21:12,22870,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,10,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:21:12,22871,'#37 C rx msg D 92,0,5,0,0,27,0,180,0,1131,24,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:22:13,22999,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,11,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:22:13,23001,'#37 C rx msg D 92,0,5,0,0,27,0,190,0,1192,24,0,1,1,13.1319,0,0,0,0,0' 2017-12-19 05:23:14,23114,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,12,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:23:14,23115,'#37 C rx msg D 92,0,5,0,0,27,0,200,0,1253,24,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:24:15,23235,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,13,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:24:15,23236,'#37 C rx msg D 92,0,5,0,0,27,0,210,0,1314,25,0,1,1,13.2033,0,0,0,0,0' 2017-12-19 05:25:16,23394,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,14,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:25:16,23395,'#37 C rx msg D 92,0,5,0,0,27,0,220,0,1375,25,0,1,1,13.1978,0,0,0,0,0' 2017-12-19 05:26:17,23536,'#37 C rx msg S 52,K,381,5,charging,standard,44,0,10,15,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.50,96' 2017-12-19 05:26:17,23538,'#37 C rx msg D 92,0,5,0,0,27,0,230,0,1436,25,0,1,1,13.2143,0,0,0,0,0'
Tom, you're right, the unnecessary updates result from the high internal value resolution and it's reduction on the msg protocol. If the SOC changes from 51.00 to 51.01 %, an "S" msg will be sent, although it (currently) only transports "51". Even if it would transport two decimal digits, there still could be fractional parts or float jitter, unless we restrict precision in the metrics itself and use that precision throughout all communications. I think the best way to solve this is to use msg level CRC checking as V2 did. Regards, Michael Am 19.12.2017 um 07:40 schrieb Tom Parker:
At least during charging this appears to be working better, 2 messages per minute for the most part. I always have a client connected as my python client is always connected waiting for messages.
These logs are with 63b87c3f46d5af9eaf49739aa3179c4d026aa3de + a hack to ignore changes in the ms_v_bat_12v_voltage metric (and also nissan leaf remote control changes but they don't affect the telemetry). I'm ignoring the 12v because it appears to have only 3 decimal significant figures of signal and we're monitoring changes on 3 additional significant figures of noise. The following are the values every minute while the car is charging the traction battery and the 12v system is powered by the on board DC-DC.
13.1374 13.1923 13.1813 13.1264 13.1209 13.1978 13.1044 13.1154 13.1538 13.2418 13.1593 13.1813 13.1484 13.1813 13.1374 13.1813 13.1813
It's probably worth storing and even transmitting 4 significant figures, as you can see trends in the noise much more clearly than the v2's 100mV steps, but we shouldn't trigger notifications on the noise. We could also look at averaging or taking the median to increase the signal to noise ratio.
The full log below shows the few minutes as I arrived home and it connected to the wifi (gsm is too unstable to use) and then I plugged in and started charging.
2017-12-19 05:09:33,21226,'#79 A got login' 2017-12-19 05:10:01,21292,'#37 C got login' 2017-12-19 05:10:01,21293,'#37 C rx msg S 50,K,0,0,stopped,standard,42,0,0,0,0,0,13,21,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.50,96' 2017-12-19 05:10:01,21294,'#37 C rx msg D 128,0,5,0,0,27,0,70,0,460,21,1,1,1,12.5934,0,0,0,0,0' 2017-12-19 05:10:02,21295,'#37 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:02,21296,'#37 C rx msg W 0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:03,21297,'#37 C rx msg F 3.0.0/factory/main build (idf v2.1-20-g88ab5d4) Dec 18 2017 09:50:21,,0,1,NL,redacted' 2017-12-19 05:10:03,21298,'#37 C rx msg S 50,K,0,0,stopped,standard,42,0,0,0,0,0,13,21,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.50,96' 2017-12-19 05:10:03,21299,'#37 C rx msg D 128,0,5,0,0,27,0,70,0,460,21,1,1,1,12.5934,0,0,0,0,0' 2017-12-19 05:10:04,21300,'#37 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:04,21301,'#37 C rx msg W 0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:05,21302,'#37 C rx msg F 3.0.0/factory/main build (idf v2.1-20-g88ab5d4) Dec 18 2017 09:50:21,,0,1,NL,redacted' 2017-12-19 05:10:22,21360,'#37 C rx msg S 50,K,511,0,charging,standard,42,0,17,0,0,0,3,1,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,511.50,96' 2017-12-19 05:10:22,21361,'#37 C rx msg D 156,0,5,0,0,27,0,70,0,477,22,1,1,1,12.6758,0,0,0,0,0' 2017-12-19 05:10:23,21362,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:23,21363,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:24,21364,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:27,21372,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:11:19,21481,'#37 C rx msg S 50,K,379,5,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,379.50,96' 2017-12-19 05:11:19,21482,'#37 C rx msg D 156,0,5,0,0,27,0,80,0,521,22,1,1,1,13.1044,0,0,0,0,0' 2017-12-19 05:11:39,21537,'#37 C rx msg D 92,0,5,0,0,27,0,90,0,558,22,0,1,1,13.1374,0,0,0,0,0' 2017-12-19 05:12:03,21599,'#37 C rx msg S 50,K,379,4,charging,standard,42,0,10,1,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,379.50,96' 2017-12-19 05:12:03,21602,'#37 C rx msg D 92,0,5,0,0,27,0,90,0,582,22,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:13:04,21745,'#37 C rx msg S 50,K,380,4,charging,standard,42,0,10,2,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.00,96' 2017-12-19 05:13:04,21746,'#37 C rx msg D 92,0,5,0,0,27,0,100,0,643,22,0,1,1,13.1648,0,0,0,0,0' 2017-12-19 05:14:05,21870,'#37 C rx msg S 50,K,380,4,charging,standard,42,0,10,3,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.00,96' 2017-12-19 05:14:07,21879,'#37 C rx msg D 92,0,5,0,0,27,0,110,0,704,22,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:15:13,22039,'#37 C rx msg S 50,K,380,3,charging,standard,42,0,10,4,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:15:13,22040,'#37 C rx msg D 92,0,5,0,0,27,0,120,0,765,23,0,1,1,13.1593,0,0,0,0,0' 2017-12-19 05:15:51,22142,'#15 A timeout due app due to inactivity' 2017-12-19 05:15:54,22146,'#15 A got login' 2017-12-19 05:16:07,22183,'#37 C rx msg S 51,K,380,5,charging,standard,42,0,10,5,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:16:07,22184,'#37 C rx msg D 92,0,5,0,0,27,0,130,0,826,23,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:17:08,22324,'#37 C rx msg S 51,K,380,4,charging,standard,42,0,10,6,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:17:08,22325,'#37 C rx msg D 92,0,5,0,0,27,0,140,0,887,23,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:18:09,22450,'#37 C rx msg S 51,K,380,4,charging,standard,43,0,10,7,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:18:12,22457,'#37 C rx msg D 92,0,5,0,0,27,0,150,0,948,23,0,1,1,13.1923,0,0,0,0,0' 2017-12-19 05:19:10,22589,'#37 C rx msg S 51,K,380,4,charging,standard,43,0,10,8,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:19:10,22590,'#37 C rx msg D 92,0,5,0,0,27,0,160,0,1009,23,0,1,1,13.1593,0,0,0,0,0' 2017-12-19 05:20:11,22725,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,9,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:20:11,22726,'#37 C rx msg D 92,0,5,0,0,27,0,170,0,1070,23,0,1,1,13.1703,0,0,0,0,0' 2017-12-19 05:21:12,22870,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,10,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:21:12,22871,'#37 C rx msg D 92,0,5,0,0,27,0,180,0,1131,24,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:22:13,22999,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,11,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:22:13,23001,'#37 C rx msg D 92,0,5,0,0,27,0,190,0,1192,24,0,1,1,13.1319,0,0,0,0,0' 2017-12-19 05:23:14,23114,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,12,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:23:14,23115,'#37 C rx msg D 92,0,5,0,0,27,0,200,0,1253,24,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:24:15,23235,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,13,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:24:15,23236,'#37 C rx msg D 92,0,5,0,0,27,0,210,0,1314,25,0,1,1,13.2033,0,0,0,0,0' 2017-12-19 05:25:16,23394,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,14,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:25:16,23395,'#37 C rx msg D 92,0,5,0,0,27,0,220,0,1375,25,0,1,1,13.1978,0,0,0,0,0' 2017-12-19 05:26:17,23536,'#37 C rx msg S 52,K,381,5,charging,standard,44,0,10,15,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.50,96' 2017-12-19 05:26:17,23538,'#37 C rx msg D 92,0,5,0,0,27,0,230,0,1436,25,0,1,1,13.2143,0,0,0,0,0'
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
We should be able to cope with this without having to go back to CRC checksums. The modifier support was supposed to avoid that. Using checksums isn’t going to help the metric-based protocols like MQTT and bluetooth GATT. Can we extend OvmsMetric / OvmsMetricFloat to store a default precision (defined when the metric is created)? That is then used when accessing the metric as a string. Regards, Mark
On 19 Dec 2017, at 4:00 PM, Michael Balzer <dexter@expeedo.de> wrote:
Tom,
you're right, the unnecessary updates result from the high internal value resolution and it's reduction on the msg protocol.
If the SOC changes from 51.00 to 51.01 %, an "S" msg will be sent, although it (currently) only transports "51". Even if it would transport two decimal digits, there still could be fractional parts or float jitter, unless we restrict precision in the metrics itself and use that precision throughout all communications.
I think the best way to solve this is to use msg level CRC checking as V2 did.
Regards, Michael
Am 19.12.2017 um 07:40 schrieb Tom Parker:
At least during charging this appears to be working better, 2 messages per minute for the most part. I always have a client connected as my python client is always connected waiting for messages.
These logs are with 63b87c3f46d5af9eaf49739aa3179c4d026aa3de + a hack to ignore changes in the ms_v_bat_12v_voltage metric (and also nissan leaf remote control changes but they don't affect the telemetry). I'm ignoring the 12v because it appears to have only 3 decimal significant figures of signal and we're monitoring changes on 3 additional significant figures of noise. The following are the values every minute while the car is charging the traction battery and the 12v system is powered by the on board DC-DC.
13.1374 13.1923 13.1813 13.1264 13.1209 13.1978 13.1044 13.1154 13.1538 13.2418 13.1593 13.1813 13.1484 13.1813 13.1374 13.1813 13.1813
It's probably worth storing and even transmitting 4 significant figures, as you can see trends in the noise much more clearly than the v2's 100mV steps, but we shouldn't trigger notifications on the noise. We could also look at averaging or taking the median to increase the signal to noise ratio.
The full log below shows the few minutes as I arrived home and it connected to the wifi (gsm is too unstable to use) and then I plugged in and started charging.
2017-12-19 05:09:33,21226,'#79 A got login' 2017-12-19 05:10:01,21292,'#37 C got login' 2017-12-19 05:10:01,21293,'#37 C rx msg S 50,K,0,0,stopped,standard,42,0,0,0,0,0,13,21,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.50,96' 2017-12-19 05:10:01,21294,'#37 C rx msg D 128,0,5,0,0,27,0,70,0,460,21,1,1,1,12.5934,0,0,0,0,0' 2017-12-19 05:10:02,21295,'#37 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:02,21296,'#37 C rx msg W 0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:03,21297,'#37 C rx msg F 3.0.0/factory/main build (idf v2.1-20-g88ab5d4) Dec 18 2017 09:50:21,,0,1,NL,redacted' 2017-12-19 05:10:03,21298,'#37 C rx msg S 50,K,0,0,stopped,standard,42,0,0,0,0,0,13,21,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.50,96' 2017-12-19 05:10:03,21299,'#37 C rx msg D 128,0,5,0,0,27,0,70,0,460,21,1,1,1,12.5934,0,0,0,0,0' 2017-12-19 05:10:04,21300,'#37 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:04,21301,'#37 C rx msg W 0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:05,21302,'#37 C rx msg F 3.0.0/factory/main build (idf v2.1-20-g88ab5d4) Dec 18 2017 09:50:21,,0,1,NL,redacted' 2017-12-19 05:10:22,21360,'#37 C rx msg S 50,K,511,0,charging,standard,42,0,17,0,0,0,3,1,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,511.50,96' 2017-12-19 05:10:22,21361,'#37 C rx msg D 156,0,5,0,0,27,0,70,0,477,22,1,1,1,12.6758,0,0,0,0,0' 2017-12-19 05:10:23,21362,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:23,21363,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:24,21364,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:27,21372,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:11:19,21481,'#37 C rx msg S 50,K,379,5,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,379.50,96' 2017-12-19 05:11:19,21482,'#37 C rx msg D 156,0,5,0,0,27,0,80,0,521,22,1,1,1,13.1044,0,0,0,0,0' 2017-12-19 05:11:39,21537,'#37 C rx msg D 92,0,5,0,0,27,0,90,0,558,22,0,1,1,13.1374,0,0,0,0,0' 2017-12-19 05:12:03,21599,'#37 C rx msg S 50,K,379,4,charging,standard,42,0,10,1,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,379.50,96' 2017-12-19 05:12:03,21602,'#37 C rx msg D 92,0,5,0,0,27,0,90,0,582,22,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:13:04,21745,'#37 C rx msg S 50,K,380,4,charging,standard,42,0,10,2,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.00,96' 2017-12-19 05:13:04,21746,'#37 C rx msg D 92,0,5,0,0,27,0,100,0,643,22,0,1,1,13.1648,0,0,0,0,0' 2017-12-19 05:14:05,21870,'#37 C rx msg S 50,K,380,4,charging,standard,42,0,10,3,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.00,96' 2017-12-19 05:14:07,21879,'#37 C rx msg D 92,0,5,0,0,27,0,110,0,704,22,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:15:13,22039,'#37 C rx msg S 50,K,380,3,charging,standard,42,0,10,4,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:15:13,22040,'#37 C rx msg D 92,0,5,0,0,27,0,120,0,765,23,0,1,1,13.1593,0,0,0,0,0' 2017-12-19 05:15:51,22142,'#15 A timeout due app due to inactivity' 2017-12-19 05:15:54,22146,'#15 A got login' 2017-12-19 05:16:07,22183,'#37 C rx msg S 51,K,380,5,charging,standard,42,0,10,5,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:16:07,22184,'#37 C rx msg D 92,0,5,0,0,27,0,130,0,826,23,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:17:08,22324,'#37 C rx msg S 51,K,380,4,charging,standard,42,0,10,6,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:17:08,22325,'#37 C rx msg D 92,0,5,0,0,27,0,140,0,887,23,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:18:09,22450,'#37 C rx msg S 51,K,380,4,charging,standard,43,0,10,7,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:18:12,22457,'#37 C rx msg D 92,0,5,0,0,27,0,150,0,948,23,0,1,1,13.1923,0,0,0,0,0' 2017-12-19 05:19:10,22589,'#37 C rx msg S 51,K,380,4,charging,standard,43,0,10,8,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:19:10,22590,'#37 C rx msg D 92,0,5,0,0,27,0,160,0,1009,23,0,1,1,13.1593,0,0,0,0,0' 2017-12-19 05:20:11,22725,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,9,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:20:11,22726,'#37 C rx msg D 92,0,5,0,0,27,0,170,0,1070,23,0,1,1,13.1703,0,0,0,0,0' 2017-12-19 05:21:12,22870,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,10,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:21:12,22871,'#37 C rx msg D 92,0,5,0,0,27,0,180,0,1131,24,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:22:13,22999,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,11,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:22:13,23001,'#37 C rx msg D 92,0,5,0,0,27,0,190,0,1192,24,0,1,1,13.1319,0,0,0,0,0' 2017-12-19 05:23:14,23114,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,12,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:23:14,23115,'#37 C rx msg D 92,0,5,0,0,27,0,200,0,1253,24,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:24:15,23235,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,13,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:24:15,23236,'#37 C rx msg D 92,0,5,0,0,27,0,210,0,1314,25,0,1,1,13.2033,0,0,0,0,0' 2017-12-19 05:25:16,23394,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,14,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:25:16,23395,'#37 C rx msg D 92,0,5,0,0,27,0,220,0,1375,25,0,1,1,13.1978,0,0,0,0,0' 2017-12-19 05:26:17,23536,'#37 C rx msg S 52,K,381,5,charging,standard,44,0,10,15,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.50,96' 2017-12-19 05:26:17,23538,'#37 C rx msg D 92,0,5,0,0,27,0,230,0,1436,25,0,1,1,13.2143,0,0,0,0,0'
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
A default precision just limiting the string output will not do, unless metrics modification triggers also check if change occurred within that precision. As we then effectively lose the precision for internal triggers as well, we can alternatively reduce the precision of the internal representation. Still the default precision then needs to be used throughout all communication messages, else messages with reduced precision will still be sent without notable changes. Btw, happy xmas everyone :) Regards, Michael Am 24.12.2017 um 09:02 schrieb Mark Webb-Johnson:
We should be able to cope with this without having to go back to CRC checksums. The modifier support was supposed to avoid that.
Using checksums isn’t going to help the metric-based protocols like MQTT and bluetooth GATT.
Can we extend OvmsMetric / OvmsMetricFloat to store a default precision (defined when the metric is created)? That is then used when accessing the metric as a string.
Regards, Mark
On 19 Dec 2017, at 4:00 PM, Michael Balzer <dexter@expeedo.de> wrote:
Tom,
you're right, the unnecessary updates result from the high internal value resolution and it's reduction on the msg protocol.
If the SOC changes from 51.00 to 51.01 %, an "S" msg will be sent, although it (currently) only transports "51". Even if it would transport two decimal digits, there still could be fractional parts or float jitter, unless we restrict precision in the metrics itself and use that precision throughout all communications.
I think the best way to solve this is to use msg level CRC checking as V2 did.
Regards, Michael
Am 19.12.2017 um 07:40 schrieb Tom Parker:
At least during charging this appears to be working better, 2 messages per minute for the most part. I always have a client connected as my python client is always connected waiting for messages.
These logs are with 63b87c3f46d5af9eaf49739aa3179c4d026aa3de + a hack to ignore changes in the ms_v_bat_12v_voltage metric (and also nissan leaf remote control changes but they don't affect the telemetry). I'm ignoring the 12v because it appears to have only 3 decimal significant figures of signal and we're monitoring changes on 3 additional significant figures of noise. The following are the values every minute while the car is charging the traction battery and the 12v system is powered by the on board DC-DC.
13.1374 13.1923 13.1813 13.1264 13.1209 13.1978 13.1044 13.1154 13.1538 13.2418 13.1593 13.1813 13.1484 13.1813 13.1374 13.1813 13.1813
It's probably worth storing and even transmitting 4 significant figures, as you can see trends in the noise much more clearly than the v2's 100mV steps, but we shouldn't trigger notifications on the noise. We could also look at averaging or taking the median to increase the signal to noise ratio.
The full log below shows the few minutes as I arrived home and it connected to the wifi (gsm is too unstable to use) and then I plugged in and started charging.
2017-12-19 05:09:33,21226,'#79 A got login' 2017-12-19 05:10:01,21292,'#37 C got login' 2017-12-19 05:10:01,21293,'#37 C rx msg S 50,K,0,0,stopped,standard,42,0,0,0,0,0,13,21,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.50,96' 2017-12-19 05:10:01,21294,'#37 C rx msg D 128,0,5,0,0,27,0,70,0,460,21,1,1,1,12.5934,0,0,0,0,0' 2017-12-19 05:10:02,21295,'#37 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:02,21296,'#37 C rx msg W 0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:03,21297,'#37 C rx msg F 3.0.0/factory/main build (idf v2.1-20-g88ab5d4) Dec 18 2017 09:50:21,,0,1,NL,redacted' 2017-12-19 05:10:03,21298,'#37 C rx msg S 50,K,0,0,stopped,standard,42,0,0,0,0,0,13,21,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.50,96' 2017-12-19 05:10:03,21299,'#37 C rx msg D 128,0,5,0,0,27,0,70,0,460,21,1,1,1,12.5934,0,0,0,0,0' 2017-12-19 05:10:04,21300,'#37 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:04,21301,'#37 C rx msg W 0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:05,21302,'#37 C rx msg F 3.0.0/factory/main build (idf v2.1-20-g88ab5d4) Dec 18 2017 09:50:21,,0,1,NL,redacted' 2017-12-19 05:10:22,21360,'#37 C rx msg S 50,K,511,0,charging,standard,42,0,17,0,0,0,3,1,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,511.50,96' 2017-12-19 05:10:22,21361,'#37 C rx msg D 156,0,5,0,0,27,0,70,0,477,22,1,1,1,12.6758,0,0,0,0,0' 2017-12-19 05:10:23,21362,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:23,21363,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:24,21364,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:27,21372,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:11:19,21481,'#37 C rx msg S 50,K,379,5,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,379.50,96' 2017-12-19 05:11:19,21482,'#37 C rx msg D 156,0,5,0,0,27,0,80,0,521,22,1,1,1,13.1044,0,0,0,0,0' 2017-12-19 05:11:39,21537,'#37 C rx msg D 92,0,5,0,0,27,0,90,0,558,22,0,1,1,13.1374,0,0,0,0,0' 2017-12-19 05:12:03,21599,'#37 C rx msg S 50,K,379,4,charging,standard,42,0,10,1,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,379.50,96' 2017-12-19 05:12:03,21602,'#37 C rx msg D 92,0,5,0,0,27,0,90,0,582,22,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:13:04,21745,'#37 C rx msg S 50,K,380,4,charging,standard,42,0,10,2,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.00,96' 2017-12-19 05:13:04,21746,'#37 C rx msg D 92,0,5,0,0,27,0,100,0,643,22,0,1,1,13.1648,0,0,0,0,0' 2017-12-19 05:14:05,21870,'#37 C rx msg S 50,K,380,4,charging,standard,42,0,10,3,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.00,96' 2017-12-19 05:14:07,21879,'#37 C rx msg D 92,0,5,0,0,27,0,110,0,704,22,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:15:13,22039,'#37 C rx msg S 50,K,380,3,charging,standard,42,0,10,4,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:15:13,22040,'#37 C rx msg D 92,0,5,0,0,27,0,120,0,765,23,0,1,1,13.1593,0,0,0,0,0' 2017-12-19 05:15:51,22142,'#15 A timeout due app due to inactivity' 2017-12-19 05:15:54,22146,'#15 A got login' 2017-12-19 05:16:07,22183,'#37 C rx msg S 51,K,380,5,charging,standard,42,0,10,5,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:16:07,22184,'#37 C rx msg D 92,0,5,0,0,27,0,130,0,826,23,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:17:08,22324,'#37 C rx msg S 51,K,380,4,charging,standard,42,0,10,6,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:17:08,22325,'#37 C rx msg D 92,0,5,0,0,27,0,140,0,887,23,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:18:09,22450,'#37 C rx msg S 51,K,380,4,charging,standard,43,0,10,7,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:18:12,22457,'#37 C rx msg D 92,0,5,0,0,27,0,150,0,948,23,0,1,1,13.1923,0,0,0,0,0' 2017-12-19 05:19:10,22589,'#37 C rx msg S 51,K,380,4,charging,standard,43,0,10,8,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:19:10,22590,'#37 C rx msg D 92,0,5,0,0,27,0,160,0,1009,23,0,1,1,13.1593,0,0,0,0,0' 2017-12-19 05:20:11,22725,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,9,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:20:11,22726,'#37 C rx msg D 92,0,5,0,0,27,0,170,0,1070,23,0,1,1,13.1703,0,0,0,0,0' 2017-12-19 05:21:12,22870,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,10,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:21:12,22871,'#37 C rx msg D 92,0,5,0,0,27,0,180,0,1131,24,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:22:13,22999,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,11,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:22:13,23001,'#37 C rx msg D 92,0,5,0,0,27,0,190,0,1192,24,0,1,1,13.1319,0,0,0,0,0' 2017-12-19 05:23:14,23114,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,12,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:23:14,23115,'#37 C rx msg D 92,0,5,0,0,27,0,200,0,1253,24,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:24:15,23235,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,13,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:24:15,23236,'#37 C rx msg D 92,0,5,0,0,27,0,210,0,1314,25,0,1,1,13.2033,0,0,0,0,0' 2017-12-19 05:25:16,23394,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,14,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:25:16,23395,'#37 C rx msg D 92,0,5,0,0,27,0,220,0,1375,25,0,1,1,13.1978,0,0,0,0,0' 2017-12-19 05:26:17,23536,'#37 C rx msg S 52,K,381,5,charging,standard,44,0,10,15,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.50,96' 2017-12-19 05:26:17,23538,'#37 C rx msg D 92,0,5,0,0,27,0,230,0,1436,25,0,1,1,13.2143,0,0,0,0,0'
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I was thinking that the modification check should be made based on precision. Then, we can still store natively in whatever precision is available. It is only the string output that is affected. Regards, Mark. P.S. Jingle bells ;-) Merry xmas everyone, happy new year, and let’s hoping for some ovms v3 under the xmas tree.
On 24 Dec 2017, at 4:31 PM, Michael Balzer <dexter@expeedo.de> wrote:
A default precision just limiting the string output will not do, unless metrics modification triggers also check if change occurred within that precision.
As we then effectively lose the precision for internal triggers as well, we can alternatively reduce the precision of the internal representation.
Still the default precision then needs to be used throughout all communication messages, else messages with reduced precision will still be sent without notable changes.
Btw, happy xmas everyone :)
Regards, Michael
Am 24.12.2017 um 09:02 schrieb Mark Webb-Johnson:
We should be able to cope with this without having to go back to CRC checksums. The modifier support was supposed to avoid that.
Using checksums isn’t going to help the metric-based protocols like MQTT and bluetooth GATT.
Can we extend OvmsMetric / OvmsMetricFloat to store a default precision (defined when the metric is created)? That is then used when accessing the metric as a string.
Regards, Mark
On 19 Dec 2017, at 4:00 PM, Michael Balzer <dexter@expeedo.de> wrote:
Tom,
you're right, the unnecessary updates result from the high internal value resolution and it's reduction on the msg protocol.
If the SOC changes from 51.00 to 51.01 %, an "S" msg will be sent, although it (currently) only transports "51". Even if it would transport two decimal digits, there still could be fractional parts or float jitter, unless we restrict precision in the metrics itself and use that precision throughout all communications.
I think the best way to solve this is to use msg level CRC checking as V2 did.
Regards, Michael
Am 19.12.2017 um 07:40 schrieb Tom Parker:
At least during charging this appears to be working better, 2 messages per minute for the most part. I always have a client connected as my python client is always connected waiting for messages.
These logs are with 63b87c3f46d5af9eaf49739aa3179c4d026aa3de + a hack to ignore changes in the ms_v_bat_12v_voltage metric (and also nissan leaf remote control changes but they don't affect the telemetry). I'm ignoring the 12v because it appears to have only 3 decimal significant figures of signal and we're monitoring changes on 3 additional significant figures of noise. The following are the values every minute while the car is charging the traction battery and the 12v system is powered by the on board DC-DC.
13.1374 13.1923 13.1813 13.1264 13.1209 13.1978 13.1044 13.1154 13.1538 13.2418 13.1593 13.1813 13.1484 13.1813 13.1374 13.1813 13.1813
It's probably worth storing and even transmitting 4 significant figures, as you can see trends in the noise much more clearly than the v2's 100mV steps, but we shouldn't trigger notifications on the noise. We could also look at averaging or taking the median to increase the signal to noise ratio.
The full log below shows the few minutes as I arrived home and it connected to the wifi (gsm is too unstable to use) and then I plugged in and started charging.
2017-12-19 05:09:33,21226,'#79 A got login' 2017-12-19 05:10:01,21292,'#37 C got login' 2017-12-19 05:10:01,21293,'#37 C rx msg S 50,K,0,0,stopped,standard,42,0,0,0,0,0,13,21,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.50,96' 2017-12-19 05:10:01,21294,'#37 C rx msg D 128,0,5,0,0,27,0,70,0,460,21,1,1,1,12.5934,0,0,0,0,0' 2017-12-19 05:10:02,21295,'#37 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:02,21296,'#37 C rx msg W 0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:03,21297,'#37 C rx msg F 3.0.0/factory/main build (idf v2.1-20-g88ab5d4) Dec 18 2017 09:50:21,,0,1,NL,redacted' 2017-12-19 05:10:03,21298,'#37 C rx msg S 50,K,0,0,stopped,standard,42,0,0,0,0,0,13,21,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.50,96' 2017-12-19 05:10:03,21299,'#37 C rx msg D 128,0,5,0,0,27,0,70,0,460,21,1,1,1,12.5934,0,0,0,0,0' 2017-12-19 05:10:04,21300,'#37 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:04,21301,'#37 C rx msg W 0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:05,21302,'#37 C rx msg F 3.0.0/factory/main build (idf v2.1-20-g88ab5d4) Dec 18 2017 09:50:21,,0,1,NL,redacted' 2017-12-19 05:10:22,21360,'#37 C rx msg S 50,K,511,0,charging,standard,42,0,17,0,0,0,3,1,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,511.50,96' 2017-12-19 05:10:22,21361,'#37 C rx msg D 156,0,5,0,0,27,0,70,0,477,22,1,1,1,12.6758,0,0,0,0,0' 2017-12-19 05:10:23,21362,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:23,21363,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:24,21364,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:27,21372,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:11:19,21481,'#37 C rx msg S 50,K,379,5,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,379.50,96' 2017-12-19 05:11:19,21482,'#37 C rx msg D 156,0,5,0,0,27,0,80,0,521,22,1,1,1,13.1044,0,0,0,0,0' 2017-12-19 05:11:39,21537,'#37 C rx msg D 92,0,5,0,0,27,0,90,0,558,22,0,1,1,13.1374,0,0,0,0,0' 2017-12-19 05:12:03,21599,'#37 C rx msg S 50,K,379,4,charging,standard,42,0,10,1,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,379.50,96' 2017-12-19 05:12:03,21602,'#37 C rx msg D 92,0,5,0,0,27,0,90,0,582,22,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:13:04,21745,'#37 C rx msg S 50,K,380,4,charging,standard,42,0,10,2,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.00,96' 2017-12-19 05:13:04,21746,'#37 C rx msg D 92,0,5,0,0,27,0,100,0,643,22,0,1,1,13.1648,0,0,0,0,0' 2017-12-19 05:14:05,21870,'#37 C rx msg S 50,K,380,4,charging,standard,42,0,10,3,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.00,96' 2017-12-19 05:14:07,21879,'#37 C rx msg D 92,0,5,0,0,27,0,110,0,704,22,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:15:13,22039,'#37 C rx msg S 50,K,380,3,charging,standard,42,0,10,4,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:15:13,22040,'#37 C rx msg D 92,0,5,0,0,27,0,120,0,765,23,0,1,1,13.1593,0,0,0,0,0' 2017-12-19 05:15:51,22142,'#15 A timeout due app due to inactivity' 2017-12-19 05:15:54,22146,'#15 A got login' 2017-12-19 05:16:07,22183,'#37 C rx msg S 51,K,380,5,charging,standard,42,0,10,5,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:16:07,22184,'#37 C rx msg D 92,0,5,0,0,27,0,130,0,826,23,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:17:08,22324,'#37 C rx msg S 51,K,380,4,charging,standard,42,0,10,6,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:17:08,22325,'#37 C rx msg D 92,0,5,0,0,27,0,140,0,887,23,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:18:09,22450,'#37 C rx msg S 51,K,380,4,charging,standard,43,0,10,7,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:18:12,22457,'#37 C rx msg D 92,0,5,0,0,27,0,150,0,948,23,0,1,1,13.1923,0,0,0,0,0' 2017-12-19 05:19:10,22589,'#37 C rx msg S 51,K,380,4,charging,standard,43,0,10,8,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:19:10,22590,'#37 C rx msg D 92,0,5,0,0,27,0,160,0,1009,23,0,1,1,13.1593,0,0,0,0,0' 2017-12-19 05:20:11,22725,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,9,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:20:11,22726,'#37 C rx msg D 92,0,5,0,0,27,0,170,0,1070,23,0,1,1,13.1703,0,0,0,0,0' 2017-12-19 05:21:12,22870,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,10,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:21:12,22871,'#37 C rx msg D 92,0,5,0,0,27,0,180,0,1131,24,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:22:13,22999,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,11,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:22:13,23001,'#37 C rx msg D 92,0,5,0,0,27,0,190,0,1192,24,0,1,1,13.1319,0,0,0,0,0' 2017-12-19 05:23:14,23114,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,12,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:23:14,23115,'#37 C rx msg D 92,0,5,0,0,27,0,200,0,1253,24,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:24:15,23235,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,13,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:24:15,23236,'#37 C rx msg D 92,0,5,0,0,27,0,210,0,1314,25,0,1,1,13.2033,0,0,0,0,0' 2017-12-19 05:25:16,23394,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,14,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:25:16,23395,'#37 C rx msg D 92,0,5,0,0,27,0,220,0,1375,25,0,1,1,13.1978,0,0,0,0,0' 2017-12-19 05:26:17,23536,'#37 C rx msg S 52,K,381,5,charging,standard,44,0,10,15,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.50,96' 2017-12-19 05:26:17,23538,'#37 C rx msg D 92,0,5,0,0,27,0,230,0,1436,25,0,1,1,13.2143,0,0,0,0,0'
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I second that, I can't think of any situation where an internal metrics listener would need to listen to "sub default precision" changes. For situations like that there are other/better solutions. Just needs to be clear from the docs that IsModified() means "…within default precision". I also don't think we get any new problems from extending the value precisions in the V2 messages -- and if so, that's to be seen as bugs in the clients that need to be fixed. Regards, Michael Am 24.12.2017 um 10:25 schrieb Mark Webb-Johnson:
I was thinking that the modification check should be made based on precision. Then, we can still store natively in whatever precision is available. It is only the string output that is affected.
Regards, Mark.
P.S. Jingle bells ;-) Merry xmas everyone, happy new year, and let’s hoping for some ovms v3 under the xmas tree.
On 24 Dec 2017, at 4:31 PM, Michael Balzer <dexter@expeedo.de> wrote:
A default precision just limiting the string output will not do, unless metrics modification triggers also check if change occurred within that precision.
As we then effectively lose the precision for internal triggers as well, we can alternatively reduce the precision of the internal representation.
Still the default precision then needs to be used throughout all communication messages, else messages with reduced precision will still be sent without notable changes.
Btw, happy xmas everyone :)
Regards, Michael
Am 24.12.2017 um 09:02 schrieb Mark Webb-Johnson:
We should be able to cope with this without having to go back to CRC checksums. The modifier support was supposed to avoid that.
Using checksums isn’t going to help the metric-based protocols like MQTT and bluetooth GATT.
Can we extend OvmsMetric / OvmsMetricFloat to store a default precision (defined when the metric is created)? That is then used when accessing the metric as a string.
Regards, Mark
On 19 Dec 2017, at 4:00 PM, Michael Balzer <dexter@expeedo.de> wrote:
Tom,
you're right, the unnecessary updates result from the high internal value resolution and it's reduction on the msg protocol.
If the SOC changes from 51.00 to 51.01 %, an "S" msg will be sent, although it (currently) only transports "51". Even if it would transport two decimal digits, there still could be fractional parts or float jitter, unless we restrict precision in the metrics itself and use that precision throughout all communications.
I think the best way to solve this is to use msg level CRC checking as V2 did.
Regards, Michael
Am 19.12.2017 um 07:40 schrieb Tom Parker:
At least during charging this appears to be working better, 2 messages per minute for the most part. I always have a client connected as my python client is always connected waiting for messages.
These logs are with 63b87c3f46d5af9eaf49739aa3179c4d026aa3de + a hack to ignore changes in the ms_v_bat_12v_voltage metric (and also nissan leaf remote control changes but they don't affect the telemetry). I'm ignoring the 12v because it appears to have only 3 decimal significant figures of signal and we're monitoring changes on 3 additional significant figures of noise. The following are the values every minute while the car is charging the traction battery and the 12v system is powered by the on board DC-DC.
13.1374 13.1923 13.1813 13.1264 13.1209 13.1978 13.1044 13.1154 13.1538 13.2418 13.1593 13.1813 13.1484 13.1813 13.1374 13.1813 13.1813
It's probably worth storing and even transmitting 4 significant figures, as you can see trends in the noise much more clearly than the v2's 100mV steps, but we shouldn't trigger notifications on the noise. We could also look at averaging or taking the median to increase the signal to noise ratio.
The full log below shows the few minutes as I arrived home and it connected to the wifi (gsm is too unstable to use) and then I plugged in and started charging.
2017-12-19 05:09:33,21226,'#79 A got login' 2017-12-19 05:10:01,21292,'#37 C got login' 2017-12-19 05:10:01,21293,'#37 C rx msg S 50,K,0,0,stopped,standard,42,0,0,0,0,0,13,21,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.50,96' 2017-12-19 05:10:01,21294,'#37 C rx msg D 128,0,5,0,0,27,0,70,0,460,21,1,1,1,12.5934,0,0,0,0,0' 2017-12-19 05:10:02,21295,'#37 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:02,21296,'#37 C rx msg W 0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:03,21297,'#37 C rx msg F 3.0.0/factory/main build (idf v2.1-20-g88ab5d4) Dec 18 2017 09:50:21,,0,1,NL,redacted' 2017-12-19 05:10:03,21298,'#37 C rx msg S 50,K,0,0,stopped,standard,42,0,0,0,0,0,13,21,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.50,96' 2017-12-19 05:10:03,21299,'#37 C rx msg D 128,0,5,0,0,27,0,70,0,460,21,1,1,1,12.5934,0,0,0,0,0' 2017-12-19 05:10:04,21300,'#37 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:04,21301,'#37 C rx msg W 0,0,0,0,0,0,0,0,0' 2017-12-19 05:10:05,21302,'#37 C rx msg F 3.0.0/factory/main build (idf v2.1-20-g88ab5d4) Dec 18 2017 09:50:21,,0,1,NL,redacted' 2017-12-19 05:10:22,21360,'#37 C rx msg S 50,K,511,0,charging,standard,42,0,17,0,0,0,3,1,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,511.50,96' 2017-12-19 05:10:22,21361,'#37 C rx msg D 156,0,5,0,0,27,0,70,0,477,22,1,1,1,12.6758,0,0,0,0,0' 2017-12-19 05:10:23,21362,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.22,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:23,21363,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:24,21364,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:10:27,21372,'#37 C rx msg S 50,K,378,0,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,378.50,96' 2017-12-19 05:11:19,21481,'#37 C rx msg S 50,K,379,5,charging,standard,42,0,10,0,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,379.50,96' 2017-12-19 05:11:19,21482,'#37 C rx msg D 156,0,5,0,0,27,0,80,0,521,22,1,1,1,13.1044,0,0,0,0,0' 2017-12-19 05:11:39,21537,'#37 C rx msg D 92,0,5,0,0,27,0,90,0,558,22,0,1,1,13.1374,0,0,0,0,0' 2017-12-19 05:12:03,21599,'#37 C rx msg S 50,K,379,4,charging,standard,42,0,10,1,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,379.50,96' 2017-12-19 05:12:03,21602,'#37 C rx msg D 92,0,5,0,0,27,0,90,0,582,22,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:13:04,21745,'#37 C rx msg S 50,K,380,4,charging,standard,42,0,10,2,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.00,96' 2017-12-19 05:13:04,21746,'#37 C rx msg D 92,0,5,0,0,27,0,100,0,643,22,0,1,1,13.1648,0,0,0,0,0' 2017-12-19 05:14:05,21870,'#37 C rx msg S 50,K,380,4,charging,standard,42,0,10,3,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.00,96' 2017-12-19 05:14:07,21879,'#37 C rx msg D 92,0,5,0,0,27,0,110,0,704,22,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:15:13,22039,'#37 C rx msg S 50,K,380,3,charging,standard,42,0,10,4,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:15:13,22040,'#37 C rx msg D 92,0,5,0,0,27,0,120,0,765,23,0,1,1,13.1593,0,0,0,0,0' 2017-12-19 05:15:51,22142,'#15 A timeout due app due to inactivity' 2017-12-19 05:15:54,22146,'#15 A got login' 2017-12-19 05:16:07,22183,'#37 C rx msg S 51,K,380,5,charging,standard,42,0,10,5,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:16:07,22184,'#37 C rx msg D 92,0,5,0,0,27,0,130,0,826,23,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:17:08,22324,'#37 C rx msg S 51,K,380,4,charging,standard,42,0,10,6,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:17:08,22325,'#37 C rx msg D 92,0,5,0,0,27,0,140,0,887,23,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:18:09,22450,'#37 C rx msg S 51,K,380,4,charging,standard,43,0,10,7,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:18:12,22457,'#37 C rx msg D 92,0,5,0,0,27,0,150,0,948,23,0,1,1,13.1923,0,0,0,0,0' 2017-12-19 05:19:10,22589,'#37 C rx msg S 51,K,380,4,charging,standard,43,0,10,8,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,380.50,96' 2017-12-19 05:19:10,22590,'#37 C rx msg D 92,0,5,0,0,27,0,160,0,1009,23,0,1,1,13.1593,0,0,0,0,0' 2017-12-19 05:20:11,22725,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,9,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:20:11,22726,'#37 C rx msg D 92,0,5,0,0,27,0,170,0,1070,23,0,1,1,13.1703,0,0,0,0,0' 2017-12-19 05:21:12,22870,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,10,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:21:12,22871,'#37 C rx msg D 92,0,5,0,0,27,0,180,0,1131,24,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:22:13,22999,'#37 C rx msg S 51,K,381,4,charging,standard,43,0,10,11,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:22:13,23001,'#37 C rx msg D 92,0,5,0,0,27,0,190,0,1192,24,0,1,1,13.1319,0,0,0,0,0' 2017-12-19 05:23:14,23114,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,12,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:23:14,23115,'#37 C rx msg D 92,0,5,0,0,27,0,200,0,1253,24,0,1,1,13.1813,0,0,0,0,0' 2017-12-19 05:24:15,23235,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,13,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:24:15,23236,'#37 C rx msg D 92,0,5,0,0,27,0,210,0,1314,25,0,1,1,13.2033,0,0,0,0,0' 2017-12-19 05:25:16,23394,'#37 C rx msg S 52,K,381,4,charging,standard,43,0,10,14,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.00,96' 2017-12-19 05:25:16,23395,'#37 C rx msg D 92,0,5,0,0,27,0,220,0,1375,25,0,1,1,13.1978,0,0,0,0,0' 2017-12-19 05:26:17,23536,'#37 C rx msg S 52,K,381,5,charging,standard,44,0,10,15,0,0,3,1,0,0,0,0,63.13,0,0,0,0,-1,0,0,0,0,0,0,0,-0.00,381.50,96' 2017-12-19 05:26:17,23538,'#37 C rx msg D 92,0,5,0,0,27,0,230,0,1436,25,0,1,1,13.2143,0,0,0,0,0'
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
participants (3)
-
Mark Webb-Johnson -
Michael Balzer -
Tom Parker