Plug-in does not appear to show actual status

[tenholde]

Jon,

Is the fact that no ack was received logged under normal logging? I would at least like to know that my transmissions are not getting through.

Thanks,

tenholde

[SethP]

Thank you for the reply. I think a better option is to give users the choice of immediate status update, like you do now, or a delayed update upon ack/no ack. Nothing in my system will be negatively affected by the delayed update, and any scripts I write will take that into account.

Can you give some examples of issues in scripts? I've written a plugin for 1-wire devices, and I'm implementing delayed status updates. When closing a shade, for example, it can be 30 seconds from the command until the status update.

Thanks!

Seth

It is a requirement for the device status to update immediately (for events and scripts to work properly). The issue is one of an update to the status if the device did not respond. Originally the plug-in set the status to unkown after a failure. This caused problems for some users because of the multiple event firing (Off to On to Unknown). It could be added back in as an option.

[Oman]

If a plug-in responds to a device state set command it must alter the virtual device state immediately to the new state once the command is received. If it doesn't then HomeSeer will keep trying to send the same command over and over because the events will re-trigger when they shouldn't. About the only option is to later update the status to unknown if the command did not work.



Jon

Thank you for the reply. I think a better option is to give users the choice of immediate status update, like you do now, or a delayed update upon ack/no ack. Nothing in my system will be negatively affected by the delayed update, and any scripts I write will take that into account.

Can you give some examples of issues in scripts? I've written a plugin for 1-wire devices, and I'm implementing delayed status updates. When closing a shade, for example, it can be 30 seconds from the command until the status update.

Thanks!

Seth

[Michael McSharry]

I agree with Jon that the HS interface in this area is not the easiest to work with. In the case of mcsSprinklers that has a UPB interface (as well as other 2-way interfaces) I had initially updated the status of the device to Unknown and then when the status was received updated to the acknowleged status. Since the HS2 thread that sets the status (hs.SetDeviceStatus) is not the same as the one that provides the status (hs.DeviceStatus) I was experiencing situations where I was observing the status to be stale because I was checking status before HS2 has made the new status available to the second thread. The stale status resulted in erroneous control decisions.

The approach that I ending up using for HS2 was to leave the status unchanged at the time the command was given and update the status when a new state is determined from the hardware. I allow up to 4 retries on sending the command before I change the status to FAIL from the mcsSprinklers perspective or Unknown from the Homeseer perspective. Of course when a good status response is received the status is then updated and no additional retries sent.

The mcsSprinklers environment is likely different than the general lighting environment supported by the UPB Plugin so one approach will likely not work everywhere. I'm primarily trying to convey that what looks to be a simple function is actually rather complex when integrated with HS2. With HS1 this was easier for the plugin developer.

[nightwalker]

This is all very interesting, and far more complex that i would have thought. I think i understand the difficulties involved. That still leaves users with devices that can be reported incorrectly, should there be some sort of communication failure. There has to be some way for HS to detect that it's reported state of the device is not matching the actual state of the device, and either try again or at least report in the log that there is a problem.

I've only had one error with UPB in the year i've been using it so i'm not too worried about it, i just thought that having a two way system would get rid of incorrectly reported device states.

[tenholde]

This is all very interesting, and far more complex that i would have thought. I think i understand the difficulties involved. That still leaves users with devices that can be reported incorrectly, should there be some sort of communication failure. There has to be some way for HS to detect that it's reported state of the device is not matching the actual state of the device, and either try again or at least report in the log that there is a problem.

I've only had one error with UPB in the year i've been using it so i'm not too worried about it, i just thought that having a two way system would get rid of incorrectly reported device states.

How do you know you've only had one error? It would be nice if you could check the log.

tenholde

[SethP]

Thank you for all the technical information. It's all starting to make sense. I would recommend a few things:

1. As has been suggested already, all comm failures should be written to the HS log. This is helpful to all who care, and should not have any unanticipated consequences.
2. HS should not re-fire an event while it is still in progress. If it takes a few retries to get the USB command to go through, then the event is tied up during this time, and if it can't re-fire, then this delayed update should not matter. I think this issue is going to be very important in many areas, not just UPB. We are relying upon HS to control things, having 100% accurate status is not optional -- it's a baseline requirement.

mscSprinklers does not seem to have any problems with re-entrancy while waiting for confirmation before updating the device status.

3. In all cases where HS has holes like this, it should be clearly documented. I'm using HS & UPB to turn on a device based upon temperature. If that fails, significant property damage can result. Since the event looks at the current device status, it's subject to failure. I wrongly assumed that since UPB is two-way, HS takes full advantage of this. I'm going to experiement with changing my event so that it doesn't rely upon status, and instead periodically just sends the on or off command, but that's an awful kludge when we have a system that can absolutely tell me status.

4. Add a way to query the UPB plugin for actual status of a device. This is very important if other steps aren't done to show the true status. At least this way we have the option to put in better controls ourselves.

Seth

[Event5]

Just had a thought from "my perspective" What if you sent a Link that operated all desired devices at once and then afterwords (when there is usually no transmissions going on) send status queries.

