EventGhost

KG, after moving to windows 10 I think this will be extremely useful for me. Will this negate the need to disable driver signing enforcement before using MCE blasters and receivers? There are some games that won't run on machines that have driver signing disabled because it is needed for anti-cheat programs. Thanks again for working on this.

this plugin and driver signing have nothing to do with each other.

I am trying how to get rid of the inconsistencies in the received IR codes. There is a +=10% rule on the IR transmissions. This is what makes it a royal pain in the backside. because each burst pair can be off as much as 10% of it's true value. The only way to be able to properly nail this thing down is a pronto code would have to be entered as a baseline and if a code is received that is +- 10% of that then that is the code. The other solution is to have the plugin "learn" the codes. not for conversion into a pronto code but to develop an average that can be used as a baseline. This would also give a user the opportunity to be able to name the buttons as well. instead of getting "Unknown.65F3A8DD27B1" which is just a hexadecimal representation of the RCL and the RCL is a series of + and - numbers that indicate how long to module for and how long to pause for.

This +- 10% is the reason why people keep on getting what appears to be a different code for the same button each time they press it. If you broke the hex down into decimal you would then see the codes are the same (within the +- 10% rule).

Other then that it looks pretty good so far. I do not have a blaster eye so I am not able to test the transmit.. But it does seem to be sound. I have also coded in an alternate way of receiving... The IR receivers have 2 types of receive. one is just a general receive which can be done at any time. the other is a priority receive. The priority receive is supposed to be used for learning a code. you have to enter and exit the priority receive. where as the receive you do not. I am willing to bet that when the receiver is in priority receive mode the receiver gets locked. nothing else can happen. no blasting basically. This is what the service used to do a general receive and also a learn.

Now I had read somewhere that when a receiver is in that "learn" mode the sensitivity for the receiver gets changed limiting it's effective range to about 10-12 feet. This could have also added to inconsistent codes being received. The other thing is the 100 byte buffer.. this would cause a 100ms lag in IR code reception. that 100ms needs to be something the user can adjust depending on the remote to obtain optimal performance. and the buffer size needs to be set to accommodate a 32 bit IR code and have it dynamically adjust if a 40bit code is received.



anywho. I did find the source of several issues and these will be corrected in the pure python version. I am really happy that the use of that service is going to go bye bye. that thing has been a thorn in my side and many others as well I am sure. But that is where I am at with this so far.

I just started using eventghost and i'ts pretty amazing what you can do with it! I use HP MCE receiver and it works fine most of the time, but sometimes key presses do get lost and "unknown" gets logged. If an update to this plugin will help, I'm really looking forward to it.

Thanks for the great software!

I will not be able to stop 100% of the events that occur like that... through my research i have learned that not all IR receivers are created the same..

This is what I have found out..

The CIR spec from Microsoft for a receiver is built around the MCE remote which uses either RC5 or RC6 protocol.. i can't remember off hand It may also use the NEC.. it doesn't matter which one it is..

so inside of the receiver is electronics that are made to be sensitive to the protocol the MCE remote uses.. some manufacturers have also made them sensitive to all or some of the additional protocols.. possibly none of the others.. This is where the issue with inconsistent IR codes comes into play..

because the receiver might not be built to filter a different protocol it may not provide consistent codes....

There are some modifications I have made which have increased the quality of the codes.. this comes at a cost.. these receivers will receive ANY IR.,. even stray IR in the air.. I have the ability to specify sample times.. or how long the receiver will wait until it returns the data it has collected. This is how that timeout works

say i tell it to take a 100 byte sample.. if the sample is filled up it gets returned immediately. However.. if the sample does not get filled up it will return when that timeout expires..

ok so for the SIRC 12 protocol. the transmission of this code takes 45 milliseconds.. it is a 12 bit protocol... I believe that means there needs to be 12 burst pairs. a burst pair is how long to transmit for and how long to not transmit for.

there are 4 pairs that are the preable the preamble consists of things like the frequency and what have you.
[one, two][one, two][one, two][one, two][on, off][on, off][on, off][on, off][on, off][on, off][on, off][on, off][on, off][on, off][on, off][on, off]

