Hi All,
I've already received some feedback from @Berkut (thank you) and fixed a couple of small problems. One was a typo in the release notes and the other was a problem with the Property table on the Trips tab. Neither should stop you from testing v0.25.00. I'll wait to see if there are any other bug reports before releasing an updated version.
He also asked for a use case for the "Unplugged at time:" notification. Imagine that you plan to charge your car in the evening, but when you get home from work you forget to plug it in. An "Unplugged at time:" notification could alert you to that fact at 10PM so you have a chance to go plug it rather than waking to an uncharged car. This was suggested by a couple of users.
If you don't care about the implementation, you can skip the rest of this.
The way that notifications work under the covers is that each notification corresponds to a Trigger object. A Trigger has 3 parts: a subject, a predicate, and a target. For example, with "SOC Hits or Exceeds", the subject is State of Charge (SOC), the predicate is "Hits or Exceeds", and the target is the number you set with the slider (or by typing it in). Every time any part of the app queries the State of Charge, the Trigger will be asked to evaluate the predicate using the current value. If the predicate is true, a notification is sent.
There's actually one more part to the Trigger - an optional "at time" parameter. If this parameter is set then the Trigger will only go off at that time. That means it will go off at most once per day. In actuality there is a small grace period. If you start the app very soon after the Trigger time, it will still allow the Trigger to go off if the predicate is satisfied.
So, for "Unplugged at time", the Trigger is:
Subject: Pilot Current (If 0, your car is not plugged in)
Predicate: Less Than
Target: 1
At Time: Time selected by user
If you set up this notification and it goes off, the message you will receive is: "Input Power is less than 1.0". This is automatically generated based on the Subject/Predicate/Target. All of the existing notifications are specified in this way and lots of other triggers could be as well. This will make it easier to implement other notification types in the future if there are useful ones to add.
I have no current plans to do this, but in theory the UI could become completely general. Each notification could be specified in the UI as:
- Dropdown list that allows you to select a Subject such as State of Charge, Speed, or any other data element that can be queried (e.g. range)
- Dropdown list that allows you to select a Predicate. The predicates supported currently are:
- Hits or Exceeds: Takes previous value and current value into consideration. Returns true if was < target and now is >= target
- Falls Below: Takes previous value and current value into consideration. Returns true if was >= target and now is < target
- Becomes: Takes previous value and current value into consideration. Returns true if was != target and now is == target
- Any Change: Any change to the value
- Less Than: Ignores previous value. Returns true if current value < target
- Greater Than: Ignores previous value. Returns true if current value > target
- Equal To: Ignores previous value. Returns true if current value == target
- Target field: This field type would change depending on the subject and predicate. For example, for SOC it would be a Number and for Charge Status it would be a drop down list of possible values
- At Time: Specifies an optional time.
As I said, I have no plans to implement this UI, but it is possible based on the underlying implementation.
