The O-MEGA Project

[Sem;colon]

Hi Steve,
I'm very happy you like it!

As for the tutorial; I kinda hoped you could ask some more specific question

First, you need to add (all) your HA actions to O-MEGA. There are multiple ways to do this:

The more complex but more powerful way is via an extension and a template.
Actually, this is the best and easiest way, if there is a template or extension available for your application! But if not, this requires you to create one first.
I created an tutorial for creating a template already, but it requires some basic programming knowledge (you need some HTML and JavaScript)
An extension is the logic behind your template or interface, extensions consist of macros within Eventghost.

The other way is directly via the O-MEGA webinterface (you would create a page, select a general template (you leave the target blank) and add buttons for your actions or macros that are actually configured in EventGhost.

The 2nd way is, I guess, more easy to start with. It is limited to standard elements though (buttons).
A "button" sounds rather simple, but it has very powerful features and configuration possibilities!
Every button can have one state and one value that is saved and displayed on the webinterface. These states and values are directly extracted from one or multiple Eventghost events you assign to the button. You can assign interactive popups to buttons to get other elements like sliders, color pickers etc.
But you wouldn't stop there, a button is much more than just a control element!
For example creating a scene in O-MEGA would actually execute a sequence of button presses in the disired state. As the state is visible in the O-MEGA system, you can also use these states for conditions within the scene to make it more dynamic (putting the smart in smart home )

[steve@rpad]

The more specific questions will come. Let's get you started on talking about the big picture and then slowly work our way down to the nitty gritty.

[Sem;colon]

Well, I just told you the big picture
But I'm a technician, I'm not got in pig pictures

There are so many different features that work independently from each other, I honestly don't know where to start..

[steve@rpad]

no worries, I was learning python and regular expressions in order to work EG with a couple other command line programs. I will switch to html and js and go from there. I'm a c++, fortran programmer from 30 years ago. I'm retired now and made my living as a project manager for construction/technical builds. I never made a living from programming except during Y2K.

I read enough html to get webserver going, I will start to read and get back to you. Essentially vlc and simple action buttons for power on/off are the first issues to attack(extensions/templates). I am looking for google material design as my final landing pad in regards to look and feel. So I will add css as well. You mentioned wanting to market this but I'm guessing you're a little burnt out from the 5 years you been putting this together. I'm hoping my curiosity will reignite your interest. First step is always information and that means big picture. Over time before you know it, there's an instructional post that fires up the next person. Just like the shampoo ad, "And so on, and so......" I get it if your over it all but give it a little time with me and before ya know it, i'll be able to answer my own questions.

I'm gonna start with extensions and go from there. Talk in a week with some point form questions.

[Sem;colon]

Hi Steve,

Thank you for the kind words!
I'd also like more people to use it, but also don't want to scare them away (including you) with too many options and complexity

Anyways, looks like you're really interested in getting involved with the tool - and that's greatly appreciated!

I'd suggest you first check out my tutorial how to create a template (if you didn't do that already)

Now about the extensions: You'd start off similar as for the templates, just then you edit "extensionsCfg" and you don't create a folder on the file system, but a folder in your EG tree under the folder O-MEGA_Extensions that needs to have the same name as the ID(!) of the extension you create in the webinterface.
Now, there are 3 different types of extensions that offer different features: device, interface and program.
Device: Is for everything that is NOT software on a windows PC running eventghost but can be controlled directly, you are able to turn them on and off somehow. For example PCs, TVs, AV receivers.. devices can have templates and dependencies to other devices.
Interfaces: Are gateways that control many small things, they usually can't be turned on or off directly. For example a z-wave gateway that controls light bulbs. Interfaces can NOT have templates, instead you can preconfigure buttons in the extensionCfg menu for each thing the interface can control. Interfaces can have dependencies to devices.
Programs: Software that runs on a PC with Eventghost installed. Programs can have templates and they can have dependencies on devices (well, usually the PC they are executed on).
Another important thing to define in your extension which EG plugin(s) it requires and parameters. Extensions are dynamic, just like templates, a user use them multiple times. so when someone adds, for example, a device to the configuration that has your extension as type, the user must be able to configure parameters to identify the instance of that device (for example an IP address).
You also need to define events (except for interfaces) that determine if your device or program is on or off, and these events need to be dynamic as well of course (!) You can utilize the user configured parameters for the event matching to archive this.

