setting up a communication between two devices may be hard to bootstrap; if at first it doesn't work you typically have too little information to figure which side is failing and what should be done to remedy the problem.
However if your target device already exists, and expects HTTP GET commands (as your post suggests), then you should be able to test it from any browser, e.g. Google Chrome.
Mind you, the peripheral when receiving a GET command, is normally expected to return some web page, i.e. some data that has this structure:
... the head may be empty
... some meaningful text goes here
... counter = 102 (*)
it is wise to take care of that right away, as it will help you in debugging the system.
(*) I would also suggest to include a counter value, so each time a page is returned it is different from the previous one, in a predictable way.
Similarly I also suggest you give your peripheral an observable something, say an LED that toggles each time a page request is received (that is a one-bit counter!).
Now I see some potential problems:
1. your "command" is passed entirely as one of many possible web page URLs, and it seems to contain spaces, which are not allowed in a URL (i.e. they should be escaped, this turns every space into the sequence "%20")
I find it easier to avoid all special characters, including spaces.
2. I would prefer to work with only one page, and pass all the details (relay number, relay state) and even the password as parameters; parameters are key-value pairs, starting with a question mark and separated by ampersands, so it might look like:
3. Depending on what devices and networks might sit between your PC and your peripheral, there may be a risk of your command never reaching your peripheral, due to caching somewhere on the way. This can be remedied by some META tags in the HTML head (very tricky to get a general solution), or by adding an extra parameter which is always different, like:
As the URL of consecutive commands would all be different (having an incrementing sequence number), caches can not intervene.
4. You should be aware that an HTTP command may reach your peripheral (a) not at all (internet offers no guarantees), (b) just once, (c) many times. A browser is allowed to automatically resend a command that didn't get answered soon enough. So the concept of your peripheral and its command language must allow for unintended command duplication.
A safer way is to use an HTTP POST command rather than the standard HTTP GET command. This too can be achieved through a browser (e.g. there are extensions to Chrome for this purpose).
Once you got all the above up and running fine, you can try and create C# code that replaces your browser. There are at least two ways to handle this:
1. using a WebBrowser [^] Control, which basically is the kernel of Internet Explorer with an API so you can set the URL and request a page, view it, etc. When you're done debugging, the WebBrowser can remain off-screen or be otherwise invisible.
2. using some classes from the System.Net namespace, such as HttpWebRequest[^]. I suggest you google for some examples.
Hope this helps
modified 4-Jan-19 21:58pm.