+- 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 - Dean Roddey - 04-05-2018
I'm roughing in the thermostat support now. This has raised an issue that I'm not sure which way I want to go with. For some command classes, we can provide more generic support by querying information from it, and using that to create the associated field. In the case of thermostats, we can query the supported fan modes and thermostat modes. We could hard code those in the device info file, but we'd need to have a specific device info file for each one. We couldn't have a generic thermostat handler.
But that raises a bunch of issues. We have to have all of this info before we register fields. We don't want to continue to register fields in a piecemeal fashion as more stuff comes in, since it causes clients to have to re-lookup their fields and IVs to get blinky as they redraw all field related widgets.
But it's hard to know when all of this information has been gathered, and how long do we hold off stuff that we have all the info for in order to wait for ones that we haven't managed to get the info for yet? We'd have to have another unit state presumably which introduces a lot of extra complexity.
So, I guess I just talked myself into no generic thermostat handler. The device info file can define the available modes. That also makes things faster since there's a lot less querying of info to get the driver started. It will already know that information once the thermostat type has been id'd.
The only gotcha there of course is if the device has any sort of configurable options that would make it change the modes it presents. In that case it would just present the available modes that the device info file defines and some of them may just get ignored, or maybe some wouldn't be available to set.
RE: Official 5.3 Beta Discussion Thread - kjaerligkatt - 04-05-2018
(04-03-2018, 09:30 AM)Dean Roddey Wrote: The GetClasses ones will be the battery powered ones. They can't go any further than getting basic node info until they wake up. Actually they will all wake up on their own at some point, which they do periodically. So by the time you get home they should have all done that and be in WaitDevInfo state.
Dean - just wanted to confirm that you were totally correct. 
Unfortunately I wonÔÇÖt be able to do any more for the rest of this month, as IÔÇÖm out of the country on business for a couple of weeks and then when I arrive back, weÔÇÖre moving home - so the the system will be offline until I reinstall. The positive is that I plan to do a full Zwave reset, and rebuild from a clean start point.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 04-05-2018
I got the thermostat mode, fan mode, and thermostat state CCs done today. The other two (fan state and one for high/low set points) should go pretty quickly tomorrow, then I can set up the unit handler.
Does anyone actually have a Z-Wave thermostat that could be a test bed for this? I may have to order one.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 04-06-2018
I have to give these guys some love:
https://www.youtube.com/watch?v=kDXnPfA_5pY
Snarky Puppy. How did I not know of these folks until now? It's crazy good. It's a huge mixture of influences in a large ensemble band with really good musicianship.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 04-06-2018
Version 5.2.905 is posted. This has device info files for all but one of the units successfully reported so far. The Aeon Gen 6 multi-sensor isn't in there yet.
It also has a couple small fixes for the HAI Omni TCP2 driver.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 04-07-2018
I've just posted 5.2.906. This one implements the RIVACmd command on WebRIVA as was previously discussed. So the deal is:
1. There is an IntfViewer::RIVACmd command that lets you pass arbitrary commands to a RIVA client. It takes a command name and up to three parameters.
2. For WebRIVA clients the web server now intercepts these and sends them to the WebRIVA client.
3. There can be ones that we handle internally, though I've not implemented any yet. Or, you can handle your own.
4. For the latter there is now a CQCData\HTMLRoot\WebRIVAExt\WebRIVACmd.js. You just add your code to that to handle any of your own commands. The default file that gets installed if there isn't one already there is just an empty function that does nothing, so that the file is there no matter what. Just edit it to add your own commands. Those won't get overwritten next time because the file will already be there.
5. The command name can be anything, but any that start with /CQSL/RIVACmd/ are assumed to be internal commands. You can use anything else for the names of your own commands. However, in case you might want to incorporate some that someone else has created, it would probably be best to use some sort of path like /Bubbas/xxxx, just to avoid any potential clash.
6. Of course if you have multiple web servers and you want to support these commands on them all, you'd have to duplicate that WebRIVACmd.js file on each of them.
7. This is a completely asynchronous mechanism. I.e. when one of your IV actions invokes the RIVACmd action command, that info is shipped off to the web server and your action just continues onwards. You can't wait for something to happen before continuing.
Anyhoo, there it is. I'm sure folks can find good uses for this mechanism. Later I can add some built in handlers for some obvious stuff, but I wanted to get the mechanism in place first so that other folks can start to make use of it.
RE: Official 5.3 Beta Discussion Thread - batwater - 04-07-2018
Dean none of my battery units came back with any information filled in automatically. I have not upgraded to 906 yet.
Couple of feedback items on the zwave client interface :
1) it would be nice to keep the ID hex (or make it configurable) You're using the hex value for the default unit name)
2) A grid view to see the basic details, would make it much much easier to identify what's missing without having to drill into each individual device.
I emailed my trace log. I went through and woke up each device type and provided what SmartThings is reporting as the manufacture type to correlate with the device ID.
-Ben
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 04-07-2018
By any information, you mean no manufacturer ids? You may have to force them awake by taking the batteries out and putting them back in. They will wake up eventually, but the default wakeup period can be a long time for some of them.
RE: Official 5.3 Beta Discussion Thread - batwater - 04-07-2018
I didn't manually wake them properly so disregard. I just sent 2 more device files. The remaining I'll get to tomorrow.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 04-08-2018
I got the thermostat support almost done. It introduced some tedious issues, and that required a little bit of rework of the CC impl class strategy, which is always annoying. And for whatever reason Z-Wave will often use the same sort of complicated value representations that the multi-level sensor classes uses, but use it in other classes, so I had to break out some code so that it could be used in both ML sensors and those others, such as the thermostat set points.
I also worked out the basics for handling a slow poll where that is necessary. This driver, like the past one, isn't going to do polling in the usual sense. Things either report async or they are treated as one way. But there are some special cases where a slow poll may be required, and also for listening units we can do an active 'ping' type poll if we've not gotten any async report in a good length of time, just to make sure it's still alive, like in the 15 or 30 minute range.
It was a bit of work to get this support done such that it wouldn't require a bunch of proactive busy work on the part of all of the CC impl classes. I worked it out where it's pretty easily handled generically at the base CC impl class.