Announcement

**GatorKWM** · September 27, 2007, 08:59 AM

Anogee,
Isn't this the same inherant problem with the USB PIM that we talked about some time back in this thread:

http://board.homeseer.com/showthread.php?t=113004

**Oman** · September 28, 2007, 09:49 AM

I don't think so. The plug-in indicates that the transmitted message is all zeros which isn't valid. There are a few more pieces of information I need. These should be gathered *after* the lights stop responding.

1) I need to see what comes in from the PIM when a switch transmits. Just press any switch tied to a link.

2) I need to see different lights attempt to transmit from HomeSeer. Just try to control a few different UPB lights in a row.

3) What happens if you disable then enable the UPB plug-on (from the HS setup/interfaces page) *without* restarting HomeSeer.

Then send me the log. I can't see any way that a transmit string like this can be generated unless the UPB tables themselves have been destroyed in memory. As far as I can tell I have not had any other reports of this. In most other cases the PIM just stops responding to commands sent to it. In this case the command being sent is bad.

Jon

Originally posted by GatorKWM View Post

Anogee,
Isn't this the same inherant problem with the USB PIM that we talked about some time back in this thread:

http://board.homeseer.com/showthread.php?t=113004

**anogee** · September 28, 2007, 10:59 AM

O.K. I will gather that the next time it occurs. It might be a day or so, or it could be two months. Like I say, the weird part is that HomeSeer THINKS all is working and reports devices as if they changed, but they don't. The PIM even buzzes like its trying to change something.

So my question. I thought that the plug-in verifies that signals were received correctly? Why does Homeseer THINK they were received correctly when they weren't sent correctly? If it attempted to retransmit 5 times, I could understand that.

**Oman** · September 28, 2007, 11:22 AM

The message assembled for the PIM wasn't actually a transmit request. The PIM accepted the message and since it wasn't a transmit request there wasn't a reply to be verified.

The question is what caused the message to be "munged". It looks like the UPB tables were corrupted in memory somehow. It would seem impossible looking at the code but it is happening somehow it seems. Once the tables are loaded they are never written to, only read from. Since there are no exceptions being thrown whatever is happening is not being detected by any existing sanity checks in .NET or the plug-in.

On the 1 to 10 strange scale this hits about 15.

Not a single log ever sent to me has shown this before.

I can make a special plug-in build with some additional diagnostics.

Jon

Originally posted by anogee View Post

O.K. I will gather that the next time it occurs. It might be a day or so, or it could be two months. Like I say, the weird part is that HomeSeer THINKS all is working and reports devices as if they changed, but they don't. The PIM even buzzes like its trying to change something.

So my question. I thought that the plug-in verifies that signals were received correctly? Why does Homeseer THINK they were received correctly when they weren't sent correctly? If it attempted to retransmit 5 times, I could understand that.

**anogee** · September 28, 2007, 11:31 PM

Sure, I would love to help anyway I can and I appreciate your help. By the way, this is Win XP Pro with the latest software updates if that matters.

If it can't be fixed, I wonder if there is a way it can be detected? That way I could perform a reset. Wife is then happy.

**nightwalker** · October 15, 2007, 12:27 PM

I don't think this is the same problem as I'm having for the last couple of days but it's pretty close. yesterday twice i noticed that my UPB devices were not responding. I tried to close the UPB plug in first from the button in the config like i was going to start an upstart session. Another time i tried just shutting down HomeSeer so i could restart it. The first did nothing at all. Trying to shut down HS resulted in it stopping at the UPB plugin shut down in the log and there it just froze and a reboot was necessary. I'm not getting errors in the logs, it just stops responding at all. The last thing written to the log was

10/14/2007 6:01:45 PM ~!~Shutdown~!~Shutting down plug-in: UPB
10/14/2007 6:06:50 PM ~!~Startup~!~
10/14/2007 6:06:50 PM

After that i had to reboot the system to get it back up. I'm not sure where to look, software, could it be hardware?

Has anyone seen this behavior before?

**nightwalker** · October 16, 2007, 05:56 AM

As an update to the question above. It lock up again yesterday. I had turned on debug logging in the UPB plug-in to see if it gave me a clue to what's happening. It didn't for me but maybe someone else will recognize the symptoms. In the log just after a UPB command that did not work i get.

