EventGhost

Sorry, I miscalculated...math was nevery my strong side. So that's 100 minutes, then. But I know about the one in the logger, I was thinking per plug-in basis. I would like to see everything from the other plugins, but only the attached ones from the NHS/Tellstick.

I was thinking per plug-in basis

I'm not sure how to detect (from the plugin) how you have used the events in macros. Burt with everything, I guess there should be a method, it's most likely only me, I do not know how to

OK, no worries. Would it work to run some kind of script at startup and have all the events I don't want in there? If you understand what I mean. Sort of a blacklist.

No, that's not the way, to make it on a plugin level, you have to tell the plugin to stop generating events for those not assigned. In current EG this 'hiding' is done on a 'higher level'. To make it on plugin level, you would need to check the actual tree configuration from the plugin code somehow. How much coding effort that would imply is hard to say.

Do you mean that it's possible to create a blacklist of events without touching the plugins? That would work just as well, really. As long as the chosen events doesn't show in the logger window, that's all I need. The method isn't really important.

Do you mean that it's possible to create a blacklist of events without touching the plugins?

Yes, this is possible...but I am touching something that I would like to confirm with our EG master architect (Pako). I think the idea might be useful for others as well and then it would need better polish since it has in such case to be part of the EG distro.

I have however made an experimental version that is working here so if you are interested you may test it. But first, I would like to rename this feature to block list.

It works in the following way:

There is a python file named block_list.py. This file holds and provides basically a list with labels. As example it could look like this:
To modify the list, simply use a good text editor and add/remove the labels of your choice.

When an event is incoming, the event.string is checked and if any of the labels in the list is found, the event is not written to the log. So in this list you can add unique labels for events you would like to supress. The good part is that this is only valid for the log, you can still trigger macros with them, it means they do still exist (but you have to record them before you hide them).

The block_list.py file is in my version imported by the Log.py file so both needs to be placed in the folder ...Program Files (x86)\EventGhost\eg\Classes and thereafter restart of EG.

To avoid a complete mess up in other users system, I will send you the files via PM. You have to keep personal track of them because if you re-install EG, the Log.py will be overwritten

Bests regards,
Walter

Very interesting, thanks! Sounds like a nice, general feature to me, so maybe Pako will take the bait?

Yep, that works, and I don't see any problems from it so far! Thanks, Krambriw!

Good,

A possible extension would eventually be able to block not only on event.string but also on, or in addition, the event.payload. But I have not figured out a use case for this (yet). I do not see, for the moment, why events with a special payload should be blocked but others not.

Well, I can think of a few: Many would only be interested in the temperature of te freezer if it goes above -12 degrees. Rest of the time it doesn't matter. Same goes for the fridge, and even if they have rooms where the heaters only are there to avoid freezing (usually below 5 degrees).

Oh, and maybe rain? If it has been 0 mm since the last time the rain meter sendt, there's no need to do an update to the database.

Not saying that you should implement it, I just could think of a few scenarios where somebody might like it.

No, I think you misunderstood. It will not prevent events, it will only hide presentation in the log window on the left side. All what you are mentioning is something that will have to be treated with macros/actions and if needed, applicable python scripts.

Aha, sorry. I see. Well, then I can't think of anything. Totally blank. This brain is bloody demised. This is an ex brain...

No worries, it is better to think twice so thanks for your input

Best regards

Suggestion: I had an instance now where it didn't connect on startup. Would it be possible to build in an action to restart NetHomeServer on that, and then the computer if it doesn't help? Or is it better that I do that with a script?

How do you mean?

Do you suggest to restart NetHomeServer itself or re-start the plugin??

Just to verify how things are working as per today:

If you are starting EG and the plugin fails to connect to NetHomeServer (that could run anywhere) you get an event? And once NetHomeServer is running again, the plugin connects automatically?

What you are saying now is that you want to somehow re-start NetHomeServer itself on that event? If so, it really depends where it runs.

- If you are running it in the same machine under windows, you may try some EG actions, like find window, send message etc
- If you run it under Linux, you can restart NetHomeServer with a command 'sudo /etc/init.d/nethome restart' but you need to figure out how to send this command from EG, maybe via a telnet session
- If you run NetHomeServer in a separate VM session, it might be possible to re-start the virtual machine from EG
- It is also, with support of additional software, possible to run NetHomeServer as a service under Windows and then you can execute a command line call to restart the service
- If everything runs in the same PC, as last resort, EG can reboot the whole thing

Best R