Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
iOS App for WebRIVA - CTC CQC
#31
(03-04-2018, 04:56 PM)Dean Roddey Wrote: For that sort of stuff, CQC has a set of 'trigger drivers'. These can be configured by the user to run CQC actions based on incoming data. That can be IR, or text over serial/socket. The format is arbitrary, so you can just let them configure something. Or, for canned operations, you can provide some standard format.

Also, and important factor is that these drivers allow for parameterization. So the user, when installing the driver, can define a separate character, e.g. # or whatever. Then you can have commands like this:

/Set/TV/Channel#123

CQC will react to /Set/TV/Channel as the key to look up the action to run. It will pass the values after the # as parameters to the action. So you can have a single command to set any channel. This is important because the user will be configuring that action that responds to /Set/TV/Channel. They don't want to have to have a command per channel.

The format of /Set/TV/Channel is arbitrary. It can be whatever (as long as it doesn't include the separator character.) But that sort of path based scheme allows for a hierarchy of commands. For those folks who want to write a CML command handler, they can parse that path and have a single macro that handles a number of different commands.

But, generally speaking, I'd say just let the user define what command to send, and just send that text. That's how most programmable RF type remote control systems work, and it works out pretty well that way. And that way, you don't have to try to figure out what commands to send, since they will pass through a layer of user defined abstraction.

Of course you could have some predefined ones to let them choose from. They just have to set up a handler for those if they want to respond to them.

For training purposes, they just make the signal be sent out a few times in a row. Once the driver sees the same signal a few times, he knows he's getting the right stuff and saves that as the key for that action that they configured.


Does that make sense? BTW, one reason for this is that we'd never open up CQC directly to third parties like that. It would be a huge security hole. Users can choose to allow it, and since they define what operations are available, it's not an open ended access mechanism. It can only be used to invoke commands they have expressly decided to handle.

Does the trigger driver return any string eg "OK" today commands received and acted on. Can it be used to get values etc?
Reply
#32
No, since the same system also has to work for IR. If you really want to do a client with two way control, there are two options:

1. The XML Gateway. This provides an 'XML over Sockets' interface to CQC. This is a regular socket connection, so it's all synchronous. You can run it in a background thread with queuing of commands/responses if you don't want to block the UI thread (or aren't allowed to.)
2. Using WebSockets talking to our Web Server. This requires a handler exist on our Web Sever for such a client. So you have to create both sides of the conversation in that case. That allows for the creation of a completely customized, no more than it has to be, type interface of course. Though, it also means that you are limited to the asynchronous, callback nature of Websockets, which can be annoying. And you may not have a WS client available to you, I dunno.


Both are real interfaces so they act as a proxy for you to let your user log into CQC. They maintain the credentials for you as long as the connection is maintained. Of course if you lose it, you can auto-reconnect since you know have the info that was provided by the user for login. Well, in the case of WS, you would use HTTPS/WSS to do the talking, and you would just pass a username/password over after the encrypted connection. Your handler there can ask if it is valid and what user role it represents, and can react accordingly. For the XMLGW, you just do a normal login type exchange with it and it does the logon to CQC in response to that. But it maintains the credentials on its side, acting as a proxy for your client.

It's been a long time since anyone used the XML Gateway, so the documentation for it was never updated for the 5.x system. But it's still there and still should work. If not, I can get it back to working. The old PDF documentation file for the interface is still there so you could use that. Obviously XML can be a bit clunky as an interface language, but it's text mode so no issues with endianness and easily extensible and all that.
Dean Roddey
Software Geek Extraordinaire
Reply
#33
(03-04-2018, 05:42 PM)Dean Roddey Wrote: No, since the same system also has to work for IR. If you really want to do a client with two way control, there are two options:

1. The XML Gateway. This provides an 'XML over Sockets' interface to CQC. This is a regular socket connection, so it's all synchronous. You can run it in a background thread with queuing of commands/responses if you don't want to block the UI thread (or aren't allowed to.)
2. Using WebSockets talking to our Web Server. This requires a handler exist on our Web Sever for such a client. So you have to create both sides of the conversation in that case. That allows for the creation of a completely customized, no more than it has to be, type interface of course. Though, it also means that you are limited to the asynchronous, callback nature of Websockets, which can be annoying. And you may not have a WS client available to you, I dunno.


Both are real interfaces so they act as a proxy for you to let your user log into CQC. They maintain the credentials for you as long as the connection is maintained. Of course if you lose it, you can auto-reconnect since you know have the info that was provided by the user for login. Well, in the case of WS, you would use HTTPS/WSS to do the talking, and you would just pass a username/password over after the encrypted connection. Your handler there can ask if it is valid and what user role it represents, and can react accordingly. For the XMLGW, you just do a normal login type exchange with it and it does the logon to CQC in response to that. But it maintains the credentials on its side, acting as a proxy for your client.

It's been a long time since anyone used the XML Gateway, so the documentation for it was never updated for the 5.x system. But it's still there and still should work. If not, I can get it back to working. The old PDF documentation file for the interface is still there so you could use that. Obviously XML can be a bit clunky as an interface language, but it's text mode so no issues with endianness and easily extensible and all that.

I could do web sockets if there was a major requirement for responces rather than just "triggers" to CQC. I guess thats a question to four members.

If we initially go with just triggers, would setup screen like the one below work?

[img]blob:http://www.charmedquark.com/ebe1d69f-03f4-492f-a79f-ba850f78d30d[/img]
Reply
#34
That image link didn't quite work. You can upload images. You have to do New Reply to get to the full editor.
Dean Roddey
Software Geek Extraordinaire
Reply
#35
[attachment=2157 Wrote:Dean Roddey pid='150557' dateline='1520218862']That image link didn't quite work. You can upload images. You have to do New Reply to get to the full editor.


Attached Files
.png   Main_storyboard_—_Edited.png (Size: 82.79 KB / Downloads: 21)
Reply
#36
Yeh, something like that should do.
Dean Roddey
Software Geek Extraordinaire
Reply
#37
I use a url like this for taking actions when the camera system detects motions and does a get request on the CQC server.

<ip>:<port>/DrivewayCam?cmd=motiondetected&sched=3

This is using the HTTPGet driver which resides on a different port to the WebRIVA server. The driver learns the commands up to the parameters and then the parameters are used for actions specific to the camera trigger and the current mode.
Mykel Koblenz
Illawarra Smart Home
Reply
#38
He could use the HTTP one, or he could just use the one that sends basic text strings. There's not really any functional difference.
Dean Roddey
Software Geek Extraordinaire
Reply
#39
(03-05-2018, 08:28 AM)Dean Roddey Wrote: He could use the HTTP one, or he could just use the one that sends basic text strings. There's not really any functional difference.

Im close to submitting the updated app to Apple.

Ive added a today Widget, which has 8 customisable buttons (title, Icon, and send data). The TodayWidget  sends plain text command to the CQC.
Ive also added :
 the ability to sync the setting via iCloud
 A check for "URL" illegal characters in the address Url and password etc.


The video below show the app on an iPhone

https://youtu.be/0ZcSrpw3nPM

The video below show entering settings for a button

https://youtu.be/pBrJPjK5qsI


In the app I've included icons for music, tv, bulbs etc please see attached image, if there are more icons that you would like to see in the app please can you let me know before I submit the app to Apple.

.jpg   icons.jpg (Size: 99.16 KB / Downloads: 10)
Reply
#40
Ohhh - this is good.

Big deal for me, not so for others, but can you provide a way to change the home screen icon?

And perhaps a couple of additional icons, particularly for an appliance module (on/off) that is used on a fan or coffee pot or something?
do the needful ...
Hue | Sonos | Harmony | Elk M1G // Netatmo / Brultech
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)