SqueezeBox speak

Just set-up openhab 2 on a rPi2, added bindings for Network, SqueezeBox and a few ESP8266 modules. Also installed rssvoice. I’m not interested in controlling SqueezeBox from within openhab but would like to interrupt music with “Watson come here” commands. I put in a simple rule for squeezebox to trigger at a specific cron time to test the setup, then I restarted my rPi.

My squeezebox is running on Max2play (rPi3)

Is this command suppose to work in openhab2?
squeezeboxSpeak(“max2play3”, “This is Major Tom to Ground Control”)

Is there something else I’m suppose to configure?
thanks

No. This is the OH1 method.

Please see the documentation here

Thank you for pointing me to the right documentation. I thought that I had gone off the deep end.

I think I understand most of what the documentation shows me but I’m confused by the Thing Configuration. I’ve created a squeezebox.thing file in /etc/openhab2/things called squeezebox.things
copied the example & changed the Mac & Ip address

Then reboot the rPi the log says I don’t have a server configured I I think I do?
Is there something else I need to do?
Thanks for your help

2017-07-16 09:27:19.943 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Stopped Paper UI
2017-07-16 09:27:19.967 [INFO ] [panel.internal.HABPanelDashboardTile] - Stopped HABPanel
2017-07-16 09:27:19.988 [INFO ] [.dashboard.internal.DashboardService] - Stopped dashboard
2017-07-16 09:28:03.466 [INFO ] [voicerss.internal.VoiceRSSTTSService] - Using VoiceRSS cache folder /var/lib/openhab2/voicerss/cache
2017-07-16 09:28:28.901 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'squeezebox.things’
2017-07-16 09:28:32.314 [INFO ] [.dashboard.internal.DashboardService] - Started dashboard at http://192.168.0.106:8080
2017-07-16 09:28:32.318 [INFO ] [.dashboard.internal.DashboardService] - Started dashboard at https://192.168.0.106:8443
2017-07-16 09:28:34.335 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app
2017-07-16 09:28:34.654 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2017-07-16 09:28:34.974 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2017-07-16 09:28:37.246 [INFO ] [ebox.handler.SqueezeBoxPlayerHandler] - player thing squeezebox:squeezeboxplayer:EFA4839D-A968-4642-B2D1-C8896F78FD6B:b827eb1f3dfb has no server configured, ignoring command: REFRESH
2017-07-16 09:28:40.571 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber ‘org.eclipse.smarthome.core.thing.link.ThingLinkManager@120572e’ takes more than 5000ms.

I resolved this part but still not hearing anything. I see that Max2play is using a version of squeezelit based on 1.8.4 so I’ll need to send a request to update that.

So does this stop me from continuing my testing. I mean can I hear anything at all?
thanks

Yes, you definitely need a squeezelite version 1.8.6-985 or newer. Notifications will not play on squeezelite versions before 1.8.6-985.

Edit: You could try piCorePlayer. The latest version of pCP includes the a version of squeezelite with the fix.

I used the piCorePlayer WebUI to update recently and it upgraded to the latest and greatest v3.21, but it’s not > 985.

piCorePlayer | piCorePlayer v3.21 | linux 4.9.35-pcpCore | piCore v8.01 | Squeezelite v1.8.6-938

Does anybody have better information? Is > 985 really in the v3.21 Download?

I need to clarify my post above.

The initial fix for the notification issue was in squeezelite build 938. Any build 938 or later should work. However, a further fix was included in build 985. I don’t know when 985 will be included in a pcp release.

FWIW, I’m running pcp 3.20, which includes squeezelite build 957

piCorePlayer v3.20 | linux 4.9.21-pcpCore_v7 | piCore v8.01 | Squeezelite v1.8.6-957

Seems odd that pcp 3.21 would contain squeezelite build 938. Nevertheless, you should be ok with build 938.

Well, I lost/began having issues with this upgrade of piCorePlayer. I wrote a rule that used several say commands. It worked for a while, then it began doing the previously fixed issue. Where the URL is sent, then we get TIMEOUT Warnings. So I don’t think that 938 will work correctly especially for say commands…

Trying to get back to stable.

Maybe try pcp 3.20? It’s been working well for me.

One other comment, I’m on OH2 Stable these days. Not sure I can revert and I’m not sure I want to go burn some img files. Might switch to a Chromecast Audio. Sure to be better supported now.

It was a really cool rule too, it read my kids spelling words to them. Kind of an Automated Spelling test.

Frustrated!

I’ve downgraded to 3.20, and I can break it. I’m getting the TIMEOUT waiting for items to update.

