Tom, Sorry to hear about this. I had one other similar report, but still trying to find out the cause. In the early days, the rangers used to unplug OVMS, but now they just seem to leave it in place (particularly as they don't have firmware upgrades to do so don't usually need that DIAG connector). I'm traveling at the moment (back on Sunday), so hard to see too much. Regarding the setting, you are correct - it is +8 to disable the alerts (so 9 for your 1.5 car). I checked the utilisation logs, and it looks like your car did have a bump in data usage. You can check in the Apps, but it looks to be around 200KB so hopefully not too bad. For the problem itself, I think it can be caused by one of two cases. Either (a) two different alerts (so the system is swapping between both), or (b) an alert-on-alert-off toggle type of situation. Due to the way that we queue the alerts (only 1 queued), it is hard to know which. I did think of changing the code slightly to cope with (b) - by making the alert safety timer not reset on a alert-off, but to carry on counting down to zero. If we make the alert safety timer a general mechanism to allow only one alert every N seconds, that will reduce the impact but also stop it being able to report different alerts (which is really nice at the moment). Perhaps a better solution is a rate-limit (an average of 1 every few minutes, but with an initial balance of perhaps 5?). That is quite simple to implement: just a single byte value saying how much alert balance remaining there is, decrement it every time an alert is raised, drop alerts if the counter value is zero, and increment the counter (to a maximum of perhaps 5) every few minutes. Regards, Mark. On 15 May, 2013, at 12:42 AM, Tom Saxton wrote:
I took our Roadster in for service yesterday, and this morning I noticed that it's sending the same vehicle alert repeatedly at an alarming rate, like once a second.
Vehicle Alert Code: TR1N/29 (00000000)
I tried calling the store to ask them to unplug the OVMS, but they weren't answering the phone (it was before they were officially open).
I then tried to turn off GPRS to get it to stop spewing. I sent a PARAMS command to only allow SMS, but that didn't work. Thinking that it might need to reboot to get the command to stick, I sent a RESET command, which did the trick. I see there's code to call vehicle_initialise() after handling a PARAMS command, so I'm a little surprised the RESET was needed.
Then I remembered that version 2.3.2 mentioned a way to turn off vehicle alerts. From the release notes:
## Add facility to suppress vehicle alerts via carbits feature +16
But Mark's email from April 16th says:
Yes, car bits feature 14, add 8 to the value (bit #3) to suppress vehicle alerts via push notification.
From looking at the code, it looks like adding 8 (setting the 8 bit in binary) to the value for Feature 14 will turn off sending the vehicles alerts to the server.
I have Feature 14 set to 1 to indicate that ours is a 2008 Roadster, so I added 1+8=9 and sent "FEATURE 14 9", then re-enabled SMS,IP, and RESET. That restored network comms so the OVMS app is working again, and I'm not seeing the alerts any more.
Finally, I notice there's code to prevent OVMS from sending the same alert more than once per minute, but if another code comes in, or the alert gets cancelled, the 60-second timer gets cleared.
I wonder if that code should be more aggressive about limiting alert frequency. I suspect what's happening with the Roadster is that it's repeatedly firing and then dismissing an alert message (presumably related to the service they are doing), which completely circumvents the timer, resulting in a ridiculous number of alert messages.
I suspect this was happening all night, so my next phone bill may be interesting at $2/MB.
Tom
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev