brente

Thanks Darin! I can confirm that this beta version does fix the volume slider and mute indicator issue.

@Jonathan, C4 Engineer@Darin, C4 PM UI I saw that Control4 released an updated iOS app yesterday (version 322.27.1.1654), but this issue with the volume slider not updating is NOT fixed in this release...

I missed Top fox’s original post here, but seeing the same thing myself. Version 321.46.1.1183 of the iOS os3 app worked fine, and probably subsequent versions until recently when this broke…

Ok, great! I looked and didn’t see any reports, so must have missed it. I had an older iOS device that had the iOS c4 app version 321.46.1.1183 back from dec 2021, and that worked perfectly. I say they broke it only a few updates ago…

Not sure when this broke in the iOS Control4 app, but when the audio changes for my room, the volume slider on the device page (and the smaller display on the room page) does not update as the volume changes and only shows the correct volume value after that page is refreshed (e.g., going back to the previous page and returning). Note that the Android version of the os3 control4 works as expected. The device volume changes with the volume controls, but the volume slider only shows a static number that doesn’t reflect the actual setting. This used to work just fine not too long ago, but I haven’t used my iOS device lately to control my room so never noticed until now that this is broken. Since the display works just fine on my Amazon fire 10, it’s not a controller issue. I have also force quit the ios control4 app with no change. The versions of the control4 apps are the latest with version numbers as: ios app version: 322.25.0.1627 android app version:322.21.0.10 anyone else seeing this? Control4 - can you confirm this is an issue?

Not sure if many others are still using the iOS control4 for OS2 app, but I've noticed that with iOS version 2.10.17 there is a noticeable 6-7 second delay when trying to activate a video device by tapping the device icon in the lower left corner of the Control4 UI after switching away from the Control4 app to use another app on an iOS device. Not sure if it's an iOS 14 issue, or a bug in the Control4 app, but it's 100% reproducible. Oddly, it doesn't seem to happen with an audio device (e.g., sonos). I've submitted feedback for the Control4 app beta via iOS TestFlight, but haven't seen any confirmation from Control4 about it. Not sure when this issue first started, but it's there now. Steps to reproduce are: - Watch a video device - press the Control4 icon in the upper left corner or the back arrow to return to the Control4 home screen - tap the device icon in the lower left corner to activate the device UI * the first time that the user does this, there is a 6-7 second delay before the device UI is displayed * once the device UI is displayed, the user can toggle back and forth between the Control4 Ui home screen and the device UI screen very quickly - switch to the Control4 home screen in the iOS app - switch to the iOS device home screen (putting the Control4 app in the background) - return to the Control4 app and tap the device icon in the lower left corner. * there is a 6-7 second delay before the device UI is displayed * after the delay is noticed, the user can toggle back and forth between the Control4 Ui home screen and the device UI screen very quickly this happens 100% for me on multiple devices. looking at the Control4 for OS2 app log, there are no entries beyond showing that the app was activated. Any Control4 employees around?

Darin - I never noticed this before (probably just never encountered this scenario), but here’s a UI display bug with the latest Control4 os2 2.10 app on iOS... When using the Control4 app on an iPad Pro, if the app is open in horizontal position and the security proxy is open, then the user switches to another app by swiping up from the bottom, then launches the Control4 app again, the Control4 app thinks that the orientation of the iPad Pro is in vertical mode instead of horizontal mode. Repro 100% Steps to reproduce: - orient the iPad to horizontal mode - launch the Control4 app and switch to the security proxy - note that the Control4 app detects horizontal orientation and the “disarmed ready” message is to the left of the center “arm” button - swipe the bottom to the right to switch to the previous app, or swipe up from the bottom to get to the home screen - swipe the bottom to the left to return to the Control4 app, or tap the Control4 app on the screen to launch again - Note that the app defaults to vertical orientation mode as shown in the screen shot below instead of first checking the orientation of the iPad before drawing the UI. This is incorrect behavior

