Have you created an account on your new server before trying to log into it… You can NOT use the same account as you had on the cloud… well, actually you can use the same email and even password if you want (from Cloud), but it will still be a totally separate server and new and empty account, until you start creating projects in it.
What are you entering in your custom settings… and are you inside of your network at the time and using the correct IP and port to your laptop?
Then how did you get the wrong port?? The number 8443 doesn’t even show up on a search of that link I provided
I don’t use my Local Server on Windows. All I can suggest is double check all your settings, paths, IP (hint… NOT the same IP you used for the Admin page), ports, etc… and make sure the server is actually running at the time… if you close the terminal window, the server shuts down.
yes … I have installed local server before 2 days back.
Below is my server properties:
#hardware ssl port
#hardware plain tcp/ip port
#web sockets ssl port
#web sockets plain tcp port
#application ssl port
#by default server uses embedded in jar cert to simplify local server installation.
#WARNNING DO NOT USE THIS CERTIFICATES ON PRODUCTION OR IN WHERE ENVIRNOMENTS REAL SECURITY REQUIRED.
#provide either full path to files either use '.' for specifying current directory. For instance "./myfile.crt"
#Blynk server allows to use 2 hosts for same IP, below properties for second host
#by default System.getProperty("java.io.tmpdir")/blynk used
#folder for logs.
#log debug level. trace|debug|info|error. Defines how precise logging will be.
#defines maximum allowed number of user dashboards. Needed to limit possible number of tokens.
#defines maximum allowed widget size in KBs as json string.
#user is limited with 100 messages per second.
#in case of consistent quota limit exceed during long term, sending warning response back to exceeding channel
#for performance reason sending only 1 message within interval. In millis
#maximum allowed number of notification queue. Queue responsible for processing email, pushes, twits sending.
#Because of performance issue - those queue is processed in separate thread, this is required due
#to blocking nature of all above operations. Usually limit shouldn't be reached.
#Number of threads for performing blocking operations - push, twits, emails, db queries.
#Recommended to hold this value low unless you have to perform a lot of blocking operations.
#this setting defines how often we can send mail/tweet/push or any other notification. Specified in seconds
#maximum size of user profile in kb's
#period in millis for saving all user DB to disk.
#period in millis for saving stats to disk.
#specifies maximum period of time when application socket could be idle. After which
#socket will be closed due to non activity. In seconds. Default value 600 if not provided.
#leave it empty for infinity timeout
#specifies maximum period of time when hardware socket could be idle. After which
#socket will be closed due to non activity. In seconds. Default value 15 if not provided.
#leave it empty for infinity timeout
#Enables native socket transport for Linux using JNI. Should be turned on only if you 100% sure.
#may not work on some environments. Used to increase server performance. Performance boost is ~20-40%.
#Enabled native openSSL support for SSL handlers. Should be turned on only if you 100% sure.
#may not work on some environments. Used to increase server performance. Performance boost is ~16%.
#For more details see - http://netty.io/wiki/forked-tomcat-native.html
#mostly required for local servers setup in case user want to log raw data in CSV format
#from his hardware
#size of async logger ring buffer. should be increased for loads >2-3k req/sec
#administration https port
#reset pass port
#host for reset pass redirect. by default current server IP is taken. could be replaced with more friendly hostname.
#it is recommended to override this property with your server IP to avoid possible problems of host resolving
#comma separated list of administrator IPs. allow access to admin UI only for those IPs.
#you may set it for 0.0.0.0/0 to allow access for all.
#you may use CIDR notation. For instance, 192.168.0.53/24
#comma separated list of users allowed to create accounts. leave it empty if no restriction required.
That should be fine then… with the correctly setup…
#secured https, web sockets and app port
Listen, I can’t run through the whole setup with you… not when there are perfectly clear directions at the official links I have provided (I am working on my own stuff). And sorry, but based on all the wrong ports and such, I am not quite a believer that you have fully read them
As for other issues/questions, aside from searching this forum and reading the docs… make another topic so others can see the details and help with the API stuff (but simple answer is yes… if done properly )
Well look at the at AV issue… i am fairly sure that was the solution of other Windows Local Server users.
It is A way… but since the Blynk App is directly tied into the whole Blynk system (and the only non open source part), while you can use the API for external commands, you cannot NOT use the Blynk App.
You must use it to setup the accounts and projects in the first place… so this DIY App sounds like lots of extra redundant work to me… but fill yer boots