suggestions for enhancements to webcontrol (not 32)

[Efried]

Many thanks for the hint, will buy ASAP. However this is no industrial solution. My WC has now operated for some (very hot) days, but the first Chinese device similar to the TP-Link was overheating and not working properly from the start. Hop this one is besser and consumes less.
I'm surprised hearing about 5V power supply for the WC. Would that lead to less heat dissipation or induce problems to the DC-DC voltage control instead of 7V?
Apart from reversed polarity there are other potential traps Fortunately I had some fast fuse preventing short cut in the WC from incorrect placement of a relay. If you have no total insulation from switched power this might be risky. Also differing ground levels with sensors. So alltogether integrating most of the periphery into the WC biotop, working with breack out boards or "stacks" would higly appreciated.
 
 

Thanks for the feedback. There is a little wifi device made by TP-LINK TL-WR702N. In that it has a wifi client mode. If you configured WebControl on your network already, simply configure this tiny little device into wifi client mode, select the SSID and enter your security mode and passphase, then connect WebControl to it. Your WebControl will be on the wifi network through that.
 
You can also using a DC-DC converter to get your solar panel's DC output regulated to 5V, directly power that TP-Link wifi client and WebControl. Please make sure voltage is connected correctly, if powered in a wrong direction, WebControl board will be fried immediately.

 

[CAI_Support]

As long as no noise being feed through power to the WC board, you should be able to use your own DC 5V power source.
Many consumer router or wifi having heat problem. One way to "fix" that problem is open the box, add your own heatsink to the main chip in wifi or router.  You will be surprised how much improvement that can be.
 
We use a lot routers and wifi aps in our office. We always add heatsink to them. We never had one device failed after adding heatsink, really improved network reliability.  Silver based Epoxy works best for glue the heatsink.

 

[rossw]

CAI, have you had any thoughts about how you might (or if you would) permit using more than one var/ram in a webset command?
 
That is, at the moment you have a setup section under notify where we can specify an IP address and host, plus the "get URI", then in our program we specify a var/ram to be appended to the URI that is sent.
 
I've got several situations where I'd like to send multiple variables. It'll always be the same ones, it just seems far more efficient to do it as one GET rather than a great list of them, repeated.
 
So for example, rather than a GET URI of   /path/to/my.cgi?temp1=
and then in code telling it to use RAM1, then using another webset with a different URI to send another variable - we obviously have a limit of 8, but it really is quite inefficient.
 
If we could have something along the lines of    /path/to/my.cgi?temp1=$VAR1&thing2=$RAM3&thing3=$VAR4  
The actual values of RAM3, VAR1, etc, would be substituted as the query is sent to the host.
 
What think ye?

 

[CAI_Support]

Hi Ross,
 
Thanks for your suggestion.  Our implementation for the WEBSET is to capture the value at the time call made into a queue, then later when enough network resources available then send it out.  To queue more than one variables in each queue position will require to increase the queue size, which will need more RAM. We can definitely change the 32bit version to do that.  It will be difficult to do that with RAM is so limited now on the WebControl 8 board.

 

[rossw]

Hi Ross,
 
Thanks for your suggestion.  Our implementation for the WEBSET is to capture the value at the time call made into a queue, then later when enough network resources available then send it out.  To queue more than one variables in each queue position will require to increase the queue size, which will need more RAM. We can definitely change the 32bit version to do that.  It will be difficult to do that with RAM is so limited now on the WebControl 8 board.

 
 
Yup. Understood. However, in my case (not necessarily others) - I could easily live with the system filling in the value at the time the command actually processes. It will be easily "interlocked" by setting all the variables I want to send, then calling the webset command and then (critically) - waiting for the response back from the server so I know it has been received.
 
If no response in a reasonable time, wait, re-try and finally give up or do something else.
 
If the limitation was clearly stated in the manual (ie, that the values will be completed by the core at the time they are actually transmitted, and not necessarily at the time the event was queued) I don't think there would be any problem. The advantages will far outweigh the disadvantages!

 

[CAI_Support]

Hi Ross,
 
If we do not capture the value at the time of trigger, then it is possible to dynamically format the string and send them to server. However, if that value is changing fast, the time server received could be far apart from the time triggered.  Let us chow it over and think if we can come up a solution to have both.

 

[rossw]