10/15/2007 3:30:00 PM - Info - Device: Powder Room Display Lights (]1) ON
10/15/2007 3:30:00 PM - UPB - In SetIO:]1 Cmd: 2 Bright: 0 Data1: 0 Data2: 0
10/15/2007 3:30:00 PM - UPB - Processing SetIO (Device Housecode) for ]1 Cmd: 2 Bright: 0 Data1: 0 Data2: 0
10/15/2007 3:30:00 PM - UPB - Setting value for ]1
10/15/2007 3:30:00 PM - UPB - In SetIO:]1 Cmd: 19 Bright: 100 Data1: 0 Data2: 0
10/15/2007 3:30:00 PM - UPB - Ignoring SetIO (Device Housecode) for ]1 Cmd: 19 Bright: 100 Data1: 0 Data2: 0 because the device table shows that it is being updated by the plug-in.
10/15/2007 3:30:00 PM - Info - Event Trigger "Powder Room - On"
10/15/2007 3:30:00 PM - Info - Device: Virtual Powder Room (V16) ON
10/15/2007 3:30:00 PM - UPB - PIM<--Sending 0A100101FF226400015E to PIM (Try # 1)

At that point nothing else. Trying to shut down HomeSeer and restart i got

10/15/2007 3:48:37 PM - UPB - Enter ShutdownIO, waiting for threads to terminate...
10/15/2007 3:48:37 PM - UPB - Exit ReadSerialThread
10/15/2007 3:48:38 PM - UPB - Exit TimedPollThread
10/15/2007 3:48:40 PM - UPB - Closing serial port

That was the last entry, it just sat there and i was forced to reboot the computer to get it back up.

Any ideas out there?

**Oman** · October 16, 2007, 11:29 AM

You don't mention what PIM you have. I looks from the log like the serial port driver hung up. It couldn't send data, and it froze homeseer when the close request went out. Is this is standard serial port?

Jon

Originally posted by nightwalker View Post

As an update to the question above. It lock up again yesterday. I had turned on debug logging in the UPB plug-in to see if it gave me a clue to what's happening. It didn't for me but maybe someone else will recognize the symptoms. In the log just after a UPB command that did not work i get.

10/15/2007 3:30:00 PM - Info - Device: Powder Room Display Lights (]1) ON
10/15/2007 3:30:00 PM - UPB - In SetIO:]1 Cmd: 2 Bright: 0 Data1: 0 Data2: 0
10/15/2007 3:30:00 PM - UPB - Processing SetIO (Device Housecode) for ]1 Cmd: 2 Bright: 0 Data1: 0 Data2: 0
10/15/2007 3:30:00 PM - UPB - Setting value for ]1
10/15/2007 3:30:00 PM - UPB - In SetIO:]1 Cmd: 19 Bright: 100 Data1: 0 Data2: 0
10/15/2007 3:30:00 PM - UPB - Ignoring SetIO (Device Housecode) for ]1 Cmd: 19 Bright: 100 Data1: 0 Data2: 0 because the device table shows that it is being updated by the plug-in.
10/15/2007 3:30:00 PM - Info - Event Trigger "Powder Room - On"
10/15/2007 3:30:00 PM - Info - Device: Virtual Powder Room (V16) ON
10/15/2007 3:30:00 PM - UPB - PIM<--Sending 0A100101FF226400015E to PIM (Try # 1)

At that point nothing else. Trying to shut down HomeSeer and restart i got

10/15/2007 3:48:37 PM - UPB - Enter ShutdownIO, waiting for threads to terminate...
10/15/2007 3:48:37 PM - UPB - Exit ReadSerialThread
10/15/2007 3:48:38 PM - UPB - Exit TimedPollThread
10/15/2007 3:48:40 PM - UPB - Closing serial port

That was the last entry, it just sat there and i was forced to reboot the computer to get it back up.

Any ideas out there?

**nightwalker** · October 16, 2007, 06:06 PM

Originally posted by Oman View Post

You don't mention what PIM you have. I looks from the log like the serial port driver hung up. It couldn't send data, and it froze homeseer when the close request went out. Is this is standard serial port?

Jon

Good idea, i guess my info was a little lite.

The PIM I'm using is a HAI unit that's worked well for the last 6 months or so. It's connected through an Edgeport8 that i've used for about a year now with no issues. Connected to that same Edgeport is a netcaller ID box, a T103, and a relay8 unit. All of those continued to operate when the UPB was locked up.

I suppose it could be the port that the HAI unit is connected to. I can try changing it to one of the spare ones and see if that has any effect.

Of course it hasn't done it today, isnt' that always the way

**nightwalker** · October 20, 2007, 10:49 AM

I've been playing with this for a couple of days now. I'm coming to the conclusion that i have something internal in my system that has started to interfere with either the com port or the Plug-in. HS itself does not seem to be effected. UPB just stops and a reboot sets everything right again. I'm continuing to look for the root cause and if i have to I'll wipe the system and redo, it may be time for that anyway.

This however brings up several questions that keep popping to mind. I have the UPB set to detailed debug logging and i don't quite understand all of what it's telling me however.

Since HS itself seems to keep right on working even though UPB is down. All other functions, X10, IR, Relays, Events all continue to work as well.

Since UPB is a two way protocol and the logs clearly show that UPB is looking to get a ACK back from the PIM.

1 Why when there is no ACK sent from the PIM does HS continue to show UPB devices as they should have been, not how they really are. I would think that when no ACK is received after a command is sent that it would try again. I may have something set wrong but darn if i can find what.

HomeSeer just goes right along as though nothing is wrong, even though nothing on the UPB side is doing anything. I would think a big red error line in the log would be good to show that there was no confirmation from the PIM that a command has been sent and the device is in the correct state.

2 Is there no way to monitor the UPB pim, the way the Powerlinc USB is?

This is the first real problem I've encountered with UPB and I'd sure like to get if fixed before the WAF fall any further, especially when it's not the usual hardware signal problems you usually end up troubleshooting. I hate when that happens.

**anogee** · October 22, 2007, 09:39 AM

Originally posted by nightwalker View Post

1 Why when there is no ACK sent from the PIM does HS continue to show UPB devices as they should have been, not how they really are. I would think that when no ACK is received after a command is sent that it would try again. I may have something set wrong but darn if i can find what.

HomeSeer just goes right along as though nothing is wrong, even though nothing on the UPB side is doing anything. I would think a big red error line in the log would be good to show that there was no confirmation from the PIM that a command has been sent and the device is in the correct state.

2 Is there no way to monitor the UPB pim, the way the Powerlinc USB is?

This is the first real problem I've encountered with UPB and I'd sure like to get if fixed before the WAF fall any further, especially when it's not the usual hardware signal problems you usually end up troubleshooting. I hate when that happens.

Yup, exactly the same two questions I ask in my posts above.

**nightwalker** · October 22, 2007, 10:46 AM

I can see why, I've redone the system and seem to have gotten rid of my bug of the comport going dead, at least for now but those questions still remain.

I can not think of any reason that a two way UPB system should report the wrong status. It's downright embarrassing when I'm a thousand miles away talking to my wife on the phone and she tells me the lights didn't come on. Looking at it from my ppc all looks well so i turn on the lights again, manually this time. HS responds, tells me the light is on and it's not.

Maybe this is a wish list item, i wonder where that would go?

In case it's here there are two things.

1. Allow some way to monitor the PIM like the powerlinc is so i know something is wrong.

2. Please take a look at the plug-in code to see if there might be a reason why HS would be reporting the wrong status. It seems to me that the device should not be updated until HS sees the ACK come back from the PIM and if it's not returned generate an error message or even better trigger a Virtual device to show a problem. That i can act on and get notification of the problem no matter where i am.

What say HomeSeer, little help here!

**Oman** · October 22, 2007, 11:06 AM

HomeSeer requires that the device changes immediately to the new state, no matter how long the actual change takes to complete. The initial versions of the plug-in would change the status to "Unknown" if the communication to the device failed (after it failed which takes several seconds due to the fact that the plug-in *does* retry), but that caused some problems for people so it was removed. The log indicates the failure but there is no real way for HomeSeer to have failures reported on a device by device basis.

It would be possible to add an option to allow the devices to go to "unknown" if the command failed if the user chose to do so.

Jon

Originally posted by nightwalker View Post

I can see why, I've redone the system and seem to have gotten rid of my bug of the comport going dead, at least for now but those questions still remain.

I can not think of any reason that a two way UPB system should report the wrong status. It's downright embarrassing when I'm a thousand miles away talking to my wife on the phone and she tells me the lights didn't come on. Looking at it from my ppc all looks well so i turn on the lights again, manually this time. HS responds, tells me the light is on and it's not.

Maybe this is a wish list item, i wonder where that would go?

In case it's here there are two things.

1. Allow some way to monitor the PIM like the powerlinc is so i know something is wrong.

2. Please take a look at the plug-in code to see if there might be a reason why HS would be reporting the wrong status. It seems to me that the device should not be updated until HS sees the ACK come back from the PIM and if it's not returned generate an error message or even better trigger a Virtual device to show a problem. That i can act on and get notification of the problem no matter where i am.

What say HomeSeer, little help here!

**nightwalker** · October 22, 2007, 12:51 PM

Originally posted by Oman View Post

HomeSeer requires that the device changes immediately to the new state, no matter how long the actual change takes to complete. The initial versions of the plug-in would change the status to "Unknown" if the communication to the device failed (after it failed which takes several seconds due to the fact that the plug-in *does* retry), but that caused some problems for people so it was removed. The log indicates the failure but there is no real way for HomeSeer to have failures reported on a device by device basis.

It would be possible to add an option to allow the devices to go to "unknown" if the command failed if the user chose to do so.

Jon

Ok, i can see that and it makes sense, if HS didn't change the device in a timely manner all kinds of conditional events could be very slow in happening.

I'm not sure what problems could have been caused by an unknown status?

Failing that would the Plugin triggering a virtual device if the ACK command is not recieved? With at least that i could alert myself that there could be a problem.

Like i say all is well on my system now, but should something get in the way of the comport, plugin, or even noise on the powerline i'd at least have a way to know there is a problem without having to physically look to see if the device is on. Being away fairly often that's not always possible to physcially look at things.

Announcement

Plugin Stops Transmitting

Plugin Stops Transmitting

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment