Charmed Quark Systems, Ltd. - Support Forums and Community
Official 5.3 Beta Discussion Thread - Printable Version

+- Charmed Quark Systems, Ltd. - Support Forums and Community (
+-- Forum: General Discussion (
+--- Forum: Beta Discussions (
+--- Thread: Official 5.3 Beta Discussion Thread (/showthread.php?tid=10397)

RE: Official 5.3 Beta Discussion Thread - Ron Haley - 11-28-2017

Ok. Finally got through the whole threadSmile  

Question still seems to be out there on whether CQC is going to compete in the media serving front.  I have all my movies and audio on a Synology NAS, using Plex to serve it up.  This works fine from my Tivos, IOS devices etc.  Unfortunately CQC support isn't really up to par for Plex. Sonos is now integrated with Alexa, so I can vocally call up songs/albums and direct them to multiple Sonos Speakers.  However, the songs have to be on a paid service like Spotify or Amazon Music.  

Would love to be able to access local content.

RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 11-28-2017

What's the not up to part for Plex bit?

RE: Official 5.3 Beta Discussion Thread - Ron Haley - 11-28-2017

No music support. Can't access particular songs. Now I'm talking about doing this via voice commands from Alexa. CQC doesn't have the API that allows you to access music from Plex. In fact, last time I tried, doesn't have an API that allows you to access particular songs from within the FTB driver either.
You've done a terrific job with voice access, but there appears to be no way of getting to particular media objects to hand off to players.

RE: Official 5.3 Beta Discussion Thread - potts.mike - 11-28-2017

Have you looked into the skill developed by Plex?

RE: Official 5.3 Beta Discussion Thread - Ron Haley - 11-28-2017

I have, but can't get the audio to Sonos.  Even the new Sonos:One with Alexa integrated won't play from the Plex skill!

RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 11-28-2017

Well, the multi-column list box PO'd me one time too many today. I'm going to replace that thing. I was looking at something that had been an issue for a while, which is that the column titles don't draw a background for whatever reason related to my having to play all kinds of tricks to make it do the things we need. So I started trying to that to work and it was just yet still more silly layers of hacks. Without that it's hard to tell the column headers from the actual column data sometimes. And it has various redraw glitches and it has lots of issues with buffered painting that makes it flash when you resize things. It makes the UI look less than professional I think.

So I'm going to replace it once and for all. It might take me a couple of weeks which sucks, but the thing is at the core of so much of the UI now that getting a really good version of it will be a huge improvement in the product. And it will end up being used even more going forward since there are still various places where it could have been used but there just wasn't time to rework things to use it. And now instead of having to do a number of derivatives that handle special cases I can just have it support the stuff we need directly, which will simplify the code a lot.

RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 12-01-2017

I got step one done of replacing the horrendous built in multi-column list box (one of the variations of the very complex list view control.) I did the column header control as a start. I've got a nice one done that does all I need for now, though it has support in place for more later when the time comes. Even just that bit is so much nicer and easier to use. There could be other uses for a column header that supports resizing operations and such, so I don't want to build it into to the actual list control itself. So it's done as a separate control. The actual MC list box will be a combination of that header control and a multi-column list control.

The next step will be the actual multi-column list box control. That'll be a bit of a slog, so I'll bounce between it and other things until its done. It'll be so nice to get this new one in place.

Firstly though I'll go back to the Z-Wave driver and test out the replacement Z-Stick and see if I get any different results than before. I'm betting probably not, to the detriment of my mental health. But it's pretty unlikely the one I had just happened to be bad in just this specific way. But, we'll see.

RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 12-01-2017

I didn't get far enough to tell if anything is different or not. I had been doing so many hacks and such to try things that I really need to go back and make sure that I know what is going on. It seemed like maybe it was doing better. But hopefully I'll know more tomorrow.

RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 12-04-2017

Well, more days of work and I'm basically in the same place. I've done a lot of tweaking and it's very difficult to understand what is going on.

1. As mentioned before, this new lock has a light that comes on when it sees the beam and wakes up, so I know when it is awake.
2. It will wake up if I send it any non-secure commands
3. It will absolutely not wake up for any secure command
4. If it's already awake because of some non-secure commands I just sent, once a secure command is sent, it goes back off.
5. I can put a non-secure command right before a secure command to make sure it's definitely awake, and it still just ignores the secure command goes back off again.
6. I put it in a loop where it just continually retried a secure message every 5 seconds, but it never once worked.

So clearly the issue isn't with beaming. It's obviously waking up when spoken to non-securely. It's something to do with security, but I cannot for the life of me figure out what that is. Unfortunately the only secure devices I have are two locks, both of which act the same way so I have no real sanity check. The Vizia stick master controller is security enabled, but it is set up only to be an outgoing control mechanism. It doesn't respond to anything, secure or not. The only way to talk to it is to have the user start a replication operation really.


1. Clearly during replication I talk to the master in secure mode, using the key he provides. So that means my encryption stuff cannot be wrong. If it was it would be wrong during replication as well. MAYBE it's wrong in some way that the Vizia stick doesn't care about but two completely different make of locks do, but it's unlikely.
2. The master can still talk to the lock and open and close it, so clearly the lock does respond to secure messages.
3. I'm doing exactly the same thing when talking to the lock as when I'm talking to the master.
4. I've tried different msgs that have to be sent securely, just to make sure I'm not by some chance doing the first one I'd normally send wrong. All of them act the same.

So I have no explanation a to why it doesn't work. But it seems clear it must be security related in some way. It's almost like the lock doesn't consider me to be a secure member of the network for some reason.

RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 12-04-2017

I was just watching it when I run my little 'query info about this node' command (via the InvokeCmd field.) It lights up, then the query code asks for what secure command classes it supports, which has to be done securely. That fails and the light goes off. It then runs a bunch of commands that have to be done securely, that all also fail. Then, at the end, it runs some that may or may not have to be secure, and they are done non-secure in this case, because the above stuff failed to get any info that might have made it happen securely. It lights back up and does those commands correctly.

So it just absolutely doesn't respond to secure commands. It's not like something is confusing it and it just stops responding. It will respond, then not respond, then immediately respond again afterwards, all based on whether the messages are secure mode or not.

I also, just as a sanity check, removed the lock, add the Z-Stick and put the lock back, to make sure that the Z-Stick was already in place before adding the lock. Then I do a refresh replication to get the Z-Stick updated with info about the lock. That didn't make any difference either.