I figured you were just posting your progress of getting it working but you didn’t say or include a link with new code so I figured it was not ready yet or maybe it was something @Vitesze was paying you to create.
I see your example code folder now I took a look
So to use your example code on the Electron you just have to run ImageReceiver code in Node and then the Electron the server IP via setting a Particle variable that holds the server IP?
Does the Image Receiver code just save the image data to file or display it? I have never used Node before except to run the Particle CLI application.
Actually the link was there already, since the code hadn't changed between post #50 of this thread and my Electron image post, I didn't see need to provide the same link again, sorry.
I've now already published v0.0.3 of the lib to the Library Repo.
I tried to put all the required info into the comment block at the top of the sample, but being so involved in the topic I might have assumed too many things to be clear.
So I'd be greatful if you could point out things that aren't clear enough to make it understandable to as many people as possible.
That's a note I can also add in the comment, but as with the (missing) link also that info was provided already in my earlier post
This out folder will be created by the NodeJS server inside its own directory.
One note about a point that might not be clear but is beyond the scope of the library and hence won't be added to the comment block:
Since the Electron is not connected to your LAN it will have to access the NodeJS server from outside of your LAN and hence you need to tell it your LAN's public IP address and configure port forwarding on your primary router to forward any outside requests to the local IP of your server. The local server will listen on port 8124 but your "public" port does not need to be the same - the port translation is also to be set up in your router.
No problem, I didn't have any time to test it until now anyways but I am looking forward to giving it a go!
This whole camera thing got me to try out Motioneye OS security camera software on an old Rasberry Pi 3 & Raspberry Pi 2 camera I have had sitting around for more than a year now and I'm amazed at how well it works in full HD.
No problem, I'll give it a try soon and see how it works out and provide feedback if something is not clear from an amateurs point of view.
Did you do any testing with cellular data consumption for the full-size jpg image transfers?
@Vitesze Have you got this working yet on your end?
Noted.
I'm using my cellphone as my WiFi hotspot and it does not have port forwarding options built into it so sounds like I will need to test this out somewhere I have access to a router I can port forward. Thanks for noting this.
That's an unfair competition RPi's are playing a completely differrent league.
The used cell data is pretty much the same as the image file itself plus ~5-10%
The image is sent in junks of 512 byte which are wrapped in the UDP "envelope".
For testing this might not be an option, but if this happened to be a permanent solution then dynDNS might be an option.
I’m going to start testing out this library in a couple mins… Apologies for not giving any feedback in the last 2 weeks, in fact things have been crazy busy for me, so I can finally sit down now and test the uCAM
I have the camera all set up and ran the imageReceiver.js file. However, where do I actually find the IP + Port of this server?
Perhaps I’m doing something wrong and am not actually running the server properly - I notice that an ‘out’ was created in the same folder. Is that correct?
I suppose you have got your server connected to a consumer WiFi router which is either connected directly to your ISP or via some other router.
In such a setup your server will probably have an IP like 192.168.#.# or 10.0.#.# but these are not globally unique, hence the Electron cannot access these. It only can access the public IP of your gateway router.
You need to find that and also set up port forwarding as mentioned further up already
If this is not an option for you - as was not for @RWB - you may need to use a service like dynDNS.
Am I correct in that after starting the imageReceiver.js for the first time, an ‘‘out’’ folder is created at the file location, and this is where images should appear?
If so, then I think I indeed have issues with the Server Address. I can take the JPG just fine, but am unable to send it to my PC.
I don’t really understand the part about the ‘‘public’’ port not needing to be the same? If by default it listens to port 8124, and I would portforward that, then it should in theory work fine, unless something else is already using that port?
I will probably look into a server service as I can’t really control my portforwarding and it’s a better solution for me in the long run anyway.
@RWB Would greatly value your input on this, as if I recall correctly you have mentioned using this method a few times.
Lets say your public IP would be something like 24.85.15.109 and your local server has the IP 192.168.1.2 you can setup port forwarding for 24.85.15.109:12345 to 192.168.1.2:8124.
In order for the TCP/IP packets to find their way to the server, the Electron would send them to 24.85.15.109
:12345, your gateway gets the packets, looks at the port 12345 and it's forwarding list and realises that any packet coming in at that port is actually meant for the local IP 192.168.1.2 and should knock on port 8124.
Sure, you could use 8124 instead of 12345 but - as I said - they don't have to be the same, but I didn't say they mustn't be the same, right?
However, if you happened to have multiple servers running all the same imageReceiver.js you could just run the same code on all the individual machines and just set up a dedicated public port and forward IP to have the packets find their way.
Yes, unfortunately I don’t have access to managing these forwarding lists, so sadly it’s not an option for me right now. My plan is to have code where the Electrons will take a 320x240 JPG once every x hours, and automatically send it to a remote server (not using Particle.function()).
A service like dynDNS would be able to do just that?
No. dynDNS only provides a resolvable DNS for a dynamic IP address. If your home router sits on an ISP like Comast (in the US), then anytime there is a power outage, your router could receive a different IP address. It isn't static like most corporate networks. The dynDNS service, if your router supports it, will allow the router to update that dynamic IP address any time it changes. All you have to remember is something like vitesze.dyndns.com instead of the ever changing public IP address. I used to use a free service like 20 years ago but haven't use one in forever. There are many out there, some free, if you have a need for it.
Right, I’m not really sure if a local server is the way I want to go. After all, I would want to have pictures taken even when my device is turned off, and also have images available for other users potentially. Would be great if I had a remote server that can be accessed from wherever, that would store all my images.
Do you have any recommendations for something like that (e.g. like an FTP Server?)
So you need a publicly available data repository for storing binary files… I think. I assume free as well.
I did a quick search for “dropbox” on this forum but didn’t get any hits. You might check out the dropbox API documentation. You might be able to use one of the could services such as Azure, AWS, Google, etc. to store binary BLOBs in a database. You could get a virtual machine running in the cloud with a running FTP server. There are hosted FTP services such as: drivehq (not endorsing, I have no experience.)
I have not been able to test @ScruffR latest Electron Camera upload code because like you I have no way to forward any IP addresses because my main WiFi hotspot is my cell phone which does not offer any port forwarding features.
I'm pretty sure we can upload the pictures to an FTP server but it does add to the data usage since FTP is not 100% efficient at transferring the data, there is extra FTP data usage.
@ScruffR I think you put a good amount of work getting the library to where it is now and it works but is it also possible to use an FTP library like this to upload the image file even though it cost extra data usage to use FTP?
The actual uCamIII library is agnostic of the actual data sink you want to use.
The library example illustrates how to implement three possible ways to transfer the image.
If someone comes up with a good application for the library - e.g. using FTP - PRs for additional examples are always welcome.
@Vitesze, I’ve also helped another member with a similar project who has signed up to some virtual host service that offers VMs to run NodeJS servers, DB servers like MySQL instance, and other stuff and he seems guite satisfied with it.
I’m guessing that if you can get the pictures to upload to an FTP server using the FTP library @Vitesze and his company would pay you to make it happen.
Running NodeJS servers is just something that we know nothing about so it’s uncharted territory. If the FTP allows us to bypass port forwarding and all that then even better. The Electron would just need to push data to a paid hosted FTP server.
I’ve used the FTP server before to download files to an SD card but I have never pushed an Image file stored in a variable and then pushed it to the FTP server. Conceptually this seems simple, technically I am not sure how to make it happen.
Pictures to an FTP Server for sure is really a thing I’m interested in - the data overhead is manageable. I already decided to go with 320x240 images to offset the costs a bit for the image data, and can train the device to be ‘smart’ at what times the images are most desired to be viewed.
@ScruffR For sure additional help with this would be great to have, as I have absolute no knowledge on all these data-exchange methods. I do wish to post the results of this project eventually here on the forum as I think it would be incredibly interesting for many people - but due to the complexity not many are attempting it.
RPi's are playing a completely differrent league.
Apologies for not giving any feedback in the last 2 weeks, in fact things have been crazy busy for me, so I can finally sit down now and test the uCAM 