each pair consists of 2 unsigned long long integers on a 64 bit system... a long/unsigned long takes up 4 bytes of data space.. so a signed/unsigned long long is going to take up exactly 2 times the amount so 8 bytes per number.. that is 16 bytes of data per pair.

we have 4 pairs for the preamble and another 12 for the actual code.. that is 16 total pair.. each pair needing 16 bytes of data you end up with 256 bytes needed for a SIRC12 code.. Now a 12 bit code is a small code... most common is 32 bit and then you have Samsung using 40 bit.

a 32 bit code needs 1024 bytes and then another 64 for the preamble making it a total of 1088 bytes

so if you keep with the 45 milliseconds for a 12 bit code and break that down we can get a sort of rough estimate on how long a 32 bit will take to transmit.

45 / 12 = 3.75 ms per bit
3.75 * 32 = 120 ms total.

This is where it gets hairy... we have no clue what remote you are using.. so we also have no clue what size to make the packet or how long to wait for the packet to get filled.

If i set the thing to wait for 120 milliseconds and make the packet 1088 bytes.. the poor bastards with the sony remotes are going to have to wait 120 milliseconds for each button press.. well that's not really fair..

however I can make the packet say 256 bytes and set the speed to 45 milliseconds for each packet. i can daisy chain the packets together to form a 1088 bit code.. only a single issue here.. we have to be FAST!! once the receiver returns the first 256 bytes it no longer has a place to put any additional data until we hand it the next empty packet.. so any time used from when a packet gets returned until we give it an empty packet has got to be really small to not miss any data..

and then you toss in there the whole stray IR thing.. if there is a long wait to return you can get more stray IR in the code and you end up with reading you do not want to have..


The whole CIR design for Windows was designed to work with a single protocol. so they knew exactly how large the packets should be and also how long to wait. a device is also manufactured in the same manner..

because the IR protocols are different sizes and have different transmit speeds then toss in there the fact that we have no clue what protocol is being used into the mix you are going to incorrect codes happen.. there is nothing that can be done about this.. Now take those issues and then trow in the problem with the design of the receivers and you are talking complex to get things working right..


It is all a balance.. we have to find the right combination of packet size to wait time to get the best readings across all protocols. we have no control over the design of a receiver. so a user may have to try a different brand if they are encountering issues.

That was interesting, thanks for the information.

If I got that right you can't change what protocols the receiver reads, but perhaps the sample time should be user configurable so you could test what works best for your specific setup?

Right now my combination of HP IR receiver and Logitech Harmony works mostly fine, missed key presses are quite rare.

That is exactly what I am going to do. along with the user being able to adjust the size of the buffer as well.

The IR receivers are capable of receiving IR that is between a specific range. I would have to double check to see what that range is. But they have to have proper filtering in place for the protocol the MCE remote uses those are the requirements set forth by Microsoft. That being stated.. they can go above and beyond and filter more protocols. They can also use better grade components which would produce a cleaner result..

But I have done some work on this today.. and this is what I have discovered thus far. The decoding for SIRC12, SIRC15 and SIRC20 was entirely wrong. and would produce codes that would be all over the board because of small fluctuations. the SIRC protocol specifically states that an on state of .6ms is considered "off" and a burst of 1.2ms is considered on and they have a 0.6 ms wait between each burst. there is a 2.4ms preamble. The codes that Microsoft spits out are like this.


[2450, 550, 600, 600, 650, 550, 650, 550, 650, 550, 650, 550, 650, 550, 600, 600, 1200, 550, 1250, 550, 650, 550, 1250, 550, 1200, 25900]


2450 - 2.4ms preamble. simple math there shows that the received value is off by .05ms but it is within the +-10%.. so we need to put an iron on that bad larry and make it the 2.4 it is supposed to be. then there is a wait. that wait is supposed to be 0.6ms (600) again this is off. but withion tolerances.. this too needs to be set to it's proper value..

so through the use of the protocol specification I am able to determine what is on and what is off. each on or off represents a single bit.. the first 7 bits is the actual button code. for SIRC12 and SIRC20 the next 5 bits is the device type. and for sony15 the next 8 bits are the device type. sony20 has an additional 8 bits that are an extension to the device type..

