Good practises for making an eventghost config

[V_J]

Hello,

I finally got round to working a bit on my Eventghost config, and will have a bit of time to finish it. Basically, I want it to combine the following:

• Kodi: xbmc2 addon
• MPC-HC: mpc-hc addon (it is my external player configured in Kodi)
• Squeezeboxes: xap plugin
• Marantz amplifier: modified Marantz RS232 addon
• Loxone home automation: http based communication

The whole point is that I use want to have everything controlled from the home automation, which means that I use Eventghost to send and receive http post requests. My question is on how to design it all in a way that is maintainable. So far, I had test configurations to make sure hat what I want can work; now I'm at the stage of making the final config.

Are these good practices?
1.
I started out with a tree that has sub-branches for all actions of each plugin. Every time I need an action, I do a jump with return to macros in these branches. I feel this may make it easier if something changes (e.g. amplifier gets replaced by something else, mpc-hc gets replaces, ...) as all actions are grouped there.

Code: Select all

|+ all actions
||- Marantz
||- xmbc2
|'- ...
|
 

2.
I made a tree that takes behaves the same as the tree in 1, but combines the jump to those macros with sending status updates to the home automation. This will be the tree I will jump to when I have events.

3.
I will a tree that takes events, and then performs appropriate jumps to macros in the tree in 2.

4.
To control kodi/mpc-hc, I have a sub-tree for each, with actions triggered by the same incoming http events. Using the process watch addon, I do an exclusive enable of the correct sub-branch: select if kodi is running but mpc hc is not, then it is kodi-branch; if kodi and mpc-hc are running, it is the mpc-hc branch. If neither is running, I don't really care at the moment ( but I may replace that with e.g. basic keyboard functionality - just realized that)

Code: Select all

|+ control
||- Kodi
||- mpc-hc
|'- ...
|
 

5.
The test mentioned in 4. is in its own sub-tree, where I put events and subsequent actions.

At this point, I have the tree mentioned in 1, I have the structure mentioned in 4 and am working on the trees 2 (not all actions will trigger sending a status update to the home automation, and I want to send as little as possible) and on 3.

Does this seem like a good structure? Am I missing things? Are the large number of jumps bad (e.g. should I merge tree 1 and 2) ?

Thanks!

J├Ârg

[kgschlosser]

me personally. what I have done is i created a folder called Startup and i reserved autostart for just plugins.. for things like setting global variables that i may use and but what i did was i created a small plugin that would fire off a true startup event. something that could trigger actions before the plugins load. this is simply due to the fact that after a plugin loads the plugin can trigger an event and that could start an action that depends on a global variable that is not set. so instead of having to add a bunch of disable/enables for the actions that depend on these variables i made a small utility that triggers an event as soon as eventghost loads the plugin file. because the Main.OnInit actually gets triggered after the plugins start. now i know i could have put that information into the autostart. but i think it just looks cleaner not to have the autostart loaded with things other than the plugins... personal preference i guess


but i also have a folder called devices... and under that folder i have a separate folder for each device. and then a separate macro for each action. and also a python script file containing the python version of the action being called.. I have the devices folder disable which disables everything below it.

this allows for simple copy and paste of a macro to another location in the tree if i need to add another event that can trigger that action. I do this because using the jumps doesn't give you a simple way of locating the folder it goes to other then the macro name. and that could be located who knows!??!? and the digging begins... LOL
and also you can name things the same so if you have more then one macro with the same name. same kind of a deal.

if there is another macro that depends on the data from the first i will simply do a trigger event and attach the information to be used in the next macro as a payload.

i like having one action for a device in a macro. this allows me to to keep the macros for a specific device grouped together in a folder that is set to the device name and model number and location in the home. and if triggering an event from another macro that depends on information from this one. i set the event as the name of the folder as this folder

so an example of the above would be this

(f) = folder
(m) = macro
(e) = event
(a) = action

Code: Select all

(f) Samsung TV
    (f)UN55D8000 - Bedroom 2
        (m) Power On
            (e) Remote.Bedroom2.PowerOn
            (a) Send PowerOn
            (a) TriggerEvent MicasaVerdeVera.Bedroom2.Ceiling.Dim - 10
(f)MicasaVerdeVera
    (f)Bedroom 2
        (m) Ceiling Dim
            (e) Lights.Bedroom2.Ceiling.Dim
            (a) Send Payload Data

this allows for very easily finding a specific macro and also accommodates for multiples of the same brand as well as the same model

after many many many times of re writing the whole tree... and a few more times after that . i have personally found this to be the best solution for my home... i have one central version of EG that controls everything. i do have an HTPC for each room. and i could have allowed that HTPC to control the devices for that room. but then i have multiple EG's i have to maintain. and configure.

i do have EG running on those HTPC's but they are all identical and only have 2 plugins installed. one plugin simply creates an OSD for the data i sent to it. and the data i send to it is actually the code to draw the screen. and the other is what receives the incoming data and there are 2 macros one that launches the OSD, and another that polls for a resolution change and if there is one sends the change back to the server all of the processing is done by the server and the specific information needed to complete the code for a specific display is dynamically inserted into the code. and then transmitted to the HTPC.

keeps everything in one place but also makes it really simple to put together things like a webpage will information from every device and every room without the need for collecting that data from each instance that is running.. and it also allowed me to be able to access a device from a different room through the menu system and show all of the states of that device,


so the really nested tree is what i found that makes it simple to locate things. and i will tell you if you start off that way and don't have to keep rewriting your tree. will save a lot of time.

[V_J]

