Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Official 5.2 Beta Discussion Thread
Dean, Way over my head with this conversation but figured I would try. Trend seems to be for Home automation controllers to move away from controlling device directly(low level). but instead use OAuth2 over the internet to some kind of http get?. Seems it offloads a lot of change risk to local drivers querying and controlling devices. (my amazon echo, google home and smartthings hub all do this )
Yes it makes us 100% reliant on the internet for home control but I remember when I had a dedicated T1 circuit into my house because the "Internet" was not reliable.

Any appetite for a shift away from CQC drivers controlling things directly but to leverage the recent standards being developed for remote access of devices?
Examples: https://graph.api.smartthings.com and https://api.honeywell.com/oauth2/authorize

I know it is a little mind shift but I would rather my CQC control my smartthings hub, Echo, Google home, or other devices like my Honeywell thermostats via the open api over the internet. Yes I will give up a few seconds response time and add some bandwidth traffic but the IOT is going that way.

Up side example: if there was a good driver for the smartthings api over the internet you would instantly increase the number and types of devices CQC could control.(as smartthings hub at $49 controls thousands of devices with all different protocols).

Let CQC be the brains and user interface and let smartthings hub,etc do the low level device control via internet Oauth2.

My 2c.
_______________
Denon 3808ci, 2112ci ,Sonos, NoVo Grand Concerto, Z-Wave(Lights,Locks), Hue, SmartThings,
iPads,Tivo,Hikvision,Elk-M1,TED5000,Somfy RTS blinds+ZRTSI, Amazon Echos+Dots, Polk XRT12,
Honeywell Wi-Fi 9000, Caleo Wi-Fi Thermostats, Rainmachine
OAUTH is just a standard for authentication, not control. So it could be allowed to, for example, let you use your Google ID to login to CQC. But nothing to do with controling devices.
Wuench
My Home Theater/Automation Website

[THREAD=5957]BlueGlass CQC Config[/THREAD]
[THREAD=10624]Wuench's CQC Drivers[/THREAD]
Yeh, you beat me to it. It is a standard'for authentication but the actual protocols involved are still all different, and in the case of cloud based ones, with the extra downside of more moving parts and network dependence. We currently use it for the Nest driver.

As to using some other hub to get access to devices, it could be done of course, but we'd never be a serious player doing things like that, and we'd be at the mercy of a 'competitor'.

For the most part this stuff isn't an issue. It's just that Z-Wave is just one of those cases that always seems to happen, where the worst option gets the most popular. But, once the new driver is done, we should be able to deal with whatever silliness comes out of that world moving forward, which is why I'm doing this despite the fact that we have a basically workable driver currently. I want to get something done that is survivable and where we aren't constantly having to say, no, sorry can't support that because it's just yet another possible way to skin a Z-Wave cat that we didn't foresee.

If Leviton had done just a slightly better job on the VRC0P we could stick with it. But, as with all things Z-Wave it falls frustratingly short.
Dean Roddey
Explorans limites defectum
(09-16-2017, 09:30 AM)Dean Roddey Wrote: But, once the new driver is done, we should be able to deal with whatever silliness comes out of that world moving forward, which is why I'm doing this despite the fact that we have a basically workable driver currently. I want to get something done that is survivable and where we aren't constantly having to say, no, sorry can't support that because it's just yet another possible way to skin a Z-Wave cat that we didn't foresee.

Dean, really appreciate your taking this on!!! I have multiple z-wave devices sitting in the wings waiting for CQC connectivity.

-Ben
I'm back to a compilable Z-Wave driver again after some major swizzling. I think that it's getting pretty well structured now. We'll see how it does.

I also did some doc updates today to get some missing stuff in place and some rearranging and whatnot.

I was playing with the WebRIVA thing where it loses connection while in the bgn tab. I didn't quite get it figured out. I'll bang on it more tomorrow.
Dean Roddey
Explorans limites defectum
Banged away all day and never got a workable version of the latest stuff. Got disgusted with it and decided to have another go and rearranging it, in the hopes of simplifying it more, but going back to a bit more busy work at each point where a message is sent. Trying to come up with something auto-magically to get rid of that busy work just wasn't working. It's too inconsistent and difficult to keep with what's where when. So I just tried to make it as easy as possible to do the busy work.

I'll pick it up again tomorrow. I'm starting to feel kind of mentally challenged here.
Dean Roddey
Explorans limites defectum
OK, finally a big breakthrough. I got rid of my somewhat ad hoc set of flags and such that tracked what was going on in the thread that manages the msg I/O, and realized that I could get it down to a very formalized state machine, without any loss of throughput because the limitations of the Z-Wave protocol wouldn't allow for more than that anyway.

That in turn vastly simplified the logic, and allowed me to get very detailed trace log info about how it was moving from this state to that state. That in turned showed me some things I was missing.

