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 ... 6
16
Developers / Re: New Event Plug-in proposal
« on: November 15, 2010, 05:47:12 pm »
BTW, posde, if you're still watching this thread, I'm jealous of your KNX blinds. :) In re-writing the Sunrise/Sunset logic I'm also adding Sun Elevation and Azimuth. Maybe someday soon you'll be able to use that to adjust your drapes/blinds based on the sun's position.

17
Developers / Re: New Event Plug-in proposal
« on: November 15, 2010, 05:43:03 pm »
This way you could have multiple modes for your houses heating, for example,

Timed:Use a pre defined set of times to turn the heating on and off
Auto: Use a temperature sensor do decide the heating requirements
On: Just put the heating on regardless of the time and/or temperature
Off:
Boost: Turn the heating on for 1 hour then reset to previous settings.

These modes would then show up in the climate panel of the UI for quick and easy setting.  Like I say this may already be possible, but if you are re-thinking the events module then it could be worth adding in. 

I'm not currently running any climate devices right now in my setup, but like this idea.  You might even be able to do this today with the Event Plug-in and a custom Climate Scenario.  It might be possible to further automate it with one of the House modes.

At the very least this is a good use-case for the new Event Plug-in.  I'm just working out the design for the plugin now and will keep this scenario in mind.  Maybe there is something easy I can tweak that will make your scenario easier to implement.

Lastly I'm not that up to speed on LinuxMCE yet, but if you need any help with simple coding or UI work I would be more than willing to help.

Thanks for the offer!  We could sure use any coding help you are willing to offer.  If you're interested in helping I'd suggest looking at the current bugs for LinuxMCE and see if there are any that you can tackle.  I found going through and fixing some of the bugs was a good way to learn how LinuxMCE works under the hood.

18
Developers / Re: New Event Plug-in proposal
« on: November 12, 2010, 03:01:47 pm »
I wonder if the event plugin is the problem, or the presentation of the plugin to the user

It is both. :)  When the Event Plug-in intercepts an event, it uses the PK_Event to only find event handlers for that specific type of event.  The web interface works the same way, allowing the user to only enter an event handler for a specific type of event.

I'm not sure which came first, but they both have the same issue.

19
Developers / Re: New Event Plug-in proposal
« on: November 12, 2010, 02:47:26 pm »
Just thought of one thing; I've tried to make the event plugin reload its rules without requiring a router reload. I think we should think along these lines for new plugin too. So make sure the rule set can be updated whenever the rules are edited in the web admin.

Will do.  I plan to support all the commands the current Event Plug-in supports.

20
Developers / Re: New Event Plug-in proposal
« on: November 09, 2010, 07:43:33 pm »
I think I've talked myself out of interfacing with Drools.  ...for now...  :)  For the simple cases like "Motion Detector not tripped in the last 10 minutes" just keeping track of the last time a device changed state will be sufficient enough to get CLIPS to understand that type of event.

21
Developers / Re: New Event Plug-in proposal
« on: November 09, 2010, 03:54:00 pm »
Just to follow up on the last post.  I wish we could use Drools for the Event Plug-in.  I'd drop CLIPS in a heartbeat.  Drools would give us much more capabilities than are currently available in CLIPS - Temporal Reasoning being the biggest capability I see missing from CLIPS (see description about half way down the Drools Fusion page).  Temporal Reasoning would allow me to add a "Motion Detector not tripped in the last 10 minutes" type of condition to my Sprinkler rules.  But Drools requires Java and I'm not sure how well the rest of the developers would like adding Java into a core plugin.

22
Developers / Re: New Event Plug-in proposal
« on: November 09, 2010, 03:51:56 pm »
I've done some small improvements to the current Event plugin over the last year, so if you need any assistance, I'll try to help out.

Much appreciated.  I'll probably ping on you with some questions when I get stuck :)

I can't think of any new features is should support, as long as the basic functionality we have today is still available. Timed event, for instance, not sure if they should be handled separately, or if they can be efficiently implemented in the CLIPS.

I think I'll be able to keep the timed events all within CLIPS and do away with the special cases that we have today.  At its core, CLIPS is based on reacting to changes in data.  I just need to feed CLIPS data for 'Day of Month', 'Day of week', and 'Current time' and keep those data points updated as time passes.

I think focusing on replacing what we have today is a good first step, then we can use it for a while and new ideas might appear.

