[Release] Samsung Multiroom WiFi Audio

Fixed. Updated code to correct error and updated initial instructions to include the following:

SPECIAL INITIAL INSTALL INSTRUCTIONS:

  • Press 'Next' to install.
  • Immediately select 'Done' on the next page (installs app).
  • Run app again (now installed) and continue.

(For some reason, discovery does not work unless you install then run app again? I will investigate this further and try to resolve. But that is for another day.)

Link to updated app:
"Hubitat_Samsung-WiFi-Audio/Samsung WiFi Audio App.groovy at master · DaveGut/Hubitat_Samsung-WiFi-Audio · GitHub
"

aaron,

I am working on it. Still not able to replicate. It is not long term; but will take the rest of the week. It is more complex that I thought and I still can not replicate.

1 Like

I am using the Notification app and the speaker is selected as a music player so I can control volume. Just giving you my configuration.

@djgutheinz according to @chuck.schwer's answer in the Set TTL of SSDP discovery topic, this driver will soon find speakers in other subnets, but it won't work properly.

You use the mac field for ID of the child device, but it is null when the speaker is on a routed subnet. I use a modified version of your driver, where the ID is the SSDP UUID, and it works properly in all cases, maybe you should do something similar... This is how I solved the problem in the app:

def ssdpHandler(evt) {
	def parsedEvent = parseLanMessage(evt.description)
	logDebug("ssdpHandler:  parsedEvent = ${parsedEvent}")
	def ip = convertHexToIP(parsedEvent.networkAddress)
	def port = convertHexToInt(parsedEvent.deviceAddress)
	def mac = parsedEvent.mac == "null" ? "unknown" : convertDniToMac(parsedEvent.mac)
	def ssdpUSN = parsedEvent.ssdpUSN
	def uuid = ssdpUSN.replaceAll(/uuid:/, "").take(36)
	def speakers = state.speakers
	if (speakers."${uuid}") {
		def d = speakers."${uuid}"
		def child = getChildDevice(uuid)
		if (d.ip != ip) {
			d.ip = ip
			if (child) {
				logDebug("ssdpHandler: updating child, IP = ${ip}")
				child.updateDataValue("deviceIP", ip)
				child.updateDataValue("appVersion", appVersion())
			}
		}
	} else {
		def speaker = [:]
		speaker["dni"] = uuid
		speaker["mac"] = mac
		speaker["ip"] = ip
		speaker["ssdpPort"] = port
		speaker["ssdpPath"] = parsedEvent.ssdpPath
		speakers << ["${uuid}": speaker]
		logDebug("ssdpHandler:  speaker = ${speaker}")
	}
}

In case you're interested...

1 Like

Dave, I decided to start over again, and uninstalled everything, rebooted the HE, and reinstalled the driver and app. I can get it working, but like Aaron my queue gets stuck and I need to save preferences to clear it. Then it will work again.

I tried the previous git driver and app, and it wouldn't find my speakers with those. I am using the latest versions.

By the way, I really appreciate your work on this.

I am working on the queuing problem. I think it is caused by a new message coming in at the same time the queue is shutting down. I will figure it out.

1 Like

I update speaker driver to the latest version and now getting error

Do a Save Preferences. It will create the new "state.unreachableCount" which was created to temporarily stop the refresh cycle (and associated system load) if the speaker is not on the net. See post below.

@aaron, @chris

Update. I am still working the TTS queuing issue. The problem 'appears' to be with use of state within Hubitat. It is not always updating properly when set and this causes this (and other unnoticed problems).

I am working on the entire code set trying to reduce the reliance on state variables to a minimum, using data instead.

3 Likes

Updated SPEAKER driver is on GitHub. You MUST run save preferences after replacing driver code. Link:

"Hubitat_Samsung-WiFi-Audio/Samsung Speaker.groovy at master · DaveGut/Hubitat_Samsung-WiFi-Audio · GitHub"

Changes:
a. Fully tested all code for unnecessary activity.
b. Reworked Queuing to work per requirements.
c. Added automatic recover function to queuing. If queue is stuck, it will start queuing over in 30 seconds.
d. Tested queuing using play text, play text and resume, and speak. Had a up to 12 messages entered during the playing process with no drops, overlaps, or queue freezes.
e. Removed test queue. Use speak, play text, play text and resume.

2 Likes

@djgutheinz I have updated the device driver and haven't had any issues yet. Keep you posted if I run into anything.

1 Like

Getting errors, line 200 when hit save preferences and line 715 when notification sent .

Assure you have done a SAVE PREFERENCES. That enables the queue. It also start other processes that need to accommodate the latest version.

I'm using this mainly for notifications. They have now gone from taking 1 second to execute, to now taking 3-4 seconds to execute. If I open a door, it takes 3 seconds to tell me now. Previously it was 1 second. I also have 1 Sonos, and that notification is almost instant, less than a second.

error in line 200 , that is what I get after hit SAVE PREFERENCES...
I have two WAM1500 speakers, not sure if that matters...

Does it work otherwise? One suggestion, select debug logging in preferences. Then deselect save preferences.

Error is in Debug Logging. The new logical value has to be kick-started in the installation. Usually done on installation.

It works to play music from android application. I also can change input from Hubitat.

CrisD,
Let me make a special test version for you. Update or new code today.

1 Like

Thanks. I also have 2 R1's.

1 Like

I've managed to get speakers working. But I had to remove them from hubitat and add back....