Having the port disappear due to removing the dongle was not my case. The machine would see the dongle early in the day. I could watch the log as devices were polled/responding then later in the evening a light would fail to turn on on schedule or by event. The dongle had not been removed during that time. I would look at the logs and see no activity. I could not control lights. i would have to reboot the machine for the dongle to start working again. Whether the usb ports were going to sleep or something else was going on I could not determine. After playing with it for a while I decided to move to a different motherboard, Asus A8N32SLI. Something I had laying around and have not had that problem again. I never pursued the problem further. I presently am using the board as a mythtv server and have little to no trouble from it. Of course I am not using the usb ports either.

Having the port disappear due to removing the dongle was not my case. The machine would see the dongle early in the day. I could watch the log as devices were polled/responding then later in the evening a light would fail to turn on on schedule or by event. The dongle had not been removed during that time. I would look at the logs and see no activity. I could not control lights. i would have to reboot the machine for the dongle to start working again. Whether the usb ports were going to sleep or something else was going on I could not determine. After playing with it for a while I decided to move to a different motherboard, Asus A8N32SLI. Something I had laying around and have not had that problem again. I never pursued the problem further. I presently am using the board as a mythtv server and have little to no trouble from it. Of course I am not using the usb ports either.

The port does not disappear when removing a dongle - but you do need to re-insert it into the same port when PnP is disabled. What I was describing is not specific to the ASrock but a general problem.

It sounds more likely that your ZWave binary was dying after a few hours - it may have been that the usb chip used in the MCV was not happy with the usb ports on the ASrock. I know that MCV have had problems with their dongle when used in conjunction with their Vera product.

We have no such problems with ZWave or the ZWave interfaces we use and never have had either on any hardware let alone the ASrocks.

Is it possible that the serial port goes away temporarily when the Z-Wave chip is reset? I never encountered this when testing the soft-reset on Tricklestar hardware. Do you see any Plug-and-play events happening around the same time as the soft-reset took place?

Just curious, do you have any wireless devices in your house operating around 900 MHz? Maybe a cordless phone, wireless speakers, or a video monitor?

- There is no timed events running at that time of the day (which I'm aware of or can see in the setup)- No one at home used the zwave from the hybrid or md.- The only thing that might have happened is that someone physically turned on or off one of the lights at home locally (Not through any remotes or computers)

i'd suspect that we should not try to acquire the mutex a 2nd time in dropSendQueueJob()...

When I added dropSendQueueJob(), I changed the mutex so that it is recursive. dropSendQueueJob() should be able to acquire the mutex a second time from the same thread, as should zwSoftReset().

seen that but it looks like it hangs there..

I'm not understanding. Are you saying the mutex is getting corrupted?

I see in the log it prints out "ERROR: Three dropped commands in a row, soft-resetting controller". In dropSendQueueJob() this happens after the mutex is unlocked. Then there is the "Soft-resetting the Z-Wave chip" from zwSoftReset(). Then I see the "Sending job..." which occurs from WriteSerialStringEx() back in the main receiveFunction() loop.

I was thinking the mutex was okay, otherwise the receiveFunction() wouldn't be able to acquire it again before calling WriteSerialStringEx(). But maybe, since this is all happening in the same thread, the mutex doesn't get unlocked as many times as it is locked - and then outside threads cannot add new things to the queue.

I was pretty sure there was a matching unlock for every mutex lock, but I'll take another look at the code again tonight. Hari, if you could take a look too I'd appreciate having a second set of eyes looking at the code too. It was from changeset 23385