jakblak

After seeing the output from those Lua snippets I believe you are correct. This same driver template is probably used for their receivers as well which most likely do display in DB

Feel free to also try this one which uses the STEP scale instead of the DB scale gSystemVolumeDisplay = "STEP" local output = 0 local volumeLevel_Step = 80 tVolumeSetCommandMap_Step[output].value = volumeLevel_Step command = tVolumeSetCommandMap_Step[output] QueueCommand(command)

Ok, looks like maybe it there was a problem with the snippet because I had edited it on my Mac. Anyway, here's a new one gSystemVolumeDisplay = "DB" local output = 0 local volumeLevel = 40 local minDeviceLevel = -92 local maxDeviceLevel = 23 local volumeLevel_dB = ConvertVolumeToDevice(volumeLevel, minDeviceLevel, maxDeviceLevel) tVolumeSetCommandMap_dB[output].value = volumeLevel_dB command = tVolumeSetCommandMap_dB[output] QueueCommand(command)

Strange, the API documentation does indicate that -46 should be a valid value at least when volume display is "DB". @Cartnj, would you mind trying the snippet below and then replying with the output from the log?. It's the same as above but this time it's explicitly setting the display to "DB" gSystemVolumeDisplay = “DB” local volumeLevel = 40 local minDeviceLevel = -92 local maxDeviceLevel = 23 local volumeLevel_dB = ConvertVolumeToDevice(volumeLevel, minDeviceLevel, maxDeviceLevel) tVolumeSetCommandMap_dB[0].value = volumeLevel_dB local command = tVolumeSetCommandMap_dB[0] QueueCommand(command)

Sorry @dinom, I'm not sure if that feature (Lua command window) is part of HE or not.

@dinom Try pasting the following commands into the Lua window of the driver and you can verify if there needs to be a conversion from a volume level to a db level local volumeLevel = 40 local minDeviceLevel = -92 local maxDeviceLevel = 23 local volumeLevel_dB = ConvertVolumeToDevice(volumeLevel, minDeviceLevel, maxDeviceLevel) tVolumeSetCommandMap_dB[0].value = volumeLevel_dB local command = tVolumeSetCommandMap_dB[0] QueueCommand(command) This is the equivalent of setting the volume level to 40 then converting it to the db scale (-92 to 23) that the API is looking for instead of the 0-50 scale that it's currently using. Feel free to set the volumeLevel to any number between 0 to 100 and see if you get the desired effect

I noticed the same thing and I can't see where the `gSystemVolumeDisplay` is being set although you could change it manually by going to the Lua window of the driver and typing gSystemVolumeDisplay = "STEP" As a side note, I modified the driver by changing the device volume range from 0-50 to -92-23 and that results in a value of -46 being sent to the driver instead which looks like a more appropriate value based on the range specified in the main.volumedb command. However, I think there's more to this bug beyond just changing the range.

Fair enough... I've written a few drivers in my time but it's not my full-time job so I admit I may be wrong. I'm just basing my assumptions off of what I see in the code and the debug output. Just for reference, that 20db value is then assigned to the 'value' field of this Sony API command tVolumeSetCommandMap_dB = { --index: mod 1000 value of Output Connection id --value: Protocol Command Data (Discreet Volume - command prefix/suffix) [0] = {id=0, type="set", feature="main.volumedb", value=""}, --valid values: -92.0 to 23.0. step = 0.5 | -100 = -? [1] = {id=0, type="set", feature="zone2.volumedb", value=""}, [2] = {id=0, type="set", feature="zone3.volumedb", value=""}, } Perhaps the 0-100 to 0-50 conversion should be translated to a value between -92.0 and 23.0 instead