@c4009 Looking into this, I learned that on the NX8/NX-8E panels the "*" key allows access to secondary arming settings (along with secondary functions, which I was aware of). So, using "*STAY" enables "Night Mode" for Stay and arms all zones (including interior zones), and "*EXIT" enables "Silent Exit" for Exit/Away arming. These aren't called out in the Interlogix manuals. Examining the Control4 Interlogix 584 driver, I saw that the current driver provides access to the secondary Silent Exit arming setting (as "Silent(Away)"), but not the Night setting. Interestingly enough, the 584 driver is coded for supporting Night arming setting mode, but that arming setting is commented out for some reason. To enable the Night arm setting, I modified the C4 Interlogix driver by changing the <arm_states> section of the driver.xml file to add back in the "Night" mode setting to the list. (I also updated the <modified> date and incremented the <version> number to reflect that changes were made). To install the revised driver, right-click the device in Composer Pro, then select Update Driver and choose the revised driver. After the driver is updated, you will need to reboot your controller for the changes to take effect. Note that this will not affect any of your security settings or bindings. After installing the revised driver and rebooting the controller, when you go to arm the panel, you will see that the arm settings pop-up list will now include "Night" as an arm setting option - see attached image (From the iOS Control4 app). You will also be able to enable this mode through programming, if desired. By the way, I never knew that the arm settings list in the Control4 app was scrollable (gotta love Apple's decision to hide scroll bars) - you can swipe up to see the other arming settings... Note that the 584 driver also has the "Stay (Auto Bypass)" arming setting commented out, along with a selection of other Interlogix panel secondary functions commented out too that don't appear under the Functions button. Probably not commonly needed options... securitypanel_interlogix_nx584.c4z

It seems as though it is the same data from the 2017 hack that pulled the user info from this web site...

@c4009 - I am not familiar with the use of “*” in front of “STAY” feature and don’t see any reference to this in the nx8e or keypad manual. From your description, it sounds like doing “*STAY” will bypass all of the internal sensors except one, but still set the alarm for instant Mode (as STAY does, versus EXIT mode) - I’ll have to try this on my panel to see if that works (wonder what zone type value determines this?). if correct, from what I am aware of, there is no way to do this from the Control4 security UI. I am not familiar with alarm.com and any functionality that they offer. Sorry. You can manually bypass zones from the c4 ui through the Function button, but it won’t let you “unbypass” zones that are automatically bypassed when arming the through STAY - it will only let you bypass additional zones that are not automatically included already.

Hi - unfortunately, from my experience with the 584 driver, you can’t access this functionality from c4 programming (Or a macro) directly. I’d have to double-check, but I believe that the driver does support and use this internally (I think by the functions capability as you saw - that capability emulates the interlogix keypad functionality), but you’d need to use LUA programming to access it and/or expose for c4 programming (non-trivial) - it is not exposed outside of the driver currently. May not help you, but a couple of things: - the 584 driver supports the ability to bypass an open zone automatically IF you have the automatic bypass setting enabled on the panel (the 587 driver did not). You can see this with an open zone by attempting to arm the panel from the c4 ui (can’t use an interlogix touch panel to do this), the c4 security panel driver will report a zone is open, and if you continue the arming process then the 584 driver will automatically bypass that open zone - when the error is displayed, you can manually close the zone, then arming will continue without bypassing the zone. However, you won’t be able to know whether the zone was bypassed or not beyond arming time. - if you want to bypass a specific zone automatically when arming, you can also set the appropriate property for that zone in your panel settings (e.g., automatically bypassing internal motion detectors when arming for STAY mode) - this is a function of the panel and not c4 (you may use this already). Still, not exposed programmatically. myself, I just manually bypass a zone when needed using the panel...

Attached are the full 584 driver instructions that are included with the "NX-584 RS-232 Automation Module" driver (the settings that @sweeper154 posted above are included in this documentation) - note that these instructions are also viewable from the Documentation tab for the 584 driver in Composer Pro or Composer HE. The instructions call out all of the panel/module settings that the driver expects. Changing the panel settings does require some knowledge - be sure to note current settings before changing in case you run into issues. You can find instructions on how to change the panel settings in the 584 module instructions or with in the nx8e instructions. Some things to be aware of: - the 584 driver reads all of the zone information (number, type, description, etc.) from the panel in several ways: when the driver is first installed, by using the action button, or when the controller is restarted. You can try the action button to refresh the zone information without restarting the controller. - if you have the panel settings correct and the zone count shows in composer (pro or HE), but the zone names are not displayed as they are on the keypad, you may need Control4 to fix this on your controller. It seems as though the driver (and older versions) doesn’t clean itself up completely so leaves data on the controller that can’t be removed by simply deleting the driver and restarting the controller. I did not have this problem going from the 587 driver to the 584 driver, but @Scrib ran into this, but I’m not sure exactly what Control4 did (they knew what needed to be done and it was quick). - if you turn on logging on composer, you should be able to watch the status messages that the driver generates as it processes the zone information read from the panel to aid in troubleshooting. - after the zone information is read correctly, you will be able to bind sensors to the zones to use the open/closed state for programming. once everything is up and running, it works well... documentation.rtf