One of them was that some types of acks must be in turned acked. I wasn't doing that, so if I asked something to send me a receipt ack (which I do on things that don't send back a reply per se), it was sending me a receipt ack and I wasn't acking that so it was just retrying it and that would make me time out because it wasn't responding to me, etc... So that improved things a lot, and explained a number of issues I had before. And I also now see any unclaimed acks of any type, which tells me something upstream didn't appropriately set up the outgoing msg, so that I can take care of that.

And I'm now packing outgoing msgs with lots of info as I build them (without undue busy work in the creation) so that the I/O thread knows exactly what they are and how to respond. The burden gets moved to the sender, but ultimate he's the only one who can really make sense of the fairly ad hoc nature of the protocol and msg formats, which are quite inconsistent.

Anyhoo, the inclusion is going perfectly now, way better than before with no misfires in the trace, no msg retries from my side or the Z-Stick side, and all the security back and forth is completely smooth. Beyond that I start doing my module info gathering phase where I still need to get that working again in the new scheme, but that's just details. It's all updated I've just got some goobers in there to take care of. I'll get that going again easily enough.

So, eventually even I can figure something out. I've come at this thing probably ten different ways now, some based on looking at other implementations and figuring they must know what they are doing, but maybe they don't. Anyway, this scheme works by far the best for me.
Dean Roddey
Explorans limites defectum
Well, nothing went wrong today, so that's a good sign. I have all the previous functionality up and working correctly and it's all still solid. I didn't re-break it again. I had a few head-scratchers but figured them out. So I'm back to moving forward again. I've got my trace log stuff well worked out now and it provides a lot of information that will help with any issues in the field.
Dean Roddey
Explorans limites defectum
I'm well into a documentation update for a 5.2 release. I'm doing a fairly significant restructuring to make it easier for folks to find things and to help newbies ease into the subject. All the stuff that was in the /Big Picture section was moved to a /More Details section. The Big Picture section now contains actual, real big picture stuff. So it's basically a page per topic with a broad overview and lots of links to more in-depth information and videos as appropriate.

The initial overview page also now has some common questions that a new user would ask and provides various links to help sections that cover those topics. And I'm just adding lost more links in general.

It's fairly brain frying, but I've made some good progress. I'll continue making updates but the major structural changes will be in the next drop and maybe you guys can give me some feedback on it.
Dean Roddey
Explorans limites defectum
I'm slowly banging the docs into their new form. They will be much better, but it's really brain scrambling to try to get it all into a form that is both nicely all interlinked, but also with a good indicated flow of events so that folks don't get lost. I'm also starting to de-emphasize the old RIVA stuff which means updating the installer and getting new screen caps and making sure that documentation is up to date. The installation related videos will have to be updated as well I guess.

To get away from doc stuff for a while today, I created a new variation of the toolbar that lets you assign a global variable to it. That will be used to set the index of the marked button on the toolbar (the marked button uses the emphasis colors and can use a mark image as well.) So you create a variable like:

GlobalVars::CreateVar(GVar:MenuIndex, String, Enum: Audio, Video, Weather, Security)

You assign that to the toolbar. Just make sure that the enumerated limit values are in the same order as the buttons. Then you can, anywhere, just set the variable to one of the enumerated values and the toolbar will get the ordinal of the set value and use that to set the mark.

This is particularly useful when using a toolbar as a menu for selecting which overlay will be loaded, where you generally want to have the currently loaded overlay's toolbar button show the emphasis. That's easy when you select the overlay from the menu itself. But often that's not the case. If you do something in the current overlay content that causes another one to load, then currently there's no way to update the mark on the toolbar.

With this new scheme, each template that loads into the overlay can just update the global variable with it's value. Then no matter how the overlay contents gets loaded, the toolbar will update to reflect that.

I will have to update those 'final navigation' tutorial videos to reflect this.
Dean Roddey
Explorans limites defectum


Possibly Related Threads…
Thread Author Replies Views Last Post
  6.x Beta Release Discussions Thread gReatAutomation 26 3,809 05-09-2022, 08:25 PM
Last Post: Shaky
  Official 5.5 Beta Release Thread Dean Roddey 46 14,774 09-23-2021, 03:32 PM
Last Post: jokermac
  Official 6.x Beta Release Thread Dean Roddey 2 1,123 04-16-2021, 05:55 AM
Last Post: Dean Roddey
  5.5 Beta Discussions Thread Dean Roddey 291 75,467 04-05-2021, 04:10 PM
Last Post: Dean Roddey
  6.X Discussions Thread gReatAutomation 1 928 04-01-2021, 03:23 PM
Last Post: Dean Roddey
  Official 5.4 Beta Discussion Thread Dean Roddey 441 170,908 06-15-2019, 02:33 AM
Last Post: Bugman
  Official 5.4 Beta Release Thread Dean Roddey 55 30,859 06-07-2019, 07:02 PM
Last Post: Dean Roddey
  Official 5.3 Beta Discussion Thread Dean Roddey 815 376,856 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.3 Release Thread Dean Roddey 27 20,066 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.2 Beta Release Thread Dean Roddey 13 14,351 10-09-2017, 06:49 PM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)