On Eventghost side you will get events triggered for your extensions to which you need to create macros to actually interface the devices or applications you want to control. The O-MEGA plugin brings a lot of useful actions you can add to your tree and utilize for this.

So, in your example of vlc, you would create an extension with the name "vlc" of the type program, add a parameter to where the .exe file is located and add events that are triggered when you open or close vlc. (I'm not sure if the EG plugin for vlc creates events when you open and close it, perhaps you need to use the process watcher plugin to get these events)
Then you need to add a program to your configuration (let's name it "vlc on server") of the type "vlc" assign it to your server PC device and configure the path to the .exe.
Then you would create and configure your vlc template, like in the tutorial, but select your extension as target.
Finally you would create a page that targets "vlc on server" and then you can select your template there as template.

Sounds a little long winding? Well, it is.. But once someone created a template/extension it can be exported, shared and imported and then it's pretty easy to use them - just like with plugins

[steve@rpad]

Thanks Sem; The tutorial and the above msgs will get me started. I'm re-populating my EG Tree with various plugins I was using previously, (Time filler for sure!) I'm gonna delete TerRemote(see all the confidence I have in you!). I'm gonna put all my eggs into the O-MEGA basket and then get started on a VLC ext. Thanks sir!

When you get a chance can you just quickly give us a quick how-to on persistent variable use with O-MEGA? I noticed your config form from EG Tree for O-MEGA has the persistent variable buttons removed and your start up messages in EG log denote persistent variable inclusion within your plugin so...

I have 5.1 Amp, Sub Amplifiers x 2, Humidifier, Air Cleaner that only are on/off or one way communication would like to keep track and be able to add those variables in as well, since I'm going ALL IN!

[Sem;colon]

Hi Steve, awesome!

For the persistent variables: The message about persist variables you're getting is just a startup message of the webserver plugin O-MEGA loads in the background, but they are not used.
Instead O-MEGA stores all information persistently in it's configuration files!
As I wrote earlier, each button has a state and a value that are extracted from events - those are of course persistently stored (!)
In addition, each device, interface or program has it's own little persistent "namespace" that is accessable via the web-frontend and EG-backend (the get and set methods for this are available as actions of the O-MEGA plugin in EventGhost)

If you have devices that are really just on/off, you definately don't need a template and extension for that, a normal button on a page will be perfectly sufficient and is fairly easy to setup. I have lots of these in my config

Your Amp isn't from Pioneer by chance? Cos I have a template and extension for that

[Sem;colon]

Hey everyone!

New Version: 0.3.71
- Fixed bug in the installer: Didn't work when there is a white space in the path
- Eventlog is now twice as long and can be filtered
- Two new settings for users: Admin and scene editor (when you update, a new administrator user will be created automatically with the admin right. You can delete it and give another of your users admin rights. There has to be one admin on your config)
- Scenes that are not hidden can now be viewed by every user
- Scenes can now be assigned to views
- Scenes can now be locked, meaning that only administrators can edit it
- New device depending setting to automatically return to dashboard after some seconds inactivity (nice for wall panels)
- New plugin setting to purge old backups after X days
- New plugin setting to delay the execution of scenes at server start
- New feature for the Dashboard to perform additional actions when sliding over tiles that represent button actions on touch devices
- Some code cleanup and optimization
- Minor bug fixes
- The position of the view selector had changed and is now more centered. This can save one click on a smartphone, as you can now see it without scrolling

Get it from the first post!

[Sem;colon]

Hey everyone!

New Version: 0.3.73

Just a small update this time; just some bug fixing and the installer is not using the Eventghost plugin import anymore, but copies the plugin files directly (no popup anymore during the installation)

Get it from the first post!

[kgschlosser]

@Sem;colon

what do we need to do in order to make the process of installing complex plugins like the Omega plugin easier to do??..

It's apparent that we should probably add some kind of an options dialog that can run when the installer runs. We also have a need to get pip and setup tools working in EG so plugins can get modules installed if needs be. maybe a registry handler as well. I am also thinking about adding a temporary directory handler also. this way eg can handle the cleanup when it closes.

We should be able to facilitate the installation of your plugin from inside of EG. if we need to write a framework for doing that and add it to EG I am game for doing it. I never have really liked the current design of the plugin installations because of it being pretty limited in nature and doesn't allow for installing anything else that may be needed in order for a plugin to be able to operate.

I also wanted to make a suggestion. I know that you are using the webserver plugin as the core of your plugin. Have you ever tried using Flask? I think you may find this to be a better option then using the webserver plugin. I started working on a framework that uses Flask and will dynamically write the HTML, javascript and css data that is needed and it will pass that data back to the requesting user using Flask.

I will send you over what I have written up so far with that framework along with an example so you can see how it works. My design idea on it is to add some javascript code to each page that gets served that will run any time an event takes place on the webpage. that code will run an HTTP POST command and inform the framework that a user clocked on a button. or resized the page or whatever other actions. If something needs to be done based on that event then the data back be passed as a response to the POST and the javascript code can update the page accordingly. I think this idea is a more graceful design then how the current webserver plugin is set up to operate.

If it sounds like something you would be interested in send me a PM and I will discuss it with you further and give you more detail on what I am envisioning the framework to work like.

[Sem;colon]

Hey Kevin!

The main reason why I changed to copy the plugin files directly is, that the plugin installation within Eventghost seems to be not working so well..
I recently tried to update my plugin on a different PC.
EventGhost was running and the plugin installation popup came up and I confirmed it with Ok.
Restarted Eventghost and.. still had the same old version of the plugin. So, I executed the .egplugin file again (this time Eventghost was closed) I confirmed the pop-up and started EG. Then I opened it and boom! Plugin not found. And indeed, the plugin files were gone.
So, the same thing one more time, now the plugin was finally there in the right version.

Actually wanted to create an issue on GitHub about it but got sidetracked

Anyways, to make the plugin install for flexible and create like an installer framework within EG maybe a little too much, as the ability it provides right now is totally sufficient in 99% of the cases.
Instead, it would be nice to have a possibility to run the installation of plugins in a silent mode (command line switch) to utilize it from within another 3rd party installer framework

[kgschlosser]

it would be nice to have a possibility to run the installation of plugins in a silent mode (command line switch) to utilize it from within another 3rd party installer framework

You can do this!

Code: Select all

eventghost my_plugin_filename.egplugin

it is not going to be in a silent mode and a dialog is going to appear.. I do not know if that is OK or would it have to be so no dialog opens up.

[kgschlosser]

I have been working on keeping plugins into their self contained egplugin file these would get extracted only if they are added to the tree at the time EG starts This would allow multiple versions of a plugin to be installed instead of having to deal with deleting a version when upgrading.

[Sem;colon]

Hi Kevin,

it is not going to be in a silent mode and a dialog is going to appear.. I do not know if that is OK or would it have to be so no dialog opens up.

I know about this, that's what I did and - no, the pop-up is disturbing users a lot, especially when they should return to the 3rd party installer after the plugin has been imported (Read the first posts of this thread for reference) Also they kinda break the installation when clicking "cancel" on the pop-up.

I have been working on keeping plugins into their self contained egplugin file these would get extracted only if they are added to the tree at the time EG starts This would allow multiple versions of a plugin to be installed instead of having to deal with deleting a version when upgrading.

Besides maybe troubleshooting, I can't think of any scenario right now where having multiple versions of the same plugin would make sense.. for the sake of simplicity, I'd prefer having only one version at a time and get it properly updated (replaced) when importing a plugin.

[Sem;colon]

About Flask..
It's cool! If I would start now with the project from scratch, I would probably build it on flask and make life much easier . However, 10 years ago when I started the project, I didn't know about Flask or Django etc. Now I can't just change to flask, as it would mean a complete rewrite and I totally not want to do that :/

I'm sure something like a flask plugin would be a cool thing and appropriated by anyone that wants to write a web UI for EventGhost