8000 Recorder/ocat do not seem to be able to access stored location updates that got published as CSV · Issue #205 · owntracks/recorder · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Recorder/ocat do not seem to be able to access stored location updates that got published as CSV #205

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
8000
hoalex opened this issue Jul 19, 2017 · 6 comments
Closed

Recorder/ocat do not seem to be able to access stored location updates that got published as CSV #205

hoalex opened this issue Jul 19, 2017 · 6 comments

Comments

@hoalex
Copy link
Contributor
hoalex commented Jul 19, 2017

Hi there,

I'm trying to get Owntracks Pico (thanks for this great idea, btw) working with the Recorder (installed on Debian Stretch, latest version from your repository).
The Pico part works just fine, i.e. location updates are correctly published in CSV syntax to my MQTT broker (I'm using a slighty modified version of your Homie sketch so it works with Homie v2).

Inside the web interface of the Recorder, I am able to see my GPS sensor on the live map. The Recorder also saves the location updates in the corresponding *.rec files, which look like the following:

2017-07-19T09:21:49Z    csv                     {"_type":"location","t":"p","tid":"c8","tst":1500456109,"lat":redacted,"lon":redacted,"cog":60,"vel":1,"alt":270,"dist":0,"trip":24000,"csv":true}

What is not working is the "points" and "tracks" options – Recorder does not show any points, but simply an empty map.

Looking at ocat, I tried the following commands to debug this situation:

  • ocat --list shows: {"results":["wemos-gps"]}
  • ocat --list --user wemos-gps shows {"results":["gps","-implementation","-mac","-homie","-stats","-fw","-online","-localip","-name"]}
  • ocat --list --user wemos-gps --device gps shows {"results":["/var/spool/owntracks/recorder/store/rec/wemos-gps/gps/2017-07.rec"]}
  • ocat --last --user wemos-gps --device gps shows [{"_type":"location","t":"p","tid":"c8","tst":1500456109,"lat":redacted,"lon":redacted,"cog":60,"vel":1,"alt":270,"dist":0,"trip":24000,"csv":true,"topic":"homie/wemos-gps/gps/csv","username":"redacted","device":"gps","ghash":redacted,"isotst":"2017-07-19T09:21:49Z","disptst":"2017-07-19 09:21:49"}]

So far, so good (I guess?). But when trying to get the last locations (via ocat --user wemos-gps --device gps) I get the following output: {"locations":[]}

I guess that this is the reason why recorder also does not see any historic data.

To further narrow down this issue, I set up Owntracks on my iOS device. It does not have this problem, i.e. I can see the historic points in Recorder and also retrieve them via ocat. So it seems that this has something to do with the way that stored CSV entries are processed by ocat and Recorder?

If you need any more input, please let me know.

Regards
Alex
@jpmens
Copy link
Member
jpmens commented Jul 19, 2017

Judging by this piece:

2017-07-19T09:21:49Z    csv                     {"_type":"

you are publishing to ../csv, am I right? If so please change to publish to the base topic, i.e. owntracks/wemos-gps/gps (owntracks/username/devicename).

@hoalex
Copy link
Contributor Author
hoalex commented Jul 19, 2017

You are right, they are published to ../csv. With a little bit of sed-magic I was able to make the recorder show the entries: by substituting csv with * in the rec-file. So this is definitely the root cause.

I have to figure out how to make Homie perform the publish on the base path... as far as I know, Homie uses the following scheme by default: homie/<device-name>/<node-name>/<node-property>, where device-name is wemos-gps, node-name is gps and its property is csv.
I guess I will have to either modify Homie or the Recorder to make this work for me.

@jpmens
Copy link
Member
jpmens commented Jul 19, 2017

Don't modify either. Let's think about this for a moment.
Can you try setting Homie's property from "csv" to "" (empty string)? I don't really think that'll work though.

If that doesn't work: can you confirm the device is publishing to owntracks/user/device/csv? And if you change Homie's property from "csv" to "pico", can you confirm the device then publishes to owntracks/user/device/pico? (I ought to know this, but I've forgotten and cannot test now.)

If that is the case, I propose a change to Recorder: I would consider all publishes to ../pico to actually be root publishes (without /pico on them). That would solve it for you.

@hoalex
Copy link
Contributor Author
hoalex commented Jul 19, 2017

Can you try setting Homie's property from "csv" to "" (empty string)? I don't really think that'll work though.

Actually, it does! According to mosquitto_sub, the publish is performed at homie/wemos-gps/gps/ (notice the slash at the end), but this does not seem to irritate Recorder.

For the sake of completeness:

If that doesn't work: can you confirm the device is publishing to owntracks/user/device/csv?

When you name the node property "csv", it does publish to the path you mentioned.

And if you change Homie's property from "csv" to "pico", can you confirm the device then publishes to owntracks/user/device/pico?

Yes again.

The current "workaround" is good enough for me. Well, at least until Homie introduces some breaking changes ;-)
I don't know how much work it would be for you to implement the pico-specific behavior you outlined above, so maybe you can categorize this under low-priority. For me, the way it works now is fine, but it would probably be a bit nicer to have a specific sub-topic under which the publish takes place, just to be fully Homie spec-compliant.

Thanks again for your help, it's much appreciated! 👍

jpmens added a commit that referenced this issue Jul 19, 2017
@jpmens
NEW: Add support for OwnTracks Pico by pretending ../pico is a base…
b8bfa75 
… topic

	addresses #205
@jpmens
Copy link
Member
jpmens commented Jul 19, 2017

When I now publish a payload (JSON or CSV) to owntracks/hoalex/wemos/pico I get the following entry in my .rec file:

$ tail -1 JP3/rec/hoalex/wemos/2017-07.rec
2017-07-19T20:26:04Z    *                       {"_type":"location","cog":323,"batt":11, ...

which ought to be what you need.

If you can test this I'd appreciate it, otherwise you have to wait until the next release.

@hoalex
Copy link
Contributor Author
hoalex commented Jul 20, 2017

I re-compiled Recorder and tested the changes with my physical device (setting the node property name to pico), and indeed the Recorder now shows the points just fine 👍

A message to

homie/wemos-gps/gps/pico c8,5970825A,p,xxx,yyy,0,1,28,0,0

generates

2017-07-20T10:13:50Z	*                 	{"_type":"location","t":"p","tid":"c8","tst":1500545630,"lat":xxx,"lon":yyy,"cog":0,"vel":1,"alt":280,"dist":0,"trip":0,"csv":true}

I think we can consider this ticket closed then :-) Thanks!

@hoalex hoalex closed this as completed Jul 20, 2017
jpmens added a commit that referenced this issue Feb 12, 2018
@jpmens
2018-02-12 version 0.7.3
d13232e 
- FIX: GPX exporter gets xmlns (#215)
- FIX: wait on start of systemd to allow Mosquitto to start (#185)
- FIX: s/json_remove_from_parent/_delete/g
- NEW: Add support for OwnTracks Pico by pretending `../pico` is a base topic (#205)
- UPD: rollback: cards are now once again stored at user/device/user-device.json (but map/table also uses user/user.json if it exists)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jpmens @hoalex
0