HSPhone Caller ID - Not Returning to previous state

[cheaha]

I'm using the latest beta version of the plugin (issue was there with earlier versions too, just wanted to make sure problem hadn't already been addressed). I used the speaker proxy with out the write to file option (HS attached to line in) and HSPhone to announce caller-ID. Sent caller-id to $SONOS$TTS$ and it's set to speak on every ring. This works great; however, after all is done, the zones do NOT return to previous state. They load the previous stream (online radio) but they don't go back to playing status.

This DOES work when using hs.speakex but not when sending via the standard speak in the HS interface.

To Test:

• Setup SonosController to act as speaker proxy
• Create a TTS group
• Setup HSPhone to announce caller-id and send TTS to $SONOS$(TTS Group Name)$
• Start a radio stream on sonos
• Call yourself

Any ideas?

Related to this thread? LINK

[dcorsus]

I'm using the latest beta version of the plugin (issue was there with earlier versions too, just wanted to make sure problem hadn't already been addressed). I used the speaker proxy with out the write to file option (HS attached to line in) and HSPhone to announce caller-ID. Sent caller-id to $SONOS$TTS$ and it's set to speak on every ring. This works great; however, after all is done, the zones do NOT return to previous state. They load the previous stream (online radio) but they don't go back to playing status.

This DOES work when using hs.speakex but not when sending via the standard speak in the HS interface.

To Test:

• Setup SonosController to act as speaker proxy
• Create a TTS group
• Setup HSPhone to announce caller-id and send TTS to $SONOS$(TTS Group Name)$
• Start a radio stream on sonos
• Call yourself

Any ideas?

Related to this thread? LINK

Any chance to turn debug on, do your thing and email or post the debug log.
You write "it's set to speak on every ring" does that mean you have a handfull of link/announce/unlink actions in rapid succession? If so, what is the periodicity of these announcements? If in rapid succession, I wouldn't be surprised that the radio station is not back in "playing" state when the second announcement kicks in and now a wrong state would be stored. Anyway just guessing and therefore a log would help.

Thanks

Dirk

[cheaha]

Dirk,

Sure, I'll post a log. You make a good point. I assumed that the return to previous state would have a built in delay preventing a scenario like you described, but that was foolish to assume that. It is possible that the ring event (about three seconds apart) causes the recovery process already in progress to halt, thus not quite making it back to a playing state, then recording the wrong state as the current state. We'll look at the log to see.

If that is the case, then would it be possible to build in a user definable delay to the recovery process. For example, recover previous state after 4000ms therefore, if a new TTS comes in, the old values will still be preserved, thus ensuring that only after that delay will recovery begin and eventually make it back to where we started from? Perhaps even be able to define that recovery delay as a function of the Speaker group in addition to the group, volume, and mute options. That would mean we could define a custom grouping to handle these types of announcements that wouldn't effect the other system announcements recovery time.

We'll know more once I post the log I'm sure. Thanks!

[cheaha]

Ok. It does on first inspection feel like a race condition. If I turn off debugging I sometimes get a demonstration of the problem, however, if I turn on debuging (which slows everything down a good bit), the condition does not present ever.

I have attached a selection from the log; however, keep in mind that the problem is NOT showing when debugging is turned on. I'm not sure if the log will be enough information, as it looks like I hit the wrap length on the HS log. Let me know if it isn't and I'll redo it with a longer setting.

Again though, it feels like exactly what you described: a condition where the rapid succession of TTS events causes an interruption of the restoration mid way, and then records the wrong settings when it starts again. I really do think the most elegant solution would be to add a optional delay (which obviously would address the issues as the delay caused by debugging option is demonstrating) to the Link Group Table entry that allows for delay for user definable recovery delays for specific link groups. This is only one way of doing it, the other would be just to check the proxy queue for array length prior to starting recovery process and then adding a 1000ms delay on top of that.

If for no other reason, there is also another key advantage to adding a delay... as recovering, stopping, speaking, recovering, stopping, speaking is rather cpu intensive and could be introducing some delay to the actual TTS event itself. By adding the delay it should allow for faster repeat TTS response time. What are your thoughts on this?

By the way...here is a compliment ... your plugin is one of the tightest homeseer implementations of a plugin I have run across. From a programatic standpoint you really have done a fantastic job. UPNP can be tricky and the level at which you have tied into the HomeSeer architecture is about best case as one could hope for, so "thank you"

[dcorsus]

Ok. It does on first inspection feel like a race condition. If I turn off debugging I sometimes get a demonstration of the problem, however, if I turn on debuging (which slows everything down a good bit), the condition does not present ever.

I have attached a selection from the log; however, keep in mind that the problem is NOT showing when debugging is turned on. I'm not sure if the log will be enough information, as it looks like I hit the wrap length on the HS log. Let me know if it isn't and I'll redo it with a longer setting.

