+- Charmed Quark Systems, Ltd. - Support Forums and Community (https://www.charmedquark.com/vb_forums)
+-- Forum: General Discussion (https://www.charmedquark.com/vb_forums/forumdisplay.php?fid=3)
+--- Forum: Beta Discussions (https://www.charmedquark.com/vb_forums/forumdisplay.php?fid=12)
+--- Thread: Official 5.3 Beta Discussion Thread (/showthread.php?tid=10397)
RE: Official 5.3 Beta Discussion Thread - jkmonroe - 11-12-2017
i dont know anything about this beyond whats on this website, but it sounds like Hue is changing their API. can you take a look at this and see what we might need to do? eta on release is december.
https://developers.meethue.com/entertainment-blog
RE: Official 5.3 Beta Discussion Thread - kfly - 11-12-2017
(11-12-2017, 05:11 PM)jkmonroe Wrote: i dont know anything about this beyond whats on this website, but it sounds like Hue is changing their API.  can you take a look at this and see what we might need to do?  eta on release is december.
https://developers.meethue.com/entertainment-blog
Looks like they want to get into "surround sound" for lights during gaming.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 11-12-2017
It sounds like the new API is purely for the media lighting stuff, and that the rest will stay the same. Seems like a lot of work for something that is of very marginal value to most folks, meaning even if they might use it it would at best a novelty. They could have put that work into creating a new API that makes the core functionality of their system vastly more useful.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 11-12-2017
Well, Microsoft has a tool now called Message Analyzer, which can (among other things) monitor USB port traffic. So I tried to see if I could see what the Vizia RF software is sending to the Vizia USB dongle. But that was an exercise in frustration. A split second of tracing generates tens of thousands of messages, almost all of which seem to be exactly the same in terms of the payload. I can split it out by USB device and one of them looks like it might possibly be the right one, in that it has a payload that looks remotely like it could be nonce data, but it's just five thousand entries of exactly the same thing.
It's hard to tell what's going on, and not worth continuing. So I guess I order another Z-Stick to get the last possible hardware failure bit sanity checked. I can't see what else to do.
Of course, as I was saying above, the Vizia software never fails to control the lock, but it's not talking through the Z-Stick, it's talking through its own dongle.
RE: Official 5.3 Beta Discussion Thread - jkmonroe - 11-12-2017
(11-12-2017, 07:01 PM)Dean Roddey Wrote: It sounds like the new API is purely for the media lighting stuff, and that the rest will stay the same. Seems like a lot of work for something that is of very marginal value to most folks, meaning even if they might use it it would at best a novelty. They could have put that work into creating a new API that makes the core functionality of their system vastly more useful.
I dont know if anyone cares to support this new feature via CQC, I was more curious if the rest of the stuff would stay the same. 
Came across this in the forum about the new API, so it looks like they will coexist.  Good news.  
"Both API's will co-exist. As the RESTful API is meant for home automation, with explicit retries for confirmed delivery.
The Entertainment API is meant for fast updates and won't have retries."
RE: Official 5.3 Beta Discussion Thread - batwater - 11-13-2017
Dean, I don't know if these white paper documents from Sigma help  but it does talk about the protocol for battery devices in the first.  Maybe it will give you an idea if nothing else...
Z-Wave FLiRS - Z Wave Sigma Designs
Presuming you have seen this one...
Introduction to the Z-Wave Security Ecosystem
Found these on a resources page
-Ben
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 11-13-2017
Yeh, I've read those. But they don't say anything about how the beaming process is actually done on the sending side, and AFAIK, there is nothing at all that needs to be done. The one thing that makes that clear that they do mention is that, if it goes through one or more intermediate nodes, only the last node does the beaming. That means that it can't be anything that I make the Z-Stick do, since it might not even need to be the stick that does it. It has to be something done by the hardware, based on its knowledge that the target requires the beam, as best I can tell. And all nodes can and do get this information about other nodes.
I know of at least one command I can send to get it to wake up, and that is
The security one, BTW, is on the new 2nd generation security scheme, which doesn't really exist in the wild yet. Everything currently uses the AES 128bit scheme.
RE: Official 5.3 Beta Discussion Thread - znelbok - 11-13-2017
(11-12-2017, 02:52 PM)Dean Roddey Wrote: You can already do that. All of the trigger driver instances on a given machine will share a global variables space. You do need to be a little careful if you have multiple instances of trigger drivers on the same machine that they don't step on each other's toes.
Maybe, ultimately, it would be better to just give each driver instance its own global variable space. But most folks probably never run more than one so as a practical matter it won't be an issue.
Anyhoo, in the meantime, just use global variables to store that sort of state.
You confused me with this reply.  Can it be done?  If so how?  Are you talking about GVar's?
I want the trigger driver to have its own fields so that the IV and other drivers can use them without the need for the VAR driver - keeps it all neat and tidy and contained.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 11-13-2017
Yeh, I meant GVars. I thought you just wanted internal storage to remember things across triggered actions so that the next action could read that info and react accordingly. Adding some fields to the driver wouldn't be hard, but allowing you to edit them would be a lot more work since it would require a client side interface and new remote APIs for managing the list and whatnot.
I'll put it on the list.
RE: Official 5.3 Beta Discussion Thread - znelbok - 11-14-2017
Dean
In the Static Web Image widget there is an update time which you set to 8000ms as the default. I usually set this to 1000.
Every time I re-open the interface for editing that value reverts back to 8000. The number I enter is not being retained at all.