The driver is not encrypted and I spent a few minutes going through it looking for the cause. What I've found is that the driver does in fact convert from a 0-100 scale to a 0-50 scale via the function below. Values being sent to this function are: volLevel = 20 minVolLevel = 0 maxVolLevel = 100 minDeviceLevel = 0 maxDeviceLevel = 50 function ProcessVolumeLevel(volLevel, minVolLevel, maxVolLevel, minDeviceLevel, maxDeviceLevel) local level = (volLevel-minVolLevel)/(maxVolLevel-minVolLevel) --Dbg:Info("level = " .. level) local vl=(level*(maxDeviceLevel-minDeviceLevel))+minDeviceLevel --Dbg:Info("vl = " .. vl) vl= tonumber(("%.".."0".."f"):format(vl)) --Dbg:Info("vl new = " .. vl) Dbg:Info("ProcessVolumeLevel(level in=" .. volLevel .. ", level out=" .. vl .. ")") return vl end The resulting output from the debug logs is this: ReceivedFromProxy(): SET_VOLUME_LEVEL on binding 5001; Call Function SET_VOLUME_LEVEL() OUTPUT: 4000 LEVEL: 40 ProcessVolumeLevel(level in=40, level out=20) PRX_CMD.SET_VOLUME_LEVEL(), volumeLevel_dB = 20 A volume level of 40 is coming into this function and is converted to 20 db. A SET_VOLUME_LEVEL (with a value of 20 db) command is then queued up to be sent to the sound bar. Looks like there may be a problem in the sound bar api or the firmware

Yep, I'll watch it and let you know when it gets fixed.

Hey @dinom, the problem exists in the driver. I reached out to the driver cert team and was told that since the driver is created by Sony we have to wait for them to make a fix. The driver team did make a request to Sony for an expedited fix.

The app is not quite ready to go out to public beta yet but when it is, I'll create a post with the link.

I have verified with the composer team that a T3 driver is required to be in the project. This will be fixed in the next release.

I’ll find the bug on this and see if it’s a problem with the iOS app. If so, my team can get it fixed for you. If it’s on the driver side, getting it fixed will depend on if it’s a certified driver that Control4 wrote.

I’ll check on this as I don’t think it should be a requirement. If so, it sounds like a bug

There was an app update that went live on Monday. The version of the Android app is 3.0.1, and 3.0.3 for iOS

Not sure if everyone noticed but Wakeup/Sleep functionality has now been added to all of the mobile apps for OS3.

I'm not a dealer but I can comment on this. The connection times are slower than they were in OS2 due to an underlying change in the networking technology used to talk to the controller. The team is hard at work on reducing connection times and we've already made great strides and we're continuing to reduce them further. We'll be dropping a public beta of the app in the next month or so with these connection improvements and I'll post the link in this thread so if you're interested you can give it a try. In the meantime, thanks for your patience

One of my favorite features

Hi @composedryan, We have done some work on Hikvision cameras in the latest release of the iOS OS2 app. Unfortunately it is still working it's way through the app store submission process, but if you would like, you can download the beta and give it a try. It can be found at this link https://testflight.apple.com/join/1T6qRsAk If the newest app doesn't work for you, please send me a PM and we'll see if we can get you back up and running.

@Tokead I do apologize about the missing Wakeup functionality in the OS2 app. We are working through the app store submission process at the moment and expect approval within a couple of days. If you would like to download the iOS OS2 beta app while you're waiting you can do so at the following link. https://testflight.apple.com/join/1T6qRsAk

Thanks @msgreenf, I didn’t know about that one. Admittedly I haven’t been dealing with Android issues, but I also haven’t seen that on my own system. That doesn’t sound like what CTO is dealing with however.

Hey @CTO, we certainly tested with OS3 on multiple systems with more than 6 T3s, including my own (2 portables, 5 in-walls) and I’m not aware of any issues with intercom or anything else. It does sound like you have something else going on. Have you contacted your dealer since the update?

This was unintentional and is being worked on. We'll have an app update shortly.

Stating that “There is nothing revolutionary or evolutionary about that function” tells me that you have some in-depth knowledge about Control4 hardware and software that I’m not aware of. I know that what C4 does may seem trivial and could easily be done on hardware as simple as a Raspberry PI but I assure you, it is not. Having worked at Control4 for over a decade, I’ve been in many meetings where product managers are desperately trying to figure out how to NOT deprecate hardware. Sometimes the problem is limited engineering resources and sometimes it is the result of hardware limitations that can’t be overcome. I can confidently tell you that the decision to deprecate hardware is never taken lightly and has never been done with the intent to sell something new and better.