Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
iOS App for WebRIVA - CTC CQC
(02-15-2018, 10:01 AM)Dean Roddey Wrote: No matter what, you are going to go back to the main screen. There's no way we can flip to a new template and somehow know that the first one had these templates loaded into these overlays and that those templates correspond to these other over here in another scope templates and those overlays correspond to these other overlays on this new template. Or worse, that you had a popup up that was taking input from the user, and how to take that current input and get it into a another popup. That's not really practical that we could change templates and somehow recreate the same conditions.

If you want to stay on the same screen, you'd have to keep the same template and it would have to adjust its contents on the fly to a different aspect ratio. That would require a completely different approach to how screen layout works, i.e. something more like CSS. And be careful what you wish for, because then creating templates would be just as horrible as creating CSS based layouts.

If you want something like that, you'd have to use Websockets to create your own custom HTML based client.

What if for now I add an option to enable/disable orientation  eg.

eg in setting:

Orientation Enable : Yes/No

Default/Landscape user :
Default/Landscape password :

Portrait user :
Portrait password :

If Orientation is disabled :
1) It uses the Default/User
2) The code for detection of orientation change is disabled.

if Orientation is enabled :
1) It uses the user depending on orientation
2) The code for detection of orientation change is enabled.
It wont detract from the app. Its not a setting I see myself using though.

I say put it in - it may allow others to come up with some ideas and use cases.
Mykel Koblenz
Illawarra Smart Home
If people like it, then we could add a second default template to the user account later, and the URL could have a &orient=[p|l] option which would choose the portrait or landscape one. If landscape isn't set, you'd still get portrait.
Dean Roddey
Explorans limites defectum
V 1.4 now in app store

add ability to display a different screen for landscape or protrait.
removed screen bounce
grouped settings
Awesome work - thanks
Mykel Koblenz
Illawarra Smart Home
Any thoughts on an appletv app?
Nest|Harmony|Neeo|LG TV|Smarthings|
Is control from a TV really practical?

I have my android TV loading up CQC and its clunky to navigate - possible but not really something I would want to do. As a status though it works.
Mykel Koblenz
Illawarra Smart Home
Yeah, I was more thinking a notification/informational type view.
Nest|Harmony|Neeo|LG TV|Smarthings|
(02-21-2018, 03:36 PM)potts.mike Wrote: Yeah, I was more thinking a notification/informational type view.
Hi sorry for the delay it responding. I have been working on getting iOS to send a command string via a TCP socket. My initial testing has been with the Clipsal Wiser but I don't see any reason why the same principle would not work with the CQC as long as it can receive a string from a TCP socket.

I haven't had a chance to look at notifications due to having to write code for both the wiser and iOS to get TCP communication working. Then I look at Apple Watch and AppleTV

With the CQC have to got some sample of command strings it can receive?

For example on the Wiser I have set it up so that it can receive "Set Light,2,255,0" which will turn on lighting group 2, at level 255(on) instantly (0 seconds)

Ive put a couple of demos on youtube showing control of the clipsal wiser via the Today widget and via force touch widget

Demo 1

Demo 2
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:


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.
Dean Roddey
Explorans limites defectum

Forum Jump:

Users browsing this thread: 1 Guest(s)