Some early thoughts on 5.4

[Dean Roddey]

Some 5.3 should be out soon. It's taken a while, but since everyone can get the betas when they want and they are solid I've not been rushing it. I wanted to take some time and really get a lot of little niggles worked out and make some very useful internal architectural improvements, such as the new publish/subscribe stuff that I've started using to quite good effect. And of course there's been that demonic new Z-Wave driver.

But, looking out to 5.4 in the meantime, I've been thinking about some things. There may be a big skunkworks undertaking that will be the one major scale new bit, though I'm not sure about that. Leaving that aside, it seems to me that one medium sized thing most mentioned in terms of making it more practical to create the system you want is basically a 'rules engine'. I'm not sure if that's the case, but it gets mentioned a lot.

Obviously it shouldn't do things that would overlap the things that triggered/scheduled events, timed field writes, or the logic server are designed for and make easy enough to do. In particular triggered events are driven by triggers, so they react very fast, are efficient, and will not even miss a very fast transition. The rules engine will have to poll, so a lot more overhead, more latency, and the possibility of missing a very fast transition. It seems to me it would be for things that act on fields in some extended way that isn't easy to do with events.


To be honest, I'm having trouble coming up a lot of candidate rules for an initial set. I'm leaving out anything that is straightforward to use one of the above mentioned tools to achieve (maybe with the addition of, say, some more logic server options.)

Things it wouldn't be used for, I think, are:

• Anything that combines the values of fields to create a new field. That's the existing logic server functionality, though maybe we add some new ones.
  
• Anything that says, when this happens, make that happen for this long and then stop it. That's a triggered event that just does a timed field write.
  
• Do this at these times. That's a scheduled event
  

Some that I can think of are:

• Ramp this value from x to y over this many seconds, with possibly linear, logarithmic, and inverse logarithmic options. Maybe later a PID option but probably not initially.
  
• Randomly turn on and off these fields to simulate occupancy
  
• Set this field to a set of alternating values, flipping every X seconds
  

Any of these could have an option for an expression that has to evaluate to true before the rule will run, so that you can have a way to suppress them or to only allow them to run under particular circumstances.

I'm guessing that this would be added to the logic server as a separate type of logic. So you'd have a faux fields tab and a rules tab. 

Anyhoo... Any other ideas for rules that would make your life easier? If we don't have more than that, it's not worth it I don't think, at least not now and something else should probably get priority. I've got other ideas but wanted to see if this one was a good candidate.

[bryanb]

Dean,

Thanks for asking. I don't see anything that I could use in the Rules Engine. What would be helpful to me are:

1. A source control tool for templates, macros and drivers. I have 120 templates, around 10 custom macros and 5-10 custom drivers in one of my customer's system. I have 30 customer locations and I know all 30 are on a different set of templates, macros, drivers and CQC versions. Some way to manage this kind of environment would be very helpful. I have remote access to most of these customer locations, so tools to keep these systems updated would be very helpful. At a very minimum, add a date/time stamp when a template is changed and provide a tool to print the template name and date/time stamp.

2. A network install capability would make updating systems easier. My home system has 3 clients in addition to the master server. All of my customer systems have 1 client. We need away to update the master server and let it update the clients.

3. I would like to see a rewrite of the interface viewer like you did with the admin tools in 5.0. The IV needs to have native support for Windows, IOS and android. Add an angle parameter to most widgets that draw an image or text.

Anyway, that's my 2 cents worth.

Bryan

[Dean Roddey]

#1 All templates and images and such have a serial number. It is incremented each time one is modified. That is used to know when a change has occurred and we need to download a new version of it. So that could be exposed I assume. But I don't think it would really provide what you want since they could diverge on different systems, so a later number may or may not mean a later version relative to another system. Obviously we could let you just configure your own major/minor versions on templates and images and macros, and allow you to get a report with that information in it. Then you could do whatever you want with that capability.

#2 is obviously often asked for. But it's a huge thing to take on. It's not just the initial doing of it. Proving that it still works on every new release would be a vast amount of overhead. We really would need a release test team to support something like that.

#3 would take approximately the remainder of the life of the universe, so that one isn't likely to happen any time soon. WebRIVA will remain the portable client for the foreseeable future.

[batwater]

My two requests: (that I can think of)

1. Command line installer (no GUI interaction!)
   
2. UPB Driver modernization - including compatibility for the multi IO module
   

[Dean Roddey]

A command line installer is a considerably smaller chunk to chew off than a distributed installer.

[batwater]

A silent installer would be awesome!!!

I can create a scripted "distributed" installer of sorts if I have the ability to manage the install via command line with command line switches for each of the parameters. (including the ability to force an extract of the install directory/files into a targeted directory on a specific machine via UNC name). Also would want a flag to turn on/off logging and send to a targeted directory.

I would be happy to develop said scripting and share!

-Ben

[Dean Roddey]

I wasn't thinking about a scripted one. But just one that will update the install based on the current settings. Allowing for you to provide arbitrary options gets into a lot more work to have a language to express that and to keep that up over time and parse it and validate that it's a coherent configuration. Currently the 'validation' is really in the UI itself to just not show you invalid options and whatnot.

So step one would likely just be 'update me based on current configuration'. That's probably the far and away most common scenario.

[batwater]

I understand what you are saying on taking the defaults but to make this as effective as possible by not having to extract the files for each machine I need the ability to tell the installer to just extract the files in the selected directory and exit. There does need to be some level of command line switches available. Extract and backup control for certain. See this thread...

About the current installation process: In the current GUI, every time I go to extract the files to a folder manually as a prep for the rest of my install process I have to un-check the option, go into the gui to select the target folder location that it already knows (at least it does remember), okay the selection and then do the extract.

BTW, I do want to have this whole thing scripted when it's all said and done, one command execute to update all machines with CQC installed.

[Dean Roddey]

Not saying I'm going to do any of this for the next release. But, speaking in terms of supposed implementation, I'm assuming that the extraction would need to be the same, since it's a self extractor to get the actual image out, and you probably want to see the version and notes and such. You'd just cancel the GUI installer when it comes up, or we provide a check box for 'just extract' that would stop and exit after the image is extracted. So you'd just do that to extract the installer image wherever you want it to be. Then there'd be a new executable in the image to run if you want to do a headless update, which you could do from a shared directory that each machine can see, and run it as many times as you want from that same extracted image.

[potts.mike]

I’ve moved all my automation to Hubitat bc of rule machine, there rule engine. If you’re going to create a rule engine it needs to be able replace the triggered and scheduled events system in the place now. That is simply to clumsy for novices to navigate maybe keep what’s there as an advanced mode but you need to surface a simpler interface for people.

https://hubitat.com/blogs/home-automation-tutorials