Hi new to this group. I am installing HG on a Windows 10 desktop using a CM19 for communication to my old X10 devices. If I install, then enable X10 Interface for the CM19, the log immediately starts showing these errors. If I disable, the messages stop. I have been able to control an X10 light with HG, even though these messages continue to repeat. Is this a bad driver issue? What is causing this? I hate to have superfluous message generating and filling the log.
Problem occurs on both versions 14 and 19.
Thanks for any help you might be able to offer.
LibUsbDotNet.Main.UsbException: Repeated calls to wait with a submit is not allowed.
at LibUsbDotNet.Internal.OverlappedTransferContext.Wait(Int32& transferredCount, Boolean cancel)
at CM19Lib.Driver.CM19.ReadData()
LibUsbDotNet.Main.UsbException: Repeated calls to wait with a submit is not allowed.
at LibUsbDotNet.Internal.OverlappedTransferContext.Wait(Int32& transferredCount, Boolean cancel)
at CM19Lib.Driver.CM19.ReadData()
Do you possibly have any other X10 drivers belonging to any other X10 software installed on your computer. If so you’ll have to remove them as they would conflict with the HG XTenLib drivers.
The HG X10 drivers have been tested and work both in Windows and Linux
I currently use a CM11 and only program it on the same windows 10 system when I want to make changes to the program I load down to it. The application I use for that is ActiveHomeVista, another shareware App. So I have drivers that would allow the CM11 to be connected, but they are not in constant use, only when I reprogram it.
I shouldn’t have to delete those drivers if they are not being accessed at the same time, should I?
Yes that’s correct. It doesn’t exist. I imagine it was a call to a legacy folder from previous testing. You could create a folder yourself and I imagine that error message will disappear or you could start creating X10 security modules if you have any.
Please, I did not mean to say you are mistaken. It’s a good idea and I will try it. I can re-install the old CM11 drivers after testing. I was just thinking that different drivers can co-exist, especially since one is for the CM11 and the other is for the CM19. I let HG install the CM19 driver. The CM11 driver I have had installed for years. Perhaps this is a conflict. Thank you for your response.
I can easily create the folder, but I have no security modules. I don’t use them. Not sure if I can create one through HG or I need to find one as a reference and load it into the directory to be found during startup. Either way, if it’s not critical, I can live with it for now. I just wanted to point it out to whoever was still working on the HG install .exe as that is looking for it. Thanks again.
I’m new to the HG and the CM19. I bought the CM19 because only CM15 and CM19 were listed in HG as recognized devices for RF. I heard people use it with CM11, but I do not understand yet how to get that working.
I use the CM11 as a standalone controller for my system for many years. ActiveHomeVista allowed me to continue using it on my Windows 10 computer. It is never connected to the computer to control anything, only for reprogramming schedules.
I am going to probably replace it with a PI setup in the near future. The end goal is to simply communicate with Alexa but maybe keep the CM11 running as a backup if it doesn’t interfere.
So I really only have the CM19 plugged into the computer now. It has been able to control a switch successfully using HG.
Anyway what I suggest you do is remove any X10 drivers on your computer and reboot it. That should allow the CM19 HG drivers to have exclusive access to your CM19.
FYI, I removed the known drivers I found for ActiveHomeVista, rebooted, started HG, plugged in the CM19 and it was recognized and can turn lights on/off. However, the messages in the log regarding the CM19.ReadData error “Repeated calls to wait with a submit is not allowed.” are still continuing.
Will keep searching for a solution…
Thank you for your reply. Yes, perhaps this is something that is only occurring on Windows. Since my eventual target is PI, I guess I’ll worry about it only if I end up seeing it there. I will review the github site you suggest and open an issue report. Thanks for checking your install on PI.
The ActiveHome vista is a thirdparty software that uses the x10 ActiveHome Pro SDK it installs drivers which work for the cm11, cm15, cm14 and cm19 those drivers conflict with HG drivers. That isn’t a HG issue but a windows driver thing.
Personally at this stage I’d park the notion of HG on Windows and move on to the likes of the Raspberry Pi or equivalent SBC.
I just noted from the GitHub you are using a CM19a, the US version and depending on age of your CM19a there was I believe a number of version changes in this model. Determining the Vendor ID number may be helpful.
Peter, you appear to have discovered the real problem is likely a bug inside the LibUsbDotNet library dealing with the CM19a. I might try to locate a CM19e just to test if this is a CM19a specific issue or more a Windows issue? I agree with Tuicemen that this is not an HG specific issue, however, since I simply did the basic HG install and the program says it can interface to a CM19 (E or A is not mentioned), it introduces an issue inadvertently that is confusing to a newbie like me.
In addition, the other error with the missing X10_security_modules.xml is something that should be turned off in the demos or include a modules.xml in the library so it is resolved properly. Again, as a newbie it is somewhat bewildering why this is broken when first looking at HG. I was able to simply disable the Security Alarm System program and the message of course went away…
Finally, I appreciate that this is an older program no longer mainstream as it once was. However it seems there is still interest in it so it would be great if these issues were resolved for a future release since it still continues to evolve occasionally. Thanks for both you and Tuicemen’s help in understanding this.
If you’re based in the US please note the CM19E is a 433 MHz transceiver.
The Vendor ID needs to be correctly reported by the CM19 to the HG x10 driver for it to function correctly.
As I mentioned previously both the CM19a and the CM19E were both tested and found to function correctly in Linux.
It was brought to my attention that there was an earlier version of the CM19a that wasn’t correctly identified by the HG x10 driver so if you can extract the Vendor ID from your CM19a you should be able to determine if it will function correctly in HG.
Again there are few still using X10 in HG and even fewer using X10 with HG on the Windows platform so I doubt you’ll see much in the way of resolving this issue. I really do suggest going the Raspberry Pi route with your CM19 as it’s proven to work.