Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - esev

Pages: 1 2 [3] 4 5 6
Hm. I doubt this is due to the USB_UIRT.

When the issue occurs for you, have you tried sending the StatusReport command to the ZWave device?  (device tree->ZWave->Send command to device)  If that works for you, I've got a fix in the works that will cure the issue as soon as it arises.

Unplugging my other USB devices consistently fixes the problem.


Which other USB devices do you have?  Maybe we have one in common that is causing this issue.  I've got the USB_UIRT, Hauppauge HD-PVR, Gyration GYR4101US in addition to my Tricklestar ZWave.


I finally got the error to occur again.  However I cannot find anything telling in the logs that would indicate why it is failing.  Again, performing the soft-reset cleared things up.  If you'd like to take a look at the logs for yourself, you can download them from:  Both the ZWave and kernel debugging logs are included.

One thing that did arrise from the logs is that when this issue occurs the ZWave controller is sending back notifications that the message cannot be sent to the ZWave stack: i.e. "ERROR: ZW_SEND could not be delivered to Z-Wave stack" shows up in the logs.

Since I cannot see any other obvious way to fix this, I'm using your suggestion of a counter to trigger a soft-reset after receiving two consecutive ZW_SEND delivery errors.  I chose two because the retry limit of a job is currently set to 3.  My thought was that if the reset was successful, the third retry would still have a chance to work.  To do this, however, I needed to insert the soft-reset job at the beginning of the ZWSendQueue.

Let me know if this will be acceptable.  I've attached a preliminary patch.  I'll wait to confirm this works before posting it to a ticket on Trac.  I can add the "Out of frame flow" fix from my previous post to this patch too, if you'd like.



Thanks for the reply.  With the full debugging turned on, I'm seeing some weird things.  For example, I see the ZWave dongle send a message to the driver at the same time the ZWave driver sends a message to the dongle.  This is causing an issue as in Serial.cpp line 95 all the data in the input buffers is flushed when a message is transmitted to the dongle.  This causes a message from the dongle to be missed in the driver and sometimes winds up in a ERROR! Out of frame flow!! message.

Is there a reason for flushing the input buffer like that?  I'm hesitant to touch that code because it might be there to handle a special case with another ZWave dongle.

I haven't gotten into the infinite retry state yet with full debugging turned on.  Still waiting...


Maybe sending the Soft-Reset does work.  I just noticed I was getting these error messages again.  I sent the StatusReport command to the ZWave device and, after the 30sec device polling was complete, the system went back to normal.

I'll enable debugging on the pl2303 module and also crank up the logging on the ZWave device.  Maybe between the logs I be able to catch something out of the ordinary going on.

Failing that, Hari, would you mind if I submit a patch to do a Soft-Reset if all devices fail to respond to the poll that takes place every 30 seconds?

I suspected communications problems at first too.  But my ZWave dongle has nearly direct line-of-sight to the closest device, and the two are less than 20ft away from each other.  The weird thing is that the errors go away immediately after a reboot.

The errors are always in a set of four: three await_callback and one Dropping command.  They will continue this way for hours, sometimes going back to normal on their own.  When everything is working fine I don't get any errors except for an occasional single await_callback.

I'm happy to try resetting my devices and moving the ZWave dongle to one of my Media Directors (will this work?) just to see if being in a different part of the house has any effect.

I should also mention, the last time I got these errors I issued a "#788 StatusReport" to the ZWave plugin.  I stopped getting these errors after sending that command.  I think that is because implementation of the StatusReport command Soft-Resets the dongle.  I've only tried this one time however, so it might have just been a coincidence that things started working again.

Does anyone else get this error in their ZWave log?
   No callback received: await_callback: 105 timer: 31 <0xb7136b90>
   No callback received: await_callback: 105 timer: 31 <0xb7136b90>
   No callback received: await_callback: 105 timer: 31 <0xb7136b90>
   ERROR: Dropping command, no callback received after three resends <0xb7136b90>

