feature questions

[mikemack]

Hi Spud,


Admittedly I have not played around with your plugin yet, but wanted to ask up front if you supported or would consider supporting a few things that I thought were lacking from the previous upb version.

1. Intelligent queuing. UPB is sllooow. So it would be great if you could queue messages to a particular device, then when you have a transmit opportunity, collapse the requests to that device and take the last meaningful state to transmit.

If you wanted to be fancy you could timestamp the queued events and the UPB rx events and then allow incoming events (received over UPB) to purge the per-device queue.
Basically I want to be able to (in HSTouch) continually update a light with the value, but when I did that with the previous plugin the light just turned up and down for almost 5 mins trying to catch up.


2. Periodic polling. I would like to ask HS to poll the status of all of my devices at some time (maybe 3am or so) so that all the status is always consistant at the start of a day. Maybe also add some mismatch counters to help debug UPB communication issues where HS gets out of sync.


Thanks,
Mike

[jstaab]

I haven't had any performance issues so far that I've noticed. Some times there is a slight lag if you try to turn a light on and off immediately within the web page, say within the same second. I've just assumed it's because HS hasn't quite figured out the status has changed or the web page hasn't realized the change yet. All my lights are controlled by various events and motion sensors and all feels normal. For some unknown reason though, things seemed to feel a bit quicker with the 3.0.0.7 version, for what it's worth.

As far as devices out of sync, haven't had that happen yet or I haven't noticed. However, I set all my UPB devices to report their status when they physically change.

[spud]

1. Intelligent queuing. UPB is sllooow. So it would be great if you could queue messages to a particular device, then when you have a transmit opportunity, collapse the requests to that device and take the last meaningful state to transmit.

If you wanted to be fancy you could timestamp the queued events and the UPB rx events and then allow incoming events (received over UPB) to purge the per-device queue.
Basically I want to be able to (in HSTouch) continually update a light with the value, but when I did that with the previous plugin the light just turned up and down for almost 5 mins trying to catch up.

there is already something like that implemented for state requests, you can't queue more than one state request for the same device.
I'm not sure I understand what you mean by "continually update a light with a value"? Anyway I believe the implementation of this UPB plugin is quite different from the HS2's one so I would encourage you to try it and let me know what's not working for you.

2. Periodic polling. I would like to ask HS to poll the status of all of my devices at some time (maybe 3am or so) so that all the status is always consistant at the start of a day. Maybe also add some mismatch counters to help debug UPB communication issues where HS gets out of sync.

I could add a "poll current state" action to the plugin so that you can set up an event that run every night at 3am.
That being said it should be very rare that HS gets out of sync because everytime a UPB module change state it reports it to the plugin, and everytime the plugin sends a command to a UPB module, the HS device state is updated accordingly, and if the plugin detects an error for this command the state for the module is then requested to make sure everything is still synchronized.

[jstaab]

there is already something like that implemented for state requests, you can't queue more than one state request for the same device.
I'm not sure I understand what you mean by "continually update a light with a value"? Anyway I believe the implementation of this UPB plugin is quite different from the HS2's one so I would encourage you to try it and let me know what's not working for you.



I could add a "poll current state" action to the plugin so that you can set up an event that run every night at 3am.
That being said it should be very rare that HS gets out of sync because everytime a UPB module change state it reports it to the plugin, and everytime the plugin sends a command to a UPB module, the HS device state is updated accordingly, and if the plugin detects an error for this command the state for the module is then requested to make sure everything is still synchronized.

One thing to note, I believe you have to go into UPStart and set the device to report it's change when the switch is used locally. I don't think it's turned on per device by default.

[mikemack]

For continually update I was speaking of using a slider in HSTouch with the "TrackRealtime" set to True. This is nice because when you are adjusting, you can see the value before you lift your finger. When I did this before, HSTouch sent MANY change events as the slider was moving -- much faster then UPB could deliver them and it resulted in several minuets of the light changing brightness.

Regarding update - adding a poll state would be perfect. I have many upb switches (every light in the house is on UPB) and I have found that sometimes they can get out of sync - the UPB protocol is fine for what it does, but it has little in the way of collision detection, so if two switches are pressed simultaneously there is a good chance that the status reports will not be received.

Thanks,
Mike

[Uncle Michael]

UPB is sllooow. So it would be great if you could queue messages to a particular device, then when you have a transmit opportunity, collapse the requests to that device and take the last meaningful state to transmit.

Wow! How expectations change. Have you tried X10?

I understand what you are referring to (based on your follow-up post), and I don't understand UPB well enough to really know, but I suspect what you are describing might not be a characteristic of UPB, but the fade rate of the switch interacting with far too many sequential commands. I do agree that what you are asking for is preferred to a protocol that mindlessly sends every incremental dim value as a slider moves.

[spud]

Regarding update - adding a poll state would be perfect. I have many upb switches (every light in the house is on UPB) and I have found that sometimes they can get out of sync - the UPB protocol is fine for what it does, but it has little in the way of collision detection, so if two switches are pressed simultaneously there is a good chance that the status reports will not be received.

In version 3.0.0.8 available there: http://board.homeseer.com/showthread...01#post1088701
I have added an Action to poll UPB Device state. You can either poll a specific device or all of them.


As for your other request, if you are using "TrackRealtime" set to True only to see the value before you release the slider, you might want to ask HST to add a new option to be able to see the value but without updating the device until you lift your finger.

[mikemack]

Thank you!

I will give it a try, and also try again the setup with HSTouch.

Mike

[mikemack]

Ok, I gave it a try and I see the same issue that I had with the previous plugin.

It is easy to demonstrate. Attach a UPB device to a slider in HSTouch, and set the "TrackRealtime=TRUE". Then slide the slider up and down - you would expect the light to follow the position of the slider, but instead the act of moving the slider creates tons of messages and for several mins they are replayed to the device.

Mike

[spud]

I don't think it would be ever possible that your light follow the value of the slider in realtime, so I don't think you should use "TrackRealtime=TRUE".