Help with watch node

[jma...@gmail.com]

Having difficulty with the watch node:

Setting 'files' parameter as /mnt/n54l/media/video and then wired to a debug node

The watched directory is an nfs share mounted via fstab.  I can see and access it from the raspbian command line on the pi running node-red.

But when new files are created in the directory I get no output into the debug node.

Checked the dir name spelling, checked the log (nothing), tried enclosing dir name in double quotes, single quotes and also putting a '/' at the end.

Still nothing.

Probably something obvious - but what am I doing wrong?

[Nick O'Leary]

The Watch node does not work on NFS/SMB mounted directories. Its help text needs updating to reflect this.

Sorry!

Nick

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/34b8e4e8-1103-4933-9239-003f0a3d2a05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jma...@gmail.com]

OK, more data.

It seems if files are created or removed locally (i.e. on the pi running node-red) into this directory, the watch node triggers.  But if the files are created by another pi into the same shared directory, nothing triggers.

[jma...@gmail.com]

Ack.  There goes that plan.  Alternatives?

Use case is

1. Security cameras running on multiple pis creating media files on a server when motion is detected. 
   
2. Node-red watching and forwarding the media file from remote server via telegram bot nodes. 

No need for notifications or signals when motion is detected as the media landing on the server or telegram client is its own notification.  Anything more is clunky.  And want to avoid the server having to do anything other than serve files.

On Wednesday, October 4, 2017 at 9:36:38 PM UTC+11, Nick O'Leary wrote:

The Watch node does not work on NFS/SMB mounted directories. Its help text needs updating to reflect this.

Sorry!

Nick

On 4 October 2017 at 11:20, <jma...@gmail.com> wrote:

Having difficulty with the watch node:

Setting 'files' parameter as /mnt/n54l/media/video and then wired to a debug node

The watched directory is an nfs share mounted via fstab.  I can see and access it from the raspbian command line on the pi running node-red.

But when new files are created in the directory I get no output into the debug node.

Checked the dir name spelling, checked the log (nothing), tried enclosing dir name in double quotes, single quotes and also putting a '/' at the end.

Still nothing.

Probably something obvious - but what am I doing wrong?

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.

To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.

[Colin Law]

On 4 October 2017 at 11:51, <jma...@gmail.com> wrote:
> Ack. There goes that plan. Alternatives?

You could routinely poll the server and remember the timestamp of the
most recent file.

Colin

> https://groups.google.com/d/msgid/node-red/eba7631f-d710-4296-b5e3-8dec422c5c61%40googlegroups.com.

[jma...@gmail.com]

Polling is probably the easiest way to get something at least. I'll have to pretend the edge cases don't exist for it to be easy though. Not sure I can do that.

[jma...@gmail.com]

Seeping on the problem it is probably better to spend the effort creating an MQTT interface between the cams and the node-red pi.  The camera software can run scripts on motion detection start, end, still capture, etc.  I can publish the media path and name to MQTT where node-red will process it.

[jma...@gmail.com]

*Sleeping

[wku...@gmail.com]

If you are running "motion" can't you have the Pi with the cameras ftp or scp the motion detected files to your server or send the telegram message using one of the motion command launchers like on_picture_save?

Personally I'd try to eliminate the server as it creates a single point of failure, unless you want a central archive of all motion detected images,  I'm planning to use a router with a cell phone data plan as a fallback should the miscreants cut the internet connection, Right now I just send a message via a GSM modem if the internet or A/C power goes down.  My UPS will keep the system up for about 70 minutes, This is the best I can come up with to eliminate my connection to the Internet as a single point of failure.

When another Pi puts pictures into the shared folder you are watching, is the user/group IDs the same along with the access permissions?  There are some samba config options to force user/group and permission on the files coming it.

Is the node-red watch node using some kind of "hook" into the file system that writing the file as a share target doesn't trigger?  Otherwise how does it know where the file comes from if its not a user/group permission issue?

Maybe you need to sync the filesystem after the transfer into the shared folder, I'd try an exec node in front of the watch to run the sync command and see if that helps.

Problem with timestamps as filenames is when the clock passes midnight. it changes the filename and usually the path so as to not over write files captured "yesterday" at the same time.

[jma...@gmail.com]

I'm using pikrellcam.  I get way too many false positives using either the motion package (via motioneyeos) or a PIR detector wired up through GPIO.

Eliminating the server is an interesting thought. Using the telegram web services api directly from each pi as you suggest would eliminate quite a bit of network traffic.

As Nick stated watching NFS/SMB shares doesn't work.  I suspect because it doesn't work by polling, but by hooking into file system actions by the node red host OS.
 

[Colin Law]

On 5 October 2017 at 06:02, <jma...@gmail.com> wrote:
> I'm using pikrellcam. I get way too many false positives using either the
> motion package (via motioneyeos) or a PIR detector wired up through GPIO.
>
> Eliminating the server is an interesting thought. Using the telegram web
> services api directly from each pi as you suggest would eliminate quite a
> bit of network traffic.

Why would that involve less network traffic than publishing to an mqtt
server? Plus it does mean that you are reliant on having functioning
internet access.

>
> As Nick stated watching NFS/SMB shares doesn't work. I suspect because it
> doesn't work by polling, but by hooking into file system actions by the node
> red host OS.

I believe that is correct.

Colin

[jma...@gmail.com]

On Thursday, October 5, 2017 at 5:46:09 PM UTC+11, Colin Law wrote:

Why would that involve less network traffic than publishing to an mqtt
server? Plus it does mean that you are reliant on having functioning
internet access.

The transfer of the media to and from the file server would be eliminated.  Publication of new media to MQTT not needed either.  Each camera client would send all media as it is created from local storage directly to telegram. Thinking about this it would potentially have the drawback of requiring a telegram bot for each camera.  Telegram bots don't handle two devices talking to them simultaneously.