2017-09-13 11:41:01.804 [INFO ] [arthome.model.script.logSpellingTest] - Rule playSound Test
2017-09-13 11:41:01.811 [INFO ] [arthome.model.script.logSpellingTest] - Trying to Speak
2017-09-13 11:41:06.705 [WARN ] [ebox.handler.SqueezeBoxPlayerHandler] - TIMEOUT after 4000 waiting for volume to update!
2017-09-13 11:41:11.713 [WARN ] [ebox.handler.SqueezeBoxPlayerHandler] - TIMEOUT after 5000 waiting for playlist to update!
2017-09-13 11:41:15.723 [WARN ] [ebox.handler.SqueezeBoxPlayerHandler] - TIMEOUT after 4000 waiting for volume to update!
2017-09-13 11:41:23.432 [WARN ] [ebox.handler.SqueezeBoxPlayerHandler] - TIMEOUT after 4000 waiting for volume to update!
2017-09-13 11:41:28.439 [WARN ] [ebox.handler.SqueezeBoxPlayerHandler] - TIMEOUT after 5000 waiting for playlist to update!

I believe that this must be related to the short audio file issue. I’m effectively looping through a list of words. I’ve attempted to send the engine a long string with pauses, but I have not figured out a working pause notation (… ,) that is similar to the following.

I know the return in the Exit logic is not ideal either.

var boolean exitFlag = false

rule "Joeys Spelling Test"

when

   Item JoeySpell changed to ON

then

   logInfo("logSpellingTest","Rule playSound Test")

   val myList = newArrayList('poetry',
                                'museum',
                                'variety',
                                'favorite',
                                'quietly',
                                'cruelty',
                                'violet',
                                'money',
                                'creator',
                                'fluent',
                                'actual',
                                'city',
                                'pioneer',
                                'triangle',
                                'Messiah',
                                'people',
                                'congruent',
                                'diagram',
                                'giant',
                                'they' )

   logInfo("logSpellingTest","Trying to Speak")

      myList.forEach[ str |

         say("Spell the word.     " + str)

         Thread::sleep(3000)

         say("" + str)

         Thread::sleep(3000)

        if(JoeySpell.state == OFF) {

            logInfo("Spelling Test turned OFF, exiting.")

            return

         }

      ]

   JoeySpell.sendCommand(OFF)

end

I don’t think so. The signature of the short audio file issue is a single 30 second timeout when playing the mp3 stream. The timeouts above appear to be on all commands being sent to the LMS.

This looks more like an issue with the LMS or the player, or both. Did you try restarting the LMS and the pcp?

Yes, I did restart all components. I even restarted the binding itself. Your comment got me thinking that maybe pCp wasn’t ready for my next request, so I increased my two timeouts. Things are working now. I will keep an eye on it.

  myList.forEach[ str |

     say("Spell the word.     " + str)
     Thread::sleep(8000)
     say("" + str)
     Thread::sleep(6000)

Thanks for the reply,

Tony

Hi all,

since my upgrade to OH 2.2 the TTS with Squeezebox only works very sporadically; most of the times I see the following in the .logs:

2017-12-23 13:33:59.190 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Play notification sound on player 00:04:20:2a:37:4b at URI http://192.168.0.73:8080/audio/c2a3930d-4093-419e-9aeb-a806829c2c9e.mp3
2017-12-23 13:33:59.191 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Cur State: vol=20, mut=NOT MUTED, pwr=OFF, stp=STOPPED, ctl=PAUSED, shf=OFF, rpt=OFF, tix=0, tnm=1, tim=17
2017-12-23 13:33:59.192 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Setting up player for notification
2017-12-23 13:33:59.193 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Powering on the player
2017-12-23 13:33:59.194 [DEBUG] [ebox.handler.SqueezeBoxServerHandler] - Sending command: 00:04:20:2a:37:4b power 1
2017-12-23 13:33:59.195 [DEBUG] [ebox.handler.SqueezeBoxServerHandler] - Sending command: 00:04:20:2a:37:4b mixer volume 0
2017-12-23 13:34:03.206 [WARN ] [ebox.handler.SqueezeBoxPlayerHandler] - TIMEOUT after 4000 waiting for volume to update!
2017-12-23 13:34:03.207 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Playing notification
2017-12-23 13:34:03.208 [DEBUG] [ebox.handler.SqueezeBoxServerHandler] - Sending command: 00:04:20:2a:37:4b playlist add http://192.168.0.73:8080/audio/c2a3930d-4093-419e-9aeb-a806829c2c9e.mp3
2017-12-23 13:34:08.262 [WARN ] [ebox.handler.SqueezeBoxPlayerHandler] - TIMEOUT after 5000 waiting for playlist to update!
2017-12-23 13:34:08.263 [DEBUG] [ebox.handler.SqueezeBoxServerHandler] - Sending command: 00:04:20:2a:37:4b mixer volume 20
2017-12-23 13:34:08.563 [DEBUG] [ebox.handler.SqueezeBoxServerHandler] - Sending command: players 0
2017-12-23 13:34:12.275 [WARN ] [ebox.handler.SqueezeBoxPlayerHandler] - TIMEOUT after 4000 waiting for volume to update!
2017-12-23 13:35:08.566 [DEBUG] [ebox.handler.SqueezeBoxServerHandler] - Sending command: players 0

This happens independendly of the amount of text I pass to the “say” command; I use 8 hardware squeezeboxes - thus the sync of all of them (e.g. if you switch another one on) can take a moment …

Any help appreciated :-).

