# About node-red-node-pisrf?

**URL:** <https://discourse.nodered.org/t/about-node-red-node-pisrf/31546>\
**Category:** General\
**Created:** [14 August 2020 05:16 UTC](https://discourse.nodered.org/t/about-node-red-node-pisrf/31546 "2020-08-14T05:16:05Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Nodi.Rubrum](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/nodi.rubrum/32/107482_2.png) [@Nodi.Rubrum](https://discourse.nodered.org/u/Nodi.Rubrum)\
**Post date:** [14 August 2020 05:16 UTC](https://discourse.nodered.org/t/about-node-red-node-pisrf/31546/1 "2020-08-14T05:16:05Z")

</div>

Is node-red-node-pisrf maintained? I mean, it may not be a priority, but it is not orphaned, right? I have a couple of suggestions for it:

1. Just add that US-100 sensor works with the node, just like the SRF04 and SRF05 sensors.

2. Nice to add feature, would be to add of a qualifier to the measure, to define 'same' measurement to be a bit more forgiving before reporting? For example, you only send a new message if the distance measurement is the same per the documentation. That appears to be a literal qualifier, 20 cm, reported, 20 cm not reported, 25 cm reported, at least that is what a take away from the documentation, is that correct? But these (type) of sensor are notorious for being inconsistent, a typical sequence is 20, 20, 21, 20, 19, 22, 22, 21, 20, 19, 18, 21 for example.

Thinking that this node might benefit from a range scope or variance qualifier, which can be inclusive or exclusive. This would smooth the reporting or sharpen the reporting. For example, a + or - vector allowance.

So the range is + or - 2, and object is 20 cm, and the sequence is 19 report, 20 not reported, 23 reported because 23 if is out side the range baseline of 19, then series resets against 23, etc. The opposite could be a feature as well. Such that target is 20 cm, and sequence is 19 report, 20 report, 21 report, 23 not report, 23 not report, 24 not report, 19 report. Even an actual variance or standard deviation option would be nice, as well.

In enterprise monitoring of virtual machines and docker instances, I developed a sliding baseline monitor that only triggered an exception, when for a given duration, the peaks or valleys exceeded a qualified limit or range, with include or exclude logic as needed. This was because the base monitoring software often reported false positives (from our perspective) which was expensive in time/resource response to same. Since could keep statistical data over time, we in effect created a poor mans' learning engine, the service teams loved us for it.

Oh, we 'sold' the enhancement back to the vendor of monitoring software, for a major discount on the purchase contract.

Just a thought.

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [14 August 2020 12:00 UTC](https://discourse.nodered.org/t/about-node-red-node-pisrf/31546/2 "2020-08-14T12:00:27Z")

</div>

Always happy to take updates and pull requests. Can certainly tweak the readme. We do also have both the smooth node and rbe node. Smooth does an average over x previous readings, and rbe can do hysteresis type functions, so hopefully they would complement what you want.

---

<div class="post-metadata">

**Author:** ![Nodi.Rubrum](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/nodi.rubrum/32/107482_2.png) [@Nodi.Rubrum](https://discourse.nodered.org/u/Nodi.Rubrum)\
**Post date:** [14 August 2020 13:35 UTC](https://discourse.nodered.org/t/about-node-red-node-pisrf/31546/3 "2020-08-14T13:35:26Z")

</div>

True, the smooth and average could be used, I was thinking of embedding the logic, to make it easier for the user. What was it I think you said once, hide the details from the user? 🙂

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [14 August 2020 16:16 UTC](https://discourse.nodered.org/t/about-node-red-node-pisrf/31546/4 "2020-08-14T16:16:24Z")

</div>

we also hold to the tenet that a node should one job and do it well... so the pisrf node reads range, and the smooth node smooths it... etc...

---

<div class="post-metadata">

**Author:** ![Nodi.Rubrum](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/nodi.rubrum/32/107482_2.png) [@Nodi.Rubrum](https://discourse.nodered.org/u/Nodi.Rubrum)\
**Post date:** [15 August 2020 01:02 UTC](https://discourse.nodered.org/t/about-node-red-node-pisrf/31546/5 "2020-08-15T01:02:13Z")

</div>

How is the conflict resolved? Don't answer that... Just could not resist pulling the chain. 🙂

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [15 August 2020 05:40 UTC](https://discourse.nodered.org/t/about-node-red-node-pisrf/31546/6 "2020-08-15T05:40:39Z")

</div>

There is no conflict.

---

<div class="post-metadata">

**Author:** ![Nodi.Rubrum](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/nodi.rubrum/32/107482_2.png) [@Nodi.Rubrum](https://discourse.nodered.org/u/Nodi.Rubrum)\
**Post date:** [16 August 2020 03:55 UTC](https://discourse.nodered.org/t/about-node-red-node-pisrf/31546/7 "2020-08-16T03:55:12Z")

</div>

Geez... it was a joke!

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)\
**Post date:** [15 October 2020 03:55 UTC](https://discourse.nodered.org/t/about-node-red-node-pisrf/31546/8 "2020-10-15T03:55:17Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.