The clients would need internet access which is a bit of a problem as someone could unplug the cable to an outdoor camera client and use it to get on my network.  They'd be in for a surprise if they didn't understand it was PoE.  The PoE switch the clients will use is a managed switch so I can probably restrict the clients quite well though I'd need to work out how to achieve it.

I would still need node red with MQTT and telegram bot nodes to control the camera settings remotely.  And node-red flow is currently doing presence detection, turning the cameras on when we are away.

[Julian Knight]

The transfer of the media to and from the file server would be eliminated.  Publication of new media to MQTT not needed either.  Each camera client would send all media as it is created from local storage directly to telegram. Thinking about this it would potentially have the drawback of requiring a telegram bot for each camera.  Telegram bots don't handle two devices talking to them simultaneously.

Not sure that is entirely true. I've certainly got 2 different instances of Node-RED talking to the same Telegram conversation using the same API key.

The clients would need internet access which is a bit of a problem as someone could unplug the cable to an outdoor camera client and use it to get on my network.  They'd be in for a surprise if they didn't understand it was PoE.  The PoE switch the clients will use is a managed switch so I can probably restrict the clients quite well though I'd need to work out how to achieve it.

That should be easy enough to control. And in any case, you should be defending your clients network from IoT traffic, failing to do so is part of the reason IoT is such a cyber problem right now. It is always best to have IoT on a separate network, at least a separate subnet and to have a firewall between the IoT network and your general network. In fact, it should be a requirement. If I were your customer, I would certainly require it.

 

I would still need node red with MQTT and telegram bot nodes to control the camera settings remotely.  And node-red flow is currently doing presence detection, turning the cameras on when we are away.

Telegram is an excellent way to implement remote alerting and control for Node-RED as it is so easy to create a bot and Telegram security is pretty good from end-to-end. Much easier than trying to protect a Node-RED Dashboard. 

[Colin Law]

On 5 October 2017 at 09:39, <jma...@gmail.com> wrote:
> On Thursday, October 5, 2017 at 5:46:09 PM UTC+11, Colin Law wrote:
>>
>>
>>
>> Why would that involve less network traffic than publishing to an mqtt
>> server? Plus it does mean that you are reliant on having functioning
>> internet access.
>>
>
> The transfer of the media to and from the file server would be eliminated.
> Publication of new media to MQTT not needed either. Each camera client
> would send all media as it is created from local storage directly to
> telegram. Thinking about this it would potentially have the drawback of
> requiring a telegram bot for each camera. Telegram bots don't handle two
> devices talking to them simultaneously.

I misunderstood, I thought you were referring to just the
notifications over telegram rather than the the video files
themselves. However, having sent the file off via telegram, what then
happens?

Colin

[wku...@gmail.com]

Thanks for the info about pikrellcam,  I'd thought the PiCam motion vectors could be useful for motion detection when I first read about them in the pi camera documentation, glad to see someone has taken up the challenge, that is the beauty of open source.

If your Pi are monitoring outdoors, how are you keeping them cool?  My Pi3 running motioneye runs 68-74C in a ~28C room,  It'd be hard to keep it from overheating about 8 months of the year around here outdoors where temps of 35C+ are common.

I'm finding PIR combined with motioneye to be about perfect for interior spaces where I control the lighting.  Mine is a backup to the hard wired perimeter alarm system should someone decide to cut a hole in a wall or roof.

Its easy to run off into paranoia-land with this security stuff, but the local news is full of "security system" footage of criminals hauling stuff away with precious little news of them ever being prosecuted for it, so I want high resolution photos pushed to us so we can call the police in necessary in a minute or two.  I'm of the opinion that a 5-8Mpixel still is worth a lot more that a few seconds of lower resolution video and gets to us much faster.

[jma...@gmail.com]

On Thursday, October 5, 2017 at 11:35:28 PM UTC+11, Colin Law wrote:

However, having sent the file off via telegram, what then
happens?

I get a notification from telegram on my phone where I review the media file and take action.

If I want anything to happen automatically at home I'll have to script it on each of the camera pis or pipe it into node-red.  I will probably end up using MQTT and pipe to node-red as I originally suggested.  I'll set up scripts on the camera pis to publish to MQTT the path to new media files when created on the file server and have node-red handle the telegram interaction. 

For quick and dirty using the telegram api to send notifications and files directly from the camera pis to the telegram bot works ok in bash scripts just using curl.  I've set it up today as a PoC.

[Colin Law]

OK gottit. So rather than copying the files to a server you will leave
them on the individual pis so you can recover them later if you need
them. Or does the telegram server keep them for you?

Colin

> --
> http://nodered.org
>
> Join us on Slack to continue the conversation: http://nodered.org/slack
> ---
> You received this message because you are subscribed to the Google Groups
> "Node-RED" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to node-red+u...@googlegroups.com.
> To post to this group, send email to node...@googlegroups.com.
> Visit this group at https://groups.google.com/group/node-red.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/node-red/5281f83e-c3ec-4ba2-af6f-92a228ee6ff1%40googlegroups.com.

[Julian Knight]

Just a side-thought. If the reason you are doing this is for security. You won't want to leave the files on the Pi's. B-}

[jma...@gmail.com]

Telegram will keep them for long enough, I think.  Certainly months worth of photos from one camera as I am already doing that with my python based camera.  I can review them in the chat on my phone and keep or delete.

I may write media to the file server instead of locally despite it being a single point of failure.  SD cards on the pis wear out and they will be a pain to access.  I haven't decided yet.

I will write up the project at some point.  My plan tends to change when something starts to look difficult.  I'm lazy.