but i also have a folder called devices... and under that folder i have a separate folder for each device. and then a separate macro for each action. and also a python script file containing the python version of the action being called.. I have the devices folder disable which disables everything below it.

Ok, I started with exactly the same! It contains all actions that my devices can do.

i like having one action for a device in a macro. this allows me to to keep the macros for a specific device grouped together in a folder that is set to the device name and model number and location in the home. and if triggering an event from another macro that depends on information from this one.

I did not realize there was a way to trigger an event. That is indeed much more elegant than a jump and return.

after many many many times of re writing the whole tree... and a few more times after that . i have personally found this to be the best solution for my home... i have one central version of EG that controls everything. i do have an HTPC for each room. and i could have allowed that HTPC to control the devices for that room. but then i have multiple EG's i have to maintain. and configure.

I am at that stage of rewriting and planning how to group everything to be maintainable: if some software changes (e.g. now I use Kodi with MPC-HC as external player, but that may change) or some hardware changes (e.g. receiver gets replaced) or something gets added, I would like to have a structured way of knowning what/where to add/change.

I mainly will have events from http calls made by the home automation interface (but I define those events). I initially thought of adding more intelligence there, but I know realized that I will keep all the intelligence related to interpreting commands that address software in EventGhost: it saves communicating back to the system what is currently running and makes the setup in the home automation system smaller and easier (it is not a very comfortable development environment).

Thanks for the advice! I am more and more seeing how to make it work together.

[kgschlosser]

i do not believe you can send off payload dta from using the TriggerEvent that is built into the EG actions. and i know you end up being stuck with the Main. prefix if you use it as well

but if you add an action Python Command and key in this little bit of code... then you will get all the goodies. there are a couple of versions on how to do thi.. if you want static payload data, or data that is returned by an action.. or data that is from another trigger event... but it's all pretty simple


the command is

Code: Select all

eg.TriggerEvent(prefix='SOMEPREFIX', suffix='SOME.SUFFIX', payload=YOUR_STATIC_DATA)

or if you want to add returned data from another action

Code: Select all

eg.TriggerEvent(prefix='SOMEPREFIX', suffix='SOME.SUFFIX', payload=eg.result)

the real trick to this is to come up with a naming convention for the folders/device/rooms that you can have as the actual event name. that way it makes it a breeze to track something down.

last time i checked i have over 2000 tree items. it was a nightmare to find something without the use of that naming convention..

but you can also double click on the item in the log as well to bring you to a specific action as well.


everything i have set up reports back so all the states are stored and can be brought up in an osd or a menu from anywhere in the home. so for instance if i meander into my media room. and i can't remember if i shut the tv off in my bedroom (up 2 stories) i can bring up the menu for my house. select that bedroom. and it will tell me if the TV is on or off. and i have the ability to shut it off from there

so having things report status changes can be a really good thing

[V_J]

Thanks for the insights!
A good naming convention is always necessary, so that is covered.

I think I know now how to do it. My config is not that complicated, but has a few quirks in it (e.g. the plugin I have for my receiver only works one way: I have to request my receiver for sending back settings - the receiver sends events but the plugin via serial port does not take it, and no time to work on that now). The use of mpc-hc as external player for Kodi also messes up some controls (even moreso when mpc-hc uses xysubfilter). But I will do the following:
- tree with subtrees for all actions of devices (as a resource)
- tree with events
-- subtree with macros that link events coming from the home automation (http events) to actions (e.g. change volume, trigger event volume changed)
-- subtree with macros that link events sent out by software (e.g. the xap plugin) to actions (usually to update something in the home automation)
-- subtree with marcos that link events needed for polling the receiver and updating the home automation (e.g. volume changed)

The subtrees in events will have a number of additional subtrees, where appropriate ones are enabled/disabled depending on what is currently active (e.g. cursor control will work for Kodi, mpc-hc or other).

I'll be going abroad for 2 years, so will not be able to work much on it, but I want it finished now just to have something that works. I feel I need 1-2 more days with EventGhost to finish it, and then a few more days with the home automation interfacing. Most likely after that I will rewrite the plugin for the receiver, to have bidirectional communication.

[m19brandon]

Did you change to the suffixes after the fact through a script or did you go back and manual reran?

(f) = folder
(m) = macro
(e) = event
(a) = action

My conf is a mess.

[kgschlosser]

what i did was run EG from a command line with the -multiload switch, this allows for 2 instances of EG to run at the same time. in the 2nd running copy of EG i created a new tree. and one at a time copied and pasted and then edited. making sure to save after every single move. and make sure you disable all of your plugins before doing this.

[kgschlosser]

I think i am going to work on changing the icon for a macro if there is a jump into it. and a right click menu to the source of the jump. I would prefer to use the jumps if there was some kind of a notification that a specific macro has a jump into it.

[m19brandon]

what i did was run EG from a command line with the -multiload switch, this allows for 2 instances of EG to run at the same time. in the 2nd running copy of EG i created a new tree. and one at a time copied and pasted and then edited. making sure to save after every single move. and make sure you disable all of your plugins before doing this.

I am going to have to live with my mess for now but that will be a weekend project in 2017. Thanks for sharing.

[kgschlosser]

@m19brandon
hey i have something cool i am just about finished with. it's a plugin that converts the Add Action Dialog into a pane. and it can always stay open. and is apart of the EG interface. would be perfect for something like remaking your tree. you would be able to click on a specific action to create in rapid succession. don't know why you would want to do something like that but you could.

I am just trying to get around a hangup when the thing goes to open the ConfigDialog for a new TreeItem. there is some kind of a goofy issue with stackless and the threads. i may just select the item and then send over an event like it is being activated. that would open the dialog up... kind of a hack but it should work.