with kind regards,
Patrik

That’s odd. It looks like the LMS is not responding (or not responding timely) to some pretty basic commands (like the command to change the volume). Have you tried restarting the LMS?

Hi Mark,

thank you for the reply; did a restart - but the problem persists. Here the response times for some commands that went through:

2017-12-23 14:38:20.389 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Done waiting 900 ms for volume to update
2017-12-23 14:38:22.609 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Done waiting 2200 ms for playlist to update
2017-12-23 14:38:23.026 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Done waiting 400 ms for volume to update
2017-12-23 14:38:29.035 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Done waiting 2100 ms for volume to update
2017-12-23 14:38:30.452 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Done waiting 1400 ms for playlist to update
2017-12-23 14:38:36.085 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Done waiting 5600 ms for stop
2017-12-23 14:38:36.405 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Done waiting 300 ms for volume to update
2017-12-23 14:38:38.428 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Done waiting 2000 ms for playlist to update
2017-12-23 14:38:38.845 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Done waiting 400 ms for volume to update
2017-12-23 14:39:44.744 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Done waiting 2400 ms for volume to update

I wonder if I should try a binding with higher timeout value - but with OH 2.1 I never had this problem. Thus I wonder a higher timeout would just mask another problem, or if my system indeed needs more time since the OH 2.2. update. Surprisingly, the system does not feel slow when operated via openhab.

I´ll try to compile a binding version with higher timeout values to see what happens; btw: shall I create a pull request to move the timeout values to constants?

with kind regards,
Patrik

I wonder if a rule (e.g. the artist meta data lookup) slows down the plugin; I´ll first have a look into this …

with kind regards,
Patrik

A couple of those volume update times are really long, especially anything over 1 sec. The playlist update times look about right – it’s normal for the LMS to take a long time on that. It certainly can’t hurt to try tweaking the timeout values, but it seems to me like there’s something else going on here.

I’d suggest you hold off on the PR until we can track this down.

If the rule is doing queries against the LMS, then that might be worth looking into. Maybe log those lookups in the rule to see if they coincide with the timeouts.

Mhhh… the rules are not active in the are in question; sometimes it works - but most of the times the volume change times out. If I change the volume via UI there´s only a slight delay.

2017-12-23 17:16:43.517 [DEBUG] [eezebox.internal.SqueezeBoxAudioSink] - Processing audioStream http://192.168.0.73:8080/audio/8b3e4e6c-8d4f-4075-91c2-05478830c9d9.mp3 of format AudioFormat [codec=MP3, container=NONE, bitDepth=16, bitRate=64000, frequency=44100]
2017-12-23 17:16:43.518 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Play notification sound on player 00:04:20:2a:37:4b at URI http://192.168.0.73:8080/audio/8b3e4e6c-8d4f-4075-91c2-05478830c9d9.mp3
2017-12-23 17:16:43.519 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Cur State: vol=30, mut=NOT MUTED, pwr=ON, stp=NOT STOPPED, ctl=PLAYING, shf=OFF, rpt=OFF, tix=10, tnm=21, tim=119
2017-12-23 17:16:43.521 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Setting up player for notification
2017-12-23 17:16:43.522 [DEBUG] [ebox.handler.SqueezeBoxServerHandler] - Sending command: 00:04:20:2a:37:4b stop
2017-12-23 17:16:43.523 [DEBUG] [ebox.handler.SqueezeBoxServerHandler] - Sending command: 00:04:20:2a:37:4b mixer volume 20
2017-12-23 17:16:47.550 [WARN ] [ebox.handler.SqueezeBoxPlayerHandler] - TIMEOUT after 4000 waiting for volume to update!
2017-12-23 17:16:47.551 [DEBUG] [ebox.handler.SqueezeBoxPlayerHandler] - Playing notification

I´ll create a build with more timeout for the volume to see how that performs …