# The \*new\* (updatd) \`ping\` node
**URL:** https://discourse.nodered.org/t/the-new-updatd-ping-node/38020
**Category:** Feature Requests
**Created:** [26 December 2020 00:25 UTC](https://discourse.nodered.org/t/the-new-updatd-ping-node/38020 "2020-12-26T00:25:52Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)
#### Post date: [26 December 2020 00:25 UTC](https://discourse.nodered.org/t/the-new-updatd-ping-node/38020/1 "2020-12-26T00:25:53Z")
I have just had a world of hurt when I installed/updated the _standard_ `ping` node.
I was using the`advanced-ping` node but it is kind of deprecated.
I started modifying my flows to use the standard `ping` node and things weren't working as expected.
# _What??!!_\*
Hmmm.... _thinking_ and looking more closely at the messages.
# ARGH!
The `ping` node strips away any extra stuff on a message.
So if I am sending something like:
`{"name":"test","payload":"192.168.0.1"}`
The `name` isn't getting through.
So it is _one step forward, one backward_.
Probably petty of me, but this seems to not be helping how the node works if it strips away _unused_ parts of the message.
Could it be modified to leave any extra parts of the message intact?
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [26 December 2020 08:32 UTC](https://discourse.nodered.org/t/the-new-updatd-ping-node/38020/2 "2020-12-26T08:32:01Z")
It appears you are right, the ping node does not keep additional properties in the input message. I think that counts as a bug in node-red-node-ping so I suggest you submit an issue.
---
### Author:  [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)
#### Post date: [26 December 2020 08:33 UTC](https://discourse.nodered.org/t/the-new-updatd-ping-node/38020/3 "2020-12-26T08:33:27Z")
Well, I am not sure it is an "issue" and more me wanting....
I did post to the feature request part.
---
### Author:  [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [26 December 2020 08:48 UTC](https://discourse.nodered.org/t/the-new-updatd-ping-node/38020/4 "2020-12-26T08:48:46Z")
The (excuse) for the way ping works is backwards compatability.
Before I added **Triggered** mode to the ping node, it was purely a sender (no input) but I realised that folk would need info downstream to correlate what they sent. Additionally, as it is a completely async operation & more than 1 item can be pinged, it was decided to pass the original payload in `msg.ping` so the user could access the extra meta data.
Potentially, I could have held onto and resent clones the original msg for each ping result in the CSV/Array, but this didnt feel right at the time of writing the PR.
@dceejay any opinion on this please?
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [26 December 2020 10:53 UTC](https://discourse.nodered.org/t/the-new-updatd-ping-node/38020/5 "2020-12-26T10:53:44Z")
Hmm yes - Can't think why we didn't pass through the original properties. As you say - originally it was just a generator node so there would never be any expectation of additional data. It would make sense if it was consistent with other nodes and did pass through if possible, as having to create an array and add extradata is a bit of a faff for simple use cases.
---
### Author:  [@system](https://discourse.nodered.org/u/system)
#### Post date: [24 February 2021 10:53 UTC](https://discourse.nodered.org/t/the-new-updatd-ping-node/38020/6 "2021-02-24T10:53:50Z")
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.