there should be no reason for getting codes that are all out of sorts... I have fixed those 3 protocols thus far. Sony also has a "standard" button mapping. So I have mapped all of the device types to their respected commands and the names of the commands.

So if you point a sony TV remote and press power the event is now going to be "SIRC12.TV.Power" if the remote is for an AVR and you press the power button the event will be "SIRC12.AVR.Power"

here is a list of the device types along with the code for that type that is gotten from the IR
I am going to allow the user the option of removing the device type from the event as well. so the events would be

SIRC12.Play
SIRC20.Pause

and so on and so forth.

Now from my readings the MCE remotes use one of the RC protocols or the NEC protocol I can't remember which one. It is actually a spinoff of that protocol.. This is one of the things I believe that is causing a lot of people some problems.. it isn't set up as a spinoff of it... it was written into it.. so I believe it is causing issues with the decoding of a non MCE remote that uses the same protocol.

Oh I did also want to mention.. the learned codes are going to be nice and clean. right now they are not cleaned up before sent to create the pronto code.. this is the main reason why there is issue with the learned codes. they are sent into the converter exactly how the receiver gave us the data.. as you can see in the example above the data is not "ideal" But it can be made ideal if sent through a decoding process and cleaned up to provide a clean code.

I also have the ability to clean up any codes that are gotten from elsewhere and pasted into EG. Microsoft seems to have increments of 50 for each of the pieces of returned data. It is not that hard to round them out and then send that code through the cleaning process to make sure that it is spot on with the specification.

I think I am going to be able to get everything working really well with a close to 0% error rate on receiving and sending IR.. It is going to take some time tho because I have to learn each and every single one of the IR protocols and make the changes needed..

I can tell you the receiving part of the process is pretty damned fast and the code runs smooth for that portion of it.

I have a remote that is hacked so I am able to test each and every single protocol.

Sounds really cool, your efforts looking in to this are appreciated!

This is where the problem lies tho.

half of the IR stuff is a plugin. the other half is built into EG.. and the pieces that are apart of EG is the decoding portion of the code.

I am going to have to try and get a hold of the guy that is managing the github account he has kind of disappeared. so I do not know what we are doing with it... I may end up making a new repository if i cannot get a hold of him.. It is rather frustrating actually. I have tried a few times already with no response. we may have to assume that he is not going to come back to the project.. sad to lose someone like that.. but life is first.. and if things need his tending to then that is what he should be doing. and I am sure he is.. can't get to upset about something like that I guess..


So as i was saying.. I have the sony ir codes sorted out.. I am going to move into the NEC and the RC protocols next as these are the most commonly used ones. I will package up this whole thing with the new decoders in place for this plugin. I will have to add the decoders into EG at a later point.

I wanted to give you folks an update on this.

I added decoding for these protocols
Samsung
NECx
Aiwa
Amcor (air conditioner)
Argo (air conditioner)
Carrier (air conditioner)
Coolix (air conditioner)
Daikin (air conditioner)
Denon
Dish
Electra (air conditioner)
Fijitsu
GiCable
GlobalCache
GoodWheather (air conditioner)
Gree (air conditioner)
Haier (air conditioner)
Hitachi
Inax
Kelvinator (air conditioner)
LG
Lutron
MNitsubishi
MWM
Neoclima (air conditioner)
Nikai
Panasonic
Poineer
Sanyo
Sherwood
Tcl
Teco
Toshiba
Trotec
Vestel
Whirlpool (air conditioner)
Whynter (air conditioner)

and did some more work on the existing protocols..

I keen on experiencing a random application crash. When I run it through the Visual Studio debugger it is telling me that something is getting all mucked up with the reference counts for the garbage collection. I am not sure what is causing this problem. I have not been able to sort it out.. At any rate.. I have decided since the portion of the Windows API I am dealing with was deprecated in Windows 10 that I would grab the bull by the balls so to speak and I am going to attach to the USB and parse out the raw data from what I have completed thus far this is going to be an easier interface to deal with then the Windows APi because i am only dealing with a single data type.. byte.. where the windows API does all kinds of data type conversions and makes a mess of things. I still have to sort out getting the data but I thought I would take a look see at the HID plugin and see what it does..

