hepcat72 / node-red-contrib-life360

GNU General Public License v3.0
3 stars 4 forks source link

"No callbacks" message from Life360-Server node #1

Closed Prog72 closed 2 years ago

Prog72 commented 3 years ago

I'm getting this message constantly in the debug sidebar from the Life360-Server node.

Arriving/leaving activity still seems to be working as expected.

Prog72 commented 3 years ago

Further investigation reveals that restarting Node-RED clears the problem but it returns after a full deploy. A deploy of modified flows does not cause this.

I wouldn't normally perform a full deploy but seemingly had that selected by accident.

hepcat72 commented 3 years ago

I have seen this before. It comes from the Life360-Server node. That server node maintains a callback (associative) array. Each "Life360" node (i.e. the former "location" node) registers with the "Life360-Server" node and provides it a callback, which the Life360-Server node adds to its callback array. I see that "No callbacks" message in a few circumstances: when there are no "Life360"/location nodes in any flow or when a Location node has been disabled or deleted.

I had added a "disabled_callbacks" (associative) array to be able to track whether or not a callback should be called (i.e. when a Life360 node has been temporarily disabled. It should get updated when a Life360 node is disabled and when it is deleted, but I admit I did not exhaustively test this. There could be an edge case where this isn't correctly updating, say if you add a Life360 node and then delete it?

But first, are you still running the manually installed version or did you uninstall it and re-install via npm? because the manual version might potentially confuse the server nodes WRT the original parent repo.

Prog72 commented 3 years ago

I removed the manually installed version and re-installed via the Palette Manager as that seemed the logical thing to do now the node is 'official'.

Since selecting to deploy only modified flows I've not had a return of this issue. Could it be that the Life360-Server node being redeployed is the cause? Forgive me if I'm barking up the wrong tree.

hepcat72 commented 3 years ago

Don't worry about it. There may or may not be an improvement to be made here to prevent log clutter, so if you have any suggestions or would even like to submit a PR, either are welcome.

My understanding is that a full re-deploy should resolve the issue, so I suspect that your specific issue may be resolved by the update to the "official" version, since I may have made some changes to the relevant code between your 2 installs.

I could be wrong however. If you can make the problem recur in the "official" version, then I'd be willing to dig into it. Just report what you do that makes it happen (keeping track of node disablings/deletions).

jeffreywfinch commented 3 years ago

Having the same issue with the "No callbacks" debug message.

hepcat72 commented 3 years ago

This means you either haven't added any Life360 nodes in any flow (but have configured the Life360-Serve node) or a previously added Life360 node has been deleted. It's a message that comes from the Life360-Server node, which stores a callback in an associative array for each Life360 node you create. If I understand the way the the cleanup code works (although I could be wrong because this was my first node red node endeavor), the callbacks should be silenced by this call:

https://github.com/hepcat72/node-red-contrib-life360/blob/3a8654143b39f047224905d74637151de4f3cb53/nodes/location.js#L29

when a Life360 node they are disabled - and that deleting should be the same as disabling.

However, perhaps my assumption that this loop goes through all circles and their members is incorrect:

https://github.com/hepcat72/node-red-contrib-life360/blob/3a8654143b39f047224905d74637151de4f3cb53/nodes/server.js#L296

I'd thought that as long as there existed enabled Life360 nodes (with their server nodes set), you wouldn't get the log message.

Can you elaborate on your conditions? Do you have any Life360 nodes in any of your flows (note - not subflows)? Did you delete any nodes, and if so, does restarting node red silence the log messages?

jeffreywfinch commented 3 years ago

I was using node-red-contrib-life 0.1.4. I deleted node-red-contrib-life, downloaded node-red-contrib-life360 1.0.0 and updated a single flow. When I deleted the node it started with the error "No callbacks". The only thing that will stop it is a restart if NodeRed. I also get the occasional messages stating "No API key set"

hepcat72 commented 3 years ago

Just so I get a complete picture, can you confirm this re-stating of your process (from the install of this fork)?:

  1. Installed node-red-contrib-life360
  2. Added 1 Life360 node to a flow
  3. Edited the node and in doing so, clicked the pencil button and entered your Life360 login credentials to the Life360-Server node
  4. Deployed
  5. Deleted the Life360 node from the flow
  6. Deployed
  7. Restarted node-red

The way the code is written, the "No Callbacks" message is intended to be output between steps 6 & 7 (because the server is running and nothing is listening to it, which is a waste of effort). Can you confirm that this accurately captures your process?

If I am missing any steps in this process, there may be a problem. If not, then I'm open to suggestions on how it should change, like perhaps the message should change to "Life360-Server is running, but no Life360 nodes are listening. Disable the Life360-Server config node if you are no longer using Life360 in your flows."

hepcat72 commented 3 years ago

I suspect I'm missing a step, because in this scenario, restarting node-red should still emit the no callbacks message (because there's still nothing listening to it). I believe it should be silenced after step 9:

  1. Add a new Life360 node to a flow
  2. Deploy
  3. Restart node-red