That's my first goal of this project.  To read the events in the current database tables and represent them in a format that CLIPS understands.  Eventually I'm going to need to update the table structures to support some of the more advanced features of CLIPS, but starting small like this is a good idea.

One nice thing supported in CLIPS is the use of variables.  As a simple example of how powerful this can be, take a look at the existing events for Watching and Stopped Watching Media.  Currently those two events need to be duplicated for each Room.  If I'm able to model all the data from our devices into CLIPS, those rules could be re-written like this.

Rule 1 - Lights Off when Watching media
    (room (PK_Room ?room) (watching-media True))
    ?the_light <- (light (PK_Room ?room) (state On))
  * ACTION (?the_light send-command Off)

Rule 2 - Lights On when Stopped Watching media
    (room (PK_Room ?room) (watching-media False))
    ?the_light <- (light (PK_Room ?room) (state Off))
  * ACTION (?the_light send-command On)

?room and ?the_light are variables.  The first condition with the variable is the one that sets it.  So if you're watching media in Room 1, ?room will be 1.  The next condition will use the value of ?room to select only the light in that room that is On.  The action will use ?the_light as the target for the command to be sent.  The Rete algorithm specifies this rule will continue to run for each light On in each room that playing Media.  The rule will stop running when all the lights in all the rooms where media is played are Off.

Using the sprinkler example, it wouldn't be hard to extend the example to support Sprinkler Zones - only allowing a Zone to turn On if all the conditions were met and another Zone was not currently On.  The current database tables won't support this type of rule.  That's why I'll be looking to change them after the first version comes out.

The Rete algorithm is pretty powerful and can do some really tricky things.  Check out the CLIPS User Guide if you're interested in what can be implemented with CLIPS.  JBoss also has some videos demoing their Rete based products.  The Drools Expert is pretty much the same thing as CLIPS - but with a very pretty interface.

23
Developers / New Event Plug-in proposal
« on: November 09, 2010, 05:36:52 am »
I'd like to look into redesigning the Event Plug-in to make it better suited to handling complex events.  In the current Event Plug-in, a complex event might need to be broken into several separate events.

Lets say, as an example, you would like to automate whether your lawn sprinklers should be On or Off. In this example, you have two sensor devices to help determine when to water your lawn.  The first sensor, a rain sensor detects if it is currently raining.  If is is raining the state of the sensor will be "Raining" and if it is not raining, the state will be "No Rain".  The second sensor, a ground moisture sensor, detects the percentage of moisture in the ground.

In this example, you'd like the lawn to be watered only if the following conditions are satisfied:
  - The time is between 0500-0659
  - The rain sensor state is "No Rain"
  - The moisture sensor state is 25% or less
  - House mode is not Entertaining (you don't want to soak your guests)

Using the current Event Plug-in you would need to define six different events to manage your sprinklers.  You need two events (one On and one Off) for each type of event that effects the sprinklers.  Here are the six events, the event criteria are shown in parentheses:

  - Event 1 - Time Based at 0500, turn on
    (AND
      (sprinkler state = "Off")
      (moisture sensor state <= 25%)
      (rain sensor state "No Rain")
      (NOT
        (house mode "Entertaining")
      )
    )
    * ACTION: Turn the sprinklers on

  - Event 2 - Time Based at 0700, turn off
    (sprinkler state = "On" )
    * ACTION: Turn the sprinklers off

  - Event 3 - State Based, turn on
    (AND
      (sprinkler state = "Off")
      (current time >= 0500)
      (current time < 0700)
      (moisture sensor state <= 25%)
      (rain sensor state = "No Rain")
      (NOT
        (house mode "Entertaining")
      )
    )
    * ACTION: Turn the sprinklers on

  - Event 4 - State Based, turn off
    (AND
      (sprinkler state = "On")
      (OR
        (moisture sensor state > 25%)
        (rain sensor state = "Raining")
      )
    )
    * ACTION: Turn the sprinklers off

  - Event 5 - House Mode Based, turn on
    (AND
      (sprinkler state = "Off")
      (current time >= 0500)
      (current time < 0700)
      (moisture sensor state <= 25%)
      (rain sensor state = "No Rain")
      (NOT
        (house mode "Entertaining")
      )
    )
    * ACTION: Turn the sprinklers on

  - Event 6 - House Mode Based, turn off
    (AND
      (sprinkler state = "On")
      (house mode "Entertaining")
    )
    * ACTION: Turn the sprinklers off

As you can see, it takes a bit of thought to get this setup properly.  This is due to the current implementation of the Event Plug-in only being able to act on single events.  In this example, the individual events are Time, State, and House Mode.

An alternate implementation of the Event Plug-in could be less focused on the events that occur in the system and more focused on the overall state of the devices managed by LinuxMCE.  In this implementation, instead of being tied to a specific event, you just define the conditions necessary for your sprinklers to be On or Off.  To implement the example above only two rules are needed.  This is much easier for a person to implement and understand.

  - Rule 1 - Sprinklers auto-on
    (AND
      (sprinkers state off)
      (current-time >= 0500)
      (current-time <  0700)
      (rain-sensor state "No Rain")
      (moisture-sensor state <= 25%)
      (NOT
        (house-mode "Entertaining")
      )
    )
    * ACTION: (sprinklers send-command "on")

  - Rule 2 - Sprinklers auto-off
    (AND
      (sprinklers state on)
      (OR
        (current-time <  0500)
        (current-time >= 0700)
        (rain-sensor state "Raining")
        (moisture-sensor state > 25%)
        (house-mode "Entertaining")
      )
    )
    * ACTION: (sprinklers send-command "Off")

Implementing an event plugin that is based on the overall state of the system can quickly become inefficient if the right algorithm is not used.  You can immagine a nieve algorithm, checking each condition of each rule every time an event is fired, would bog down the system in a hurry.  I'm proposing this plug-in be based on the Rete algorithm.  You can read more about the Rete algoritm on Wikipedia, but in a nutshell it is designed to efficiently handle this type of rule based logic.  A C language public domain implementation of the Rete algorithm exists and is called CLIPS (C Language Integrated Production System).  I'd like to use CLIPS to implement a Rules-Base event plugin for LinuxMCE.  I'd also like to re-do the web interface for events to make it work with this new implementation.

Is it alright if I implement a new Event Plug-in?  Are there any other suggestions on how this should be done or features it should support?

24
Installation issues / Re: Volume Control in other rooms
« on: November 07, 2010, 04:05:17 am »
This should be fixed in the next snapshot.  The trac ticket for this is #746

25
I updated my core over the weekend and started having issues with the OSD orbiter not coming back on screen when I finished watching media on a non-pluto/external Blu-ray player.

Let me describe my setup.  I'm using Gyration remotes to control my OSD Orbiters.  I have a receiver, television, and Blu-ray player all in the same entertainment area.  I have device pipes setup on my MD to switch the receiver and television to the proper inputs to display the OSD orbiter.  And I have device pipes setup on my Blu-ray player device to switch the receiver and television to the proper inputs to view the Blu-ray player via Live AV.

What used to happen, was when I finished watching a Blu-ray, I'd press the power button on the remote.  That would turn off the Blu-ray player and switch my receiver and television back to the inputs needed to view the MD's OSD orbiter.  Then I'd press the power button again and the OSD Power menu would come up so that I could power down the television and receiver.

Now what happens is when I finish watching a Blu-ray, I press the power button on the remote and the only thing that happens is the Blu-ray player turns off.  I'm left with a "no signal" screen on my television.  When I press power again, I cannot see the OSD Power menu (though I know it has selected the 'Display Off' option for me).

I tracked my issue down to changeset 23325 (Don't turn the TV on when music stops playing).  I completely understand the reason behind this change, but can we bring that code back and find a different solution?

26
Just a quick note to let you know V 1.0.2 is available on app store now. There are no improvements but it does run on older iPod's with iOS 3.1.3 now. I know there are many lying around that could probably serve and be reused now :-)

Thanks!  I'll have to give this a try.

27
Darn.  That didn't fix it.  Back to the same old locked up dongle.

Hari explained a lot about how Z-Wave is supposed to work on IRC yesterday (thanks again Hari).  He explained that ZWave controllers/dongles aren't supposed to take any longer than about 2-3 seconds to respond.  So it looks like our controllers are not behaving correctly.

I've created a Trac ticket for this issue.  I'll be submitting the work-around that was discussed before - to soft-reset the controller if more than three consecutive commands fail - this evening after I've completed my testing.  I'll keep the ticket open for another few weeks just in case we find another solution, but unfortunately it looks like we have some bad hardware.

28
Just had a small success.  On a hunch, I increased the time the driver waits for a callback from 3 seconds to 30 seconds.  Turns out that when I get this error, the controller/dongle actually takes just over 5 seconds to respond.  Here is the log:

Code: [Select]
36 10/28/10 11:05:28.257 We have been idle for 30 seconds, polling device states <0xb7116b90>
40 10/28/10 11:05:28.357 Sending job 0x9ce5320 (cb 1) - 0x1 0x9 0x0 0x13 0xff 0x2 0x20 0x2 0x5 0x1 0x3e (###### ###>) <0xb7116b90>
41 10/28/10 11:05:28.368 0x1 0x4 0x1 0x13 0x1 0xe8 (######) <0xb7116b90>
36 10/28/10 11:05:28.368 ZW_SEND delivered to Z-Wave stack <0xb7116b90>
01 10/28/10 11:05:31.369 No callback received after 3 seconds, waiting a little longer <0xb7116b90>
41 10/28/10 11:05:33.132 0x1 0x6 0x0 0x49 0x81 0x0 0x0 0x31 (###I###1) <0xb7116b90>
36 10/28/10 11:05:33.132 FUNC_ID_ZW_APPLICATION_UPDATE:UPDATE_STATE_NODE_INFO_REQ_FAILED received <0xb7116b90>
36 10/28/10 11:05:33.132 Generic callback handling for command 73, ERROR: wrong callback type: 19 <0xb7116b90>
41 10/28/10 11:05:33.404 0x1 0x6 0x0 0x49 0x81 0x0 0x0 0x31 (###I###1) <0xb7116b90>
36 10/28/10 11:05:33.404 FUNC_ID_ZW_APPLICATION_UPDATE:UPDATE_STATE_NODE_INFO_REQ_FAILED received <0xb7116b90>
36 10/28/10 11:05:33.404 Generic callback handling for command 73, ERROR: wrong callback type: 19 <0xb7116b90>
41 10/28/10 11:05:33.424 0x1 0x5 0x0 0x13 0x1 0x0 0xe8 (#######) <0xb7116b90>
36 10/28/10 11:05:33.424 ZW_SEND Response with callback 1 received <0xb7116b90>
36 10/28/10 11:05:33.424 ZW_SEND was successful, removing job <0xb7116b90>

See the log in my previous message to see what happens when the driver times out after 3 seconds.  I think maybe if the driver times out after 3 seconds, and tries to resend, it might be causing the controller/dongle to stop accepting new requests - requiring a soft-reset to get it un-stuck.

Hari, or anyone more familiar with the ZWave protocol, does this make sense?  Also, do you know what the FUNC_ID_ZW_APPLICATION_UPDATE:UPDATE_STATE_NODE_INFO_REQ_FAILED response means?

BTW: Getting rid of the buffer flush at the end of the Serial Write routine cleared up all my Out of frame flow errors.

29
davegravy,

Do you still have any logs around with the ZW_SEND could not be delivered to Z-Wave stack error message?  If so, I'd be interested in seeing them.  I'm really interested in the messages that are sent just prior to you seeing the first ZW_SEND delivery error popping up in your log.  If you can get me that, and maybe the previous 50 or so lines that would be perfect.

Maybe that would help me focus in on the issue.

Here is a sample from my log
Code: [Select]
36 10/26/10 21:20:24.189 We have been idle for 30 seconds, polling device states <0xb7251b90>
40 10/26/10 21:20:24.288 Sending job 0x952bde0 (cb 73) - 0x1 0x9 0x0 0x13 0xff 0x2 0x20 0x2 0x5 0x49 0x76 (###### ##Iv) <0xb7251b90>
41 10/26/10 21:20:24.300 0x1 0x4 0x1 0x13 0x1 0xe8 (######) <0xb7251b90>
36 10/26/10 21:20:24.300 ZW_SEND delivered to Z-Wave stack <0xb7251b90>
41 10/26/10 21:20:24.317 0x1 0x5 0x0 0x13 0x49 0x0 0xa0 (####I##) <0xb7251b90>
36 10/26/10 21:20:24.317 ZW_SEND Response with callback 73 received <0xb7251b90>
36 10/26/10 21:20:24.317 ZW_SEND was successful, removing job <0xb7251b90>
40 10/26/10 21:20:24.417 Sending job 0x952c000 (cb 74) - 0x1 0xc 0x0 0x13 0xff 0x5 0x60 0x6 0x2 0x20 0x2 0x5 0x4a 0x13 (######`## ##J#) <0xb7251b90>
41 10/26/10 21:20:24.426 0x1 0x4 0x1 0x13 0x1 0xe8 (######) <0xb7251b90>
36 10/26/10 21:20:24.426 ZW_SEND delivered to Z-Wave stack <0xb7251b90>
41 10/26/10 21:20:24.449 0x1 0x5 0x0 0x13 0x4a 0x0 0xa3 (####J##) <0xb7251b90>
36 10/26/10 21:20:24.449 ZW_SEND Response with callback 74 received <0xb7251b90>
36 10/26/10 21:20:24.449 ZW_SEND was successful, removing job <0xb7251b90>
41 10/26/10 21:20:24.477 0x1 0x9 0x0 0x4 0x0 0x7 0x3 0x20 0x3 0xff 0x2a (####### ##*) <0xb7251b90>
36 10/26/10 21:20:24.477 FUNC_ID_APPLICATION_COMMAND_HANDLER: <0xb7251b90>
36 10/26/10 21:20:24.477 COMMAND_CLASS_BASIC -  <0xb7251b90>
36 10/26/10 21:20:24.477 Got basic report from node 7, value: 255 <0xb7251b90>
41 10/26/10 21:20:24.552 0x1 0x9 0x0 0x4 0x0 0x4 0x3 0x20 0x3 0x63 0xb5 (####### #c#) <0xb7251b90>
36 10/26/10 21:20:24.552 FUNC_ID_APPLICATION_COMMAND_HANDLER: <0xb7251b90>
36 10/26/10 21:20:24.552 COMMAND_CLASS_BASIC -  <0xb7251b90>
36 10/26/10 21:20:24.552 Got basic report from node 4, value: 99 <0xb7251b90>
40 10/26/10 21:20:24.652 Sending job 0x952c220 (cb 75) - 0x1 0x9 0x0 0x13 0xff 0x2 0x31 0x4 0x5 0x4b 0x63 (######1##Kc) <0xb7251b90>
41 10/26/10 21:20:24.656 0x1 0x4 0x1 0x13 0x1 0xe8 (######) <0xb7251b90>
36 10/26/10 21:20:24.656 ZW_SEND delivered to Z-Wave stack <0xb7251b90>
41 10/26/10 21:20:24.680 0x1 0x5 0x0 0x13 0x4b 0x0 0xa2 (####K##) <0xb7251b90>
36 10/26/10 21:20:24.680 ZW_SEND Response with callback 75 received <0xb7251b90>
36 10/26/10 21:20:24.680 ZW_SEND was successful, removing job <0xb7251b90>
41 10/26/10 21:20:24.740 0x1 0x9 0x0 0x4 0x0 0x3 0x3 0x20 0x3 0x0 0xd1 (####### ###) <0xb7251b90>
36 10/26/10 21:20:24.740 FUNC_ID_APPLICATION_COMMAND_HANDLER: <0xb7251b90>
36 10/26/10 21:20:24.740 COMMAND_CLASS_BASIC -  <0xb7251b90>
36 10/26/10 21:20:24.740 Got basic report from node 3, value: 0 <0xb7251b90>
41 10/26/10 21:20:24.784 0x1 0x9 0x0 0x4 0x0 0x6 0x3 0x20 0x3 0x0 0xd4 (####### ###) <0xb7251b90>
36 10/26/10 21:20:24.784 FUNC_ID_APPLICATION_COMMAND_HANDLER: <0xb7251b90>
36 10/26/10 21:20:24.784 COMMAND_CLASS_BASIC -  <0xb7251b90>
36 10/26/10 21:20:24.784 Got basic report from node 6, value: 0 <0xb7251b90>
36 10/26/10 21:20:54.884 We have been idle for 30 seconds, polling device states <0xb7251b90>
40 10/26/10 21:20:54.986 Sending job 0x952c440 (cb 76) - 0x1 0x9 0x0 0x13 0xff 0x2 0x20 0x2 0x5 0x4c 0x73 (###### ##Ls) <0xb7251b90>
41 10/26/10 21:20:54.993 0x1 0x4 0x1 0x13 0x1 0xe8 (######) <0xb7251b90>
36 10/26/10 21:20:54.993 ZW_SEND delivered to Z-Wave stack <0xb7251b90>
41 10/26/10 21:20:55.012 0x1 0x5 0x0 0x13 0x4c 0x0 0xa5 (####L##) <0xb7251b90>
36 10/26/10 21:20:55.012 ZW_SEND Response with callback 76 received <0xb7251b90>
36 10/26/10 21:20:55.012 ZW_SEND was successful, removing job <0xb7251b90>
41 10/26/10 21:20:55.097 0x1 0x9 0x0 0x4 0x0 0x4 0x3 0x20 0x3 0x63 0xb5 (####### #c#) <0xb7251b90>
36 10/26/10 21:20:55.097 FUNC_ID_APPLICATION_COMMAND_HANDLER: <0xb7251b90>
36 10/26/10 21:20:55.097 COMMAND_CLASS_BASIC -  <0xb7251b90>
36 10/26/10 21:20:55.097 Got basic report from node 4, value: 99 <0xb7251b90>
41 10/26/10 21:20:55.180 0x1 0x9 0x0 0x4 0x0 0x3 0x3 0x20 0x3 0x0 0xd1 (####### ###) <0xb7251b90>
36 10/26/10 21:20:55.180 FUNC_ID_APPLICATION_COMMAND_HANDLER: <0xb7251b90>
36 10/26/10 21:20:55.180 COMMAND_CLASS_BASIC -  <0xb7251b90>
36 10/26/10 21:20:55.180 Got basic report from node 3, value: 0 <0xb7251b90>
40 10/26/10 21:20:55.280 Sending job 0x952c660 (cb 77) - 0x1 0xc 0x0 0x13 0xff 0x5 0x60 0x6 0x2 0x20 0x2 0x5 0x4d 0x14 (######`## ##M#) <0xb7251b90>
41 10/26/10 21:20:55.288 0x1 0x4 0x1 0x13 0x1 0xe8 (######) <0xb7251b90>
36 10/26/10 21:20:55.288 ZW_SEND delivered to Z-Wave stack <0xb7251b90>
41 10/26/10 21:20:55.309 0x1 0x5 0x0 0x13 0x4d 0x0 0xa4 (####M##) <0xb7251b90>
36 10/26/10 21:20:55.309 ZW_SEND Response with callback 77 received <0xb7251b90>
36 10/26/10 21:20:55.309 ZW_SEND was successful, removing job <0xb7251b90>
40 10/26/10 21:20:55.408 Sending job 0x952c880 (cb 78) - 0x1 0x9 0x0 0x13 0xff 0x2 0x31 0x4 0x5 0x4e 0x66 (######1##Nf) <0xb7251b90>
41 10/26/10 21:20:55.417 0x1 0x4 0x1 0x13 0x1 0xe8 (######) <0xb7251b90>
36 10/26/10 21:20:55.417 ZW_SEND delivered to Z-Wave stack <0xb7251b90>
41 10/26/10 21:20:55.436 0x1 0x5 0x0 0x13 0x4e 0x0 0xa7 (####N##) <0xb7251b90>
36 10/26/10 21:20:55.436 ZW_SEND Response with callback 78 received <0xb7251b90>
36 10/26/10 21:20:55.436 ZW_SEND was successful, removing job <0xb7251b90>
41 10/26/10 21:20:55.572 0x1 0x9 0x0 0x4 0x0 0x6 0x3 0x20 0x3 0x0 0xd4 (####### ###) <0xb7251b90>
36 10/26/10 21:20:55.572 FUNC_ID_APPLICATION_COMMAND_HANDLER: <0xb7251b90>
36 10/26/10 21:20:55.572 COMMAND_CLASS_BASIC -  <0xb7251b90>
36 10/26/10 21:20:55.572 Got basic report from node 6, value: 0 <0xb7251b90>
41 10/26/10 21:20:56.261 0x1 0x9 0x0 0x4 0x0 0x6 0x3 0x20 0x3 0x0 0xd4 (####### ###) <0xb7251b90>
36 10/26/10 21:20:56.261 FUNC_ID_APPLICATION_COMMAND_HANDLER: <0xb7251b90>
36 10/26/10 21:20:56.261 COMMAND_CLASS_BASIC -  <0xb7251b90>
36 10/26/10 21:20:56.261 Got basic report from node 6, value: 0 <0xb7251b90>
41 10/26/10 21:20:56.972 0x1 0x9 0x0 0x4 0x0 0x6 0x3 0x20 0x3 0x0 0xd4 (####### ###) <0xb7251b90>
36 10/26/10 21:20:56.972 FUNC_ID_APPLICATION_COMMAND_HANDLER: <0xb7251b90>
36 10/26/10 21:20:56.972 COMMAND_CLASS_BASIC -  <0xb7251b90>
36 10/26/10 21:20:56.972 Got basic report from node 6, value: 0 <0xb7251b90>
36 10/26/10 21:21:27.117 We have been idle for 30 seconds, polling device states <0xb7251b90>
40 10/26/10 21:21:27.217 Sending job 0x952caa0 (cb 79) - 0x1 0x9 0x0 0x13 0xff 0x2 0x20 0x2 0x5 0x4f 0x70 (###### ##Op) <0xb7251b90>
41 10/26/10 21:21:27.225 0x1 0x4 0x1 0x13 0x1 0xe8 (######) <0xb7251b90>
36 10/26/10 21:21:27.225 ZW_SEND delivered to Z-Wave stack <0xb7251b90>
05 10/26/10 21:21:30.333 No callback received: await_callback: 79 timer: 31 <0xb7251b90>
40 10/26/10 21:21:30.433 Sending job 0x952caa0 (cb 79) - 0x1 0x9 0x0 0x13 0xff 0x2 0x20 0x2 0x5 0x4f 0x70 (###### ##Op) <0xb7251b90>
41 10/26/10 21:21:30.441 0x1 0x4 0x1 0x13 0x1 0xe8 (######) <0xb7251b90>
36 10/26/10 21:21:30.441 ZW_SEND delivered to Z-Wave stack <0xb7251b90>
05 10/26/10 21:21:33.544 No callback received: await_callback: 79 timer: 31 <0xb7251b90>
40 10/26/10 21:21:33.644 Sending job 0x952caa0 (cb 79) - 0x1 0x9 0x0 0x13 0xff 0x2 0x20 0x2 0x5 0x4f 0x70 (###### ##Op) <0xb7251b90>
41 10/26/10 21:21:33.648 0x1 0x4 0x1 0x13 0x1 0xe8 (######) <0xb7251b90>
36 10/26/10 21:21:33.648 ZW_SEND delivered to Z-Wave stack <0xb7251b90>
05 10/26/10 21:21:36.749 No callback received: await_callback: 79 timer: 31 <0xb7251b90>
01 10/26/10 21:21:36.749 ERROR: Dropping command, no callback received after three resends <0xb7251b90>
40 10/26/10 21:21:36.848 Sending job 0x952ccc0 (cb 80) - 0x1 0xc 0x0 0x13 0xff 0x5 0x60 0x6 0x2 0x20 0x2 0x5 0x50 0x9 (######`## ##P#) <0xb7251b90>
41 10/26/10 21:21:36.854 0x1 0x4 0x1 0x13 0x0 0xe9 (######) <0xb7251b90>
36 10/26/10 21:21:36.854 ERROR: ZW_SEND could not be delivered to Z-Wave stack <0xb7251b90>

30
I just worry that once we have your fix there will be little motivation to figure out what the exact cause of the problem is. Is there nothing else that can be done to narrow this down without wireless diagnostic equipment?

I have the same feeling.  This is a quick hack and might mask the real issue.  I was hoping to see something in the kernel logging that would indicate why this happens, but from what I could see the ZWave dongle was getting and properly understanding the commands the driver was sending.

You're welcome to take a look at those logs.  I'd start with the ZWave.log file, search for the error and note the time that it occurred.  Then open up the kern.log and search for events coming from the kernel around that same time.

The only other theory that I have is that maybe the dongle can't handle multiple requests coming in at the same time.  I noticed that when the ZWave driver does its polling it sends a broadcast message and doesn't wait for all the individual devices to reply before issuing the next command.  I'll try putting a delay between the messages and see if that helps.  Just takes a while to test because I don't know how to predictably reproduce the error.

I'd be curious to know if there is anyone who has turned off the polling feature in the ZWave driver and is still getting these issues.

Pages: 1 [2] 3 4 ... 6