I have the Tricklestar 300ZW and see these from time to time.  It seems once I start getting this error it continues till I reboot the computer.  While this error is occurring LinuxMCE is unable to control any ZWave devices.

Just curious if anyone else has seen this. Is it limited to the Tricklestar dongle? Is there any way to prevent it?

im sorry esev, i didnt mean to step on your toes there.

No worries. :)  Glad to see someone is looking over these.

It might be worth pushing 838 off to the 1004 release.  There is a documented workaround on the wiki for 0810.  I suspect Kubuntu 1004's stock HID driver will be sufficient, in which case this will be a quick fix.

I've been fixing a few more issues encountered while using the system. Here are some tickets with patches that if applied can be closed:

40 - from the comments i think it can be closed but im not 100% sure

Please don't close 838.  The sqlCVS batches were approved, but I still need to work out how to get a new HID driver installed with the system.  I've added a comment to the ticket to make that clearer.


I've added patches to a couple tickets that were marked as 'Defect'. Could these tickets be updated to 'Defect Patch'?

If there is anything I can do to help get these tickets resolved/closed please let me know.


Installation issues / Re: Volume Control in other rooms
« on: October 23, 2010, 04:17:51 pm »
LmceCape and Techstyle,

Can you confirm where the volume control messages are going when viewing your devices from a remote Media Director?  Sounds like LmceCape's volume control is going to the Audio Pipe he has setup for the device.  How about you Techstyle?  When you view the cable box from a different media director than the one it is plugged into and try to control the volume, where does the volume actually get controlled (that MD, the cable box, or somewhere else)?

Just want to confirm the behavior you're seeing.  It'll make it easier to track down and try to fix.

Installation issues / Re: 8.10 Installation Experience for hybrid
« on: October 21, 2010, 12:26:08 am »
1. After confirming all of the Video and Audio settings the mouse pointer ends up in the middle of the screen. This causes the text that appears in the middle of the screen to vanish immediately after it is displayed. I moved the pointer off the middle and then the text remained so I could see the installation comments as they appeared. I noticed the same behavior when the machine is booting up. Maybe the mouse pointer can be moved to the upper left corner rather than the center of the display.

2. I was unable to press "model isn't on the list" when specifying a Pioneer receiver. The button failed to respond to the button press. Seemed like a defect.

3. Specifying SchedulesDirect information during the Setup process failed to get properly recorded with the LinuxMCE-default video source. I had to specify it again when configuring the MythTV backend.  Seemed like a defect.

4. The MythTV frontend was unable to delete previously recorded MythTV shows after the re-installation because the files were owned by root instead of mythtv in the PVR directories. I changed the ownership of the files to mythtv and I was able to delete again.  Maybe the drive configuration could confirm that the files have proper permissions when a drive is added. I migrated the recordings per

Thanks for posting these issues!

I can confirm #2 doesn't work.  The button cannot be clicked on, but it can be reached via arrow keys on the keyboard.

You might want to submit these as individual tickets on the bug tracking system.

Developers / Re: Touch Orbiter and Web Orbiter speed improvements
« on: October 20, 2010, 04:46:54 pm »
This looks like a very nice idea. We will look at testing it in the iOS Orbiter asap.

Glad you can make use of it!  I figured it might help conserve battery life with the iPhone and Android clients.

Developers / Re: Touch Orbiter and Web Orbiter speed improvements
« on: October 20, 2010, 04:26:54 pm »
Sorry, just realized that patch won't work for anyone who is running the latest version of the Web Orbiter code from Subversion.  If you are running the latest, the attached WebOrbiter patch will work for you.

One change I made to the web orbiter is that clicking on the Orbiter screen doesn't cause the UI image to reload. The two events, clicking and reloading, are independent of one another.  This is done because the RefreshImage ajax query will block till the Proxy_Orbiter actually generates the new screen.  At that point the UI image will be refreshed.


Pages: 1 2 [3] 4 5 6