Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
CML Driver socket example?
Hi All,
I am trying to write a driver for an IP device.
It accepts connection on a single port, but after getting the data needed, the socket must be closed to allow for other clients to also connect.
In the process of opening a connection, if timeouts, will have to retry a few seconds later as likely another client was connected.
Can anyone suggest a driver for me to look as example? Only the socket opening/closing part.
Is this a stream socket or a datagram socket? If it's a stream socket you won't be able to do it, since that requires a listener socket and you can't create those in CML. If it's a datagram socket, then you don't need to close and re-open it.

If it's a stream socket, ca you connect to the device instead of the other way around?
Dean Roddey
Explorans limites defectum
Thanks Dean, should have been more specific...
I have a Davis Vantage Pro2 weather station and added to it a WeatherLinkIP datalogger. This uploads the data to Davis' webserver and Wunderground automatically without a computer on. Also provides a local server where I can query the data directly.

I was able to modify the existing driver made by Mikla on this forum by simply adding a "MEng.System.Runtime.StreamSocket;" and relevant stream socket parts.

The driver works just fine, creates all the fields and are correctly populated, updated. The issue I have that the connection opened from the driver is persistent and after that no data is uploaded to Davis' website and Wunderground.

I found the following in the FAQ's of the device.

Q: How do I communicate with my datalogger?
A: It should be as simple as connecting on TCP port 22222 and sending serial commands. You do need to ensure you use a raw TCP connection with no higher level protocol. It will momentarily refuse the connection if it is actively uploading to that moment, but if you retry in a few seconds it should work. Please note that in order to allow the IP logger to send to, you must release the TCP socket for about 5 seconds once per minute for the current conditions (loop packet) to be sent and about 60 seconds once per hour for the archive records to be sent up.

Note the part of releasing the connection. This is what I would like to implement in the driver and I am lost on how to do it. Thought to check the weather drivers shipped with CQC as they behave similarly, ie connecting periodically that can be configured, but those are not CML
How often are you polling the thing? If it's not often, I'd just open the socket long enough to do the query, then close it. Then open a new one next time. I.e. don't open it in GetCommResource and close it in FreeCommResource(), just open it when you want to do a query, then close it again. Then all of the above doesn't matter.

That assumes you are not needing to quickly poll it. If you only need to get the data once every five minutes or something, then it would be fine to just connect, query, close.
Dean Roddey
Explorans limites defectum
Currently the driver polls about every second.
There are quite some reads and writes taking place.

How frequent of a open/close sequence is too frequent that would overload my CQC server?
It's not that it would overload it, it's more than it's less efficient. Does it really need to poll that fast? I mean we are talking about weather data, right? Even fickle weather isn't going to change that much in five minutes is it?
Dean Roddey
Explorans limites defectum
When it is raining, or the wind is blowing yes, especially the wind. If windy, gusting, etc, rate and direction is constantly changing.
If it's not acceptable to do it every few minutes or something then it will just be a lot more complicated. Not a very well designed protocol really.

I would do it like this:

1. Have a 'next poll time' time stamp and an 'InBackoff' boolean member
2. In Init use SetPollTimes to set the poll time to 250ms.
3. If Connect succedds, set the boolean to false and set the next poll time to now plus a second.
4. In Poll, see if now is past the next poll time time stamp. If so, it's time to poll.
5. If time to poll, check InBackoff and if it's true, open the socket again and clear InBackoff
6. Do your poll
7. Use a counter to count poll callbacks. Every 45'ish times though, set the next poll time to now plus, say 8 seconds to be safe, close the socket, and set the InBackoff .
8. Every 3000'th'ish time, set the next poll time to now plus 70'ish seconds, close the socket, and set InBackoff.

So that will make you naturally backoff for the right amounts of time and use the same mechanism to poll normally as to do deferred polling.

If you try to re-open the socket and it fails, return LostConnection and let the driver go back to normal reconnection state.
Dean Roddey
Explorans limites defectum
Thanks, this is helpful, I am making some progress and will share what I came up with shortly.

One clarification I need is to where/when should I initialize fields, so that they are not discarded when the socket is temporarily disconnected?
Of course after the backoff is over, will refresh to sync the data.

Possibly Related Threads…
Thread Author Replies Views Last Post
  RainMachine Sprinkler Irrigation Controller Driver kblagron 60 21,744 07-17-2022, 08:36 PM
Last Post: kblagron
  SmartThings API V1 driver kfly 5 988 02-22-2022, 07:55 AM
Last Post: kfly
  Tesla Driver Driver kfly 14 6,138 02-21-2022, 10:11 AM
Last Post: kfly
  Help on editing existing Driver Spot 5 818 02-03-2022, 06:50 PM
Last Post: kblagron
  New to driver development - where to start? jokermac 2 797 09-22-2021, 04:01 PM
Last Post: Spot
  Yamaha RX-V673 IP control Driver jdmevo123 22 11,811 03-27-2021, 03:02 PM
Last Post: Spot
  Updated SMS Driver gReatAutomation 0 786 01-28-2021, 12:53 PM
Last Post: gReatAutomation
  Sage Media Server driver (beta) Fonceur 698 349,896 07-26-2020, 04:59 PM
Last Post: sic0048
  Russound MCA-66 on TCP driver 5 2,906 05-24-2020, 06:23 AM
Last Post: gReatAutomation
  Samsung SmartTV Driver George M 0 1,038 05-20-2020, 09:04 AM
Last Post: George M

Forum Jump:

Users browsing this thread: 1 Guest(s)