Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
iOS App for WebRIVA - CTC CQC
#71
(03-31-2018, 04:11 AM)lcrowhurst Wrote:
(03-31-2018, 02:07 AM)znelbok Wrote: So is this using the Listening TCP trigger driver to work with the new functionality - if s what port is being used.  The port being used by the WebRIVA server can't be used.

What is the line termination CR, LF or both?

Sorry I haven't got a CQC so hopefully Im answering this correctly.

But yes the listening TCP driver, I don't know what port it uses , but in the setting for CTC CQC under the Today widget section you can set the port that is used by CQC.

I add a \n (LF) to any text entered.

i missed the Today section in settings - so that all makes it easy now.  I'll do some testing with it later tonight
Mykel Koblenz
Illawarra Smart Home
Reply
#72
OK, First comments

The driver want to connect to the port and if the server i.e. iOS is not listening then there is no connection and the driver will not connect. Only when you go to the widgets does iOS create the port and the driver then connects.

When you press one of the buttons to train the driver you can see that CQC has seen the data in the log files, but you can not re-send the command again by pressing the button again - it needs to be sent three times to train the driver and it appears that the iOS widget will not allow the command to be sent more than once - Please check if this is an app restriction or apple restriction.

Once the widget is closed off and you return back to the home screen the driver drops back to not connected because the connection is not persistent.
Mykel Koblenz
Illawarra Smart Home
Reply
#73
I didn't think about that. So maybe the HTTP one would have been a better idea, since in that case the iOS program would be the client and the driver is the listening server. It would be pretty easy to convert it to that form. The only thing in the program that would need to change is that it would issue an HTTP GET instead of a sending a raw text value over a socket. Parameter would be sent as URL query parameters. The names don't matter, so ?v1=x&v2=y and so forth.
Dean Roddey
Software Geek Extraordinaire
Reply
#74
"The driver want to connect to the port and if the server i.e. iOS is not listening then there is no connection and the driver will not connect. Only when you go to the widgets does iOS create the port and the driver then connects."

Sorry I was under the impression that the CQC acted as the server . I havent got a CQC, so wrote some code for the Wiser that i originally created the app for, so that is acted as the server. When you press a button on the Widget it creates a connection , sends the command and closes the connection.

“When you press one of the buttons to train the driver you can see that CQC has seen the data in the log files, but you can not re-send the command again by pressing the button again - it needs to be sent three times to train the driver and it appears that the iOS widget will not allow the command to be sent more than once - Please check if this is an app restriction or apple restriction.”

The Button in the widget should be able to send the  command s as many times as you need, to the “CBus Wiser” I can send as many times as I like


“Once the widget is closed off and you return back to the home screen the driver drops back to not connected because the connection is not persistent.”

The connection is only created once a button is pressed


“I didn't think about that. So maybe the HTTP one would have been a better idea, since in that case the iOS program would be the client and the driver is the listening server. It would be pretty easy to convert it to that form. The only thing in the program that would need to change is that it would issue an HTTP GET instead of a sending a raw text value over a socket. Parameter would be sent as URL query parameters. The names don't matter, so ?v1=x&v2=y and so forth”

As answered above, yes the iOS is the the client. I i change the code to issue a HTTP Get , can you give a couple of examples of the Url (address and parameters) I would need to send. Im guessing the parameters can still be entered in the Button send box.

Can the CQC Trigger driver act as /be altered to act as a server?
Reply
#75
As a rule the trigger drivers don't act as servers for security reasons. They will only connect to things that they know they should connect to. But I was a bit brain friend when I wrote that last night. The HTTP one of course has the driver as the server. And there is also a listening version of the generic trigger driver. So as long as they use that one, then, yeh, your application would be the client connecting to it.

I guess when the client disconnects, the driver consider's that it has 'gone offline'. It was mostly written I guess with the scenario in mind where the other side was some sort of other server or device that would always be there. But it shouldn't really consider the client not being connected as an offline condition since they could be mobile devices that come and go.

I'll take a look at that, but in the meantime, you are good as you are, so ignore the above.
Dean Roddey
Software Geek Extraordinaire
Reply
#76
(04-02-2018, 07:31 AM)Dean Roddey Wrote: As a rule the trigger drivers don't act as servers for security reasons. They will only connect to things that they know they should connect to. But I was a bit brain friend when I wrote that last night. The HTTP one of course has the driver as the server. And there is also a listening version of the generic trigger driver. So as long as they use that one, then, yeh, your application would be the client connecting to it.

I guess when the client disconnects, the driver consider's that it has 'gone offline'. It was mostly written I guess with the scenario in mind where the other side was some sort of other server or device that would always be there. But it shouldn't really consider the client not being connected as an offline condition since they could be mobile devices that come and go.

I'll take a look at that, but in the meantime, you are good as you are, so ignore the above.

I'm trying to get this functionality working with no success. I'm using the Generic Listening IP Trigger Driver with CQC v5.3.2. The CQC system logs are showing that CQC is receiving the command text from my iOS device, but when I try to "train" the trigger driver, it doesn't receive the command text. I'm suspecting that this is because the trigger driver is not yet handling the fact that the client is disconnecting after each command text is sent.

Dean, have you had a chance to look into this as yet?
Reply
#77
I can't remember now, that was a while back. But I think that it would still assume that it is dealing with a persistent connection.

What kind of signal are you sending it and what are you using to send it? Can you send an HTTP GET instead? That wouldn't have this sort of issue.

And I guess also, what are you using it for? We have our WebRIVA client so you could run real CQC touch screens on your iOS client now. So you'd only need to do something like if you wanted to trigger something from some other source on the iOS device that a touch screen interface.
Dean Roddey
Software Geek Extraordinaire
Reply
#78
I'm just sending it plain text signals using the capability of the CTC CQC app. I have no idea if I can send a HTTP GET instead - if its as simple as prefixing the text with HTTP GET, then I guess no problem. But that seems to be a workaround.

I am running real CQC touch screens on the iOS client using the CTC CQC app, and they work pretty well. However, making use of the today capability of the CTC CQC app provides nice shortcuts for users to perform frequent actions very quickly and simply.
Reply
#79
By CTC CQC app you mean the iOS RIVA app? If so, you don't need that anymore. We have a browser based client that works basically the same but better. It works through our web browser.

https://www.charmedquark.com/Web2/CQCDoc...=/Overview

It won't be as simple as prefixing it with HTTP GET. You have to send an actual HTTP GET request, which is a bit more than that.

I'll have to back and look at it again, but I'm pretty sure the situation is still as above. The HTTP guy just waits for HTTP style connections which are generally one shot type things, then it starts listening for the next one. The generic listener guy waits for a connection before he considers himself 'online' and assumes he's going to continue to talk to whoever connected. When you disconnect, he considers that a failure and goes back offline, probably before the incoming message is actually processed.

I guess it COULD act like the HTTP one does. But it would break any existing users of it who are assuming it's an ongoing connection, because the driver would then break the connection after reading a command. It might require a separate new driver that works more in the HTTP fashion.
Dean Roddey
Software Geek Extraordinaire
Reply
#80
Yes - CTC CQC is the name of the iOS RIVA app. I have it working perfectly to access WebRIVA interfaces. I am now looking to extend my usage of it to take advantage of the iOS Today capability that the iOS app has, but it appears as though the way it works and the way that CQC trigger devices work are not compatible. The iOS app does not send HTTP GET commands and the CQC generic listening IP trigger driver requires the IP connection to be retained during learning.

I don't understand the statement "we have a browser based client that works basically the same but better". How is running a web browser on my iOS device better than being able to setup a local app on my iOS device that knows CQC user credentials, server address & port, options to recognise portrait v landscape etc?
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)