OK so I have been making headway on this.. I am writing the code that reads the raw USB data and figures out what it does/means...
I thought I would be a super nice guy and I mean a really nice guy.. this is for those folks using crapintosh and linux and do not have the ability to use one of these nice MCE ir receivers on their machine. I am also going to write in the code needed to set the device up as if it were plugged into a windows machine. and it will be usable. Now I know that EG is only made for Windows.. I would like for that to change eventually for starters.. This is also an education for me. so I am learning as much as I can about the USB protocol and specification by doing this. That knowledge is going to allow me to improve the device detection bits of the system plugin... I know that I already updated it once.. I hate the update I made.. it is slow because it uses WMI. If I go right to the beginning of the stack and deal with the data directly I will be able to spit out a device connection before windows even gets the chance to install drivers for it. This is a good thing! if you wanted to block the installation of a device you would be able to. where right now all you can do is uninstall it after it has been installed. Windows does allow you to set a global policy that will stop the installation but it is a "global" policy.. so it stops all USB devices from getting installed.. with EG you will be able to selectively stop them. Improving Windows through the use of EventGhost, I LOVE it!!!!

The other thing is that when you plug in an IR receiver windows installs several drivers.. This is because of Windows Media center and all of the handling needed for that. The only thing we are interested in is sending and receiving the IR codes and nothing more.. They have removed Media Center in windows 10. But they forgot to remove the eHome portions along with it. They have deprecated all of the CIR API in windows 10 so we can expect that ehome will be removed in a not to distant future. In order to protect EG's remote control functionality I felt it important to make it work without the need of the eHome drivers and also without the need of the CIR API in Windows. doing this is going to ensure that these receivers will work so long as USB still exists because there will be no need to have a driver for it.

OOOOH YEAH!!!!!

well my efforts to go the route I wanted to go turned out to be more complex then I wanted to have to drag a user through doing.. it required changing out the ehome drivers for different ones.. I said FORGET THAT!!!

so I went back to using the windows API,.... I discovered what was causing the application crash.. there is a bug in the ctypes module that was causing it.. this is not a documented bug. it is a "new find" the bug exists from python 2.7 to python 3.8 those are the versions I have checked..

But none the less I coded around the problem.. I now am able to get the raw ir timings correctly from the windows API... Now when i say correctly... I so far have 100% matched codes across multiple protocols..
I need to do some more work on the rc5 protocol because the MCE remotes seem to like to spit out the code twice for a single button press. 100% code matching with no "unknowns" being produced. I am truly excited for it working out like this.

I think that there are going to be quite a few happy people when this is finally fixed!.

no more service. no more needing to elevate privileges to install the plugin.

I am however going to break API as far as the events are concerned... because the original plugin was not designed to handle more then a single receiver the events that were generated did not have to indicate a receiver they were coming from. well now that we have the ability to support more then a single receiver we need to be able to identify the receivers....

you might be thinking why would I have more then 1 receiver...
say you have a TV in your living room, one in your bedroom and another in a spare bedroom. the TV's have the ability to be controlled over wifi. using a raspberry pi with a program called virtualhere installed onto it you can plug in a receiver into the raspberry pi and it will connect the receiver to a usb port on a PC. It is able to do this over the network (wifi) so Windows and EG alike have no cluse that the thing is not actually plugged directly into the PC.. so now you have the ability to control all TV's in your home from a single PC running a single copy of EG

when the original plugin was made this ability did not exist. so you would be limited to 15 feet because that is the maximum cable length for USB... having multiple receivers was not something useful if they could only be 15 feet apart. well through some creative folks and some wild ideas you end up with programs like virtualhere. that remove those limitations.. and we need to keep pace, better yet we need to lead the pack. EG will be the ONLY HA software that is going to be able to use technology like this. EG is also going to have the most accurate IR handling of any HA available.

any way you shake a stick at it. this plugin is going to be leaps and bounds better.