@sweeper154 - since you have an nx-8e, assuming you’re using the built in 584 functionality? (Instead of the external 587 module). Ensure that you’re using the 584 driver per above. For panel settings, check the driver documentation for the default panel settings to use (which include baud rate, etc) - I believe you can see this from composer HE in the documentation tab for the driver, or your dealer can send to you. If you were using the 584 driver before upgrading, the driver should still function fine in the latest os3 update. If settings are right and it’s still not working, then their may be a driver issue on your controller - another user had that problem and c4 support fixed it (hopefully you won’t have to do this though).

Have your dealer search for the "NX-584 RS-232 Automation Module" driver - that should show up in their Composer Pro. It is compatible with OS3+

Not sure what's wrong, but I was using the AV7702 driver ("receiver_Marantz_AV7702_serial_ip.c4i") with an AV7702 for years and it worked great. When I replaced the AV7702 preamp with an AV7705, I kept the AV7702 driver in place as the functionality didn't really change, and I have no issues with volume control over IP. So, might want to try one of the older drivers. Also, see that you're using the EU version of the driver - no idea how it differs from the regular driver... edit: I'm using the AV7702 driver under 2.10.6 and it works great. No idea if issues exist for higher C4 versions...

Great. Be sure to follow the instructions included with the driver for the panel settings. Reach out if you have any trouble

It depends on what cable you have connected to your c4 controller (on my system, I actually have a null modem cable plugged into my controller). The 584e has a male db9 connector, so at least that side needs a female side. If you don’t need a cable, you can also go with a null modem adapter that fits in line with the cable.

@Scrib it's relatively straight forward. With the 584e connected to the system, just entering and exiting programming mode on the NX panel should add the 584e to the system (you don't need to remove the 587e - just disconnect it) - note that there is a delay after exiting as the panel checks for devices. In programming mode on the NX panel, you need to set it up per the 584e driver instructions (the instructions tell you settings to use) - there are only a few changes compared to the 587e configuration. Note that the driver says to disable any unused partitions/zones as otherwise they will show up in the C4 interface. The instructions say that a NULL modem cable is needed - not sure that's the case with the 587e, but I had to change my wiring to get the 584e to work with my cable (so, I'm thinking that the 587e didn't need a null modem cable). When all connected up, the 584e driver will report "Driver Initializing" while it reads in the partition/zone information from the panel. If you turn on trace Log Level in the Properties page of the 584e driver you can see the communication between the panel and the driver as the initializing process works - if you don't see any activity, then I'd check your cable... the 584e installation manual should come with your 584e and has the installation instructions to follow. You can find it here too: https://www.surveillance-video.com/media/lanot/attachments/customimport/NX-584E-Installation-Manual.pdf Reach out if you have questions...

@ERDrPCI agree with you that running the programming after an event occurs (e.g., weather alert event) would be the most efficient way to check the zones. I have an idea about getting the open zone names as you need, but need to find time to mess with it. Give me a week or so and I'll let you know what I come up with...

