06-24-2018, 12:21 PM
(This post was last modified: 06-24-2018, 12:23 PM by 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:
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.
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
- 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
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.
Dean Roddey
Explorans limites defectum
Explorans limites defectum