I have also built lookup tables for the common protocols. these lookup tables are going to allow EG top produce named events like you see when you use the MCE remotes.. except this is going to work for many of the other protocols as well. I want to reduce the number of 76FA38A6 kind of events from happening.


I was screwing around more with the RC5 protocol. It is in fact not sending a double code. it is a fine line between what the remote considers to be a single press and holding the button down. I mean really fine line. I am going to work in some code that will create a shrinking duration between incoming codes. this is going to produce a "ramping" kind of an effect.. this duration will be reset if a different button gets pressed or if a timeout expires.. It is going to filter out what I call a slow release of the button that can produce multiple events when they are really not intended. the user will be able to adjust the start time for the duration. setting it to 0 would turn the feature off.

OK so I just added decoding of the XBox 360 and XBox One remotes. I also have started working on normalizing pronto code output..

Each protocol defines specific pulse and space widths. These widths are very specific.. as an example for the NEX/NECx protocol it states the first pulse is 9000us and the second pulse is -4500us or -2250us(button held down). from there each burst pair (on off widths) is 560 us for the on. for off if the pair is supposed to be a logical 0 then the off is -560 if it is supposed to be a logical 1 then the off is -1690.

Ir protocols allow for a +- 10% deviation from the specification.. so we check if the data received if +- 10% of the above values.. if it is within then we change the received value to match exactly what the protocol specification states.

by doing the above for each supported protocol this is going to be the part that locks in the accuracy. any learned IR codes are also going to be run through this process providing the user with what would be considered a manufacturer supplied pronto code!

With the protocols that define a mechanism for buttons being held down or when buttons gets released I have found this is the cause of the "double presses" The current plugin does not account for the button being released and will produce a second event.. This I have solved. When blasting IR codes or if using a code on a remote that has been learned and there is a trailing repeat that is not supposed to be there, I have that covered as well. It will ignore a repeat if it is attached to a code. the repeat has to come in all by it's self to be considered a repeat. and when blasting this repeat is going to be chopped off.

the thing I am not understanding about the NEC and NECx repeat codes is there is a duration of 110 milliseconds from the start of the code until the start of the next repeat... on the NEC protocol to blast the whole code over again at most is going to take 85.5 milliseconds. and the NECx is not going to be much over 100 milliseconds.. I do not know what the purpose would be to using the repeat codes, so as far as blasting goes for those 2 protocols is it not necessary to build in a mechanism to to blast the repeat codes instead of the original because blasting the originals is faster...

The only case that might come up is if a device uses the repeat codes like this..
if a repeat code comes in it is going to loop a command to do for 110 milliseconds. if another repeat comes in it resets that timer so the loop will continue. if the timer expires or a different button gets pressed the loop will stop... That is the only way I could see a use for it. I have been trying to think of a way to make EG use this mechanism with the enduring events. A whole lot can happen in 110 milliseconds. so i cannot hold the original press open for that time waiting for a repeat command.. what happens if one does not come in? then the enduring event does not get stopped for 110 milliseconds. and that is no good. The same problem exists with other remote codes where there is a toggle bit for pressed and released..

I think I am going to have to come up with a mechanism that can be used to control an enduring event.. maybe have it automatically populate the Auto Repeat macro for the best timings for the protocol used in that event. Doing this would provide the user with a nice running auto repeat.

Sorry if I am babbling.. It is helping me to think things out and how I plan on handling them..

I wanted to mention that I did add in the ability to set the prefix of the event to either the device manufacturer, device model or the device description. Which ever is wanted to be used. you can also turn on or off having the protocol name used in the event as well as being able to turn on or off the device name added to the event. many protocols have pre defined devices and also pre defined commands. the pre defined commands will always be keyed to whatever device the code is using.. I am also going to make it so that the user has the ability to remap the commands to whatever is they want to use.

woweee. this is very cool to see. I have really tried to read your posts thoroughly but my programming knowledge ended with .NET VB 101

I super appreciate your efforts to revamp the plugin, and I look forward to testing the results!

Exciting stuff! Do you know if Virtualhere on RPI be run in conjunction with Libreelec-Kodi?