Get coordinates of a satellite from http request

I want to retrieve the coordinates of a satellite, so I can display it.

I retrieve the TLE data via an HTTP request.
But I can't put it in the right format for the TLE function to convert the TLE data into Cartesian coordinates.
I can't find any information about the function that can help me, so I rely on you.

did you read the nodes notes and look at the examples?

The nodes notes don't give any example, that's the problem.
Even if i didn't see it.

The examples are to use, the function "satellite" and not "TLE" that's my problem.
Mine is not in the list so i have to give him the data

So have you send the output of the http-request node to a debug node so you can see what the data looks like?

Yes, it looks like a string including the 3 lines of the TLE data

Looking at the node's code, it doesn't appear to allow the TLE data to be supplied through input messages:

Looking at your flow above, it looks like you're trying to use a dynamic set of TLE data. Even when the parsing of your http response would go well, you're not able to use them with this node in its current form. I think you've to file an issue for this use case on the node's repository.

Do you think it's possible to modify the source code to be able to use my http response ?

you need to send the data to a split node then after that send a msg setting
to the corect values and it will work.

I'm creating a issue on the node suggestion the author add such an example.

If you can provide the example I'm sure we can get it fixed/added.
I'm sure a PR would be appreciated.

You actually can send in the data, you need to set msg.satid, msg.tel1 and msg.tel2. The best way I found is to send the output of the http-in node to a split node. Send the output to the split to a switch and test for a 0, 1, 2 and 3. Send each output to a change node.
In the first change node, set msg.satid to msg.payload
In the second, set msg.tel1 to msg.payload
In the third, set msg.tel2 to msg.payload
In the forth, set msg.payload to a timestamp
and send the result to the TLE node

[{"id":"f7fe6450.9276b8","type":"inject","z":"ae5ddf35.d207","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":140,"y":240,"wires":[["430e2c33.47bc54"]]},{"id":"430e2c33.47bc54","type":"http request","z":"ae5ddf35.d207","name":"","method":"GET","ret":"txt","paytoqs":false,"url":"","tls":"","persist":false,"proxy":"","authType":"","x":150,"y":300,"wires":[["ea5a9d7e.d55be8"]]},{"id":"ea5a9d7e.d55be8","type":"split","z":"ae5ddf35.d207","name":"","splt":"\\n","spltType":"str","arraySplt":1,"arraySpltType":"len","stream":false,"addname":"","x":150,"y":360,"wires":[["3ad99d04.972882"]]},{"id":"3ba481d8.ac070e","type":"tle","z":"ae5ddf35.d207","satid":"M6P","tle1":"1 44109U 19018AF  20099.13260841  .00002228  00000-0  73746-4 0  9997","tle2":"2 44109  97.4708 168.0219 0060915 100.5916 315.6514 15.30648385 56824","coordsys":"latlongdeg","name":"","x":130,"y":560,"wires":[["3a2d4ef5.72f2a2"]]},{"id":"3a2d4ef5.72f2a2","type":"debug","z":"ae5ddf35.d207","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":130,"y":620,"wires":[]},{"id":"3ad99d04.972882","type":"switch","z":"ae5ddf35.d207","name":"","property":"parts.index","propertyType":"msg","rules":[{"t":"eq","v":"0","vt":"num"},{"t":"eq","v":"1","vt":"num"},{"t":"eq","v":"2","vt":"num"},{"t":"else"}],"checkall":"true","repair":false,"outputs":4,"x":130,"y":420,"wires":[["a1480d7a.f1f94"],["5608bb5.0d34fc4"],["eb8bf9ca.b4a63"],["b202c21e.2e4568"]]},{"id":"a1480d7a.f1f94","type":"change","z":"ae5ddf35.d207","name":"","rules":[{"t":"set","p":"satid","pt":"msg","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":360,"y":360,"wires":[["2200b141.a8392e"]]},{"id":"5608bb5.0d34fc4","type":"change","z":"ae5ddf35.d207","name":"","rules":[{"t":"set","p":"tel1","pt":"msg","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":350,"y":400,"wires":[["2200b141.a8392e"]]},{"id":"eb8bf9ca.b4a63","type":"change","z":"ae5ddf35.d207","name":"","rules":[{"t":"set","p":"tel2","pt":"msg","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":350,"y":440,"wires":[["2200b141.a8392e"]]},{"id":"2200b141.a8392e","type":"join","z":"ae5ddf35.d207","name":"","mode":"auto","build":"string","property":"payload","propertyType":"msg","key":"topic","joiner":"\\n","joinerType":"str","accumulate":false,"timeout":"","count":"","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"","reduceFixup":"","x":590,"y":420,"wires":[["3ba481d8.ac070e"]]},{"id":"b202c21e.2e4568","type":"change","z":"ae5ddf35.d207","name":"set timestamp","rules":[{"t":"set","p":"payload","pt":"msg","to":"","tot":"date"}],"action":"","property":"","from":"","to":"","reg":false,"x":360,"y":480,"wires":[["2200b141.a8392e"]]}]

Did you confirm this to work? Looking at the code it would be great if that was an option, but it wouldn't work in its current form. Because yes for msg.satid, but I can't see msg.tle1 and msg.tle2 to be working

@afelix yup it does work, I just added an example to my prior post

Because based on the below, msg.tle1 and msg.tle2 are ignored regardless the value of the config parameters in the node. In fact, those properties aren't mentioned as such.

They are mentioned as properties from the node configuration, but not on the message object.

Give my flow a try and see what you get...

Maybe I did something bad but it doesn't work for me.
I used "string" to split.

Try the example I posted in my post above. you need to use the 'split' node

@dceejay I've just add a PR to the node with the example I gave above.

The timestamp overwrites all of my other msg

Did you use the flow I provided?

There's a few issues with your flow, I'm updating them now. What's happening is that the split happens, then a switch on and timestamp is set through "otherwise", but set to msg.payload. Join happens on "automatic", overwriting and putting the old payload back over the timestamp. Trying to get around that before I can check what actually happens.