![]() ![]() I extended the solution so that it can contemplate both cases. What I end up realizing is that maybe not all protocols can be easily modeled as a generic to all protocol template. I updated the branch with the implementation of two commands from GT06 (the ones matching the commands I defined before). ![]() If we should have this discussion in github (whether in the issue or as a pull request), let me know and I'll move all of this hehe If you have any question about it I am more than willing to answer them.Īny suggestions is, of course, very appreciated. And sorry for the length of the post, but I wanted to explain all the decisions I took so you can evaluate it better. Well I think this covers everything and I really hope that you are interested in adding this feature in your current roadmap. Just a little digression but I am curious about it. It is working now but made me wonder why isn't traccar using any existing libraries (like GSON) to parse and produce JSON. ![]() I also created some test for all the converters. On a less important note, I extended the JSON converter API to handles enums and nested objects (this is necessary for each command subclass). So if someone has a GPS with not so common feature or protocol extension, then it can use it right away. It is called debug, but it could also be called ad-hoc, and would give the feature of sending an ad-hoc command without the need of having it inside traccar. That allowed me to try different commands to see what they do (since, hey, protocol documentation is not something that is really accurate. Since I am not familiar with this protocols, I created a servlet with a "debug" service that send a raw command (literally whatever the user sent in the json) to the gps. Besides, if the protocol needs some more logic, then it is more natural to handle it in code instead of a configuration file/database. Mainly, I believe that this is an implementation issue which is not something the user should modify, as the protocol will not change. This takes me to why did I defined the commands in code, instead of putting them in the database or in the configuration file. But if it were that the a protocol has a more complicated definition, then it can override the sendCommand message and implement it that way, without affecting the rest of the code. So for each type of command there is a hierarchy called GpsCommand which defines this common part.Īgain, as far as I understand (but this time I am less sure he), the protocols usually sends a single message to the gps and so this implementation covers that case. The second part is the execution of the message (ndCommand) where it takes the template and changes the parameters according to the current requested command.Īs far as I understand (I am still new to GPRS GPS command protocols) all the parameters for a command type (for instance, to set the frequency of locations notifications) are the same, but the format of the message is different. The base implementation is just a Map of Command Type => String, where the String is the template which has placeholders for the actual values. The first part is the template for each command which is defined in each protocol subclass in loadCommandsTemplates (which is protocol dependent). The command message is split in two parts. And I also moved the TrackerServer initialization to this hierarchy, so everything that is related to a given protocol, can be found starting in its corresponding Protocol subclass. This hierarchy allowed me to put the command templates specifically for each protocol. This seemed better than selecting the protocol for each device manually since: a) If you change your SIM to another gps with a different protocol, everything is handled automatically b) It is tedious to set it manually. So as soon a device connects to the server, it gets associated with the protocol it connected. To identify which protocol corresponds to what devices, I hung on the identify method on the ProtocolDecoder class. The biggest change you'll find is that I created a Protocol hierarchy so all protocols can be treated polymorphically for whatever operation is needed. First of all, I made quite a bit of code movements, which I'll explain below, so don't panic, everything can be changed.Īll the work is in this branch (which is rebased against your master as of right now): Since I am in need of sending commands to the gps devices I implemented the feature and so I wanted to share the code with you. model.I am not sure where to write about this, since there is an open issue in github ( #7), but I will go here since it seems more constructive discussion oriented :) ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |