Lets Discuss UpdateEntArea changes/additions

[jondecker76]

I think its time that we discuss some enhancements to UpdateEntArea (auto generated scenarios and event responses)

1) Its current implementation is very clean in regards to scenario generation, but messy when it comes to events. This is because scenario generation each section (lighting, media, climate, etc.) has 1 file dealing with the creation of scenarios. Responses to events, however, are all crammed into one file for all of the sections. I propose that we separate this out and put the relavent parts in the other separated files where the scenarios are generated. This way, everything regarding lighting (scenario creation, responses to events with its criteria etc.. for lighting will all be in UpdateEntArea_Lighting.cpp). It might not really be needed at this moment, but if we start adding a lot of logic to auto-generate other things, it will become very important when it comes to maintaining all of this logic.

2) It has been mentioned before - some users want to be able to turn off auto-generation. This would be *very* easy to implement, both in the source code, and in a web admin page to change the settings. I propose a step further.. Lets break auto-generation down into 3 categories:
a) Basic scenarios (scenarios that are crutial to LMCE functioning the way we know it, like Lights On/Off buttons appearing for a room when a lighting device is added)
b) Advanced Scenarios (eye-candy scenarios like Showtime, etc...)
c) Responses to events (the user wants a Showtime scenario, but doesn't want it executing when they start media)
This would not be hard to implement. A new table in the database with a few booleans, a check in each of the UpdateEntAreas_* files, and a web admin interface. Then the user will have ultimate control, allowing LMCE to create basic scenarios, advanced scenarios, and event responses, or any combination of them PER SECTION. For example, the web admin page might have:

Code: [Select]

Enable Autogenerated:
[ ] Basic Lighting Scenarios        [ ] Basic Climate Scenarios       [ ] Basic Media Scenarios
[ ] Advanced Lighting Scenarios     [ ] Advanced Climate Scenarios    [ ] Advanced Media Scenarios
[ ] Lighting Event Responses        [ ] Climate Event Responses       [ ] Media Event Responses
etc...
etc...
Of course, the default would be for all of them to be on. This would allow a tremendous amount of flexibility for all LMCE users

3) Lets start making a list of more auto-generated scenarios/event responses - I mean there is'nt a single auto-generated climate scenario! Other areas are lacking as well.


These are just some of my thoughts on this - I'd like to see the ball get rolling.

What do you guys think? What can you add/take away from this?

[jondecker76]

One more thought on this (which involves more work) would be to take the hard-code out of it completely, and store the criteria and the resulting commands in the database. Then anybody could make their own auto-generated scenario, or modify one that comes with LMCE from an admin page. Again, a lot more work up front, but incredibly flexible in the long run.

[freymann]

I'm with ya on this one. I think tschak noticed that it auto generates scenarios that already exist over again. Heck, even if we could get it to NOT recreate existing scenarios that would be helpful.

Yesterday when I playing around, I don't know how many times I had to go back into the On and Showtime lighting scenarios for the Living-Room and Basement and set them all to Leave Alone.

If it didn't regenerate existing, then I could flip them all to leave alone and it would stay that way. That would be simple enough for me.

But your thinking is great. Modular, room for adding on, easier to manage.

[tschak909]

I like the ideas so far... my concern is that there is quite a bit of code that needs to run to generate things like TV's...

Things like:

* Okay, do we have a TV?
  * Yes we do, which PVR are we using, MythTV, or VDR?
  * Okay, create the commands to start.

Moving this to a database will require significant development, and a lot of experimentation..not so much talk..but we need to do some research to see how far we can actually take it. The big mistake of any system (and yes, Pluto makes this mistake constantly), is it tries to be everything to everyone. We need to concentrate on the 80% cases.

But we also need to spend some time building out truth tables for things like building automatic events for lighting, climate, etc., finding out if these devices exist, and creating scenarios to use them efficiently, taking into account house modes.

For example, if house mode is sleeping, and you have motion sensors, you may want events to trigger when you walk to the bathroom, to light a path

or,

you may want to be conservative on lighting the fireplace....

we need to sit down, and seriously map these things out, and give this system the reputation it is grasping for, that of a smart home.

Because, in my opinion, if you're adding all these buttons, that you have to click to do the different things, and castrating events wholesale, you're missing half the point of using this system!

-Thom

[jondecker76]

I agree - doing this through a database would take a good deal of time while losing a lot of the power c++ is providing - just tossing around Ideas.

But I still think we need to strip out the UpdateEntArea_Events.cpp and redistribute the code to the other appropriate files to have cleaner code separation. If nothing else, this is a good place to start. (cleaning up what is already there)

I myself believe in a smart home solution, but I still  have to agree that nothing should happen automatically happen unless the user wants it to. For instance I love the automatic Showtime in my theatre room, but hate it in my bedroom. With that in mind, maybe options per area per room would be a better idea. This would, in my opinion, be a great feature.

I understand that we can't cater to everyone, and that a smart home needs to figure some things out on its own - but when a smart-home solution is "too smart", its not a good thing either (you lose the ability for something not to happen - reversing the normally good effect a smart-home solution has).

Can you explain your truth table concept a little bit more? I think i'm following you, but I want to make sure. I have some free time coming up and this is something I want to be involved in.

[tschak909]

well, basically, from an engineering perspective, we think of the house as one big finite state machine....

and we lay out a set of conditions (inputs), and then define an output (a desired action).

the conditions would be things like the presence of certain pieces of equipment, such as sensors, AV devices, etc.

and the outputs would either be an event or a scenario written that suits these.....

THEN

when we have those laid out, then we have a clearer picture of how we can selectively enable/disable these... it may very well be something as simple as a set of check-boxes..but given a set of predefined scenarios, I think that we can reduce this further, and maybe even put it into a series of wizard screens that can be tacked onto the setup wizard, or the web admin.

-Thom

[ddamron]

I agree. 

I think the key here is to define the INPUT states and OUTPUT states of the 'finite' machine.
we'd need to set up a table of "State Rules".

It's going to be a bit tricky with the INPUT states, there's a lot of them!
and just as many output states too..

Checkboxes, I disagree with, becuase they inherently mean ==, we should also be able to select criteria that is < or >, !=, etc.

Calculated INPUT states are also something that needs to be looked at.. ie
every 3rd day, if it has not rained, turn on sprinker Program 1

Calculated state would be every 3rd day, input state would be NOT rained, output state would be a cmd to sprinklers

make sense?

[tschak909]

yes, absolutely.

as soon as i pay the onconference bill, i want to schedule a meeting where we lay down the basics...maybe we'll get to the advanced stuff too..

-thom

[darrenmason]

Perhaps it makes sense to utilise an external rules engine?
We might even find that UIs etc have already been layered  over it and we just need to bind our inputs (conditions). What do you think?

[tschak909]

hmmm

maybe worth some investigation...

-Thom

[bulek]

Hi,

in my view there are few most important things when it comes to dealing with scenarios, events etc... either being autogenerated or manually added :

      1. Important is to have ability to execute another scenario from scenario - in this way you could make different levels of scenarios (as already suggested) - pretty elementary ones (like set lights on in room, ) could be autogenerated and available to user/integrator when making more complex scenarios (welcome home, going away, visit, meal, etc...) or presented in transparent way, so user can easily switch them on and off... In this way we could generate as many as possible elementary scenarios, so user just selects them, adds custom data and there he goes.

      2. Maybe better way would be to make dealing with scenarios a bit more easy - I know that we have pretty powerful scenario/event engine, but dealing with them through web-admin is bit unconvenient for user - a lot of clicking, a lot of knowledge needed, etc... It would be more convenient to present pretty large database of prepared scenarios that user could only select (we already have prepared some events like "detecting mobile phone" and we could probably just prepare also events for all mobile phones currently registered and scenario for if any of mobile enters, etc...)

      3. All autogenerated stuff should be transparent, easy to deal with and maybe switched off at the start (but users should be made aware of them, so they can decide to use them or not)....

Currently also one other equally important thing is missing - a proper configurable support for devices on floorplan. currently only few types of devices are supported, with hardcoded controls that appear on Orbiters and for my use, almost no one exactly matches my needs. Removing hardcodings there and make things easier for configuration (for instance you could select what control button will appear on Orbiter for each device etc) will make our floorplans much prettier and user friendlier. Also possibilities to enter arbitrary info on them is important (for instance you could put one sentence weather situation/forecast on Orbiter floorplan - remember by option of having any background we want, this doesn't only mean to be the floorplan of the house, but think of it more like a simple Scada)...

HTH,

regards,

Bulek.


 

[jondecker76]

Bulek - regarding #1 - you can already make a scenario execute another scenario, its just not apparent how to do it. Send an execute command to DCERouter with the PK of the scenario command group.

While these aren't exactly all auto-generated scenario related, you have some points. For a new user, or a user with little knowledge on the inner workings of LMCE, using the advanced event editor is confusing. It would almost be nice if we added a new field "Lookup" to the command parameters table. Then, for each command parameter put a string in the lookup field telling what infomation it is and where to find it (I.e. "pluto_main.CommandGroup.Description" ). Then in the web admin, instead of an ugly textbox wanting a primary key, we can  have a dropdown with descriptions populated from the CommandGroup table in that example. If we did this, then the advanced events UI would be usable by just about everybody.

Regarding floorplan stuff, i've spent a lot of time looking into it. For controls, some things need added to Lighting_Plugin and Climate_Plugin. For generic text, it isn't quite that easy because not all Icons have a text area set up in designer