Any recommendations for eg tree structures?

[V_J]

Hello,

Well, it looks like all the pieces are falling in place for me to start making my config. And I've started planning the egtree structure... Any recommendations on what to do and what not to do?

I'm thinking of the following folders:

• external hardware events that are passed on between devices
  • amplifier -> loxone (marantz plugin -> xap)
    • various macros that interpret an event and create an xap message
  • loxone -> amplifier (xap -> marantz plugin)
    • various macros that interpret xap packet and trigger a marantz plugin action
  • Squeezebox -> loxone (xap -> http input)
    • subtree for every room
      • various macros to send text strings to http inputs on the loxone (cannot easily do text over udp)
• software events
  • ... (mpc-c, madvr, ...)
• all actions possible with a plugin
  • marantz plugin
  • ...(here I will add also the Squeezeserver plugin and see if I can get control of my LG TV)

But in general, I'm thinking of structuring based on functionality: I'm currently working on that first aspect (communicating events between devices), so at this stage EventGhost does not add much interactivity but rather works as a protocol/media converter. Next step with the software events would require more of EventGhost speciality, so I have not yet thought of this structure well.

In my previous egtree, I used a lot of goto commands: as a response to an event, rather than putting an action, I put a goto to the appropriate action in the folder "all actions possible with a plugin". I thought that would be a better way of maintaining it if a plugin gets replaced (the goto to the macro can stay, at least showing which functionality is expected, while the entire tree of actions of the plugin can be deleted), but I'm not sure that is a good practise...

Any thoughts or roads not to follow?

[Sem;colon]

Hi Jörg,
I think it's really personal preference.
I used jump actions a lot in the past but not anymore, they are hard to follow and copy paste of them kinda messed up my EG tree.
I have folders that are device/program specific to give the whole thing some structure and I assign events directly to macros with the actions. Never had any problems since I do it like this. (When I'm changing a plugin I just open my .egtree file with notepad++ and use the replace function btw. )

[V_J]

Yes... of course it is a bit personal preference, but still it helps to learn from other people... My previous config was 512 kB, and had far too many unused items (which I kept because I thought they might come in handy at one point). Loading it now in Eventghost 0.5 shows that 3 of the 8 plugins are not loading, and the bad way in which I communicated with loxone makes almost all events throw errors. And it is far too messy to maintain. I use the tree to get snippets of code and such, but am dead set to learn from the mistakes.
I fully get what you are saying about the gotos. I even had a large number of conditional gotos (the usage was: depending on which program was active, I changed the interpretation of a command coming from Loxone; the same play button could that way control either Kodi or MPC), but that really messes things up.

[Sem;colon]

the usage was: depending on which program was active, I changed the interpretation of a command coming from Loxone; the same play button could that way control either Kodi or MPC

... Did I mention that the O-MEGA project can do that too? Even across multiple devices and PCs

[V_J]

Actually, that part worked quite well in native Eventghost, using the setting to activate a tree exclusively: if one program is active (using processwatcher), set the tree with macros for that program's reaction to events to exculsively active. And then some checking if the program closes or so to deactivate it, but that went quite ok.
I will be offline for a few days (but can work offline on the Loxone thing, which I left a bit for now).

[Sem;colon]

That's true, I used it like this in the past. The difference is that the O-MEGA does not need any activate/deactivate structure for it to work, keeping your tree small, as it creates a new application specific event from your original event.
But as far as I remember it came with the downside that holding down a button (long press) didn't work

[V_J]

Things are nicely shaping up... Before I had a connection for every status from the amplifier to EG, and from EG to the Loxone, and similarly in the reverse direction for every command to the amplifier.

Now, using the new (modified) marantz plugin, I can catch all events, and post a http command to loxone using a single wildcard entry (the http command is generated in a script from the payload data). In the Loxone I still need one http input for each, but at least I don't need that many actions in EventGhost; any command added to the plugin will also be passed through.

For sending commands from the Loxone to the amplifier, I'm also using http posts (I prefer them over udp broadcasts) to EventGhost. Here I may also cut down a bit based on payloads (e.g. for power, only consider this part as an event and then based on the payload select the action on/off) but I'm not sure it would not be better here to just connect the poweron event with the action. The tree wold be bigger though... So this will be a trade-off between a smaller tree, where the actions are python scripts that trigger other actions; or a bigger tree where the actions are directly put.

edit: had some weird idea, but upon trying it is pointless... so I removed it again

[AlexPhilip]

Everything to do with html is a tree.

As a regular frontend developer you probably won't use or care about much of the things mentioned in the article. You'll build on other people's work where these things are abstracted away.
But if you're someone who's writing a library for DOM manipulations these might be things you need to know. (I'm thinking about if you want to write your own virtual DOM implementation, or your own react-like lib, ...)

Usually "regular" frontend developers (myself included) don't take a comp-sci degree but a more practical degree more focused on just programming. (Way less focus on data structures and algorithms)
At least that's the case in my country (Belgium), not sure if there's a distinction in the US/other places.