Dumb question about editing a node

This might be a topic for a new thread but...

  • this.on('close' is server side (node removed / used for server side clean up)
  • oneditdelete is client side (for client side tasks when a node is deleted from the editor)

I've written a few nodes and so far had no need to use oneditdelete (yet) but I do use this.on('close' for various server side clean up)

Well, my problem seems to be that my location node gives the server node a callback to use when the server detects a status change, but when that location node is deleted, I need to remove that callback stored in the server node because I'm still seeing output from it in the log.

I don't understand how the deleted location node is able to print to the log, but in either case, the callback does need to get removed from the server node...

So does oneditdelete trigger if a node is deleted via selection & delete key (i.e. without opening the edit dialog)?

add debugger key word into your node, restart node-red, open the browser & devtools, give it a go. Y

As i said earlier, I've not used it but i suspect it will fire when deleted from the editor (before deploy - so in other words, still active in the runtime).

If you want to remove callbacks at the server side, I would suggest you need to use this.on('close' and its parameters to determine if there is a clean up (at server side) to do.

reference

1 Like

Huh. Yeah, that doc is where I learned about the this.on('close'. I'll reread it a few times more. I'm not entirely sure where it goes in the server node's code or how the location node deletion triggers it if it's in the server code. Thanks for the help.

It gets called whenever you hit the deploy button (and that node is affected by the deploy) or ctrl-c - ie whenever that node is stopped - at which point it should tidy up any "old" connections ready to be started again.

1 Like

I got it working. I was a little surprised that when I searched for this.on('close'... in node-red-nodes, I didn't find examples of it being called from inside a constructor. In fact, the examples I saw didn't even have class definitions, so it seemed a little magical to me (since I don't know javascript) and I felt a bit disoriented, but once I decided I needed to put it in the constructor, it made a lot more sense.

I pushed an update to that repo (if anyone is following this).

I'm definitely following this, not that I understand most of it. I do however use Life360 currently with IFTTT and would love to get it working in Node-RED ahead of IFTTT support ending.

I'm unsure of the etiquette but if I can help in any small way with testing then please let me know.

Thanks @Prog72. I was able to implement a debug/test mode that allowed me to simulate departures on startup. (The code base was already capable of triggering artificial arrivals on startup [because all previous locations are null on the first check]. I just added a way to set prior locations when debugLeave is set to true [though setting the starting conditions is not straight-forward - I tried commenting it to explain].) My testing was not exhaustive, but I do think I confirmed it's problem-free this past weekend. There could exist edge cases, including in the GUI.

I also re-packaged my fork to be independent (renaming it node-red-contrib-life360), since I haven't heard back from the original developer except for a single comment 25 days ago saying he was too busy. I'd never published an npm before, and I ran into an issue upon npm publish:

npm ERR! code E403
npm ERR! 403 403 Forbidden - PUT https://registry.npmjs.org/node-red-contrib-life360 - Package name triggered spam detection; if you believe this is in error, please contact support@npmjs.com
npm ERR! 403 In most cases, you or one of your dependencies are requesting
npm ERR! 403 a package version that is forbidden by your security policy.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/pi/.npm/_logs/2020-11-09T15_54_51_024Z-debug.log

I emailed support@npmjs.com. I don't know how long they typically take to reply, but I hope within a week.

I don't know how to install it for node red without using it's palette tool, but feel free to do a local install of the package and/or review the code in the PR.

Thanks, I've installed it and everything seems to be working flawlessly. I'll obviously raise an issue if I spot any problems but so far it's looking good. :+1:

Thanks for your hard work getting this node functional before the IFTTT support ends. It's very much appreciated.

1 Like

Yay!

Thanks for reporting back.

1 Like

I was googling around some more this morning trying to get the package to publish on NPM and I saw in a stack post which suggested I prepend the name with my @username/, which seems to have worked. It's published now at:

When I look in node-red however, I see "Type already registered" in the palette install tab:

Is that because I've been editing the code inside node red? Or is it because I need to edit something to make it more distinct from node-red-contib-life? (I haven't installed my version of the package in my node red instance yet and the package info from the install should still match the original node-red-contrib-life.)

I had that issue when I still had node-red-contrib-life installed. I removed it but I think I also may have had to re-install your node-red-contrib-life360 to get rid of the error.

It seems to me that Node-RED may be getting them confused somehow so you may well need to change something in that regard.

internally in the nodes you have called one life360-server and the other just location - this second one may very well conflict with another node of same name/type.

2 Likes

Thanks @dceejay,

So is this an example of the only places relevant to eliminate the overlap?:

nodes/server.html: RED.nodes.registerType(' **life360-server** ', {
nodes/server.html:<script type="text/x-red" data-template-name=" **life360-server** ">
nodes/server.js: RED.nodes.registerType(" **life360-server** ", ServerNode);

(wow - emphasis from the shell was maintained in the paste to the forum. That's impressive, if that's what actually happened.)

Well actually I suspect the other (location) one more as that would be less unique - but yes those.

1 Like

Sure. Just trying to identify what discretely needs to be unique across all possible node, and that one would not be unique WRT the parent repo and I suspect is probably why I see that "Type already registered" message twice.

I was struggling this morning to decide what to rename the location node to. The most descriptive name would be something that says all the things, e.g. "arrival and departure event triggers". I was trying to come up with a word that means both arrival and departure and the closest I came up with was 'aloha', but that's too niche. Perhaps just 'life360' or 'location-events' or 'location-changes'...

I'm open to suggestions.

well as it's to do with life360 and location maybe life36-location-events ?

1 Like

"Circle Activity" perhaps?

1 Like

It really doesn’t matter as long as it is probably unique.

1 Like

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