Dave

[Oman]

The commands *are* retried over and over when they fail. It is not until all the retries are exhausted that the command is abandoned.

The problem isn't necessarily with the same event re-firing but other events using a trigger or condition that are at issue.

I do think that failed UPB commands are written to the normal log.

mcsSprinklers does actually have same issue (and handled in the opposite manor from the UPB plug-in because the environment is somewhat different) but since most users are actually not using HS events to control the individual zone logic it usually isn't an issue for that plug-in.

You can poll the status of most UPB devices to confirm that the result is as desired. This is different from confirming that it received the command because a command does not in all cases correlate to an actual resulting value. Polling the state of the channel will return an actual value that can be tested.

Jon

Thank you for all the technical information. It's all starting to make sense. I would recommend a few things:

1. As has been suggested already, all comm failures should be written to the HS log. This is helpful to all who care, and should not have any unanticipated consequences.
2. HS should not re-fire an event while it is still in progress. If it takes a few retries to get the USB command to go through, then the event is tied up during this time, and if it can't re-fire, then this delayed update should not matter. I think this issue is going to be very important in many areas, not just UPB. We are relying upon HS to control things, having 100% accurate status is not optional -- it's a baseline requirement.

mscSprinklers does not seem to have any problems with re-entrancy while waiting for confirmation before updating the device status.

3. In all cases where HS has holes like this, it should be clearly documented. I'm using HS & UPB to turn on a device based upon temperature. If that fails, significant property damage can result. Since the event looks at the current device status, it's subject to failure. I wrongly assumed that since UPB is two-way, HS takes full advantage of this. I'm going to experiement with changing my event so that it doesn't rely upon status, and instead periodically just sends the on or off command, but that's an awful kludge when we have a system that can absolutely tell me status.

4. Add a way to query the UPB plugin for actual status of a device. This is very important if other steps aren't done to show the true status. At least this way we have the option to put in better controls ourselves.

Seth

[tenholde]

With "Normal Log Entries" I unplugged a upb module and sent an ON and the only log entry is:

1/14/2008 2:31:36 PM Info Device: Xmas Tree Skirt ([14) ON

with "Debug Log Entries" I then send an OFF and the log entries are:

1/14/2008 2:35:56 PM Info Device: Xmas Tree Skirt ([14) OFF
1/14/2008 2:35:56 PM UPB PIM<--Sending 0A18250DFF2200070183 to PIM (Try # 1)
1/14/2008 2:35:56 PM UPB Waiting for ACK/NAK from PIM
1/14/2008 2:35:58 PM UPB PIM<--Sending 0A18250DFF2200070183 to PIM (Try # 2)
1/14/2008 2:35:58 PM UPB Waiting for ACK/NAK from PIM
1/14/2008 2:35:59 PM UPB PIM<--Sending 0A18250DFF2200070183 to PIM (Try # 3)
1/14/2008 2:35:59 PM UPB Waiting for ACK/NAK from PIM
1/14/2008 2:36:00 PM UPB PIM<--Sending 0A18250DFF2200070183 to PIM (Try # 4)
1/14/2008 2:36:00 PM UPB Waiting for ACK/NAK from PIM
1/14/2008 2:36:02 PM UPB PIM<--Sending 0A18250DFF2200070183 to PIM (Try # 5)
1/14/2008 2:36:02 PM UPB Waiting for ACK/NAK from PIM
1/14/2008 2:36:03 PM UPB ** Retry count exceeded, Can't send Msg

It certainly appears that UPB plugin does NOT log failures to normal log. And, as expected, the status of the device was set to OFF.

tenholde

[tenholde]

Jon,

I think I understand the complexity here, and any changes could create an issue for existing scripts/events, etc. Could I propose the following:

(1) Always log ack failures to the normal log

(2) Provide an option that would deal with ack failures as follows:

> Immediately change status as is done today

> If no ack recieved, then change status to 17, unknown


tenholde

[SethP]

Can this be done for a single device? If so, how? The only option I see is "Poll Devices".

Thanks!

Seth

You can poll the status of most UPB devices to confirm that the result is as desired. This is different from confirming that it received the command because a command does not in all cases correlate to an actual resulting value. Polling the state of the channel will return an actual value that can be tested.
Jon

[Oman]

I wanted to get an updated UPB plug-in build out anyway... so I have made the following changes...

1) If a direct command fails to ACK for any reason, the associated HomeSeer device will be updated to reflect the status of "Unknown". It will have had the desired state set during the retry period.

3) If a command fails to ACK there will be a failure log entry in all logging modes except for "none".

4) There is now a report generation option that will create a log file with the info I would need to fix any problems.

Does anyone want to do some beta testing?

Jon

Can this be done for a single device? If so, how? The only option I see is "Poll Devices".

Thanks!

Seth

[tenholde]

I'll be glad to.

tenholde

[Oman]

PM me an email address that I can send an attachment to and I'll send it over.

Jon

I'll be glad to.

tenholde