If you are getting the no callbacks message between steps 9 & 10, then the disabled node tracking and/or the loop is not behaving how I intended, and I'll have to figure out how to fix it.

hepcat72 commented 3 years ago

Oh yeah, sorry - I neglected to respond about the API key message. I can't seem find any code that prints a message like "No API key set". I also do not have that in my logs. Can you elaborate on that? Do you know how I could reproduce that behavior?

hepcat72 commented 3 years ago

OK. Thanks. If I understand correctly (and correct me if I'm wrong), the problem could be one of 2 possibilities:

  1. If your rebuild included node-red-contrib-life 0.1.4 (which is a guess based on the inclusion of node red in the rebuild) you would still have the config node from that old version. The old version does issue the same log message if the corresponding "location" node is deleted (note, the old version only supports 1 location node, whereas my newer version can have any number). Since restarting silences the issue, it could be that the old version's config node was deleted or reset. It would spit out messages until a restart even though it doesn't appear among the config nodes (in my experience).
  2. If your rebuild did not include node-red-contrib-life 0.1.4, restarting node red silences the issue, and your Life360 node is in a flow (as opposed to a subflow), the code is not behaving how I expected it would and I need to fix a bug. This would rule out the "behaving as expected" assessment.

Let me ask a few questions to determine which is the case:

  1. Are there 2 sections in the node panel on the left (one labeled "life360" and one labeled "Life360")?
  2. Home many life360-related config nodes appear among the config nodes (and do they all have login credentials entered)?
  3. If items 1 & 2 show that the old version is not installed, you delete all Life360 nodes from your flows, add a new Life360 node, deploy (no restart), do you see the log message? (I understand you essentially already did this, but this would just confirm that the issue was not from the last vestiges of a potentially old version hanging on if it at one point existed upon your rebuild.
Prog72 commented 3 years ago

2020_11_25_Life360.Flows.zip

Just a warning that the above file will contain your Life360 password in plain text.

hepcat72 commented 3 years ago

Hey @jeffreywfinch - I deleted your comment to protect your login info. I never looked at it, but you might consider changing your login info.

jeffreywfinch commented 3 years ago

Interesting; thanks for catching that. I was under the impression that all credentials were stripped out of the export file. I'll get back to you on the questions in a little while.

jeffreywfinch commented 3 years ago

The rebuild did not include the node-red-contrib-life 0.1.4 executable files. So...I just did a new export of the NodeRed config file. I went through each line by hand and confirmed:

  1. there is only one Life360 location config node which is correctly populated. { "id": "1106fb89.487924", "type": "Life360-Server", "name": "Life360-eMail", "username": "", "password": "" },

  2. There are a total of 4 configured sections like this one linked to the config file. { "id": "83ebe51.13ecf18", "type": "Life360", "z": "904bb7d8.8166b8", "name": "life360-JWF-Home", "server": "1106fb89.487924", "outputAtStartup": true, "circle": "adb6c393-8b3c-4a65-b4a3-cbb5deacd5d0", "place": "218bd4f8-3762-45fb-ad92-850e63a8435f", "person": "ad53d201-8f9f-4082-81df-480fe793ae0b", "event": "either", "x": 101, "y": 80, "wires": [ [ "2ecf756b.f1a14a", "278e7171.1de8be" ] ] },

jeffreywfinch commented 3 years ago

I just spun-up a new NodeRed site in docker for testing..

docker run -d \ --name d1-nodered \ --network=pub_net \ --mac-address="02:42:c0:a8:00:2b" \ --ip="192.168.0.43" \ -v /mnt/docker/nodered/data:/data \ -h d1-nodered \ -e “TZ=America/New_York” \ --restart unless-stopped \ nodered/node-red

All I did was configure a single location config host and a basic one. As soon as I redeployed the "No callbacks" logging started.

[ { "id": "ef8e9d4b.c8e61", "type": "Life360", "z": "37a8d0d9.cd1a5", "name": "Life360-JWF-Home", "server": "2f0a1a55.0c7676", "outputAtStartup": true, "circle": "adb6c393-8b3c-4a65-b4a3-cbb5deacd5d0", "place": "218bd4f8-3762-45fb-ad92-850e63a8435f", "person": "ad53d201-8f9f-4082-81df-480fe793ae0b", "event": "either", "x": 200, "y": 120, "wires": [ [] ] }, { "id": "2f0a1a55.0c7676", "type": "Life360-Server", "name": "Life360-Me", "username": "", "password": "" } ]

hepcat72 commented 3 years ago

OK. I think that cinches it. I'm stumped though as to what causes that... Maybe the callbacks structure needs to be indexed by circle. How many circles do you have and what circles does each location node use?

Ugh, that doesn't make sense. It loops through all callbacks for each "Life360" node on a flow and as long as 1 is enabled, there should be no log output. Maybe "onChange" isn't being called when I think it does...

I'm open to ideas. This behavior doesn't make sense. I just need to be able to reproduce it and try it out. Is the only time you can reproduce it after an install? You said it goes away when you restart node red, right?

jeffreywfinch commented 3 years ago

I have one circle with 4 people and 6 places. I had 3 circle but was only using one so I just deleted the other two. One other note: I'm authenticating with an email address not a mobile phone number. Yes, it goes away after an restart of NodeRed..

hepcat72 commented 3 years ago

I authenticate with an email too. I forgot to re-ask, because I see I didn't get an answer on this before:

Are your "Life360" nodes on regular flows or sub-flows?

Sub-flows don't "exist" until they are called. That could explain the no callbacks message. While I have seen the message in my log, I was focussed on other things at the time and assumed I had some deleted, disabled, or un-set flow nodes.

jeffreywfinch commented 3 years ago

I don't have any sub-flows.. :-(

hepcat72 commented 3 years ago

Since the problem goes away after restart, it must have something to do with the first deploy after setting up the config node... So there must be a special case I need to account for. Maybe the pencil button copies the config node...? Perhaps if I add a few debugs showing what's in the callbacks array and the node ID of the server and flow nodes, maybe I'll discover the source of the issue. And I wonder if I can reproduce it without uninstalling and re-installing, like if I duplicate the Server/config node... Though I'm not sure how soon I'll be able to get to this.

patriklofdahl commented 3 years ago

Well i have this to and im trying to remove ilfe360 ive deleted al text that i can find But it's still runing the server How do i fix tis

hepcat72 commented 3 years ago

Even if you uninstall node-red-contrib-life360 in the "manage palette" interface, the server won't stop until you restart node-red. I myself faced this the other day when I'd set up a development version last week to do some debugging on another issue. I uninstalled the package and kept getting the no callbacks warning message until I restarted node-red. I use pm2 for my node-red instance. If you do too, the command to restart node-red is pm2 restart node-red.

Note, if you just want to stop the server and not uninstall, all you have to do is delete the Life360-Server configuration node.

  1. Go to your config nodes:
goconfig
  1. Select the Life360-Server node:
dellts
  1. Hit your delete/backspace key on your keyboard
patriklofdahl commented 3 years ago

Thanks hepcat72 That did the trick Ive tried to solve this for hours No jsut deleted the server and a restart of nored and its gone :)

hepcat72 commented 3 years ago

Sure. This is the first node I ever wrote, and honestly, my first serious usage of javascript, so I don't really understand why deleted (nigh, even uninstalled) nodes continue to be allowed to run. And the mechanisms to delete or disable nodes don't seem to work. But... the problem exists in the repo I forked from as well (node-red-contrib-life), so it's not related to my efforts. Maybe at some point, I'll see if I can make it work better. Actually, I wonder if I can just assign a node status to a config node (like the colored dots with text that show up under a node in a flow). That would probably be preferable...

Out of curiosity... why did you decide to not use node-red-contrib-life360? Did you have any problems with it (other than the repeated callback warning when you tried to remove it)? I'm just wondering if there's any other issue or if you were looking for another feature (or maybe found a better node).

Botched1 commented 3 years ago

Just FYI, I get constant "no callback" messages too. Sometimes it will work for a bit on initial load, sometimes it won't. In any case after a while ity goes back to "no callback" messages and stops working.

Had to go back to the original node-red life360 nodes, which seem to work fine (updates, no "no callback" messages), but obviously have more limited functionality.

hepcat72 commented 3 years ago

Just FYI, I get constant "no callback" messages too. Sometimes it will work for a bit on initial load, sometimes it won't. In any case after a while ity goes back to "no callback" messages and stops working.

Had to go back to the original node-red life360 nodes, which seem to work fine (updates, no "no callback" messages), but obviously have more limited functionality.

Yes, this is easily worked around with a node red restart. The behavior is consistent/reproducible and reflects existing or vestigial config nodes with no nodes in any flows receiving updates from the config node. If you have a node on a flow and do a restart of node red, the only things that that can cause the no callbacks message from occurring again is deleting nodes in flows. The config node maintains an array of nodes it sends updates to. If that node goes away, you get the message. Re-deploying node red does not update that array.

And in fact, the same issue exists on the original project I forked from, but behaves slightly differently because that project only supports a single workflow node, thus instead of an array. it maintains a single node reference to send updates to.

The problem seems to be the trigger that is supposed to clean up that/those node references. Deleting or disabling a workflow node is supposed to rebuild the references. However, that trigger doesn't appear to be working as expected. Since this issue is easily worked around via a restart, it has not been a high priority for me. If you would like to look into it, please fork. If you figure it out, a PR is more than welcome.

Botched1 commented 3 years ago

No, those aren't the only ways this happens.

I have exactly 1 flow with 1 life360 node on it - so it is really easy to keep track of/know when it has been touched.

When I started noticing the 'no callback' messages I hadn't touched the node or the flow in weeks. What I see is that after a node-red reload it will (usually) work fine and then later that day, or the next, I'll go into node-red and it is spewing 'no callback' errors again - and I am 100.0% sure neither that specific node nor the flow it is in have been touched/reloaded.

So clearly it can happen without touching the node or the flow at times. Maybe from other nodes/flows being downloaded? Not sure.

Anyway, thanks for the efforts. All I can say is the original node set does not do this on my system. Not sure what the difference is, I haven't went back and looked at the code yet. I may if I get time, though, but there are about 10 other node projects in my queue first.

hepcat72 commented 3 years ago

My recollection is faulty. Looks like the message is not in the original repo:

https://github.com/andreyoshev/node-red-contrib-life/blob/9c950c0e8a0a051b139913b3888c7b63fcb52c06/nodes/server.js#L100-L109

It must have been in some other code I referenced during development, as I remember it happening there too. This is the code that generates it:

https://github.com/hepcat72/node-red-contrib-life360/blob/3a8654143b39f047224905d74637151de4f3cb53/nodes/server.js#L291-L308

The valueChangedCallbacks value is an array that is updated when a node on a flow is created. That node essentially registers its callback with the config node to say "I want to receive updates when there's a change". As long as those nodes exist in flows, and they are "enabled" (i.e. listening), you should not get the message.

It's interesting though that it starts happening for you with no changes to the flows. I cannot reproduce that behavior. I haven't gotten a "No callbacks" message from the config node since the last time I restarted node-red from the last time I messed with the flows last November. Are you sure you are restarting node-red - or are you just re-deploying the flows? To be explicit, I mean, go to the command line and enter (if like me, you use pm2 to start node-red):

pm2 restart node-red

Re-deploying (e.g. via the red button in the browser interface) does not fix the issue. If you are in fact restarting node-red, then I suspect something else must be going on and that the same issue would affect the original repo's code - you just wouldn't know it.

Cheers, Rob

Botched1 commented 3 years ago

Very possible that it is happening in the original too - fair point! At this point I have gone back and forth between the old and new so many times (with a pm2 restart node-red in between. :) ), I probably need to step back and test 1 thing at a time.

I'll troubleshoot more and see what I can see. Thanks for the feedback! I appreciate it.

jpoeppelman1 commented 3 years ago

This no callbacks bug is polluting my logs, can someone fix this please?

hepcat72 commented 3 years ago

Once you get things set up and there exists an enabled Life360 node on an enabled flow, do a restart of node red (e.g. pm2 restart nodered) and the messages will go away. You should only have to do this once. Sorry for the inconvenience. If you're more capable at javascript than I am, and you figure out a solution to prevent the messages in the first place, PRs are welcome, but given the easy work-around, I haven't bothered to figure it out (after spending significant time working on it during development - I'm just not that javascript savvy).

jpoeppelman1 commented 2 years ago

I'm using Docker Node Red, I still see this callbacks message all the time. Can someone please fix this? Please!

hepcat72 commented 2 years ago

Are you prevented from doing a node-red restart in your current docker setup? You should only have to restart once. And if you're running docker, you should take an image after that restart so that you don't have to do it every time you spin docker up. If you have all the nodes setup correctly, a restart is required to correctly populate the callbacks array. It would be nice for the nodes to initialize properly without requiring a restart and I spent a lot of time trying to figure it out, but the features I was using to do the init didn't work as described - either that or I simply don't know what was wrong.

jpoeppelman1 commented 2 years ago

Can someone please fix this?

hepcat72 commented 2 years ago

@jpoeppelman1 - Did you try my advice above? It has worked for everyone thus far. It worked for me. I do not see the log messages, but I did before the node red restart. If you can't restart and take an image of the container, just go into the code and delete the print statement. And again, I worked on this issue for quite some time and couldn't figure out a way to quiet it without a restart. If you figure it out, please submit a pull request.

jpoeppelman1 commented 2 years ago

I get the following when trying to restart my docker image.

/bin/sh: pm2: not found

hepcat72 commented 2 years ago

Assuming you mean restart node-red (not docker), you are apparently using a different process manager than pm2. I'm guessing you don't know what method you're using to start mode red on boot. Take a look at this article and figure out what it is that manages your node red instance:

https://nodered.org/docs/faq/starting-node-red-on-boot

brianmay commented 2 years ago

I am seeing this message immediately after almost single deploy operation in node-red.

I also suspect that messages aren't getting through when I see this message. Although I haven't yet been able to positively confirm that is the reason I stopped seeing any messages yet. Still trying to debug this.

In any case, I don't particularly want to have to restart the server after every single deploy :-(

hepcat72 commented 2 years ago

You don't have to restart the server. You only have to restart node red and you don't have to restart it after every deploy. You only have to restart it once. It's an installation requirement.

brianmay commented 2 years ago

Sorry, restart node-red is what I meant.

I do have to restart node-red after every deploy, or I see these messages. And it seems like messages don't get through until I do so.

hepcat72 commented 2 years ago

You must have a misconfig. That message means that the server/config node is running, but no Life360 nodes are listening. The server node keeps an array of "callbacks" that tells it where to send the messages. When you add a Life360 node to a flow, it registers with the server node and says "send messages to me". As long as there's at least 1 such node registered with the server node, you won't see those messages.

I redeploy my flows all the time. Redeploying doesn't empty the server node's array of callbacks.

The one exception is after the initial install.

Regardless, if you start seeing those messages after each deploy, something else must be going on.

Are your Life360 nodes in a regular flow or a subflow?

brianmay commented 2 years ago

Everything is in a regular flow. And there is at least 1 such node...

hepcat72 commented 2 years ago

Alright. Well, we need to figure out the difference between your setup and mine which causes you to see the no callbacks message in the logs after a deploy and me to not see the no callbacks message in the logs after a deploy.

Are you running node-red in a container?

Try this as a sanity check: Create an arrival life360 node for your current location, set it to trigger arrivals on node-red restart, and connect it to a debug node. With node red opened in a browser window, restart node-red and confirm you get an output in the debug panel when it reconnects. If you get an output, then we can rule out a misconfig of the server node. Though I'm not 100% sure you'd get that message if it is generated while disconnected, so perhaps tick the output to console in the debug node or output directly to a file.

brianmay commented 2 years ago

@hepcat72 Yes, everything works fine after I restart the process.

Also, yes, running inside a container.

Currently on node-red 2.1.3.

hepcat72 commented 2 years ago

Glad you can confirm intended behavior after a restart. How often does your container spin up? You may need to take a new snapshot after restarting node-red to make the effect of the restart on the Life360 install permanent.

brianmay commented 2 years ago

I think there might be a misunderstanding here.

I always said that it works correctly after restarting it. That test proved nothing.

But it fails again if I makes changes to my flows and redeploy.

hepcat72 commented 2 years ago

No, I understand. That was a sanity check. You sounded unsure about whether messages were getting through, albeit when you see the no callbacks message - but I don't know that for sure. So partly, I was just showing you one way to test that arrival events are working.

So now we need to understand what circumstances are starting those no callbacks messages to appear (for you and no one else, once they've performed a restart).

When you deploy, what deploy method are you using, the deploy button or the little down arrow in the button and selecting an alternative deploy option? Have you explocitly confirmed that you start seeing the messages immediately after a redeploy?

hepcat72 commented 2 years ago

...And since I cannot reproduce the behavior you're seeing, I have to figure out exactly what's going on - what's confirmed to work and what causes the problem you're seeing. And I don't like to start debugging before confirming what works.

hepcat72 commented 2 years ago

And besides, that's what a sanity check is: a confirmation of what we already believe to be true.