Not sure that the integration is any better from the 587e driver to the 584e, but here's some of what I see (may be incomplete): - when the 584e driver is put into an appropriate Log Level, you can see that the driver has access to all of the panel events/messages and will log/display all the alarm panel events that it sees, BUT not all of these events are exposed outside of the driver - after the 584e driver queries the panel and adds the zones to the system, you can connect contact sensors (or other) to the 584e driver. The sensors will show the open/closed state of as reported by the panel. You can then use the individual sensor state to trigger programming or to query the open/closed state. - the partition OPEN_ZONE_COUNT variable will indicate the number of zones that are open when arming is attempted. If zero, then all closed. if greater than zero, then something is open. - the "Arm Failed" partition event will be triggered if a zone is open when arming is attempted. The driver, however, will not report back what zone is open. You could (manually) query each zone to see which one (or more) are open if this event is triggered. You could create a programming macro that would add all open zones to a variable, and then use that variable to report open zones. - the "Disarm Failed" partition event is NOT triggered if an invalid alarm PIN is entered to disarm the alarm. I'd say this is a BUG in the 584e driver. As a workaround, you could watch the DISPLAY_TEXT partition variable for a change to the string "Operation Rejected by Panel" which is the error message displayed when an invalid code is entered. - the alarm arm/disarm panel will allow logging of the arm/disarm event and will report that a PIN was used, but will not display the actual PIN used (it's obscured) - (per above) if an invalid PIN code is entered, DISPLAY_TEXT partition variable for "Operation Rejected by Panel" which is the error message displayed when an invalid code is entered - when an alarm is triggered, the DISPLAY_TEXT variable (and panel display) will not report which zone causes the alarm to be triggered. The "OPEN_ZONE_COUNT" will indicate the number of zones open. as said above under "Arm Failed" partition event, you could have some code to manually check each zone and store their state in a variable to then report which zones triggered the alarm - could be the same programming macro code so would only have to code it once. UPDATE: the DISPLAY_TEXT variable does show the zone that caused the alarm, but the value stored in the variable changes very quickly so odds are if you try to display the contents, it won’t show the value as expected - you can reproduce this by using programming to show the value when it changes (e.g., include it in an email or a notification). - the ALARM_STATE partition variable does not appear to indicate whether an alarm has occurred or not. BUG. I'd think that it should, assuming that the variable is used to indicate the state of an alarm - its not documented in the driver so it's purpose is unclear. UPDATE: this variable seems to indicate whether the panel is in an alarm state (set to 1 for true), or not (set to 0 to false) So, while the driver doesn't make it easy to get access to the panel details, you could probably accomplish a lot of what you want with some work (a lot of work) by adding extra programming to the project. Too bad that the driver isn't more robust to simplify the reporting of the type of information that you are asking for. No idea if any of the other panel drivers report that information either.

coming from a 587e, the 584e works great with the NX8. One thing to be aware of is that the 584e requires a NULL modem cable, whereas the 587e uses a straight through cable. Going from the 587e, you will also end up removing all of your contact sensor bindings from the project as the 584e driver will query the panel/keypad directly and pull all zone/partition information and settings and will not use the separate contact sensor bindings that the 587 driver needed... correction: you don't need to remove your existing contact sensors and can bind them to the 584e driver if you want to use their state to program against

On iOS 13? If so, seems to be a known touchid bug in iOS... https://9to5mac.com/2019/09/30/ios-13-iphone-touch-id-login-bug/

This might help you... Depending on the actual driver that you are using, you may be able to display panel information through the email agent or the push notification agent by using text like this in the message body to reference the alarm variable state info such as: ${ROOM->SECURITYSYSTEMNAME::ALARM_STATE} ${ROOM->SECURITYSYSTEMNAME::DISPLAY_TEXT} ${ROOM->SECURITYSYSTEMNAME::TROUBLE_TEXT} Where "ROOM" is the name of the room that the security panel driver is assigned to, and "SECURITYSYSTEMNAME" is the name of the driver as used in the room - replace this text with the names from your project. The DISPLAY_TEXT variable should show the same information that would be displayed on a keypad panel, and the TROUBLE_TEXT would show any trouble messages that the panel reports. Depending on the version of the driver and security proxy used, you should be able to view the panel UI through the control4 user interface to view the alarm system state, then cycle through and display messages that would show on a keypad. So, if you're trying to arm the alarm, you should be able to see the alarm state to indicate if a contact is open and which one it is. If, however, you want the security panel zones to appear in the Control4 ui under Security->Locks & Sensors so that you can view the state of the actual sensors, then you do need to add a contact to each of the appropriate rooms and bind them to the security panel driver as lippaVisual says. If needed, you could probably check each contact sensor to see its state, but I found the just using the DISPLAY_TEXT variable close enough for my use...

Looks like I have a control4 bingo! Ha ha ha! while the ui customization seems nice, if that’s all that 3.0 brings for now, no hurry to upgrade for most current long time customers given the expense of new hardware and the pain of incompatibilities...

No worries. I haven't used mine much either, but was testing out my projector and saw it was skipping instead of scanning. I had thought that it worked before, but must not have. Given the crappy samsung remote, I figured I would try programming my AVR remote and that worked fine. Thanks for the original driver!