Excuse me but if you say that Attribute copying is now done after hours calculation. How should I do now to make the engine hours work?, you tell me that the problem is that you think it may be related to attribute copying. So i disable it using <entry key="processing.copyAttributes.enable">false</entry>
Sorry, I'm a bit confused with the solution or because I didn't understand well or my translation is not helping me.
Thanks in advance
Hi, currently we back to used 5.12 instead. the engine hours back to continue counted. It must be like that.
I think I probably need to replace the new devices. the one that report the ignition directly and then update to a new version again.
thank you everyone.
I think you misread my comments. There is no way to fix it. I was explaining why it worked before.
Friend Theerayuttu al devices i have use protocol GPS103 or G06 both report the ignition directly. I fact ingition on/off is detected and reported perfectly.
Anton, maybe a i misread your comments. So, engine hours are not calculated based on the ignition status? I mean, in what ideal situation would they work in version 6.1? Or do they just not work anymore?
tecseguridad, but we have this issue from only devices are not reported ignition directly and used computed attribute to assign ignition value. I think yours should be able to work.
I try opening the source code (server) and check the engine hours calculation. It's supposed to be calculated from the ignition key value. If it comes directly from the device, it should calculate it automatically.
However as Anton's comments, if it uses the ignition value from the computes attribute, it won't calculate it anymore. I understand it like this.
So, could you check if you've used the ignition value from the computes attribute or not?
Theerayuttu thanks for answer me. Im not using computes attribute. Ingition on/off is detected directly. Does the engine hours feature work for you? What GPS protocol do you use?
Regards
We were reviewing the code and we understood that the engine hours are calculated from the data in the 'fix_time' database. Is this correct? This means that if I have filters activated, there are 'fix_time' values that would not be taken into account.
Greetings, thanks for your time and answers
This topic has helped me to learn more about my devices and how they operate. Therefore, I have only one remaining question: Is there a possibility to develop a function through Traccar support that ensures a report of the ignition status of my devices in the new versions of Traccar? It is imperative for me to address this concern, as I wish to continue updating to newer versions without encountering similar issues.
tecseguridad, we used startek, h02, meiligao protocol, but does not work for meiligao.
look at the source code, it uses fixtime to calculation the number of hours. may possible that problem come from this fixtime.
Thanks Theerayuttu, i look at source code and check it uses fixtime and ingition status, but jus if ignition is received in every package because of cache like in osmand protocol.
In the gt06 protocol, for example, the ignition status is sent every 2 minutes. But I wonder if there's a way to store that state? That is, if a package arrives with the ignition on and then another with the ignition off within a period of time, it should be calculable, don't you think?
This should fix the problem:
https://github.com/traccar/traccar/commit/69046d9d687997f3631019adfcb6bf437c4805f9
Computed attributes will run before hours handler.
It won't work, as I said. I explained why it worked before by accident and incorrectly.