suggestions for enhancements to webcontrol (not 32)

[mc2000]

WebControl 8 newest firmware 3.02.16 allows each of those 8 emails being send to 8 different receipions. In addition, it allows one board to do HTTP GET call to set another Webcontrol board VAR or OPx value from PLC logic. This HTTP GET can also set to web servers, if the server has proper CGI code to process the call made from WebControl. When the other board or remote web server is down, future HTTP GET call will not send.

Do the Sending and Receiving board (of the HTTP GET plc command) both need to be v3.02.16 firmware, or
can a sending board v3.02.16 firmware work with a receiving board with older (say) v03.01.03 firmware?

Can you give an example of the plc command for the HTTP GET function?

thanks

 

[CAI_Support]

The sending board must be on V3.02.16 to have the WEBSET command in PLC. The receiving board can be any version of firmware.
You can define 8 "URLs" in 3.02.16 firmware, the URL is in the format:
192.168.2.15:81 /api/setvar.cgi?varid=2&value= www.mydomain.com

ipaddort URI optional domain name for virtual hosting in ISP
port is optional, withoutport, WEBSET will use port 80
URI is whatever WebControl or web server URI, note there is no space after last "=" sign, so that the value can be added later
optional domain name is for virtual host name, in case the receiving is a hosted server in ISP

in PLC, you can call it like this:
WEBSET URL1 1234
or
WEBSET URL2 RAM2

Inside WebControl, we will actually construct the URL with your URI and value to

"http://192.168.2.15:...id=2&value=1234"
or
"http://www.mydomain....id=2&value=1234"

If you have server receiving, you can see in the MIME header, WebControl firmware also send its MAC address and hostname in the VIA tag for identify the sender.

 

[CAI_Support]

When you say "the first 64 bytes" of the server reply - do you mean of the header, or of the data past the header?
I think it's going to be a very big ask to expect people can get their user data within the first 64 bytes of the reply including header, because many http daemons don't provide for insertion that early.

If it's after the header then fine, and if you specify the answer will be (say) "immediately after the =" or whatever, then so be it.
If you have the codespace for it, it would be perhaps "nice" if the server could reply with something like:
var1=12345 - perhaps be able to specify where the answer will go? Perhaps be able to return multiple answers?
Imagine: a webcontrol board could come on-line, make a request of a "provisioning server" which could send back a bunch of registers. The lat/long, unique ID code, time offset and local variables relevant to that webcontrol boards purpose!

Thanks, Ross,
For CGI code to reply the client, the CGI code can almost control how the reply looks like, for example, what is the return code, what is the message contents. The prefer the reply is: Content-Type: text/plain, so that no fancy html encoding.
On Linux, you could even use shell script to genrate reply just echo whatever you want to reply to the client.

You have a good idea to get whole configuration back through the HTTP client, we could try that on the 32bit board, but on this board, we probably could only do a thing like SETVAR?VARID=1&VALUE=12345, kind of thing.

 

[LarsK]

A USB power supply would be great. Using a cell phone USB adapter the output would be 5V 1A.
Using the mini/micro plug on the WC board would make it sleek.

Here is a Raspberry Pi powered by USB:
(Made my idea)

 

[CAI_Support]

Using USB power WebControl board is possible, you can bypass the 5V reulator and directly power the board with that. If you do that, you can replace the diode D1 with a fast fuse, short the pin1 and pin3 on the 5V regulator. don't toss out the protection diode, put that in parallel with C1 or C3, in the orientation so that in case power polarity was reversed, it would cause fuse to blow out.

The USB must provide enough current to power WebControl board. Most USB power cube with greater than 0.5A will be fine.

Fast fuse can be like this one:
http://www.ebay.com/itm/170935013020

 

[LarsK]

Hmmm.. maybe time to start soldering.
Could this be a future option?
Most users will have several USB cubes around not in use.

 

[CAI_Support]

If you are sure you have USB power polarity right, you can power the board even from temp sensor or humidity sensor terminal, just feed 5V to pin 3 and ground to pin 1. However, that is without any protection. Our engineers found accidents do happen, especially if you connect to it on and off during experienmenting. That is why we have the protection diode and regulator, just to prevent in case.

You are correct that there are a lot of USB power cubes due to most cell phones are using 5V power to change now.

 

[todster]

This would be a cool command. Using the contents of a var indirectly.
This probably isn't the best example for usage
 
INC RAM1
Set ALLOUT var[ram1]
 
Probably not doable though.
 

 

[rossw]

This would be a cool command. Using the contents of a var indirectly.
This probably isn't the best example for usage
 
INC RAM1
Set ALLOUT var[ram1]
 
Probably not doable though.

 
 
I've asked for this before, I can't recall the rejection reason though.
It would make a LOT of things cleaner. Loops and Subroutines particularly so.

 

[todster]

Maybe in the 32 board?

 

[CAI_Support]

Hi Todster and Ross,
 
Sorry for I am slow understanding what this code
INC RAM1
Set ALLOUT var[ram1]
 
do you want to use RAM1 as non-blocking delay value?  Non blocking delay only can be put on the value being set, not on the value reading from.  In addition, if we implemented ALLOUTS, that will have no non-blocking delay associate with it, due to each bit of the output has its own timer already, those timer must be set individually.
 
If you could please let us know what the actual behavior you want to have, we will try to implement that.

 

[rossw]

Hi Todster and Ross,
 
Sorry for I am slow understanding what this code
INC RAM1
Set ALLOUT var[ram1]
 
do you want to use RAM1 as non-blocking delay value?  Non blocking delay only can be put on the value being set, not on the value reading from.  In addition, if we implemented ALLOUTS, that will have no non-blocking delay associate with it, due to each bit of the output has its own timer already, those timer must be set individually.
 
If you could please let us know what the actual behavior you want to have, we will try to implement that.

 
Todster has used the square brackets in a manner that's confused you, but in a manner that's consistent with our use of indirection from other languages.
 
In his example   var[ram1]   which in my emails to you way back, I think I'd used   var(ram1)   to reduce confusion, he is suggesting that we want to read a variable who's number is indexed by the value of ram1.
 
Thus, if  ram1 = 3,     var(ram1)  is   the value of var3

 

[CAI_Support]

Thanks for explaining it, Ross.
I think it is easy to think VARs are continue allocated memory, so that index will move to next position in the storage. In WebControl, VARs are not internally stored as an array. Rather, each VAR is a structure itself to maintain timer and other information related to its own history.
 
index is a good idea, I will discuss with out engineers to see how can we support that.

 

[rossw]

index is a good idea, I will discuss with out engineers to see how can we support that.

 
 
 
When talking to s'ware engineers, be aware that "indexed" and "indirect" are not the same thing. Be sure to give them an example of what you mean

 

[todster]

The brackets were an error on my part. I should have used something a bit more unique to encapsulate it. I wasn't interested in indexing through registers.
 
SET VAR1 AI1
SET VAR2 AI2
SET VAR3 AI3
......
Set ALLOUT var(ALLIN)
 
As Russ pointed out, there is a difference between index and indirect.
I'm proposing more than just var's.  A var is just the most popular use. This would work almost anywhere a number is used. Instead of a number we will use the contents of whatever register we insert in ()
Something Ross could use to establish accel rates for his solar panel tracking
 
ACCEL:
INC VAR1 (AI1)
DECEL:
DEC VAR1 (AI2)
The closer he gets to the end the slower the motor speed.