I've got some piece of hardware that uses ModbusRTU. Using a TCP/IP Gateway for ModbusRTU I can now control the hardware using my C# application over TCP/IP. This works.
Now I would like to control it with my android phone.
Yes, I could make an Android app, what should be no problem for me, but I want to make it more special for myself to fix it with the web browser. That way I'm even more flexible since other OS's should be no problem too.
I'm interested where I should start looking if I want to control the hardware by using the web browser. What programming language, what are the server requirements.
Please mind that I've have very little experience with web browser programming but I'm eager to learn it. Did just some very simple things with PHP / Ajax.
Fyi, the ModbusTCP packeds are really simple, I only control some lights on/off/dimming at my home and to enable some equipment.
I am currently playing with the Marmalade Quick beta which can open a TCP port in Lua. This is a simple high level language, with a build system for Android.
http://quick-docs.madewithmarmalade.com/
Which Modbus lighting controller are you using?
Related
I'm working on a project and am looking for a way to connect with ESP8266 via WiFi module on ESP8266. I have to build use this method, through the windows desktop I can control the movement of robot. From C# to ESP just like remote control project. I have a lack of knowledge of C# same as basics of servers/internet but I have everything done in Arduino IDE code and control the robot through web browser but I'm stuck on Communication Wifi between C# and ESP866. I need some help. Thanks in advance
You can host a REST API Server in the ESP8266 with the using the ESP8266WebServer and use your usual REST Programming in C# like RestSharp or Flurl.
Im creating a web application that can view a few database tables. You can even update the tables from the web application. Everything works fine, but I want the tables also to be updated in realtime when the tables are changed from another client! And even from my windows application. I've heard that you can use websockets between clients. But Can you also use websockets from a windows program to communicate with a webserver? (on the same computer)
All client examples Ive found so far uses javascript, so I think the answer is no, but hope Im wrong. I was planning to use signalR.
Im writing in C#.
Yes. Websockets are not natively in the .NET library for clients. But there are good 3rd party libraries which are free.
I have used WebSocket4Net. https://websocket4net.codeplex.com/
WebSocket is an official IETF wire protocol that can be used by any language. WebSocket is also a W3C official JavaScript API, but there are other language bindings that mimic the JavaScript standard, e.g., Java, C#, C++, iOS, Android, et al.
The Kaazing Gateway has C#/.NET bindings for WebSocket. Here's the 4.0 binary: http://developer.kaazing.com/downloads/byop-edition-download/
Search for "Kaazing" in Github to get the src.
Full disclosure: I work for Kaazing.
I have developed a Windows Phone application that uses camera to take pictures every second. Now I want to send these images to my Windows desktop application.
Besides images, I'm planing to send GPS data and other sensors' data to my Windows desktop application in the future.
I believe I can use System.Net.Sockets.Socket, but what I get from Socket is byte[], I don't know which part of the array is an image and which part is the next image. I need special coding.
Are there object-oriented ways to send data? Does .net remoting and WCF work on WP? What's your suggestion?
The target Windows Phone OS version can be 8 or 8.1.
Don't reinvent the wheel. Opening a socket in this case is just about the same as starting a self-hosted http server, except with the http server all your problems are solved.
While with sockets, you have a lot of protocol and headaches to solve, with the HttpServer you got a ton of proven and tested code at your back, helping you solve your problem faster, plus everyone knows Http, so it's also easier to understand and maintain.
One way could be to roll up a Self-hosted Web API
Overview
C# File - Users PC
PHP Server - Hosts Webpages for application
Server and Users PC on local network
I have a c# file that reads weight from a USB scale. How would I trigger this file to run so it feeds into my program. The problem is I am using PHP to host our webpage/application so its not running client side and the scale is not hooked up to the server but to the clients PC.
The C# script would have to be on the clients in order to read the scale so how would I trigger this to happen?
Is this even possible and if not what would be a better way?
Important Edit
I was able to run the Scale Script (C#) when I wanted by having PHP and C# use TCP sockets.
The C# would listen for PHP to send something and when it did it would read the scale and send this information back to PHP becuase PHP was listening for a response. Mixed in with a little Ajax and it updates in the web browser.
Gave Chris Credit because he was the most helpful with answering my questions
It sounds like what you really want is for the client application to submit the data to the website itself, and the most suitable approach is probably to expose a web service from your server.
This service should accept weight data, along with some sort of customer key or whatever, to correlate the records correctly on the server side. I've never created a web service in PHP personally, so I can't give any advice on the implementation of that, but it is fairly trivial to hook a C# client app up to a web service once you've exposed its metadata (assuming you use SOAP).
you can't start C# application from a web page in a way that'll work in every browser every time. BUT, you can have some workarounds:
Use ActiveX component that read the data in the client and upload it to the server. the biggest cons is that it'll only work in Internet Explorer
use Silverlight client application that runs on elevated mode (v4) and upload the data to your server.
refer your clients to download application (the C# application you wrote about) and run it - this application will upload the data to your server.
hope this helps.
C# isn't a scripting language, it's a language that compiles into executable binaries or libraries. You won't be able to execute C# code on the client's computer via a website because C# code needs to be compiled before it can run.
Presumably what you really want is for your compiled C# binary to be executed on the client's machine via your website. You won't be able to easily do that. There are a lot of security measures in place to prevent browsers from running programs on your computer. There may be ways to hack around these security measures by using plugins (such as ActiveX), but it's not something that will be a one-liner.
Edit: I think you need to step back and think about what you're trying to do in a broad sense. You're trying to create a website that can read information from a user's USB port. This is the type of thing that browsers are designed to prevent, and for good reason. I wouldn't want random websites to be able to access peripheral hardware without my explicit permission. If you want this website to function the way you're expecting, you're going to have to seriously think about the security implications. You'll need some kind of client-side code (ActiveX, Silverlight, ...), and the user will need to explicitly give permission to for this all to happen. It won't be easy, and it won't be automatic. And I'm damn glad that's true.
I am making a medium sized standard LOB application. Currently its a web application but I am formulating a proposal to revamp it into a Desktop remote application. By this I mean that the database and the application server will be hosted in a remote location. The client application will communicate with the server via the internet through (either WCF / Webservices / Remoting).
My question is this: The only reason I am shifting this from a web platform is due to the constraints of the web (I dont want to do AJAX or Java scripting to minimize those constraints, so please no JS/AJAX recommendations). I have made traditional desktop applications and they are considerably fast but i have never made a remote or a distributed application. I am not sure weather the speed of the application will be faster then the web or not.
As I understand it, the remote desktop application would be much faster. For one, there wont be any post backs involved, (I hate them so much). The data will obviously come via internet, so in that respect, is it better to shift to the remote desktop just for sheer speed and power?
Any help in the right direction would be greatfull. Many thanks.
Zeeshan
I think biggest advantage of desktop clients over web applications is freedom in UI design, and you don't have to worry about any inconsistencies in the client environment, although those are not an issue if you are using a client that runs on silverlight.
Personally I don't like web applications that requires a lot of user interaction, there are some of them that is a pleasure to use but I think it is very easy to do it the wrong way and end up having a buggy or not so responsive application (probably because of the incompatibilities in browsers, I have IE, Firefox and Chrome installed on my computer and I use one for some websites because they run faster on it, and others for other sites because web pages show up correctly only on them). Though this might not be an issue for a silverlight client.
In case of network speed, depending on the things that goes on the wire even with binary serialization remoting might have quite a bit of overhead. For example along with the data it writes full class names, library names and their versions so it can get pretty big and slow even for small amounts of data (although it should still be smaller then HTTP). It also has the same problems that HTTP has over unreliable connections because it uses a similar protocol. For one project we had to write a custom serializer for some objects because binary serialization alone was generating 200K, but our custom serializer for those objects were generating 50K. Then we ended up writing our own network protocol because the one that comes with the runtime was frequently stalling over unreliable wireless networks, and remoting doesn't give any control on the socket created by it (which makes sense in terms of encapsulation but you can't close it and force it to open a new one).
(I am assuming that you are asking about remoting vs web app. not remote desktop vs. web apps, because of your note about post back, you can't avoid it with a remote desktop session)
Rewriting an application just for sheer speed? No, because probably user won't see much difference in response time.
You are somewhat ambiguous with your terminology - do you want a client app that runs on the user's machine, or do you want an app that runs on the server and the user connects via remote desktop (RDP)?
If you are talking about a client app that communicates to the server via WCF etc., then yes it will be faster than a standard web app, although it will still be slower than a native desktop app. It will be faster than the web app not just because of the lack of postbacks, but also because you will be sending pure data through the wire, not a massive amount of HTML/Javascript combined with your data. With a client app, you have several options so consider them carefully - do you want Silverlight, WPF, or a native WinForms app? Each have their positives and negatives.
If you were talking about having a client app running on the server which the user then access via RDP, then you have other considerations to think of. For any more than two concurrent users you will need to consider buying CALs so the users can connect to the server. At this point you should also be considering whether you should be running a terminal server or Citrix type setup instead of using remote desktop.
Edit
When using WCF over a WAN (internet) you will certainly have to consider how you will secure it. WCF makes it trivial to secure the channel, but you need to consider how you will do authentication - there are a couple of different ways, but you can easily google that stuff yourself. The method you choose will be important due to the limited resources or skill-sets of the users.
As for what you write it in, you can't argue with Winforms if that is where your experience is. Personally, i would never again use ASP.NET/Ajax/etc for a web type application, it would be WPF or Silverlight all the way (i would only use ASP.NET for simple web sites). You can use the express (free) versions of Visual Studio to write it in, you don't need Expression (it's just a nice to have, and is more aimed at the design side than the actual coding side). Deploying the app need not be difficult - Silverlight or WPF xbap are delivered via the web, the user has to do nothing (except for the simple install of the Silverlight plugin or installing the right .Net framework for WPF - check this link). Winforms or stand-alone WPF require slightly more work, but you can avoid most issues by writing a good installer.
Whichever you choose, make sure you don't under estimate the time for development (because you will have a bit of a learning curve), and also make sure you budget enough time for testing it - especially the security side of it :)
I have been in a similar situation, although started with a Winforms LOB application.
Heres what we found with WinForms...
It's going to be harder to deploy in your release cycle, to all client machines.
WinForms can't be run on other operating systems easily. (with the exception on mono)
WCF endpoints can get complicated, and you need to manage an endpoint for release/version of your application.
Authentication, Authorization and Security can be tricky to get right!
Heres why you should stick to a html web application.
it's going to be easier to deploy, as you just need to copy one set of DLL's into the bin folder. Can be scripted from a continuous integration or staging server.
Security is going to be easy, by using a SSL certificate.
Silverlight/Flash should fill in the gaps that HTML leaves out.
Microsoft has also combined the connected systems in .net 3.5, they now call it WCF (ASMX/Remoting/etc...). It's got quite a learning curve 4-5 weeks.