Hi Ross,
 
If we do not capture the value at the time of trigger, then it is possible to dynamically format the string and send them to server. However, if that value is changing fast, the time server received could be far apart from the time triggered.  Let us chow it over and think if we can come up a solution to have both.

 
Certainly.
However, I repeat - simply knowing that there could be some non-trivial delay, and the fact that you already return a figure from the server, means it is possible for the code to actually set the variables, then wait until they get through before changing them. So there's a "user work-around" for the potential problems of such delays.

 

[CAI_Support]

If those bits represent which door or window was broken, or which pressure sensor caused problem, that could be not recoverable data.  In our minds, we always consider the case that user got this information is last communication. That might be more important than other changing within the system  limitation.

 

[rossw]

If those bits represent which door or window was broken, or which pressure sensor caused problem, that could be not recoverable data.  In our minds, we always consider the case that user got this information is last communication. That might be more important than other changing within the system  limitation.

 
I think we are talking at crossed purposes. How is it different trying to find somehow the extra RAM to store the variables (which you've already said is virtually impossible) operationally different to letting the user set (lets say, just for argument) 6 VAR or RAM variables, calling the webset command (in exactly the same way as if you were able to store the variables).... but instead of the program continuing to run and do things that would alter those variables - to preserve them until such time as a valid response comes back from the server to acknowledge it has been received ok??
 
As an example: a weather station.
It accumulates some information. Max/Min Temperature, humidity, wind speed, gust, direction, barometric pressure, rainfall. These are all captured and need to be sent back to a server. A webset command is sent, the station continues to record rainfall, wind etc, but doesn't over-write the "being sent" data until such time as the ack response comes back.
 
(I do this now sending data back and forwards from my trackers - only it's horribly inefficient as I have to send multiple requests to send all the data back to the server - even though I encode multiple data points per word (eg, elevation, azimuth and unit are one word, actuator current, status and unit in a second word - but I still have to do it 6 times (that's 12 requests) - and with redundant information (unit number) replicated. Could be far more efficient!)

 

[az1324]

Why don't you just have the server fetch the xml page and parse all the data that way or parse it out from an email?

 

[rossw]

Why don't you just have the server fetch the xml page and parse all the data that way or parse it out from an email?

 
That's what I do now.
But for something to deploy to other users it's not going to work.
1. The WC will almost always be behind a NAT firewall/router, so can't fetch FROM the WC
2. Many ISPs are now blocking outbound mail, so would require end users to set mail in the WC config (NOT something I want)
3. Email is far too slow and unreliable for real-time events.
 
But apart from that: good idea

 

[az1324]

Run a small process that will accept the SMTP protocol on your server and it shouldn't be any slower than webset.

 

[rossw]

Run a small process that will accept the SMTP protocol on your server and it shouldn't be any slower than webset.

 
You missed the bit that some ISPs are actively filtering outbound SMTP.
I could run it on an "unusual port" but that will cause other (unrelated) problems.
Also, SMTP is far from efficient. If you've ever sniffed the exchange between a WC and an SMTP host, you'll see there is a LOT of traffic (I was watching it send a single character at a time - one packet each!). If you're using a 3G/cellphone connection, that will get expensive, fast. It also doesn't scale well.

 

[az1324]

You mean they are filtering port 25?  Or they are actually using packet inspection to filter SMTP?  It should not be hard to find another port to run it on.  You could even patch a webserver to accept it along with HTTP on port 80.  Yes the transmission of email sounds very suboptimal one byte at a time.
 
But really it sounds like you would be better served with a platform that you can customize fully like arduino, beagle bone, pcduino, etc...

 

[rossw]

But really it sounds like you would be better served with a platform that you can customize fully like arduino, beagle bone, pcduino, etc...

 
I like the WC boards. They've more-or-less got everything I need on one board without needing to add ethernet (particularly).
I can set one up and send it to a customer easily. If they blow it up, they can just buy one locally and I can usually get access to it via rdp, teamviewer, etc, to program and set it up. The functionality in the PLC side makes stand-alone systems useful and practical. Time to develop/deploy is minimal, etc. The suggestion for multi-variable webset is just a "nice to have" enhancement. I've got 50 or 60 of these things deployed already and use smtp or http, but have to either jump through hoops to make it work, or suffer the inevitable performance issues.