Steve, What is the current status of the changes you have been making to the locations system? I have a user asking why:
location set Likini
location action enter Likini notiffy entered
****: location action enter Likini notify entered
Unregconised command Usage: location action enter <location> acc <profile> Usage: location action enter <location> homelink 1|2|3 Usage: location action enter <location> notify <text> Was this ever completed? Regards, Mark
Mark, Implementing actions is still on my TODO list, but the location command to configure the actions was working. The "Unrecognized command" response indicates that something has broken. It should allow the command and store the requested action, but then show the warning "NOTE: Actions are not implemented yet!" You will see that same warning after the output of the "location list" command. Part of the work I completed was an enhancement to the command parsing to allow lists of keywords following a variable token, like you see acc, homelink or notify after <location> in the Usage output. This code was a bit tricky. I have not paid close attention to recent commits to any of the command processing code, so maybe some change was made that was incompatible with my enhancement. I will investigate. -- Steve On Tue, 5 May 2020, Mark Webb-Johnson wrote:
What is the current status of the changes you have been making to the locations system?
I have a user asking why:
>location set Likini
>location action enter Likini notiffy entered
>****: location action enter Likini notify entered
Unregconised command
Usage: location action enter <location> acc <profile>
Usage: location action enter <location> homelink 1|2|3
Usage: location action enter <location> notify <text>
Was this ever completed?
Regards, Mark
Mark & Steve, is "location action" a convenience wrapper for the event script system? If so, should we leverage it to events in general, i.e. "event action …"? Regards, Michael Am 05.05.20 um 07:13 schrieb Stephen Casner:
Mark,
Implementing actions is still on my TODO list, but the location command to configure the actions was working. The "Unrecognized command" response indicates that something has broken. It should allow the command and store the requested action, but then show the warning "NOTE: Actions are not implemented yet!" You will see that same warning after the output of the "location list" command.
Part of the work I completed was an enhancement to the command parsing to allow lists of keywords following a variable token, like you see acc, homelink or notify after <location> in the Usage output. This code was a bit tricky. I have not paid close attention to recent commits to any of the command processing code, so maybe some change was made that was incompatible with my enhancement.
I will investigate.
-- Steve
On Tue, 5 May 2020, Mark Webb-Johnson wrote:
What is the current status of the changes you have been making to the locations system?
I have a user asking why:
>location set Likini
>location action enter Likini notiffy entered
>****: location action enter Likini notify entered
Unregconised command
Usage: location action enter <location> acc <profile>
Usage: location action enter <location> homelink 1|2|3
Usage: location action enter <location> notify <text>
Was this ever completed?
Regards, Mark
OvmsDev mailing list OvmsDev@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
Mark and Michael, I have fixed the problem that caused the "location action" command to always say the command was unrecognized. The current status of this project is that the location command stores action parameters in the config attached to the location name and position entries that existed before I began this project. My plan was to implement the actions directly, not through scripts. Mark specified a concept of charging profiles to be implemented in the vehicle code and the location actions could select one of those profiles, or trigger a homelink action, or send a notification text. The idea of this being a convenience wrapper for scripts is a reasonable one except that figuring out what configuration state is represented by a collection of scripts is difficult. I suppose one way to roughly manage that would be to keep the state as now but then have a dedicated script subdirectory that gets blown away and recreated from the state every time the system starts up. Since this command is storing the actions with the locations, that does not immediately generalize to events. A parallel repository of event actions could be implemented. -- Steve
participants (3)
-
Mark Webb-Johnson -
Michael Balzer -
Stephen Casner