Again though, it feels like exactly what you described: a condition where the rapid succession of TTS events causes an interruption of the restoration mid way, and then records the wrong settings when it starts again. I really do think the most elegant solution would be to add a optional delay (which obviously would address the issues as the delay caused by debugging option is demonstrating) to the Link Group Table entry that allows for delay for user definable recovery delays for specific link groups. This is only one way of doing it, the other would be just to check the proxy queue for array length prior to starting recovery process and then adding a 1000ms delay on top of that.

If for no other reason, there is also another key advantage to adding a delay... as recovering, stopping, speaking, recovering, stopping, speaking is rather cpu intensive and could be introducing some delay to the actual TTS event itself. By adding the delay it should allow for faster repeat TTS response time. What are your thoughts on this?

By the way...here is a compliment ... your plugin is one of the tightest homeseer implementations of a plugin I have run across. From a programatic standpoint you really have done a fantastic job. UPNP can be tricky and the level at which you have tied into the HomeSeer architecture is about best case as one could hope for, so "thank you"

Before I go add new features, could you post how you trigger the event. Do you have events/actions that get triggered by HSPhone or are you intercepting speaker device IDs (speaker proxy). If the prior, my recommendation would be to restructure the actions and add delays to it. Your case is probably the worse were the period of 3 seconds is (in your case) long enough to start the linking/unlinking but too short for the player to go back completely to its "original" state. Do you need the event for each ring? If you could post how you do it, I might have some suggestions

Dirk

[cheaha]

I don't use anything special....it's a core feature of HSPhone. It announces the Caller-ID on each ring by default. All I did is specify $SONOS$TTS$ as the target speaker client. But even beyond HSPhone I can see where there are programatic cases where several series of TTS outputs would happen rapidly in succession.

[dcorsus]

I don't use anything special....it's a core feature of HSPhone. It announces the Caller-ID on each ring by default. All I did is specify $SONOS$TTS$ as the target speaker client. But even beyond HSPhone I can see where there are programatic cases where several series of TTS outputs would happen rapidly in succession.

I see ... how nice of HSPhone to make it so easy :-)

Are there any knobs in HSPhone we can turn? I assume it announces the callerID upon each ring. Does HSPhone allow you to add a prefix or suffix text (or sound) to this? If they allow some customizable sentence, we can add a SAPI delay (xml) tag to it.

Dirk

[cheaha]

Unfortunately only the prefix is editable and does not use a variable for the actual caller-id information, so there is no way to add a delay at the end (<silence msec="1000"/>). Let me ask, how are you choosing to return from a speak? Are you checking the proxy queue for waiting events before you return the sonos to previous settings. It would seem that the best way to avoid the issue all together is to find the race condition.

Can you describe the process of the speaker proxy event a little so I can better understand the steps taken by the plugin? Also, I'm having trouble understanding the point of having the link-tts option in the master control, if one can just use hs.speakex and trigger the link automatically with the return. Seems like Link-TTS is not necessary...what am I missing?

[dcorsus]

Unfortunately only the prefix is editable and does not use a variable for the actual caller-id information, so there is no way to add a delay at the end (<silence msec="1000"/>). Let me ask, how are you choosing to return from a speak? Are you checking the proxy queue for waiting events before you return the sonos to previous settings. It would seem that the best way to avoid the issue all together is to find the race condition.

Can you describe the process of the speaker proxy event a little so I can better understand the steps taken by the plugin? Also, I'm having trouble understanding the point of having the link-tts option in the master control, if one can just use hs.speakex and trigger the link automatically with the return. Seems like Link-TTS is not necessary...what am I missing?

I guess you can add the delay at the front, it really doesn't matter whether at front or end except that you would like to know asap who is calling so you can either pick up or not.

The way things work are as follows. Announcements have a queue per linkgroup. So the first announcement that triggers linking (and saving current state) will create the queue. As long as new announcements are coming in while current announcements are converted to speech and played, the announcements are queued. As soon as the last announcement has ended, the unlinking happens immediately. So you are unlucky in a number of ways, if the announcement was slightly longer, they would be added to the queue and you wouldn't have a problem. If they were shorter the unlinking would be done and the player would have reverted to original state. If it wasn't for a radio station, the player state would move to playing instantaneously, now it can take many seconds for the buffering to be complete before the player moves to playing state.

So why not try to add the tag to the prefix and see how things go. Adding a delay to any announcement isn't a good solution, doing it on some and not others is a lot harder to implement. Finding a work around is the easiest for me

As to your question about the link control, this would be used if you have something totally different you want to do. For example, you may want to set your players in a certain configuration and then play something. There are people who set players to whole house, play some radiostation, triggered by disarming their alarm. If you had a clear trigger when the phone starts ringing and a clear trigger when it ends, you could use that to prevent the repetitive speech but as you state, it would be a lot harder.


Dirk

[markesdale]

My HsPhone setup

Just my two cents here... I have HSphone and am using CallID with Dirk's Sonos PeopleImport plugin.

HSphone defaults to speaker device 0.

All I did was setup the controller to broadcast speaker device 0 to the zones I needed it in. Stops the need for the $Sonos$ stuff all together and it seems to work fine.

M

[cheaha]

Thanks for the reply. What is the PeopleImport plugin? Tried doing a search but came up empty.